Zweitens hat John recht. Wir haben gestern den ganzen Vormittag damit verbracht, mit unseren Auditoren einen Haufen Mängel zu diskutieren, die sie gefunden haben«, fahre ich fort. »Dick Landry geht der Hintern schon auf Grundeis, weil das den Finanzbericht für dieses Quartal beeinflussen könnte. Wir müssen unsere Änderungen besser im Griff haben, und als Manager und technische Leiter müssen wir uns überlegen, wie wir einen vernünftigen Prozess aufsetzen können, der selbst verschuldete Pannen vermeidet und uns die Auditoren vom Hals hält, gleichzeitig aber dafür sorgt, dass wir unsere Arbeit erledigt bekommen. Wir werden diesen Raum nicht eher verlassen, bevor wir nicht einen Plan ausgearbeitet haben. Verstanden?« Zufrieden sehe ich, dass alle angemessen eingeschüchtert sind, und eröffne die Diskussion. »Was hält uns also davon ab, das zu erreichen?«
Einer der technischen Leiter sagt schnell: »Ich werde anfangen. Dieses Change-Management-Tool ist unbenutzbar. Es gibt Millionen Pflichtfelder, und in den meisten Fällen sind die Auswahlboxen für ›Betroffene Anwendungen‹ nicht passend gefüllt. Darum habe ich es aufgegeben, überhaupt Change Requests einzutragen.«
Ein anderer Leiter ruft: »Das stimmt. Wenn ich mich an Pattys Regeln halte, muss ich Hunderte Servernamen per Hand in eines der Textfelder eintragen. Und meist ist das Feld gar nicht groß genug! 100 Servernamen sollen in ein Textfeld mit 64 Zeichen passen? Welcher Idiot hat das denn gebaut?«
Weiteres, unerfreuliches Lachen.
Patty ist knallrot geworden. Sie ruft: »Wir müssen Auswahlboxen nutzen, damit wir die Datenintegrität wahren können! Und ich würde die Liste mit den Anwendungen liebend gerne aktuell halten, aber ich habe keine Ressourcen dafür. Wer hält denn den Anwendungskatalog und die Change-Management-Datenbank up to date? Meint ihr, das geschieht irgendwie per Magie?«
»Es geht nicht nur um das Tool, Patty. Der ganze Prozess ist kaputt«, erklärt Wes. »Wenn meine Leute Change Requests eintragen, müssen sie ewig warten, bis die genehmigt sind, geschweige denn eingeplant werden. Uns sitzt das Business die ganze Zeit im Nacken, dass wir unseren Kram erledigt bekommen. Wir können nicht darauf warten, dass du unsere Einträge bis ins Detail analysierst und dich dann beschwerst, dass nicht alle Felder korrekt ausgefüllt sind.«
Patty meckert zurück: »Das ist Quatsch, und das weißt du. Deine Leute halten sich nie an die Regeln. Ihr markiert doch auch alle Change Requests als ›dringend‹ oder als ›Notfalländerung‹. Das Feld ist nur für echte Notfälle gedacht!« Wes erwidert: »Das müssen wir doch tun, denn nur so schaut sich dein Team die Einträge überhaupt an! Wir können nicht drei Wochen darauf warten, eine Erlaubnis zu bekommen.«
Einer der leitenden Techniker schlägt vor: »Vielleicht könnten wir noch ein weiteres Feld aufnehmen mit dem Namen ›Extrem dringend‹?«
Ich warte, bis alle wieder zur Ruhe gekommen sind. Wenn wir so weitermachen, erreichen wir heute gar nichts mehr. Schließlich sage ich nach hektischem Nachdenken: »Wir machen zehn Minuten Pause.«
Als wir fortfahren, sage ich: »Wir beenden dieses Meeting nicht ohne eine Liste mit genehmigten und terminierten Änderungen, die wir in den nächsten 30 Tagen umsetzen.
Wie ihr sehen könnt, hat meine Assistentin einen Stapel leerer Karteikarten mitgebracht. Ich möchte, dass jede Gruppe jede geplante Änderung aufschreibt – eine pro Karte. Dabei sollen drei Informationen darauf stehen: wer die Änderung plant, welches System geändert wird sowie eine kurze Zusammenfassung in einem Satz.
Ich habe einen Kalender auf das Whiteboard gemalt, auf dem wir die genehmigten Änderungen schließlich je nach Termin anpinnen werden«, fahre ich fort. »Das sind die Regeln. Kurz und einfach.«
Wes schnappt sich einen Stapel Karten und schaut sie misstrauisch an. »Echt jetzt? Karteikarten, heutzutage? Warum nehmen wir nicht gleich deinen Laptop, der scheint ja noch älter zu sein als diese Karten?«
Alle lachen – mit Ausnahme von Patty. Sie sieht verärgert aus, ganz offensichtlich ist sie nicht begeistert über die Richtung, in die dieses Meeting läuft.
»Das ist so anders als jeder Change-Management-Prozess, den ich je zu Gesicht bekommen habe«, sagt John. »Aber ich werde meine Änderungen an die Tafel pinnen. Zum Beispiel die anstehenden Firewall-Updates und Änderungen am Monitoring, die für die nächsten Tage geplant sind.«
Überraschenderweise inspiriert Johns Bereitschaft zur Teilnahme auch andere, und sie fangen an, fleißig ihre Änderungen auf die Karten zu schreiben.
Schließlich sagt Wes: »Okay, versuchen wir es. Alles ist besser als dieses blöde Change-Management-Tool.«
Einer der Techniker hält eine Handvoll Karten hoch. »Ich habe hier alle Datenbankänderungen aufgeschrieben, die wir machen wollen.«
Als ich zustimmend nicke, liest er eine der Karten vor: »Vom Hersteller empfohlenes Wartungsskript für die Datenbank auf dem Octave-Server XZ577 ausführen, um Filial-POS-Performanceprobleme zu beheben. Betrifft die Order Entry-Datenbank und die Anwendungen. Sollte am nächsten Freitagabend um 20:30 ausgeführt werden.«
Ich nicke und bin erfreut über die Klarheit der vorgeschlagenen Änderung. Aber Wes sagt: »Das ist doch keine Änderung. Ihr führt doch nur ein Datenbankskript aus. Wenn du das Skript ändern würdest, könnten wir uns darüber unterhalten. Nächster Punkt.«
Aber der Techniker antwortet: »Nein, das ist definitiv eine Änderung. Es passt temporär ein paar Datenbankeinstellungen an, und wir wissen nicht, was für eine Auswirkung das auf die Produktion haben kann. Für mich ist das genauso riskant wie eine Änderung der Datenbankkonfiguration.«
Ist das eine Änderung oder nicht? Ich kann beide Seiten nachvollziehen.
Nach 30 Minuten Diskussion ist immer noch nicht klar, was wir unter einer »Änderung« verstehen.
Ist der Neustart eines Servers eine Änderung? Ja, weil wir nicht wollen, dass irgendjemand einfach so einen Server durchstartet, insbesondere wenn darauf ein kritischer Service läuft. Das Abschalten eines Servers? Ja, aus dem gleichen Grund.
Wie ist es mit dem Einschalten eines Servers? Nein – haben wir alle gedacht. Bis jemand das Beispiel brachte, in dem ein zweiter DHCP-Server eingeschaltet und damit das gesamte Firmennetzwerk für 24 Stunden lahmgelegt wurde.
Nach einer weiteren halben Stunde schreiben wir schließlich auf das White-board: »Eine ›Änderung‹ ist jede Aktivität, die physisch, logisch oder virtuell auf Anwendungen, Datenbanken, Betriebssysteme, Netzwerke oder Hardware wirkt und die bereitgestellte Services beeinflussen kann.«
Ich werfe einen Blick auf meine Uhr. Wir sind jetzt schon 90 Minuten hier und haben noch nicht einmal die erste Änderung genehmigt. Ich drängle jetzt ein wenig, aber am Ende des zweistündigen Meetings haben wir gerade einmal fünf Änderungen an das Whiteboard gepinnt.
Erstaunlicherweise scheint außer mir niemand frustriert zu sein. Jeder hat sich an der lebhaften Diskussion beteiligt, selbst Patty. Jeder denkt über die Risiken der vorgeschlagenen Änderungen nach, manchmal sogar mit dem Ergebnis, dass eine Änderung gar nicht notwendig ist.
Ermutigt sage ich: »Wir werden am Montag damit weitermachen. Lasst eure Karten so bald wie möglich Patty zukommen. Patty, wie können wir die Karten am besten durcharbeiten?«
Kurz angebunden sagt sie: »Ich werde später ein Körbchen dafür beschriften. Bis dahin stapelt sie einfach hier vorne auf dem Tisch.«
Als das Meeting aufgelöst wird, teilen mir beim Hinausgehen viele Leute mit: »Tolles Meeting« und »Ich wünschte, wir hätten mehr Zeit gehabt« oder »Ich freue mich auf Montag!«.
Nur Patty bleibt zurück, mit verschränkten Armen. »Wir haben viel Blut, Schweiß