Projekt Phoenix

Der Roman über IT und DevOps

Gene Kim
Kevin Behr
George Spafford

Deutsche Übersetzung von Thomas Demmig

Beijing · Cambridge · Farnham · Köln · Sebastopol · Tokyo

Die Informationen in diesem Buch wurden mit größter Sorgfalt erarbeitet. Dennoch können Fehler nicht vollständig ausgeschlossen werden. Verlag, Autoren und Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für eventuell verbliebene Fehler und deren Folgen.

Alle Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt und sind möglicherweise eingetragene Warenzeichen. Der Verlag richtet sich im Wesentlichen nach den Schreibweisen der Hersteller. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

Kommentare und Fragen können Sie gerne an uns richten: kommentar@oreilly.de

Copyright der deutschen Ausgabe:

© 2015 by O’Reilly Verlag GmbH & Co. KG

1. Auflage 2015

Die Originalausgabe erschien 2013 unter dem Titel

The Phoenix Project: A Novel About IT, DevOps, and Helping

Your Business Win in der IT Revolution Press, Portland, Oregon.

Bibliografische Information Der Deutschen Bibliothek

Die Deutsche Bibliothek verzeichnet diese Publikation in der

Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

Übersetzung und deutsche Bearbeitung: Thomas Demmig

Lektorat: Alexandra Follenius, Köln

Fachgutachten: Christian Trabold, Singapur

Korrektorat: Sibylle Feldmann, Düsseldorf

Satz: III-satz, www.drei-satz.de

Umschlaggestaltung: Michael Oreal, Köln

Produktion: Karin Driesen, Köln

Belichtung, Druck und buchbinderische Verarbeitung:

Druckerei Kösel, Krugzell; www.koeselbuch.de

ISBN 978-3-95875-175-0

Dieses Buch ist auf 100% chlorfrei gebleichtem Papier gedruckt.

Parts Unlimited

Parts Unlimited: Führungsteam

Steve Masters, CEO, kommissarischer CIO

Dick Landry, CFO

Sarah Moulton, SVP Retail Operations

Maggie Lee, Senior Director of Retail Program Management

Bill Palmer, VP IT Operations, zuvor Director of Midrange Technology Operations

Wes Davis, Director Distributed Technology Operations

Brent Geller, Lead Engineer

Patty McKee, Director IT Service Support

John Pesche, Chief Information Security Officer (CISO)

Chris Allers, VP Application Development

Parts Unlimited: Aufsichtsrat

Bob Strauss, Lead Director, ehemaliger Vorstandsvorsitzender, ehemaliger CEO

Erik Reid, Aufsichtsratskandidat

Nancy Mailer, Chief Audit Executive

Zur sofortigen Veröffentlichung

Freitag, 29. August

Firma: Parts Unlimited (PAUD)

Einstufung: SELL

Kursziel: $8 (aktuell $13)

Steve Masters, CEO von Parts Unlimited, tritt nach acht Jahren mit sofortiger Wirkung von seiner Position als Vorstandsvorsitzender zurück. Aufsichtsratsvorsitzender Bob Strauss, vor 20 Jahren selbst Vorstandsvorsitzender und CEO, kehrt aus seinem Ruhestand zurück, um diese Rolle wieder einzunehmen.

Der Aktienkurs von Parts Unlimited ist in den letzten 30 Tagen bei starkem Handel um 19% gefallen und liegt jetzt 52% unter seinem Spitzenwert von vor drei Jahren. Die Firma verliert weiterhin an Boden gegenüber ihrem Erzrivalen, der bekannt dafür ist, die Bedürfnisse seiner Kunden vorauszuahnen und darauf zügig zu reagieren. Parts Unlimited läuft seiner Konkurrenz nun in Bezug auf Umsatzwachstum, Warenumsatz und Rentabilität hinterher.

Das Unternehmen hat schon länger versprochen, dass sein »Phoenix«-Programm es wieder zu altbekannter Rentabilität zurückführen und den Abstand zur Konkurrenz verringern wird, indem es die Filial- und E-Commerce-Kanäle enger miteinander verzahnt. Obwohl das Programm sich schon um Jahre verzögert hat, gehen viele davon aus, dass die Firma bei der Telefonkonferenz mit Analysten im nächsten Monat eine weitere Verzögerung bekanntgeben wird.

Wir glauben, dass institutionelle Investoren wie Wayne-Yokohama Bob dazu gedrängt haben, als erste Maßnahme den Vorstand neu auszurichten, um das Schiff in Elkhart Grove wieder in ruhigeres Fahrwasser zu leiten. Eine wachsende Zahl von Investoren drängt auf weitere deutliche Änderungen im Führungsstab und auf strategische Entscheidungen, wie zum Beispiel die Aufspaltung des Unternehmens.

Laut unseren Quellen hat der Aufsichtsrat Strauss und Masters sechs Monate gegeben, um drastische Verbesserungen zu bewirken. Wenn sie das nicht schaffen, ist von weiteren Wechseln und turbulenten Zeiten auszugehen.

Kelly Lawrence, Chief Industry Analyst, Nestor Meyers

Teil 1

KAPITEL 1

Dienstag, 2. September

»Bill Palmer hier«, melde ich mich am Handy direkt nach dem ersten Klingeln.

Ich bin spät dran, daher fahre ich zehn Meilen pro Stunde schneller als erlaubt – anstelle meiner üblichen fünf. Ich habe den Morgen mit meinem dreijährigen Sohn im Wartezimmer des Kinderarztes verbracht und versucht, ihn nicht von den anderen anstecken zu lassen, während immer wieder mein Telefon vibrierte.

Heute sind unregelmäßige Netzwerkaussetzer das Problem. Als Director of Midrange Technology Operations bin ich verantwortlich für die Verfügbarkeit und Funktionsfähigkeit einer recht kleinen IT-Gruppe bei Parts Unlimited, einer Produktions- und Vertriebsfirma aus Elkhart Grove mit vier Milliarden Dollar Jahresumsatz.

Selbst in den ruhigeren Gefilden, für die ich mich mit meinem Job entschieden habe, muss ich Netzwerkprobleme schnell beheben. Weil ein kaputtes Netzwerk die Services stört, die meine Gruppe anbietet, muss ich mich auch um solche Dinge kümmern.

»Hallo Bill, hier ist Laura Beck aus der Personalabteilung.« Mit ihr habe ich sonst nichts zu tun, aber ihr Name und ihre Stimme klingen vertraut ... Mist. Ich versuche, nicht zu laut zu fluchen, als ich mich wieder erinnere. Aus den monatlichen Firmen-Meetings. Sie ist die verantwortliche VP of HR. »Guten Morgen Laura«, sage ich mit einem erzwungenen Lächeln, »was kann ich für Sie tun?«

»Wann sind Sie im Büro? Ich würde Sie gerne so schnell wie möglich treffen«, ist ihre Antwort.

Ich hasse solch unklare Meeting-Anfragen. Ich selbst mache so etwas nur, wenn ich jemanden zusammenfalten will. Oder entlassen.

Moment. Ruft Laura an, weil mich jemand feuern will? Gab es einen Ausfall, auf den ich nicht schnell genug reagiert habe? Als Mitarbeiter in IT Operations machen wir ständig unsere Witze über diese letzte Panne, die unsere Karriere beenden wird.

Wir vereinbaren, uns bei ihr in einer halben Stunde zu treffen, aber als sie keine weiteren Details preisgibt, frage ich so schmeichelnd wie möglich: »Laura, worum geht es denn? Gibt es ein Problem in meiner Gruppe? Oder stecke ich selbst in Schwierigkeiten?« Ich lache extra laut, damit sie es auch bei sich hören kann.

»Nein, nein, darum geht es nicht«, sagt sie fröhlich. »Eigentlich sind es sogar gute Nachrichten. Bis gleich, Bill.«

Als sie auflegt, versuche ich mir auszumalen, wie gute Nachrichten heutzutage aussehen könnten. Als mir das nicht gelingt, schalte ich das Radio wieder ein und höre augenblicklich einen Werbespot unseres größten Konkurrenzhändlers. Es geht um seinen einmaligen Kundenservice und ein atemberaubendes Angebot, bei dem die Leute ihre Autos mit ihren Freunden zusammen online konfigurieren können.

Die Werbung ist toll. Ich würde den Service sofort nutzen, wenn ich nicht so loyal zu meiner Firma stünde. Wie schaffen sie es nur, solch unglaubliche Dinge auf den Markt zu bringen, während wir nicht von der Stelle kommen?

Ich schalte das Radio aus. Trotz all unserer Arbeit und der langen Nächte zieht die Konkurrenz problemlos an uns vorbei. Wenn unsere Marketingleute diesen Werbespot hören, gehen sie bestimmt die Wände hoch! Denn weil sie eher aus der Kunst- oder Musikecke kommen und keinen technischen Hintergrund haben, versprechen sie den Kunden das Blaue vom Himmel, und die IT muss dann sehen, wie sie das liefern kann.

Jedes Jahr wird es schwerer. Wir müssen mehr mit weniger erreichen und konkurrenzfähig bleiben, während wir gleichzeitig Kosten verringern.

Manchmal denke ich schon, dass das nicht klappen kann. Vielleicht habe ich zu viel Zeit als Sergeant bei den Marines verbracht. Dort lernt man, seinen Standpunkt gegenüber seinem Vorgesetzten so gut wie möglich zu vertreten, aber bisweilen muss man einfach »Yes, Sir!« sagen und dann diesen Hügel einnehmen.

Ich biege auf den Parkplatz ein. Vor drei Jahren war es so gut wie unmöglich, einen freien Platz zu finden. Nach den ganzen Entlassungen ist Parken nur noch selten ein Problem.

Beim Betreten von Gebäude 5, in dem Laura und ihre Kollegen sitzen, stelle ich überrascht fest, wie nett es hier eingerichtet ist. Ich kann noch den neuen Teppich riechen, und es gibt sogar schicke Holzpaneele an den Wänden. Plötzlich kommen mir die Wände und Teppiche in meinem Gebäude sehr alt vor. Die hätten längst erneuert werden müssen. Wie unsere IT. Immerhin sitzen wir nicht in einem armseligen, schwach beleuchteten Kellerloch wie in der britischen Serie The IT Crowd.

Als ich Lauras Büro erreiche, schaut sie lächelnd hoch. »Schön, Sie wiederzusehen, Bill.« Wir geben uns die Hände. »Nehmen Sie Platz, während ich schaue, ob wir uns jetzt mit Steve Masters treffen können.«

Steve Masters? Unser CEO?

Während sie zum Telefon greift, setze ich mich hin und schaue mich um. Das letzte Mal war ich vor ein paar Jahren hier, als wir von der Personalabteilung aufgefordert wurden, einen Raum für stillende Mütter bereitzustellen. Wir hatten damals viel zu wenig Büros und Meeting-Räume, und es standen kritische Projekt-Deadlines an.

Eigentlich ging es nur darum, einen Konferenzraum in einem anderen Gebäude zu nutzen, aber bei Wes klang das so, als wären wir ein Haufen von Mad Men-Neandertalern aus den 1950ern. Kurz danach wurden wir beide für einen halben Tag herzitiert, um politisches Bewusstsein und unser Verhalten zu schulen. Vielen Dank, Wes.

Neben vielem anderen ist Wes auch für die Netzwerke verantwortlich, weshalb ich mich immer so intensiv um Netzwerkprobleme kümmere.

Laura dankt der Person am anderen Ende der Leitung und wendet sich mir zu. »Schön, dass Sie so kurzfristig kommen konnten. Wie geht es Ihrer Familie?«

Ich runzle die Stirn. Wenn ich Small Talk halten wollte, würde ich andere Leute bevorzugen als jemanden aus HR. Ich zwinge mich zu ein paar Sätzen über unsere Familien und Kinder und versuche dabei, nicht allzu intensiv über all die anderen Dinge nachzudenken, die ich jetzt eigentlich erledigen müsste. Schließlich frage ich direkt: »Also, was kann ich für Sie tun?«

»Natürlich. Entschuldigung.« Sie macht eine Pause, dann sagt sie: »Seit heute Morgen arbeiten Luke und Damon nicht mehr für unsere Firma. Da ist einiges ganz nach oben gekocht, und schließlich wurde Steve einbezogen. Er hat Sie als neuen Vice President of IT Operations ausgewählt.«

Sie lächelt mich an und hält mir ihre Hand hin. »Bill, Sie sind der neue VP in der Firma. Ich denke, ich darf gratulieren?« Heilige Scheiße. Ganz benommen schüttele ich ihre Hand.

Nein, nein, nein. Das Letzte, was ich will, ist eine »Beförderung«.

Luke ist unser CIO gewesen, der Chief Information Officer. Damon hat für ihn gearbeitet, er war mein Chef, verantwortlich für IT Operations in der gesamten Firma. Und jetzt sollen beide einfach weg sein?

Das habe ich nicht kommen sehen. Es gab keine Gerüchte. Gar nichts.

In den letzten zehn Jahren kamen und gingen neue CIOs. Alle zwei Jahre, wie ein Uhrwerk. Sie blieben gerade lang genug, um die Abkürzungen zu verstehen, zu wissen, wo sich die Toiletten befinden, einen Haufen Programme und Initiativen aufzusetzen, die alles über den Haufen werfen, und dann wieder zu verschwinden.

CIO steht für »Career Is Over«. Und VPs of IT Operations sind nicht weit davon entfernt.

Mir war klar geworden, dass der Trick für eine lange Karriere im Management von IT Operations darin liegt, erfahren genug zu sein, um seine Sachen ordentlich zu machen, dabei den Kopf aber immer schön geduckt zu halten, um den strategischen Spielchen auszuweichen, die einen verletzbar machen. Ich habe überhaupt kein Interesse daran, einer der VPs zu werden, die sich den lieben langen Tag nur gegenseitig PowerPoints zuschicken.

Um Laura mehr Informationen zu entlocken, versuche ich es mit Witzchen. »Zwei Executives, die gleichzeitig gehen? Haben sie silberne Löffel geklaut?«

Sie lacht, zeigt aber schnell wieder ihr HR-gestähltes Pokerface. »Sie haben beide entschieden, sich neu zu orientieren. Näheres werden Sie sie selbst fragen müssen.«

Gemeinhin ist es so: Wenn Ihr Kollege Ihnen sagt, dass er sich entschieden hat, zu gehen, war das freiwillig. Erzählt Ihnen jemand anderes, dass er gehen wollte, war das erzwungen.

Folglich wurden mein Boss und dessen Boss gerade rausgeworfen.

Das ist genau der Grund dafür, dass ich keine Beförderung möchte. Ich bin sehr stolz auf das Team, das ich in den letzten zehn Jahren aufgebaut habe. Wir sind nicht viele, aber wir sind die bei Weitem am besten organisierte und zuverlässigste Truppe. Insbesondere verglichen mit Wes.

Beim Gedanken daran, der Chef von Wes zu sein, stöhne ich auf. Er managt kein Team – er ist eigentlich nur einen Schritt von einem chaotischen Mob entfernt.

Als mir der kalte Schweiß auf der Stirn steht, weiß ich, dass ich diese Beförderung niemals akzeptieren werde.

Die ganze Zeit hat Laura weitergeredet, und ich habe kein einziges Wort mitbekommen. »... und daher müssen wir uns natürlich überlegen, wie wir diesen Wechsel bekannt geben. Und Steve möchte Sie so schnell wie möglich sehen.«

»Laura, vielen Dank für das Angebot. Ich fühle mich geehrt. Aber ich will diesen Job nicht. Warum sollte ich? Ich liebe meine aktuelle Arbeit, und es gibt so viel, was ich da noch erledigen will.«

»Ich glaube nicht, dass Sie eine Wahl haben«, sagt sie mitfühlend. »Das kommt direkt von Steve. Er hat Sie persönlich ausgesucht, also müssen Sie mit ihm reden.«

Ich stehe auf und bleibe standhaft: »Nein, wirklich. Vielen Dank, dass Sie an mich gedacht haben, aber ich habe schon einen tollen Job. Ich wünsche viel Glück dabei, jemand anderen zu finden.«

Minuten später führt mich Laura zu Gebäude 2, dem höchsten auf unserem Gelände. Ich ärgere mich über mich selbst, dass ich mich in diesen Wahnsinn habe reinziehen lassen.

Wenn ich jetzt losrenne, wird sie mich bestimmt nicht einholen können, aber was dann? Steve würde mir einfach einen Trupp HR-Schläger hinterherschicken und mich wieder einfangen.

Ich sage nichts. Ich habe jetzt wirklich kein Interesse an Small Talk. Laura scheint das nicht zu stören, sie geht flott neben mir her, über ihr Smartphone gebeugt und ab und zu die Richtung angebend.

Sie findet Steves Büro, ohne einmal aufzusehen. Offensichtlich ist sie diesen Weg schon viele Male gegangen.

Dieser Flur ist warm und einladend, eingerichtet wie in den 1920ern, als dieses Gebäude erbaut wurde. Mit dem dunklen Holzboden und den Buntglasfenstern stammt es aus einer Ära, als im Büro noch jeder Anzüge trug und Zigarren rauchte. Damals florierte die Firma – Parts Unlimited schuf diverse Bauteile, die in so gut wie jedem Auto zu finden waren, als die Pferdekutschen gerade aus dem Alltag verschwanden.

Steve hat ein Eckbüro, vor dem eine Sekretärin Wache hält. Sie mag um die 40 sein, strahlt Freundlichkeit aus und scheint ausgesprochen organisiert zu sein. Ihr Schreibtisch ist aufgeräumt, die Wand hinter ihr übersät mit Klebezetteln. Neben ihrer Tastatur steht eine Kaffeetasse mit den Worten: »Don’t mess with Stacy«.

»Hi Laura«, sagt sie, als sie von ihrem Computer hochschaut. »Viel los heute, was? Das ist also Bill?«

»Jepp, höchstpersönlich«, antwortet Laura lächelnd.

Zu mir sagt sie: »Stacy sorgt dafür, dass bei Steve alles läuft. Sie werden sie bald gut kennenlernen, vermute ich. Wir beide können später weitermachen.« Dann geht sie.

Stacy lächelt mich an. »Schön, Sie kennenzulernen. Ich habe schon viel von Ihnen gehört. Steve erwartet sie.« Sie zeigt auf seine Tür.

Ich mag sie auf Anhieb. Und ich denke darüber nach, was ich gerade erfahren habe. Laura hatte heute viel zu tun. Stacy und Laura kennen sich sehr gut. Steve hat also einen direkten Draht zu HR. Offensichtlich bleiben Leute, die für Steve arbeiten, nicht lange in der Firma.

Toll.

Als ich Steves Büro betrete, bin ich ein bisschen überrascht, dass es fast genauso aussieht wie das von Laura. Es hat die gleiche Größe wie das meines Chefs – okay, meines Exchefs – und wie vermutlich mein zukünftiges Büro, wenn ich mich dümmer anstelle, als ich bin.

Vielleicht habe ich persische Teppiche, Wasserspiele und große Skulpturen erwartet. Stattdessen gibt es Fotos eines kleinen Propellerflugzeugs, von seiner fröhlichen Familie und – zu meiner Überraschung – eines von ihm in einer Uniform der US Army auf einer Landebahn irgendwo in den Tropen. Mir fallen die Abzeichen an seinen Aufschlägen auf.

Steve war also ein Major.

Er sitzt hinter seinem Schreibtisch und prüft irgendwelche Excel-Ausdrucke. Hinter ihm ist ein Laptop aufgeklappt, auf dem in einem Browser eine Reihe von Aktienkursen zu sehen ist.

»Bill, schön, Sie wiederzusehen«, sagt er, steht auf und schüttelt mir die Hand. »Es ist schon lange her. Etwa fünf Jahre, oder? Nachdem Sie dieses beeindruckende Projekt gestemmt haben, eine der eingekauften Firmen zu integrieren. Ich hoffe, es ist Ihnen seitdem gut ergangen?«

Ich bin überrascht und ein bisschen geschmeichelt, dass er sich an unser kurzes Zusammentreffen erinnert, insbesondere da es doch schon so lange her ist. Ich lächle und sage: »Ja, sehr gut, danke. Ich bin beeindruckt, dass Sie sich daran erinnern.«

»Sie glauben, wir geben solche Prämien an jeden?«, sagt er ernst. »Das war ein wichtiges Projekt. Damit sich der Zukauf bezahlt machte, mussten wir ihn gut in unsere Firma einbringen, was Sie und Ihr Team ausgezeichnet hinbekommen haben.

Ich bin sicher, Laura hat Ihnen ein bisschen was über die organisatorischen Änderungen erzählt, die ich vorgenommen habe. Sie wissen, dass Luke und Damon nicht mehr länger in der Firma arbeiten. Ich werde die Position des CIO noch neu besetzen, aber bis dahin wird die IT direkt an mich berichten.«

Geschäftig fährt er fort: »Wie auch immer, weil Damon jetzt weg ist, muss ich eine Position neu besetzen. Nach unseren Recherchen sind Sie deutlich der beste Kandidat für den VP of IT Operations.«

Als ob er sich gerade erinnert, sagt er: »Sie waren ein Marine. Wann und wo?«

Ich antworte automatisch: »22. Marine Expeditionary Unit. Seargent. Ich war sechs Jahre dabei, habe aber nie einen Kampf miterlebt.«

Als ich mich daran erinnere, wie ich damals als großspuriger 18-Jähriger zu den Marines ging, muss ich lächeln. »Die Armee hat mir in manchen Dingen den Kopf zurechtgerückt – ich verdanke ihr viel. Trotzdem hoffe ich, dass keiner meiner Söhne dort unter den Bedingungen beitreten würde, die ich damals erlebt habe.«

»Das glaube ich gerne.« Steve lacht. »Ich war selbst acht Jahre in der Armee, nur etwas länger, als ich musste. Aber es machte mir nichts aus. Das ROTC¹ war die einzige Möglichkeit für mich, das College zu bezahlen, und es ist mir dort gut ergangen.«

Lächelnd fügt er hinzu: »Sie haben uns nicht so verhätschelt wie euch Marines, aber ich kann mich trotzdem nicht beschweren.«

Ich lache und stelle fest, dass ich ihn mag. Das ist das längste Gespräch, das wir je hatten. Ich frage mich plötzlich, ob es das ist, was Politiker ausmacht.

Ich versuche jedoch, mich darauf zu konzentrieren, warum er mich hat kommen lassen: Er will mich dazu bringen, irgendeine Kamikaze-Aufgabe zu übernehmen.

»So sieht es im Moment aus«, sagt er und lässt mich an seinem Konferenztisch Platz nehmen. »Wie Sie sicherlich wissen, müssen wir wieder profitabel werden. Dazu sind unser Marktanteil und die durchschnittliche Auftragsgröße zu erhöhen. Unsere Retail-Konkurrenz macht sich schon lustig über uns. Und weil das die ganze Welt weiß, sind unsere Aktien nur noch die Hälfte von dem wert, was sie vor drei Jahren waren.«

Er fährt fort: »Das Phoenix-Projekt ist von essenzieller Bedeutung, um wieder mit der Konkurrenz gleichzuziehen und endlich das zu tun, was dort schon seit Jahren geschieht. Die Kunden müssen bei uns überall einkaufen können – sei es im Internet oder in unseren Läden. Ansonsten werden wir bald keine Kunden mehr haben.«

Ich nicke. Vielleicht mag unser IT-Umfeld nicht auf dem neuesten Stand sein, aber mein Team ist mit Phoenix seit Jahren beschäftigt. Jeder weiß, wie wichtig es ist.

»Wir hängen dem Zeitplan Jahre hinterher«, fährt er fort. »Unsere Investoren und die Börse sind wirklich nicht erfreut. Und jetzt verliert der Aufsichtsrat das Vertrauen in unsere Fähigkeit, Zusagen einzuhalten.

Ich will direkt sein. Wenn es so weitergeht, bin ich in sechs Monaten weg vom Fenster. Seit letzter Woche ist Bob Strauss, mein alter Chef, der neue Vorstandsvorsitzende. Es gibt eine lautstarke Gruppe von Investoren, die die Firma aufteilen wollen, und ich weiß nicht, wie lange wir sie noch hinhalten können. Auf dem Spiel steht hier nicht nur mein Job, sondern der von fast 4.000 Mitarbeitern bei Parts Unlimited.«

Plötzlich sieht Steve viel älter aus als die Anfang fünfzig, auf die ich ihn schätze. Er sieht mich direkt an und sagt: »Als kommissarischer CIO wird Chris Allers, unser VP of Application Development, direkt an mich berichten. Und Sie auch.«

Er steht auf und geht in seinem Büro hin und her. »Ich brauche Sie, damit all die Dinge, die laufen sollen – nun ja, eben laufen. Ich brauche jemanden, der zuverlässig ist und der keine Angst hat, mir schlechte Nachrichten zu erzählen. Und vor allem brauche ich jemanden, dem ich vertraue und von dem ich glaube, dass er das Richtige tut. Bei diesem Integrationsprojekt gab es viele Herausforderungen, aber Sie haben immer einen kühlen Kopf bewahrt. Sie haben den Ruf, zuverlässig und pragmatisch zu sein und zu sagen, was Sie denken.«

Er war ehrlich zu mir, daher werde ich es auch sein. »Sir, bei allem Respekt, aber es scheint für die IT-Führungsebene sehr schwierig zu sein, hier Erfolge vorweisen zu können. Anfragen nach Budget oder Mitarbeitern werden immer abgewiesen, und manche Manager werden so schnell ausgetauscht, dass sie nicht einmal die Möglichkeit hatten, ihren Schreibtisch komplett einzurichten.«

Mit aller Entschiedenheit sage ich: »Die Midrange Operations sind für den Erfolg von Phoenix ebenso wichtig. Ich muss dort bleiben und dafür sorgen, dass alles erledigt wird. Ich freue mich, dass Sie an mich gedacht haben, aber ich kann das Angebot nicht akzeptieren. Ich verspreche jedoch, meine Augen offen zu halten und mich nach einem geeigneten Kandidaten umzuschauen.«

Steve schaut mich abschätzend an, mit erstaunlich ernsthaftem Blick. »Wir mussten in der ganzen Firma Budgetkürzungen vornehmen. Diese Anordnung kam direkt aus dem Aufsichtsrat. Mir waren da die Hände gebunden. Ich möchte keine Versprechen machen, die ich nicht einhalten kann, aber ich kann versprechen, dass ich alles, was möglich ist, auch tun werde, um Sie und Ihren Auftrag zu unterstützen.

Bill, ich weiß, dass Sie nicht nach diesem Job gefragt haben, aber es geht hier um das Überleben der Firma. Ich brauche Sie, um dieses großartige Unternehmen am Leben zu erhalten. Kann ich auf Sie zählen?«

Oh, bitte.

Bevor ich erneut höflich ablehnen kann, höre ich mich plötzlich selbst sagen: »Jawohl, Sir, Sie können auf mich zählen.«

In Panik realisiere ich, dass Steve irgendeinen Jedi-Trick eingesetzt haben muss. Ich zwinge mich, mit dem Reden aufzuhören, bevor ich noch weitere dumme Zusagen mache.

»Herzlichen Glückwunsch«, sagt Steve, steht auf und schüttelt mir kräftig die Hand. Er schlägt mir auf die Schulter. »Ich wusste, dass Sie sich richtig entscheiden würden. Im Namen des gesamten Führungsteams bedanke ich mich dafür, dass Sie mitmachen.«

Ich starre seine Hand an und frage mich, ob ich mich da irgendwie wieder rauswinden kann.

Keine Chance.

Mich selbst innerlich verfluchend, sage ich: »Ich werde mein Bestes geben, Sir. Und könnten Sie trotzdem erklären, warum keiner auf dieser Position lange durchgehalten hat? Was ist Ihnen am wichtigsten? Und was wollen Sie gar nicht?«

Mit einem resignierten schiefen Lächeln füge ich hinzu: »Wenn es schiefgeht, werde ich wenigstens dafür sorgen, dass es auf eine neue und ungewöhnliche Weise passiert.«

»Das mag ich!«, sagt Steve und lacht laut auf. »Ich will, dass bei der IT alles läuft. Es ist wie mit der Toilette. Ich nutze sie und will mir keine Sorgen darum machen müssen, ob sie funktioniert. Ich will nicht, dass irgendetwas verstopft und die Toiletten die ganze Etage unter Wasser setzen.« Er lächelt breit über seinen eigenen Witz.

Toll. Seiner Meinung nach bin ich ein besserer Hausmeister.

Er fährt fort: »Sie haben den Ruf, dass Sie in der IT-Organisation das am besten geführte Schiff haben. Daher gebe ich Ihnen die Verantwortung für die gesamte Flotte. Ich erwarte, dass Sie auch die anderen Schiffe auf Vordermann bringen.

Chris muss sich weiter auf das Umsetzen von Phoenix konzentrieren. In Ihrem Bereich darf nichts davon ablenken. Das gilt nicht nur für Sie und Chris, sondern für jeden in der Firma. Ist das klar?«

»Absolut«, sage ich und nicke. »Sie wollen, dass die IT-Systeme zuverlässig verfügbar sind und dass die anderen Abteilungen darauf aufbauen können. Sie wollen, dass es so wenige Unterbrechungen gibt wie möglich, sodass Phoenix weiter vorangetrieben werden kann.«

Überrascht nickt Steve. »Genau. Genau das, was Sie sagen, ist auch mein Wunsch.«

Er übergibt mir eine ausgedruckte E-Mail von Dick Landry, dem CFO.

Von: Dick Landry

An: Steve Masters

Datum: 2. September, 08:27

Wichtigkeit: Hoch

Betreff: ACTION NEEDED: Gehaltsabrechnungslauf schlägt fehl

Hey, Steve. Wir haben echte Probleme mit dem Lauf der Gehaltsabrechnung, der diese Woche ansteht, und sind uns noch nicht sicher, ob es an den Zahlen liegt oder am System. Aber unabhängig von der Ursache sind die Zahlungen an die Mitarbeiter in Gefahr, wenn wir das Ganze nicht wieder zum Laufen bekommen. Das wäre wirklich schlecht.

Wir müssen das Problem beheben, bevor heute um 17 Uhr das Zeitfenster geschlossen ist. Bitte sage uns, wie wir das in der neuen IT-Organisation eskalieren können.

Dick

Ich zucke zusammen. Mitarbeiter, die kein Gehalt überwiesen bekommen, bedeuten Familien, die ihre Verpflichtungen nicht erfüllen können – Hauskredit, Miete, ja sogar das normale Einkaufen.

Mir wird klar, dass auch mein Hauskredit in vier Tagen abgebucht wird und wir eine dieser Familien sein könnten. Eine verspätet bezahlte Rate kann zu großen Problemen führen, und wir mussten sowieso schon lange daran arbeiten, den Studienkredit von Paige zurückzuzahlen.

»Sie wollen, dass ich mich darum kümmere und das Problem beseitige?«

Steve nickt und zeigt mit dem Daumen nach oben. »Halten Sie mich bitte auf dem Laufenden.« Dann wird er nochmals ernst. »Jede verantwortungsbewusste Firma kümmert sich um ihre Mitarbeiter. Viele unserer Arbeiter leben von Gehalt zu Gehalt. Sorgen Sie dafür, dass es für sie und ihre Familien nicht noch schwerer wird, okay? Das könnte sonst Ärger mit der Gewerkschaft bringen, vielleicht sogar einen Streik. Und das wäre keine gute Presse für uns.«

Ich nicke automatisch. »Kritische Geschäftsvorgänge wieder zum Laufen bringen und uns von den Titelseiten fernhalten. Verstanden. Vielen Dank.«

Warum ich mich genau bedanke, weiß ich auch nicht.

KAPITEL 2

Dienstag, 2. September

»Na, wie lief es?«, fragt Stacy freundlich und schaut von ihrer Tastatur auf.

Ich schüttle nur meinen Kopf. »Ich kann es nicht fassen. Er hat mich dazu überredet, einen neuen Job anzunehmen, den ich nicht haben wollte. Wie konnte das geschehen?«

»Er kann sehr überzeugend sein«, sagt sie. »Da ist er einmalig. Ich arbeite jetzt seit fast zehn Jahren für ihn und würde überall mit ihm hingehen. Gibt es irgendetwas, mit dem ich Ihnen Ihre Aufgabe erleichtern kann?«

Ich denke einen Moment nach, dann frage ich: »Es gibt da ein sehr dringendes Problem mit der Gehaltsabrechnung, das behoben werden muss. Dick Landry sitzt im dritten Stock, oder?«

»Bitte schön«, sagt sie, bevor ich meine Frage vollständig ausgesprochen habe, und drückt mir einen Notizzettel in die Hand, auf dem ich die Daten von Dick finde. Büro, Telefonnummern, alles.

Dankbar lächle ich sie an. »Vielen, vielen Dank – Sie sind fantastisch!«

Auf dem Weg zurück zum Aufzug wähle ich Dicks Handynummer. »Dick hier«, meldet er sich unwirsch, während er weiterhin am Rechner tippt.

»Hier ist Bill Palmer. Steve hat mich gerade zum neuen VP of IT Operations gemacht und mich gebeten ...«

»Herzlichen Glückwunsch«, unterbricht er mich. »Hören Sie, meine Leute haben ein Riesenproblem bei der Lohnabrechnung gefunden. Wann können Sie in meinem Büro sein?«

»Ich bin gleich da«, antworte ich. Er legt ohne weiteren Kommentar auf. Ich bin schon freundlicher begrüßt worden.

Im dritten Stock laufe ich durch Finance und Accounting, vorbei an Nadelstreifenanzügen und gestärkten Kragen, bis ich Dick an seinem Schreibtisch finde – schon wieder am Telefon. Als er mich sieht, hält er seine Hand über die Sprechmuschel. »Sie sind von IT?«, bellt er mich an.

Ich nicke, und er sagt ins Telefon: »Tut mir leid, aber ich muss los. Da ist endlich jemand, der mir helfen will. Ich rufe zurück.« Ohne auf eine Antwort zu warten, legt er auf.

Ich habe noch nie jemanden erlebt, der einfach so auflegt, und bereite mich innerlich auf ein kurzes und unfreundliches Gespräch vor – der Teil mit dem Kennenlernen wird wohl ziemlich knapp ausfallen.

Wie bei einer Geiselnahme hebe ich langsam meine Hände und zeige Dick die ausgedruckte E-Mail. »Steve hat mir gerade von dem Ausfall bei der Gehaltsabrechnung erzählt. Wie kann ich mir am besten einen Überblick über die Situation verschaffen?«

»Wir stecken tief in der Scheiße«, antwortet Dick. »Gestern fehlten beim Gehaltsabrechnungslauf alle Datensätze für die Mitarbeiter, die auf Stundenbasis bezahlt werden. Wir sind ziemlich sicher, dass das ein IT-Problem ist, und es hält uns davon ab, unsere Mitarbeiter zu bezahlen. Zudem verletzen wir damit unzählige arbeitsrechtliche Bestimmungen, und die Gewerkschaft wird uns zweifelsohne in der Luft zerreißen.«

Er murmelt noch einen Moment Unverständliches, dann sagt er: »Lassen Sie uns zu Ann gehen. Sie ist mein Operations Manager und rauft sich seit gestern Nachmittag die Haare.«

Ich muss mich ganz schön beeilen, um mit ihm Schritt zu halten, und laufe ihn fast über den Haufen, als er abrupt stehen bleibt und durch das Fenster eines Besprechungsraums schaut. Er öffnet die Tür. »Wie sieht’s aus, Ann?«

Im Raum befinden sich zwei gut gekleidete Frauen. Die eine – etwa 45 Jahre alt – steht vor dem Whiteboard, das mit Grafiken und Tabellen gespickt ist, während die andere – Anfang 30 – auf einem Laptop tippt. Überall auf dem Tisch des Besprechungszimmers liegen Tabellenausdrucke herum. Die Ältere gestikuliert mit einem geöffneten Textmarker und zeigt auf eine Liste mit potenziellen Fehlerquellen.

Etwas an der Art, wie sie sich kleiden, und ihr besorgter und gereizter Gesichtsausdruck sagen mir, dass die beiden von einer lokalen Wirtschaftsprüfungsfirma engagiert wurden. Ehemalige Buchprüferinnen. Vermutlich ist es gut, dass sie auf unserer Seite sind.

Ann schüttelt frustriert den Kopf. »Wir sind nicht wirklich weitergekommen. Es ist ziemlich sicher ein IT-Fehler eines der Zeiterfassungssysteme, die uns die Daten liefern. Alle Datensätze für die stundenbasierten Mitarbeiter wurden beim letzten Hochladen durcheinandergebracht ...«

Dick unterbricht sie. »Das hier ist Bill von der IT. Er soll dieses Problem lösen oder beim Versuch sterben – ich glaube, das hat er gesagt.«

Ich sage: »Hallo zusammen. Ich bin gerade erst neuer Chef von IT Operations geworden. Können Sie von vorne beginnen und mir erzählen, was Sie über das Problem wissen?«

Ann geht zum Flowchart, das an das Whiteboard gepinnt ist. »Beginnen wir mit dem Informationsfluss. Unser Finanzsystem erhält seine Payroll-Daten von den verschiedenen Bereichen auf unterschiedlichen Wegen. Wir sammeln alle Zahlen für die Mitarbeiter mit festen und stundenbasierten Gehältern und bereiten sie auf. Das klingt einfach, ist aber ausgesprochen komplex, weil jeder Bundesstaat andere Steuertabellen, Arbeitsschutzgesetze und so weiter hat.

Um sicherzustellen, dass nichts durcheinandergekommen ist«, fährt sie fort, »achten wir darauf, dass die aufsummierten Beträge zu den einzelnen Positionen aus den jeweiligen Bereichen passen.«

Ich mache mir schnell ein paar Notizen, und sie erzählt weiter. »Das ist ein ziemlich störrischer Prozess, der zum Teil per Hand geschieht. Meistens funktioniert alles, aber gestern haben wir bemerkt, dass der Register-Upload für die auf Stundenbasis bezahlten Mitarbeiter nicht durchgelaufen ist. Bei allen waren null Stunden und null Dollar eingetragen.

Wir hatten mit diesem Upload schon früher Probleme, daher haben wir von der IT ein Programm bekommen, mit dem wir manuelle Korrekturen vornehmen können und fehlerhafte Daten nicht ganz so schlimm sind.«

Ich zucke zusammen. Mitarbeiter aus der Personalabteilung, die Payroll-Daten außerhalb des entsprechenden Programms ändern. Gar nicht gut. Das ist fehleranfällig und gefährlich. Jemand könnte diese Daten auf einen USB-Stick kopieren oder per E-Mail weiterleiten, dabei sind das ausgesprochen kritische Daten.

»Sie sagen, die Zahlen für die Mitarbeiter mit festem Gehalt sind in Ordnung?«, frage ich.

»Stimmt«, antwortet sie.

»Aber die auf Stundenbasis bezahlten Mitarbeiter würden alle nichts bekommen«, hake ich nach.

»Jepp«, bestätigt sie erneut.

Interessant. Ich frage: »Warum ist der Gehaltsabrechnungslauf Ihrer Meinung nach fehlgeschlagen, wenn er doch sonst läuft? Hatten Sie schon früher Probleme?«

Sie zuckt mit den Schultern. »So etwas ist noch nie passiert. Ich habe keine Ahnung, was der Grund sein könnte. Es waren für diese Zahlungsperiode keine größeren Änderungen angekündigt. Ich habe mich das auch schon gefragt, aber sollten wir von den IT-Leuten nichts hören, stecken wir in der Klemme.«

»Wie sieht unser Notfallplan aus?«, frage ich. »Was passiert, wenn wir keine rechtzeitige Lösung finden?«

»Das steht doch in der E-Mail, die Sie da vor sich haben«, sagt Dick. »Deadline für elektronische Zahlungsanweisungen ist heute, 17 Uhr. Wenn wir das nicht schaffen, müssen wir eventuell einen großen Berg Papierschecks per FedEx an unsere Standorte schicken, damit sie dort an die Mitarbeiter verteilt werden!«

Ich runzle angesichts dieser Option die Stirn, und auch der Rest des Teams will daran gar nicht denken.

»Das würde nicht funktionieren«, sagt Ann und tippt sich mit dem Textmarker an ihre Zähne. »Wir haben unseren Payroll-Prozess ausgelagert. Jeden Monat laden wir die Daten zu der Firma hoch, die sie dann verarbeitet. Vielleicht könnten wir im schlimmsten Fall den letzten Payroll-Lauf herunterladen, in Excel anpassen und dann neu hochladen.

Weil wir jedoch nicht wissen, wie viele Stunden jeder Mitarbeiter gearbeitet hat, wissen wir auch nicht, wie viel wir ihnen zahlen müssen!«, fährt sie fort. »Wir wollen niemandem zu viel bezahlen, aber das wäre immer noch besser, als ungewollt jemandem zu wenig zukommen zu lassen.«

Es ist offensichtlich, dass Plan B eine Menge Probleme bereiten würde. Wir müssten die Gehaltsschecks der Leute mehr oder weniger schätzen – eventuell bekommt jemand Geld, der gar nicht mehr bei uns arbeitet, während Neueinsteiger leer ausgehen.

Um Finance die notwendigen Daten zur Verfügung zu stellen, könnten wir ein paar eigene Reports zusammenschrauben, dafür bräuchten wir jedoch die Anwendungsentwickler oder die Datenbankleute.

Aber damit würden wir nur Öl ins Feuer gießen. Entwickler sind noch schlimmer als die Netzwerk-Admins. Zeigen Sie mir einen Entwickler, der ein Produktivsystem nicht zum Absturz bringt. Und wenn Sie einen hätten, wäre der vermutlich in Urlaub.

Dick sagt: »Das sind beides hundsmiserable Alternativen. Wir könnten unseren Payroll-Lauf verschieben, bis wir die richtigen Daten hätten. Aber das ist nicht möglich – sind wir auch nur einen Tag zu spät, haben wir die Gewerkschaft am Hals. Es bleibt also nur Anns Vorschlag, unseren Mitarbeitern irgendetwas zu bezahlen, auch wenn es nicht der richtige Betrag ist. Nächsten Monat könnten wir dann Korrekturen vornehmen. Aber jetzt haben wir einen Fehler im Financial Reporting, den wir erst beheben müssen.«

Er reibt sich den Nasenrücken und überlegt weiter. »Wir werden einen ganzen Haufen seltsamer Journaleinträge in unserem Hauptbuch haben – gerade jetzt, wo unsere Auditoren für die SOX-404-Audits kommen. Wenn sie das sehen, werden sie gar nicht mehr gehen wollen.

So ein Mist. Ein Fehler im Financial Reporting?«, murmelt Dick vor sich hin. »Wir brauchen das Okay von Steve. Wenn die Auditoren hier ihre Zelte aufschlagen, werden sie bis zum Sankt-Nimmerleins-Tag bleiben, und keiner wird mehr seine eigentliche Arbeit erledigen können.«

SOX-404 ist die Abkürzung für den Sarbanes-Oxley-Act von 2002, den der US-Kongress als Reaktion auf die Bilanzskandale bei Enron, WorldCom und Tyco erließ. Dabei stehen CEO und CFO persönlich dafür ein, dass die Bilanzen ihrer Firmen korrekt sind.

Jeder denkt mit Wehmut an die Tage zurück, als er nicht die Hälfte seiner Zeit mit Auditoren reden und täglich neue regulatorische Anforderungen umsetzen musste. Ich schaue mir meine Notizen an und werfe dann einen Blick auf die Uhr. »Dick, ausgehend von dem, was wir jetzt haben, würde ich empfehlen, dass Sie weiterhin für den schlimmsten Fall planen und Plan B weiter ausarbeiten, damit wir ihn ohne größere Probleme umsetzen können. Zudem schlage ich vor, bis 15 Uhr zu warten, bevor wir eine Entscheidung treffen. Vielleicht schaffen wir es ja doch, die Systeme und Daten bis dahin zurückzubekommen.«

Als Ann nickt, sagt Dick: »Okay, Sie haben vier Stunden.«

Ich antworte: »Seien Sie versichert, dass wir die Dringlichkeit der Situation sehen und Sie über den aktuellen Stand unterrichtet werden, sobald ich etwas Neues weiß.«

»Danke, Bill«, sagt Ann. Dick bleibt still, als ich mich umdrehe und zur Tür hinausgehe.

Jetzt, da ich das Problem aus Businesssicht gesehen habe, fühle ich mich besser. Zeit, unter die Motorhaube zu schauen und herauszufinden, warum die komplexe Payroll-Maschine stehen geblieben ist.

Während ich die Treppen hinuntergehe, hole ich mein Telefon heraus und überfliege meine E-Mails. Meine Konzentration ist schon wieder dahin, als ich sehe, dass Steve meine Beförderung bis jetzt nicht bekannt gegeben hat. Wes Davis und Patty McKee, bisher meine Kollegen, wissen immer noch nicht, dass ich ihr neuer Chef bin.

Vielen Dank, Steve.

Als ich Gebäude 7 betrete, trifft mich die Erkenntnis wie ein Schlag. Unser Gebäude ist das Getto des gesamten Campus von Parts Unlimited.

Gebaut in den 1950ern und zuletzt in den 1970ern renoviert, wurde es offensichtlich nur nach funktionalen Gesichtspunkten entworfen, aber nicht nach ästhetischen. Hier wurden Bremsbeläge hergestellt, bis es zu einem Data Center wurde und man Büroräume einrichtete. Gebäude 7 ist einfach nur alt und heruntergerockt.

Der Empfangsmitarbeiter lächelt mich an. »Hallo, Mr. Palmer. Wie war der Tag bisher?«

Einen Moment reizt es mich, ihn zu bitten, mir Glück zu wünschen, damit er diese Woche korrekt bezahlt wird. Aber natürlich grüße ich einfach nur höflich zurück.

Ich lenke meine Füße zum Network Operations Center – oder wie wir es nennen: dem NOC, wo Wes und Patty sehr wahrscheinlich sein werden. Sie sind nun meine beiden wichtigsten Manager.

Wes ist Director of Distributed Technology Operations. Er hat die technische Verantwortung für über 1000 Windows-Server, aber auch über die Datenbank- und Netzwerkteams. Patty ist Director of IT Service Support. Sie leitet alle Level-1- und Level-2-Helpdesk-Mitarbeiter, die rund um die Uhr Fragen am Telefon beantworten, Störungen beheben und Anfragen aus dem Business weiterleiten. Zudem ist sie verantwortlich für einige der wichtigsten Prozesse und Tools, auf denen die gesamte IT Operations-Abteilung aufbaut, wie zum Beispiel das Fehlermeldungssystem, das Monitoring und die Change-Management-Meetings.

Ich gehe an vielen Cubicles vorbei – genauso wie in den anderen Gebäuden. Nur anders als in den Gebäuden 2 und 5 blättert hier die Farbe von den Wänden ab, und im Teppich zeigen sich dunkle Flecken.

Dieser Teil des Gebäudes war früher die Werkhalle. Als es umgebaut wurde, konnte nicht das gesamte Maschinenöl entfernt werden. Und egal wie viel Grundierung unter dem Teppich aufgetragen wurde – irgendwie schafft es das Öl immer wieder, sich in den Teppich zu mogeln.

Ich notiere mir, eine Budgetanforderung für neue Teppiche und das Streichen der Wände einzureichen. Bei den Marines war es nicht nur eine Frage der Ästhetik, die Kasernen ordentlich zu halten – es ging auch um Sicherheit.

Der Mensch ist ein Gewohnheitstier.

Ich höre das NOC, bevor ich es sehen kann. Es sieht aus wie ein großer Baseball-Bullpen-Bereich, mit langen Tischen an der einen Seite, auf denen der Status der verschiedenen IT-Dienste auf großen Monitoren angezeigt wird. Die Level-1- und Level-2-Helpdesk-Leute sitzen an drei Reihen mit Rechnern.

Das ist nicht ganz vergleichbar mit der Kontrollstation in Apollo 13, aber so erkläre ich es immer den Verwandten.

Wenn irgendwo etwas so richtig schiefgeht, braucht man die verschiedenen Beteiligten und Manager an einem Tisch, damit sie das weitere Vorgehen koordinieren können, bis das Problem gelöst ist. Wie jetzt. Am Konferenztisch sind 15 Leute in einer lauten und hitzigen Diskussion rund um eine spinnenartige Freisprecheinrichtung versammelt.

Wes und Patty sitzen nebeneinander am Konferenztisch, daher stelle ich mich hinter sie, um zuzuhören. Wes lehnt sich auf seinem Stuhl zurück und verschränkt die Arme vor der Brust – zumindest, soweit es eben geht. Mit seinen 1,90 Metern Körpergröße und über 125 Kilogramm Gewicht ist er eine recht beeindruckende Gestalt. Er scheint immer in Bewegung zu sein und hat den Ruf, zu sagen, was ihm gerade durch den Kopf geht.

Patty ist das genaue Gegenteil. Wo Wes laut und unverblümt ist und aus der Hüfte schießt, denkt Patty nach, analysiert und ist eine Verfechterin von Prozessen und Prozeduren. Wo Wes groß, streitlustig und manchmal sogar zänkisch ist, ist Patty elfenhaft, logisch und besonnen. Ihr eilt der Ruf voraus, Prozesse mehr zu lieben als Personen, und häufig ist sie diejenige, die versucht, Ordnung in das IT-Chaos zu bringen.

Sie ist das Gesicht der gesamten IT-Organisation. Geht etwas im IT-Umfeld schief, rufen die Leute Patty an. Sie ist die professionelle Apologetin, sei es bei abstürzenden Servern, zu langsam ladenden Webseiten oder – wie heute – bei fehlenden oder kaputten Daten.

Patty wird auch angerufen, wenn etwas im IT-Bereich zu erledigen ist – das Updaten eines Computers, das Ändern einer Telefonnummer oder das Ausliefern einer neuen Anwendung. Sie kümmert sich um die Planung, daher versuchen die Leute bei ihr immer, ihre eigenen Aufgaben als Erstes erledigt zu bekommen. Patty leitet dann die Aufgaben an diejenigen weiter, die die eigentliche Arbeit machen. Meist geschieht das entweder in meiner alten Gruppe oder in Wes’ Team.

Wes haut mit der Faust auf den Tisch. »Holt einfach den Hersteller ans Telefon und erzählt ihm, dass wir zur Konkurrenz gehen, wenn sie nicht schnellstens einen Techniker schicken. Wir sind einer ihrer größten Kunden! Eigentlich sollte der ganze Kram schon längst erledigt sein.«

Er schaut sich um und sagt: »Ihr kennt doch den Spruch, oder? Wie erkennt man, ob ein Verkäufer lügt? Seine Lippen bewegen sich.«

Einer der Entwickler am Tisch antwortet: »Wir haben sie gerade am Telefon. Sie sagen, es dauert mindestens vier Stunden, bis deren SAN-Techniker vor Ort sein kann.«

Ich runzle die Stirn. Warum reden sie über das SAN? Storage Area Networks bieten eine zentrale Speichermöglichkeit für viele unserer kritischen Systeme. Geht dort etwas schief, wirkt sich das meist global aus. Nicht nur ein Server würde nicht weitermachen können, sondern Hunderte.

Während Wes mit dem Entwickler diskutiert, versuche ich, nachzudenken. Nichts bei dem Problem mit der Gehaltsabrechnung hört sich wie ein SAN-Problem an. Ann war der Meinung, es wäre vermutlich irgendetwas mit den Zeiterfassungsanwendungen, die in den verschiedenen Werken im Einsatz sind.

»Aber nachdem wir versucht hatten, einen Rollback für das SAN durchzuführen, konnte man auf gar nichts mehr zugreifen«, sagt ein anderer Techniker. »Das Display zeigte plötzlich alles auf Japanisch an! Na ja, zumindest sah es wie Japanisch aus. Was auch immer es war, wir konnten uns keinen Reim auf die kleinen Bildchen machen. Da war uns klar, dass wir den Hersteller mit ins Boot holen müssen.«

Auch wenn ich erst später dazugekommen bin – meiner Überzeugung nach sind wir hier total auf dem Holzweg.

Ich beuge mich vor und flüstere Wes und Patty zu: »Können wir uns kurz alleine unterhalten?«

Wes dreht sich zu mir und sagt, ohne richtig auf mich zu achten: »Kann das nicht warten? Falls du es noch nicht mitbekommen haben solltest, wir haben echt ein großes Problem.«

Ich lege meine Hand fest auf seine Schulter. »Wes, das ist wirklich wichtig. Es geht um das Problem mit der Gehaltsabrechnung und betrifft eine Unterhaltung, die ich gerade mit Steve Masters und Dick Landry hatte.«

Er schaut überrascht auf. Patty ist schon aufgestanden. »Wir gehen in mein Büro«, sagt sie und führt uns dorthin.

Als ich Patty in ihr Büro folge, sehe ich dort an der Wand ein Foto ihrer Tochter, die wohl um die elf Jahre alt ist. Ich bin beeindruckt, wie sehr sie ihrer Mutter ähnelt – furchtlos, unglaublich klug und beeindruckend –, so sehr, dass es bei solch einem süßen kleinen Mädchen schon fast ein bisschen beängstigend wirkt.

Unwirsch fragt Wes: »Okay, Bill, was ist so wichtig, dass du deswegen einen aktuellen Sev-1-Ausfall unterbrichst?«

Das ist eine gute Frage. Severity-1-Ausfälle sind ernst zu nehmende Zwischenfälle, die den Geschäftsbetrieb beeinflussen und so kritisch sind, dass wir normalerweise alles stehen und liegen lassen, um sie zu beheben. Ich atme tief durch. »Ich weiß nicht, ob ihr es schon gehört habt, aber Luke und Damon arbeiten nicht mehr für die Firma. Offiziell haben sie sich dazu entschieden, eine Auszeit zu nehmen. Mehr weiß ich leider auch nicht.«

Die Überraschung in ihren Gesichtern bestätigt meinen Verdacht. Sie wussten es nicht. Ich fasse die morgendlichen Ereignisse kurz zusammen. Patty schüttelt den Kopf und gibt ein missbilligendes »ts, ts« von sich.

Wes ist verärgert. Er hat viele Jahre mit Damon zusammengearbeitet. Mit rotem Gesicht sagt er: »Jetzt hast du also das Sagen? Ich will dich nicht beleidigen, aber ist das nicht eine Nummer zu groß für dich? Du hast die Midrange-Systeme betreut, die schon seit Jahren mehr oder weniger veraltet sind. Du hast dir eine angenehme kleine Aufgabe eingerichtet. Und weißt du was? Du hast keine Ahnung, wie man mit modernen, verteilten Systemen arbeitet – für dich sind die 90er doch immer noch Zukunftsmusik!«

»Ganz ehrlich«, fährt er fort, »ich glaube, dir würde der Kopf explodieren, wenn du mit der unbarmherzigen Geschwindigkeit und Komplexität zurechtkommen müsstest, mit der ich tagtäglich zu tun habe.«

Ich zähle ruhig bis drei. »Möchtest du Steve vorschlagen, meinen Job zu übernehmen? Gerne. Dann sorge aber dafür, dass die Geschäftsbereiche das bekommen, was sie brauchen, und dass jeder pünktlich bezahlt wird.«

Patty antwortet schnell: »Ich weiß, du hast mich nicht gefragt, aber ich denke auch, dass wir uns vor allem um das Problem mit der Gehaltsabrechnung kümmern müssen.« Sie macht eine kurze Pause, dann sagt sie: »Meiner Meinung nach hat Steve eine gute Wahl getroffen. Meinen Glückwunsch, Bill. Wann können wir uns über ein größeres Budget unterhalten?«

Ich lächle ihr kurz dankbar zu, dann schaue ich wieder zu Wes.

Er scheint noch mit sich zu hadern, und ich kann seinen Gesichtsausdruck nicht wirklich entziffern. Aber schließlich gibt er nach. »Okay, in Ordnung. Aber auf das mit dem Gespräch mit Steve werde ich noch zurückkommen. Er wird mir einiges zu erklären haben.«

Ich nicke. Angesichts meiner Erfahrung mit Steve wünsche ich Wes ernsthaft Glück, wenn er ihn wirklich zur Rede stellen will.

»Danke für eure Unterstützung. Die ist mir sehr wichtig. Also, was wissen wir über den – oder die – Fehler? Was ist mit diesem SAN-Upgrade von gestern? Gibt es da einen Zusammenhang?«

»Das wissen wir nicht.« Wes schüttelt den Kopf. Wir haben gerade versucht, das herauszufinden, als du kamst. Gestern waren wir dabei, eine neue SAN-Firmware einzuspielen, als der Payroll-Lauf fehlschlug. Brent dachte, dass das SAN die Daten zerschießt, daher hat er vorgeschlagen, die Änderungen wieder zurückzunehmen. Das klang sinnvoll, aber wie du weißt, gibt es nun ein kleines Problem.«

»Ein kleines Problem« – das ist wohl die Untertreibung des Jahrhunderts. Hier geht es ja nicht darum, dass ein Smartphone nach einem Update nicht mehr läuft.

Brent arbeitet für Wes. Er ist bei den wichtigen IT-Projekten immer voll dabei, und ich habe schon häufig mit ihm zusammengearbeitet. Er ist echt pfiffig, aber er kann auch einschüchternd wirken, weil er so viel weiß. Und das Schlimme ist: Meist hat er recht.

»Du hast es ja gehört«, sagt Wes und weist auf den Konferenztisch, an dem die Diskussion unvermindert weitergeht. »Das SAN startet nicht, rückt keine Daten raus, und wir können nicht einmal die Fehlermeldungen entziffern, weil sie in irgendeiner seltsamen Sprache ausgegeben werden. Jetzt sind eine ganze Reihe von Datenbanken unten, natürlich einschließlich der Payroll.«

»Um an dem SAN-Problem zu arbeiten, mussten wir Brent von einer Phoenix-Aufgabe abziehen, deren Erledigung wir Sarah versprochen hatten«, sagt Patty unheilvoll. »Das wird uns noch teuer zu stehen kommen.«

»Oh, oh. Was genau haben wir ihr versprochen?«, frage ich alarmiert.

Sarah ist Senior Vice President of Retail Operations, und sie arbeitet ebenfalls für Steve. Sie hat die unheimliche Begabung, immer anderen Leuten die Schuld in die Schuhe zu schieben, wenn bei ihr etwas schiefgeht – insbesondere den IT-Leuten. Schon seit Jahren drückt sie sich vor jeder Form von echter Verantwortung.

Auch wenn ich Gerüchte hörte, dass Steve sie als seine Nachfolgerin aufbauen will, habe ich sie immer als völlig ausgeschlossen abgetan. Ich bin sicher, dass Steve sie durchaus durchschaut.

»Sarah hat von irgendwem gehört, dass wir Chris einen Haufen virtueller Maschinen zu spät liefern würden«, antwortet sie. »Wir haben alles stehen und liegen gelassen, um das fertigzubekommen – bis wir uns um das SAN kümmern mussten.«

Chris Allers, VP of Application Development, ist für die Anwendungen und den Code verantwortlich, den die Geschäftsbereiche brauchen. Wir kümmern uns dabei um Betrieb und Wartung. Bei Chris dreht sich im Moment alles um Phoenix.

Ich kratze mich am Kopf. Unsere Firma hat viel in Virtualisierung investiert. Auch wenn das Ganze verdächtig nach den Mainframe-Umgebungen der 1960er aussieht, hat die Virtualisierung in Wes Welt viel geändert. Man musste plötzlich nicht mehr Tausende realer Server verwalten. Nun sind es logische Instanzen innerhalb eines fetten Servers oder sogar irgendwo in der Cloud.

Das Erstellen eines neuen Servers beschränkt sich auf einen Rechtsklick in einer Anwendung. Verkabelung? Nur eine Anpassung der Konfiguration. Aber trotz der Versprechen, dass die Virtualisierung all unsere Probleme lösen würde, schaffen wir es gerade nicht, eine virtuelle Maschine pünktlich an Chris zu liefern.

»Wenn Brent am SAN-Problem arbeiten muss, dann lassen wir ihn da. Ich kümmere mich um Sarah«, sage ich. »Aber wenn das Payroll-Problem durch das SAN verursacht wurde – warum sehen wir dann nicht mehr Fehler und Ausfälle?«

»Sarah wird definitiv nicht erfreut sein. Weißt du, plötzlich möchte ich deinen Job doch nicht haben wollen«, sagt Wes und lacht laut. »Lass dich bloß nicht gleich am ersten Tag feuern. Denn dann werden sie mich fragen!«

Er denkt einen Moment nach. »Aber mit dem SAN – da hast du recht. Brent arbeitet gerade daran. Lass uns bei ihm vorbeischauen und ihn fragen, was er davon hält.«

Patty und ich nicken. Das ist eine gute Idee. Wir müssen genau herausfinden, was wann passiert ist. Und bisher basiert alles nur auf Hörensagen.

Das reicht aber nicht, um Kriminalfälle zu lösen, und erst recht nicht, um IT-Probleme zu heben.

KAPITEL 3

Dienstag, 2. September

Ich folge Patty und Wes am NOC vorbei zu den Cubicles. Wir landen in einem größeren Bereich, der den Platz von sechs Cubicles einnimmt. An einer Seite steht ein langer Tisch mit einer Tastatur und vier LCD-Monitoren – wie bei einem Wall-Street-Händler. Überall stehen Server herum, an denen kleine Lämpchen blinken. Jeder Bereich des Tischs ist mit weiteren Monitoren vollgestellt, auf denen Diagramme, Anmeldefenster, Codeeditoren, Word-Dokumente und unzählige Anwendungen zu sehen sind, die ich nicht kenne.

Brent tippt etwas in einem Fenster ein und hat dabei alles um sich herum ausgeblendet. Am Telefon ist die Telefonkonferenz zu hören, die auch im NOC läuft. Es scheint ihm offensichtlich egal zu sein, ob das laut gestellte Telefon seine Kollegen stört.

»Hey Brent, hast du eine Minute?«, fragt Wes laut und legt eine Hand auf seine Schulter.

»Kann das warten?«, antwortet Brent, ohne aufzuschauen. »Ich bin gerade ziemlich beschäftigt. Weißt du, ich arbeite an dem SAN-Problem.«

Wes stellt das Telefon leise und schnappt sich einen Stuhl. »Ja, genau darum sind wir ja hier.«

Als sich Brent herumdreht, fährt Wes fort. »Erzähl mir noch mal von letzter Nacht. Warum bist du davon ausgegangen, dass das SAN-Upgrade daran schuld ist, dass der Payroll-Lauf fehlgeschlagen ist?«

Brent verdreht die Augen. »Ich habe einem der SAN-Techniker mit dem Firmware-Upgrade geholfen, nachdem alle anderen nach Hause gegangen waren. Das hat viel länger gedauert als erwartet, und nichts lief so, wie in der Tech Note angegeben. Es war ziemlich knifflig, aber gegen 19 Uhr waren wir endlich fertig.

Dann starteten wir das SAN neu, aber alle Selbsttests schlugen fehl. Wir haben daran etwa 15 Minuten gearbeitet, um herauszufinden, was schiefging. Dann kam die E-Mail mit dem Fehler beim Payroll-Lauf. Da zog ich die Reißleine.

Wir waren einfach zu viele Versionen hintendran. Der SAN-Hersteller hat vermutlich nie den Upgrade-Pfad getestet, dem wir gefolgt sind. Ich habe dich angerufen, weil ich das Ganze abbrechen wollte. Mit deiner Zustimmung haben wir dann mit dem Rollback begonnen.

Und da ist das SAN abgestürzt.« Brent lässt sich in seinen Stuhl zurückfallen. »Davon ist nicht nur die Payroll betroffen, sondern noch ein ganzer Haufen anderer Server.«

»Wir wollten die SAN-Firmware schon seit Jahren aktualisieren, haben das aber irgendwie nie geschafft«, erklärt Wes. »Einmal waren wir kurz davor, aber da gab es kein ausreichend großes Wartungsfenster. Die Performance ist immer schlechter geworden, bis zu viele kritische Anwendungen betroffen waren. Daher haben wir uns schließlich gestern dazu entschieden, in den sauren Apfel zu beißen und das Upgrade durchzuführen.«

Ich nicke. Da klingelt mein Telefon.

Es ist Ann, daher mache ich den Lautsprecher an.

»Wie von Ihnen vorgeschlagen, haben wir uns die Daten aus der Payroll-Datenbank angeschaut. Der letzte Monat war in Ordnung, aber dieses Mal sind alle Sozialversicherungsnummern für die stundenbasierten Mitarbeiter völliger Müll. Und alle Felder für Arbeitsstunden und Stundensätze stehen auf null. Das hat hier noch keiner so erlebt.«

»Nur eine Spalte enthält Müll?«, frage ich und hebe überrascht meine Augenbrauen. »Was meinen Sie mit ›Müll‹? Was steht in den Feldern?«

Sie versucht zu beschreiben, was sie auf ihrem Bildschirm sieht. »Na ja, da stehen keine Ziffern oder Buchstaben. Ich sehe Herzchen, Piks und seltsame Zeichen ... Und es gibt einen Haufen Zeichen mit Akzenten und Umlauten ... Und es gibt keine Leerzeichen. Ist das wichtig?«

Als Brent kichert, weil Ann versucht, den Unfug in den Feldern laut vorzulesen, erhält er von mir einen bösen Blick. »Ich denke, wir haben verstanden«, sage ich. »Das ist ein wichtiger Hinweis. Können Sie mir das Arbeitsblatt mit den kaputten Daten zumailen?«

Sie sagt es zu. »Ach übrigens, kann es sein, dass jetzt eine ganze Reihe von Datenbanken unten ist? Gestern Abend waren sie noch da.«

Wes murmelt etwas und sorgt dafür, dass Brent still bleibt.

»Ähm, ja. Wir sind uns dessen bewusst und arbeiten auch daran«, antworte ich, ohne mit der Wimper zu zucken.

Als sie auflegt, atme ich erst einmal tief aus und nehme mir einen Moment, um welcher Gottheit auch immer zu danken, die Menschen schützt, die Feuer löschen oder Computerpannen beheben.

»Nur ein kaputtes Feld in der Datenbank? Kommt, Leute, das klingt wirklich nicht wie ein SAN-Fehler«, sage ich. »Brent, was lief gestern abgesehen vom SAN-Upgrade noch, das den Payroll-Lauf hätte stören können?«

Brent dreht sich mit seinem Bürostuhl um die eigene Achse, während er nachdenkt. »Hmm, jetzt, wo du es sagst ... Ein Entwickler von der Zeiterfassungsanwendung hat mich gestern angerufen und mir eine seltsame Frage zur Struktur der Datenbanktabelle gestellt. Ich steckte mitten in der Phoenix-Test-VM, daher habe ich ihm nur kurz geantwortet. Du glaubst doch nicht, dass er irgendetwas gemacht hat, wodurch das Programm jetzt nicht mehr läuft, oder?«

Wes dreht sich schnell zu dem Telefon, über das die ganze Zeit die NOC-Telefonkonferenz lief, und schaltet das Mikro wieder ein. »Hey Leute, Wes hier. Ich sitze mit Brent und Patty zusammen, und unser neuer Chef, Bill Palmer, ist da. Steve Masters hat ihn zum Chef von IT Ops gemacht. Hört also alle mal zu.«

Meine Hoffnung auf eine ordentliche Bekanntgabe meiner neuen Aufgabe schwindet zusehends.

Wes fährt fort: »Weiß irgendjemand von einem Entwickler, der an der Zeiterfassungssoftware gedreht hat, die in den Fabriken genutzt wird? Brent sagt, jemand hat ihn angerufen, der an einer Datenbanktabelle arbeiten wollte.«

Aus dem Lautsprecher erklingt eine Stimme. »Ja, ich habe jemandem geholfen, der Verbindungsprobleme zu einer Fabrik hatte. Ich bin ziemlich sicher, dass er ein Entwickler für die Zeiterfassungs-App war. Er installierte irgendeine Security-Anwendung, die John noch diese Woche aktiviert haben wollte. Ich glaube, er hieß Max. Irgendwo hier müssen noch seine Kontaktdaten sein ... Er sagte, er würde heute in Urlaub gehen, daher war das Ganze so eilig.«

Jetzt kommen wir der Sache näher.

Ein Entwickler, der schnell noch eine unaufschiebbare Änderung ins System schiebt, um in Urlaub gehen zu können – eventuell als Teil eines dringenden Projekts unseres Chief Information Security Officers John Pesche.

Solche Situationen bestätigen immer wieder meinen Argwohn gegenüber Entwicklern: Sie machen sich häufig keine Gedanken darüber, dass sie etwas kaputt machen könnten, bevor sie verschwinden. Und IT Operations muss dann wieder hinterherräumen.

Gefährlicher als ein Entwickler ist nur ein Entwickler, der mit der Security zusammenarbeitet. Zusammen haben sie die Mittel, das Motiv und die Gelegenheit.

Ich vermute, unser CISO hat einen Entwicklungsmanager dazu gedrängt, etwas zu tun. Das hat dazu geführt, dass ein Entwickler irgendetwas anderes tat, und dadurch blieb dann der Payroll-Lauf hängen.

Die Information Security bedrängt immer wieder die Leute mit eiligen Anforderungen und interessiert sich dann nicht für die Folgen für den Rest der Firma. Darum laden wir sie nicht so häufig zu Meetings ein. Wenn man etwas erledigt haben will, ist es am besten, wenn sie nicht dabei sind.

Sie kommen immer mit Millionen von Gründen, warum etwas, das wir machen wollen, eine Sicherheitslücke erzeugt, durch die Alien-Hacker in unsere schöne Firma eindringen und unseren Code, das geistige Eigentum, die Kreditkartennummern und die Fotos unserer Familien stehlen können. Das sind zwar alles potenziell mögliche Risiken, aber ich sehe oft keine Verbindung zwischen ihren schrillen, hysterischen und selbstgerechten Anforderungen und dem tatsächlichen Verbessern der Abwehr unserer Umgebung.

»Okay, Leute«, sage ich entschieden. »Der Fehler bei der Gehaltsabrechnung ist wie ein Tatort, und wir sind Scotland Yard. Das SAN ist kein Verdächtiger mehr, aber leider haben wir es während der Untersuchung verstümmelt. Brent, du arbeitest weiter am verletzten SAN – das müssen wir ganz offensichtlich wieder ans Laufen bringen.

Wes und Patty, unsere neuen Verdächtigen sind Max und sein Manager«, sage ich. »Tut alles, was nötig ist, um sie zu finden, festzusetzen und herauszufinden, was passiert ist. Mir ist egal, ob Max Urlaub hat. Er hat vermutlich irgendetwas durcheinandergebracht, und wir müssen das bis 15 Uhr wieder geradeziehen.«

Ich denke einen Moment nach. »Ich werde mich auf die Suche nach John machen. Möchte mir jemand dabei helfen?«

Wes und Patty diskutieren darüber, wer John mit verhören möchte. Patty sagt unnachgiebig: »Ich sollte dabei sein. Seit Jahren versuche ich, Johns Leute in der Spur zu halten. Sie folgen nie unseren Prozessen und sorgen immer wieder für Probleme. Ich würde zu gern sehen, wie Steve und Dick ihn für diesen Stunt auseinandernehmen.«

Das ist anscheinend ein überzeugendes Argument, daher sagt Wes: »Okay, er gehört dir. Er tut mir jetzt schon ein wenig leid.«

Ich bereue meine Wortwahl. Das ist hier keine Hexenjagd, und ich will keine Vergeltung. Wir müssen immer noch wissen, welche Aktivitäten zu diesem Fehler geführt haben.

Aufgrund falscher Schlussfolgerungen kam es gestern Abend zu dem SAN-Fehler. Das würde nicht wieder passieren. Nicht unter meiner Leitung.

Als Patty und ich John anrufen, muss ich meine Augen zusammenkneifen, um dessen Telefonnummer auf Pattys Bildschirm zu erkennen. Vielleicht sollte ich doch mal auf meine Frau hören und mir eine Brille anschaffen. Die Vierzig sind schließlich nicht mehr fern.

Ich wähle die Nummer, und nach einem Klingeln wird abgenommen. »John hier.«

Ich erzähle ihm kurz von den Problemen mit dem Payroll-Lauf und dem SAN und frage dann: »Haben Sie gestern irgendwelche Änderungen an der Zeiterfassungsanwendung vorgenommen?«

Er sagt: »Das klingt nicht gut, aber ich kann versichern, dass wir nichts an Ihren Midrange-Systemen getan haben. Tut mir leid, da kann ich nicht helfen.«

Ich seufze. Eigentlich hätte doch mittlerweile Steve oder Laura eine Info zu meiner Beförderung herumschicken können. Anscheinend muss ich meine neue Rolle heute jedem erklären.

Vielleicht wäre es einfacher, die Ankündigung selbst zu verschicken.

Also wiederhole ich in Kurzform meine hastige Beförderung. »Wes, Patty und ich haben gehört, dass Sie gestern mit Max irgendetwas Wichtiges ausgeliefert haben. Worum ging es da?«

»Luke und Damon sind weg?« John klingt überrascht. »Ich hätte nie gedacht, dass Steve tatsächlich beide wegen der Resultate eines Compliance-Audits feuern würde. Aber wer weiß? Vielleicht ändert sich jetzt hier mal etwas. Lassen Sie sich das eine Lehre sein, Bill. Die Operations-Leute können Security-Fragen nicht immer mit Füßen treten. Nur ein freundlicher Rat ...

Da wir gerade dabei sind – ich frage mich sowieso, wie uns die Konkurrenz immer wieder zuvorkommen kann«, fährt er fort. »Wie sagt man so schön: Einmal ist Zufall, zweimal ist Glück, dreimal muss der Feind seine Finger im Spiel gehabt haben. Vielleicht sind die E-Mail-Systeme des Vertriebs gehackt worden. Das würde erklären, warum uns so viele Abschlüsse durch die Lappen gehen.«

John redet weiter, aber ich denke immer noch über seine Vermutung nach, dass Luke und Damon vielleicht wegen einer Security-Sache gefeuert wurden. Das ist möglich – John kennt eine ganze Menge wichtiger Menschen, zum Beispiel Steve und den Aufsichtsrat, aber auch interne und externe Auditoren.

Wie auch immer, ich bin sicher, dass Steve als Grund für die Kündigung von Luke und Damon weder John noch die Information Security genannt hat – nur die Notwendigkeit, sich auf Phoenix zu konzentrieren.

Ich schaue Patty fragend an. Sie verdreht die Augen und tippt sich an die Stirn – sie ist eindeutig der Meinung, dass John spinnt.

»Hat Steve Ihnen irgendwelche Einblicke in die neue Organisationsstruktur gegeben?«, frage ich aus reiner Neugier. John beschwert sich immer darüber, dass die Information Security zu wenig Priorität besitzt. Er versucht ständig, mit dem CIO gleichgestellt zu werden, weil dadurch ein inhärenter Interessenkonflikt gelöst würde. Meines Wissens hatte er damit bisher keinen Erfolg.

Es ist kein Geheimnis, dass Luke und Damon John so weit wie möglich außen vor ließen, damit er keinen Einfluss auf die Leute bekam, die die eigentliche Arbeit erledigten. Aber trotz ihrer Bemühungen schaffte John es immer wieder, bei Besprechungen dabei zu sein.

»Was? Ich habe keine Ahnung, was passiert«, sagt er gekränkt. Offensichtlich habe ich da einen Nerv getroffen. »Ich werde wieder im Dunkeln gelassen, wie immer. Vermutlich bin ich der Letzte, der es erfährt. Bis Sie mir davon erzählt haben, dachte ich, ich würde weiterhin an Luke berichten. Und jetzt weiß ich gar nicht, wer mein Chef ist. Haben Sie das von Steve erfahren?«

»Das ist nicht meine Gehaltsklasse – ich weiß so wenig wie Sie«, antworte ich und spiele den Dummen. Schnell wechsle ich das Thema und frage: »Was können Sie uns über die Änderungen an der Zeiterfassungs-App sagen?«

»Ich werde Steve anrufen und herausfinden, was da vor sich geht. Vermutlich hat er vergessen, dass Information Security überhaupt existiert«, fährt er fort und ich frage mich, ob wir überhaupt noch über die Payroll sprechen können.

Zu meiner Erleichterung sagt er: »Ach ja, Sie haben nach Max gefragt. Wir hatten ein dringendes Audit-Problem beim Speichern von PII – also Personally Identifiable Information –, etwa bei den SSNs, also den Sozialversicherungsnummern, aber auch bei den Geburtstagen und so weiter. Das EU-Recht und mittlerweile viele US-Staaten verbieten das Speichern solcher Daten. Das war ein großes Thema beim letzten Audit. Ich wusste, dass mein Team die Firma mal wieder vor sich selbst würde schützen müssen, bevor wir erneut eins auf die Mütze bekommen. Das wäre ein gefundenes Fressen für die Medien, oder?«

Er fährt fort: »Wir haben ein Produkt gefunden, das diese Information verschlüsselt, sodass wir die SSNs nicht länger speichern müssen. Das sollte schon vor über einem Jahr installiert werden, aber trotz meines Drängens ist das nie geschehen. Jetzt ist uns die Zeit davongelaufen. Die Auditoren der Payment Card Industry – also PCI – kommen Ende des Monats, und ich habe Druck gemacht, damit das Zeiterfassungsteam endlich etwas tut.«

Sprachlos starre ich das Telefon an.

Einerseits bin ich verzückt, dass wir John sozusagen noch mit rauchender Pistole in der Hand erwischt haben. Johns Beschreibung vom SSN-Feld passt genau zu Anns Beschreibung der kaputten Daten.

Andererseits: »Mal sehen, ob ich das richtig verstanden habe ...«, sage ich langsam. »Sie haben diese Verschlüsselungsanwendung installiert, um ein Audit-Problem zu beheben. Dadurch konnte die Gehaltsabrechnung nicht durchlaufen, und Dick und Steve gehen jetzt die Wände hoch?«

John reagiert gereizt. »Erstens bin ich ziemlich sicher, dass das Verschlüsselungsprodukt nicht die Ursache für das Problem ist. Das ist undenkbar. Der Hersteller hat uns versichert, dass es keine Probleme machen wird, und wir haben all ihre Referenzen geprüft. Zweitens haben Dick und Steve jeden Grund, die Wände hochzugehen: Compliance ist nicht optional. Es ist Pflicht. Meine Aufgabe ist es, sie aus den orangefarbenen Overalls herauszuhalten, darum habe ich getan, was ich tun musste.«

»Orangefarbene Overalls?«

»Na ja, halt das, was man im Gefängnis trägt. Mein Job ist es, dafür zu sorgen, dass das Management alle relevanten Gesetze, Vorschriften und Verträge einhält. Luke und Damon waren viel zu sorglos. Sie haben zu viel davon ignoriert, sodass unser Audit- und unser Security-Stand ernsthaft bedroht waren. Wenn ich nicht wäre, würden wir vermutlich mittlerweile alle im Gefängnis sitzen.«

Ich dachte, wir würden hier über ein Problem mit der Gehaltsabrechnung reden, nicht über Gefängnisaufenthalte.

»John, wir haben Prozesse und Prozeduren, wie man Änderungen auf Produktivsystemen einführt«, meldet sich Patty zu Wort. »Sie haben sie umgangen und für ein weiteres großes Problem gesorgt, das wir nun beheben müssen. Warum haben Sie sich nicht an den Prozess gehalten?«

»Ha! Ein guter Witz, Patty«, schnaubt John. »Ich habe mich an den Prozess gehalten. Wissen Sie, was Ihre Leute mir gesagt haben? Die nächste Möglichkeit für ein Deployment wäre in vier Monaten. Hallo? Die Auditoren kommen nächste Woche!« Unnachgiebig fährt er fort: »Sich an Ihren bürokratischen Prozess zu halten, war einfach nicht möglich. Wenn Sie an meiner Stelle gewesen wären, hätten Sie dasselbe getan.«

Patty wird rot. Ich sage ruhig: »Laut Dick haben wir weniger als fünf Stunden, um die Zeiterfassungsanwendung wieder zum Laufen zu bringen. Nachdem wir wissen, dass es eine Änderung bezüglich der SSNs gab, haben wir, glaube ich, alles, was wir brauchen.«

Ich fahre fort: »Max, der bei der Änderung geholfen hat, ist heute in Urlaub. Wes oder Brent werden Sie kontaktieren, um mehr über das Verschlüsselungsprodukt zu erfahren, das Sie eingesetzt haben. Ich gehe davon aus, dass Sie ihnen alles erzählen, was sie wissen müssen. Das ist sehr wichtig.«

John stimmt zu, und ich danke ihm, dass er Zeit für uns übrig hatte. »Moment, eine Frage noch. Warum glauben Sie, dass das Produkt nicht für den Fehler verantwortlich ist? Haben Sie die Änderung getestet?«

Es ist kurz still in der Leitung, bevor John antwortet. »Nein, wir konnten die Änderung nicht testen. Es gibt keine Testumgebung. Anscheinend hat Ihr Team vor Jahren Budget angefordert, aber ...«

Ich hätte es wissen müssen.

»Nun, das sind doch gute Neuigkeiten«, sagt Patty, nachdem John aufgelegt hat. »Das lässt sich vielleicht nicht einfach beheben, aber immerhin wissen wir jetzt, was passiert ist.«

»War Johns Verschlüsselungsänderung im Change-Plan enthalten?«, frage ich.

Sie lacht humorlos. »Das habe ich doch versucht, dir zu erklären. John folgt nur sehr selten unserem Change-Prozess. Das machen die wenigsten. Es geht hier zu wie im Wilden Westen. Wir schießen meist aus der Hüfte.«

Verteidigend fährt sie fort: »Wir brauchen mehr Prozesse und mehr Unterstützung von ganz oben, dazu Tools und Training rund um die Prozesse. Jeder hier denkt, dass man seine Dinge nur dadurch erledigen kann, dass man sie einfach macht. So ist mein Job fast unmöglich.«

In meiner alten Gruppe sind wir bei Änderungen immer sehr diszipliniert vorgegangen. Keiner hat etwas geändert, ohne es nicht vorher allen zu sagen, und wir haben uns ein Bein ausgerissen, um dafür zu sorgen, dass unsere Änderungen nichts kaputt machten.

Ich bin es nicht gewohnt, so blind zu fliegen.

»Wir haben keine Zeit, jedes Mal solche Nachforschungen anzustellen, wenn etwas schiefgeht«, sage ich genervt. »Besorge mir bitte eine Liste mit den gemachten Änderungen – sagen wir, der letzten drei Tage. Ohne einen genauen Zeitablauf werden wir Ursache und Wirkung nicht zusammenbekommen und vermutlich gleich wieder solch einen Ausfall verursachen.«

»Gute Idee.« Sie nickt. »Falls nötig, werde ich jeden in der IT anmailen, um herauszufinden, was sie tun. So bekomme ich auch die Dinge mit, die nicht auf unserem Plan zu finden sind.«

»Was meinst du mit ›jeden anmailen‹? Gibt es kein System, in das die Leute ihre Änderungen eintragen? Was ist mit unserem Ticket-System oder dem Change-Authoriziation-System?«, frage ich erstaunt. Das ist ja so, als würde Scotland Yard jeden in London anmailen, um herauszufinden, wer in der Nähe eines Tatorts war.

»Träum weiter«, sagt Patty und schaut mich an, als hätte ich keine Ahnung – was offensichtlich der Fall ist. »Seit Jahren versuche ich, die Leute dazu zu bewegen, unseren Change-Management-Prozess und die Tools zu nutzen. Aber wie John verwendet es keiner. Genauso mit unserem Ticket-System. Alle sind total sorglos.«

Die Dinge sind ja viel schlimmer, als ich gedacht hatte.

»Okay, tu, was zu tun ist«, sage ich schließlich und kann meinen Frust kaum verbergen. »Achte darauf, dass du alle Entwickler der Zeiterfassung erwischst, aber auch die Systemadministratoren und die Netzwerkleute. Rufe ihre Vorgesetzten an und erzähle ihnen, wie wichtig es ist, über alle Änderungen Bescheid zu wissen, egal wie unwichtig sie zu sein scheinen. Vergiss nicht Johns Leute.«

Als Patty nickt, sage ich: »Sieh mal, du bist der Change-Manager. Wir müssen hier besser werden. Wir müssen wissen, was vor sich geht, und dafür brauchen wir irgendeinen funktionierenden Change-Management-Prozess. Sorge dafür, dass jeder seine Änderungen dort durchlaufen lässt, sodass wir ein besseres Verständnis dafür haben, was hier passiert.«

Zu meiner Überraschung sieht Patty niedergeschlagen aus. »Bill, das habe ich schon versucht. Ich werde dir sagen, was passieren wird. Das Change Advisory Board – das CAB also – wird ein oder zwei Mal zusammenkommen. Und in ein paar Wochen werden die Leute nicht mehr teilnehmen, weil sie ›zu beschäftigt sind‹. Oder sie ziehen ihre Änderungen einfach durch, ohne auf die Genehmigung zu warten, weil ihnen eine Deadline im Nacken sitzt. Wie auch immer, es wird innerhalb eines Monats im Sande verlaufen.«

»Nicht dieses Mal«, sage ich unnachgiebig. »Verschicke eine Meeting-Aktualisierung an alle Technologiemanager, in der steht, dass die Teilnahme verpflichtend ist. Und wenn sie nicht können, müssen sie eine Vertretung schicken. Wann ist das nächste Treffen?«

»Morgen.«

»Ausgezeichnet«, sage ich ehrlich begeistert. »Da freue ich mich drauf.«

Als ich schließlich nach Hause komme, ist es nach Mitternacht. Ein langer Tag mit vielen Fehlschlägen hat mich ausgelaugt. Im Flur liegen Luftballons herum, und auf dem Küchentisch steht eine halb leere Flasche Wein. An der Wand pinnt ein Bild, auf dem mit Wachsmalstiften steht: »Herzlichen Glückwunsch, Daddy!«

Als ich nachmittags meine Frau Paige angerufen hatte, um ihr von meiner Beförderung zu erzählen, war sie viel glücklicher als ich. Sie bestand darauf, die Nachbarn einzuladen, um das Ganze zu feiern. Doch weil ich jetzt erst zu Hause bin, habe ich meine eigene Party verpasst.

Um 14 Uhr konnte Patty erfolgreich zeigen, dass von den 27 Änderungen der letzten drei Tage nur Johns Verschlüsselungsänderung und das SAN-Upgrade mit dem Payroll-Problem in Verbindung stehen konnten. Aber Wes und sein Team waren immer noch nicht so weit, das SAN wieder ans Laufen zu bringen.

Um 15 Uhr musste ich Ann und Dick die schlechte Nachricht überbringen, dass wir keine andere Wahl hätten, als auf Plan B zurückzugreifen. Ihre Frustration und ihre Enttäuschung waren nicht zu verbergen.

Die Zeiterfassungsanwendung war um 19 Uhr wieder lauffähig und das SAN erst um 23 Uhr wieder im Netz.

Kein sehr erfolgreicher erster Tag für einen VP of IT Operations.

Bevor ich nach Hause fuhr, schrieb ich noch eine E-Mail mit dem Status an Steve, Dick und Ann und versprach, alles Nötige zu veranlassen, damit solch ein Fehler nicht wieder geschieht.

Ich gehe nach oben, putze mir die Zähne und schaue noch einmal kurz auf mein Telefon, bevor ich ins Bett gehe. Ich fluche, als ich eine E-Mail von unserem PR-Manager sehe mit dem Betreff: »Schlechte Neuigkeiten. Wir sind wohl morgen auf der Titelseite ...«

Ich sitze auf der Bettkante und lese mit zusammengekniffenen Augen den Text.

Elkhart Grove Herald Times

Parts Unlimited verpfuscht Gehaltsschecks, Gewerkschaftsvorsitzender nennt Fehler »unverschämt«

Der Automobilzulieferer Parts Unlimited kann seine Arbeiter nicht korrekt bezahlen, manche Mitarbeiter bekommen sogar gar kein Gehalt. Das geht aus einem internen Memo hervor. Die in Elkhart Grove beheimatete Firma hat zugegeben, dass es Probleme mit dem korrekten Erstellen der Gehaltsschecks für manche ihrer auf Stundenbasis bezahlten Arbeiter gab, während andere gar kein Gehalt bekommen. Parts Unlimited bestreitet, dass dies mit Liquiditätsproblemen zu tun hätte, vielmehr hätte es einen Fehler im Gehaltsabrechnungs-system gegeben.

Die früher bis zu vier Milliarden Dollar schwere Firma musste in den letzten Quartalen mit sinkenden Einnahmen und steigenden Verlusten kämpfen. Diese Finanzprobleme, die manche der oberen Führungsebene zuschreiben, haben unter den Arbeitern im Ort zu deutlich wachsenden Ängsten um ihren Arbeitsplatz geführt, weil sie Sorge haben, ihre Familien nicht mehr ernähren zu können.

Laut dem Memo kann es unabhängig von der Ursache für den Fehler Tage oder Wochen dauern, bis die Mitarbeiter ihren korrekten Lohn erhalten. »Das ist nur die letzte in einer langen Reihe von Management-Fehlentscheidungen, die die Firma in den vergangenen Jahren getroffen hat«, sagt Kelly Lawrence, Chief Industry Analyst bei Nestor Meyer.

Der CFO von Parts Unlimited, Dick Landry, hat auf Nachfragen der Herald Times zu den Problemen mit der Gehaltsabrechnung, den Buchungspannen und Führungsqualitäten nicht geantwortet.

In einer Erklärung, die Parts Unlimited veröffentlichte, entschuldigte sich Landry für die »Panne« und gelobte, dass so etwas nicht wieder vorkommen würde. Die Herald Times wird weiter berichten.

Zu müde, noch irgendetwas zu tun, schalte ich das Licht aus und mache mir eine gedankliche Notiz, mich morgen bei Dick persönlich zu entschuldigen. Ich schließe die Augen und versuche, einzuschlafen.

Eine Stunde später liege ich immer noch wach und starre an die Decke.

KAPITEL 4

Mittwoch, 3. September

Mit einem Kaffee in der Hand öffne ich um 7:30 Uhr meinen Laptop und hoffe, mit den E-Mails und Voicemails durch zu sein, bevor ich um 8 Uhr mein erstes Meeting habe. Fassungslos starre ich auf den Bildschirm. In den 22 Stunden, die seit meiner Beförderung vergangen sind, fanden 526 neue E-Mails den Weg in meine Inbox.

Ach du heilige Scheiße.

Ich überspringe alle Nachrichten rund um die gestrige Panne und bin erschrocken über die ganzen Glückwünsche von Lieferanten, die sich gern mit mir zum Essen treffen würden. Wie haben die das herausgefunden? Ich bin ziemlich sicher, dass ein Großteil meiner Firma noch gar nichts davon weiß.

Ich lese eine E-Mail von Ellen, der Assistentin meines früheren Chefs, die nun mich unterstützen soll. Sie beglückwünscht mich und fragt, wann wir uns treffen können. Ich antworte ihr, dass ich sie gerne im Lauf des Vormittags bei einem Kaffee sprechen würde. Dann schicke ich eine Nachricht an den IT Service Desk mit der Bitte, Ellen Zugriff auf meinen Kalender zu gewähren.

Eine rot blinkende LED an meinem Bürotelefon erregt meine Aufmerksamkeit. Dort steht: »07:50. 62 neue Nachrichten«.

Mir klappt die Kinnlade herunter. Es würde über eine Stunde dauern (die ich nicht habe), sie anzuhören. Ich schreibe Ellen noch eine E-Mail und bitte sie, meine Voicemails durchzugehen und alle aufzuschreiben, bei denen Handlungsbedarf besteht.

Bevor ich sie absende, füge ich noch schnell hinzu: »Falls Nachrichten von Steve oder Dick dabei sind, ruf mich direkt auf meinem Handy an.«

Ich schnappe mir meinen Notizblock und beeile mich, zum ersten Meeting zu kommen, als das Handy vibriert. Es ist eine dringende E-Mail:

Von: Sarah Moulton

An: Bill Palmer

Cc: Steve Masters

Datum: 3. September, 07:58

Wichtigkeit: Hoch

Betreff: Neue Verzögerungen bei Phoenix

Bill, wie Sie wissen, handelt es sich bei Phoenix um das wichtigste Projekt, das in unserer Firma gerade läuft. Ich habe unerfreuliche Gerüchte gehört, dass Sie das Release verzögern.

Ich muss Sie nicht daran erinnern, dass unsere Konkurrenz nicht schläft. Mit jedem weiteren Tag gehen unsere Marktanteile weiter zurück. Ich muss sicher sein, dass sich alle der Dringlichkeit bewusst sind. Insbesondere Sie, Bill.

Wir haben heute um 10 Uhr ein Notfall-Projektmanagement-Meeting. Bitte kommen Sie dazu und bereiten Sie sich darauf vor, diese inakzeptablen Verzögerungen zu erklären.

Steve – ich weiß, wie wichtig Ihnen dieses Projekt ist angesichts der Zusagen, die Sie dem Aufsichtsrat gegeben haben. Wenn Sie dafür Zeit finden, wäre es gut, wenn Sie ebenfalls teilnehmen könnten. Wir würden uns freuen, Ihre Sicht der Dinge zu hören.

Mit freundlichen Grüßen

Sarah

Oh, oh.

Ich leite die E-Mail an Wes und Patty weiter und markiere sie mit hoher Wichtigkeit. Eine Welt, in der die Hälfte der E-Mails dringend ist, kann nicht richtig sein. Ist denn wirklich alles so wichtig?

Ich rufe Wes auf seinem Handy an. »Ich habe gerade deine E-Mail von Sarah erhalten«, sagt er. »Was für ein völliger Bullshit.«

»Worum geht es da eigentlich?«, frage ich.

»Ich bin ziemlich sicher, dass sie sich auf Brent bezieht, der seine Konfiguration für die Phoenix-Entwickler nicht fertigstellen konnte. Wir müssen ihnen immer hinterherjagen, weil sie uns nicht sagen können, wie die Testumgebung auszusehen hat. Wir tun unser Bestes, aber immer wenn wir etwas bereitstellen, sagen sie uns, dass es falsch sein.«

»Wann haben sie uns davon erzählt?«, frage ich.

»Vor zwei Wochen. Das läuft immer so mit der Entwicklung, aber dieses Mal ist es schlimmer. Sie sind so verrückt darauf, ihre Termine einzuhalten, dass sie erst jetzt darüber nachdenken, wie das Ganze getestet und ausgeliefert werden soll. Und da versuchen sie halt, uns das Ganze in die Schuhe zu schieben. Mach dich auf etwas gefasst. Sarah wird uns in dem Meeting grillen wollen.«

Es ist erstaunlich, wie die Übergaben zwischen Entwicklung und IT Operations jedes Mal in die Hose gehen. Aber angesichts des dauerhaften Kleinkriegs zwischen den beiden Gruppen sollte ich nicht überrascht sein.

Ich antworte: »Okay, verstanden. Dann tue mir den Gefallen und schaue dir diese Entwicklungsspezifikation persönlich an. Wir müssen dafür sorgen, dass wir etwas in der Hand haben. Schnapp dir also alle Beteiligten – egal ob Entwickler oder Ops – und sperre sie so lange in einen Raum, bis wir eine schriftliche Spezifikation haben. Phoenix ist so wichtig, dass wir das nicht versaubeuteln dürfen.«

Wes versichert, dass er sich darum kümmern wird, und ich frage: »Gibt es noch etwas, das Sarah uns in die Schuhe schieben könnte?«

Er denkt nach und sagt schließlich: »Nein, ich glaube nicht. Wir haben mit dem Payroll-Lauf einen ziemlich guten Grund, warum Brent mit seiner Arbeit nicht fertig werden konnte.«

Dem stimme ich zu. Mit dem Gefühl, uns ausreichend gut abgesichert zu haben, sage ich: »Wir sehen uns um zehn.«

Weniger als eine Stunde später gehe ich in der warmen Sonne zu Gebäude 9, in dem viele der Marketingleute sitzen. Zu meiner Überraschung begleitet mich ein ganzer Trupp IT-Leute. Warum?

Dann wird es mir klar. Der größte Teil unserer Marketingprojekte ließe sich ohne IT gar nicht realisieren. Intensives Marketing braucht Hightech. Aber wenn so viele von uns mit diesen Marketingprojekten zu tun haben – sollten die Meetings dann nicht bei uns abgehalten werden?

Ich vermute, dass es Sarah so lieber hat. Sie sitzt als Spinne im Dunkeln und erfreut sich daran, wie all die Arbeitsknechte zu ihrem Bau kommen.

Beim Eintreffen sehe ich zuerst Kirsten Fingle, die das Projektmanagement-Büro leitet. Sie sitzt am Kopf des Tischs. Ich bin von ihr sehr begeistert, denn sie ist organisiert, besonnen und verantwortungsbewusst. Als sie vor fünf Jahren zur Firma kam, brachte sie ein ganz neues Niveau an Professionalität mit.

Rechts von ihr lehnt sich Sarah in ihrem Stuhl zurück. Sie tippt auf ihrem iPhone herum und nimmt ihre Umgebung gar nicht wahr.

Sarah ist so alt wie ich: 39. Diesbezüglich passt sie sehr darauf auf, was sie sagt – sie lässt einen immer glauben, sie sei älter, gleichzeitig lügt sie aber nicht direkt.

Noch etwas, das mich bei ihr wahnsinnig macht.

Im Raum sind 25 Personen. Viele der Verantwortlichen der Geschäftsbereiche sind da, von denen einige für Sarah arbeiten. Chris Allers ist ebenfalls da. Er ist ein bisschen älter als ich und sieht schlank und fit aus. Genauso häufig, wie er mit seinen Mitarbeitern scherzt, tritt er ihnen auch in den Hintern, wenn sie eine Deadline verpasst haben. Er hat den Ruf, ein kompetenter und gradliniger Manager zu sein. Bei fast 200 Entwicklern, die für ihn arbeiten, muss er das auch.

Um bei Phoenix zu helfen, wurde sein Team in den letzten beiden Jahren um 50 Personen aufgestockt – größtenteils in Offshore-Entwicklerfirmen. Chris muss ständig mit der Anforderung kämpfen, mehr Features in weniger Zeit und mit weniger Geld umzusetzen.

Viele seiner Manager sind ebenfalls mit im Raum –auch Wes, er sitzt rechts von Chris. Als ich mich nach einem freien Platz umsehe, bemerke ich eine ungewöhnliche Anspannung bei allen. Und dann sehe ich auch, warum.

Da, direkt neben dem einzigen freien Platz am Tisch, sitzt Steve. Jeder hier scheint sich große Mühe zu geben, ihn nicht anzustarren. Als ich mich ganz lässig neben ihn setze, summt mein Telefon. Eine SMS von Wes:

Scheiße. Steve hat noch nie an einem Projektmanagement-Meeting teilgenommen. Wir sind im Arsch.

Kirsten räuspert sich. »Der erste Punkt auf unserer Agenda ist Phoenix. Da gibt es nicht viel Gutes zu berichten. Der Status ist schon vor vier Wochen von Gelb nach Rot gewechselt, und meiner persönlichen Einschätzung nach ist die Deadline in ernsthafter Gefahr.«

Mit ihrer professionellen Stimme fährt sie fort: »Zur Erinnerung: Letzte Woche gab es zwölf Aufgaben im kritischen Pfad von Phoenix Phase 1. Nur drei davon wurden erledigt.«

Es gibt ein kollektives Aufstöhnen und viel Gemurmel im Raum. Steve schaut mich an. »Nun?«

Ich erkläre: »Die kritische Ressource ist Brent, der vollständig mit dem Beheben des Payroll-Fehlers beschäftigt war, von dem wir ja alle wissen. Das war ein komplett unvorhersehbarer Notfall, den wir aber ganz offensichtlich lösen mussten. Jeder weiß, wie wichtig Phoenix ist, und wir tun alles, was möglich ist, damit sich Brent darauf konzentrieren kann.«

»Vielen Dank für Ihre ausgesprochen kreative Erklärung, Bill«, ätzt Sarah. »Das eigentliche Problem ist hier doch, dass Ihre Leute anscheinend nicht erkennen, wie wichtig Phoenix für die Firma ist. Unsere Konkurrenz fegt uns vom Markt. Sie haben alle die Werbung über ihre neuen Services gesehen und gehört. Sie sind innovativer – sowohl in den Filialen als auch online. Sie haben schon einige unserer wichtigsten Partner abgeworben, und unser Vertrieb bekommt langsam Panik. Ich bin nicht der Typ für ›Ich habe es doch gesagt‹, aber ihre neuesten Produktankündigungen zeigen, warum wir nicht so weitermachen können, als ob nichts geschehen wäre.«

Sie fährt fort: »Bill, damit wir unseren Marktanteil wieder erhöhen können, müssen wir Phoenix ausliefern. Aber aus irgendeinem Grund sorgen Sie und Ihr Team nur für Verzögerung. Vielleicht sind Ihre Prioritäten nicht richtig gesetzt? Oder vielleicht sind Sie es ja nicht gewohnt, solch ein wichtiges Projekt zu unterstützen?«

Trotz meiner mentalen Vorbereitung merke ich, wie ich wütend werde. Vielleicht liegt es an der herablassenden Art und Weise, wie sie Steve nachplappert. Oder dass sie mich während ihrer Gardinenpredigt nicht angesehen hat, sondern Steve, um zu sehen, wie er reagiert. Oder dass sie mich mehr oder weniger als desinteressiert und inkompetent bezeichnet hat.

Alle halten die Luft an, während ich mich dazu zwinge, tief durchzuatmen.

Mein Ärger löst sich wieder auf. Das alles sind nur politische Spielchen. Die mag ich nicht, aber ich muss damit klarkommen. Bei den Marines war ich mit meiner Karriere schon fast durch, als ich doch noch zum Staff Sergeant befördert wurde. Man wird dort kein Unteroffizier, wenn man die politischen Spielchen nicht beherrscht.

»Interessant«, sage ich zu Sarah, »erzählen Sie mir, was wichtiger ist: unsere Arbeiter zu bezahlen oder die Phoenix-Aufgaben zu erledigen? Steve hat mich aufgefordert, das Payroll-Problem zu lösen. Hätten Sie das anders als Steve priorisiert?«

Als ich Steve erwähne, ändert sich Sarahs Gesichtsausdruck. »Nun, wenn die IT das Problem gar nicht erst verursacht hätte, müssten Sie nicht Ihre Zusagen uns gegenüber in den Wind schießen. Ich glaube, wir können uns auf Sie und Ihr Team nicht verlassen.«

Ich nicke langsam, nehme aber den Fehdehandschuh nicht auf. »Dann bin ich auf Vorschläge von Ihnen gespannt, Sarah.«

Sie sieht mich an, dann Steve. Offensichtlich merkt sie, hier nicht mehr punkten zu können, denn sie rollt nur mit den Augen. Ich sehe, wie Wes angesichts dieser Diskussion ungläubig den Kopf schüttelt und unerwartet ruhig bleibt.

Sarah fährt fort: »Wir haben über 20 Millionen Dollar für Phoenix ausgegeben und sind nahezu zwei Jahre zu spät. Wir müssen endlich liefern.« Mit einem Blick auf Chris fragt sie: »Angesichts der Verzögerungen durch Bills Gruppe – wann können wir frühestens live gehen?«

Chris schaut von seinen Papieren hoch. »Ich habe mir das angeschaut, nachdem wir letzte Woche darüber geredet haben. Wenn wir bei einigen Punkten Gas geben und wenn die virtualisierte Umgebung von Bills Team wie gewünscht läuft, können wir Freitag in einer Woche produktiv gehen.«

Ich starre Chris an. Er hat sich einfach ein Datum aus den Fingern gesogen, ohne dabei all die Dinge zu berücksichtigen, die vor dem Deployment noch getan werden müssen.

Ich habe einen plötzlichen Flashback. Bei den Marines hatten wir für die oberen Unteroffiziere ein Ritual. Wir tranken Bier und schauten Star Wars: Die Rückkehr der Jedi-Ritter. Immer dann, wenn Admiral Ackbar rief: »Das ist eine Falle!«, brüllten wir vor Lachen und spulten zurück.

Dieses Mal lache ich nicht.

»Moment mal,« greift Wes ein und schlägt mit der Hand auf den Tisch. »Was wollen Sie uns da anhängen? Wir haben vor gerade einmal zwei Wochen von den Spezifikationen für das Phoenix-Deployment erfahren. Ihre Leute haben uns immer noch nicht erzählt, was für eine Infrastruktur wir brauchen, daher können wir noch nicht einmal die notwendigen Server und Netzwerkgeräte bestellen. Und ganz nebenbei – die Lieferanten haben schon angekündigt, dass die Lieferzeit mindestens drei Wochen betragen wird!«

Er wendet sich nun an Chris und sagt ärgerlich: »Außerdem habe ich gehört, dass die Performance eures Codes so unterirdisch ist, dass wir die schnellsten und besten Geräte brauchen, die der Markt zu bieten hat. Eure Anforderung ist, 250 Transaktionen pro Sekunde zu unterstützen, und ihr schafft zurzeit nicht einmal vier! Wir werden so viel Hardware brauchen, dass ein eigenes Rack nötig sein wird, und vermutlich müssen wir auch noch einen Aufschlag zahlen, damit wir die ganze Hardware rechtzeitig bekommen. Wer weiß, wie sich das auf unser Budget auswirkt.«

Chris will antworten, aber Wes ist gerade in Fahrt. »Wir haben noch keine konkrete Spezifikation, wie die Produktions- und Testsysteme konfiguriert werden sollen. Oh, braucht ihr keine Testumgebung mehr? Ihr habt doch euren Code noch gar nicht richtig getestet, denn dann würde der Zeitrahmen ganz gesprengt werden!«

Mir sinkt das Herz in die Hose, als mir die Konsequenzen bewusst werden. Den Film habe ich schon mal gesehen. Die Handlung ist einfach: Sie nehmen ein dringendes Projekt mit einem festen Liefertermin, der nicht verschoben werden kann, weil der Wall Street oder dem Kunden Versprechungen gemacht wurden. Dann fügen Sie einen Haufen Entwickler hinzu, die die gesamte verfügbare Zeit ausnutzen und kein Fitzelchen Zeit mehr für Tests oder eine ordentliche Auslieferung lassen. Und weil niemand den Auslieferungstermin anpassen will, müssen alle, die nach der Entwicklung noch mit dem Projekt zu tun haben, ihre Aufgaben in ausgesprochen kurzer Zeit erledigen, um im Zeitrahmen zu bleiben.

Die Ergebnisse sind nie schön. Normalerweise ist das Softwareprodukt so instabil und unbenutzbar, dass selbst die Leute, die danach geschrien haben, der Meinung sind, die Auslieferung wäre überflüssig gewesen. Und es sind immer die Leute von IT Operations, die nächtelang aufbleiben, die Server stündlich durchstarten, um den gruseligen Code zu kompensieren, und all die anderen Heldentaten vollbringen, um vor dem Rest der Welt zu verbergen, wie schlecht es eigentlich um das Produkt aussieht.

»Leute, ich verstehe den Wunsch, Phoenix so schnell wie möglich in den Produktivbetrieb zu bringen«, sage ich so ruhig wie möglich zu Steve und Chris. »Aber ausgehend von dem, was wir gerade von Wes gehört haben, ist es meiner Meinung nach viel zu früh für ein Deployment. Wir wissen weder, was für Equipment wir brauchen, um die Performanceziele zu erreichen, noch sind irgendwelche Kapazitätstests gelaufen, um unsere Schätzungen zu untermauern. Es ist sehr unwahrscheinlich, dass wir eine adäquate Dokumentation vorliegen haben, um dieses Ding produktiv einzusetzen, geschweige denn, alles zu monitoren und zu sichern.«

So überzeugend wie möglich fahre ich fort: »Nichts wäre mir lieber, als Phoenix endlich am Markt zu haben, aber wenn die User Experience zu schlecht ist, vergraulen wir unsere Kunden, und sie gehen zur Konkurrenz.«

Ich wende mich Chris zu. »Ihr könnt uns nicht einfach den Kram über den Zaun werfen und euch dann gegenseitig ein High five geben, um euch dazu zu gratulieren, dass ihr die Deadline geschafft habt. Wes erzählt uns gerade, dass der Kram vermutlich in tausend Teile zersplittert sein wird, und dann sind es meine Leute, die nächtelang und am Wochenende arbeiten müssen, damit er wieder zusammengepuzzelt wird.«

Chris reagiert gereizt. »Erzähl mir nicht diesen Mist mit ›über den Zaun werfen‹. Wir haben euch zu unseren Architektur- und Planungs-Meetings eingeladen, aber ich kann an einer Hand abzählen, wie oft dann auch jemand gekommen ist. Meist müssen wir Tage oder sogar Wochen warten, bis wir von euch das bekommen, was wir brauchen!«

Dann hält er seine Hände hoch, so als ob alles außer Kontrolle sei. »Schaut, ich würde auch gerne mehr Zeit haben. Aber von Anfang an wusste jeder, dass die Deadline fix sein würde. Das war eine Businessentscheidung, die wir gemeinsam getroffen haben.«

»Genau!«, grätscht Sarah in das Gespräch, bevor ich antworten kann. »Das zeigt doch, dass Bill und sein Team kein Gespür für die Dringlichkeit besitzen. Perfektion ist der Feind des Guten. Bill, wir besitzen einfach nicht den Luxus, alles so lange zu polieren, bis es irgendeinen von Ihnen vorgeschlagenen Gold-Standard erfüllt. Wir müssen Gewinn machen, und das können wir nur, wenn wir Marktanteile zurückgewinnen. Und dazu muss Phoenix live gehen.«

Sie sieht Steve an. »Uns war das Risiko doch klar, oder Steve? Sie haben das den Analysten und selbst den Leuten von CNBC wirklich toll verkauft – ich glaube nicht, dass wir jetzt abgewatscht werden wollen, weil wir noch später liefern, als wir es sowieso schon tun.«

Steve nickt bedächtig und reibt sich am Kinn, während er nachdenkt. »Stimmt«, sagt er schließlich und lehnt sich vor. »Wir haben unseren Investoren und den Analysten gegenüber die Zusage gemacht, dass wir Phoenix in diesem Quartal ausliefern werden.«

Mir fällt die Kinnlade herunter. Sarah hat all meine Argumente einfach beiseite gewischt und Steve auf einen waghalsigen, destruktiven Weg geschickt.

Verärgert sage ich: »Sieht denn keiner, wie verrückt das ist? Ich war in diesem Raum bei einem Meeting dabei, in dem wir über das Installieren neuer Wasserspender in jeder Filiale diskutiert haben. Das Team hatte neun Monate Zeit, den Roll-out zu planen. Neun Monate! Und alle waren der Meinung, das sei vernünftig.

Jetzt reden wir über Phoenix, das Tausende POS-Systeme und die gesamten Back-Office-Buchungssysteme betrifft. Das ist mindestens zehntausendmal komplexer als das Installieren der Wasserspender und weitaus risikoreicher für den Geschäftsbetrieb. Und wir bekommen nur eine Woche, um den Roll-out zu planen und umzusetzen?«

Ich schaue Steve inständig an. »Ist das nicht ein bisschen waghalsig und unfair?«

Kirsten nickt, aber Sarah sagt geringschätzig: »Bill, das ist eine rührende Geschichte, aber es geht hier nicht um Wasserspender, sondern um Phoenix. Und zudem glaube ich, die Entscheidung ist schon gefallen.«

Steve sagt: »Ja, das ist sie. Vielen Dank für Ihre Einschätzung der Risiken, Bill.« Er wendet sich Sarah zu. »Wann wird Phoenix freigegeben?«

Sarah antwortet schnell: »Marketing-Launch ist nächsten Samstag, am 13. September. Phoenix wird am Tag zuvor um 17 Uhr verfügbar sein.«

Steve schreibt sich die Daten in seine Kladde und sagt: »Gut. Halten Sie mich über den Fortschritt auf dem Laufenden und lassen Sie mich wissen, wenn es irgendetwas gibt, was ich tun kann.«

Ich schaue zu Wes, der mit seinen Händen ein Flugzeug darstellt, das vor ihm auf den Tisch aufschlägt und in Flammen aufgeht.

In der Halle sagt Wes: »Na, das lief doch ziemlich gut, Chef.«

Mir ist nicht zum Lachen zumute. »Was ist da drin passiert? Wie konnten wir in diese Lage geraten? Weiß irgendjemand, was wir tun müssen, um diesen Launch zu unterstützen?«

»Keiner hat eine Ahnung«, antwortet er und schüttelt empört den Kopf. »Wir haben uns noch nicht einmal darauf geeinigt, wie die Übergabe von der Entwicklung aussieht. Bisher haben sie einfach einen Link zu einem Netzwerkordner geschickt und gesagt: ›Da, das muss deployt werden.‹ Es gibt ausgesetzte Neugeborene, die mehr Handlungsanweisungen mitgeliefert bekommen.«

Ich schüttele meinen Kopf angesichts dieses Vergleichs, aber er hat recht. Wir haben hier ein echtes Problem.

Er fährt fort: »Wir müssen ein gewaltiges Team bilden, einschließlich der Leute von Chris, um herauszufinden, wie wir das lösen. Wir haben Probleme auf jeder Ebene: Netzwerk, Server, Datenbanken, Betriebssysteme, Anwendungen, Layer-7-Switching – das volle Programm. Die nächsten neun Tage werden für uns alle sehr lang werden.«

Ich nicke unglücklich. Diese Art von gemeinsamem Aktivismus gehört zur IT, aber ich ärgere mich, wenn wir wieder die Helden sein müssen, um die fehlende Planung von anderen auszubügeln.

Ich sage: »Ruf dein Team zusammen und bitte Chris, das mit seinem auch zu machen. Aber schreib keine E-Mail und lass das Ticketsystem außen vor. Alle müssen zusammen in einem Raum sein.

Ach, und noch was: Was meinte Chris, als er sagte, dass unsere Leute nie bei den Architektur- und Planungs-Meetings von Phoenix aufgeschlagen sind? Stimmt das?«

Wes rollt frustriert mit den Augen. »Ja, denn meist haben seine Leute uns immer auf den letzten Drücker eingeladen. Echt jetzt, wer kann in seinem Kalender innerhalb von einem Tag oder weniger einen Termin freibekommen?«

Nach einem Moment sagt er: »Um fair zu sein: Bei einigen der größeren Planungs-Meetings wurden wir rechtzeitig informiert. Und eine der entscheidendsten Personen, die dort hätte sein müssen, konnte es nicht, weil es Eskalationen gab. Dreimal darfst du raten, wer das war ...«

Ich stöhne. »Brent?«

Wes nickt. »Jepp. Er ist der Einzige, der den idiotischen Entwicklern bei solchen Meetings erzählen kann, wie es in der Realität aussieht und was im Produktivbetrieb auf jeden Fall kaputtgehen wird. Die Ironie daran ist, dass er nie zu den Meetings gehen kann, um den Entwicklern das zu erzählen, weil er immer damit beschäftigt ist, all diese Dinge zu reparieren.«

Er hat recht. Wenn wir diesen Teufelskreis nicht durchbrechen können, werden wir immer weiter hineingezogen werden. Brent muss mit den Entwicklern zusammenarbeiten, um die Probleme an der Quelle zu beheben, damit wir nicht dauernd mit dem Löschen von Feuern beschäftigt sind. Aber Brent hat keine Zeit dazu, weil er eben die Feuer löschen muss.

Ich sage: »Wir brauchen unsere besten Köpfe bei der Vorbereitung dieses Deployments. Sorge also dafür, dass Brent dabei ist.«

Wes sieht einen Moment verlegen aus. »Was ist?«, frage ich ihn.

»Ich glaube, er arbeitet gerade an einer Netzwerkstörung«, antwortet er.

»Jetzt nicht mehr«, sage ich. »Das werden sie mal ohne ihn regeln müssen. Wenn damit irgendjemand ein Problem hat, soll er zu mir kommen.«

»Okay, was immer du willst, Chef«, sagt er und zuckt mit den Schultern.

Nach dem Projektmanagement-Meeting bin ich nicht in der Stimmung, mit jemandem zu reden. Ich sitze an meinem Schreibtisch und bin knurrig, weil mein Laptop nicht wieder aufwachen will. Einzig die Festplatten-LED blinkt vor sich hin. Als sich auf dem Bildschirm nichts tut, schnappe ich mir meine leere Kaffeetasse, die neben dem Bild mit Paige und meinen zwei Söhnen steht, und gehe zur Kaffeemaschine im Flur.

Als ich zurückkomme, teilt mir ein Fenster auf dem Bildschirm mit, dass ein kritisches neues Update einzuspielen ist. Ich setze mich, klicke auf »Ok« und beobachte, wie der Fortschrittsbalken langsam wächst. Plötzlich erscheint der verfluchte »Blue Screen of Death«. Mein Laptop ist platt, und ich kann ihn nicht nutzen.

Auch nach einem Reboot bleibt es dabei. Ich murre verzweifelt: »Du willst mich doch verarschen!«

In dem Moment schaut Ellen, meine neue Assistentin, um die Ecke. Sie streckt die Hand aus und sagt: »Guten Morgen. Herzlichen Glückwunsch zur Beförderung, Bill!« Dann sieht sie meinen Laptop mit dem Blue Screen und sagt mitfühlend: »Oh, das sieht nicht gut aus.«

»Umm, danke«, sage ich und schüttele ihre Hand. »Wegen des Laptops – können Sie jemanden im Desktopsupport fragen? Bei Phoenix ist noch viel zu tun, und ich brauche den Rechner.«

»Kein Problem«, sagt sie und lächelt. »Ich werde denen erzählen, dass unser neuer VP im Dreieck springt, weil sein Laptop nicht läuft. Von allen, die hier arbeiten, brauchen Sie wohl am ehesten einen funktionierenden Computer, oder?

Wissen Sie«, fügt sie hinzu, »ich habe gehört, dass heute viele dieses Problem haben. Ich werde dafür sorgen, dass Sie an den Anfang der Liste wandern. Sie können es sich nicht leisten, zu warten, bis Sie dran sind.«

Noch mehr zerschossene Laptops? Das ist der sichere Beweis, dass mir das Universum heute eins auswischen will.

»Ach übrigens, ich brauche Hilfe beim Koordinieren von ein paar Notfall-Phoenix-Meetings. Hat Ihnen schon jemand Zugriff auf meinen Kalender gegeben?«, frage ich.

Sie verdreht die Augen. »Nein. Das ist auch der Grund, warum ich eigentlich heruntergekommen bin. Ich wollte Sie fragen, ob Sie mir die nächsten paar Tage ausdrucken können. Aber das ist jetzt ja nicht machbar. Ich werde das den Supporter, der sich um Ihren Laptop kümmert, machen lassen. Manchmal dauert es Wochen, bis die E-Mail-Administratoren solche Aufgaben abarbeiten.«

Wochen? Das ist inakzeptabel. Ich schaue auf meine Uhr und entscheide, mich später darum zu kümmern. Ich bin sowieso schon zu spät.

»Versuchen Sie Ihr Bestes«, sage ich. »Ich bin bei Pattys Enterprise-Change-Management-Meeting. Wenn Sie etwas brauchen, rufen Sie mich an, okay?«

Zehn Minuten zu spät schlüpfe ich zu Pattys Meeting in den Raum, denn ich gehe davon aus, dass entweder ein Haufen Leute ungeduldig auf mich wartet oder das Meeting schon in vollem Gange ist.

Stattdessen sehe ich nur Patty, die am Konferenztisch sitzt und an ihrem Laptop arbeitet.

»Willkommen zum CAB, Bill. Ich hoffe, du findest noch einen freien Stuhl«, sagt sie.

»Wo sind die alle?«, frage ich.

Ich bin perplex. Als ich noch die Midrange-Gruppe leitete, hat keiner in meinem Team die Change-Management-Meetings verpasst. Denn hier haben wir die ganze Arbeit koordiniert und organisiert, um sicherzustellen, dass wir uns nicht selbst ins Knie schießen.

»Ich habe dir doch gestern schon erzählt, dass das Change-Management hier etwas lasch gesehen wird«, sagt Patty seufzend. »Manche Gruppen haben ihren eigenen Change-Management-Prozess, so wie ihr. Aber die meisten tun gar nichts. Der Ausfall gestern ist doch der beste Beweis dafür, dass wir auf Firmenebene so etwas benötigen. Momentan weiß die linke Hand nur sehr selten, was die rechte tut.«

»Was ist also das Problem?«, frage ich.

Patty schürzt die Lippen. »Ich weiß es nicht. Wir haben einen ganzen Haufen Leute zum ITIL-Training geschickt, sodass sie sich mit den ganzen Best Practices vertraut machen konnten. Wir haben uns Berater ins Haus geholt, die uns dabei halfen, das Ticket-System durch ein ITIL-konformes Change-Management-Tool zu ersetzen. Die Leute sollten ihre Change Requests dort eintragen und sich genehmigen lassen. Aber nach zwei Jahren haben wir nur einen tollen Prozess auf dem Papier, dem keiner folgt, und ein Tool, das keiner nutzt. Wenn ich die Leute dränge, es zu verwenden, erhalte ich nur Beschwerden und Ausreden.«

Ich nicke. ITIL steht für die IT Infrastructure Library, in der viele Best Practices und Prozesse rund um IT dokumentiert sind. Aber das ITIL-Programm steht in dem Ruf, nur die eigene Zeit zu verschwenden.

Ich ärgere mich, dass Wes nicht da ist. Ich weiß, dass er zu tun hat, aber wenn er nicht hier ist – warum sollten seine Mitarbeiter dann kommen? Solche Aktivitäten müssen von oben kommen – und auch durchgehalten werden.

»Nun, sie können sich bei mir beschweren und ihre Ausreden vortragen«, sage ich bestimmt. »Wir starten den Change-Management-Prozess neu. Mit meiner vollen Unterstützung. Steve hat mir aufgetragen, dafür zu sorgen, dass die Leute sich auf Phoenix konzentrieren können. Solche Ausfälle wie gestern mit dem SAN sorgen dafür, dass wir Teile von Phoenix nicht rechtzeitig bereitstellen konnten, und jetzt müssen wir dafür bezahlen. Wenn jemand bei einem Change-Management-Meeting nicht dabei sein will, braucht dieser Jemand anscheinend ein wenig Unterstützung. Durch mich.«

Als Patty mich bei der Erwähnung von Phoenix verwirrt anschaut, beschreibe ich ihr kurz, wie Wes und ich den Morgen damit verbracht haben, uns überfahren zu lassen. Sarah und Chris saßen am Steuer, aber Steve war auch dabei und spornte sie an, uns umzunieten.

»Das ist nicht gut«, sagt sie missbilligend. »Kirsten ist auch überfahren worden, oder?«

Ich nicke, will aber nicht mehr sagen. Ich mochte schon immer den Spruch aus Der Soldat James Ryan: »Es gibt eine Befehlskette: Man meckert nach oben, nicht nach unten.«

Stattdessen bitte ich sie, mir den aktuellen Change-Prozess zu beschreiben und zu erklären, wie er sich mit den Tools automatisieren lässt. Das klingt alles vernünftig. Aber es gibt nur eine Möglichkeit, zu sehen, ob der Prozess funktioniert.

Ich sage: »Setze ein weiteres CAB-Meeting für Freitag an. Gleiche Uhrzeit. Ich werde eine E-Mail an alle CAB-Verantwortlichen schicken und sie wissen lassen, dass das verpflichtend ist.«

Als ich zu meinem Büro zurückkehre, sitzt Ellen an meinem Schreibtisch, über meinen Laptop gebeugt, und schreibt mir eine Notiz.

»Ich hoffe, es läuft wieder alles?«, frage ich.

Als sie mich hört, zuckt sie zusammen. »Mein Gott, hast du mich erschreckt«, sagt sie lachend. »Der Support hat dir einen Ersatzlaptop dagelassen, weil sie deinen normalen nicht wieder zum Laufen bekommen haben – auch nicht nach einer halben Stunde.«

Sie zeigt auf die andere Seite meines Schreibtischs, und ich muss zwei Mal hinsehen. Mein Ersatzlaptop scheint nahezu zehn Jahre alt zu sein – er ist doppelt so groß wie mein alter und sieht dreimal so schwer aus. Der Akku wurde mit Klebeband gesichert, und die Hälfte der Tasten auf der Tastatur ist von der langen Nutzung abgescheuert.

Einen Moment frage ich mich, ob das ein Scherz sein soll.

Ich setze mich hin und öffne meine E-Mails, aber alles ist so langsam, dass ich mehrfach glaube, der Rechner sei abgestürzt.

Ellen sieht mich mitfühlend an. »Der Supporter hat gesagt, das sei alles, was heute zur Verfügung stünde. Mehr als 200 Leute haben ähnliche Probleme, und viele haben überhaupt keinen Ersatz bekommen. Anscheinend haben alle mit deinem Laptopmodell diese Probleme, weil ein Security-Patch eingespielt wurde.«

Ach ja. Heute ist Patch Tuesday, da werden von John und seinem Team die Sicherheitspatches der wichtigsten Programme eingespielt. Und wieder sorgt John bei meinem Team für große Probleme und Ausfälle.

Ich nicke nur und danke ihr für die Hilfe. Nachdem sie weg ist, setze ich mich hin und schreibe eine E-Mail an alle CAB-Verantwortlichen, wobei mein Drücken der Tasten oft zehn Sekunden und mehr brauchen, bis sie auf dem Bildschirm Spuren hinterlassen.

Von: Bill Palmer

An: Wes Davis, Patty McKee, IT Operations Management

Datum: 3. September, 14:43

Wichtigkeit: Hoch

Betreff: Verpflichtendes CAB-Meeting am Freitag, 14 Uhr

Ich habe heute am wöchentlichen CAB-Meeting teilgenommen und war ausgesprochen verärgert, dass ich neben Patty der einzige Teilnehmer war – insbesondere angesichts des vermeidbaren gestrigen Ausfalls, der durch Änderungen ausgelöst wurde.

Ab sofort müssen Manager (oder ihre Vertreter) an allen angesetzten CAB-Meetings teilnehmen und die ihnen zugewiesenen Aufgaben erledigen. Wir werden den Change-Management-Prozess bei Parts Unlimited wiederbeleben und ihn bis zum letzten Buchstaben befolgen.

Jeder, der versucht, das Change-Management zu umgehen, muss mit disziplinarischen Maßnahmen rechnen.

Am Freitag um 14 Uhr wird es ein verpflichtendes CAB-Meeting geben. Wir sehen uns dort. Wer Fragen oder Bedenken hat, kann mich gerne anrufen.

Vielen Dank für die Unterstützung

Bill

Ich drücke auf »Senden« und warte 15 Sekunden, bis die E-Mail tatsächlich meinen Postausgang verlässt. Fast sofort klingelt mein Handy.

Es ist Wes. Ich sage: »Ich wollte dich gerade wegen der Laptops anrufen. Wir brauchen Ersatz für unsere Manager und Mitarbeiter, damit sie ihre Aufgaben erledigen können.«

»Ja, ja, da sind wir schon dran. Aber deswegen rufe ich gar nicht an. Und auch nicht wegen Phoenix«, sagt er genervt. »Es geht um deine Mail zum Change-Management: Ich weiß, du bist der Boss, aber du solltest doch wissen, dass die IT beim letzten Change-Management-Bekehrungsversuch komplett zum Erliegen kam. Keiner – und ich meine wirklich keiner – konnte irgendetwas erledigt bekommen. Patty bestand darauf, dass jeder eine Nummer zog und darauf wartete, dass ihre Eierköpfe unsere Änderungen genehmigten und einplanten. Es war absolut lächerlich und eine völlige Zeitverschwendung.«

Wes lässt sich nicht stoppen: »Diese Software, die wir nutzen sollten, ist totaler Müll. Es dauert 20 Minuten, alle Felder für eine Änderung auszufüllen, die in fünf Minuten umgesetzt wäre! Ich weiß nicht, wer den Prozess entworfen hat, aber ich glaube, sie gehen davon aus, dass wir alle auf Stundenbasis bezahlt werden und lieber über unsere Arbeit reden, statt sie zu erledigen.

Irgendwann hat das Networking and Server Team rebelliert und sich geweigert, Pattys Tool einzusetzen«, fährt er hitzig fort. »Aber John lief mit dem Ergebnis eines Audits zu Luke, unserem alten CIO. Und wie du legte Luke fest, dass wir uns an die Richtlinien halten müssen und jeder gefeuert würde, der das nicht tut.

Meine Leute haben die Hälfte der Zeit damit verbracht, Verwaltungskram zu erledigen und in dem blöden CAB-Meeting zu sitzen«, redet er weiter. »Zum Glück ließ das Ganze mit der Zeit nach, und John bemerkte gar nicht, dass keiner mehr zu den Meetings ging. Er selbst war doch auch schon mindestens ein Jahr nicht mehr da!«

Interessant.

»Ich verstehe«, sage ich. »Das darf so nicht wieder passieren, aber wir können uns auch kein weiteres Payroll-Desaster leisten. Wes, ich brauche dich dort, und du musst dabei helfen, eine Lösung zu finden. Denn sonst bist du ein Teil des Problems. Kann ich mich auf dich verlassen?«

Ich höre ihn laut seufzen. »Ja sicher. Aber du kannst davon ausgehen, dass ich meine Klappe nicht halte, wenn Patty versucht, irgendein Bürokratiemonster zu schaffen, das uns allen das Leben aussaugt.«

Ich seufze.

Bisher dachte ich, IT Operations würde nur durch Entwicklung, Information Security, Audit und Geschäftsbereiche bedrängt werden. Jetzt erkenne ich, dass sich meine obersten Manager anscheinend auch untereinander bekriegen.

Was müssen wir bloß tun, damit wir wieder miteinander auskommen?

KAPITEL 5

Donnerstag, 4. September

Als der Wecker um 6:15 klingelt, bin ich schlagartig wach. Mein Kiefer tut weh, weil ich die ganze Nacht angespannt war. Die trostlose Aussicht auf den anstehenden Phoenix-Launch ließ sich nicht aus meinen Gedanken vertreiben.

Wie immer werfe ich vor dem Aufstehen schon kurz einen Blick auf mein Handy, um nach schlechten Neuigkeiten zu suchen. Normalerweise verbringe ich rund zehn Minuten mit dem Beantworten von E-Mails – es ist immer praktisch, schon gleich am Morgen ein paar Bälle von meiner Seite des Felds weggeschlagen zu haben.

Dann sehe ich etwas, das mich so schnell aufsetzen lässt, dass ich Paige aufwecke. »Mein Gott, was ist los?«, fragt sie erschrocken und noch nicht ganz wach.

»Eine neue Mail von Steve. Leg dich wieder hin, Schatz ...«, sage ich zu ihr, während ich meine Augen mal wieder zusammenkneife, um die Mail zu lesen.

Von: Steve Masters

An: Bill Palmer

Cc: Nancy Mailer, Dick Landry

Datum: 4. September, 06:05

Wichtigkeit: Hoch

Betreff: DRINGEND: Review zu SOX-404-IT-Audit-Ergebnissen

Bill, bitte schauen Sie sich das ASAP an. Ich muss Ihnen nicht sagen, wie wichtig es ist, ein sauberes SOX-404-Audit abzuliefern.

Nancy, bitte arbeiten Sie mit Bill Palmer zusammen, der jetzt für IT Operations verantwortlich ist.

Steve

>>>Beginn der weitergeleiteten Nachricht:

Wir haben gerade unseren internen Audit von Q3 abgeschlossen, um für das anstehende externe SOX-404-Audit bereit zu sein. Dabei sind uns einige besorgniserregende Defizite aufgefallen, die wir besprechen müssen. Aufgrund der Schwere und Dringlichkeit der Ergebnisse müssen wir uns gleich morgens mit IT treffen.

Nancy

Und tatsächlich gibt es in meinem Kalender ein zweistündiges Meeting um 8 Uhr, angesetzt von Nancy Mailer, Chief Audit Executive.

Heilige Scheiße. Nancy ist ausgesprochen klug und anspruchsvoll. Vor Jahren habe ich erlebt, wie sie beim Eingliedern einer aufgekauften Handelskette einen Manager gegrillt hat. Er präsentierte seine Finanzzahlen, als sie mit schnellen Fragen nachhakte – wie eine Mischung aus Columbo, Matlock und Scarface.

Er brach ziemlich schnell ein und gab zu, die Ergebnisse seiner Abteilung zu positiv dargestellt zu haben.

Bei der Erinnerung an dieses Meeting fange ich an zu schwitzen. Ich habe nichts falsch gemacht. Aber angesichts des Tons der E-Mail ist Nancy etwas Wichtigem auf der Spur, und Steve hat mich ihr in den Weg geworfen.

In meiner Midrange-Technology-Gruppe habe ich immer ein strenges Regiment geführt. So hatten wir nie großen Ärger mit der Audit-Gruppe. Sicher, es gab immer viele Fragen und Dokumentationsanforderungen, für die wir ein paar Wochen zum Sammeln von Daten und Vorbereiten der Antworten brauchten. Gelegentlich wurde etwas gefunden, aber das war dann schnell behoben.

Ich habe uns bisher immer in einer respektvollen Arbeitsbeziehung gesehen – aber diese E-Mail klingt unheilvoll.

Ein Blick auf die Uhr. Das Meeting beginnt in 90 Minuten, und ich habe noch keine Ahnung, worüber Nancy reden will.

»Mist«, rufe ich aus und wecke Paige vorsichtig. »Schatz, kannst du die Kinder heute zur Schule bringen? In der Firma ist es schon wieder kritisch, die Chief Audit Executive und Steve sind mit im Boot. Ich muss noch telefonieren und pünktlich im Büro sein.«

Genervt sagt sie: »Seit zwei Jahren bringst du die Kinder donnerstags zur Schule! Ich muss heute auch früh los!«

»Es tut mir leid, Schatz. Das ist wirklich wichtig. Der CEO der Firma hat mich gebeten, mich darum zu kümmern. Steve Masters. Du weißt schon, der Kerl aus dem Fernsehen, der auch bei der Weihnachtsfeier die große Ansprache hält? Da darf nicht schon wieder so etwas wie gestern schiefgehen. Und die Zeitungsmeldungen von vorgestern ...«

Ohne ein Wort stürmt sie die Treppe hinunter.

Als ich endlich den Besprechungsraum für das Acht-Uhr-Meeting finde, bemerke ich sofort, wie ungewöhnlich still es ist. Sonst gibt es immer Small Talk, während die Teilnehmer nach und nach eintrudeln.

Nancy sitzt am einen Ende des Tischs, um sie herum vier weitere Personen. Direkt neben ihr sitzt John – wie immer mit seiner schwarzen Mappe. Und wie immer bin ich überrascht, wie jung er ist. Mit seinem dichten, lockigen, schwarzen Haar muss er Mitte dreißig sein.

Er hat einen verhärmten Blick, und wie viele Uniabsolventen hat er in den drei Jahren, die er bei Parts Unlimited ist, zugenommen. Vermutlich aufgrund des Stresses, den er mit seinem wenig erfolgreichen moralischen Feldzug hat.

John erinnert mich in diesem Moment tatsächlich sehr an Brent. Aber anders als Brent, der normalerweise ein Linux-T-Shirt trägt, hat John ein gestärktes Hemd an, das ihm ein bisschen zu groß ist.

Wes ist deutlich underdressed im Vergleich zu allen anderen hier im Raum, aber es scheint ihn nicht zu stören. Die letzte Person im Raum ist ein junger Mann, den ich nicht kenne – vermutlich der IT-Auditor.

Nancy beginnt: »Wir haben gerade unser internes Audit für Q3 als Vorbereitung für die anstehenden externen SOX-404-Audits abgeschlossen. Und dabei gibt es eine kritische Situation. Tim, unser IT-Auditor, fand eine erstaunlich große Zahl von Problemen mit IT-Sicherheitsmaßnahmen. Schlimmer noch ist, dass es sich bei vielen davon um Wiederholungstäter handelt, die schon seit drei Jahren auftauchen. Wenn wir diese Probleme nicht lösen, können sie dafür sorgen, dass die Firma zugeben muss, keine ausreichende Kontrolle über die Genauigkeit ihrer Bilanzen zu haben. Das könnte wiederum zu unschönen Kommentaren der externen Auditoren in den 10-K-Dokumenten für die US Securities and Exchange Commission führen.

Wir haben bisher zwar nur vorläufige Ergebnisse, aber aufgrund des Ernstes der Situation habe ich das Audit-Komitee schon mündlich darüber informiert.«

Ich werde bleich. Ich verstehe zwar nicht den ganzen Audit-Jargon, weiß aber genug, um zu erkennen, dass Dicks Tag damit gelaufen ist und es möglicherweise weitere schlechte Nachrichten über uns in den Zeitungen geben wird.

Zufrieden, dass ich den Ernst der Lage verstehe, nickt Nancy. »Tim, bitte stellen Sie uns Ihre Ergebnisse vor.«

Er holt einen dicken Stapel getackerte Papiere hervor und gibt jedem von uns ein Exemplar. »Wir sind gerade mit unserem Audit der IT General Controls bei Parts Unlimited für die ganzen kritischen Finanzsysteme fertig geworden. Vier Leute haben acht Wochen gebraucht, um diese Zusammenfassung zu erstellen.«

Meine Fresse. Ich hebe den dicken Stapel Papier hoch. Wo haben die einen Tacker gefunden, der das zusammenfasst?

Es handelt sich um ein ausgedrucktes Excel-Sheet, jeweils mit 20 Zeilen pro Seite in winziger Acht-Punkt-Schrift. Die letzte Seite trägt die Nummer 189. Ungläubig sage ich: »Das müssen über 1000 Punkte sein!«

»Leider ja«, antwortet Tim und kann dabei seine selbstgefällige Genugtuung nicht ganz verbergen. »Wir haben 952 IT-General-Control-Mängel gefunden, von denen 16 signifikante und 2 potenzielle wesentliche Schwachstellen sind. Das hat uns ganz offensichtlich alarmiert. Angesichts der Kürze der Zeit, die bis zum Beginn des externen Audits bleibt, brauchen wir Ihren Plan zur Nachbesserung so schnell wie möglich.«

Wes hängt gebeugt über dem Tisch, eine Hand an seiner Stirn, mit der anderen blättert er die Seiten durch. »Was für ein verdammter Mist ist das denn?«

Er hält auf einer Seite inne. »›Punkt 127. Unsichere Windows-Einstellung MAX_SYN_COOKIE‹? Soll das ein Witz sein? Falls Sie es noch nicht mitbekommen haben – wir müssen eine echte Firma am Laufen halten. Es tut mir leid, wenn das diesem Vollzeit-Audit-Geraffel in die Quere kommt.«

Auf Wes kann man sich verlassen. Er sagt die Dinge, die die Leute denken, die aber schlau genug sind, sie nicht zu sagen.

Nancy antwortet ernst: »Leider ist jetzt die Phase der Control Reviews und Tests vorbei. Wir brauchen von Ihnen den ›Management Response Letter‹. Sie müssen jeden dieser Punkte untersuchen, bestätigen und dann einen Plan zur Nachbesserung erstellen. Wir werden den dann begutachten und dem Audit-Komitee sowie dem Aufsichtsrat vorstellen. Normalerweise hätten Sie ein paar Monate Zeit dafür, Ihren Response Letter vorzubereiten und den Nachbesserungsplan umzusetzen«, fährt sie fort und hat dabei einen entschuldigenden Gesichtsausdruck. »Leider haben wir angesichts des Audit-Testplans dieses Mal nur drei Wochen, bevor die externen Auditoren eintreffen. Das ist bedauerlich. Wir werden darauf achten, IT in der nächsten Audit-Runde mehr Zeit einzuräumen. Aber dieses Mal brauchen wir Ihre Antwort bis ...«

Sie schaut in ihren Kalender. »... Montag in einer Woche – spätestens. Meinen Sie, das ist möglich?«

Oh nein.

Das sind gerade einmal sechs Arbeitstage. Wir brauchen schon drei Tage, um das ganze Dokument überhaupt zu lesen.

Unsere Auditoren, von denen ich bisher immer dachte, sie stünden für Gerechtigkeit und Objektivität, hauen uns jetzt in die Pfanne?

Ich schnappe mir auch den dicken Stapel Papier und schaue mir ein paar Seiten an. Es gibt viele Einträge wie den, den Wes vorgelesen hat, aber andere verweisen auf unpassende Sicherheitseinstellungen, das Vorhandensein von Ghost-Accounts und Probleme mit dem Change-Management oder der Funktionstrennung.

John blättert in seiner Mappe und sagt diensteifrig: »Bill, ich habe viele dieser Punkte schon bei Wes und Ihrem Vorgänger angesprochen. Sie haben den CIO überredet, einen Management Waiver abzuzeichnen, in dem steht, dass er das Risiko akzeptiert – und dann nichts getan. Wenn einige dieser Punkte jetzt unter den wiederkehrenden Problemen zu finden sind, glaube ich nicht, dass wir uns dieses Mal da rauswinden können.«

Er wendet sich Nancy zu: »Bei den vorherigen Managern waren IT Controls ganz klar nicht im Fokus, aber ich bin zuversichtlich, dass Bill dem mehr Beachtung schenken wird, wenn sich die ganzen Probleme jetzt nicht mehr verstecken lassen.«

Wes schaut John verächtlich an. Auch ich kann nicht glauben, dass sich John vor den Auditoren so produziert. In solchen Momenten frage ich mich, auf wessen Seite er steht.

Unbeirrt von Wes und mir sagt John zu Nancy: »Meine Abteilung hat ein paar andere Punkte gerade gezogen, für die wir positiv erwähnt werden sollten. So haben wir zum Beispiel das Verschlüsseln der PII in unseren kritischen Finanzsystemen abgeschlossen, sodass wir zumindest dort aus dem Schneider sind.«

Nancy sagt trocken: »Interessant. Das Vorhandensein von PII steht nicht im Fokus des SOX-404-Audits, daher wäre aus dieser Perspektive ein Konzentrieren auf die IT General Controls besser gewesen.«

Moment. Johns dringende Verschlüsselungsänderung war überflüssig?

Wenn das stimmt, müssen John und ich reden. Später.

Ich sage langsam: »Nancy, ich weiß wirklich nicht, was wir bis Freitag liefern können. Wir stecken bis zum Hals in Arbeit mit dem Wiederherstellen der Systeme und kämpfen schon damit, den anstehenden Phoenix-Roll-out zu unterstützen. Welche dieser Punkte sind die, auf die wir auf jeden Fall reagieren sollten?«

Nancy nickt Tim zu, der sagt: »Sicher. Der kritischste Punkt ist die potenzielle wesentliche Schwachstelle, die Sie auf Seite 7 finden. Dabei geht es darum, dass eine nicht genehmigte oder ungetestete Änderung an einer Anwendung für das Rechnungswesen in die produktive Umgebung gelangen kann. Das führt potenziell zu einer wesentlichen Schwachstelle –absichtlich oder ungewollt. Das Management hat keine Möglichkeit, solch eine Änderung zu erkennen oder gar zu verhindern.

Zudem sind von Ihrer Gruppe keinerlei Protokolle der Change-Management-Meetings erstellt worden, die eigentlich laut Ihrer Richtlinien wöchentlich stattfinden sollten.«

Ich versuche, mich nicht allzu deutlich zu winden, als ich daran denke, dass gestern keiner zum CAB-Meeting gekommen ist. Und während des Payroll-Problems waren wir so sehr auf Johns Verschlüsselungsänderung fokussiert, dass das SAN schließlich zerschossen war.

Wenn wir schon solche Änderungen nicht mitbekommen, bezweifle ich, dass wir es erkennen würden, wenn jemand eine Sicherung abstellt, um eine kleine betrügerische Transaktion von vielleicht 100 Millionen Dollar durchzuführen.

»Wirklich? Das ist unglaublich. Ich werde mir das genauer anschauen«, sage ich mit der hoffentlich passenden Menge an Überraschung und Empörung. Während ich so tue, als würde ich mir auf meinem Notizblock ein paar Details aufschreiben, und dabei zufällige Wörter umkreise und unterstreiche, nicke ich Tim zu, damit er fortfahren kann.

»Als Nächstes haben wir eine Reihe von Servern gefunden, bei denen Entwickler administrativen Zugriff auf produktive Anwendungen und Datenbanken haben. Das verletzt die Funktionstrennung, mit der betrügerische Vorgänge verhindert werden sollen.«

Ich schaue zu John hinüber. »Wirklich? Das ist ja ein Ding. Entwickler nehmen Änderungen an Anwendungen vor, ohne vorher eine Genehmigung dafür zu haben? Das klingt deutlich nach einem Sicherheitsrisiko. Was würde wohl passieren, wenn jemand einen Entwickler überredet, zum Beispiel Max, etwas Ungenehmigtes zu tun? Da müssen wir auf jeden Fall etwas gegen tun, oder, John?«

John wird rot, sagt aber höflich: »Ja, natürlich. Ich stimme dem zu und helfe gerne mit.«

Tim sagt: »Gut. Kommen wir nun zu den 16 signifikanten Punkten.«

Eine halbe Stunde später leiert Tim immer noch Punkte herunter. Ich starre mürrisch auf die lange Liste. Die meisten Punkte haben die gleiche Qualität wie die langen, nutzlosen Berichte, die wir von der Information Security bekommen – ein weiterer Grund, warum John einen so schlechten Ruf hat.

Das ist das unendliche Hamsterrad des Schmerzes: Die Information Security schickt Quartal für Quartal E-Mails mit langen Listen voll mit Empfehlungen zum sicheren Arbeiten.

Als Tim endlich fertig ist, meldet sich John freiwillig: »Wir müssen diese angreifbaren Systeme patchen. Mein Team hat viel Erfahrung beim Patchen von Systemen, falls Sie Unterstützung brauchen. Diese Audit-Ergebnisse sind eine tolle Gelegenheit, einige der großen Sicherheitslücken zu schließen.«

»Ihr beide habt doch gar keine Ahnung, was ihr da tun wollt!«, sagt Wes zu John und Tim – ganz offensichtlich außer sich vor Wut. »Einige der Server, auf denen diese ERP-Systeme laufen, sind schon über 20 Jahre alt. Die halbe Firma wird stillstehen, wenn sie abstürzen, und den Hersteller gibt es schon seit Ewigkeiten nicht mehr! Diese Kisten sind so fragil, dass sie schon bei einem schiefen Blick zur falschen Tageszeit abstürzen und dann mit allerlei Voodoo wieder zum Leben erweckt werden müssen. Die von euch vorgeschlagenen Änderungen würden die niemals überstehen!«

Er lehnt sich über den Tisch und deutet mit seinem Finger auf John. »Sie wollen die Systeme selbst patchen? Bitte sehr. Aber ich will ein von Ihnen unterschriebenes Dokument, in dem steht, dass Sie zu allen Werken fliegen und bei den dortigen Chefs zu Kreuze kriechen, wenn das System zum Stillstand kommt. Und gleichzeitig können Sie auch erklären, warum keiner seine Ziele erreichen wird. Okay?«

Meine Augen weiten sich vor Erstaunen, als sich John Wes’ Finger noch entgegenlehnt und empört sagt: »Oh ja? Was wäre denn, wenn wir überall in den Nachrichten sind, weil wir Kundendaten verloren haben, die wir hätten schützen müssen? Werden Sie sich dann persönlich bei den Millionen Familien entschuldigen, deren Daten an die russische Mafia verkauft wurden?«

Ich sage: »He, jetzt beruhigt sich jeder mal. Wir wollen alle das Richtige für die Firma tun. Der Trick ist, herauszufinden, wofür wir Zeit haben und welche Systeme sich tatsächlich patchen lassen.«

Ich schaue mir den Stapel Papier an. Wes, Patty und ich können ein paar Leute beauftragen, die Punkte durchzuschauen, aber wer erledigt die dann liegen bleibende Arbeit? Wir haben schon mit Phoenix zu viel um die Ohren, und ich fürchte, dass uns dieses neue große Projekt das Genick brechen wird.

Zu Nancy sage ich: »Ich werde mit meinem Team gleich loslegen, und wir werden einen Plan vorstellen. Ich kann nicht versprechen, dass wir unseren Response Letter bis dahin fertig haben, aber ich kann versprechen, dass wir alles tun, was möglich ist. Ist das ausreichend?«

»Ja, das ist es«, sagt Nancy gütlich. »Ziel dieses Meetings war nur, die vorläufigen Audit-Ergebnisse durchzugehen und die nächsten Schritte festzulegen.«

Als das Meeting zu Ende ist, bitte ich Wes, noch kurz zu warten.

John bekommt das mit und bleibt auch da. »Das ist ein Desaster. All meine Ziele und Boni hängen daran, einen sauberen Compliance-Report für die SOX-404- und PCI-Audits zu haben. Das wird dieses Jahr nicht klappen – und nur, weil ihr Ops-Leute eure Aufgaben nicht erledigt!«

»Willkommen im Klub«, sage ich.

Um ihn loszuwerden, fahre ich fort: »Sarah und Steve haben entschieden, den Deployment-Termin für Phoenix auf nächsten Freitag vorzuziehen. Sie wollen alle Sicherheits-Reviews absagen. Es ist wohl besser, wenn Sie direkt mit Chris und Sarah sprechen.«

Wie erwartet, flucht John und stürmt hinaus.

Ermattet lehne ich mich in meinem Stuhl zurück und sage zu Wes: »Das ist nicht unsere Woche.«

Wes lacht humorlos. »Ich habe dir doch gesagt, dass dir die Geschwindigkeit hier den Kopf platzen lassen wird.«

Ich zeige auf die Audit-Ergebnisse. »Wir sollen all unsere wichtigen Ressourcen für Phoenix freihalten, aber damit sind alle beschäftigt. Wir können nicht zufällig einen Haufen Leute aus dem Hut zaubern, oder?«

Wes schüttelt den Kopf, sein Gesicht ist ungewöhnlich angespannt.

Er blättert den Stapel Papier erneut durch. »Die Technologiechefs müssen auf jeden Fall dabei sein. Aber wie du schon sagst – sie sind alle mit Phoenix beschäftigt. Sollen wir hier umplanen?«

Ich weiß es ehrlich nicht. Wes starrt einen Moment auf eine der Seiten. »Ach ja, für einen ganzen Haufen dieser Punkte werden wir Brent brauchen.«

»Oh komm«, maule ich. »Brent, Brent, Brent, Brent! Können wir denn gar nichts ohne ihn machen? Schau uns an! Wir versuchen, auf Management-Ebene über Zusagen und Ressourcen zu reden, und es geht immer nur um eine Person! Es ist mir egal, wie begabt er ist. Wenn du mir sagen willst, dass unsere Organisation ohne ihn nichts auf die Reihe bekommt, haben wir echt ein Problem.«

Wes zuckt etwas verlegen seine Schultern. »Er ist ohne Zweifel einer unserer besten Leute. Er ist wirklich pfiffig und weiß viel über so gut wie alles, was wir hier einsetzen. Zudem ist er einer der wenigen, der tatsächlich versteht, wie die ganzen Anwendungen hier in der Firma untereinander in Verbindung stehen. Mann, der Kerl weiß vermutlich mehr darüber, wie diese Firma läuft, als ich.«

»Du bist ein Senior Manager. Das sollte für dich genauso inakzeptabel sein wie für mich!«, sage ich steif. »Wie viele Brents brauchst du denn mehr? Einen, zehn oder hundert? Steve muss all diese Arbeit priorisieren. Von dir muss ich wissen, welche Ressourcen wir brauchen. Wenn ich Steve nach mehr Ressourcen frage, will ich nicht erst bei euch nachhaken müssen.«

Er verdreht die Augen. »Ich werde dir erzählen, was passieren wird. Wir werden zum Management gehen und unseren Fall vorstellen. Sie werden nicht nur Nein sagen, sondern uns auch noch das Budget um fünf Prozent kürzen.

Das ist die letzten fünf Jahre passiert. Und weiterhin wird jeder alles gleichzeitig haben wollen und unsere To-do-Liste immer weiter füllen.«

Aufgeregt redet er weiter: »Und nur damit du es weißt: Ich habe schon versucht, mehr Brents einzustellen. Weil ich nie zusätzliches Budget erhalten habe, musste ich eine ganze Reihe von Positionen wegfallen lassen, um vier sehr erfahrene Entwickler einzustellen, die ähnlich gut wie Brent sind. Und weißt du, was passiert ist?«

Ich hebe fragend eine Augenbraue.

»Die Hälfte hat innerhalb von einem Jahr gekündigt, und die, die noch da sind, sind bei Weitem nicht so produktiv, wie ich es gern hätte. Ich habe zwar keine Daten, die das beweisen können, aber ich vermute, Brent ist mehr unter Wasser als je zuvor. Er beschwert sich, dass er zu viel Zeit damit verbringt, die neuen Leute zu trainieren und ihnen zu helfen. Mittlerweile ist er echt am Ende. Und gleichzeitig ist er überall dabei.«

Ich antworte: »Du sagst, dass die Leute ›unsere To-do-Liste füllen‹. Wie sieht die Liste im Moment aus? Wo kann ich eine Kopie bekommen? Wer verwaltet die Liste?«

Wes antwortet langsam: »Nun, da sind die Businessprojekte und die verschiedenen IT-Infrastrukturprojekte. Aber viele der Zusagen sind gar nicht dokumentiert.«

»Wie viele Businessprojekte? Wie viele Infrastrukturprojekte?«, frage ich.

Wes schüttelt den Kopf. »Ich weiß es nicht auswendig. Ich kann die Liste der Businessprojekte von Kirsten organisieren, aber ich bin nicht sicher, ob irgendjemand die Antwort auf deine zweite Frage kennt. Diese Projekte kommen nicht beim Projektmanagement-Büro vorbei.«

Langsam wird mir flau im Magen. Wie können wir die produktiven Systeme ordentlich betreuen, wenn wir nichts über die Anforderungen, die Prioritäten, den Arbeitsfortschritt und die verfügbaren Ressourcen wissen? Ich ärgere mich, dass ich diese Fragen nicht gleich am ersten Tag gestellt habe.

Aber endlich denke ich wie ein Manager.

Ich rufe Patty an. »Wes und ich wurden gerade vom Audit auseinandergenommen. Sie brauchen eine Reaktion bis Montag nächster Woche. Du musst mir dabei helfen, herauszufinden, was für Zusagen wir bisher gemacht haben, sodass ich eine Grundlage für ein Gespräch mit Steve über neue Ressourcen habe. Können wir uns darüber unterhalten?«

Sie sagt: »Da bin ich dabei. Kommt einfach her.«

Nachdem Wes Patty kurz über die Folgen des Mammut-Audit-Berichts unterrichtet hat, den er auf ihren Tisch fallengelassen hat, pfeift sie durch die Zähne.

»Weißt du, ich wünschte, du wärst bei dem Meeting mit den Auditoren dabei gewesen«, sage ich. »Die meisten kritischeren Punkte drehten sich darum, dass wir keinen funktionierenden Change-Management-Prozess haben. Ich glaube, du wärst zum Schluss der beste Freund der Auditoren gewesen.«

»Auditoren haben Freunde?«, lacht sie.

»Ich möchte, dass du Wes dabei hilfst, bis Montag abzuschätzen, wie viel Aufwand es bedeutet, die Audit-Punkte zu beheben«, bitte ich sie, »aber jetzt geht es erst mal um etwas anderes. Ich versuche, eine Liste mit allen Zusagen zu bekommen, die IT irgendwem in der Firma gegeben hat. Wie groß ist diese Liste, und wie wird sie gefüllt?«

Nachdem sie gehört hat, was Wes mir erzählte, antwortet Patty: »Wes hat recht. Kirsten verwaltet die offizielle Liste mit den Businessprojekten, bei denen wir fast überall irgendwie beteiligt sind. Und wir haben unsere eigenen IT Operations-Projekte, die meist von den Budget-Ownern betreut werden – dafür gibt es keine zentrale Liste.«

Patty fährt fort: »Wir haben zudem alle Anfragen an den Service Desk – egal ob es Wünsche nach etwas Neuem oder Fehlermeldungen sind. Aber diese Liste wird auch unvollständig sein, weil sich viele Kollegen lieber direkt an ihren Lieblings-ITler wenden. Das passiert alles informell.«

Ich frage langsam: »Du sagst also, dass wir keine Ahnung haben, wie die Liste mit unseren Zusagen aussieht? Wirklich?«

Wes verteidigt sich: »Bisher hat danach noch nie jemand gefragt. Wir haben immer kluge Leute eingestellt und ihnen einen bestimmten Aufgabenbereich übertragen. Darum mussten wir uns noch nicht kümmern.«

»Nun, dann müssen wir damit anfangen. Wir können nicht dauernd neue Zusagen machen, wenn wir nicht einmal wissen, was wir aktuell zu tun haben!«, sage ich. »Zuerst muss ich jetzt aber wissen, wie hoch der Aufwand ist, die Audit-Ergebnisse umzusetzen. Dann brauche ich über jeden daran Beteiligten die Information, was er sonst noch zu tun hat, von dem wir ihn dann abziehen würden.«

Ich denke einen Moment nach, dann ergänze ich: »Macht das bitte auch für alle, die mit Phoenix zu tun haben. Ich gehe davon aus, dass wir überlastet sind, aber ich will wissen, wie sehr. Ich möchte den Leuten proaktiv Bescheid sagen können, wenn wir Projekte mit ihnen stoppen müssen, damit sie dann nicht überrascht sind, wenn wir nicht liefern können.«

Sowohl Wes als auch Patty sind überrascht. Wes fängt sich als Erster: »Aber ... aber wir müssten dann ja mit so gut wie jedem reden! Patty mag ihre Freude daran haben, die Leute bezüglich ihrer Änderungspläne in die Mangel zu nehmen, aber wir können doch nicht herumlaufen und die Zeit unserer besten Leute verplempern. Die müssen arbeiten!«

»Ja, ich weiß, dass sie Arbeit zu erledigen haben«, sage ich genervt. »Ich will doch nur eine ganz kurze Beschreibung dessen, woran sie gerade arbeiten und wie lange es ihrer Meinung nach dauern wird!«

Als mir bewusst wird, wie das klingen kann, ergänze ich: »Sagt den Leuten auf jeden Fall, dass wir das machen, um mehr Ressourcen zu bekommen. Es soll keiner denken, dass wir Leute rausschmeißen oder Arbeit outsourcen wollen, okay?«

Patty nickt. »Wir sollten das schon längst mal gemacht haben. Andauernd ist ein Projekt besonders wichtig, aber wir wissen nie genau, was deswegen hinten runterfällt. Bis jemand schreit und wissen will, warum wir irgendetwas nicht liefern konnten.«

Sie tippt auf ihrem Laptop. »Du willst eine Liste mit Zusagen der IT-Organisation von unseren wichtigsten Mitarbeitern, und zwar jeweils mit einer kurzen Beschreibung, was sie gerade tun und wie lange das dauern wird. Wir werden mit den Leuten beginnen, die für Phoenix oder das Lösen der Audit-Punkte nötig sind, aber dann auch den Rest der IT-Organisation abfragen. Ist das so richtig?«

Ich lächle und freue mich, dass Patty es so gut zusammengefasst hat. Ich weiß, dass sie das richtig machen wird. »Genau. Bonuspunkte gibt es, wenn ihr zwei herausfindet, welche Ressourcen am meisten überlastet sind und wie viele neue Ressourcen wir brauchen. Das wäre die Grundlage, um Steve nach mehr Personal zu fragen.«

Patty sagt zu Wes: »Das sollte recht einfach sein. Wir können 15-minütige Gespräche aufsetzen, Daten aus unserem Service-Desk- und Ticket-System ziehen, die Projektliste von Kirsten organisieren ...«

Überraschenderweise stimmt Wes zu und ergänzt: »Wir könnten auch in unsere Budget-Tools schauen, um herauszufinden, was für Personal- und Hardwareanforderungen wir gestellt haben.«

Ich stehe auf. »Super, Leute. Setzt ein Meeting auf, in dem ihr mir erzählt, was ihr herausgefunden habt. Nicht später als Freitag. Ich will am Montag zu Steve gehen und brauche dafür echte Daten.«

Patty gibt mir ein »Daumen hoch«. Jetzt kommen wir voran.

KAPITEL 6

Freitag, 5. September

In einem der vielen endlosen Phoenix-Status-Meetings stelle ich fest, dass die Entwickler noch viel weiter hinterherhängen, als wir sowieso schon befürchtet haben. Wie Wes vorausgesagt hat: Mehr und mehr Punkte werden auf das nächste Release verschoben – einschließlich fast aller Tests.

Wir werden also diejenigen sein, die die Probleme feststellen werden, wenn sie uns im Produktivbetrieb um die Ohren fliegen, und nicht die Quality-Assurance-(QA-)Abteilung. Super.

Während einer Meeting-Pause werfe ich einen Blick auf mein Handy und sehe eine E-Mail von Patty. Sie will sich mit mir wegen der Ressourcen treffen und verspricht einige Überraschungen.

Ich öffne das angehängte Spreadsheet und sehe eine vielversprechende Menge an Details, kann aber auf meinem winzigen Bildschirm nichts erkennen. Also antworte ich Patty, dass ich schon auf dem Weg bin und sie doch Wes dazubitten soll.

Als ich ankomme, bin ich überrascht, dass Wes schon einen Projektor aufgebaut hat, der ein Spreadsheet an die Wand wirft. Ich freue mich, dass wir uns endlich treffen können, um die Situation zu analysieren, statt immer nur tagtäglich Feuer zu löschen.

Ich schnappe mir einen Stuhl. »Okay, was könnt ihr mir erzählen?«

Wes beginnt: »Patty hat das alles super zusammengestellt. Was wir herausgefunden haben, ist – nun ja, interessant.«

Patty erklärt: »Wir haben Gespräche geführt, Daten eingesammelt und dann unsere Analyse durchgeführt. Bisher haben wir die Ergebnisse nur für unsere wichtigsten Ressourcen. Aber wir sehen schon einige unerfreuliche Dinge.«

Sie zeigt auf eine Zeile im Spreadsheet. »Wir haben einen Haufen Projekte. Kirsten sagt, sie verwaltet offiziell etwa 35 größere Businessprojekte, bei denen wir auf die eine oder andere Art und Weise beteiligt sind. Innerhalb von IT Operations haben wir schon über 70 Projekte erfasst, aber die Zahl wächst mit jeder Person weiter, mit der wir uns unterhalten.«

»Moment«, sage ich erschrocken und setze mich in meinem Stuhl gerade auf. »Wir haben 150 Mitarbeiter in IT Operations, oder? Wenn ihr schon über 105 Projekte gefunden habt, sind das 1,5 Personen pro Projekt. Erscheint euch das nicht zu viel?« Wes antwortet: »Natürlich. Und wir wissen, dass da noch mehr Projekte hinzukommen werden. Am Ende reden wir vermutlich über eine Person pro Projekt. Das ist Wahnsinn.«

Ich frage: »Wie groß sind diese internen Projekte?«

Wes wechselt auf einen anderen Tab und zeigt die Liste der erfassten Projekte zusammen mit der Zahl der geschätzten Mann-Wochen. »E-Mail-Server zusammenfassen und aktualisieren«, »35 Instanzen von Oracle-Datenbanken aktualisieren«, »Lemming-Datenbank-Server installieren«, »Wichtigste Businessanwendungen virtualisieren und migrieren« und so weiter.

Ich stöhne. Einige Projekte sind zwar klein, aber bei den meisten scheint es um größere Aktionen zu gehen – geschätzt drei Mann-Jahre und mehr.

Als Patty meinen Gesichtsausdruck sieht, sagt sie: »So habe ich auch reagiert. Wir haben es mit sehr vielen Projekten zu tun. Schauen wir uns jetzt mal an, wie viele Ressourcen wir haben. Das ist ein bisschen schwieriger, da wir einem Projekt nicht irgendwelche Leute zuweisen können.«

Sie fährt fort: »Wir haben uns angeschaut, wer welchem Projekt zugeordnet ist und wie es mit deren anderen Verpflichtungen und der Verfügbarkeit aussieht. Das ist unser Ergebnis.«

Als Wes zu einem weiteren Spreadsheet-Tab wechselt, sinkt mir das Herz in die Hose.

»Bitter, oder?«, sagt Wes. »Die meisten unserer Ressourcen sind mit Phoenix beschäftigt. Schau dir aber die nächste Zeile an: Compliance ist das zweitgrößte Projekt. Und selbst wenn wir nur an der Compliance arbeiteten, würde das die meisten unserer wichtigen Ressourcen für ein ganzes Jahr beschäftigen! Und natürlich gehört dort Brent dazu.«

Skeptisch sage ich: »Ihr macht Witze, oder? Wenn wir all unsere Projekte auf Eis legen und nur die Audit-Ergebnisse umsetzen würden, wären unsere wichtigsten Leute für ein ganzes Jahr gebunden?«

»Jepp«, sagt Patty nickend. »Schwer zu glauben, aber es zeigt, wie viel Arbeit in den Audit-Ergebnissen steckt.«

Ich starre sprachlos auf den Tisch.

Wenn mir jemand diese Daten während meines ersten Gesprächs mit Steve gezeigt hätte, wäre ich schreiend aus dem Raum gerannt. Es ist noch nicht zu spät, denke ich grinsend, als ich mir dies bildlich vorstelle.

Mit der mir mittlerweile angewöhnten Ruhe sage ich: »Okay, Wissen ist immer besser als Nichtwissen. Erzählt weiter.«

Wes schaut wieder auf das Spreadsheet. »Das drittgrößte Thema ist die Arbeit an Problemen und das Beheben von Pannen. Aktuell verbringen unsere Mitarbeiten etwa 75 Prozent ihrer Zeit damit. Und weil es dabei häufig um kritische Businesssysteme geht, müssen solche Zwischenfälle auch immer der Arbeit an anderen Dingen vorgezogen werden – einschließlich Phoenix und dem Abarbeiten der Audit-Ergebnisse.

Wusstest du übrigens, dass wir gestern, als wir uns mit Brent unterhielten, das Gespräch zwei Mal verschoben haben, weil er bei kritischen Problemen eingreifen musste? Wir haben ihn also bei seiner Arbeit für Phoenix unterbrochen, nur um selbst durch Ausfälle unterbrochen zu werden!«, sagt er lachend.

Ich beginne ebenfalls zu lachen, höre aber abrupt auf. »Moment. Welchen Ausfall? Warum habe ich davon nichts gehört? Wir können unsere Abteilung so nicht leiten!«

»Ach, mal wieder ein SAN-Problem, aber nichts Kritisches«, antwortet Wes. »Vor ein paar Monaten ist ein Laufwerk ausgefallen, sodass das SAN ohne Redundanz lief. Als ein weiteres Laufwerk kaputtging, wurde das gesamte Volume heruntergefahren. Brent musste dabei helfen, ein paar der Datenbanken wiederherzustellen, als wir das SAN wieder zum Laufen brachten.«

Verärgert rufe ich: »Verdammt, Wes. Das hätte man doch verhindern können! Schnapp dir einen deiner Neueinsteiger und lass ihn jeden Tag die Logs nach Laufwerkfehlern durchsuchen. Vielleicht wirft er gleichzeitig direkt einen Blick auf die Laufwerke und schaut, ob alle noch schön blinken. Das heißt nicht umsonst ›Präventive Wartung‹! Wir brauchen Brent bei Phoenix, nicht bei so mickerigem Scheiß wie dem!«

Wes sagt verteidigend: »Hey, es ist schon ein wenig komplizierter, als du denkst. Wir haben die Bestellung der Ersatzlaufwerke eingereicht, aber sie steckt seit Wochen in der Beschaffungsabteilung fest. Wir mussten schließlich einen unserer Lieferanten anbetteln, dass er uns die Laufwerke sozusagen auf Kredit gibt. Das war nicht unser Fehler.«

Ich verliere die Geduld. »Wes, hör mir zu: ES INTERESSIERT MICH NICHT! Das Beschaffungswesen ist mir egal. Mir ist auch egal, wie lieb ihr zum Lieferanten sein musstet. Ich will, dass ihr eure Arbeit erledigt. Sorg dafür, dass das nicht wieder passiert!«

Ich atme tief durch. Mein Frust kommt nicht von dem defekten Laufwerk, sondern weil wir uns nie auf die Dinge konzentrieren können, die für die Firma am wichtigsten sind.

»Lasst uns das jetzt nicht weiter vertiefen«, sage ich zu Wes. »Aber das mit der täglichen Kontrolle des SAN meine ich ernst. Setze bitte nächste Woche ein Meeting auf, bei dem du, Patty und ich uns den Grund für diese Ausfälle anschauen. Wir müssen sehen, wie wir diese Feuerwehrarbeiten so weit reduzieren, dass wir uns um die eigentliche Projektarbeit kümmern können. Wenn Phoenix nicht läuft, ist die ganze Firma gefährdet.«

»Ja, das habe ich verstanden. Ich werde versuchen, das noch vor dem Phoenix-Roll-out auf die Reihe zu bekommen«, sagt Wes mürrisch. »Und das mit der SAN-Kontrolle kläre ich heute Nachmittag.« »Gut, zurück zum Spreadsheet«, sage ich.

Patty beobachtet uns verdrießlich. »Du hast recht. Das zog sich durch alle Gespräche wie ein roter Faden. Keiner schafft es, in Ruhe an seinen Projekten zu arbeiten. Und selbst wenn sie Zeit haben, hadern sie damit, all ihre Verpflichtungen richtig zu priorisieren. Die Businessleute bitten ja andauernd unsere Leute, irgendetwas für sie zu erledigen. Vor allem das Marketing.«

»Sarah?«, frage ich.

»Sicher, aber nicht nur sie«, antwortet Patty. »So gut wie jeder Manager in dieser Firma schaut mehr oder weniger häufig bei seinem Lieblings-IT-Mitarbeiter vorbei – entweder um ihn um einen Gefallen zu bitten oder um Druck auszuüben, damit etwas erledigt wird.«

»Wie können wir das denn ändern, und was brauchen wir, damit all diese Projekte ordentlich abgearbeitet werden?«, frage ich. »Worum sollten wir Steve bitten?«

Wes scrollt in seinem Spreadsheet nach unten. »Ausgehend von den Zahlen, die wir bisher haben, werden wir wohl sieben neue Mitarbeiter brauchen: drei Datenbankadministratoren, zwei Servertechniker, einen Netzwerktechniker und einen Virtualisierungsspezialisten. Dir ist natürlich klar, dass wir diese Leute erst einmal finden müssen und dass es dann sechs bis zwölf Monate dauert, bis sie voll produktiv eingesetzt werden können.«

Natürlich. Ich wusste, dass neue Mitarbeiter nicht sofort voll produktiv sind. Aber trotzdem ist es entmutigend, wenn Wes betont, dass echte Hilfe erst in einiger Zeit zu erwarten ist – selbst wenn Steve die neuen Positionen genehmigt.

Als ich später zu unserem zweiten CAB-Meeting gehe, bin ich hoffnungsfroh. Wenn wir unseren alten Change-Prozess wieder zum Leben erwecken können, sollten wir dazu in der Lage sein, eines der größten Audit-Probleme schnell zu lösen, und gleichzeitig auch selbst etwas davon haben.

Ich bin zudem begeistert davon, wie gut Patty und Wes zusammenarbeiten.

Als ich mich dem Besprechungsraum nähere, höre ich laute Stimmen.

»... und dann hat Patty ihn dafür gefeuert, dass er seinen Job gemacht hat. Er war einer unserer besten Netzwerktechniker. Du hattest das nicht zu entscheiden!«

Kein Irrtum möglich. Da tobt sich Wes aus. Dann höre ich, wie Patty hitzig antwortet: »Was? Du hast die Kündigung doch unterschrieben! Warum ist das jetzt plötzlich meine Schuld?«

Es wäre ja auch zu schön gewesen.

Ich höre John sagen: »Das war der richtige Schritt. Wir haben jetzt seit drei Jahren bei den Audits die gleichen Probleme mit dem Change-Management. Das landet dieses Mal beim Audit-Komitee. Und beim nächsten Mal ist es vermutlich nicht nur ein Techniker, der gefeuert wird, wenn Sie mich fragen.«

Was? Wer hat John zu diesem Meeting eingeladen?

Bevor John alles noch schlimmer machen kann, trete ich schnell durch die Tür und sage fröhlich: »Hallo, alle zusammen! Und? Können wir uns ein paar Changes anschauen?«

14 Personen schauen mich an. Die meisten technischen Leiter der verschiedenen Gruppen sitzen am Tisch. Wes steht vor Wut schäumend hinter seinem Stuhl, während Patty vor dem Beamer steht und die Arme verschränkt hat.

John sitzt weiter hinten im Raum, seine allgegenwärtige Mappe geöffnet und ganz offensichtlich eigentlich unerwünscht.

Mit beiden Händen setze ich meinen antiken Laptop ab. Er landet etwas hart auf dem Tisch, und der Akku löst sich, weil das Tape nicht mehr länger klebt. Dann höre ich das kratzende Geräusch einer herunterfahrenden Festplatte.

Wes’ verärgerter Gesichtsausdruck ist sofort verschwunden. »Wow, Boss, nette Kiste. Was ist das? Ein Kaypro II? So etwas habe ich ja seit 30 Jahren nicht mehr gesehen. Falls du ein 8-Inch-Diskettenlaufwerk benötigen solltest, um CP/M auf dem Rechner zu starten – ich habe noch eines auf dem Dachboden liegen.«

Zwei der Entwickler kichern ebenfalls. Ich lächle Wes kurz an und bin dankbar für die Ablenkung.

Ich bleibe stehen und sage zu allen: »Ich will euch erklären, warum ich alle herbeordert habe. Angesichts der Dringlichkeit von Phoenix könnt ihr euren Hintern darauf verwetten, dass ich keine Zeit verschwenden würde, wenn es nicht so wichtig wäre.«

Ich fahre fort: »Erstens dürfen solche Aktionen wie die vom Dienstag, die zum SAN-Ausfall und zum Payroll-Problem geführt haben, so nicht wieder vorkommen. Was als mittelschwerer Payroll-Zwischenfall begann, führte zu einer massiven, selbst gemachten SAN-Katastrophe. Und warum? Weil wir nicht miteinander darüber reden, was für Änderungen wir planen oder umsetzen. Das können wir nicht weiter hinnehmen.

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ß und Tränen in unsere alte Change-Management-Richtlinie gesteckt, und alle haben sie ignoriert. Warum glaubst du, dass es dieses Mal anders sein wird?«

Ich zucke mit den Schultern. »Keine Ahnung. Aber wir werden so lange Vorgehensweisen ausprobieren, bis wir ein funktionierendes System haben. Und ich werde sicherstellen, dass uns dabei jeder hilft. Es geht nicht nur darum, die Auditoren glücklich zu machen. Wir brauchen einen Weg, unsere Änderungen sicher zu planen, zu kommunizieren und umzusetzen. Ich garantiere dir, dass ich meinen Job nicht mehr lange haben werde, wenn wir unsere Arbeitsweise nicht bald ändern.«

Patty zeigt auf ihr Dokument mit der alten Richtlinie und sagt: »Wir sollten die ganze Arbeit nicht aus dem Fenster werfen. Wir haben Wochen damit verbracht, sie zu entwerfen, und Hunderttausende Dollar für Berater ausgegeben, die unsere Tools angepasst haben.«

Sie ist fast den Tränen nahe. Ich erinnere mich, wie lange sie versucht hat, diesen Prozess in der Firma umzusetzen.

»Ich weiß, dass in diesem Prozess viele gute Ideen und viel Arbeit stecken«, sage ich mitfühlend. »Aber seien wir ehrlich. Keiner folgt ihm, wie uns die Auditoren gerade erst wieder deutlich gemacht haben. Wir wissen zudem, dass die Leute das System missbraucht haben, um ihre Arbeit zu erledigen.«

Aufrichtig sage ich: »Wir fangen vielleicht neu an, aber wir brauchen deine Erfahrung und deine Kenntnisse, damit es funktioniert. Es ist immer noch dein Prozess, und ich weiß, dass er für den Erfolg unserer Firma unabdingbar ist.«

»Okay«, sagt sie seufzend. »Ich denke, ich sollte mir mehr Gedanken darum machen, dass unsere Firma überlebt, als darüber, ob wir unseren alten Prozess nutzen oder nicht.«

Ihr Gesichtsausdruck ändert sich. »Wie wäre es, wenn ich die Ergebnisse dieses Meetings und die neuen Anweisungen für das Einreichen von Change Requests aufschreibe?«

Später am Nachmittag bin ich zurück im Phoenix War Room, als mich Patty anruft. Ich gehe in den Flur. »Was gibt es?«

Sie klingt angespannt. »Wir haben ein Problem. Ich dachte, wir müssten nächste Woche 50 Änderungen oder so begutachten. Aber wir sind schon bei 243 eingereichten Änderungen. Ich bekomme E-Mails von Leuten, die mir für das Wochenende noch mehr Karten versprechen ... Ich glaube, wir werden bei über 400 Änderungen für nächste Woche landen!«

Oh nein. 400? Wie viele dieser 400 Änderungen sind hoch risikoreich, betreffen potenziell Phoenix, die Payroll-Anwendung oder Schlimmeres?

Ich erinnere mich plötzlich an meine Arbeit als Rangemaster bei den Marines. Als Rangemaster war ich für die Sicherheit aller Personen auf dem Schießstand verantwortlich. Ich habe eine albtraumhafte Vision eines Mobs von 400 unbeaufsichtigten Achtzehnjährigen, die von den Lastwagen springen, zum Schießstand rennen und johlend und grölend mit ihren Gewehren in die Luft feuern ...

»Ähm, zumindest folgen die Leute dem Prozess«, sage ich nervös kichernd.

Ich höre sie lachen. »Wie wollen wir die ganzen Change Requests am Montag genehmigen, wenn noch so viele eintrudeln? Sollen wir vielleicht weitere Änderungen verbieten, bis wir alle abgearbeitet haben?«

»Auf keinen Fall«, sage ich sofort. »Du treibst den Leuten ihre Begeisterung und ihre Unterstützung aus, wenn du ihnen das verbietest, was sie tun müssen. Ich glaube nicht, dass wir hier eine zweite Chance haben.

Verschicke eine E-Mail an alle, dass Änderungen für nächste Woche bis Montag eingereicht werden müssen. Die Änderungen, die am Montag laufen sollen, müssen nicht genehmigt werden, aber die für den Rest der Woche schon. Ohne Ausnahme.«

Ich höre, wie Patty anfängt zu tippen. »Okay, habe ich. Ich werde wohl ein paar Leute brauchen, die mir über das Wochenende dabei helfen, die ganzen Karten zu organisieren. Ehrlich, ich bin erstaunt, wie viele Änderungen es gibt.«

Das bin ich auch.

»Ausgezeichnet«, sage ich und lasse meine Bedenken unausgesprochen.

KAPITEL 7

Freitag, 5. September

Gerade als ich zurück an meinem Schreibtisch bin und nach einer Kopfschmerztablette suche, klingelt mein Telefon. »Palmer hier«, sage ich, während ich die Schubladen durchwühle.

»Hallo Bill, hier ist Stacy – Steves Assistentin. Ich bin froh, Sie zu erwischen. Es gibt ein potenzielles neues Aufsichtsratsmitglied namens Erik Reid, das mit allen IT-Verantwortlichen reden will. Hätten Sie jetzt ein Stündchen für ihn Zeit?«

»Moment, ich schaue mal in meinen Kalender«, antworte ich.

Die Bildschirmauflösung dieses alten Laptops ist so niedrig, dass die Wochenansicht unbenutzbar ist. Ich wechsle zur Tagesansicht, aber der Bildschirm bleibt leer, während der Laptop klappert und brummt.

Ich gebe auf und sage: »Ich weiß, es ist wichtig, aber kann das nicht bis Montag warten? Sie glauben nicht, was hier heute abging.«

Sie antwortet schnell: »Ich wünschte, es könnte warten, aber Erik ist nur heute hier. Und so wie ich das sehe, sind Bob Strauss – Sie wissen schon, der neue Vorstandsvorsitzende – und Steve in heller Aufruhr, weil sie Angst haben, dass er unser Angebot nicht annehmen wird. Er scheint offensichtlich ein ziemliches Technologie-Genie zu sein, und Bob und Steve haben es irgendwie geschafft, ihn zu uns zu locken, um ihn zu umwerben. Er besteht darauf, die IT-Führungsriege kennenzulernen, bevor er wieder fährt.

»Okay, ich komme«, sage ich und unterdrücke ein Seufzen.

»Super. Er sitzt in dem Besprechungsraum direkt bei mir. Kommen Sie rüber – es gibt richtig guten Kaffee und Donuts.«

Ich lache. »Na, das sind die ersten guten Neuigkeiten, die ich heute erfahre. Ich bin unterwegs.«

Als ich zum Besprechungsraum in Gebäude 2 gehe und Stacy zuwinke, grüble ich über die verrückte Welt, in die ich gezogen wurde. Ich bin es eigentlich nicht gewohnt, in das Politikgeplänkel des Vorstands verstrickt zu werden.

Wie versprochen, sehe ich durch das Fenster ein großes Wägelchen mit vier Sorten Kaffee und sechs Boxen Vandal Donuts – ein Laden, der hier so bekannt ist, dass man fast immer eine lange Schlange davor findet.

Ein Mann in zerknitterten Kakihosen und heraushängendem Baumwollhemd kniet vor dem Wagen und verteilt die Donuts auf zwei Teller. Ich wusste gar nicht, dass Vandal Donuts auch einen Lieferservice hat.

Ich schnappe mir eine Tasse und gieße Kaffee hinein, während ich die Donuts begutachte. Dann sage ich: »Wissen Sie, meine Frau und ich sind große Fans von Ihnen. Als wir uns kennenlernten, standen wir fast jeden Freitagabend 20 Minuten an, um unseren Schuss zu bekommen. Jetzt haben wir Kinder, und ich werde losgeschickt, welche für sie zu holen. Vielleicht nehme ich heute einen mit nach Hause.«

Ich nehme mir einen großen Schoko-Donut, der mit Froot Loops bestreut ist, dazu einen gigantischen glasierten Donut mit Schinken sowie drei weitere, die sehr schmackhaft erscheinen.

Der Liefermensch steht auf und sieht mich lächelnd an. »Ja, ich verstehe, warum. Ich mag diese Donuts sehr. Ich hatte noch nie vergleichbare. Seit ich hier bin, habe ich bestimmt schon fünf Stück gegessen. Das kollidiert leider mit meiner Low-Carb-Diät, die ich eigentlich mache, aber ...«

Er hält mir seine Hand hin und sagt: »Ich bin Erik.«

Na super.

Ich schaue an mir herunter. In der einen Hand halte ich den Kaffee, in der anderen einen mit Donuts überladenen Teller.

»Ach du je«, sage ich hastig. Ich stelle alles auf dem Tisch hinter mir ab, drehe mich wieder zu ihm um und schüttle seine Hand. »Schön, Sie zu treffen. Ich bin Bill – Bill Palmer.«

Ich schaue ihn mir nochmals an. Er hat einen Schnurrbart, ist etwa 1 Meter 80 groß, etwas übergewichtig und hat langes graues Haar, das ihm bis auf die Schultern reicht. Im Stehen sieht er einem Mitarbeiter eines Lieferservice noch ähnlicher als einem potenziellen Aufsichtsratsmitglied – und vor allem sieht er nicht aus wie ein »Technologie-Genie«.

Ein weiterer Blick auf ihn lässt mich meine Meinung ändern – ich bin ziemlich sicher, dass ein Liefermitarbeiter weniger zerknitterte Kleidung tragen würde.

»Keine Sorge«, sagt er lächelnd, während er sich einen weiteren Donut nimmt und zum Tisch weist. »Setzen Sie sich. Ich wollte gern mit jedem der IT-Leiter reden, während ich hier bin. Natürlich musste ich mit Steve reden und mit ... ähm, wie heißt noch mal Ihr CFO? Darren? Dale? Wie auch immer – das scheinen nette Jungs zu sein. Vielleicht ein bisschen blauäugig, aber ...«

Er gestikuliert geringschätzig. »Ich habe auch mit Ihrem Entwicklungsmenschen gesprochen. Ähm, Cary? Calvin? Und dann mit Ihrem Sicherheitschef Jimmy und Ihrer Retailing-Dame Sylvia.«

Ich versuche meinen gequälten Gesichtsausdruck zu verbergen, weil er wirklich alle Namen durcheinanderbringt.

»Okay ... und wie ist Ihr Eindruck bisher?«, frage ich vorsichtig. Er hört auf zu kauen, streicht sich ein paar Krümel aus seinem Bart und überlegt. »Es sieht so aus, als ob Sie in einer Welt des Schmerzes leben. IT Operations hat sich irgendwie bei jedem wichtigeren Arbeitsablauf mit ins Boot manövriert, auch in die wichtigsten Firmenprojekte. Alle Executives springen im Dreieck und legen den Entwicklern die Daumenschrauben an, damit alles getan wird, was nötig ist, um produktiv gehen zu können.«

Er sieht mir in die Augen. »Sie haben chronische Probleme mit der Verfügbarkeit der IT und sorgen dafür, dass Firmenverantwortliche auf den Titelseiten der Zeitungen auftauchen – und zwar nicht mit positiven Nachrichten. Und jetzt ist Ihnen das Audit-Team auf den Fersen, was zu weiteren schlechten Nachrichten führen kann und vielleicht sogar zu einer unschönen Fußnote im Geschäftsbericht. Und jeder, der irgendetwas von Phoenix mitbekommen hat, weiß, dass da noch viel mehr schlechte Nachrichten am Horizont auftauchen werden ...«

Während er redet, merke ich, wie ich immer roter im Gesicht werde – ob aus Wut oder Verlegenheit, kann ich nicht genau sagen.

»Es sieht nicht so gut für Sie aus«, sagt er. »Zumindest nicht aus Sicht eines potenziellen Aufsichtsratsmitglieds, das Ihre Leistung begutachten und bewerten soll.«

Ich schürze meine Lippen und widerstehe dem Drang, etwas zu sagen, das defensiv klingen kann. Neutral antworte ich: »Steve hat mich vor drei Tagen gebeten, diesen Job anzunehmen. Ich habe zwar Nein gesagt, aber er hat mich überzeugt. Da warten sicherlich noch einige Überraschungen auf mich ...«

Er sieht mich für einen Moment an und bricht dann in schallendes Gelächter aus. »Ganz bestimmt!«, sagt er entwaffnend. »Haha, Überraschungen. Also, wie sieht Ihr Plan aus? Wie wollen Sie das Schiff wieder aufrichten?«

Ich überlege einen Moment, wie ich am besten formuliere, was ich in dieser Woche schon angestoßen habe. Dann antworte ich: »Ehrlich gesagt, versuche ich immer noch, mir einen Überblick zu verschaffen. Meist taumele ich von einem Notfall zum nächsten. Ich weiß, dass wir bei unserer Arbeit strenger und disziplinierter vorgehen müssen. Auch versuche ich, herauszufinden, auf welchen Prozessen wir aufbauen, um die Arbeit zu erledigen. Angesichts dessen, was ich bisher gesehen habe, müssen wir sie verbessern, damit wir uns nicht dauernd selbst ins Knie schießen.«

Ich denke nochmals kurz nach. »Das alles, damit wir endlich vom reinen Feuerlöschen wegkommen. Ich kämpfe immer noch damit, ein überraschend aufgetauchtes Projekt zum Abarbeiten der Audit-Ergebnisse mit Mitarbeitern besetzen zu können. Soweit ich das sehe, sind wir mit unseren Zusagen ebenfalls weit ins Hintertreffen geraten. Wir brauchen offensichtlich mehr Leute oder müssen viel effizienter werden, um all die zugesagte Arbeit auch erledigen zu können.«

Erik runzelt die Stirn. »›Strenger und disziplinierter‹? Ich vermute, Sie waren Unteroffizier beim Militär. Ein E-6. Nein, dafür sind Sie zu jung. Ein E-5, stimmt’s?«

Ich blinzle ihn überrascht an. »Das stimmt. E-5, US Marine Corp. Woher wussten Sie das?«

»Ein Schuss ins Blaue«, antwortet er. »Unter anderem auch deshalb, weil Sie nicht wie ein Chemiker oder Auditor aussehen.«

»Was?«, frage ich.

»Sie haben recht. Sie können die Strategie nicht umsetzen, wenn Sie noch mit der Taktik kämpfen«, sagt er und ignoriert meine Frage. »Aber was bei den Marines funktioniert hat, wird hier nie klappen, wenn man sich anschaut, wie dieser Zirkus geleitet wird. Statt eines General in der Befehlskette haben Sie hier zehn Generäle, die alle direkte Befehlsgewalt auf die Gefreiten ausüben.«

Ich sage langsam: »Moment. Sie sagen, Strenge und Disziplin sind unwichtig?«

»Natürlich sind sie wichtig«, sagt er ernst. »Aber Ihr Problem ist viel größer, und es hat nichts mit Ihrem Getue rund um ›Effizienz‹ und ›Prozess‹ zu tun. Ihr aktuelles Problem ist, dass Sie offensichtlich nicht wissen, was ›Arbeit‹ ist.«

Ich starre ihn an.

Was ist das denn für ein Clown? Einen kurzen Moment frage ich mich, ob ich Wes oder Patty bitten soll, sich mit ihm zu befassen, aber Steve wollte offensichtlich, dass ich mich persönlich um ihn kümmere.

»Ich weiß, was Arbeit ist«, sage ich langsam. »Wir erledigen sie jeden Tag. Wenn wir nicht dafür sorgen, dass die Systeme laufen und die Businessanforderungen umgesetzt werden, bin ich schnell weg vom Fenster.«

»Was ist dann genau Ihre Definition von ›Arbeit‹?«, fragt er neugierig.

»Nun, Steve hat mir wiederholt unmissverständlich klargemacht, dass wir Phoenix endlich zum Laufen bekommen müssen. Für mich ist das Arbeit.«

Er sieht an die Decke und scheint mit sich selbst zu reden. »Ja, das ist sicherlich eine Art von Arbeit. Aber es fehlen noch drei weitere Arten, für die IT Operations verantwortlich ist. Für mich sind Sie noch weit weg von einem Verständnis von Arbeit, das Sie benötigen, um Ihre Probleme mit Projekt-Deliverables, Ausfällen und Compliance zu lösen.«

Er steht auf. »Schnappen Sie sich Ihre Sachen. Wir werden einen kleinen Ausflug machen.«

Verwirrt und verärgert schaue ich auf meine Uhr. 16:17. Ich habe eigentlich zu viel zu tun, um meine Zeit mit diesem Kerl zu verplempern.

Dann ist er plötzlich weg. Ich schaue in den Flur, aber dort ist er auch nicht zu finden. Ich sehe Stacy fragend an, und sie zeigt auf den Fahrstuhl. Ich laufe und kann ihn gerade noch einholen.

Er ist schon in den Fahrstuhl getreten und hält mir die Tür auf. »Sie bekommen es vermutlich nicht mit, wenn Ihrer Gruppe Arbeit zugewiesen wird. Und wenn Sie das nicht sehen, können Sie die Arbeit auch nicht managen – geschweige denn organisieren, in eine Reihenfolge bringen oder irgendeine Sicherheit haben, dass Ihre Ressourcen das auch schaffen.«

Ich runzle die Stirn und denke an mein letztes Meeting mit Wes und Patty, als sie keine Liste der Verpflichtungen liefern konnten. Ich sage: »Was soll das hier sein? Irgendeine Art von Intelligenztest?«

»Ja, das könnte man so sehen«, antwortet er. »Aber keine Sorge, es geht nicht nur um Sie. Steve muss seinen Intelligenztest ebenso bestehen. Und Dick natürlich auch.« Ich folge ihm zu seinem blauen, kleinen Mietwagen, und wir fahren fünf Minuten zu MRP-8, einer der Fabrikhallen. Sie ist sehr groß – vermutlich viermal so groß wie unser Gebäude –, aber in erstklassigem Zustand und anscheinend erst vor Kurzem generalüberholt.

Eine fast sechzigjährige Wachfrau begrüßt uns: »Hallo, Dr. Reid. Schön, Sie zu sehen! Wie geht es Ihnen? Das ist ja schon ganz schön lange her.«

Erik schüttelt ihr freundlich die Hand und antwortet: »Es ist schön, Sie mal wieder zu sehen, Dorothy. Wir wollen uns nur mal einen Überblick über die Fabrikhalle verschaffen. Können wir noch auf den Laufsteg hinauf?«

Mit kokettem Lächeln antwortet sie: »Normalerweise ist er gesperrt, aber ich denke, für Sie kann ich eine Ausnahme machen.«

Ich schaue Erik misstrauisch an. Erst konnte er sich anscheinend keinen einzigen Namen merken, und jetzt erinnert er sich sogar an den einer Wachfrau, die er vor Jahren das letzte Mal gesehen hat? Und niemand hat je etwas von einem Dr. Reid erzählt.

Nachdem wir fünf Treppen hinaufgestiegen sind, stehen wir auf einem Laufsteg, von dem aus man einen Blick über die gesamte Fabrikhalle hat, die fast zwei Straßenblöcke groß ist.

»Schauen Sie hier runter«, sagt Erik. »Sie sehen auf beiden Seiten des Gebäudes Laderampen. Die Ausgangsmaterialien kommen hier an, während die fertigen Produkte auf der anderen Seite weggeschafft werden. Die Bestellungen kommen aus dem Drucker dort hinten. Wenn Sie hier lang genug beobachten, können Sie sehen, wie all die WIPs, also ›Work in Process‹, ›Ware in Arbeit‹ oder – für Fertigungsneulinge – ›Umlaufbestände‹ von einem Ende der Halle zur anderen wandern, von wo aus sie als fertige Produkte an die Kunden geliefert werden.

Jahrzehntelang gab es in diesem Gebäude«, fährt er fort, »überall Stapel mit halb fertigen Waren. Die waren manchmal so hoch, dass sie nur mit den großen Gabelstaplern wie denen da drüben bewegt werden konnten. An manchen Tagen war es nicht einmal möglich, von einem Ende der Halle zum anderen zu schauen. Im Nachhinein wissen wir jetzt, dass WIP eine der Hauptursachen für chronische Probleme mit den Lieferterminen und der Qualität ist. Zudem muss der Disponent die Prioritäten tagtäglich neu anpassen. Erstaunlich, dass die Firma das trotzdem überstanden hat.«

Er weist mit seinen breit ausgestreckten Armen auf die Halle. »In den 1980ern wurden in dieser Halle drei neue unglaubliche Management-Trends umgesetzt. Sie haben vermutlich schon davon gehört: die Theory of Constraints oder Engpasstheorie, die Lean Production oder das Toyota Production System und das Total Quality Management. Auch wenn alle diese Trends aus verschiedenen Ecken der Management-Theorien stammen, sind sie sich doch in einem einig: WIP ist der stillschweigende Killer. Daher ist einer der wichtigsten Mechanismen beim Managen jeder Fertigungsanlage die Arbeits- und Materialfreigabe. Ohne sie haben Sie die WIP nicht im Griff.«

Er zeigt auf einen Schreibtisch in der Nähe der Laderampen. »Sehen Sie diesen Schreibtisch?«

Ich nicke, schaue aber auch deutlich auf meine Uhr: 16:45 Uhr.

Von meiner Ungeduld unbeirrt fährt Erik fort: »Lassen Sie mich Ihnen eine Geschichte erzählen. Vor vielen Jahren gab es einen Kollegen namens Mark. Er war der Vorarbeiter für diesen Arbeitsbereich dort unten. In dem Regal da lagen die Mappen für die eintreffenden Arbeitsaufträge. Ist es nicht irre, dass diese Mappen immer noch so aussehen wie vor Jahrzehnten?«

»Auf jeden Fall«, setzt er seine Ausführungen fort, »habe ich eines Tages gesehen, wie sich Mark eine Mappe nahm, um einen Auftrag zu beginnen. Ich frage ihn: ›Warum haben Sie gerade diesen Auftrag genommen und nicht einen der anderen?‹

Und wissen Sie, was er mir sagt? Er sagt: ›Das ist ein Auftrag, der hier bearbeitet werden muss. Und wir haben gerade Zeit dafür.‹«

Erik schüttelt ungläubig den Kopf. »Ich konnte es kaum fassen. Also sage ich ihm: ›Ihre Arbeitsstation ist die erste von 20, die das Werkstück danach noch bearbeiten müssen. Berücksichtigen Sie nicht die Verfügbarkeit der anderen 19 bei Ihrer Entscheidung?‹ Und er antwortet: ›Nein. So mache ich es schon seit 20 Jahren.‹«

Er lacht. »Ich denke, für ihn war das durchaus eine vernünftige Entscheidungsgrundlage. Er sorgt dafür, dass die erste Arbeitsstation beschäftigt bleibt – so wie beim First In/First Out. Aber natürlich weiß heute jeder, dass man die Arbeit nicht abhängig von der Verfügbarkeit der ersten Station auswählt. Stattdessen sollte das Tempo entscheiden, mit der die Station ihre Arbeit erledigen kann, die der Engpass im Produktionsablauf ist.«

Ich starre ihn ausdruckslos an.

Er fährt fort: »Aufgrund der Art und Weise, wie Mark die Arbeitsaufträge auswählte, stapelte sich die WIP vor unserem Engpass, und die Aufträge wurden nie rechtzeitig fertig. Jeden Tag gab es einen Notfall. Wir waren jahrelang ›Kunde des Jahres‹ der Luftfrachtfirma, weil wir immer wieder Tausende fertiggestellter Produkte über Nacht an wütende Kunden ausliefern mussten.«

Er macht eine Pause und sagt dann nachdrücklich: »Eliyahu M. Goldratt, der die Theory of Constraints entwickelte, hat uns gezeigt, dass alle Verbesserungen, die nicht den Engpass betreffen, nur eine Illusion sind. Unglaublich, aber wahr! Jede Verbesserung, die nach dem Engpass vorgenommen wird, ist nutzlos, weil sie nicht ausgelastet werden kann. Und jede Verbesserung vor dem Engpass führt nur zu noch mehr halb fertigen Produkten, die sich davor stapeln.

In unserem Fall war der Engpass ein Härtungsofen – genau wie in Goldratts Buch Das Ziel. Wir hatten auch Trockenkabinen für den Lack, die später zu Engpässen wurden. Als wir das Bearbeiten neuer Arbeitsaufträge stoppten, konnte die Arbeitsstation, die für den Engpass sorgte, aufgrund der um sie herumgestapelten Teile schon nicht mehr gesehen werden – selbst von hier oben nicht!«

Obwohl ich nicht will, lache ich mit ihm. Rückblickend betrachtet, liegt das Problem auf der Hand, aber ich kann mir vorstellen, dass es für Mark zu dem Zeitpunkt nicht so deutlich zu sehen war. »Vielen Dank für diese Geschichtsstunde. Aber das meiste davon habe ich schon im Studium gelernt. Ich kann auch nicht erkennen, wie dies möglicherweise für das Managen von IT Operations dienlich ist. IT lässt sich nicht wie eine Werkshalle führen.«

»Wirklich nicht?«, wendet er sich mir zu und runzelt die Stirn. »Lassen Sie mich raten. Sie werden jetzt sagen, dass es bei IT nur um reine Wissensarbeit geht und die ganze Arbeit eher künstlerisch ist. Daher gibt es keinen Raum für Standardisierung, dokumentierte Arbeitsabläufe und all das großspurige ›Strenge und Disziplin‹, das Ihnen doch so lieb und teuer ist.«

Ich bin unsicher und weiß nicht, ob er mich von etwas überzeugen will, dem ich schon folge, oder ob er mich dazu bringen will, eine absurde Schlussfolgerung zu akzeptieren.

»Wenn Sie glauben, dass IT Operations nichts von Plant Operations lernen kann, liegen Sie falsch. Völlig falsch«, sagt er. »Ihr Job als VP of IT Operations ist, den schnellen, verlässlichen und ununterbrochenen Fluss der geplanten Aufgaben sicherzustellen, der die Businessbereiche unterstützt und dabei den Einfluss und die Unterbrechungen durch ungeplante Arbeiten minimiert, sodass Sie stabile, verlässliche und sichere IT-Services bieten können.«

Während ich ihm zuhöre, frage ich mich, ob ich mir das aufschreiben sollte.

Er schaut mich genauer an. »Ich sehe, wir sind für dieses Gespräch noch nicht bereit. Bis Sie kein besseres Verständnis dafür haben, was Arbeit ist, würde jede Unterhaltung über das Steuern von Arbeit Verschwendung sein. Es wäre so, als würde man sich mit jemandem über das Jonglieren unterhalten, der nicht an die Gravitation glaubt.

Seien Sie aber versichert«, sagt er und zeigt auf den Schreibtisch für die Arbeitsaufträge, »um das zu erreichen, was Sie wollen, muss Ihnen schließlich klar werden, was Ihr Äquivalent zu diesem Schreibtisch ist. Sie müssen herausfinden, wie Sie Arbeitsaufträge in IT Operations steuern, und – was noch wichtiger ist – sicherstellen, dass die Ressourcen, die bei Ihnen den größten Engpass bilden, nur die Arbeit tun, die dem gesamten System dient statt nur einem Silo.

Wenn Sie das erkannt haben, junger Bill, sind Sie auf dem richtigen Pfad zum Verständnis der Drei Wege«, sagt er. »Der Erste Weg lässt uns verstehen, wie wir für einen zügigen Arbeitsfluss von der Entwicklung nach IT Operations sorgen, denn das steht zwischen uns und dem Kunden. Der Zweite Weg zeigt uns, wie wir schneller und besser Rückmeldungen erhalten, um Qualitätsprobleme an ihrer Quelle zu beheben und zu vermeiden, Arbeit mehrfach machen zu müssen. Und der Dritte Weg zeigt uns, wie wir eine Kultur aufbauen, in der man experimentieren kann, aus Fehlern lernt und versteht, dass Wiederholung und Übung die Voraussetzungen für den Weg zum Meister sind.«

Auch wenn er jetzt verdächtig nach Meister Shifu aus dem Film Kung Fu Panda klingt, höre ich interessiert zu. Die Notwendigkeit von Strenge und Disziplin sowie das kontinuierliche Üben und Verbessern unserer Fähigkeiten sind wichtige Lektionen, die ich bei den Marines gelernt habe. Während dort das Leben meiner Männer davon abhing, ist es hier mein Job. Das Aufbauen dieser Verlässlichkeit ist das, was ich meiner IT Operations-Gruppe am dringendsten einimpfen will.

Erik übergibt mir einen Zettel mit einer Telefonnummer. »Denken Sie daran, es gibt vier Arten von Arbeit. Sie haben die Arbeit an Businessprojekten als eine aufgeführt. Wenn Sie auch die anderen drei herausgefunden haben, rufen Sie mich an.«

Er nimmt seine Autoschlüssel aus der Tasche und fragt: »Soll ich Sie zurück ins Büro fahren?«

Als ich endlich zurück in meinem Büro bin, ist es 17:10 Uhr. Ich melde mich wieder am Laptop an, um auf E-Mails zu antworten. Aber ich kann mich nicht konzentrieren.

Diese Stunde mit Erik war wie in einem seltsamen Paralleluniversum. Oder wie das Betrachten eines psychedelischen Films, den jemand im Drogenrausch gedreht hat.

Was hat Erik damit gemeint, dass es vier Arten von Arbeit gibt?

Ich denke an mein Meeting mit Wes und Patty zurück. Wes beschrieb, dass es getrennte Listen für IT-Infrastrukturprojekte und für Businessprojekte gibt. Sind Infrastrukturprojekte eine andere Art von Arbeit?

Während ich darüber grüble, taucht ein E-Mail-Benachrichtigungsfenster auf meinem Bildschirm auf und weist mich darauf hin, dass ich wohl eine weitere Mail beantworten muss.

Sind E-Mails eine andere Art von Arbeit?

Das bezweifle ich. In der Fabrikhalle hat Erik auf den gesamten Raum verwiesen. Als er von »Arbeit« sprach, schien er die auf Organisationsebene zu meinen, nicht die Tätigkeit auf der Ebene eines einzelnen Arbeiters oder Managers.

Ich denke weiter darüber nach. Dann schüttle ich den Kopf und schicke eine kurze Mail an Steve, um ihn wissen zu lassen, dass ich mich mit Erik getroffen habe. Ich bin ziemlich sicher, dass ich noch in zehn Jahren meinen Freunden von meinem kurzen Zusammentreffen mit dem langhaarigen Irren hoch über der Fabrikanlage erzählen werde.

Ich muss sehen, dass ich fertig werde. Paige wird ernsthaft sauer sein, wenn ich an einem Freitag zu spät nach Hause komme. Als ich den Laptop aus der Dockingstation nehme, durchschneidet ein nervenzerreißendes Piepen die Luft.

»Ach du Scheiße!«, rufe ich, als ich feststelle, dass das Piepen aus meinem Laptop kommt. Hektisch versuche ich, die Lautstärke herunterzuregeln oder ihn auszuschalten, aber er piept weiter.

Verzweifelt drehe ich den Laptop um, um den Akku herauszunehmen, aber das Tape ist wieder so stabil, dass er bleibt, wo er ist. Ich schnappe mir einen Brieföffner und schaffe es, das Tape zu durchtrennen und den Akku zu entfernen.

Endlich tritt Stille ein.

KAPITEL 8

Montag, 8. September

Das ganze Wochenende habe ich damit verbracht, an der PowerPoint-Präsentation zu arbeiten, die ich für mein Meeting mit Steve an diesem Morgen benötige. Trotz der ganzen Arbeit wünschte ich mir, ich hätte mich besser vorbereiten können.

Ich zwinge mich, zu entspannen, indem ich mir vorstelle, eine angenehme und lebhafte objektive Diskussion mit ihm zu führen und mit dem gewünschten Ergebnis herauszukommen. Immer wieder erinnere ich mich selbst daran, wie wichtig das für die Firma und meine Abteilung ist. Alle haben hart daran gearbeitet, die Daten für dieses Treffen zusammenzustellen, und jetzt hängen Erfolg oder Misserfolg davon ab, wie gut ich das Steve präsentieren kann.

Als ich eintreffe, lächelt mich Stacy an und sagt freundlich: »Gehen Sie schon hinein. Es tut mir leid, dass wir Ihnen nur 30 Minuten freimachen konnten.«

In der Tür bleibe ich abrupt stehen, denn Sarah sitzt mit Steve am Tisch zusammen. Sie erzählt ihm gerade: »... Sie haben das toll gemacht, als Sie beschrieben haben, was unser Ziel ist. Das waren ein paar der kritischsten Analysten, aber auch die sind jetzt überzeugt. Sie haben denen auch noch einen Grund gegeben, wieder mit uns zu sprechen, wenn Phoenix live geht. Zudem scheinen sie von der Phoenix-Roadmap sehr beeindruckt zu sein.«

Sie erzählen den Analysten von der Phoenix-Roadmap? Bei so vielen Features, die ins nächste Release verschoben wurden, frage ich mich, wie klug es ist, Versprechen an den Markt zu geben, die eventuell nicht gehalten werden können.

Steve nickt nur und antwortet glücklich: »Schauen wir mal, ob das ihren Eindruck von uns verbessert. Gut, dass Sie diese Telefonkonferenz aufgesetzt haben. Wir sehen uns ja später noch mal für die nächste Runde.«

Sarah lächelt mich an und sagt: »Hey, Bill. Sie sind heute aber früh auf, oder?«

Ich knirsche mit den Zähnen und ignoriere ihren Kommentar. »Guten Morgen zusammen.« Interesse heuchelnd, sage ich: »Scheint, als ob Sie ein gutes Telefonat hatten.«

Sarah lächelt noch breiter. »Ja, sie sind von unserer Vision ausgesprochen begeistert und meinen, dass das für uns die Wende bringen könnte. So werden wir auch anders vom Markt und der Wall Street wahrgenommen.«

Ich schaue sie ruhig an und frage mich, ob solche Briefings an Analysten und Journalisten die Ursache für den Druck auf Chris’ Team sind, Features viel zu voreilig zu veröffentlichen.

Ich schnappe mir einen Stuhl gegenüber von Steve. So richtig kann ich Sarah nicht den Rücken zukehren, aber ich tue mein Bestes.

Steve soll meine Handouts nicht bekommen, solange Sarah noch im Raum ist, aber sie redet weiter mit ihm, geht nochmals das Meeting durch und überlegt, wie man beim nächsten noch besser vorgehen kann.

Während sie sich unterhalten, kann ich nur daran denken, dass sie mir meine Zeit stiehlt.

Elf Minuten später lacht Steve über einen Witz von Sarah, und sie verlässt endlich das Büro. Steve wendet sich mir zu und sagt: »Es tut mir leid, dass es länger gedauert hat. Unser nächstes Analysten-Briefing zu Phoenix ist schon in 20 Minuten. Also, worum geht es Ihnen?«

»Sie haben mir von Anfang an klargemacht, dass ich vor allem Phoenix unterstützen muss. Der erfolgreiche Roll-out sollte mit allen Mitteln erreicht werden«, beginne ich. »Ausgehend von meinen Beobachtungen der letzten Woche, sieht es sehr eng aus – sogar so eng, dass Phoenix meiner Meinung nach in ernsthafter Gefahr ist.

Ich habe meine Leute zusammenstellen lassen, wie die Anforderungen an uns wirklich aussehen und wie viel Kapazität wir haben«, fahre ich fort. »Wir haben alles erfasst, was wir tun sollen – egal wie groß oder klein die Aufgabe ist. Basierend auf unseren bisherigen Analysen ist für mich klar, dass die Anforderungen an IT deutlich größer sind als die uns zur Verfügung stehenden Ressourcen. Ich habe mir auch zusammenstellen lassen, was an Aufgaben ansteht, damit wir besser entscheiden können, wer wann an was arbeiten sollte.«

So gewichtig wie möglich sage ich: »Eine Sache ist sehr deutlich. Wir sind definitiv unterbesetzt. Ich sehe keine Möglichkeit, all das auszuliefern, was wir versprochen haben. Entweder müssen wir die Projektliste zusammenstreichen oder Personal einstellen.«

Ich fahre fort und versuche, die vernünftigen und logischen Argumente zu wiederholen, an denen ich das ganze Wochenende gearbeitet habe. »Das andere große Problem ist, dass wir zu viele verschiedene Projekte haben, die um unsere Aufmerksamkeit buhlen. Sie haben deutlich gemacht, dass Phoenix am wichtigsten ist, aber wir scheinen keine Ressourcen exklusiv dafür abstellen zu können. So hat uns zum Beispiel letzten Dienstag das interne Audit-Team eine Reihe von Erkenntnissen geliefert, auf die wir innerhalb von einer Woche eine vernünftige Antwort liefern müssen. Auch das hat Einfluss auf Phoenix.«

Während meines Vortrags habe ich Steve beobachtet, aber bisher ist sein Gesicht ausdruckslos. Ich schaue ihn gefasst an und frage: »Ich würde in diesem Meeting gerne verstehen, wie Phoenix gegenüber den Audit-Ergebnissen priorisiert wird, was wir mit der hohen Zahl von Projekten machen wollen und wie wir sie mit ausreichend Personal versorgen.«

In meiner Vorstellung habe ich mich als kompetenter und engagierter Manager gezeigt, der sich nicht sicher ist, wie er den Businessabteilungen am besten helfen kann, ohne moralische Wertungen zu treffen.

Steve antwortet verärgert: »Was für eine Bullshit-Frage ist das zur Priorisierung? Wenn ich zum Aufsichtsrat ginge und denen erzählen würde, dass ich entweder nur Sales oder nur Marketing machen könnte und sie mir helfen sollten, mich zu entscheiden, würden die mich aus der Sitzung werfen. Ich muss beides tun – so wie Sie beides tun müssen! Das Leben ist hart. Phoenix ist das wichtigste Projekt für die Firma, aber das heißt nicht, dass Sie das SOX-404-Audit als Geisel nehmen könnten.«

Ich zähle bis drei, bevor ich sage: »Ich war offensichtlich nicht klar genug. Sowohl Phoenix als auch das Compliance-Projekt brauchen bestimmte zentrale Ressourcen, wie zum Beispiel Brent. Das Compliance-Projekt alleine würde diese Personen schon ein Jahr lang beschäftigen, aber sie sollen sich ja auf Phoenix konzentrieren. Dazu kommt, dass unsere Infrastruktur so fragil ist, dass wir täglich Ausfälle haben, für die häufig die gleichen Ressourcen benötigt werden, um die Systeme wieder zum Laufen zu bekommen. Wenn es heute einen ähnlichen Ausfall wie beim Payroll-Lauf gäbe, müsste Brent vermutlich bei Phoenix und dem Compliance-Projekt zurückstecken, um herauszufinden, was da schiefgegangen ist.«

Ich schaue ihn geradeheraus an und sage: »Wir haben uns verschiedene Möglichkeiten zum Verbessern der Ressourcenlage angeschaut, das Einstellen und Versetzen von Leuten eingeschlossen, aber keine davon wird schnell genug einen merklichen Effekt haben. Wenn Phoenix wirklich oberste Priorität hat, müssen wir einen Teil der Compliance-Aufgaben hintenanstellen.«

»Das kommt nicht in Frage«, sagt er, bevor ich weiterreden kann. »Ich habe diesen dicken Stapel mit Audit-Ergebnissen gesehen, und wir werden echte Probleme bekommen, wenn wir uns nicht um diese Punkte kümmern.«

Das läuft definitiv nicht so, wie ich mir das vorgestellt habe. »Okay«, sage ich langsam. »Wir werden unser Bestes geben, aber fürs Protokoll: Wir haben definitiv zu wenig Leute, um eines der Projekte sauber zu bearbeiten – geschweige denn beide Projekte.«

Ich warte darauf, dass er reagiert. Sekunden vergehen, bis er schließlich nickt.

Mehr werde ich vermutlich nicht bekommen, daher zeige ich auf die erste Seite des Handouts, das ich ihm gegeben habe. Ich sage: »Gut, dann schauen wir uns vielleicht die Projektbelastung und unsere Kapazitäten an. Aktuell unterstützen wir 35 Businessprojekte über Kirstens Projektmanagement-Büro und über 70 kleinere Businessprojekte und interne Initiativen. Dazu kommen weitere, die wir noch nicht zusammengefasst haben. Mit unseren 143 IT-Mitarbeitern werden wir davon nichts wie versprochen erledigen können.«

Ich zeige auf die zweite Seite des Handouts und sage: »Wie Sie sehen, sind mein Team und ich zu der Schlussfolgerung gekommen, dass wir sechs weitere Ressourcen benötigen, um die dringlichsten Lücken zu füllen.«

Zum Schluss kommend, sage ich: »Mein Ziel ist, unseren Durchsatz so zu steigern, dass wir nicht wieder in solch eine Situation geraten, und so viele Projekte abzuschließen, wie wir können. Ich würde von Ihnen gerne die Zusage haben, diese Stellen sofort ausschreiben zu können, damit wir mit der Suche beginnen. Talente wie Brent sind nicht leicht zu finden, und wir müssen eher früher als später beginnen.«

Bei meinen Proben war das der Moment, in dem Steve sich meine Diagramme genauer anschaut, ein paar Fragen stellt und wir eine vernünftige Diskussion über einen guten Kompromiss führen. Vielleicht würde er mir sogar auf die Schulter klopfen und mich für die Qualität meiner Analyse beglückwünschen.

Aber Steve nimmt meine Handouts nicht einmal in die Hand. Stattdessen sieht er mich an und sagt: »Bill, Phoenix ist schon zehn Millionen Dollar über seinem Budget, und wir müssen möglichst bald Geld hereinbekommen. Sie haben in Ihrem Team ein paar der teuersten Ressourcen der ganzen Firma. Da müssen Sie leider mit auskommen.«

Er verschränkt die Arme vor seiner Brust und fährt fort: »Letztes Jahr sind ein paar IT-Analysten da gewesen und haben unsere Firma mit anderen Firmen verglichen. Die haben uns erzählt, dass wir viel mehr für IT ausgeben als unsere Konkurrenten.

Sie denken vielleicht, dass bei 3000 Mitarbeitern sechs weitere sicher nichts ausmachen. Aber glauben Sie mir: Jede Ausgabe wird genau unter die Lupe genommen. Wenn ich die Firma nicht wieder profitabel bekomme, wird es weitere Entlassungen geben. Und weitere zwei Millionen Dollar Personalkosten sind da nicht hilfreich.«

Er fährt verständnisvoller fort: »Mein Vorschlag? Gehen Sie zu den anderen VPs und stellen Sie ihnen Ihr Problem vor. Wenn die das genauso kritisch sehen wie Sie, sollten sie einen Teil ihres Budgets für Sie abknapsen können. Aber eins möchte ich klarstellen: Eine Erhöhung des Budgets steht nicht zur Diskussion. Es kann sogar sein, dass wir auch in Ihrem Bereich kürzen müssen.«

Ich habe Stunden damit verbracht, mir im Rollenspiel Worst-Case-Szenarien vorzustellen. Anscheinend muss ich noch pessimistischer werden.

»Steve, ich weiß nicht, wie ich hier noch deutlicher werden kann«, sage ich ein bisschen verzweifelt. »Wir sind keine Zauberer. All die Aufgaben, die uns die verschiedenen Abteilungen zuteilen, müssen von echten Menschen erledigt werden. Verpflichtungen wie das Compliance-Thema sind uns aufgehalst worden, ohne zu berücksichtigen, woran die Leute schon arbeiten – zum Beispiel an Phoenix.«

Ich merke, dass ich nicht viel zu verlieren habe. Um ihm eventuell per Schock klarzumachen, was auf dem Spiel steht, sage ich: »Wenn Sie wirklich die Konkurrenz wieder einholen wollen, indem Sie Phoenix zu einem Erfolg machen, dann muss ich sagen: Sie handeln nicht danach. Für mich sieht es so aus, als ob Sie zu spät zu einer Schießerei kommen und dann nur ein Messer dabeihaben.«

Ich erwarte irgendeine Reaktion, aber er lehnt sich nur zurück und verschränkt erneut seine Arme. »Wir tun alle unser Bestes. Gehen Sie also am besten zurück an Ihre Arbeit und machen Sie das auch.«

Just in diesem Moment öffnet sich die Tür, und Sarah kommt herein. »Hi Steve. Entschuldigen Sie die Störung, aber die nächste Telefonkonferenz mit Analysten beginnt in zwei Minuten. Soll ich uns einwählen?« Scheiße. Ich schaue auf meine Uhr. 9:27.

Sie hat mir sogar am Ende noch drei Minuten gestohlen.

Endgültig geschlagen sage ich: »Okay, verstanden. Weiter Druck machen. Ich werde Sie auf dem Laufenden halten.«

Steve nickt dankbar und wendet sich dann Sarah zu, während ich die Tür hinter mir schließe. Auf dem Weg nach draußen schmeiße ich die Präsentation, an der ich das ganze Wochenende gearbeitet habe, in Stacys Mülleimer.

Ich versuche, den üblen Geruch des Versagens loszuwerden, als ich zum Change Advisory Board-Meeting gehe. Während ich darüber nachdenke, wie ich Wes und Patty die schlechten Neuigkeiten beibringe, betrete ich den Besprechungsraum, den Patty zum Change Coordination Room auserkoren hat.

Alle Gedanken an Steve sind auf der Stelle verschwunden, als ich aufblicke.

Die Wände sind vollständig mit Whiteboards vollgestellt. An zwei Wänden bedecken Karteikarten nahezu jeden freien Fleck. Und die Karten hängen nicht immer einzeln – mit Büroklammern verbunden hängen manchmal bis zu zehn Karten aneinander.

Auf dem Tisch in der Mitte des Raums sind 20 oder 30 weitere Kartenstapel.

Auf der anderen Seite des Tischs sind zwei Mitarbeiter von Patty mit einer Karte beschäftigt. Nachdem sie sie gelesen haben, befestigen sie die Karte zwischen zwei anderen Karten vor ihnen am Whiteboard.

»Meine Fresse«, sage ich.

»Wir haben ein Problem«, sagt Patty hinter mir.

»Kein Platz mehr für weitere Whiteboards?«, frage ich halb im Spaß. Bevor Patty antworten kann, höre ich, wie Wes den Raum betritt. »Ach du Scheiße!«, sagt er. »Wo kommen alle diese Karten her? Sind die alle für diese Woche?«

Ich drehe mich zu ihm um. »Überrascht? Die meisten kommen aus deiner Gruppe.«

Er schaut sich die Boards an und dann die Karten auf dem Tisch. »Ich wusste ja, dass meine Leute ziemlich viel zu tun haben, aber ... das müssen ja ein paar Hundert Änderungen sein.«

Patty dreht ihren Laptop, um uns das gerade offene Spreadsheet zu zeigen. »Seit Freitagnachmittag wurden für diese Woche 437 Änderungen eingereicht.«

Wes ist erst einmal sprachlos. Schließlich schüttelt er den Kopf und sagt: »Und jetzt sollen wir die alle durchgehen und genehmigen? Das Meeting soll doch nur eine Stunde dauern – aber dafür brauchen wir Tage!«

Er sieht mich an. »Bill, ich sage ja nicht, dass wir das nicht machen sollten, aber wenn wir da jede Woche durch müssen ...«

Erneut verstummt Wes, überwältigt von der vor uns liegenden Aufgabe.

Ehrlich gesagt, sehe ich das genauso. All die Manager dazu zu bekommen, ihre Änderungen einzureichen, war anscheinend nur der erste Schritt. Ich hatte nicht erwartet, dass uns der Prozess um die Ohren fliegen würde, wenn es über das Einsammeln der Daten hinaus zum Autorisieren der Änderungen käme.

Ich zwinge mich, fröhlich zu sagen: »Das ist ein toller Anfang. Wie meistens wird es erst schlimmer, bevor es besser wird. Wir haben eine super Unterstützung durch die technischen Leiter, also müssen wir uns jetzt Gedanken machen, wie wir diese Änderungen regelmäßig untersuchen und einplanen können. Irgendwelche Vorschläge?«

Patty spricht als Erste. »Na ja, keiner hat gesagt, dass wir all diese Änderungen durchgehen müssen – vielleicht können wir ein paar davon an andere delegieren.«

Ich verfolge erst einmal, wie Wes und Patty Ideen abwägen, bevor ich mich einmische. »Lasst uns wieder an unsere Ziele denken: Die linke und die rechte Hand sollen wissen, was die jeweils andere tut, wir wollen mehr über die Ursachen für die Ausfälle wissen, und das Audit-Team soll sehen, dass wir uns um die Change-Koordination kümmern.

Wir müssen uns auf die kritischsten Änderungen konzentrieren«, fahre ich fort. »Die 80/20-Regel gilt vermutlich auch hier: 20 Prozent der Änderungen sorgen für 80 Prozent der Risiken.«

Ich starre die Kartenstapel vor mir an und nehme mir ein paar, um mich inspirieren zu lassen.

Eine Karte mit einem großen, traurigen Smiley darauf halte ich hoch und frage: »Was ist PUCCAR?«

»Ach, diese nutzlose App«, sagt Wes angewidert, »ist die Check Clearing and Reconciliation-Anwendung, die irgendjemand vor fast zwei Jahrzehnten geschrieben hat. Wir nennen sie ›Sucker‹, weil sie uns jedes Mal, wenn wir etwas an ihr ändern, um die Ohren fliegt und keiner weiß, wie man die Fehler behebt. Der Hersteller ist damals in der Dotcom-Blase pleite gegangen, aber wir haben nie Budget dafür bekommen, sie zu ersetzen.« Ich frage: »Wenn wir wissen, dass sie so instabil ist – warum müssen wir sie dann ändern?«

Wes antwortet: »Das versuchen wir ja auch zu vermeiden. Aber manchmal ändern sich die Gesetze oder die Vereinbarungen zwischen den Firmen, und dann müssen wir sie eben anpassen. Sie läuft zudem noch auf einem Betriebssystem, das schon lange nicht mehr unterstützt wird, daher ist das Ganze noch heikler ...«

»Gut! Das ist eine kritische Änderung. Was für Änderungen sind noch eingereicht worden, die so sind wie PUCCAR?«, frage ich.

Wir bilden einen Stapel aus fast 50 Karten mit Änderungen an den Rainbow-, Saturn- und Taser-Anwendungen sowie mit Anpassungen am Netzwerk und an bestimmten Datenbanken, die einen merklichen Teil des Businessbereichs – oder sogar alle – beeinträchtigen könnten.

»Schon ein Blick auf diese Karten lässt mich erschaudern«, sagt Wes. »Da sind ein paar ganz schön gefährliche Änderungen bei.«

Er hat recht. Ich sage: »Okay, markieren wir alle diese Karten als ›kritisch‹. Das sind Hochrisikoänderungen, und die müssen vom CAB genehmigt werden. Patty, solche Änderungen sollten bei unseren Meetings immer ganz oben liegen.«

Patty nickt und macht sich Notizen. »Gut, habe ich. Wir definieren Hochrisikokategorien für Änderungen, die nicht nur eingereicht, sondern auch autorisiert werden müssen, bevor sie eingeplant und umgesetzt werden.«

Wir erstellen zügig eine Liste der zehn fragilsten Services, Anwendungen und Infrastrukturelemente. Alle Change Requests, die eines der Objekte auf der Liste betreffen, müssen auf jeden Fall vom CAB begutachtet werden.

Patty fügt hinzu: »Wir müssen für diese Änderungen ein paar Standardprozeduren entwerfen – zum Beispiel wann sie zu implementieren sind –, und die relevanten Mitarbeiter müssen nicht nur darüber Bescheid wissen, sondern auch erreichbar sein, falls etwas schiefgeht. Notfalls müssen wir die Hersteller ansprechen können.«

Sie fügt mit einem verhaltenen Lächeln hinzu: »Ihr wisst schon, wie bei einer Notlandung auf einem Flughafen, wo Feuerwehr und Rettungsdienst bereitstehen, um notfalls einen Schaumteppich aufbringen zu können.«

Wes lacht und ergänzt ironisch: »Genau, und bei PUCCAR brauchen wir auch gleich einen Bestatter, der ein paar Body Bags bereithält. Und den Pressesprecher, der die Anrufe aus dem Business abwimmelt, wo sich die Leute beschweren, weil sie allergisch auf den Schaum reagieren.«

Ich lache. »Das ist echt eine interessante Idee. Lassen wir doch das Business den Schaum aussuchen. Es gibt keinen Grund, warum die ganze Verantwortung auf unseren Schultern liegen sollte. Wir können eine E-Mail an die Businessabteilungen schicken und im Voraus nach dem besten Implementierungszeitpunkt fragen. Wenn wir ihnen dazu noch mitteilen, was die Änderungen für Folgen haben werden, ziehen sie sie vielleicht sogar zurück.«

Patty schreibt alles mit. »Habe ich auch. Für solche Änderungen werde ich meine Mitarbeiter Auswertungen erstellen lassen, wie es mit der Erfolgsrate und den zugehörigen Downtimes aussieht. Dann können die Businessabteilungen bessere Entscheidungen treffen.«

Ich bin von Pattys Idee ausgesprochen angetan und zuversichtlich, dass wir auf dem richtigen Weg sind. »Okay, damit bleiben aber immer noch 400 Karten übrig. Weitere Ideen?«

Wes ist die Karten methodisch durchgegangen und hat zwei große Stapel vor sich aufgehäuft. Er nimmt sich eine vom größeren Stapel. »In diesem Stapel sind alle Änderungen, die wir immer wieder machen. Zum Beispiel diese zum monatlichen Upload der Steuertabelle in die POS-Systeme. Ich denke nicht, dass wir eine dieser Änderungen ablehnen sollten.

Auf dem anderen Stapel finden sich hingegen Änderungen wie ›Thread Pool Size des Java Application Server erhöhen‹, ›Kumquat-Hotfix des Herstellers installieren, um Performanceprobleme zu beheben‹ oder ›Load Balancer des Kentucky Data Center auf Standard-Duplex zurücksetzen‹«.

»Aber was zum Henker kann ich darüber sagen?«, fährt Wes fort. »Ich kann mir da keine Meinung bilden, weil ich zu wenig über die Situation weiß. Ich will nicht wie eine Möwe sein – anfliegen, die Leute ärgern und wieder wegfliegen.«

Begeistert sagt Patty: »Ausgezeichnet! Die ersten sind die Änderungen mit geringem Risiko, die von ITIL als ›Standard-Changes‹ bezeichnet werden. Änderungen, die wir schon viele Male erfolgreich durchgeführt haben, brauchen nicht genehmigt zu werden. Wir wollen darüber Bescheid wissen, aber sie können ohne uns eingeplant werden.«

Als jeder nickt, fährt sie fort: »Damit bleiben über 200 Änderungen mit mittlerem Risiko, die wir uns trotzdem anschauen müssen.«

»Ich stimme Wes zu«, sage ich. »Bei denen müssen wir darauf vertrauen, dass der Manager weiß, was er tut. Aber Patty, kannst du darauf achten, dass die Leute vorher alle informieren, die betroffen sein könnten, und sich von ihnen ein Okay holen?«

Ich denke einen Moment nach und sage dann: »Nehmen wir doch mal Johns Verschlüsselungsanwendung. Bevor der Change Request zu uns kommen muss, reicht es doch, dass er sich die Zustimmung der Anwendungs- und Datenbankverantwortlichen holt – und auch vom Business. Ich sehe unsere Rolle eher darin, sicherzustellen, dass er sich um die Details kümmert. Mir ist die Integrität des Prozesses wichtiger als die eigentlichen Änderungen.«

Patty schreibt alles mit. »Mal sehen, ob ich alles richtig mitbekommen habe: Für die Änderungen mit mittlerem Risiko entscheiden wir, dass der Einreichende dafür verantwortlich ist, die potenziell betroffenen Leute zu kontaktieren und deren Zustimmung zu erhalten. Ist das erledigt, reichen sie ihre Change-Karte bei uns ein, damit wir sie begutachten und einplanen.«

Ich lächle und sage: »Genau. Ist das in Ordnung, Wes?«

Er überlegt und antwortet dann: »Ich denke, das wird funktionieren. Versuchen wir es.«

»Gut«, sage ich. Dann wende ich mich an Patty. »Kannst du versuchen, dafür zu sorgen, dass die Einreicher auch wirklich ihre Hausaufgaben erledigen?«

Patty grinst und sagt: »Aber sicher doch.«

Sie schaut nachdenklich auf das Whiteboard und tippt mit ihrem Stift auf den Tisch. »Heute ist Montag. Wir haben schon gesagt, dass die für heute eingeplanten Änderungen automatisch genehmigt sind. Ich schlage vor, die Generalamnestie bis morgen zu verlängern und am Mittwoch wieder ein komplettes CAB-Meeting einzuberufen, um dann die restlichen Änderungen zu planen. Damit sollte jeder ausreichend Zeit zur Vorbereitung haben.«

Ich schaue Wes an. Er sagt: »Das ist gut, aber ich denke schon an nächste Woche. Wir sollten alle bitten, weiter Change Requests einzureichen und die wöchentlichen CAB-Meetings wieder ab Freitag, den 19., aufsetzen.«

Patty ist genauso freudig überrascht wie ich, dass Wes schon für die nächste Woche plant, statt nur zu meckern. »Ich werde in den nächsten Stunden entsprechende Mails verschicken.«

Nachdem sie sich das notiert hat, fügt sie hinzu: »Noch etwas. Ich möchte darauf hinweisen, dass aktuell zwei Personen und ich selbst komplett damit beschäftigt sind, diesen Prozess manuell laufen zu lassen. Das ist ausgesprochen aufwendig. Wir werden uns etwas überlegen müssen, um ihn zu automatisieren.«

Ich nicke. »Das ist ohne Zweifel so nicht auf Dauer fortführbar. Aber lasst uns noch ein paar CAB-Meetings Erfahrung sammeln, bis wir sicher sind, wie die Regeln genau aussehen sollen. Ich verspreche, dass wir uns dann darum kümmern werden.«

Das Meeting nähert sich seinem Ende, und wir alle sind zufrieden. Das ist lange nicht mehr vorgekommen.

KAPITEL 9

Dienstag, 9. September

Ich befinde mich in dem brutalsten Budget-Meeting, an dem ich je teilgenommen habe. Dick sitzt hinten im Raum, hört aufmerksam zu und greift ab und zu schlichtend ein. Wir alle sind von seinen Entscheidungen abhängig, weil er den ersten Entwurf für die Jahresplanung erstellen wird. Sarah sitzt neben ihm und tippt auf ihrem iPhone herum.

Irgendwann greife ich doch zu meinem Handy. Es vibriert nun schon fast eine ganze Minute ununterbrochen. Das scheint ein echter Notfall zu sein.

Ich lese: »Sev-1-Zwischenfall: Kreditkartenverarbeitungssysteme down. Alle Filialen betroffen.«

Ach du Scheiße.

Ich weiß, dass ich dieses Meeting verlassen muss, weiß aber auch, dass jeder versuchen wird, mir mein Budget streitig zu machen. Ich stehe auf, kämpfe mit dem großen Laptop und verhindere, dass sich nicht noch mehr Teile lösen. Ich bin schon fast draußen, als Sarah fragt: »Wieder Probleme, Bill?«

Ich schneide eine Grimasse. »Nichts, was wir nicht in den Griff bekommen.«

In Wirklichkeit ist jeder Sev-1-Zwischenfall automatisch ein echt großes Problem, aber ich will ihr ja nicht noch Munition liefern.

Als ich im NOC eintreffe, lasse ich mich auf den Stuhl neben Patty fallen, die die Telefonkonferenz leitet. »Kurze Info an alle: Bill ist gerade eingetroffen. Um dich auf den aktuellen Stand zu bringen: Wir konnten bestätigen, dass die Bestellsysteme nicht mehr laufen, daher haben wir einen Sev-1-Zwischenfall deklariert. Wir versuchen gerade, herauszufinden, was sich geändert hat.«

Sie macht eine Pause und schaut mich an. »Und ich bin nicht sicher, ob wir das wirklich wissen.«

Ich wende mich an alle. »Patty hat eine ziemlich einfache Frage gestellt. Was für Änderungen wurden heute vorgenommen, die zu diesem Ausfall führen könnten?«

Betretenes Schweigen, während die Leute entweder auf den Boden starren oder ihre Nachbarn verdächtig anschauen. Alle vermeiden Augenkontakt.

Ich will gerade etwas sagen, als sich jemand meldet: »Chris hier. Ich habe das Patty schon gesagt und sage es jetzt auch dir: Keiner meiner Entwickler hat irgendetwas geändert. Nehmt uns also von der Liste der Verdächtigen. Vermutlich ist es ein Datenbankproblem.«

Am anderen Ende des Tischs ist jemand sauer. »Auf keinen Fall. Wir haben für die nächsten drei Wochen keine Updates auf diesen Systemen geplant. Ich wette 50 Mäuse, dass es eine Netzwerkänderung war – deren Frickelei sorgt doch immer für Probleme.«

Wes schlägt die Hände vors Gesicht und ruft: »Herrgott, Leute!«

Verärgert und resigniert sagt er zu jemandem am Tisch: »Willst du auch deine Ehre verteidigen? Jeder darf mal.«

Und klar, der Netzwerkleiter hält seine Hände hoch und antwortet gekränkt: »Wisst ihr, das ist wirklich nicht fair, uns Netzwerkleuten immer die Schuld für Ausfälle zu geben. Wir haben heute überhaupt keine Änderungen eingeplant.«

»Beweist es«, fordert ihn der Datenbankmanager heraus.

Der Netzwerkleiter wird knallrot, und seine Stimme überschlägt sich: »Das ist doch Mist! Du forderst den Beweis, dass wir nichts getan haben? Wie soll ich das denn bitteschön beweisen? Und außerdem vermute ich das Problem eher bei einer fehlgeschlagenen Änderung an der Firewall. Die meisten Ausfälle in den letzten Wochen wurden von denen verursacht.«

Ich weiß, ich sollte diesem Wahnsinn vermutlich ein Ende machen. Aber stattdessen zwinge ich mich, mich im Stuhl zurückzulehnen und das Ganze zu beobachten, während ich mit der einen Hand meinen Mund bedecke, um nicht zu zeigen, wie sauer ich bin, und um zu verhindern, dass ich etwas Falsches sage.

Patty ist jetzt wirklich genervt und wendet sich mir zu. »Aus Johns Team ist keiner hier. Die kümmern sich um die ganzen Firewall-Änderungen. Ich versuche mal, ihn zu erreichen.«

Aus dem Lautsprecher höre ich Tastaturgeklapper, dann sagt eine Stimme: »Ähm, kann es jetzt mal jemand probieren?«

Man hört, wie mehrere Leute auf ihren Laptops tippen, um die Bestellsysteme zu erreichen.

»Moment mal«, rufe ich, bin halb von meinem Stuhl hoch und zeige auf die Telefonkonferenzspinne. »Wer hat das gerade gesagt?«

Unangenehme Stille.

»Ich bin’s, Brent.«

Oh Mann.

Ich zwinge mich wieder auf meinen Sitz und atme tief durch. »Brent, vielen Dank für deine Mühe, aber bei einem Sev-1-Ereignis müssen wir alle Aktivitäten ankündigen und besprechen, bevor wir sie umsetzen. Das Letzte, was wir wollen, ist, alles noch schlimmer zu machen und die Fehlersuche zu erschweren ...«

Bevor ich zu Ende reden kann, unterbricht mich jemand am anderen Ende des Tischs. »Hey, die Systeme sind wieder da. Gute Arbeit, Brent.«

Kommt, Leute.

Frustriert presse ich die Lippen aufeinander.

Anscheinend kann auch ein undisziplinierter Mob einmal Glück haben.

»Patty, bring das hier zu Ende«, sage ich, »ich muss Wes und dich sofort in deinem Büro sprechen.« Ich stehe auf und gehe.

In Pattys Büro bleibe ich stehen, bis ich die ungeteilte Aufmerksamkeit beider Kollegen habe. »Lasst mich eines klarstellen. Bei Sev-1-Zwischenfällen können wir nicht einfach aus dem Bauch heraus handeln. Patty, ich bitte dich als diejenige, die eine Sev-1-Telefonkonferenz leitet, von jetzt an solch eine Runde mit dem bisherigen Ablauf der Geschehnisse einzuleiten, insbesondere mit den Änderungen.

Du bist dafür verantwortlich, dass diese Informationen zur Verfügung stehen. Das sollte einfach sein, weil du ja auch den Change-Prozess steuerst. Diese Informationen kommen von dir und nicht von den ganzen Krakeelern in der Telefonkonferenz. Ist das klar?«

Patty sieht mich an, offensichtlich frustriert. Ich widerstehe dem Drang, sanftere Worte zu wählen. Ich weiß, dass sie hart gearbeitet hat und ich ihr in letzter Zeit noch mehr aufgebürdet habe.

»Jaja, klar«, sagt sie müde. »Ich werde den Prozess dokumentieren und so schnell wie möglich umsetzen.«

»Das reicht nicht«, sage ich, »ich will, dass du alle zwei Wochen Übungstelefonkonferenzen durchführst. Jeder muss daran gewöhnt sein, Probleme methodisch zu lösen und die bisherigen Ereignisse zur Hand zu haben, bevor wir solche Meetings durchführen. Wenn wir das nicht bei einer Übung schaffen – wie sollen die Leute das dann bei einem echten Notfall machen?«

Als ich den entmutigten Ausdruck in ihrem Gesicht sehe, lege ich meine Hand auf ihre Schulter. »Ich weiß, wie viel du in letzter Zeit zu tun hattest, und ich bin dir sehr dankbar dafür. Das ist wichtige Arbeit, und ich wüsste nicht, was wir ohne dich täten.«

Als Nächstes wende ich mich Wes zu. »Mach Brent klar, dass jeder ab sofort in solchen Notfällen Änderungen, über die er nachdenkt, erst mit den anderen bespricht – erst recht, bevor er sie einfach umsetzt. Ich kann es nicht beweisen, aber ich habe den Verdacht, dass Brent die Panne verursacht hat. Als er es dann bemerkt hat, hat er seine Änderung wieder zurückgenommen.«

Wes will gerade antworten, aber ich schneide ihm das Wort ab.

»Beende das«, sage ich deutlich. »Keine weiteren ungenehmigten Änderungen und keine heimlichen Änderungen bei Ausfällen. Hast du deine Leute im Griff oder nicht?«

Wes sieht überrascht aus und versucht, in meinem Gesicht zu lesen. »Ja, ich kümmere mich darum, Boss.«

Wes und ich verbringen den Rest des Dienstags und den Morgen des Mittwochs fast vollständig im Phoenix War Room. Der Auslieferungstermin ist nur noch drei Tage entfernt. Und mit jedem Tag, den er näher rückt, sieht es schlimmer aus.

Es ist richtiggehend entspannend, zurück zum Change Coordination Room zu laufen.

Als ich den Raum betrete, sind die meisten des CAB-Teams da. Der unordentliche Stapel mit Karteikarten ist verschwunden. Stattdessen hängen sie entweder an einem der Whiteboards, oder sie sind ordentlich auf dem Tisch aufgehäuft, markiert mit »Ausstehende Änderungen«.

»Willkommen zu unserem Change-Management-Meeting«, beginnt Patty. »Wie ihr an unserem Whiteboard sehen könnt, sind alle Standardänderungen schon eingeplant. Heute wollen wir die Änderungen mit hohem und mittlerem Risiko begutachten und einplanen. Dann werden wir uns den Änderungszeitplan anschauen und notwendige Anpassungen vornehmen – ich will nichts vorwegnehmen, aber ich denke, ihr werdet ein paar Punkte finden, die unsere Aufmerksamkeit verlangen.«

Sie schnappt sich den ersten Stapel mit Karten. »Die erste Änderung mit hohem Risiko betrifft eine Firewall. Eingereicht von John, geplant für Freitag.« Dann liest sie die Leute vor, die befragt wurden und der vorgeschlagenen Änderung zugestimmt haben.

Patty wendet sich an Wes und mich: »Bill und Wes, genehmigt ihr das für Freitag?«

Ich bin zufrieden, dass sich genug Leute damit befasst haben, daher nicke ich.

Wes sagt: »In Ordnung. Hey, gar nicht mal so schlecht. 23 Sekunden für das Genehmigen unserer ersten Änderung. Wir haben unsere vorherige Bestzeit um 95 Minuten unterboten!«

Es gibt vereinzelten Applaus. Patty enttäuscht nicht, als sie die verbleibenden acht Hochrisikoänderungen durchgeht. Die sind sogar noch schneller abgehandelt. Es gibt mehr Applaus, während einer ihrer Mitarbeiter die Karten am Whiteboard befestigt.

Dann nimmt sich Patty den Stapel mit den Änderungen mit mittlerem Risiko. »Es wurden 147 Standardänderungen eingereicht. Ich möchte alle dafür loben, sich an den Prozess gehalten und mit den Leuten gesprochen zu haben, die gefragt werden sollten. 90 dieser Änderungen sind bereits einplanbar und schon am Whiteboard zu finden. Ich habe sie ausgedruckt, sodass jeder einen Blick darauf werfen kann.«

Sie wendet sich wieder an Wes und mich und sagt: »Ich habe mir zehn Prozent davon angeschaut, und sie sehen meiner Meinung nach größtenteils gut aus. Ich werde das Ganze aber im Auge behalten, falls wir uns welche davon in Zukunft genauer anschauen müssen. Sofern es keine Einwände gibt, sind wir wohl mit den Änderungen mit mittlerem Risiko durch. Es gibt aber noch ein drängenderes Problem, mit dem wir uns beschäftigen müssen.«

Als Wes »Keine Einwände von mir« sagt, nicke ich ebenfalls Patty zu, die vage auf das Board zeigt.

Ich denke, ich weiß, was falsch läuft, sage aber erst einmal nichts. Einer der Manager zeigt auf eines der Whiteboards und sagt: »Wie viele Änderungen sind für Freitag eingeplant?« Bingo.

Patty lächelt kurz und sagt: »173.«

Auf dem Board ist es ziemlich offensichtlich, dass so gut wie die Hälfte der Änderungen für Freitag anstehen. Von den verbleibenden ist die Hälfte wiederum für Donnerstag angedacht, und der Rest verteilt sich auf die übrigen Tage.

Sie fährt fort: »Ich sage nicht, dass es schlecht ist, am Freitag 173 Änderungen einzuspielen, aber ich mache mir Sorgen um Konflikte zwischen ihnen und um Ressourcen, die für mehrere Änderungen gebraucht würden. Zudem soll am Freitag Phoenix deployt werden.

Wenn wir ein Tower wären«, fährt sie fort, »würde ich sagen, dass der Luftraum gefährlich überbelegt ist. Möchte eventuell jemand seine Reisepläne ändern?«

Jemand sagt: »Ich habe drei Änderungen, die ich gerne heute umsetzen möchte, wenn das keinen stört. Ich will eigentlich so weit weg wie möglich vom Flughafen sein, wenn Phoenix landet.«

»Du glücklicher«, murmelt Wes, »manche von uns müssen am Freitag hier sein. Ich kann schon die Flammen aus den Triebwerken schlagen sehen.«

Zwei weitere Entwickler bitten darum, ihre Änderungen früher umsetzen zu können. Patty lässt sie selbst an den Whiteboards ihre Karten verschieben und kontrolliert dabei, dass sie nicht anderen, schon geplanten Änderungen in die Quere kommen.

15 Minuten später sind die Karten deutlich gleichmäßiger über die Tage verteilt. Weniger glücklich macht mich die Tatsache, dass alle versuchen, ihre Änderungen möglichst weit weg vom Freitag vorzunehmen – so wie Tiere, die vor einem Waldbrand fliehen.

Während ich beobachte, wie die Karten mit den Änderungen hin- und hergeschoben werden, nagt etwas anderes an mir. Es sind nicht nur die Bilder von Chaos und Zerstörung rund um Phoenix. Stattdessen hat es etwas mit Erik und dem Gebäude MRP-8 zu tun.

Patty unterbricht meine Gedanken. »... Bill, damit haben wir alles erledigt, was zu tun war. Alle Änderungen für diese Woche sind genehmigt und eingeplant.«

Während ich versuche, mich wieder zu orientieren, sagt Wes: »Patty, du hast das super organisiert. Du weißt ja, dass ich einer deiner lautesten Kritiker war. Aber ...« Er gestikuliert zu den Whiteboards. »Das ist alles hervorragend.«

Es gibt zustimmendes Gemurmel, und Patty wird rot. »Danke sehr. Wir haben aber erst seit einer Woche einen echten Change-Management-Prozess, und so viele wie heute waren noch nie da. Bevor wir uns also gegenseitig auf die Schultern klopfen, sollten wir erst einmal die zweite Woche abwarten, okay?«

Ich pflichte bei: »Auf jeden Fall. Vielen Dank für die Zeit, die du hierfür investiert hast, Patty. Mach bitte weiter so.«

Als das Meeting vorüber ist, bleibe ich noch da und starre auf die White-boards.

Während des Meetings ist mehrfach ein Gedanke aufgeflackert. Hatte er etwas mit dem zu tun, das Erik gesagt hatte und das ich bisher verdrängt habe? Etwas zum Thema »Arbeit«?

Letzten Donnerstag haben Wes und Patty eine Liste all unserer Projekte zusammengestellt und dabei fast 100 gefunden. Diese Liste ist entstanden, indem die beiden alle IT-Mitarbeiter befragt haben. Solche Projekte gehören sicherlich zu einer von zwei Kategorien: Businessprojekte und interne IT-Projekte.

Beim Anblick der Karten mit den Änderungen wird mir bewusst, dass ich auf eine weitere Sammlung von Arbeit schaue, die wir erneut manuell erzeugt haben. Laut Patty sind das 437 verschiedene Punkte, die wir diese Woche erledigen – Arbeit?

Ich erkenne, dass Änderungen die dritte Arbeitskategorie sind.

Während Patty und ihre Leute mit den Change-Karteikarten jonglierten – von Freitag bis Anfang der Woche –, haben sie unseren Arbeitsplan geändert. Jede dieser Karten definiert die Arbeit, die mein Team im Laufe der Tage zu erledigen hat.

Sicher, jede dieser Änderungen ist viel kleiner als ein ganzes Projekt, aber es ist trotzdem Arbeit. Aber wie sieht die Beziehung zwischen Änderungen und Projekten aus? Sind sie gleich wichtig?

Und kann es wirklich sein, dass vor dem heutigen Tag keine dieser Änderungen irgendwo in einem System dokumentiert wurde? Wo kamen dann diese Änderungen überhaupt her?

Wenn Änderungen eine Art von Arbeit sind, die sich von Projekten unterscheidet – bedeutet das dann, dass wir tatsächlich an mehr als 100 Projekten werkeln? Wie viele dieser Änderungen dienen der Unterstützung der 100 Projekte? Und wenn eine Änderung keinem davon hilft – sollten wir sie dann wirklich durchführen?

Hätten wir gerade so viele Ressourcen, um all die Projektarbeit zu erledigen, hätten wir dann nicht mehr ausreichend Leute für das Umsetzen der Änderungen?

Ich frage mich, ob ich gerade dabei bin, eine wichtige Einsicht zu gewinnen. Erik hat mich gefragt, wie das Äquivalent meines Teams zu dem Tisch mit den Arbeitsaufträgen in der Fabrikhalle aussieht. Hat das Change-Management da etwas mit zu tun?

Plötzlich lache ich laut auf angesichts der absurd großen Zahl an Fragen, die ich mir selbst stelle. Ich fühle mich wie ein Ein-Mann-Debattierklub. Oder Erik hat mich irgendwie dazu gebracht, eine philosophische Nabelschau zu betreiben.

Ich denke einen Moment nach und entscheide dann, dass es wichtig ist, zu wissen, dass Änderungen eine weitere Arbeitskategorie sind, ich aber nicht weiß, warum.

Jetzt habe ich drei der vier Arbeitskategorien identifiziert. Einen kurzen Moment frage ich mich, welche denn die vierte sein könnte.

KAPITEL 10

Donnerstag, 11. September

Am nächsten Morgen bin ich in aller Frühe im Phoenix War Room. Kirsten gibt wie jeden Tag einen Überblick über die kritischsten Aufgaben für das Phoenix-Projekt. Da so viel auf dem Spiel steht, werden zugesagte Aufgaben normalerweise vom verantwortlichen Manager als »abgeschlossen« gemeldet.

Keiner will sich bei Kirsten unbeliebt machen. Oder gar bei Steve.

Die schlechten Neuigkeiten des Tages kommen von William Mason, Director of Quality Assurance, der für Chris arbeitet. Anscheinend werden immer noch doppelt so viele nicht funktionierende Features gefunden wie die, die wieder zum Laufen gebracht wurden.

Es ist nie ein gutes Zeichen, wenn einem Auto Teile abfallen, während es sich noch auf dem Fließband befindet. Kein Wunder, dass wir uns alle vor dem Deployment-Datum fürchten.

Ich überlege gerade, wie wir ein paar der Risiken reduzieren können, als ich höre, wie Kirsten Brents Namen zum dritten Mal erwähnt. Und zum dritten Mal muss Wes erklären, warum etwas nicht erledigt wurde.

Sarah meldet sich vom anderen Ende des Raums zu Wort: »Wes, schon wieder sind Ihre Leute der Flaschenhals. Gibt es da irgendwelche Probleme mit dem Personal, um die Sie sich kümmern sollten?«

Wes wird rot und will gerade antworten, als ich schnell dazwischengehe. »Kirsten, wie viele andere Aufgaben hat Brent?«

Kirsten antwortet: »Stand heute gibt es fünf noch nicht erledigte Aufgaben. Drei stammen von Mittwoch, zwei von letztem Freitag.«

»Okay, ich kümmere mich darum«, sage ich. »Sobald wir hier fertig sind, schaue ich mir an, was da los ist. Heute Nachmittag liefere ich einen Status mit angepasstem Zeitplan. Wenn ich etwas brauche, melde ich mich.«

Auf meinem Weg zu Brents Cubicle in Gebäude 7 ermahne ich mich, hier nur zu beobachten und zu verstehen. Schließlich gab es seit meiner Beförderung keinen Tag, an dem Brents Arbeit nicht Teil eines Gesprächs war.

Vielleicht ist Brent gar nicht so klug, wie wir alle denken. Oder vielleicht ist er ein technologisches Genie, und wir werden nie jemanden finden, der ihm auch nur annähernd das Wasser reichen kann. Oder er sabotiert absichtlich all unsere Versuche, ihm Arbeit wegzunehmen.

Aber Brent scheint professionell und klug zu sein – nicht viel anders als viele andere erfahrene Entwickler, mit denen ich in der Vergangenheit gearbeitet habe.

Als ich seinen Schreibtisch erreiche, höre ich ihn telefonieren und gleichzeitig tippen. Er sitzt vor seinen vier Monitoren, hat ein Headset auf und gibt etwas in eine Terminalanwendung ein.

Ich bleibe außerhalb seines Cubicles stehen und lausche heimlich.

»Nein, nein, nein. Die Datenbank läuft. Ja, ich weiß das, weil ich es direkt vor mir sehe ... Ja, ich kann Queries absetzen ... Läuft es jetzt? Okay, ich will mal schauen ... Warte mal, ich will einen manuelle Sync anstoßen. Versuche es jetzt noch mal ...«

Sein Handy klingelt. »Warte mal kurz, ich bekomme noch einen anderen Anruf. Ich rufe dich gleich zurück.«

Er macht sich eine Notiz auf einem Zettel und klebt sie an seinen Monitor neben zwei weitere Zettel. Verärgert geht er an sein Handy. »Ja, Brent hier ... Welcher Service ist unten? Hast du versucht, ihn neu zu starten? Hör mal, ich bin zurzeit total mit Phoenix zu – kann ich dich später anrufen?«

Ich will ihm gerade im Stillen gratulieren, als er sagt: »Oh ... ich weiß nicht einmal, wer das ist. Der VP von was? Okay, ich schaue mal.«

Ich seufze, lasse mich in einen Stuhl in einem leeren Cubicle fallen und lausche der heutigen Episode von Ein Tag im Leben von Brent.

Er telefoniert weitere fünf Minuten und legt erst auf, als irgendeine kritische Produktionsdatenbank wieder läuft.

Ich freue mich zwar, dass sich Brent wirklich darum sorgt, dass jeder, der mit IT-Systemen zu tun hat, seine Arbeit erledigen kann, aber ich kann es nicht gutheißen, dass auch jeder ihn als seinen persönlichen, kostenlosen Geek betrachtet. Auf Kosten von Phoenix.

Brent schnappt sich eine der Haftnotizen von seinem Monitor und will gerade zum Telefon greifen, als ich aufstehe und zu ihm gehe. »Hallo Brent.« »Argh!«, ruft er erschreckt. »Wie lange bist du schon hier?«

»Erst ein paar Minuten«, sage ich mit einem möglichst freundlichen Lächeln, während ich mir einen Stuhl nehme. »Lange genug, um zu verfolgen, wie du die Probleme von zwei Leuten gelöst hast. Das ist bewundernswert, aber ich komme gerade von Kirstens täglichem Phoenix-Status-Meeting. Du hast eigentlich fünf Aufgaben, die noch nicht erledigt sind.«

Ich zeige ihm die fünf Aufgaben aus dem Projekt-Meeting. Er sagt schnell: »Ich bin mit denen schon halb fertig. Ich brauche nur ein paar Stunden Ruhe, um sie ganz zu erledigen. Wenn ich könnte, würde ich das ja von zu Hause aus machen, aber die Netzwerkverbindung ist zu langsam.«

»Wer hat dich angerufen, und was wollten sie?«, frage ich stirnrunzelnd.

»Meist andere ITler, die Probleme damit haben, etwas wieder hinzubekommen«, antwortet er und verdreht die Augen. »Wenn etwas herunterfährt, bin ich anscheinend die einzige Person, die weiß, wo man nachzuschauen hat.«

»Ich dachte, Wes hätte ein paar Leute eingestellt, um dir einige dieser Eskalationen vom Leib zu halten?«, sage ich.

Brent verdreht wieder die Augen. »Das war die Idee, ja. Aber die meisten hatten andere Zuständigkeitsbereiche und waren nicht erreichbar, wenn wir sie brauchten. Andere wurden bei den letzten Entlassungswellen rausgeworfen, weil sie nicht genug zu tun hatten. Vertrau mir, das war kein großer Verlust. Die meisten Probleme musste ich letztendlich sowieso selbst lösen.«

»Wie häufig wirst du am Tag angerufen? Notierst du dir das irgendwo?«, frage ich.

»Du meinst, wie in unserem Ticket-System? Nein, denn wenn ich für jeden dieser Anrufe ein Ticket öffnen würde, bräuchte ich dafür länger als für das Fixen des Problems«, sagt Brent geringschätzig. »Die Anzahl der Anrufe ist von Tag zu Tag verschieden. Die letzte Woche war aber schlimmer als normal.«

Ich habe verstanden. Wenn jetzt jemand anrufen und laut genug schreien oder einen wichtigen Namen deutlich erwähnen würde, säße Brent wieder stundenlang an den Problemen anderer Leute.

»Du hast versucht, die letzte Anruferin abzuwimmeln. Warum hast du doch an dem Problem gearbeitet, anstatt ihr zu erzählen, dass sie sich verziehen soll?«, frage ich. Brent antwortet: »Sie hat mir erzählt, dass der VP of Logistics im Dreieck springt, weil Nachbestellungen nicht erzeugt werden. Und wenn ich das nicht sofort beheben würde, könnte es sein, dass unsere Filialen bei Schnelldrehern bald keinen Lagerbestand mehr hätten. Ich wollte nicht derjenige sein, der dafür verantwortlich ist.«

Ich schürze meine Lippen. Executives, die meine Entwickler dazu drängen, ihnen Gefallen zu tun, sind eine echte Plage. Aber Phoenix dadurch in Gefahr bringen? Das geht doch wohl über ihre Entscheidungsbefugnis hinaus.

Ich stehe auf und sage: »Okay, ab sofort arbeitest du nur an Phoenix. Steve Masters hat gesagt, dass dies die Top-Priorität für jeden ist. Das Projekt braucht dich im Moment mehr als je zuvor. Ich erwarte, dass du jede Aufgabe, die jemand anderes an dich heranträgt, ablehnst.«

Brent sieht zugleich erleichtert und besorgt aus. Vielleicht denkt er an den VP of Logistics.

Ich fahre fort: »Wenn dich jemand wegen etwas anderem als Phoenix anspricht, schicke ihn zu Wes. Der soll sich um die ganzen Idioten kümmern.«

Er antwortet skeptisch: »Das finde ich ja sehr nett, aber ich glaube nicht, dass das langfristig funktionieren wird. Die Kollegen hier scheinen gar nicht alle auf dem Laufenden zu sein, was unsere Systeme angeht. Letztendlich kommen sie immer zu mir.«

»Nun, dann müssen sie es halt lernen. Wenn sie anrufen, schick sie zu Wes. Wenn jemand damit ein Problem hat, schick ihn zu mir. Am besten, du erstellst eine automatische Antwort für deine E-Mails, die sagt, dass du nur auf Phoenix-Themen eingehst und ansonsten bitte ...«

Auf mein Zeichen hin vollendet er grinsend den Satz: »... Wes zu kontaktieren ist.«

»Siehst du? Gleich kapiert«, lächle ich.

Ich zeige auf sein Telefon. »Mach, was notwendig ist, damit sich die Leute nicht immer direkt an dich wenden. Wenn du willst, kannst du den Klingenton ausschalten und deine Voicemail-Ansage auf Wes verweisen lassen. Was auch immer.«

Ich erkenne, dass ich Brent alleine durch meine Anwesenheit von Phoenix abhalte, und sage schnell: »Nein, ich lasse meine Assistentin Ellen die Voice-mail-Ansage für dich ändern.«

Brent grinst erneut: »Nein, nein, das kann ich schon selbst erledigen. Aber vielen Dank für das Angebot.«

Ich schreibe ihm meine Handynummer auf einen Notizzettel. »Ellen wird sich darum kümmern. Arbeite du lieber an deinen Phoenix-Tasks. Wenn du etwas brauchst, ruf mich an.«

Als er nickt, wende ich mich zum Gehen, drehe mich aber noch einmal um. »Hey, vielleicht kann ich dich ja nächste Woche mal auf ein Bier einladen.« Er stimmt zu und scheint ein wenig fröhlicher zu wirken.

Beim Verlassen des Gebäudes rufe ich Patty an. Als sie rangeht, sage ich: »Schnapp dir Wes, und dann kommt ihr zum Phoenix War Room. Wir müssen uns Gedanken darüber machen, wie wir Brent nicht mehr so viele Eskalationen zuschustern. Und zwar sofort.«

Wir drei sitzen in einem Besprechungsraum in der Nähe des War Room.

»Wie lief es mit Brent?«, fragt Wes.

Als ich ihm erzähle, dass Brent nicht an Phoenix arbeiten konnte, weil er dauernd unterbrochen wurde, wird er blass. »Er ist dauernd in diesen Notfall-Meetings! Wie kann er bloß denken, dass irgendetwas wichtiger als Phoenix ist?«

Ich sage: »Gute Frage. Warum würde Brent Phoenix liegen lassen, um an etwas anderem zu arbeiten?«

Wes hört kurz auf zu toben. »Vermutlich, weil er von jemandem wie mir angeschnauzt wird, damit er die mir wichtigste Aufgabe erledigt. Und das stimmt wohl: Bei viel zu vielen Dingen scheint Brent der Einzige zu sein, der weiß, wie sie tatsächlich funktionieren.«

»Wenn ich es wäre, würde ich mich vermutlich damit herausreden, dass es nur ein paar Minuten dauert ...«, sagt Patty. »Das mag dann zwar sogar stimmen, aber trotzdem ist das wie ein Tod auf Raten.«

»Prozesse sollen eigentlich die Leute schützen. Wir müssen uns überlegen, wie wir Brent schützen«, sage ich. Dann erzähle ich, dass ich Brent schon aufgefordert habe, alle, die etwas von ihm wollen, zu Wes zu schicken.

»Was? Soll ich ihn die ganze Zeit mikromanagen? Ich habe nicht die Zeit, Brents Sekretär oder so etwas wie ein Helpdesk zu sein!«, ruft er.

»Okay, was ist denn wichtiger, als sicherzustellen, dass deine Ressourcen die kritischen Phoenix-Aufgaben erledigen können?«, frage ich.

Wes schaut mich ein paar Momente wie versteinert an, dann lacht er los. »Okay, erwischt. Sieh mal, Brent ist wirklich klug. Aber wenn es um das Dokumentieren von etwas geht, ist er eine echte Niete. Ich will dir mal eine Geschichte erzählen, die zeigt, wie unmöglich das bei ihm ist: Vor ein paar Monaten kämpften wir schon drei Stunden mit einem Sev-1-Zwischenfall und versuchten alles, Brent nicht schon wieder stören zu müssen. Aber schließlich gingen uns die Ideen aus, und alles, was wir taten, machte das Ganze nur schlimmer. Also haben wir Brent geholt.«

Er schüttelt den Kopf, während er nachdenkt. »Er setzt sich also an die Tastatur, und es ist, als ob er in eine Trance fällt. Zehn Minuten später ist das Problem gelöst. Alle sind glücklich und erleichtert, dass das System wieder läuft. Aber dann fragt jemand: ›Wie hast du das gemacht?‹ Und ich schwöre dir: Brent schaut ihn ausdruckslos an und sagt: ›Ich habe keine Ahnung. Ich habe es halt einfach getan.‹«

Wes haut auf den Tisch und sagt: »Und das ist das Problem mit Brent. Wie dokumentiert man so etwas? ›Schließe deine Augen und falle in eine Trance.‹?«

Patty lacht und scheint sich auch an die Geschichte zu erinnern. Sie meint: »Ich sage ja nicht, dass Brent das absichtlich macht, aber ich frage mich, ob Brent sein Wissen als eine Art Superheldenkraft sieht. Vielleicht will ein Teil von ihm das gar nicht aufgeben. Er hat damit eine Stellung inne, von der ihn niemand vertreiben kann.«

»Vielleicht, vielleicht auch nicht«, sage ich. »Aber ich werde euch erzählen, was ich sicher weiß: Jedes Mal, wenn wir Brent etwas fixen lassen, das keiner von uns wiederholen kann, wird Brent ein bisschen klüger und das gesamte System ein bisschen dümmer. Wir müssen dem ein Ende bereiten.

Vielleicht können wir einen Ressourcenpool mit Level-3-Entwicklern aufbauen, der sich um die Eskalationen kümmert. Diese Entwickler sind dafür verantwortlich, alle Zwischenfälle erfolgreich zu lösen, und sie sind die Einzigen, die Zugriff auf Brent erhalten – unter einer Bedingung.

Wenn sie mit Brent sprechen wollen, müssen sie erst die Zustimmung von Wes oder mir einholen«, sage ich. »Sie müssen dokumentieren, was sie gelernt haben, und Brent darf an keinem Problem zwei Mal arbeiten. Ich würde mir die Probleme wöchentlich anschauen, und wenn ich herausfinde, dass Brent dagegen verstößt, gibt es Ärger. Für Brent und für die Entwickler.«

Ich überlege weiter. »Bei dem, was Wes erzählt, sollten wir Brent nicht einmal erlauben, sich an den Rechner zu setzen. Er darf den Leuten nur erzählen, was einzutippen ist, und kann dabei zuschauen. Aber unter keinen Umständen darf er etwas tun, was danach wieder keiner dokumentieren konnte. Ist das klar?«

»Das ist super«, sagt Patty. »Nach jedem Zwischenfall haben wir einen weiteren Eintrag in unserer Knowledge Base zum Lösen eines kniffligen Problems und einen wachsenden Pool an Leuten, die das umsetzen können.«

Wes sieht nicht völlig überzeugt aus, aber schließlich lacht er. »Das gefällt mir auch. Wir behandeln ihn wie Hannibal Lecter – wenn wir ihn brauchen, stecken wir ihn in eine Zwangsjacke, binden ihn auf eine Sackkarre und rollen ihn zum Zwischenfall.«

Ich lache.

Patty fügt hinzu: »Um eine weitere Eskalation mit Brent zu vermeiden, sollten wir jeden Tastendruck und jede Terminalsitzung aufzeichnen. Vielleicht sollte ihm sogar jemand mit einer Videokamera folgen, damit wir genau wissen, was er geändert hat.«

Mir gefällt das, aber es wäre ein bisschen extrem. Allerdings fürchte ich, dass wir aus dieser Situation nur mit extremen Maßnahmen herauskommen.

Ich spinne das Ganze weiter. »Vielleicht nehmen wir ihm noch den Production-Zugriff weg, sodass er nur helfen kann, indem er den anderen Entwicklern sagt, was sie tun sollen.«

Wes bricht in schallendes Gelächter aus. »Wenn wir das machen, wird er eventuell kündigen.«

»Wen hätten wir denn zur Verfügung, um ihn in diesen Level-3-Ressourcenpool zu stecken?«, frage ich.

Er zögert. »Na ja, wir haben die beiden neu eingestellten Kollegen, die vor einem Jahr dazukamen und Brent helfen sollten. Eine arbeitet jetzt daran, Server-Build-Standards zu erstellen, aber das kann auch eine Zeit lang liegen bleiben. Es gibt noch zwei weitere Entwickler, die wir vor ein paar Jahren für ein Cross-Training ausgeguckt hatten, aber niemand hatte die Zeit, sich dann richtig darum zu kümmern. Das wären drei Leute.«

»Ich werde die neuen Brent-Prozeduren aufsetzen«, sagt Patty. »Jeder Zugriff auf ihn soll über Wes oder dich laufen. Aber wie halten wir Leute wie den VP of Logistics davon ab, sich direkt an Brent zu wenden?«

Ich antworte direkt: »Wir werden die Namen der Leute sammeln, die das tun. Dann rufe ich den Chef von jedem an und sage ihm, dass das zu unterbleiben hat. Danach lasse ich Steve wissen, wie diese Leute Phoenix aufhalten.«

»Okay, versuchen wir es«, sagt sie. »Jetzt haben wir uns aber nur um die ›Peitsche‹ gekümmert – wie sieht es mit dem ›Zuckerbrot‹ aus? Wie können wir Brent und die Entwickler dazu motivieren, diesem neuen Prozess zu folgen?«

»Vielleicht schicken wir sie auf eine Konferenz oder Fortbildung nach Wunsch. Wenn Seniorentwickler das Level von Brent erreichen oder danach streben, wollen sie lernen und anderen erzählen, was sie getan haben. Und zu Brent: Wie wäre es, wenn wir ihm eine Woche Urlaub spendierten – frei von irgendwelchen Eskalationen?«, schlägt Wes vor. »Ich glaube, Brent hat in den vergangenen drei Jahren keinen freien Tag ohne einen Pager verbracht. Er wird in Tränen ausbrechen, wenn wir ihm das anbieten.«

»Macht es so, Leute«, sage ich, während ich mir die Szene lächelnd vorstellen.

Bevor ich es vergesse, füge ich noch hinzu: »Wes, ich hätte gerne einen täglichen Stundennachweis für Brent, und jede Eskalation, an der Brent arbeitet, muss in das Ticket-System wandern. Wir müssen das dokumentieren, um es später auswerten zu können. Jeder, der Brent Zeit stiehlt, muss sich mir gegenüber rechtfertigen. Und wenn es nicht berechtigt war, werde ich es an Steve weiterreichen, und diese Person und sein Manager dürfen ihm dann erklären, warum sie der Meinung sind, dass ihr Projekt so wichtig ist.«

»Das ist erstaunlich«, sagt Patty. »Wir haben in der letzten Woche mehr Change-, Incident- und Eskalationsprozesse angestoßen als in den vergangenen fünf Jahren!«

»Vielleicht ist es jetzt einfach der richtige Zeitpunkt dafür«, sagt Wes erleichtert. »Aber tut mir einen Gefallen und erzählt keinem, dass ich das gesagt habe – ich habe schließlich einen Ruf zu verlieren.«

KAPITEL 11

Donnerstag, 11. September

Als ich später Mittag esse, fluche ich laut. In den wenigen wertvollen Minuten während meiner Pause, die nicht mit Terminen vollgestopft sind, hatte ich versucht, die aufgelaufenen E-Mails durchzugehen, aber leider vergessen, dass mein blöder Laptop abstürzt, wenn ich ihn einschalte, während er in der Dockingstation steckt. Das ist das dritte Mal diese Woche, dass mir das passiert ist.

Die Pause ist sowieso schon spät, und die Hälfte ist bereits vorbei, als ich mich endlich anmelden kann.

Ich finde einen leeren Klebezettel auf meinem Schreibtisch und schreibe möglichst groß darauf: »LAPTOP NUR EINGESCHALTET EINSETZEN!!!« Die Notiz klebe ich auf die Dockingstation, um mich das nächste Mal vor mir selbst zu schützen.

Ich lächle noch über meine Gegenmaßnahme, als Patty auf dem Handy anruft. »Hast du eine Minute? Im Change-Kalender geht Seltsames vor. Das musst du dir anschauen.«

Als ich in den Besprechungsraum komme, sehe ich die vertrauten Change-Karten an den Wänden hängen. Der Eingangskorb ist gut gefüllt, und weitere Karten sind ordentlich auf dem Tisch gestapelt. Patty kontrolliert etwas auf ihrem Laptop und kaut dabei an ihren Nägeln.

Als sie mich sieht, sagt sie erschöpft: »Ich glaube langsam, dieser ganze Change-Prozess ist reine Zeitverschwendung. Das Organisieren all dieser Änderungen und das Verwalten der Kommunikation mit den Stakeholdern beschäftigt drei Leute in Vollzeit. Und angesichts dessen, was ich hier gerade sehe, scheint das nutzlos zu sein.«

Dass Patty ihren Prozess, für den sie so lange gekämpft hat, plötzlich so geringschätzig ansieht, macht mir tatsächlich Sorgen.

»Whoa«, sage ich und nehme die Hände ablehnend hoch. »Das musst du mir erst einmal erklären, denn meiner Meinung nach hast du fantastische Arbeit geleistet, und ich will nicht wieder in alte Verhaltensweisen zurückfallen. Was macht dir so Sorgen?«

Sie zeigt auf die Änderungen für Montag und Dienstag. »Jeden Abend gehen meine Leute die eingeplanten Änderungen durch. Wir wollten sichergehen, dass alle Änderungen, die nicht abgeschlossen wurden, wieder eingeplant werden und unser Change-Kalender auch die Wirklichkeit widerspiegelt.«

Sie zeigt auf die Ecke einer Karte. »Wir haben die Change-Karten mit einer Markierung versehen, wenn der Change abgeschlossen wurde. Man kann an ihr auch erkennen, ob es Probleme oder gar Ausfälle deswegen gab. Seit letztem Freitag wurden 60 Prozent der geplanten Änderungen nicht umgesetzt! Das bedeutet, wir machen uns die ganze Arbeit mit dem Autorisieren und Einplanen dieser Änderungen, nur um herauszufinden, dass sie gar nicht durchgeführt werden!«

Ich sehe, warum Patty beunruhigt ist.

»Warum sind die nicht abgeschlossen? Und was macht ihr mit den nicht erledigten Change-Karten?«, frage ich.

Sie kratzt sich am Kopf. »Ich habe eine Reihe von Einreichern angerufen, und die Gründe sind ganz verschieden. Einige sagten, sie hätten nicht alle Leute zusammenbekommen, die sie für die Änderung brauchten. Irgendjemand hat während des Umsetzens seiner Änderung erkannt, dass die Storage-Leute das SAN nicht wie versprochen erweitert hatten, daher musste er seine Änderungen wieder zurücknehmen – nach zwei Stunden Arbeit.«

Ich stöhne, als ich an die ganze verschwendete Zeit und den Aufwand denke, den wir betreiben. Patty fährt fort: »Eine andere Kollegin sagte, dass sie ihre Änderung nicht implementieren konnte, weil es gerade einen Ausfall gab. Und eine ganze Reihe von Leuten erklärte, dass ...«

Es scheint ihr unangenehm zu sein, aber ich ermuntere sie, fortzufahren. »Na ja, sie brauchten für einen Teil ihrer Änderungen Brent, aber der stand nicht zur Verfügung«, sagt sie widerstrebend. »In manchen Fällen war Brents Beteiligung eingeplant. Aber in anderen haben sie erst während der Implementierung gemerkt, dass sie seine Hilfe brauchten, und mussten das Ganze dann abbrechen.«

Bevor Patty fertig geredet hat, sehe ich rot.

»Was? Schon wieder Brent? Was geht denn hier ab? Wie hat es Brent geschafft, für jeden unabkömmlich zu werden?

Ach, Mist!«, rufe ich, als mich die Erkenntnis mit einem Schlag trifft. »Haben wir das Problem selbst verursacht, indem wir Brent ganz auf Phoenix eingeschworen haben? Ist diese neue Regelung ein Fehler?«

Nach einem Moment sagt Patty: »Weißt du, das ist eine interessante Frage. Wenn du wirklich glaubst, dass Brent nur an den allerwichtigsten Projekten arbeiten sollte, ist die neue Regelung meiner Meinung nach richtig, und wir sollten sie nicht zurücknehmen.

Es ist aber auch wichtig, darauf hinzuweisen, dass Brent bis vor Kurzem den Leuten dabei geholfen hat, ihre Änderungen umzusetzen, ohne dass das irgendwo dokumentiert war. Oder zumindest hat er es versucht. Aber da er immer viel zu beschäftigt damit war, jedem zu helfen, wurden viele dieser Änderungen doch nicht fertig – auch nicht nach der alten Regelung.«

Ich greife zu meinem Handy, rufe Wes an und bitte ihn, herzukommen.

Als er kurze Zeit später eintrifft, schnappt er sich einen Stuhl und wirft einen Blick auf meinen alten Laptop. »Jesses. Schleppst du das Ding immer noch herum? Ich bin sicher, wir haben genug neuere acht Jahre alte Laptops, die du nutzen könntest.«

Patty ignoriert seinen Kommentar und bringt ihn auf den neuesten Stand. Er reagiert auf ihre Enthüllungen nicht viel anders als ich.

»Ihr macht Witze!«, sagt er verärgert und schlägt sich die Hand vor die Stirn. »Sollten wir Brent eventuell erlauben, den Leuten bei ihren Änderungen doch zu helfen?«

Ich sage schnell: »Nein, das kann nicht die Lösung sein. Ich habe das auch schon vorgeschlagen. Aber Patty meinte zu Recht, dass damit die blockierten Änderungen als wichtiger angesehen würden als Phoenix. Was sie nicht sind.«

Laut nachdenkend, sage ich: »Irgendwie müssen wir die gewohnten Wege beim Umsetzen der Änderungen aufbrechen – genauso wie wir es mit den Hilfegesuchen an Brent gemacht haben. Sein Wissen muss irgendwie zu den Leuten gelangen, die eigentlich die Arbeit erledigen müssten. Wenn sie das nicht verstehen, haben wir vielleicht ein Qualifikationsproblem in diesen Teams.«

Als niemand etwas sagt, ergänze ich zögernd: »Wie wäre es, wenn wir dieselben Level-3-Entwickler nehmen würden, die Brent davor schützen sollen, alle Ausfälle selbst zu beheben, und sie zum Unterstützen beim Umsetzen der Änderungen einsetzen?«

Wes antwortet schnell: »Vielleicht. Aber das ist keine langfristige Lösung. Die Leute, die die Arbeit eigentlich erledigen sollen, müssen wissen, was zum Teufel sie da tun. Wir können nicht noch mehr Leute ihr Wissen horten lassen.«

Ich höre Wes und Patty zu, wie sie sich gegenseitig Ideen zuspielen, um sich noch unabhängiger von Brent zu machen, als etwas an mir nagt. Erik hat WIP oder Work In Process als »stillschweigenden Killer« bezeichnet. Die Unfähigkeit, die WIP in der Fertigungshalle unter Kontrolle zu behalten, war eine der Ursachen für die chronischen Liefer- und Qualitätsprobleme.

Wir haben gerade festgestellt, dass 60 Prozent unserer Änderungen nicht wie geplant fertiggestellt wurden.

Erik hat auf den stetig wachsenden Berg an Arbeit in der Halle als Zeichen dafür hingewiesen, dass die Vorarbeiter ihre Work In Process nicht in den Griff bekamen.

Ich schaue mir den Berg an Change-Karten an, die für heute angesetzt sind und wie von einem gigantischen Schneepflug zusammengeschoben wirken. Plötzlich scheint es so zu sein, dass Eriks Beschreibung der Fabrikhalle den Zustand meiner Organisation auf unheimliche Art und Weise genau beschreibt.

Kann IT wirklich mit der Arbeit in einer Fertigungshalle verglichen werden?

Patty unterbricht meine Gedanken, als sie fragt: »Was meinst du?«

Ich schaue sie an. »In den letzten Tagen wurden nur 40 Prozent der geplanten Änderungen umgesetzt. Der Rest ist verschoben. Gehen wir davon aus, dass das so weitergeht, während wir uns überlegen, wie wir Brent all sein Wissen entlocken können.

Wir haben diese Woche 240 nicht abgeschlossene Änderungen. Wenn nächste Woche 400 neue Änderungen eintrudeln, sind es schon 640 Änderungen!

Wir sind das Bates Motel der Änderungen«, sage ich ungläubig. »Die Änderungen gehen rein, aber nicht wieder hinaus. Innerhalb eines Monats werden wir Tausende Änderungen mit uns herumtragen, die alle gerne implementiert werden möchten.«

Patty nickt. »Genau das stört mich auch. Wir müssen dabei nicht mal einen Monat warten, um auf eine vierstellige Zahl zu kommen – wir sind schon bei 942 Änderungen. Die 1000 wartenden Änderungen werden irgendwann nächste Woche erreicht werden. Es ist schon jetzt problematisch, alle Change-Karten unterzubringen. Warum tun wir uns all den Ärger an, wenn die Änderungen dann doch nicht implementiert werden?«

Ich starre all die Karten an in der Hoffnung, dass sie mir eine Antwort liefern.

Ein immer größer werdender Stapel mit Produkten auf dem Hallenboden – so hoch, dass nur Gabelstapler ihn bearbeiten können.

Ein immer größer werdender Stapel von Änderungen in IT Operations, deren Karten gar nicht mehr alle an die Wände gepinnt werden können.

Arbeit, die sich vor dem Härtungsofen stapelt, weil Mark an seinem Vorarbeiterschreibtisch die Arbeit anstößt.

Arbeit, die sich vor Brent stapelt, weil ...

Ja, warum?

Okay, wenn Brent unser Härtungsofen ist – wer ist dann unser Mark? Wer hat erlaubt, dass diese ganze Arbeit in das System geschoben wird?

Nun, wir haben das erlaubt. Oder besser gesagt, das CAB.

Mist. Sind wir also selbst daran schuld?

Aber die Änderungen müssen erledigt werden, oder? Einfach weil es Änderungen sind. Außerdem: Wie könnten wir den Ansturm der eintreffenden Aufgaben einfach ablehnen?

Wenn ich mir die wachsenden Kartenstapel anschaue – können wir einfach Nein sagen?

Aber wann wurde die Frage überhaupt gestellt, ob wir die Arbeit akzeptieren sollten? Und auf welcher Grundlage haben wir diese Entscheidung getroffen?

Wieder weiß ich keine Antwort. Aber schlimmer noch – ich habe das Gefühl, dass Erik doch kein langhaariger Irrer ist. Vielleicht hat er ja recht. Vielleicht gibt es ja eine Verbindung zwischen dem Organisieren der Fertigung und IT Operations. Vielleicht haben die Fertigungsorganisation und IT Operations tatsächlich ähnliche Herausforderungen und Probleme.

Ich stehe auf, gehe zum Change-Board und beginne, laut nachzudenken. »Patty ist beunruhigt, weil mehr als die Hälfte unserer Änderungen nicht wie eingeplant abgeschlossen wurden – bis hin zu der Überlegung, ob dieser ganze Änderungsprozess den Aufwand überhaupt wert ist.

Zudem«, fahre ich fort, »weist sie darauf hin, dass ein signifikanter Teil der Änderungen nicht abgeschlossen werden kann, weil Brent auf die eine oder andere Art und Weise im Weg ist – was zum Teil daran liegt, dass wir Brent verboten haben, irgendwelche Aufgaben zu erledigen, die nichts mit Phoenix zu tun haben. Wir glauben aber, dass eine Rücknahme dieser Regelung nicht richtig ist.«

Ich mache einen Gedankensprung und folge meiner Intuition. »Und ich würde eine Million Dollar wetten, dass das wirklich der falsche Weg wäre. Das Problem ist, dass dieser Prozess das erste Mal aufgezeigt hat, wie viel eingeplante Arbeit gar nicht umgesetzt wird! Wenn wir den Prozess aufgeben, würden wir nur wieder nicht mehr wissen, was alles nicht passiert.«

Ich bin jetzt in Fahrt und sage: »Patty, wir müssen besser verstehen, welche Arbeiten Brent betreffen. Wir müssen wissen, welche Change-Karten mit Brent im Zusammenhang stehen – vielleicht machen wir das zu einer weiteren notwendigen Information, die die Leute beim Einreichen ihrer Karten geben müssen. Oder verwende eine andere Farbe – was auch immer. Du musst herausfinden, welche Änderungen Brents Hilfe benötigen, und versuchen, diese stattdessen den Level-3-Entwicklern zu geben. Wenn das nichts bringt, versuche, sie zu priorisieren, sodass wir mit Brent eine Auswahl treffen können.«

Während ich rede, bin ich immer zuversichtlicher, dass wir auf dem richtigen Weg sind. Vielleicht lösen wir das Problem nicht, aber immerhin erhalten wir Daten.

Patty nickt, ihre Sorge und ihre Verzweiflung scheinen verschwunden zu sein. »Du willst, dass ich mir die Änderungen anschaue, die mit Brent zu tun haben. Das soll auf den Karten sichtbar sein, und neue Karten sollen diese Information schon tragen. Und wenn wir wissen, wie viele Änderungen von Brent abhängen, was das für Änderungen sind und so weiter, kommen wir zu dir zurück, um die Prioritäten zu besprechen. Richtig?«

Ich nicke und lächle.

Sie macht sich auf ihrem Laptop Notizen. »Okay, habe ich. Ich bin nicht sicher, was wir da herausfinden, aber es ist bei Weitem besser als alles andere.«

Ich schau zu Wes. »Du siehst besorgt aus – willst du etwas dazu sagen?«

»Hmm ...«, sagt er schließlich. »Da kann ich nicht viel zu sagen. Nur, dass das so anders ist als alles, was ich bisher in IT gesehen habe. Nichts für ungut, aber nimmst du in letzter Zeit neue Medikamente?«

Ich lächle matt. »Nein, aber ich hatte vor Kurzem ein Gespräch mit einem langhaarigen Irren auf einem Laufsteg oben in einer Fabrikhalle.«

Aber wenn Erik mit WIP in IT Operations recht hatte – wo lag er dann auch noch richtig?

KAPITEL 12

Freitag, 12. September

Es ist Freitag, 19:30, zwei Stunden, nachdem das Phoenix-Deployment beginnen sollte. Und es sieht nicht gut aus. Ich fange an, den Geruch von Pizza mit der Sinnlosigkeit eines Todesmarschs zu verbinden.

Das ganze IT Operations-Team stand bereit für ein Deployment um 16 Uhr. Aber es gab nichts zu tun, weil wir nichts von Chris’ Team bekommen hatten – sie saßen immer noch an Last-Minute-Änderungen.

Es ist kein gutes Zeichen, wenn man noch Teile in das Spaceshuttle einbauen will, wenn es eigentlich schon abheben soll.

Um 16:30 war William in den Phoenix War Room gestürmt – wütend und empört, dass niemand den ganzen Phoenix-Code in der Testumgebung zum Laufen bekommen würde. Schlimmer noch: Die wenigen Komponenten von Phoenix, die liefen, bestanden nicht einmal die wichtigsten Tests.

William begann damit, Meldungen mit kritischen Fehlern an die Entwickler zu schicken, von denen viele schon nach Hause gegangen waren. Chris musste sie zurückholen, und Williams Team musste darauf warten, dass die Entwickler neue Versionen bereitstellten.

Mein Team saß nicht nur dumm herum. Stattdessen arbeiteten wir mit Williams Team verzweifelt daran, Phoenix vollständig in der Testumgebung zum Laufen zu bringen. Denn wenn es schon da nicht lief, war die Chance verschwindend gering, dass es in der Produktivumgebung laufen würde.

Mein Blick wandert von der Uhr zum Besprechungstisch. Brent und drei andere Techniker steckten mit ihren QA-Kollegen die Köpfe zusammen. Sie kämpfen seit 16 Uhr und sind schon ausgelaugt. Viele sind mit ihren Laptops auf Google-Suche, während andere systematisch Einstellungen für Server, Betriebssysteme, Datenbanken und die Phoenix-Anwendung durchprobieren, um herauszufinden, wie sich alles zum Laufen bringen lässt – das sei möglich, hatten die Entwickler ihnen versichert.

Einer der Entwickler war sogar vor ein paar Minuten hereingekommen und hatte gesagt: »Hey, auf meinem Laptop läuft es. Was ist denn daran so schwer?«

Wes begann zu schimpfen, während zwei unserer Techniker und drei von Williams Leuten sich den Laptop des Entwicklers zur Brust nahmen, um herauszufinden, wo die Unterschiede zur offiziellen Testumgebung lagen.

In einem anderen Bereich des Raums diskutiert ein Techniker hitzig mit jemandem am Telefon. »Ja, wir haben die Datei von dir kopiert ... ja, Version 1.0.13 ... Was heißt das, das ist die falsche Version ... Was? Wann hast du das geändert? ... Kopiere sie und versuche es noch mal ... Okay, aber ich sage doch, das wird nicht funktionieren ... Ich glaube, es ist ein Netzwerkproblem ... Wie, wir müssen einen Firewall-Port öffnen? Warum zum Henker hast du uns das nicht vor zwei Stunden gesagt?«

Er knallt den Hörer auf die Gabel, haut mit der Faust auf den Tisch und brüllt: »Idioten!«

Brent schaut müde von seinem Laptop auf. »Lass mich raten. Das Frontend kann nicht mit dem Datenbankserver reden, weil uns jemand nicht gesagt hat, dass wir einen Firewall-Port öffnen müssen?«

Der Techniker nickt mit nachlassender Wut und sagt: »Ich kann das einfach nicht fassen. Ich habe mit dem Depp 20 Minuten telefoniert, und es kam ihm nie in den Sinn, dass es kein Codeproblem sein könnte. Das ist FUBAR.«

Ich höre den beiden weiter zu und nicke angesichts seines Statements. Bei den Marines haben wir den Begriff FUBAR auch genutzt – Fucked Up Beyond All Recognition, kurz gesagt: Am Arsch.

Als sich die Gemüter wieder etwas beruhigt haben, schaue ich auf die Uhr: 19:37.

Zeit, eine Einschätzung von meinem Team zu bekommen. Ich sammle Wes und Patty ein und halte Ausschau nach William. Den finde ich schließlich bei einem seiner Leute, auf einen Bildschirm starrend. Ich bitte ihn, sich uns anzuschließen.

Einen Moment sieht er verwirrt aus, da wir normalerweise nichts miteinander zu tun haben, aber er nickt und folgt uns in mein Büro.

»Okay Leute, wie seht Ihr die Lage?«, frage ich.

Wes antwortet zuerst. »Die Leute haben recht. Das ist FUBAR. Wir bekommen von den Entwicklern immer noch unvollständige Releases. In den letzten beiden Stunden bin ich über zwei Instanzen gestolpert, bei denen sie vergessen haben, uns eine Reihe wichtiger Dateien mitzuliefern, sodass der Code auf keinen Fall laufen konnte. Und wie du gesehen hast, wissen wir immer noch nicht, wie die Testumgebung zu konfigurieren ist, sodass Phoenix tatsächlich sauber hochfährt.«

Er schüttelt erneut den Kopf. »Angesichts dessen, was ich in der letzten halben Stunde gesehen habe, denke ich, dass wir uns sogar zurückentwickeln.«

Patty schüttelt nur angewidert den Kopf und macht eine wegwerfende Handbewegung – sie sagt nichts.

Zu William sage ich: »Ich weiß, dass wir bisher nicht sehr intensiv zusammengearbeitet haben, aber ich würde wirklich gerne wissen, was du meinst. Wie sieht es aus deiner Perspektive aus?«

Er sieht zu Boden, atmet langsam aus und antwortet dann: »Ich habe ganz ehrlich keine Ahnung. Der Code ändert sich so schnell, dass wir Probleme damit haben, up to date zu sein. Meine Einschätzung ist, dass uns Phoenix in der Produktivumgebung um die Ohren fliegen wird. Ich habe schon ein paar Mal Chris gefragt, ob wir das Release nicht besser stoppen sollten, aber er und Sarah haben meine Argumente einfach weggewischt.«

Ich frage ihn: »Was meinst du damit, dass ihr nicht ›up to date‹ bleiben könnt?«

»Wenn wir Probleme beim Testen finden, schicken wir sie an die Entwicklung, damit die sie beheben«, erklärt er. »Dann liefern sie ein neues Release. Aber es dauert immer etwa eine halbe Stunde, bis wieder alles eingerichtet ist, und weitere drei Stunden, um den Smoke-Test auszuführen. In der Zeit haben wir bestimmt drei neue Releases von der Entwicklung bekommen.«

Ich grinse über den Ausdruck »Smoke-Test« – ein Begriff, den die Entwickler von Schaltkreisen nutzen. Dort heißt es: »Wenn du die Schaltung mit Strom versorgst und es nirgendwo qualmt, wird sie vermutlich funktionieren.«

Er schüttelt den Kopf und sagt: »Wir müssen wenigstens einmal den Smoke-Test durchlaufen können. Aber ich mache mir Sorgen, dass wir keine ordentliche Versionsverwaltung mehr haben – keiner kümmert sich mehr so recht um passende Versionsnummern für das ganze Release. Immer wenn irgendetwas gefixt wird, geht etwas anderes kaputt. Wir bekommen immer nur neue Dateien, aber nicht das gesamte Paket.«

William fährt fort: »Im Moment ist das Ganze so chaotisch, dass ich eines weiß: Selbst wenn durch irgendein Wunder Phoenix den Smoke-Test bestünde, wären wir nicht in der Lage, das zu wiederholen, weil es zu viele sich verändernde Komponenten gibt.«

Er nimmt seine Brille ab, reibt sich die Augen und sagt abschließend: »Das wird vermutlich für alle eine lange Nacht. Meiner Meinung nach besteht die reale Gefahr, dass morgen um 8 Uhr in der Frühe beim Öffnen der Filialen nichts läuft. Und das wäre ein großes Problem.«

Das ist die Untertreibung des Jahrhunderts. Wenn das Release nicht um 8 Uhr fertig ist, werden die Kassensysteme in den Läden nicht funktionieren. Und das heißt, dass die Kunden nicht wie üblich bezahlen können.

Wes nickt. »William hat recht. Wir werden definitiv die ganze Nacht hier sein. Und die Performance von Phoenix ist noch schlechter, als ich schon befürchtet habe. Wir brauchen mindestens 20 weitere Server, um die Last besser zu verteilen, und ich weiß nicht, wo wir so kurzfristig so viele herbekommen sollen. Ein paar Leute sind schon auf der Suche nach ungenutzter Hardware. Vielleicht müssen wir sogar Server aus der Produktion ausschlachten.«

»Ist es zu spät, die Auslieferung noch zu stoppen?«, frage ich. »Wann genau erreichen wir den Point of no Return?«

»Das ist eine sehr gute Frage«, antwortet Wes bedächtig. »Ich müsste das mit Brent klären, aber meiner Meinung nach müssten wir das Deployment noch ohne Probleme stoppen können. Sobald wir jedoch damit beginnen, die Datenbank zu konvertieren, sodass sie die Aufträge sowohl von den POS-Systemen aus den Filialen als auch von Phoenix annehmen kann, können wir nicht mehr zurück. Bei der momentanen Lage denke ich, das wird erst in ein paar Stunden der Fall sein.«

Ich nicke. Ich habe gehört, was ich wissen wollte.

»Leute, ich werde eine E-Mail an Steve, Chris und Sarah schicken, um herauszufinden, ob ich die Auslieferung verschieben kann. Und dann werde ich mich auf die Suche nach Steve machen. Vielleicht kann ich noch eine Woche herausschlagen. Aber selbst ein weiterer Tag wäre hilfreich. Irgendwelche Anmerkungen?«

Wes, Patty und William schütteln alle verdrießlich die Köpfe und sagen nichts.

Ich wende mich Patty zu. »Hilf William dabei, herauszufinden, wie wir die Releases besser im Griff behalten. Geh zu den Entwicklern, spiele Fluglotse und sorge dafür, dass alles mit Labels versehen und versioniert ist. Und sag Wes und seinem Team Bescheid, wenn etwas Neues kommt. Wir brauchen eine bessere Sichtbarkeit und jemanden, der darauf achtet, dass sich die Leute an die Prozesse halten. Ich will, dass neuer Code nur auf einem einzigen Weg eintreffen kann, dass es kontrollierte stündliche Releases gibt und eine Dokumentation. Ihr versteht die Richtung?«

Sie sagt: »Aber gerne doch. Ich werde vor dem Phoenix War Room erscheinen, die Tür eintreten, wenn das nötig ist, und sagen: ›Wir sind gekommen, um zu helfen ...‹«

Ich bedanke mich bei allen mit einem Kopfnicken und wende mich dann meinem Laptop zu, um meine E-Mail zu schreiben.

Von: Bill Palmer

An: Steve Masters

Cc: Chris Anderson, Wes Davis, Patty McKee, Sarah Moulton, William Mason

Datum: 12. September, 19:45

Wichtigkeit: Hoch

Betreff: DRINGEND: Phoenix-Deployment in großen Schwierigkeiten – meine Empfehlung: Verschieben um 1 Woche

Steve,

ich versichere Ihnen, dass ich Phoenix genauso gerne produktiv haben würde wie jeder andere. Ich verstehe, wie wichtig dieses Projekt für die Firma ist.

Aber ausgehend von dem Überblick, den ich mir verschafft habe, glaube ich, dass wir Phoenix nicht bis zur Deadline morgen früh um 8 Uhr lauffähig haben werden. Es gibt ein GROSSES RISIKO, dass sich dies sogar auf die POS-Systeme in den Filialen auswirkt.

Nach einem Gespräch mit William empfehle ich, den Phoenix-Launch um eine Woche zu verschieben, um die Wahrscheinlichkeit zu erhöhen, dass Phoenix seine Ziele erreicht, und um zu verhindern, dass ansonsten ein NAHEZU SICHERES Desaster eintreten wird.

Ich fürchte, die Probleme können eine Größenordnung annehmen wie die Walmart-Panne zu Thanksgiving 1999 mit mehrtätigen Ausfällen und Performance-problemen, die Kunden- und Bestelldaten gefährden könnten.

Steve, ich werde Sie in ein paar Minuten anrufen.

Viele Grüße

Bill

Ich sammle einen Moment meine Gedanken und rufe dann Steve an, der sofort an sein Telefon geht.

»Steve, Bill hier. Ich habe gerade eine E-Mail an Sie, Sarah und Chris geschickt. Der Roll-out ist im Moment eine einzige Katastrophe. Das Ganze wird total nach hinten losgehen. Selbst William sieht das so. Mein Team macht sich im Moment sehr große Sorgen, dass der Roll-out nicht rechtzeitig fertig sein wird, sodass die Filialen morgen Probleme haben werden, wenn sie um 8 Uhr öffnen. Eventuell werden dort dann keine Einkäufe verbucht werden können, und auch die Website wird möglicherweise mehrere Tage ausfallen.

Es ist noch nicht zu spät, diese Katastrophe zu verhindern«, beschwöre ich ihn. »Wenn etwas schiefgeht, werden wir von keinem mehr Bestellungen oder Aufträge annehmen können – egal ob aus dem Internet oder in den Läden. Die Bestell- und Kundendaten geraten eventuell durcheinander, und wir würden damit Kunden verlieren. Ein Verschieben um eine Woche würde zwar die Kunden enttäuschen, aber sie würden zumindest zurückkommen!«

Steve denkt nach, dann antwortet er: »Das klingt schlecht, aber im Moment haben wir keine andere Wahl, als weiterzumachen. Das Marketing hat schon Anzeigen in den Wochenendausgaben der Zeitungen gebucht, in der Phoenix als verfügbar angepriesen wird. Die Anzeigen sind gebucht, bezahlt und bereits im ganzen Land verteilt. Unsere Partner stehen schon längst bereit.«

Ich bin baff und sage: »Steve, was muss passieren, damit Sie dieses Release verschieben? Ich sage doch gerade, dass das Risiko tatsächlich enorm ist und die Folgen unabsehbar sind!«

Er bleibt weiter ruhig. »Wissen Sie was? Wenn Sie Sarah davon überzeugen können, das Roll-out zu verschieben, unterhalten wir uns noch mal. Ansonsten machen Sie bitte weiter.«

»Machen Sie Witze? Sie ist doch diejenige, die diese Kamikaze-Aktion anführt.« Bevor ich weiß, was ich tue, lege ich auf. Einen kurzen Moment überlege ich, nochmals anzurufen und mich zu entschuldigen.

So sehr ich es hasse, habe ich doch das Gefühl, dass ich der Firma noch einen letzten Versuch schulde, diesen Wahnsinn zu stoppen. Also muss ich direkt mit Sarah sprechen.

Zurück im Phoenix War Room, ist es stickig und warm von zu vielen Leuten, die vor Anspannung und Sorge schwitzen. Sarah sitzt alleine und tippt auf ihrem Laptop.

Ich spreche sie an: »Sarah, können wir uns kurz unterhalten?«

Sie weist auf den Stuhl neben sich. »Sicher, worum geht es?«

Leise antworte ich: »Lassen Sie uns im Flur reden.«

Nachdem wir schweigend hinausgegangen sind, frage ich: »Was meinen Sie, wie läuft es mit dem Release?«

Sie sagt zurückhaltend: »Sie wissen, wie das läuft, wenn wir versuchen, flott zu sein, oder? Es gibt immer unerwartete Aspekte. Wo gehobelt wird, da fallen Späne.«

»Ich denke, das ist hier ein bisschen schlimmer als bei Ihren normalen Roll-outs. Sie haben sicherlich schon meine E-Mail gelesen?«

Sie antwortet nur: »Natürlich. Und haben Sie meine Antwort gelesen?«

Mist.

Ich sage: »Nein. Aber bevor Sie mir davon erzählen, will ich sicher sein, dass Sie die Folgen und Risiken für das Geschäft verstehen.« Und dann wiederhole ich nahezu Wort für Wort, was ich Steve vor ein paar Minuten erzählt habe.

Wenig überraschend ist Sarah nicht beeindruckt. Sobald ich mit meinen Ausführungen fertig bin, sagt sie: »Wir haben uns alle den Hintern aufgerissen, um Phoenix so weit zu bringen. Das Marketing ist so weit, die Entwicklung ist so weit. Alle sind fertig, nur Ihr Team nicht. Ich habe es schon zuvor gesagt, aber offensichtlich haben Sie nicht zugehört: Die Perfektion ist der Feind des Guten. Wir müssen weitermachen.«

Verwundert über diese kolossale Zeitverschwendung schüttele ich nur den Kopf und sage: »Nein, fehlende Kompetenz ist der Feind des Guten. Merken Sie sich meine Worte. Wir werden wegen Ihrer dummen Entscheidung die Trümmer noch Tage, wenn nicht Wochen aufräumen müssen.«

Als ich zurück ins NOC stürme, lese ich Sarahs E-Mail, was mich noch wütender macht. Ich widerstehe dem Drang, zu antworten und noch mehr Öl ins Feuer zu gießen. Auch widerstehe ich dem dringenden Wunsch, die Mail zu löschen – ich brauche sie, um mich für später abzusichern.

Von: Sarah Moulton

An: Bill Palmer, Steve Masters

Cc: Chris Anderson, Wes Davis, Patty McKee, William Mason

Datum: 12. September, 20:15

Wichtigkeit: Hoch

Betreff: Re: DRINGEND: Phoenix-Deployment in großen Schwierigkeiten – meine Empfehlung: Verschieben um 1 Woche

Außer Ihnen sind alle bereit. Marketing, Dev, Projektmanagement – alle haben in diesem Projekt alles gegeben. Jetzt sind Sie dran.

WIR MÜSSEN WEITERMACHEN!

Sarah

Plötzlich fällt mir ein, dass ich mich seit Stunden nicht bei Paige gemeldet habe. Ich schicke ihr schnell eine SMS:

Der Abend wird immer schlimmer. Ich werde hier mindestens noch ein paar Stunden sein. Erzähle später mehr. Hab dich lieb. Wünsch mir Glück, Schatz.

Jemand tippt mir auf die Schulter. Als ich mich umdrehe, steht Wes vor mir. »Chef, wir haben ein ernsthaftes Problem.«

Sein Gesichtsausdruck ist wirklich besorgniserregend. Ich stehe schnell auf und folge ihm auf die andere Seite des Raums.

»Erinnerst du dich, dass wir gegen 21 Uhr den Point of no Return erreicht haben? Ich habe mir angeschaut, wie die Umwandlung der Phoenix-Datenbank vorangeht: Sie ist tausendmal langsamer als gedacht. Eigentlich sollte sie vor Stunden abgeschlossen sein, aber es sind erst zehn Prozent fertig. Das bedeutet, die Konvertierung wäre erst Dienstag abgeschlossen. Wir sind echt am Arsch.«

Vielleicht bin ich müder, als ich dachte, aber ich kann ihm nicht folgen. »Warum ist das ein Problem?«

Wes versucht es noch mal: »Das Skript muss fertig sein, bevor die POS-Systeme gestartet werden. Wir können das Skript nicht stoppen und auch nicht wieder neu starten. Anscheinend gibt es nichts, was wir machen können, damit es schneller läuft. Ich denke, wir können Phoenix so weit zurecht biegen, dass es laufen wird, aber ich weiß nicht, wie es mit den Systemen in den Filialen aussieht – wir haben keines hier, um es zu testen.«

Heilige Scheiße.

Ich denke besonders lange nach, bevor ich frage: »Brent?«

Wes schüttelt den Kopf. »Er hat sich das schon ein paar Minuten lang angeschaut. Seiner Meinung nach hat jemand die Datenbankindizierung zu früh aktiviert, womit die Einfügeoperationen zu langsam sind. Aber wir können daran im Moment nichts ändern, ohne die Daten durcheinanderzubringen. Brent kümmert sich jetzt wieder um das Phoenix-Deployment.«

»Wie läuft der Rest?«, frage ich, um einen vollständigen Überblick über die Situation zu bekommen. »Gibt es Performanceverbesserungen? Oder etwas Neues zum Datenbank-Wartungstool?«

»Die Performance ist immer noch furchtbar«, sagt er. »Ich denke, es gibt da irgendwo ein riesiges Speicherleck – und dabei sind noch gar keine Benutzer auf dem System. Meine Leute befürchten, dass wir die ganzen Server alle paar Stunden werden durchstarten müssen, damit sie uns nicht um die Ohren fliegen. Blöde Entwickler ...«

Er fährt fort: »Wir haben uns 15 weitere Server zusammengesucht – ein paar neue und ein paar aus allen möglichen Ecken der Firma. Und jetzt haben wir nicht genug Platz in den Data Center Racks, um alle unterzubringen. Wir müssen alles Mögliche umräumen und umbauen, damit wir alles anschließen können. Patty hat schon einen Rundruf gestartet und noch ein paar ihrer Leute aus dem Feierabend geholt, damit sie helfen können.«

Meine Augenbrauen sind so weit gehoben, dass sie meinen Haaransatz treffen. Und dann lache ich – so stark, dass ich mich am Stuhl festhalten muss. »Oh mein Gott. Jetzt haben wir Server gefunden, um sie für das Deployment einsetzen zu können, da gibt es nicht genug Platz für sie. Toll. Eine Pause können wir wohl vergessen!«

Wes schüttelt den Kopf. »Weißt du, ich habe solche Geschichten schon von meinen Freunden gehört. Aber das hier wird wohl die Mutter aller Deployment-Katastrophen.«

Er fährt fort: »Und das ist noch gar nicht das Beste. Wir haben viel Geld in die Virtualisierung gesteckt, damit wir solche Probleme gar nicht bekommen. Aber als die Entwicklung die Performanceprobleme nicht lösen konnte, haben sie der Virtualisierung die Schuld in die Schuhe geschoben. Also mussten wir wieder alles auf echte Rechner zurückkopieren!«

Und Chris hat dieses sportliche Roll-out-Datum vorgeschlagen, weil die Virtualisierung uns doch so sehr helfen würde.

Ich wische mir die Tränen aus den Augen und zwinge mich, mit dem Lachen aufzuhören. »Wie sieht es mit den Datenbank-Supporttools aus, die uns die Entwickler versprochen haben?«

Wes wird wieder ernst. »Totaler Müll. Unsere Leute müssen die Datenbank manuell bearbeiten, um all die Fehler zu beheben, die Phoenix erzeugt. Und die Nachschubberechnung müssen wir per Hand anstoßen. Wir müssen immer noch herausfinden, wie viel manuelle Arbeit wir mit Phoenix haben werden. Das wird fehleranfällig sein und einen Haufen Leute erfordern.«

Ich winde mich, als ich daran denke, wie viele meiner Leute dadurch zusätzlich durch stupide Arbeit gebunden werden, die eigentlich von der kaputten Applikation zu erledigen wäre. Nichts macht Auditoren mehr Sorge als ein direktes Bearbeiten von Daten ohne Audit-Trails und saubere Kontrollen.

»Du machst das hier super. Am wichtigsten ist jetzt, herauszufinden, was die unvollständige Datenbankkonvertierung mit den POS-Systemen in den Filialen anstellt. Finde jemanden, der sich mit den Dingern wirklich auskennt, und hole seine Meinung ein. Wenn nötig, such dir jemanden aus Sarahs Team, der damit tagtäglich arbeitet. Noch besser wäre es, wenn du Zugriff auf ein POSGerät und einen -Server bekommst, an dem wir uns anmelden können, um selbst zu experimentieren.«

»Verstanden«, sagt Wes und nickt. »Ich weiß genau, wen ich da fragen muss.«

Ich schaue ihm nach und sehe mich dann um, um herauszufinden, wo ich am besten helfen kann.

Als die ersten Sonnenstrahlen des neuen Tages den Raum erfüllen, fallen sie auf Berge von Kaffeebechern, Papieren und diversen anderen Kram. In einer Ecke ist ein Entwickler unter ein paar Stühlen eingeschlafen.

Ich war gerade auf der Toilette, um mir das Gesicht zu waschen und den Schmutz von den Zähnen zu entfernen. Ich fühle mich ein wenig erfrischt, aber es ist schon Jahre her, dass ich eine Nacht durchgearbeitet habe.

Maggie Lee ist der Senior Director of Retail Program Management und arbeitet für Sarah. Sie beginnt um 7 Uhr ein Notfall-Meeting, und fast 30 Leute drängeln sich im Raum. Müde sagt sie: »In dieser Nacht haben viele ihr Bestes gegeben, und ich bedanke mich bei allen, die dafür gekämpft haben, Phoenix ans Laufen zu bekommen.

Wie alle wissen, ist der Grund für dieses Notfall-Meeting, dass bei der Datenbankkonvertierung etwas schiefgegangen ist«, fährt sie fort. »Das bedeutet, dass kein einziges POS-System in den Filialen laufen wird – die Läden können also nicht kassieren. Also manuelle Kassenvorgänge und manuelles Erfassen von Kreditkarten.«

Sie fügt hinzu: »Die gute Nachricht ist, dass die Phoenix-Website läuft.« Sie weist auf mich und sagt: »Mein Dank geht an Bill und die gesamte IT Operations-Crew, die das möglich gemacht hat.«

Irritiert sage ich: »Ich würde viel lieber diese POS-Systeme wieder am Laufen haben statt Phoenix. Im NOC ist die Hölle los. Alle Telefone sind bei uns seit der letzten Stunde ununterbrochen in Benutzung, denn die Kollegen in den Filialen schimpfen, weil ihre Systeme nicht reagieren. Es geht da unten zu wie bei einer Spendengala im Fernsehen. Wie bei allen ist auch meine Voicemail schon voll mit Anrufen von den Mitarbeitern aus unseren 120 Filialen. Wir werden zusätzliche Leute dazuholen müssen, nur um die Telefone zu bedienen.«

Irgendwo auf dem Tisch vibriert ein Handy, so als wollte es meine Ausführungen unterstreichen.

»Wir müssen hier proaktiv werden«, sage ich zu Sarah. »Wir müssen jedem in den Filialen eine Zusammenfassung schicken und so schnell wie möglich erklären, was passiert ist und wie sie ohne die POS-Systeme vorgehen sollen.«

Sarah sieht einen Moment ins Leere, dann sagt sie: »Das ist eine gute Idee. Wie wäre es, wenn Sie einen ersten Entwurf schreiben und wir den dann überarbeiten?«

Verdutzt sage ich: »Was? Ich bin kein Store Manager! Wie wäre es, wenn Ihre Gruppe den ersten Entwurf liefert? Dann können Chris und ich sicherstellen, dass der korrekt ist.« Chris nickt.

Sarah blickt im Raum umher. »Okay. Wir werden in den nächsten Stunden etwas schreiben.«

»Machen Sie Witze?«, rufe ich. »Die Läden an der Ostküste machen in weniger als einer Stunde auf – wir müssen gleich etwas herumschicken!«

»Ich werde mich darum kümmern«, sagt Maggie, nachdem sie ihre Hand gehoben hat. Sie öffnet ihren Laptop und beginnt direkt mit dem Schreiben.

Als ich mir die Hände an den Kopf drücke, um meine Kopfschmerzen zu verringern, frage ich mich, wie viel schlimmer dieser Roll-out noch werden kann.

Um 14 Uhr an diesem Samstag ist ziemlich klar, dass es noch viel schlimmer werden kann, als ich dachte.

Alle Filialen arbeiten im vollständigen manuellen Fallback-Modus. Alle Kreditkartenkäufe werden mit den Imprintern abgewickelt, die Durchschläge wandern in Schuhkartons.

Filialleiter haben Mitarbeiter zu Bürobedarfsläden geschickt, um Formulare für die Geräte zu organisieren, und zur Bank, um genug Wechselgeld zu besorgen.

Kunden, die die Phoenix-Website nutzen, beschweren sich darüber, dass sie entweder nicht verfügbar ist oder so langsam läuft, dass man sie nicht sinnvoll verwenden kann. Wir haben es sogar geschafft, bei Twitter ein Trending Topic zu werden. Alle unsere Kunden, die gespannt darauf waren, unsere neuen Services auszuprobieren, nachdem sie unsere TV-Werbespots und die Anzeigen in den Zeitungen gesehen haben, beschweren sich jetzt über unsere gigantische IT-Panne.

Die Kunden, die es geschafft hatten, online etwas zu bestellen, erwartete ein böses Erwachen, als sie zur Filiale kamen, um ihre Bestellung abzuholen. Denn wie sich zeigte, verliert Phoenix ab und zu Bestellungen, während bei anderen die Kreditkarte des Kunden doppelt oder dreifach belastet wird.

In Panik, dass eventuell die Integrität unserer Bestelldaten den Bach runtergegangen ist, hat Ann von Finance ihr Team einbestellt und auf dem gleichen Flur einen weiteren War Room eingerichtet, in dem sie Anrufe aus den Läden empfangen und Probleme mit den Bestellungen regeln. Zur Mittagszeit gibt es schon hohe Stapel mit Beschwerden genervter Kunden, die von den Filialen gefaxt wurden.

Um Ann zu unterstützen, hat Wes noch mehr Techniker aus dem Wochenende geholt, die nun Tools für ihre Mitarbeiter schreiben, mit denen die immer weiter wachsenden Stapel mit durcheinandergeratenen Bestellungen abgearbeitet werden können.

Als ich das dritte Mal am NOC-Tisch vorbeigehe, entscheide ich, dass ich zu fertig bin, um noch irgendwem von Nutzen zu sein. Es ist fast 14:30.

Wes diskutiert auf der anderen Seite des Raums mit irgendjemandem, daher warte ich, bis er fertig ist. Dann sage ich zu ihm: »So wie es aussieht, wird das hier ein paar Tage dauern. Wie geht es dir?«

Er gähnt und antwortet dann: »Ich habe ein paar Stunden Schlaf bekommen. Mann, du siehst echt furchtbar aus. Geh nach Hause und schlafe ein bisschen. Ich kümmere mich hier um alles. Wenn etwas ist, rufe ich dich an.«

Zu müde, um noch zu diskutieren, bedanke ich mich bei ihm und gehe.

Ich wache mit einem Ruck auf, als mein Telefon klingelt. Nachdem ich mich aufgesetzt habe, schnappe ich mir mein Handy. Es ist 16:30. Wes ruft an.

Ich schüttele den Kopf, um etwas wacher zu werden, dann gehe ich ran. »Was ist los?«

Wes sagt: »Schlechte Neuigkeiten. Kurz gesagt: Überall auf Twitter wird geschrieben, dass die Phoenix-Website Kreditkartendaten von Kunden preisgibt. Es gibt sogar Screenshots. Anscheinend ist es so: Wenn du den Einkaufswagen leerst, stürzt die Session ab und zeigt die Kreditkartennummer der letzten erfolgreichen Bestellung an.«

Ich bin schon aus dem Bett und auf dem Weg ins Bad, um kurz zu duschen. »Ruf John an. Er wird ganz aus dem Häuschen sein. Es gibt dafür bestimmt irgendeine Form von Protokoll mit tonnenweise Papieren und womöglich dem Hinzuziehen von irgendwelchen Behörden. Und Juristen sind bestimmt auch mit im Boot.«

Wes antwortet: »Ich habe ihn schon angerufen. Er und sein Team sind auf dem Weg. Und er ist echt stinkig. John hörte sich fast so an wie der Typ aus Pulp Fiction. Er hat sogar den Spruch mit den Rachetaten und dem Vernichten gebracht.«

Ich lache. Ich liebe diese Szene mit John Travolta und Samuel L. Jackson. So habe ich mir unseren friedfertigen CISO zwar nicht vorgestellt, aber wie sagt man: Man muss immer auf die Stillen achten.

Ich dusche mich schnell. Dann geht’s kurz in die Küche, und ich schnappe mir ein paar Käsesticks, die unser Sohn so liebt. Im Auto auf dem Weg zurück zur Firma esse ich sie.

Als ich auf der Autobahn bin, rufe ich Paige an. Sie geht beim ersten Klingeln ran. »Schatz, wo warst du? Ich bin arbeiten, und die Kinder sind bei meiner Mutter.«

Ich sage: »Ich war gerade eine Stunde zu Hause. Sobald ich ins Bett gekrochen war, bin ich auch eingeschlafen, aber Wes hat gerade angerufen. Anscheinend zeigt die Phoenix-Anwendung der ganzen Welt die Kreditkartennummern von Kunden. Das ist ein echtes Sicherheitsproblem, daher bin ich schon wieder auf dem Weg zur Arbeit.«

Ich höre sie missbilligend seufzen. »Du bist da jetzt seit über zehn Jahren und musstest noch nie so viel arbeiten. Ich weiß nicht, ob ich diese Beförderung so mag.«

»Da sind wir schon zwei, Schatz ...«, sage ich.

KAPITEL 13

Montag, 15. September

Am Montag ist die Phoenix-Krise ein öffentliches Fiasko. Wir haben es auf die Titelseiten aller Technologie-Sites geschafft. Es gibt das Gerücht, dass jemand vom Wall Street Journal versucht hat, Steve für ein offizielles Interview zu treffen.

Ich bekomme einen Heidenschreck, als ich meine, dass Steve meinen Namen erwähnt hat.

Völlig desorientiert schaue ich mich um – ich bemerke, dass ich bei der Arbeit bin und eingeschlafen sein muss, während ich darauf warte, dass das Phoenix-Status-Meeting beginnt. Ein Blick auf meine Uhr zeigt 11:04.

Ich muss auf mein Handy schauen, um herauszufinden, dass Montag ist.

Für einen Moment frage ich mich, wo der Sonntag geblieben ist, aber als ich Steve sehe, wie er mit hochrotem Kopf seine Ansprache hält, widme ich ihm meine volle Aufmerksamkeit.

»... es kümmert mich nicht, wer daran schuld ist. Sie können Ihren Hintern darauf verwetten, dass dies unter meiner Ägide nicht mehr passieren wird. Aber jetzt ist mir die Zukunft ziemlich egal – wir verärgern gerade massiv unsere Kunden und Aktionäre. Ich will nur wissen, wie wir da wieder herauskommen und das normale Geschäft wieder aufnehmen können.«

Er dreht sich zu Sarah um und sagt: »Und Sie sind aus der Sache so lange nicht raus, wie noch einer Ihrer Filialleiter nicht normal arbeiten kann. Manuelles Einlesen von Karten? Wo sind wir denn, in der Dritten Welt?«

Sarah antwortet ruhig: »Ich verstehe total, wie inakzeptabel das ist. Ich werde sicherstellen, dass mein gesamtes Team weiß, dass das in seiner Verantwortung liegt.«

»Nein«, antwortet Steve sofort ernst. »Sie sind letztendlich verantwortlich. Vergessen Sie das nicht.«

Mein Herz wird einen Moment leichter, als ich mich frage, ob Steve sich vielleicht von Sarahs Bann befreien konnte.

Er wendet seine Aufmerksamkeit wieder dem gesamten Raum zu und sagt ernst: »Wenn alle Filialleiter so weit sind, dass sie wieder normal arbeiten können, werde ich mit jedem, der hier beteiligt war, 15 Minuten sprechen. Ich erwarte, dass Sie das möglich machen. Keine Ausreden.

Das betrifft Sarah, Chris, Bill, Kirsten und Ann. Und auch Sie, John«, sagt er und zeigt auf die jeweiligen Personen.

Gut gemacht, John. Genau der richtige Zeitpunkt, um Steves Aufmerksamkeit zu erlangen.

Er fährt fort: »Ich werde in zwei Stunden zurück sein. Bis dahin muss ich mich mit einem weiteren Journalisten über dieses Chaos unterhalten!«

Sein Türenknallen lässt die Wände erzittern.

Sarah bricht die Stille. »Nun, Sie alle haben Steve gehört. Wir müssen nicht nur die POS-Systeme wieder zum Laufen bekommen, sondern auch noch die Bedienbarkeit der Phoenix-Website verbessern. Die Presse zerreißt uns gerade in der Luft angesichts der schlechten Bestelloberfläche und der ganzen Timeouts.«

»Sind Sie verrückt«, frage ich und lehne mich vor. »Phoenix läuft überhaupt nur durch reine Heldentaten. Wes hat keinen Witz gemacht, als er sagte, dass wir alle Frontend-Server proaktiv jede Stunde durchstarten. Wir können nicht noch mehr Instabilitäten ins System bringen. Ich schlage vor, Code-Roll-outs nur zwei Mal am Tag einzubringen und die Änderungen auf solche zu beschränken, die die Performance verbessern.«

Zu meiner Überraschung pflichtet Chris mir bei. »Ich stimme dir zu. William, was meinst du?«

William nickt. »Auf jeden Fall. Ich schlage vor, den Entwicklern mitzuteilen, dass ein Code-Commit immer eine Fehlernummer enthalten muss, die zu einem Performanceproblem gehört. Alles andere wird zurückgewiesen.«

Chris sagt: »Ist das für dich okay, Bill?«

Zufrieden mit der Lösung antworte ich: »Perfekt.«

Anders als Wes und Patty, die ebenfalls mit der Lösung einverstanden sind und sich über diese plötzliche Kooperation des Development-Teams wundern, ist Sarah nicht glücklich darüber. »Ich bin da gar nicht mit einverstanden. Wir müssen auf den Markt reagieren können, und der sagt uns, dass Phoenix viel zu schwierig zu bedienen ist. Wir können es uns nicht leisten, in dem Bereich nichts zu ändern.«

Chris antwortet. »Die Zeit für Usability-Tests und Validierung ist seit Monaten um. Wenn wir es beim ersten Mal nicht richtig machen konnten, werden wir es ohne echte Arbeit gar nicht hinbekommen. Lassen Sie Ihre Produktmanager die Mockups und Vorschläge überarbeiten. Wir werden versuchen, sie so schnell wie möglich umzusetzen, wenn diese Krise vorbei ist.«

Ich stimme ihm zu.

»Sie haben ein paar wichtige Punkte angeführt, und ich schließe mich dem an«, stimmt Sarah zu. Anscheinend hat sie bemerkt, dass sie aus dieser Diskussion nicht als Siegerin hervorgehen wird.

Ich bin nicht sicher, ob sich Sarah zurzeit überhaupt in der Position befindet, irgendetwas abzulehnen. Aber glücklicherweise wendet sich die Diskussion schnell dem Problem zu, wie die POS-Systeme wieder lauffähig gemacht werden können.

Chris steigt in meiner Achtung um einiges. Ich glaube zwar immer noch, dass er ein williger Erfüllungsgehilfe von Sarah ist, aber jetzt sollte vielleicht »Im Zweifel für den Angeklagten« gelten.

Als ich den Phoenix War Room verlasse, fällt mein Blick auf den Raum gegenüber, in dem sich Ann und ihr Team um die falschen Bestellungen kümmern. Ich frage mich, wie es ihnen ergeht.

Immer noch an meinem Bagel aus dem Meeting kauend, klopfe ich an und trete ein. Seit Samstag gab es kontinuierlich Lieferungen von Pizzas, Teilchen, Cola und Kaffee, um alle bei der Stange zu halten.

Vor mir tut sich eine Szene leidenschaftlicher Aktivitäten auf: Tische sind bedeckt mit Haufen eintreffender Faxe aus den Läden, und zwölf Leute laufen dazwischen hin und her. Jedes Fax ist eine Bestellung mit einem Problem, die darauf wartet, an eine kleine Armee von Finanz- und Kundenbetreuern weitergeleitet zu werden, die dafür zwangsrekrutiert wurden. Dort werden dann bei den fehlerhaften Transaktionen entweder die doppelten Vorgänge gelöscht, oder die gesamte Aktion wird rückgängig gemacht.

Vier Finance-Mitarbeiter sitzen an einem weiteren Tisch. Sie nutzen ihre Laptops und Taschenrechner, um die Bestellungen manuell aufzusummieren und herauszufinden, wie groß das Desaster ist und was alles hin- und hergeschoben werden muss, um Fehler auszugleichen.

An der Wand werden die Gesamtsummen aufgeführt. Aktuell sind bei über 5000 Kunden entweder doppelte Bezahlvorgänge ausgelöst worden oder Bestellungen verloren gegangen – und es müssen noch 25000 Transaktionen überprüft werden.

Ungläubig schüttele ich den Kopf. Steve hat recht. Dieses Mal haben wir es uns mit den Kunden so richtig verdorben. Es ist einfach nur peinlich.

Andererseits muss ich den Finance-Kollegen Respekt zollen, die gerade mit dem ganzen Chaos kämpfen. Es sieht organisiert aus, und die Leute tun das, was nötig ist.

Eine Stimme neben mir sagt: »Noch ein Phoenix-Wrack, hm?«

Es ist John, der wie ich die Szenerie beobachtet. Er sagt nicht: »Ich habe es doch gesagt«, aber fast. Wie immer trägt er seinen schwarzen Ordner unter dem Arm.

John schlägt sich die Hand vor die Stirn. »Wenn das unserer Konkurrenz passiert wäre, hätte ich mich totgelacht. Ich habe Chris immer wieder davor gewarnt, aber er wollte nicht zuhören. Jetzt müssen wir dafür bluten.«

Er geht zu einem der Tische und schaut den Leuten dort über die Schultern. Ich sehe, wie er sich plötzlich anspannt, einen Stapel Dokumente durchblättert und bleich wird.

Er kommt zu mir zurück und flüstert mir zu: »Bill, wir haben ein Riesenproblem. Wir müssen reden – auf dem Flur.«

Als wir draußen stehen, flüstert er: »Schauen Sie sich diese Bestellung an. Sehen Sie das Problem?«

Ich überfliege die Seite. Es handelt sich um ein eingescanntes Bestellformular, leicht verzerrt und mit schlechter Auflösung. Darauf eine Rechnung für verschiedene Autoteile mit einer vernünftig aussehenden Gesamtsumme von 53 Dollar.

Ich sage: »Warum sagen Sie es mir nicht einfach?«

John zeigt auf eine handgeschriebene Nummer, die neben die gescannte Kreditkartennummer und die Unterschrift des Kunden gekritzelt ist. »Diese dreistellige Nummer ist der CVV2-Code von der Rückseite der Kreditkarte. Er dient dazu, Betrügereien zu verhindern. Laut den Regeln der Payment Card Industry dürfen wir nichts von Spur 2 des Magnetstreifens speichern oder übertragen. Selbst der Besitz dieser Daten ist automatisch ein Vertragsbruch, der zu einer Strafe führt. Vielleicht sogar zu weiteren Erwähnungen auf den Titelseiten der Zeitungen.«

Oh nein, nicht schon wieder.

Er fährt fort, nachdem er anscheinend meine Gedanken lesen konnte. »Doch, aber dieses Mal ist es schlimmer. Statt nur in der Lokalzeitung zu stehen, stellen Sie sich einmal vor, wie Steve überall dort in den Nachrichten auftaucht, wo wir Geschäfte oder Kunden haben. Und wie er dann nach Washington fliegen muss, um sich von den Senatoren auseinandernehmen zu lassen, die doch nur ihre Wähler schützen wollen.

Das ist wirklich kritisch, Bill. Wir müssen all diese Daten sofort vernichten.«

Ich schüttele den Kopf und sage: »Keine Chance. Wir müssen jede dieser Bestellungen bearbeiten, sodass wir die Konten unserer Kunden nicht doppelt oder gar dreifach belasten. Wir sind dazu gezwungen, denn sonst würden wir unberechtigt Geld von ihnen nehmen, das wir dann zurückzugeben hätten.«

John legt eine Hand auf meine Schulter. »Das mag wichtig erscheinen, aber es ist nur die Spitze des Eisbergs. Wir stecken schon tief in der Scheiße, weil die Phoenix-Website Kreditkartendaten preisgegeben hat. Aber dieses Problem hier ist mindestens genauso kritisch. Wir werden nach der Anzahl der betroffenen Kartenbesitzer bestraft.«

Er zeigt auf die ganzen Papiere und sagt: »Das könnte unsere Strafe mehr als verdoppeln. Und sind Sie nicht auch der Meinung, dass unsere Audits schon übel genug sind? Das wird sie noch viel schmerzhafter machen, weil sie uns bis in alle Ewigkeit als Level-1-Händler klassifizieren werden. Dann werden vielleicht unsere Transaktionsgebühren von drei Prozent auf wer-weiß-wie-viel hochgesetzt. Damit würden sich die Gewinne aus den Filialen halbieren und ...«

Er hält mitten im Satz inne und öffnet ein Kalenderblatt in seinem Ordner. »Oh Scheiße! Die PCI-Auditoren sind heute hier, um einen Businessprozess-Walkthrough durchzuführen. Sie sind im zweiten Stock und unterhalten sich mit den Kollegen, die sich um die Bestellungen kümmern. Eigentlich sollten sie sogar diesen Besprechungsraum nutzen!«

»Sie machen Witze«, sage ich und fühle Panik in mir aufsteigen. Erstaunlich eigentlich, nach drei Tagen mehr oder weniger durchgehenden Adrenalinschüben.

Ich drehe mich zu dem Raum um und kann durch die Fenster ziemlich deutlich die Finance-Kollegen sehen, die gerade die fehlerhaften Bestellungen bearbeiten. Mist.

»Ich weiß«, sage ich, »dass die Leute manchmal der Meinung sind, Sie wären nicht auf unserer Seite, aber ich brauche wirklich Ihre Hilfe. Sie müssen die Auditoren aus diesem Flur fernhalten. Besser noch aus diesem Gebäude. Ich werde ein paar Gardinen an die Fenster hängen oder die Tür verbarrikadieren.«

John sieht mich an und nickt dann. »Okay, ich kümmere mich um die Auditoren. Aber ich glaube, Sie haben immer noch nicht vollständig verstanden. Als Verwalter der Kartendaten können wir nicht Hunderten von Leuten Zugriff darauf gewähren. Das Risiko von Diebstahl und Betrug ist viel zu groß. Wir müssen die Daten sofort vernichten.«

Ich kann mir nicht helfen, aber angesichts des stetigen Zustroms an Problemen muss ich lachen.

Mich wieder auf das aktuelle Problem konzentrierend, sage ich langsam: »Okay, ich werde dafür sorgen, dass die Finance-Leute das verstehen und sich entsprechend darum kümmern. Vielleicht können wir all die Unterlagen scannen und zur Dateneingabe an eine andere Firma schicken.«

»Nein, nein, das ist noch schlimmer!«, sagt John. »Denken Sie daran, wir dürfen die Daten nicht übertragen – erst recht nicht an eine Fremdfirma. Verstanden? Hören Sie, damit wir alles glaubhaft abstreiten können, werde ich so tun, als hätte ich das gerade eben nicht gehört. Sie müssen sich überlegen, wie wir all diese verbotenen Daten vernichten!«

Ich ärgere mich über Johns Bemerkung zum glaubhaften Leugnen – egal ob das gut gemeint war oder nicht. Ich atme tief durch und sage dann: »Halten Sie diese Auditoren von dieser Etage fern, ich kümmere mich um die Kartendaten. Okay?«

Er nickt und sagt: »Roger. Ich werde Sie anrufen, wenn ich die Auditoren irgendwo sicher untergebracht habe.«

Während ich ihn dabei beobachte, wie er zügig zu den Treppen geht, denke ich immer wieder: »Er macht nur seinen Job. Er macht nur seinen Job.«

Ich fluche leise, wende mich dann wieder dem Besprechungsraum zu – und sehe das große Plakat an der Tür: »Phoenix POS Recovery War Room«

Plötzlich fühle ich mich wie in dem Film Immer Ärger mit Bernie, in dem zwei junge Männer fortlaufend versuchen, eine Leiche vor einem Auftragsmörder zu verstecken. Dann frage ich mich, ob es nicht eher so etwas wie das tagelange Schreddern von Dokumenten ist, das angeblich in den Büros von Arthur Andersen stattfand – der Audit-Firma, die nach dem Enron-Desaster mit den Untersuchungen beauftragt war. Bin ich ein Komplize beim Vernichten wichtiger Beweise?

Was für ein Chaos. Ich schüttele den Kopf und gehe zurück in den Besprechungsraum, um die schlechten Neuigkeiten zu überbringen.

Im NOC bin ich erst wieder um 14:30, wo ich einen Blick auf das Drama erhaschen kann, während ich zu meinem Büro gehe. Sieben weitere Tische wurden hereingebracht, um mehr Besprechungsmöglichkeiten zu haben, und an allen sitzen Kollegen. Auf vielen der Tische und in den Ecken des Raums stapeln sich leere Pizzakartons.

Ich lasse mich auf meinen Stuhl fallen und seufze schwer. Fast eine Stunde habe ich mit Anns Team wegen der Kartendaten verbracht und dann eine weitere halbe Stunde, um ihnen zu erklären, dass dies nun wirklich ihr Problem sei und nicht meines. Ich würde gern helfen, aber mein Team ist zu sehr damit beschäftigt, Phoenix am Laufen zu halten, als dass sie noch irgendeine Aufgabe übernehmen könnten.

Ein wenig überrascht stelle ich fest, dass dies das erste Mal war, dass ich in meiner neuen Rolle zu jemandem »Nein« sagen konnte. Ich frage mich, ob ich das auch hätte tun können, wenn meine Leute nicht im Alleingang unsere Bestellsysteme am Leben erhalten würden.

Während ich darüber sinniere, klingelt mein Telefon. Es ist John. Ich gehe direkt ran, weil ich wissen will, wie es bei ihm aussieht. »Hey John, wie geht es?«

John antwortet: »Nicht schlecht. Ich habe die Auditoren hier in der Nähe meines Büros in Gebäude 7 untergebracht. Zudem habe ich dafür gesorgt, dass alle Gespräche hier geführt werden. Sie werden dem Phoenix War Room nicht nahe kommen, und die Sicherheitsleute in Gebäude 9 habe ich explizit angewiesen, sie nicht hereinzulassen.«

Ich muss darüber grinsen, wie John die Regeln zurechtbiegt. »Das ist super. Vielen Dank, dass Sie das in die Hand genommen haben. Allerdings denke ich, dass Ann trotzdem noch Ihre Hilfe brauchen könnte, um herauszufinden, was sie genau tun muss, um die Regeln zu den Kreditkarten einhalten zu können. Ich habe zwar so gut ich konnte geholfen, aber ...«

John sagt: »Kein Problem, ich helfe da gern.«

Er zögert einen Moment. »Ich hasse es, das jetzt zu erwähnen, aber Sie sollten eigentlich heute dem internen Audit Ihre Antwort auf das SOX-404-Audit zukommen lassen. Wie sieht es damit aus?«

Ich breche in schallendes Gelächter aus. »John, unser Plan war, diesen Bericht am Wochenende nach dem Phoenix-Deployment zu schreiben. Aber wie Sie wissen, lief es nicht ganz so wie gedacht. Ich bezweifle, dass irgendjemand da seit Freitag dran gearbeitet hat.«

Sehr besorgt sagt John: »Sie wissen, dass das gesamte Audit-Komitee da einen Blick drauf hat? Wenn wir diese Deadline nicht schaffen, ist das wie eine große rote Warnlampe, die darauf hinweist, dass wir ernsthafte Probleme mit den Sicherungsmaßnahmen haben. Zudem könnte dies das externe Audit deutlich verlängern.«

Ich sage so vernünftig wie möglich: »Vertrauen Sie mir – wenn ich irgendetwas tun könnte, würde ich das. Aber aktuell arbeitet mein gesamtes Team rund um die Uhr daran, den Schaden zu reparieren, den Phoenix verursacht hat. Selbst wenn der Bericht fertig wäre und ich ihn mir nur noch nehmen müsste, könnte ich es nicht. Wir sind total unter Wasser.«

Während ich rede, wird mir klar, wie befreiend es ist, zu erklären, dass mein Team so sehr am Rande seiner Möglichkeiten ist, dass nicht einmal die kleinste zusätzliche Aufgabe drin wäre – und dass mir tatsächlich geglaubt wird.

Ich höre, wie John sagt: »Ich kann hier noch zwei Techniker loseisen. Vielleicht können die ja ein bisschen Zuarbeit beim Ermitteln der Aufwände leisten? Oder wir können sie sogar in den Ressourcenpool stecken, um beim Aufräumen rund um Phoenix zu helfen. Sie sind beide technisch sehr erfahren.«

Ich horche auf. Wir haben jede verfügbare Person in dieser Situation beschäftigt, und fast jeder hat mindestens eine Nacht durchgemacht. Manche kümmern sich um fragile Services oder Systeme, andere helfen QA dabei, Systeme aufzusetzen und Tests zu schreiben, während weitere die Entwicklung dabei unterstützt, Probleme zu reproduzieren.

Ich sage sofort: »Das wäre ausgesprochen hilfreich. Schicken Sie Wes eine E-Mail mit ein paar Stichpunkten zu jedem Ihrer Leute. Wenn er ihre Skills nicht direkt einsetzen kann, können sie aber immer noch an den Aufwandsschätzungen arbeiten, solange damit niemand von Phoenix abgehalten wird.«

»Okay, super«, sagt John. »Ich werde die Infos nachher an Wes schicken und Sie wissen lassen, was wir beide uns dann überlegt haben.«

Er legt auf, und ich freue mich über den glücklichen Zufall, dass tatsächlich jemand an dem Audit-Bericht arbeiten könnte.

Dann frage ich mich, ob ich langsam schwach werde. Irgendetwas stimmt nicht, wenn ich am gleichen Tag Gründe finde, der Entwicklung und dem Sicherheitsteam danken zu können.

KAPITEL 14

Dienstag, 16. September

Am späten Montagabend haben wir die Situation stabilisiert. Zusammen mit Chris’ Team haben wir es geschafft, dass die Läden endlich wieder funktionierende Kassen haben, aber jeder weiß, dass das nur mit einem vorläufigen Fix möglich war. Zumindest müssen wir – sehr zur Erleichterung von John – jetzt keine kritischen Kartendaten mehr verarbeiten.

Es ist 10:37, und ich stehe mit Chris vor Steves Büro. Chris schaut, an der Wand lehnend, gedankenverloren auf den Boden. Ann, John und Kirsten sind auch da und warten darauf, hereingerufen zu werden – wie Schüler, die etwas angestellt haben.

Die Tür zu Steves Büro öffnet sich, und Sarah kommt heraus. Sie sieht aschfahl aus und kämpft mit den Tränen. Sarah musste als Erste hinein, und bei ihr dauerte es nicht einmal die geplanten zehn Minuten.

Sie zieht die Tür hinter sich zu, atmet aus und sagt zu Chris und mir: »Sie sind die nächsten.«

»Das wird schon schiefgehen ...«, sage ich und öffne die Tür.

Steve steht am Fenster und lässt seinen Blick über das Firmengelände schweifen. »Meine Herren, setzen Sie sich.«

Als wir sitzen, beginnt Steve damit, vor uns auf und ab zu gehen. »Ich habe mit Sarah gesprochen. Als Projektleiterin mache ich sie für Erfolg und Misserfolg von Phoenix verantwortlich. Ich weiß nicht, ob ich hier ein Führungsproblem habe oder ob sie nur die falschen Leute an Bord hatte.«

Mir fällt die Kinnlade herunter. Hat Sarah es geschafft, sich irgendwie aus diesem Desaster herauszuwinden? Das Ganze ist doch ihr Fehler!

Steve wendet sich Chris zu. »Wir haben über 20 Millionen Dollar in dieses Projekt gesteckt, und den Großteil davon hat Ihr Team verbraucht. Und jetzt sieht es für mich so aus, als wenn es besser wäre, wir hätten gar nichts vorzuzeigen. Stattdessen muss die halbe Firma Ihre Scherben zusammenkehren.«

Er wendet uns den Rücken zu und fährt fort: »In den guten Jahren waren wir eine Firma mit fünf Prozent Marge. Um eine Million Dollar zu machen, mussten wir also Produkte für 20 Millionen Dollar verkaufen. Wer weiß, wie viele Käufe dieses Wochenende nicht getätigt wurden und wie viele loyale Kunden wir für immer verloren haben.«

Erneut läuft er auf und ab. »Wir haben unseren Kunden einen wahrlich schlechten Service geboten. Das sind Leute, die ihr Auto reparieren müssen, um damit zur Arbeit zu kommen. Väter, die mit ihren Kindern an etwas werkeln. Zudem haben wir ein paar unserer besten Lieferanten und Großabnehmer verprellt.

Um die Leute zu beruhigen, die sich tatsächlich mit Phoenix herumgeschlagen haben, gibt die Marketingabteilung jetzt 100-Dollar-Gutscheine aus. Das kostet uns Millionen. Eigentlich sollten wir Geld von unseren Kunden bekommen, nicht umgekehrt!«

Als ehemaliger Sergeant weiß ich, dass es manchmal richtig ist, jemanden zu tadeln, aber was zu viel ist, ist zu viel. »Nichts für ungut, Steve, aber meinen Sie, das wäre mir neu? Ich habe Sie angerufen, erklärt, was passieren würde, und Sie gebeten, den Launch zu verschieben. Aber Sie haben mich nicht nur abblitzen lassen, sondern mir auch noch gesagt, ich solle Sarah überzeugen. Wo ist denn hier Ihre Verantwortung? Oder haben Sie all Ihr Denken ihr überlassen?«

Während ich rede, merke ich, dass ich vielleicht einen großen Fehler mache, zu sagen, was ich wirklich denke. Vielleicht sind es die Wochen durchgehender Adrenalinschübe, aber es ist ein gutes Gefühl, Steve die Meinung zu geigen. Ein richtig gutes Gefühl.

Steve bleibt abrupt stehen und zeigt mit dem Finger auf meine Stirn. »Ich weiß mehr über Verantwortung, als Sie vielleicht in Ihrem ganzen Leben lernen werden. Ich bin es leid, dass Sie nur kreischend herumlaufen, weil Sie Angst haben, dass Ihnen der Himmel auf den Kopf fällt, um danach glücklich sagen zu können: ›Ich habe es doch gewusst!‹. Ich brauche von Ihnen Lösungen.«

Ich lehne mich vor und sage: »Ich habe genau beschrieben, was passieren wird, als Ihre spezielle Freundin Sarah vor fast zwei Wochen mit diesem verrückten Plan ankam. Ich habe einen Zeitplan vorgeschlagen, der all diese Probleme verhindert hätte. Sie wollen mir erzählen, ich hätte es besser machen können? Ich bin ganz Ohr.« Mit übertriebenem Respekt füge ich noch hinzu: »Sir.«

»Ich werde Ihnen sagen, was ich von Ihnen brauche«, antwortet er ruhig. »Ich brauche Geschäftsbereiche, die mir erklären, dass sie sich nicht länger als Geiseln von euch IT-Leuten fühlen. Das höre ich nämlich ständig, seit ich CEO bin. IT steht jedem größeren Projekt im Weg. Währenddessen ziehen unsere Konkurrenten an uns vorbei, und wir bleiben im Staub zurück. Wir können ja verdammt noch mal nicht mal mehr aufs Klo gehen, ohne dass uns IT im Weg ist.«

Er atmet tief durch. »Aber darum sind Sie heute nicht hier. Ich habe Sie herbeordert, um Ihnen zwei Dinge zu erzählen. Erstens hat der Aufsichtsrat dank dieser letzten IT-Katastrophe darauf bestanden, dass wir auf ein Aufsplitten der Firma hinarbeiten. Er ist der Meinung, dass sie mehr wert ist, wenn sie in Einzelteilen verkauft wird. Ich bin dagegen, aber es wurden sogar schon Berater auf uns gehetzt, die die Machbarkeit prüfen. Dagegen kann ich nichts tun.

Zweitens habe ich es satt, russisches Roulette mit der IT zu spielen. Phoenix hat mir gezeigt, dass die IT hier anscheinend nicht sinnvoll aufgehoben ist. Vielleicht liegt es uns nicht im Blut. Ich habe Dick grünes Licht gegeben, das Outsourcing von IT zu analysieren und innerhalb von 90 Tagen einen Partner dafür zu finden.«

Die gesamte IT outsourcen. Heilige Scheiße.

Das bedeutet, dass eventuell alle in meiner Abteilung ihren Job verlieren werden.

Das bedeutet, dass ich eventuell keinen Job mehr haben werde.

Plötzlich stelle ich ernüchtert fest, dass die Erleichterung, Steve die Meinung gesagt zu haben, nur eine Illusion ist. Er hat die Macht. Mit einem Fingerschnippen kann er uns alle an den billigsten Anbieter outsourcen, der in der hinterletzten Ecke dieses Planeten sitzt.

Ich schaue zu Chris – er sieht genauso erschüttert aus wie ich.

Steve fährt fort: »Ich erwarte von Ihnen, dass Sie Dick alle Unterstützung zukommen lassen, die er benötigt. Wenn Sie in den nächsten 90 Tagen noch ein Wunder geschehen lassen können, werden wir uns vielleicht überlegen, die IT doch nicht auszulagern.

Vielen Dank, die Herren. Bitte schicken Sie Kirsten herein«, sagt er abschließend.

»Entschuldige bitte meine Verspätung«, sage ich, als ich mich in den Sessel gegenüber von Chris fallen lasse. Geschockt von unserem Gespräch mit Steve, haben wir beide uns zum Essen verabredet. Vor ihm steht irgendein bunter Drink mit einem Schirmchen. Ich hatte ihn mir immer eher als ehrlichen Trinker vorgestellt – mehr »Pabst Blue Ribbon«-Bier als Cocktails von einer Junggesellinnenparty.

Er lacht humorlos. »Glaub mir, deine zehn Minuten Verspätung sind das kleinste meiner Probleme. Bestell dir einen Drink.«

Paige hat mir wiederholt nahegelegt, dass ich dem Kerl nicht trauen soll. Sie hat ein gutes Gespür für Menschen, und wenn es um mich geht, ist sie unerträglich beschützend, was mich immer amüsiert. Denn schließlich bin ich der Ex-Marine und sie nur eine »liebe Krankenschwester«.

»Ein Pils bitte«, sage ich zur Bedienung, »und einen Scotch und ein Wasser. Es war ein harter Tag.«

»Das habe ich schon gehört. Kein Problem«, antwortet sie lachend. Chris fragt sie: »Noch einen Mai Tai für Sie?«

Er nickt und reicht ihr sein leeres Glas. So sieht also ein Mai Tai aus. Ich habe noch nie einen probiert. Wir Marines achten sehr darauf, mit was für einem Getränk man uns sieht.

Chris hebt sein Wasserglas und sagt: »Auf ein gemeinsames Todesurteil.«

Ich lächle matt und hebe ebenfalls mein Glas. Da ich das Gefühl habe, etwas Optimismus ins Spiel bringen zu müssen, sage ich: »Und darauf, dass wir einen Weg finden, den Vollzug auszusetzen.«

Wir stoßen an.

»Weißt du, ich habe nachgedacht«, sagt Chris. »Vielleicht wäre es gar nicht so schlimm, wenn meine Gruppe outgesourct würde. Ich bin schon fast mein ganzes Berufsleben in der Softwareentwicklung. Ich habe mich daran gewöhnt, dass mir Wunder abverlangt werden, das Unmögliche erwartet wird und die Leute die Anforderungen in letzter Sekunde ändern, aber nach diesem Albtraumprojekt frage ich mich, ob es nicht Zeit für etwas Neues wäre ...«

Ich kann es nicht glauben. Chris war immer zuversichtlich, manchmal sogar arrogant, und schien seine Arbeit zu lieben. »Was für eine Art Neues? Überlegst du, in Florida eine Mai-Tai-Bar zu eröffnen oder so etwas?«

Chris zuckt die Schultern. Als er auf den Tisch starrt, kann ich die Ringe unter den Augen und die Müdigkeit in seinem Gesicht sehen. »Mir hat meine Arbeit immer Spaß gemacht, aber in den letzten zehn Jahren wurde es viel schwerer. Die Technologie ändert sich immer schneller, und es ist fast unmöglich, da mitzuhalten.«

Die Bedienung kommt mit unseren Drinks. Ein Teil von mir fühlt sich schuldig, weil ich zur Arbeitszeit trinke, aber ich sage mir, dass ich es verdient habe, denn in den letzten zwei Wochen habe ich genug Freizeit in die Firma gesteckt. Chris nimmt einen großen Schluck – und ich auch.

Er fährt fort: »Es ist Wahnsinn, was Programmierer und selbst Manager wie ich alle paar Jahre lernen müssen. Mal ist es eine komplett neue Datenbanktechnologie, mal eine neue Programmier- oder Projektmanagement-Methode oder mal ein neues Delivery-Modell wie das Cloud Computing.

Wie oft kannst du all dein Wissen in die Tonne treten, um mit dem neuesten Scheiß weiterzumachen? Ich schaue manchmal in den Spiegel und frage mich: ›Wirst du dieses Jahr aufgeben? Wirst du den Rest deiner Karriere COBOL-Programme betreuen oder einfach nur ein weiterer ehemaliger Middle Manager werden?‹«

Ich lache mitfühlend. Ich hatte mich dazu entschieden, im technologischen Kielwasser mitzuschwimmen. Da fühlte ich mich wohl. Bis mich Steve zurück in das große Haifischbecken warf.

Er schüttelt den Kopf und führt fort: »Es ist immer schwerer, das Business davon zu überzeugen, das Richtige zu tun. Die benehmen sich wie Kinder im Süßigkeitenladen. Sie lesen auf dem Flug in einer Zeitschrift, dass sie ihre ganze Lieferkette in der Cloud für 499 Dollar pro Jahr verwalten können, und plötzlich ist das das wichtigste Projekt der ganzen Firma. Wenn wir ihnen dann erzählen, dass es in Wirklichkeit nicht ganz so einfach ist, und ihnen zeigen, was notwendig ist, um es richtig zu machen, sind sie verschwunden. Wohin? Sie reden mit ihrem Cousin Vinnie oder irgendeinem Verkäufer einer Outsourcing-Firma, der ihnen verspricht, dass sich das alles in einem Bruchteil der Zeit für viel weniger Geld machen lässt.«

Ich lache. »Vor ein paar Jahren hat irgendjemand in der Marketingabteilung meine Gruppe gebeten, ein Datenbank-Berichtstool zu betreuen, das eine ihrer Praktikantinnen geschrieben hat. Es war tatsächlich ziemlich gut – angesichts der paar Monate, die sie dort war. Schließlich wurde es sogar in der täglichen Arbeit eingesetzt. Aber wie betreut und vor allem sichert man etwas ab, das in Microsoft Access geschrieben ist? Als die Auditoren herausfanden, dass wir gar nicht für alle Daten den Zugriff beschränken konnten, haben wir Wochen damit verbracht, etwas zusammenzuschrauben, mit dem sie zufrieden waren.

Es ist wie mit dem Hund aus dem Tierheim«, fahre ich fort. »Die Anschaffungskosten sind nicht das Problem, sondern das operative Geschäft und die Wartung, die die Probleme bereiten.«

Chris muss lachen. »Ja, genau! Sie sagen dann: ›Das Hündchen kann fast alles, was wir brauchen. Könnt ihr ihm noch beibringen, ein Flugzeug zu steuern? Das ist doch nur ein bisschen Code, oder?‹«

Nachdem wir das Essen bestellt haben, erzähle ich ihm, wie zögernd ich meine neue Aufgabe akzeptiert habe und was für Probleme ich damit habe, alle Zusagen zusammenzutragen, die meine Gruppe gegeben hat.

»Interessant«, sagt Chris. »Weißt du, wir kämpfen im Moment auch. Wir hatten noch nie solche Probleme, unsere Liefertermine zu halten. Meine Entwickler müssen immer wieder die eigentliche Entwicklung liegen lassen, um Eskalationen zu bekämpfen, wenn irgendetwas kaputtgegangen ist. Und die Deployments dauern länger und länger. Was früher zehn Minuten brauchte, dauerte dann eine Stunde. Dann einen ganzen Tag, ein ganzes Wochenende, dann vier Tage. Ich habe sogar Deployments, die über eine Woche brauchen, bis sie abgeschlossen sind. Wie Phoenix.«

Er fährt fort: »Was nützt es, wenn alle diese Offshore-Entwickler Features bauen, wenn wir sie nicht schnell genug bereitstellen können? Wir verlängern schon die Deployment-Abstände, um jeweils mehr Features liefern zu können.«

Er lacht. »Letzte Woche war ich in einem Meeting, in dem das Feature-Backlog so lang war, dass die Produktmanager darüber diskutierten, an welchen Features in drei Jahren gearbeitet werden soll! Wir können nicht einmal für das nächste Jahr sinnvoll planen, wie soll das dann für drei Jahre gehen? Was bringt uns das?«

Ich höre aufmerksam zu. Bei Phoenix kam es zu einer Kombination aus der Notwendigkeit, bestimmte Features auszuliefern, und dem Zwang zu schmutzigen Hacks, die zu solch katastrophalen Deployments führen. Chris beschreibt eine Abwärtsspirale, aus der wir ausbrechen müssen.

»Hör zu, Bill, ich weiß, dass es jetzt ein bisschen zu spät ist, das zu sagen, aber besser spät als nie. Mir tut mein Anteil am Phoenix-Fiasko wirklich leid. Sarah kam eine Woche vor Kirstens Projektmanagement-Meeting zu mir und fragte mich alles Mögliche. Sie wollte wissen, wann der Code frühestens vollständig sein könnte. Ich hatte keine Ahnung, dass sie das als Go-Live-Datum nutzen würde – insbesondere mit Steve im Raum. William hat vorhergesagt, dass das zu einem Desaster führen würde, und ich hätte auf ihn hören sollen. Da habe ich damals die falschen Entscheidungen getroffen.«

Ich schaue ihm in die Augen und entscheide, ihm zu glauben. Ich nicke und sage: »Danke. Mach dir darum keine Sorgen.«

Dann füge ich hinzu: »Aber mach das nie wieder. Denn wenn das noch mal passiert, breche ich dir beide Beine und sorge dafür, dass Wes bei jedem deiner Mitarbeiter-Meetings dabei ist. Ich weiß nicht, was davon schlimmer ist.«

Chris grinst und hebt sein Glas. »Auf dass so etwas nie wieder passiert!«

Ein guter Gedanke. Ich lächle und stoße mit ihm an.

Nachdem ich mein zweites Bier geleert habe, sage ich: »Weißt du, ich mache mir Sorgen, dass Sarah versuchen wird, uns die ganze Schuld in die Schuhe zu schieben.«

Chris schaut von seinem Glas auf und sagt: »Sie ist wie Teflon. Alles perlt an ihr ab. Wir müssen zusammenhalten. Ich halte dir den Rücken frei und unterstütze dich, wenn ich mitbekomme, dass sie wieder ihren politischen Dreck durchziehen will.« »Und umgekehrt«, sage ich nachdrücklich.

Ich schaue auf meine Uhr. Es ist 13:20. Zeit, wieder ins Büro zu gehen, daher gebe ich der Bedienung ein Zeichen, dass wir zahlen wollen. »Das war super. Wir sollten das häufiger machen. Wie wäre es, wenn wir uns einmal die Woche treffen und uns überlegen, was wir gegen diese dämliche Idee tun können, die gesamte IT outzusourcen?«

»Auf jeden Fall«, sagt er. »Ich weiß nicht, wie es bei dir ist, aber ich werde das nicht einfach hinnehmen. Ich werde kämpfen.«

Darauf schütteln wir uns die Hände.

Obwohl ich etwas gegessen habe, ist mir noch schwummerig. Ich sollte mir besser ein paar Pfefferminzbonbons besorgen, damit ich nicht so rieche, als ob ich den ganzen Morgen in einer Kneipe verbracht hätte.

Ich schaue mir meinen Kalender auf dem Handy an und verschiebe alle Meetings auf einen späteren Zeitpunkt. Um 16 Uhr bin ich immer noch im Büro, als ich eine E-Mail von Chris bekomme.

Von: Chris Allers

An: Bill Palmer

Datum: 16. September, 20:15

Betreff: Kleine Post-Phoenix-Party

Hallo Bill!

Das Mittagessen war gut – ich habe mich sehr wohlgefühlt.

Wir schmeißen eine kleine improvisierte Party, um die Fertigstellung von Phoenix zu feiern. Nichts Besonderes, aber ich habe ein Bierfass, etwas Wein und ein paar Knabbereien besorgt, und wir treffen uns gerade im Pausenraum von Gebäude 7.

Es wäre schön, wenn ihr dazustoßen könntet. Meiner Meinung nach war es eines der besten Teamergebnisse, die ich in dieser Firma gesehen habe. Es ist auch genug für jeden in deinem Team da. :-)

Bis dann,

Chris

Ich finde die Geste von Chris wirklich gut und denke, dass auch mein Team das so sehen wird. Insbesondere Wes. Ich leite die E-Mail an Wes und Patty weiter und fordere sie auf, jeden zu bitten, vorbeizukommen. Sie haben es sich verdient.

Kurz darauf brummt mein Telefon. Eine Antwort von Wes:

Von: Wes Davis

An: Bill Palmer, Patty McKee

Datum: 16. September, 20:15

Betreff: Re: Fwd: Kleine Post-Phoenix-Party

Was für ein Arschloch. Die meisten meiner Leute werden keine Zeit dafür haben. Wir sind immer noch damit beschäftigt, all die kaputten Transaktionsdaten zu reparieren, die deren beschissener Code erzeugt hat. Es muss nett sein, sich den Luxus solch einer Feier leisten zu können. »Mission erfüllt« und so, stimmt’s?

W

Ich seufze. Für Chris’ Leute in den oberen Kabinen mag die Krise ausgestanden sein, aber wir hier im Maschinenraum pumpen immer noch Wasser ab.

Trotzdem denke ich, es ist wichtig, dass unsere Leute bei der Party vorbeischauen. Um erfolgreicher zu sein, müssen wir die Beziehung zu Chris’ Team verbessern. Und wenn es nur für eine halbe Stunde ist.

Ich knirsche mit den Zähnen und rufe Wes an. Wie Spock einmal gesagt hat: »Nur Nixon konnte nach China gehen.« Und anscheinend bin ich Nixon.

KAPITEL 15

Mittwoch, 17. September

Auch wenn ich nicht den ganzen Tag freinehmen kann, lade ich Paige zum Frühstück ein. Sie kümmert sich im Moment alleine um den Haushalt und die Kinder, während ich jede wache Minute bei der Arbeit verbringe.

Wir sind bei Mother’s, einem unserer Lieblingsfrühstücksläden. Schon bei der Eröffnung vor nahezu acht Jahren waren wir hier. Die Besitzerin hat seitdem viel Erfolg gehabt. Nicht nur, dass das Restaurant in der Stadt inzwischen sehr beliebt ist – sie hat auch noch ein Kochbuch geschrieben, und wir haben sie auf ihrer Lesereise immer wieder im Fernsehen gesehen.

Wir freuen uns sehr über ihren Erfolg. Und ich weiß, dass Paige es liebt, wenn die Besitzerin uns wiedererkennt, auch wenn es voll ist.

Ich schaue Paige in die Augen, während wir uns gegenübersitzen. Das Restaurant ist für einen Dienstagmorgen erstaunlich voll. Die Leute treffen sich geschäftlich, und die Hipster tun – nun, das, was Hipster so morgens tun. Arbeiten? Spielen? Ich habe keine Ahnung.

Mit ihrem Mimosa in der Hand, sagt Paige: »Danke, dass du dir etwas Zeit nimmst – bist du sicher, dass du dir den restlichen Tag nicht auch noch freinehmen kannst?«

Zuerst wollte ich mir keinen Cocktail bestellen, denn ich wollte meinen Arbeitstag nicht mit Alkohol beginnen. Aber wie gestern denke ich mir: »Ach, was soll’s.«

Während ich meinen Sekt mit Orangensaft trinke, lächle ich traurig und schüttle meinen Kopf: »Ich wünschte wirklich, ich könnte, Schatz. Säße ich in der Entwicklung, würde ich dem ganzen Team einen Tag freigeben, so wie Chris es getan hat. Aber in Operations müssen wir immer noch nach dem Phoenix-Fiasko aufräumen. Ich habe keine Ahnung, wann sich das Ganze wieder normalisiert.«

Sie schüttelt langsam den Kopf. »Ich kann gar nicht glauben, dass das erst deine dritte Woche ist. Du hast dich verändert. Ich beschwere mich nicht, aber ich habe dich nicht mehr so gestresst erlebt seit ...«

Sie schaut einen Moment nach oben und denkt nach. Dann sieht sie mich wieder an. »Noch nie! Die Hälfte der Zeit, in der wir im Auto sitzen, siehst du abwesend aus. Die andere Hälfte knirscht du so mit den Zähnen, als würdest du irgendein furchtbares Meeting noch mal durchspielen. Du hörst nicht mehr, was ich sage, weil du so sehr von deiner Arbeit gefangen bist.«

Ich will mich entschuldigen, aber sie schneidet mir das Wort ab. »Ich beschwere mich nicht. Ich will diesen schönen Moment nicht zerstören, in dem wir Zeit für uns haben – ohne Arbeit und ohne Kinder. Aber wenn ich daran denke, wie glücklich du warst, bevor du diese Beförderung akzeptiert hast, frage ich mich, warum du das machst.«

Ich schürze die Lippen. Selbst trotz des ganzen Dramas in den letzten Wochen habe ich das Gefühl, dass die IT-Organisation durch mich schon ein wenig besser geworden ist. Und selbst in Bezug auf das drohende Outsourcing bin ich froh, dass ich einer derjenigen bin, der versucht, es zu verhindern.

Mehr als fünf Jahre lang war ich einer der wenigen, der es geschafft hat, seine Work-Life-Balance im Griff zu haben. Aber die ist jetzt total hin.

Ein befreundeter Unteroffizier hat mir bei den Marines einmal erklärt, was seine Prioritäten sind: Versorger, Vater, Ehemann und Change Agent. In dieser Reihenfolge.

Ich denke darüber nach. Zuallererst bin ich dafür verantwortlich, meine Familie zu versorgen. Meine Gehaltserhöhung wird uns dabei helfen, die Raten für das Haus schneller zurückzahlen zu können. Damit haben wir die Chance, Geld für die Ausbildung unserer Kinder zurückzulegen – etwas, das wir schon immer machen wollten. Es wäre nicht schön, das wieder aufzugeben und das Gefühl zu haben, auf der Stelle zu treten.

Wir beide haben den Verdacht, dass unser Haus jetzt weniger wert ist, als wir dafür bezahlt haben. Vor ein paar Jahren haben wir versucht, es zu verkaufen, um näher zu meinen Schwiegereltern zu ziehen. Aber nach neun Monaten haben wir es wieder vom Markt genommen.

Mit meiner Beförderung können wir unseren zweiten Kredit schneller zurückzahlen. Und vielleicht – nur vielleicht, wenn alles gut geht – könnte Paige in ein paar Jahren aufhören zu arbeiten.

Aber ist das den Preis wert, sich dafür mit Steves tagtäglichen wilden Forderungen nach dem Unmöglichen herumschlagen zu müssen?

Schlimmer noch: Sarah, diese Verrückte, ertragen zu müssen?

»Siehst du! Schon wieder. Lass mich raten«, sagt Paige und unterbricht meine Gedanken. »Du denkst über ein Meeting nach, das du mit Steve hattest, und wie er sich in ein völliges Arschloch verwandelt hat, mit dem man nicht reden kann. Mit Ausnahme dieser Verrückten, Sarah.«

Ich lache. »Woher weißt du das?«

Sie lächelt. »Ganz einfach. Es fängt damit an, dass du irgendwo hinschaust, dann verspannen sich deine Schultern und dein Kiefer, und du presst deine Lippen aufeinander.«

Ich lache erneut.

Paige wirkt nun betrübt. »Ich wünschte, dass sie jemand anderen für diesen Job ausgewählt hätten. Steve wusste genau, wie er dich dazu kriegen würde, Ja zu sagen. Er ließ es so aussehen, als ob es deine Pflicht wäre, seinen Job und die Firma zu retten.«

Ich nicke langsam. »Aber Schatz, jetzt ist es tatsächlich so – wenn sie die ganze IT outsourcen, verlieren eventuell fast 200 Leute in meiner Gruppe ihre Arbeit, oder sie müssen für irgendeine gesichtslose Outsourcing-Firma arbeiten. Und weitere 200 Leute in Chris’ Team. Ich habe wirklich das Gefühl, dass ich das noch verhindern kann.«

Sie sieht mich zweifelnd an. »Du glaubst wirklich, ihr beide könnt das aufhalten? Denn angesichts dessen, was du erzählt hast, sieht es so aus, als ob die Entscheidung schon längst gefallen ist.«

Nachdem ich eine bedrückte Paige zu Hause abgesetzt habe, bleibe ich einen Moment in der Auffahrt stehen, um einen Blick auf meine E-Mails zu werfen, bevor ich wieder ins Büro fahre.

Ich bin überrascht, eine begeisterte E-Mail von Wes erhalten zu haben.

Von: Wes Davis

An: Bill Palmer, Patty McKee

Datum: 19. September, 09:45

Betreff: Fwd: Puh! Beinahe-Chaos dank Change-Management verhindert

Schaut euch das an, Leute. Einer der DBAs hat diese Mail heute Morgen an alle Techniker geschickt.

>>> Begin forwarded message:

Leute, der neue Change-Management-Prozess hat uns heute den Hintern gerettet. Zwei Gruppen wollten gleichzeitig Änderungen an der Materials Management-Datenbank und den Anwendungsservern durchführen. Keine Gruppe wusste von der anderen.

Rajiv hat die potenzielle Kollision an der Change-Wand erkannt. Wir haben dann entschieden, erst meine Änderung durchzuführen, und als wir fertig waren, habe ich ihn angerufen. Ansonsten hätte das wohl zu einem ziemlichen Durcheinander geführt.

Schreibt also weiter fleißig eure Kärtchen, sie sind echt hilfreich! Vielen Dank an Rajiv, Tom, Shelly und Brent.

Robert

Endlich einmal gute Nachrichten. Eines der Probleme mit der Prävention ist, dass man selten von den Desastern hört, die vermieden wurden.

Aber hier war es so. Sehr schön.

Und noch viel besser: Das kam direkt von einem Techniker, nicht von einem Manager.

Als ich zu meinem Schreibtisch komme, sehe ich den Notizzettel mit der Warnung an meiner Dockingstation und muss lächeln. Ich fahre also erst meinen Laptop hoch und warte geduldig zwei Minuten, bis der Anmeldebildschirm zu sehen ist, bevor ich ihn in die Dockingstation stecke.

Kein wildes Gepiepe. Exakt so, wie ich es aufgeschrieben habe. Auch sehr schön.

Jemand klopft an meine Tür.

Es ist Patty. »Ah, gut, dass du da bist. Hast du eine Minute? Ich glaube, wir haben ein weiteres Problem.«

»Sicher«, sage ich. »Was ist los? Lass mich raten – noch mehr Leute beschweren sich über das Change-Management?«

Patty schüttelt den Kopf und antwortet düster: »Es ist schon ein bisschen ernster. Gehen wir in den Change Coordination Room?«

Ich grummle. Jedes Mal, wenn mich Patty dorthin ruft, gibt es ein neues kniffliges Problem. Aber Probleme sind wie Hundehäufchen im Regen – sie werden selten besser, wenn man sie ignoriert.

Ich stehe auf und sage: »Geh du vor.«

Als wir den Besprechungsraum erreichen, schaue ich auf das Change-Board. Etwas ist anders. »Oh, oh« sage ich.

Patty schaut ebenfalls auf das Board und sagt: »Uh, hu. Offensichtlich, aber trotzdem unerwartet, stimmt’s?«

Ich kann nur zustimmend grummeln.

An dem Board sieht es aus, wie ich es in Erinnerung habe, allerdings nur bis letzten Donnerstag. Jeden Tag gibt es zwischen 40 und 50 Änderungen, die alle als abgeschlossen markiert sind. Aber an den folgenden Tagen gibt es so gut wie keine Änderungen. Als ob jemand alle Karten vom Board gewischt hätte.

»Wo sind die Karten hin?«

Sie zeigt auf ein anderes Board an einer anderen Wand, auf dem steht: »Neu einzuplanende Änderungen«. Darunter steht ein Körbchen, das vor Karten überquillt.

Bestimmt um die 600.

Mir dämmert, was da passiert ist, und ich frage: »Und der Grund, warum keine dieser Änderungen abgeschlossen wurde, ist ...«

Patty verdreht die Augen. »Phoenix, was sonst. All die eingeplante Arbeit musste warten. Wir haben alle, die eine Tastatur bedienen können, gebraucht, um da zu helfen. Und erst jetzt können sich die Leute wieder um ihre normale Arbeit kümmern. Am Board siehst du, dass heute der erste Tag ist, an dem geplante Änderungen tatsächlich wie geplant ausgeführt werden.«

Das scheint aus irgendeinem Grund wichtig zu sein.

Und dann trifft es mich wie ein Schlag.

Vor Kurzem hatte ich Erik angerufen, um ihm zu sagen, dass ich drei der vier Arten von Arbeit erkannt habe: Businessprojekte, interne Projekte und Änderungen. Er antwortete nur, dass es ja noch eine weitere Art von Arbeit gäbe – vielleicht die wichtigste, weil sie so destruktiv sei.

Einen kurzen Moment lang glaube ich zu wissen, welche die vierte Kategorie ist.

Und dann weiß ich es schon wieder nicht mehr. Mein schwaches Verständnis flackert nur noch kurz auf und ist dann ganz verschwunden.

Ich sage: »Verdammt!«

Patty sieht mich fragend an, aber ich ignoriere sie, während ich versuche, mir die Lösung wieder ins Gedächtnis zu rufen.

Ich schaue mir den Teil des Change-Boards an, an dem kaum Karten hängen. Es ist wirklich so, als hätte die Hand eines Riesen all die Karten weggewischt, die wir so liebevoll geplant und auf dem Board arrangiert haben. Und wir kennen diese Hand: Phoenix.

Aber Phoenix ist nicht die vierte Art von Arbeit.

Vielleicht ist das, wonach ich suche, wie dunkle Materie. Man kann sie nur daran erkennen, was sie beeinflusst und wie sie mit anderen Dingen interagiert, die wir sehen können.

Patty hat es als Feuerlöschen bezeichnet. Ich vermute, das ist auch Arbeit. Auf jeden Fall hat es uns ganze Nächte beschäftigt. Und alle geplanten Änderungen beeinflusst.

Ich drehe mich wieder zu Patty um und sage langsam: »Lass mich raten. Brent hat auch keine einzige seiner Nicht-Phoenix-Aufgaben abschließen können, stimmt’s?«

»Natürlich nicht. Du warst doch dabei, oder?«, sagt sie und schaut mich an, als wären mir acht Köpfe gewachsen. »Brent hat rund um die Uhr daran gearbeitet, alles wieder geradezubiegen und die Tools zu bauen, mit denen die Systeme und Daten am Leben bleiben. Alles andere haben wir zurückgestellt.«

All das Feuerlöschen hat die geplante Arbeit verzögert – sowohl Projekte wie auch Änderungen.

Ahh, jetzt wird es wieder klarer.

Was kann geplante Arbeit verzögern?

Ungeplante Arbeit.

Natürlich.

Ich lache laut auf, was mir einen wirklich besorgten Blick von Patty einbringt, die sogar einen Schritt zurücktritt.

Darum hat Erik sie als destruktivste Art von Arbeit bezeichnet. Es ist nicht, wie die anderen Arten, echte Arbeit. Die anderen Arbeiten sind geplant, meist, weil sie getan werden müssen.

Ungeplante Arbeit hindert einen daran, geplante Arbeit zu tun. Wie Materie und Antimaterie geht geplante Arbeit in Anwesenheit ungeplanter Arbeit in Flammen auf und verbrennt zu Asche. Wie bei Phoenix.

So viel von dem, was ich während meiner kurzen Zeit als VP of IT Operations schon umzusetzen versucht habe, hat mit dem Vermeiden ungeplanter Arbeit zu tun: eine bessere Koordination von Änderungen, sodass sie seltener zu Fehlern führen, eine ordentliche Bearbeitung von Zwischenfällen und Ausfällen, um zu verhindern, dass wichtige Ressourcen nicht arbeiten können, alles zu tun, damit Brent nicht sämtliche Eskalationen abbekommt ...

Ich habe das meiste instinktiv getan. Ich wusste, dass das zu tun war, weil die Leute an den falschen Dingen arbeiteten. Ich habe versucht, alle notwendigen Schritte einzuleiten, damit sie das Richtige tun und ungeplante Arbeit vermieden werden kann.

Ich reiße meine Arme in die Luft, als hätte ich das spielentscheidende Tor geschossen, und rufe: »Ja! Jetzt sehe ich es! Die ungeplante Arbeit! Die vierte Art von Arbeit ist die ungeplante Arbeit!«

Meine überschwängliche Stimmung wird etwas gedämpft, als ich Patty sehe, die verwirrt und ernsthaft besorgt aussieht.

»Ich erkläre es später«, sage ich. »Versprochen. Warum wolltest du eigentlich, dass ich herkomme?«

Sie ist völlig verunsichert, zeigt aber auf das leere Board mit den (nicht) abgeschlossenen Änderungen der letzten Woche. »Du warst besorgt, dass 60 Prozent der Änderungen nicht abgeschlossen wurden. Da dachte ich, du würdest völlig durchdrehen, wenn 100 Prozent nicht abgeschlossen wären. Stimmt’s?«

»Ja, stimmt. Super Arbeit, Patty. Mach so weiter!«, sage ich.

Und dann drehe ich mich um und verlasse den Raum, während ich zu meinem Handy greife. Ich muss jemanden anrufen.

»Hey!«, ruft Patty mir hinterher. »Wolltest du mir nicht etwas erklären?«

»Später!«, antworte ich ihr.»Versprochen!«

Zurück an meinem Schreibtisch, stelle ich alles auf den Kopf, weil ich nach dem Papierschnipsel suche, den mir Erik gegeben hat. Ich bin ziemlich sicher, dass ich ihn nicht weggeworfen habe.

Hinter mir sagt Ellen: »Brauchen Sie Hilfe?«

Und bald stöbern wir gemeinsam auf dem Schreibtisch.

»Ist es das hier?«, fragt sie und hält etwas hoch, das sie aus meinem Eingangskorb geborgen hat.

Ich schaue es mir genauer an und – ja! Es handelt sich um den verknitterten Papierstreifen von Erik. Er sieht aus wie Kaugummipapier.

Ich nehme ihr den Streifen ab, halte ihn hoch und sage: »Super! Vielen, vielen Dank, dass Sie ihn gefunden haben – ob Sie es glauben oder nicht, aber das könnte das wichtigste Stück Papier der letzten Jahre sein.«

Für diesen Anruf will ich mich nach draußen setzen. In der warmen Herbstsonne finde ich ein Plätzchen auf einer Bank in der Nähe des Parkplatzes. Als ich mich setze, gibt es keine Wolke am Himmel.

Ich rufe Erik an, der gleich beim ersten Klingeln abhebt. »Hallo, Bill. Wie geht es euch da, nachdem Phoenix so spektakulär abgestürzt und in Flammen aufgegangen ist?«

»Na ja, ganz gut. So langsam wird alles wieder normal«, sage ich. »Sie haben vielleicht gehört, dass unsere POS-Systeme ausgefallen sind und wir ein kleines Problem mit der Anzeige von Kreditkartendaten hatten.«

»Haha! ›Kleines Problem mit den Kreditkartendaten‹. Das gefällt mir. Wie ›Kleine Kernschmelze im Atomreaktor‹. Das muss ich mir merken«, sagt er lachend.

Er kichert, als ob er diese Katastrophe hat kommen sehen, was er – wenn ich das richtig sehe – auch getan hat, als ich ihn das erste Mal in dem Besprechungsraum traf. Irgendetwas mit »Den Kalender freimachen«.

Fast wie »das Change-Board freimachen«, fällt mir auf. Ich könnte mir selbst in den Hintern treten, dass mir das nicht vorher aufgefallen war.

»Ich gehe davon aus, dass Sie mir jetzt etwas über die vier Arten von Arbeit erzählen können?«, höre ich ihn fragen.

»Ja, ich glaube, das kann ich«, sage ich. »In der Fabrikhalle habe ich eine Art genannt – Businessprojekte, wie zum Beispiel Phoenix. Später ist mir aufgefallen, dass ich die internen IT-Projekte vergessen habe. Eine Woche später habe ich gesehen, dass Änderungen eine weitere Art von Arbeit sind. Aber erst nach dem Phoenix-Fiasko habe ich die letzte Art erkannt, denn sie hat dafür gesorgt, dass sämtliche andere Arbeit liegen blieb. Feuerlöschen. Ungeplante Arbeit. Das ist die letzte Kategorie, oder?«

»Ganz genau!«, sagt Erik. »Sie haben sogar den Begriff genutzt, der mir dafür am liebsten ist: ungeplante Arbeit. Feuerlöschen ist eine sehr gute Beschreibung, aber ›ungeplante Arbeit‹ ist noch besser. Sogar besser als ›Anti-Arbeit‹, da die destruktive und vermeidbare Natur der Sache besser hervorgehoben wird.

Anders als die anderen Arten von Arbeit handelt es sich bei ungeplanter Arbeit um eine wiederherstellende Arbeit, die Sie so gut wie immer von Ihren eigentlichen Zielen fernhält. Darum ist es so wichtig, zu wissen, woher Ihre ungeplante Arbeit kommt.«

Ich lächle, als er meine richtige Antwort würdigt, und bin erstaunlich befriedigt, dass er sogar meine Vorstellung von ungeplanter Arbeit als »Antimaterie« bestätigt.

Er sagt: »Was ist dieses Change-Board, das Sie erwähnt haben?«

Ich erzähle ihm von meinen Bemühungen, irgendeine Form von Change-Prozess ans Laufen zu bekommen, und meinem Versuch, von der Diskussion über die Anzahl der Felder auf dem Change-Formular wegzukommen. Das führte dann zu den Karteikarten, auf die die Kollegen ihre Änderungen eintragen, und ich beschreibe das Verwalten der Karten auf dem Board.

»Sehr gut«, sagt er. »Sie haben sich Werkzeuge gesucht, die Arbeit visuell zu verwalten und damit durch das System zu leiten. Das ist ein entscheidender Teil des Ersten Wegs, der für einen schnellen Fluss der Arbeit durch Entwicklung und IT Operations sorgt. Karteikarten auf einem Kanban-Board sind eines der besten Werkzeuge dafür, weil jeder die WIP sehen kann. Jetzt müssen Sie mithilfe des Zweiten Wegs damit weitermachen, Ihre größten Quellen ungeplanter Arbeit auszutrocknen.«

Ich war von den Überlegungen zur Definition von Arbeit so eingenommen, dass ich Eriks Drei Wege ganz vergessen hatte. Da ich sie ignoriert hatte, höre ich jetzt umso genauer hin.

Und in den nächsten 45 Minuten erzähle ich ihm alle Details meiner kurzen Laufbahn als VP, nur unterbrochen durch das laute Lachen von Erik, als ich die kleinen und großen Katastrophen und meine Versuche, das Chaos zu bändigen, beschreibe.

Als ich fertig bin, sagt er: »Sie sind viel weiter gekommen, als ich gedacht hätte: Sie haben die ersten Schritte eingeleitet, um die Arbeitsumgebung zu stabilisieren, Sie verwalten die WIP in IT Operations visuell, und Sie haben damit begonnen, Ihren Engpass Brent zu schützen. Zudem haben Sie wieder eine Kultur operativer Härte und Disziplin eingerichtet. Sehr gut, Bill.«

Ich nicke mit einem Seufzer. »Brent ist wirklich ein Engpass, das haben wir zu spüren bekommen.«

Er antwortet: »Wenn wir über Ihre nächsten Schritte sprechen werden, müssen Sie auf jeden Fall wissen, was für Engpässe Sie haben, denn Sie müssen den Durchfluss erhöhen. Aktuell gibt es nichts Wichtigeres.«

Erik redet jetzt wie ein Professor: »Sie haben gesagt, dass Sie in der Business School etwas über das Verwalten einer Fabrik gelernt haben. Ich hoffe, Teil Ihres Curriculums war Das Ziel von Dr. Eli Goldratt. Wenn Sie kein Exemplar mehr haben, holen Sie sich eines. Sie werden es brauchen.«

Ich glaube, mein Exemplar steht in meinem Büro zu Hause. Während ich mir kurz notiere, danach zu schauen, fährt er fort. »Goldratt hat uns gelehrt, dass es in den meisten Fabriken eine sehr kleine Zahl von Ressourcen gibt – seien es Menschen, Maschinen oder Materialien –, die den Ausstoß des gesamten Systems vorgeben. Wir nennen dies den Engpass – oder Flaschenhals. Beide Begriffe passen. Wie auch immer Sie es nennen, bis Sie ein zuverlässiges System aufgebaut haben, um den Arbeitsfluss bis zum Engpass zu steuern, ist dieser Engpass fortlaufend verschwendet, also sehr wahrscheinlich deutlich zu wenig ausgelastet.

Das bedeutet, dass Sie nicht die ganze verfügbare Kapazität bereitstellen. Und es bedeutet auch, dass Sie nicht Ihre technischen Schulden zurückzahlen, sodass Ihre Probleme und die Menge an ungeplanter Arbeit mit der Zeit zunehmen werden«, sagt er.

Erik fährt fort: »Sie haben diesen Brent als Engpass erkannt, der beim Wiederaufsetzen von Services ein Hindernis ist. Vertrauen Sie mir – Sie werden feststellen, dass er auch noch in vielen anderen Arbeitsabläufen der Flaschenhals ist.«

Ich versuche, eine Frage zu stellen, aber er fährt unbeirrt fort. »Es gibt fünf fokussierende Schritte, die Goldratt in Das Ziel beschreibt: Schritt 1 ist das Identifizieren des Engpasses. Das haben Sie getan, das ist sehr gut. Versuchen Sie weiter, sicherzustellen, dass das Ihr Engpass in der Organisation ist, denn wenn Sie sich geirrt haben, wird alles, was Sie tun, nichts bringen. Denken Sie daran – jegliche Verbesserung, die Sie nicht am Engpass vornehmen, ist nur eine Illusion.

Schritt 2 ist, den Engpass auszulasten«, fährt er fort. »Mit anderen Worten: Stellen Sie sicher, dass der Engpass keine Zeit verschwendet. Niemals. Er sollte nicht auf andere Ressourcen warten müssen und immer an der Aufgabe mit der höchsten Priorität arbeiten, die IT Operations für den Rest der Firma zu erfüllen hat. Immer.«

Aufmunternd sagt er: »Sie haben Ihre Aufgabe gut gemacht, indem Sie den Engpass an vielen Fronten ausschöpfen. Sie haben den Rückgriff auf Brent bei ungeplanter Arbeit und bei Ausfällen verringert. Sie haben sogar damit begonnen, sich zu überlegen, wie Sie Brent besser für die drei anderen Arten von Arbeit einsetzen können: Business- und IT-Projekte sowie Änderungen. Denken Sie daran: Ungeplante Arbeit zerstört Ihre Fähigkeit, geplante Arbeit durchzuführen, daher müssen Sie alles Machbare tun, sie zu reduzieren. Murphy gibt es wirklich, daher werden Sie immer mit ungeplanter Arbeit umgehen müssen, aber das muss effizient geschehen. Sie haben noch einen weiten Weg vor sich.«

Etwas ernster sagt er: »Aber Sie sind jetzt dafür bereit, über Schritt 3 nachzudenken – alles dem Engpass unterzuordnen. In der Theory of Constraints wird die meist durch ein sogenanntes Drum-Buffer-Rope umgesetzt. In Das Ziel lernt das die Hauptfigur Alex, als er feststellt, dass Herbie, der langsamste Pfadfinder in der Gruppe, die Marschgeschwindigkeit der ganzen Mannschaft bestimmt. Alex hat Herbie an den Anfang der Gruppe verlegt, um zu verhindern, dass der Abstand zwischen den Kindern zu groß wird. In der Fabrik hat Alex dann später dafür gesorgt, dass die Arbeit passend zu der Rate angestoßen wird, in der sie vom Härtungsofen verarbeitet werden kann – dem Flaschenhals. Das war sein Herbie im Arbeitsleben.

Ganze zwei Jahrzehnte, nachdem Das Ziel veröffentlicht worden war«, fährt er fort, »hat David J. Anderson Techniken mit einem Kanban-Board entwickelt, um für Entwicklung und IT Operations Arbeit anzustoßen und die WIP zu steuern. Vielleicht ist das etwas für Sie. Sie und Penelope sind mit Ihrem Change-Board nahe dran an einem Kanban-Board, mit dem der Arbeitsfluss gesteuert werden kann.

Hier nun Ihre Hausaufgabe«, fährt Erik fort. »Versuchen Sie, herauszufinden, wie Sie die Arbeitsgeschwindigkeit an Brent anpassen können. Haben Sie erst einmal IT Operations auf die Fertigungshalle abgebildet, wird das ganz einfach sein. Rufen Sie mich an, wenn Sie das geschafft haben.«

»Warten Sie«, sage ich hastig, bevor er auflegt. »Ich werde meine Hausaufgaben machen, aber reden wir eigentlich nicht am Thema vorbei? Phoenix ist doch die Ursache für die ganze ungeplante Arbeit. Warum konzentrieren wir uns jetzt auf Brent? Müssen wir nicht die ganzen Probleme mit Phoenix im Entwicklungsteam angehen, um die ungeplante Arbeit zu verringern?«

»Jetzt klingen Sie wieder wie Jimmy, der sich über Dinge beschwert, die nicht in seinem Einflussbereich liegen«, seufzt er. »Natürlich verursacht Phoenix die ganzen Probleme. Sie bekommen schließlich das, was Sie entworfen haben. Chester – Ihr entsprechender Kollege im Entwicklungsteam – kümmert sich die ganze Zeit um Features statt um Stabilität, Sicherheit, Skalierbarkeit, Wartbarkeit, Operabilität, Kontinuität und all die ganzen anderen schönen Dinge.

Am andere Ende der Fertigungsstraße versucht Jimmy, die Produktionssteuerung zu verbessern, nachdem das Kind in den Brunnen gefallen ist«, sagt er spöttisch. »Hoffnungslos! Aussichtslos! Es wird nicht funktionieren! Sie müssen diese Dinge, die manche als ›nichtfunktionale Anforderungen‹ bezeichnen, mit in das Produkt einplanen. Aber Ihr Problem ist, dass die Person, die am besten weiß, wo Ihre technischen Schulden liegen, und die weiß, wie wirklich operativer Code zu schreiben ist, zu beschäftigt ist. Sie wissen, wer diese Person ist, oder?«

Ich grummle. »Brent.«

»Genau«, sagt er. »Wenn Sie Ihr Brent-Problem nicht lösen, werden Sie ihn nur zu Design- und Architektur-Meetings mit der Entwicklungsabteilung einladen, aber er wird dort nicht auftauchen – warum?«

Ich antworte prompt: »Ungeplante Arbeit.«

»Gut!«, sagt er. »Sie werden besser. Aber bevor Ihnen das zu Kopf steigt, möchte ich Ihnen erzählen, dass auch auf dem Ersten Weg noch ein großes Stück zurückzulegen ist. Jimmys Problem mit den Auditoren zeigt, dass er nicht unterscheiden kann, welche Arbeit für das Business wichtig ist und welche nicht. Und zufällig haben Sie das gleiche Problem. Denken Sie daran, es geht nicht nur darum, die WIP zu verringern. Es ist wichtiger, unnötige Arbeit aus dem System zu drängen, als mehr Arbeit in das System stecken zu können. Dazu müssen Sie wissen, was nötig ist, um die Businessziele zu erreichen – egal ob es Projekte, Operations, Strategien, das Erfüllen von Gesetzen oder Verordnungen, Sicherheit oder was auch immer sind.«

Er fährt fort: »Denken Sie daran, wichtig ist das Ergebnis – nicht der Prozess, die Steuerung oder welche Arbeit Sie eigentlich erledigen.«

Ich seufze. Gerade als ich denke, ein konkretes Verständnis für Engpässe zu bekommen, entzieht sich Erik wieder.

»Lassen Sie sich nicht ablenken. Rufen Sie mich an, wenn Sie wissen, wie Sie die Arbeitszufuhr zu Brent steuern können«, sagt er und legt auf.

Ich fasse es nicht. Ich versuche zwei Mal, ihn wieder anzurufen, lande aber immer auf der Mailbox.

Also lehne ich mich auf der Bank zurück, atme tief durch und zwinge mich, den warmen Morgen zu genießen. Ich höre die Vögel zwitschern und das Rauschen der Autos auf der Straße.

Dann versuche ich in den nächsten zehn Minuten, so viel wie möglich von diesem Gespräch auf meinem Notizblock zu dokumentieren und alle Themen zu erwischen, die Erik angesprochen hat.

Als ich fertig bin, gehe ich wieder nach drinnen und rufe Wes und Patty an. Ich weiß genau, was ich zu tun habe, und bin ganz begierig darauf, anfangen zu können.

KAPITEL 16

Donnerstag, 18. September

Ich sitze an meinem Schreibtisch, habe mein Laptop zugeklappt und versuche mich darauf zu konzentrieren, ein paar lose Enden zusammenzufügen, als Ellen mit einem E-Mail-Ausdruck hereingestürmt kommt. Die Mail ist von Dick, der richtig Alarm macht und die ganze Firmenleitung aufgescheucht hat. Irgendetwas mit dem Rechnungssystem der Firma ist schiefgegangen. Einer der Angestellten hat im Lauf des Vormittags festgestellt, dass seit drei Tagen keinem Kunden mehr eine Rechnung gestellt wurde. Das hat unter anderem zur Folge, dass die Kunden nicht pünktlich bezahlen, womit die Firma am Quartalsende weniger Geld zur Verfügung haben wird, was wiederum alle möglichen unerfreulichen Fragen hervorrufen wird, wenn die Zahlen veröffentlicht werden.

Aus Dicks E-Mails wird klar, dass er stinkwütend ist, und offensichtlich versucht sein gesamtes Team, panisch auf allen Ebenen Schadensbegrenzung zu betreiben.

Von: Dick Landry

An: Steve Masters

Cc: Bill Palmer

Datum: 18. September, 15:11

Wichtigkeit: Hoch

Betreff: ACTION NEEDED: Potenzielles 50-Millionen-$-Defizit wegen IT-Fehler

ALLE KUNDENRECHNUNGEN STECKEN IMMER NOCH IM SYSTEM FEST ODER FEHLEN GANZ. WIR KÖNNEN SIE NICHT EINMAL AUSLESEN, UM SIE MANUELL PER E-MAIL ZU VERSCHICKEN!

Wir versuchen, herauszufinden, wie wir wieder zum normalen Geschäft zurückkehren können. Es stecken vermutlich 50 Millionen Dollar Außenstände im System, die dann am Quartalsende fehlen werden.

Die IT-Leute müssen das beheben. Das lässt sich in den Quartalszahlen unmöglich verbergen und vielleicht sogar nicht einmal wegdiskutieren.

Steve, ruf mich an. Ich werde auf dem Fensterbrett stehen.

Dick

Wir haben uns alle im NOC-Besprechungszimmer versammelt. Ich bin erfreut, dass Patty nach dem Beschreiben des Zwischenfalls gleich alle relevanten Änderungen der letzten 72 Stunden präsentieren kann.

Nachdem sie fertig ist, sage ich unnachgiebig: »Meine größte Sorge ist das Verlieren von Transaktionen. Meine Damen und Herren, ich muss es ganz deutlich sagen: FASST NICHTS AN, OHNE EINE ERLAUBNIS VON MIR ZU HABEN. Das ist nicht einfach ein Ausfall, mit dem wir es hier zu tun haben. Wir befinden uns in einer Situation, in der wir unabsichtlich Bestellungen oder Rechnungsdaten verlieren könnten. Das macht mir Angst. Und das wiederum sollte euch Angst machen.

Wie Patty schon gesagt hat – wir brauchen Zeitpläne und Hypothesen für das, was dafür gesorgt haben könnte, dass das Rechnungssystem ausgefallen ist«, sage ich. »Das ist unser Apollo-13-Moment, und ich bin Gene Kranz in der Kontrollstation in Houston. Ich will kein Rätselraten, ich will Hypothesen, die auf Fakten basieren. Also zurück an eure Rechner. Stellt Zeitpläne und Daten zusammen. Ich will eure besten Ideen zu Ursache und Wirkung. Scheitern ist keine Option.«

Um 18 Uhr hat Pattys Team über 20 mögliche Fehlerursachen zusammengetragen. Nach weiteren Untersuchungen bleiben acht als die wahrscheinlichsten übrig. Jede wird einem Kollegen zugeteilt, der sie sich genauer anschauen soll.

Wir erkennen, dass wir als Gruppe nicht viel mehr tun können, bis diese Nachforschungen abgeschlossen sind, daher verabreden wir uns für 22 Uhr zu einer nächsten Runde.

Einerseits bin ich frustriert, dass wir schon wieder in eine Krise gestürzt wurden und unser Tag durch ungeplante Arbeit dominiert wird. Andererseits bin ich ausgesprochen froh darüber, wie geordnet unsere Untersuchungen ablaufen. Ich schreibe Paige kurz, dass ich gleich zum Abendbrot kommen werde.

»Papa«, höre ich, als ich an Grants Bett sitze und versuche, ihn zum Einschlafen zu bringen, während ich gleichzeitig die Gedanken an den Ausfall aus meinem Kopf heraushalten will. »Warum hat Thomas, die Tenderlok, einen Tender? Warum?«

Ich lächle ihn an und staune über die Fragen, die meinem drei Jahre alten Sohn einfallen. Unser Ins-Bett-gehen-Ritual ist das Vorlesen von Büchern. Ich bin froh darüber, das machen wir jeden Abend. Oder zumindest, bis Phoenix dazwischengekommen ist.

Nur eine Lampe brennt. Es gibt einen Stapel Bücher neben Grants Bett, und wir sind heute schon beim dritten.

Langsam wird mein Mund trocken vom Vorlesen. Eine kleine Pause mit einer kurzen Suche im Internet zu Tendern von Lokomotiven klingt sehr verlockend.

Ich finde es toll, dass meine Kinder so viel fragen und Bücher lieben, aber es gibt Abende, in denen ich so ausgelaugt bin, dass ich während des Vorlesens einschlafe. Wenn meine Frau dann schaut, wo ich bleibe, findet sie mich eingeschlafen, mit einem von Grants Büchern auf meinem Gesicht, während Grant neben mir schlummert.

Aber egal wie müde ich bin – ich freue mich immer, früh genug zu Hause zu sein, so dass ich das Ins-Bett-gehen-Ritual mit meinem älteren Sohn wieder aufnehmen kann.

»Ja, das müssen wir herausfinden, Papa«, fordert Grant. Ich lächle erneut und hole mein Handy aus der Tasche, um bei Google nach »Tender Lokomotive« zu suchen.

Aber zuerst schaue ich kurz, ob es etwas Neues über das Problem mit den Rechnungen gibt. Ich freue mich darüber, was zwei Wochen ausmachen können.

Während des letzten Sev-1-Zwischenfalls, der unser System zum Verarbeiten der Kreditkartendaten betraf, ging es in der Telefonkonferenz die ganze Zeit nur darum, wer schuld sei, dass man selbst nicht schuld sei, und es wurde sehr viel Zeit verschwendet, in der uns die Kunden kein Geld zukommen lassen konnten.

Danach haben wir das erste einer Reihe von Post-mortem-Meetings durchgeführt – ganz ohne Schuldzuweisung –, um herauszufinden, was wirklich passiert ist, und um Ideen zu sammeln, wie eine Wiederholung vermieden werden könnte. Dazu hat Patty eine Reihe von Übungsausfall-Telefonkonferenzen gestartet, bei denen jeder dabei sein musste, um die neuen Prozeduren einzuüben.

Es war erstaunlich, das zu beobachten. Selbst Wes sah den Sinn dahinter.

Ich freue mich, in den E-Mails nun viele gute Informationen und effektive Diskussionen zwischen den Teams zu sehen, die an dem Problem arbeiten. Sie haben die Telefonkonferenz weiterlaufen lassen und einen Chatroom für die Leute aufgesetzt, die an dem Problem arbeiten. Ich selbst werde mich um 22 Uhr einwählen, um herauszufinden, wie der Stand ist.

Das ist in 45 Minuten. Genug Zeit, die ich mit Grant verbringen kann, der eigentlich bald einschlafen sollte.

Er stupst mich an, denn er erwartet offensichtlich Fortschritte bei der Suche.

»Entschuldigung, Granty. Ich wurde abgelenkt«, sage ich, während ich den Browser öffne.

Ich bin überrascht, wie viele Suchergebnisse es zu Thomas, der Tenderlok, gibt. Die Buchserie hat ein milliardenschweres Imperium mit Spielzeugeisenbahnen, Kleidung, Videos und Ausmalbüchern hervorgebracht. Mit zwei Söhnen scheinen wir prädestiniert, bald von jedem Gegenstand zwei Exemplare zu besitzen.

Ich lese gerade einen vielversprechenden Wikipedia-Artikel zu Zügen, als mein Handy vibriert und auf dem Bildschirm »Anruf von Steve Masters« erscheint.

Ich stöhne auf und schaue nochmals auf meine Uhr. Es ist 21:15.

Ich hatte in letzter Zeit definitiv zu viele Meetings und Telefonate mit Steve und frage mich, wie viele ich noch aushalte.

Andererseits ist nach dem Phoenix-Debakel jeder Ausfall und jeder Zwischenfall trivial, oder?

Ich sage sanft: »Warte mal, Grant. Papa muss gerade ein Gespräch annehmen. Ich bin gleich zurück.« Ich stehe vom Bett auf und gehe in den dunklen Flur.

Zum Glück habe ich gerade eben die E-Mails zum Ausfall überflogen. Also atme ich tief durch, bevor ich den Anruf annehme.

Ich sage: »Bill hier.«

Steves laute Stimme dröhnt in mein Ohr. »Guten Abend, Bill. Ich bin froh, Sie zu erreichen. Natürlich wissen Sie von dem Problem mit den Kundenrechnungen von Dick?«

»Natürlich«, antworte ich, überrascht von seinem Ton. »Mein Team hat heute Nachmittag eine ›bedeutende Störung‹ ausgerufen, und wir haben seitdem an dem Problem gearbeitet. Ich verschicke stündlich Statusberichte. Dick und ich haben heute Abend schon 20 Minuten telefoniert. Ich weiß, dass das ein ernsthaftes Problem ist, und mein Team folgt dem Prozess, den wir nach dem Zwischenfall mit der Payroll festgelegt haben. Ich bin sehr zufrieden damit, dass dieser Prozess funktioniert.«

»Nun, ich habe gerade mit Dick telefoniert, und er hat mir erzählt, dass Sie herumtrödeln«, sagt Steve sehr verärgert. »Ich rufe Sie nicht so spät am Abend an, um zu plaudern. Verstehen Sie, wie inakzeptabel das ist? Schon wieder IT-Chaos, das alles in Gefahr bringt. Einnahmen sind der Lebenssaft der Firma, und wenn wir keine Rechnungen stellen können, können wir auch nicht bezahlt werden!«

Ich denke an mein früheres Training zum Umgang mit frustrierten Personen und wiederhole ruhig, was ich schon gesagt habe. »Wie ich schon sagte: Ich habe mit Dick telefoniert. Er hat mir die Folgen sehr deutlich gemacht. Wir haben unseren neuen Störungsprozess angestoßen und suchen nun methodisch nach den Ursachen des Fehlers. Meine Mitarbeiter machen genau das, was sie sollen, denn bei so vielen beteiligten Komponenten macht man es leicht noch schlimmer, wenn man unbegründete Folgerungen ...«

»Sind Sie im Büro?«, fragt Steve nachdrücklich und schneidet mir das Wort ab, bevor ich fertig bin.

Seine Frage erwischt mich wirklich auf dem falschen Fuß.

»Ähm ... nein, ich bin zu Hause«, antworte ich.

Macht er sich Sorgen, dass ich das Problem wegdelegiert habe? Um nochmals meine Rolle im Umgang mit dieser Krise und meine Erwartungen an mein Team deutlich zu machen, sage ich: »Ich werde mich um 22 Uhr wieder einwählen. Wie immer haben wir einen Verantwortlichen vor Ort, und diejenigen meiner Mitarbeiter, die im Büro sein müssen, sind es auch.«

Schließlich frage ich unverblümt: »Steve, was wollen Sie mir sagen? Ich habe die Situation im Griff. Was brauchen Sie, was Sie noch nicht haben?«

Er antwortet hitzig: »Ich brauche von Ihnen ein Gespür für die Dringlichkeit. Dick und sein Team legen eine Nachtschicht ein, um herauszufinden, wie unsere Quartalszahlen aussehen, die in sechs Arbeitstagen anstehen. Aber ich denke, ich weiß schon, wie die Antwort aussehen wird.«

Steve fährt fort: »Wir werden vermutlich alle Ziele verfehlen, die wir dem Aufsichtsrat versprochen haben: Umsatz, Einnahmen, Forderungen – alles. Tatsächlich haben alle Zahlen, die wir zugesagt haben, die falsche Tendenz! Dieses Desaster wird nur den Verdacht des Aufsichtsrats erhärten, dass wir die Kontrolle über die Firma vollständig verloren haben!«

Er faucht nun fast, als er sagt: »Was ich nun also von Ihnen möchte, Bill, ist, dass Sie den Überblick behalten, sodass mein CFO nicht sagen muss, dass Sie sich drücken. Hier brennt die Hütte, und Sie erzählen mir etwas von schönen Bildern und Zeitplänen. Was zum Henker ist Ihr Problem? Trauen Sie sich nicht, Ihre Leute aus dem Bett zu klingeln?«

Ich setze noch mal an. »Steve, wenn ich der Meinung wäre, es würde helfen, würde ich jeden für eine lange Nacht ins Data Center beordern. Bei Phoenix sind ein paar Leute fast eine ganze Woche nicht nach Hause gekommen. Vertrauen Sie mir, ich weiß, dass die Hütte brennt, aber gerade jetzt müssen wir – mehr als alles andere – verstehen, was passiert ist. Bevor wir die Teams die Eingangstür aufbrechen lassen, muss sich jemand zumindest kurz anschauen, wie der Hinterhof aussieht – denn ansonsten fackeln wir eventuell gleich das nächste Haus ab!«

Ich bemerke, dass ich lauter geworden bin, obwohl die Kinder doch möglichst schlafen sollen. Also fahre ich leiser fort: »Und falls Sie es vergessen haben sollten: Während des Payroll-Problems haben wir den Ausfall noch schlimmer gemacht, indem wir irgendetwas getan haben. Wir hätten den Payroll-Lauf vermutlich noch rechtzeitig abschließen können, wenn nicht jemand mit dem SAN herumexperimentiert hätte. Deswegen war der Ausfall sechs Stunden länger, und wir haben die Payroll-Daten fast verloren!«

Meine Hoffnung, dass die Stimme der Vernunft ihn erreicht, löst sich in Luft auf, als er sagt: »Oh ja? Ich glaube nicht, dass Ihr Team das auch so sieht. Wie hieß noch mal der pfiffige Kerl, den Sie mir vorgestellt haben? Bob? Nein, Brent. Ich habe heute mit Brent gesprochen, und er sieht Ihr Vorgehen sehr kritisch. Er glaubt, dass Sie die Leute, die die wirkliche Arbeit machen, von den Aufgaben fernhalten, die eigentlich zu erledigen sind. Was macht Brent gerade?«

Scheiße.

Ich mag Transparenz. Ich versuche immer, mein Team für meinen Chef und die Businessabteilungen erreichbar zu machen. Aber es gibt dabei immer Risiken.

Zum Beispiel, dass Brent seine schrägen Theorien dem CEO vorstellt.

»Ich hoffe, Brent ist zu Hause, weil er genau dort sein sollte«, antworte ich. »Bis wir nicht sicher wissen, was schiefgelaufen ist, möchte ich ihn auch dort haben. Denn häufig sind es gerade solche pfiffigen Leute wie er, die die Probleme erst verursacht haben. Jedes Mal, wenn wir Brent einbeziehen, verstärken wir unsere Abhängigkeit von ihm und machen es unwahrscheinlicher, dass wir Dinge auch ohne ihn lösen können!«

Ich fürchte, dass Steve mir nicht folgen kann, und fange nochmals an. »So chaotisch, wie wir aktuell arbeiten, muss Brent das lecke Schiff fast jeden Tag flicken. Ich bin aber ziemlich sicher, dass Brent einer der Hauptverursacher für die Lecks ist. Natürlich nicht absichtlich, aber als Nebenwirkung der Art und Weise, wie wir hier arbeiten und Ausfälle beheben.«

Es gibt eine Pause. Dann sagt Steve langsam und bestimmt: »Ich bin froh, dass Sie da so professionell vorgehen, aber wir müssen einen Waldbrand löschen, der außer Kontrolle geraten ist. Bisher sind wir Ihrem Weg gefolgt. Jetzt machen wir es, wie ich es will.

Ich möchte, dass Sie Brent ins Büro zitieren und dass er die Ärmel hochkrempelt und dabei hilft, diesen Ausfall zu beheben. Und nicht nur Brent. Ich will, dass alle da sind und vor ihren Rechnern sitzen. Ich bin Captain Kirk. Sie sind Scotty. Und ich brauche Warp-Geschwindigkeit, also treten Sie Ihren faulen Technikern in den Hintern! Haben Sie mich verstanden?«

Steve schreit so laut, dass ich das Handy vom Ohr weghalte.

Plötzlich bin ich richtig wütend. Steve wird das schon wieder alles vermasseln.

Ich erinnere mich an meine Zeit bei den Marines und sage: »Darf ich offen reden, Sir?«

Steve schnaubt am anderen Ende der Leitung geringschätzig und sagt dann: »Ja verdammt.«

»Sie glauben, dass ich zu vorsichtig bin und ich mich nicht traue, das zu tun, was getan werden muss. Aber da liegen Sie falsch – ganz falsch«, sage ich unerbittlich. »Wenn Sie das tun, was Sie anscheinend vorschlagen – ›Alle Mann an Deck‹ –, werden wir es viel schlimmer machen«, fahre ich fort. »Ich habe versucht, Ihnen vor dem Phoenix-Launch Ähnliches zu raten. Wir sind noch nicht diszipliniert genug beim Lösen von Ausfällen. Angesichts der Komplexität und der vielen beteiligten Komponenten ist die Gefahr groß, dass wir etwas anderes kaputt machen. Ich weiß vielleicht noch nicht genau, was das Problem mit den Kundenrechnungen verursacht hat, aber ich weiß genug, um zu wissen, dass Ihr Vorschlag eine sehr schlechte Idee ist. Ich empfehle, so weiterzumachen, wie ich es bisher vorgegeben habe.«

Ich halte den Atem an und warte darauf, wie er reagiert.

Er sagt langsam: »Es tut mir leid, dass Sie das so sehen, aber ich habe die Befehlsgewalt. Ich sage Ihnen, dass wir hier Alarmstufe 1 haben, also lassen Sie die klügsten Leute an diesem Problem arbeiten. Und ich will alle zwei Stunden Statusberichte zu dieser IT-Panne, bis sie gelöst ist. Verstanden?«

Bevor ich darüber nachdenken kann, höre ich mich sagen: »Ich weiß nicht, warum Sie mich dann dafür brauchen. Sie reden direkt mit meinen Leuten, und Sie haben die Macht. Machen Sie es also selbst. Ich kann dann nicht für die Ergebnisse dieser FUBAR-Situation verantwortlich gemacht werden.«

Und bevor ich auflege, sage ich noch entschieden: »Und erwarten Sie morgen früh meine Kündigung.«

Ich wische mir den Schweiß von der Stirn, schaue von meinem Handy auf – und sehe meine Frau Paige, die mich mit weit aufgerissenen Augen anstarrt.

»Bist du wahnsinnig? Du hast gerade gekündigt? Einfach so? Wie sollen wir denn dann über den Monat kommen?«, fragt sie mit lauter werdender Stimme.

Ich schalte mein Handy stumm und stecke es zurück in die Tasche, dann sage ich: »Schatz, ich weiß nicht, wie viel du von dem Gespräch mitbekommen hast, aber lass es mich erklären ...«

Teil 2

KAPITEL 17

Montag, 22. September

Seit meiner Kündigung vor vier Tagen regt sich Paige permanent auf. Ich hingegen bin begeistert, wie viel besser ich nachts schlafe – so als ob eine riesige, unsichtbare Last von meinen Schultern genommen wurde.

Ungestört durch E-Mails oder Notfall-SMS war das Wochenende unglaublich friedlich. Am Donnerstag kamen zwar noch welche, aber ich habe einfach den E-Mail-Account gelöscht und die SMS blockiert.

Es fühlte sich super an.

Ich bitte Paige, Grant nicht zu ihrer Mutter zu bringen. Stattdessen nehme ich ihn mit auf eine Abenteuertour. Paige reagiert mit einem amüsierten Lächeln und hilft mir dabei, seinen Thomas-die-Tenderlok-Rucksack zu packen.

Um 8 Uhr sind wir aus dem Haus und fahren gut gelaunt zum Bahnhof – schon vor Monaten hatte ich Grant das versprochen. Eine Stunde lang beobachten wir die Züge, und ich ergötze mich an Grants kindlicher Freude. Trotz der Unsicherheit über meine Zukunft bin ich froh, dass ich diesen Moment mit Grant verbringen kann.

Während ich ihn fotografiere, als er fröhlich krähend auf die vorbeifahrenden Dieselloks zeigt, wird mir bewusst, wie wenig Bilder ich in den letzten Monaten von meinen Kindern geschossen habe.

Wir beobachten immer noch Züge, als mein Handy klingelt. Es ist Wes. Ich lasse die Mailbox rangehen.

Er ruft immer wieder an, und jedes Mal spricht er auf die Mailbox.

Dann ruft Patty an, deren Anruf ich ebenfalls nicht annehme. Nach drei weiteren Versuchen murmele ich frustriert: »Ach kommt, Leute ...«

»Palmer«, melde ich mich.

»Bill, wir haben die Neuigkeiten gerade von Steve gehört«, höre ich Patty, die klingt, als hätte sie das Telefon auf Lautsprecher gestellt. »Wes sitzt neben mir, und wir sind beide total geschockt. Wir wussten, dass irgendetwas nicht stimmt, als du nicht bei unserem regelmäßigen CAB-Meeting am Freitag aufgetaucht bist. Ich kann einfach nicht glauben, dass du mitten in diesem Ausfall gekündigt hast – nach allem, was wir erreicht haben!«

»Leute, das hat nichts mit euch zu tun«, erkläre ich. »Steve und ich hatten einfach ein paar unüberbrückbare Differenzen in den Vorstellungen, wie dieses Rechnungsproblem zu lösen wäre. Ich bin sicher, ihr werdet wunderbar ohne mich auskommen.«

Beim letzten Satz bin ich nicht ganz ehrlich.

»Na ja, wir haben es ganz schön vergeigt, seit du weg bist«, sagt Wes, klingt dabei ehrlich verlegen und bestätigt meine schlimmsten Befürchtungen. »Steve hat darauf bestanden, dass wir alle Techniker ins Büro holen – einschließlich Brent. Er wollte ›ein Gespür für die Dringlichkeit‹ haben und ›alle auf dem Spielfeld – keiner wartet auf der Bank‹. Offensichtlich haben wir aber die Aktivitäten der Leute nicht ausreichend koordiniert, daher ...«

Wes beendet den Satz nicht, Patty nimmt den Faden aber auf. »Wir sind uns noch nicht sicher, aber zumindest läuft das Lagerverwaltungssystem jetzt auch nicht mehr. Keiner kann herausfinden, was in den Fertigungshallen und Lagern vorhanden ist, und niemand weiß, welche Rohstoffe zu bestellen sind. Die Finanzkollegen sind kurz davor, aus dem Fenster zu springen, weil sie eventuell die Bücher nicht rechtzeitig für die Quartalszahlen schließen können. Dadurch, dass all diese Systeme unten sind, kann keiner an die Daten kommen, die gebraucht werden, um die verkauften Produkte, den Umsatz und die Marge zu berechnen.«

»Ach du heilige Scheiße.« Einen Moment bin ich sprachlos, dann sage ich: »Das ist unglaublich.«

Grant greift nach meinem Telefon und möchte gern mehr Aufmerksamkeit. Ich sage: »Hört mal, ich bin mit meinem Sohn unterwegs, und wir sind gerade mit etwas Wichtigem beschäftigt. Ich kann nicht mehr lange reden. Aber ich versichere euch, dass ich stolz auf das bin, was wir zusammen erreicht haben, und dass ich weiß, dass ihr diese Krise auch ohne mich durchsteht.«

»Das ist totaler Müll, und das weißt du«, sagt Patty. »Wie kannst du uns in so einer Lage alleine lassen? Wir hatten noch so viele Dinge gemeinsam zu erledigen, und jetzt lässt du alles halb fertig zurück! Ich hätte nie gedacht, dass du dich so davonstehlen würdest!«

»Patty hat recht. Jetzt zu gehen, ist große Kacke, wenn du mich fragst«, sagt Wes zustimmend.

Ich seufze. Ich werde ihnen sicher niemals von den frustrierenden und absurden Meetings berichten, die ich mit Steve abhalten musste. Das ist etwas zwischen ihm und mir. »Es tut mir leid, dass ich euch damit alleine lasse, aber es war etwas, das ich tun musste«, sage ich. »Ihr werdet das schon schaffen. Passt nur auf, dass Steve oder irgendjemand anderes euch nicht per Mikromanagement stresst. Keiner kennt die IT-Systeme so gut wie ihr, also soll auch keiner sagen, was ihr zu tun habt, okay?«

Ich höre Wes murmeln: »Zu spät.«

Jetzt versucht Grant, mir das Handy wegzunehmen. »Leute, ich muss aufhören. Wir hören später voneinander, okay? Bei einem Bier.«

»Ja, sicher«, sagt Wes.

»Mann, danke für alles«, sagt Patty, »wir sehen uns.«

Und das Telefonat ist beendet.

Ich seufze tief. Dann werfe ich einen Blick auf Grant, stecke das Handy weg und widme ihm wieder meine volle Aufmerksamkeit, um den Moment des kompletten Glücks, aus dem wir gerissen wurden, wiederzuerwecken.

Auf der Fahrt nach Hause klingelt mein Handy wieder. Grant ist auf dem Rücksitz eingeschlafen. Dieses Mal ist es Steve.

Ich habe gerade kein Interesse an einem Gespräch mit ihm und lasse die Mailbox rangehen. Drei Mal.

Nachdem ich in die Garage gefahren und ausgestiegen bin, versuche ich, Grant aus seinem Sitz zu bekommen, ohne ihn aufzuwecken. Als ich mit ihm ins Haus gehe, sehe ich Paige. Ich zeige auf Grant und flüstere ihr stumm »Eingeschlafen!« zu. Leise steige ich die Treppe hoch und schaffe es, ihn ins Bett zu befördern und ihm die Schuhe auszuziehen, ohne dass er aufwacht.

Erleichtert seufzend schließe ich die Tür hinter mir und gehe wieder nach unten.

Als Paige mich sieht, sagt sie: »Dieser Mistkerl Steve hat mich heute Morgen angerufen. Ich wollte eigentlich gleich wieder auflegen, aber er hat mir eine lange Geschichte über seine Selbstanalyse mit einem Kerl namens Erik erzählt. Er sagt, er hätte einen Vorschlag für dich. Ich habe ihm versprochen, die Nachricht an dich weiterzugeben.«

Als ich mit den Augen rolle, sagt sie, plötzlich besorgt: »Schau, ich weiß, dass du gekündigt hast, weil du der Meinung warst, das sei das Richtige. Aber du weißt genauso gut wie ich, dass es nicht viele Firmen in der Stadt gibt, die so gut zahlen wie Parts Unlimited. Insbesondere nach deiner Beförderung. Ich will nicht von meinen Eltern wegziehen müssen.«

Sie schaut mich nüchtern an. »Schatz, ich weiß, er ist ein Idiot, aber wir müssen beide Geld verdienen. Versprich mir, dass du dir anhörst, was er zu sagen hat, und gehe unvoreingenommen daran, okay? Bill? Okay?«

Ich nicke kurz, gehe ins Esszimmer und rufe Steve an.

Steve geht beim ersten Klingeln ans Telefon. »Guten Tag, Bill. Danke, dass Sie zurückrufen. Ich hatte das Vergnügen, mit Ihrer Frau zu sprechen und ihr zu sagen, was für ein Vollidiot ich war.«

»Ja, sie hat so etwas angedeutet«, antworte ich. »Sie sagte, Sie wollten unbedingt mit mir sprechen.«

Steve fährt fort: »Hören Sie, ich wollte mich entschuldigen für das Verhalten, das ich an den Tag gelegt habe, seit Sie dankenswerterweise meine Bitte akzeptiert haben, unser VP of IT Operations zu werden. Dick dachte, ich sei verrückt, als ich ihm erzählte, dass ich IT an mich berichten lassen wolle. Aber ich habe ihm davon erzählt, wie ich, als ich vor langer Zeit Werksleiter wurde, für einen Monat am Fließband gearbeitet hatte, um im Detail zu verstehen, was die Arbeiter dort zu tun haben.

Ich habe Dick versprochen, dass ich mir selbst die Hände schmutzig machen und das Problem nicht einfach nur wegdelegieren würde. Ich ärgere mich über mich selbst, dass ich dieses Versprechen gebrochen habe. Und das Delegieren aller IT-Themen an Sarah war ein Riesenfehler.

Ich war nicht fair zu Ihnen, insbesondere weil Sie Ihren Teil des Handels erfüllt haben. Sie sind sehr geradlinig und haben wirklich versucht, die Katastrophen zu vermeiden.«

Steve macht eine kleine Pause. »Hören Sie, Erik und das gesamte Audit-Komitee haben mir Feuer unter dem Hintern gemacht. Er hat mich so lange getreten, bis ich etwas verstanden habe. Ich habe erkannt, dass ich all die Jahre etwas komplett falsch gemacht habe, und das will ich jetzt ändern.

Kurz gesagt, ich würde mich freuen, wenn Sie ab sofort wieder in Ihren Job als VP of IT Operations zurückkehrten. Ich möchte mit Ihnen zusammenarbeiten wie zwei Menschen in einer nicht richtig funktionierenden Ehe – so hat Erik es genannt. Vielleicht können wir beide herausfinden, was beim Managen der IT hier bei Parts Unlimited wirklich falsch läuft.

Ich bin überzeugt davon, dass IT eine Kompetenz ist, die wir hier entwickeln müssen, und bitte Sie um 90 Tage. Wenn Sie dann immer noch gehen wollen, können Sie das tun – mit einer ordentlichen Abfindung.«

Ich denke an mein Versprechen Paige gegenüber und wähle meine Worte sorgfältig. »Sie haben sich im letzten Monat ziemlich viel Mühe gegeben, ein – wie Sie sagen – Vollidiot gewesen zu sein. Ich habe Ihnen immer wieder meine Analysen und Empfehlungen vorgestellt. Und jedes Mal haben Sie sie vom Tisch gewischt. Warum sollte ich Ihnen jetzt trauen?«

45 Minuten später, in denen mich Steve fortwährend bekniet hat, zurückzukommen, lege ich auf und gehe zurück in die Küche, in der Paige auf mich wartet und wissen will, was passiert ist.

KAPITEL 18

Dienstag, 23. September

Am nächsten Morgen fahre ich um 6:30 Uhr zur Arbeit, um pünktlich bei Steves Leadership-Meeting zu sein. Er nennt es zwar ein Außenmeeting, aber es findet in Gebäude 2 statt.

Früher am Morgen bin ich noch kurz zu Grant und Parker ins Kinderzimmer geschlüpft, um mich zu verabschieden. Parker schläft noch, aber ich küsse ihn und flüstere leise: »Sorry, dass Papa dich heute nicht auf eine Abenteuertour mitnehmen kann. Eigentlich wärst du ja dran, aber Papa muss zurück zur Arbeit. Aber dieses Wochenende – versprochen.«

Ich hoffe, das ist es wert, Steve.

Das Meeting findet im Besprechungsraum des Aufsichtsrats statt. Als ich im 15. Stock aus dem Fahrstuhl steige, kann ich immer noch nicht glauben, dass es hier so ganz anders als in den anderen Gebäuden aussieht.

Chris, Wes und Patty sind schon da, alle mit Kaffeebechern in der Hand und Teilchen vor der Nase.

Patty nimmt mich kaum zur Kenntnis.

Wes begrüßt mich lautstark und sagt sarkastisch: »Hey, Bill. Schön, dich zu sehen. Ich hoffe, du kündigst heute nicht gleich wieder.«

Danke, Wes.

Chris nickt mir verständnisvoll zu, verdreht die Augen und macht die Geste für das Trinken eines Biers. Ich nicke zurück, lächle und schaue mich im Raum um.

Meine Stimmung bessert sich, als ich sehe, dass wieder etwas von Vandal Donuts geordert wurde. Ich beginne, mir meinen Pappteller vollzuladen. Als ich überlege, ob sechs Donuts auf dem Teller ein Bruch des Protokolls wären, legt sich mir eine Hand auf die Schulter.

Es ist Steve. »Schön, Sie zu sehen, Bill. Ich bin froh, dass Sie da sind.« Er schaut sich meinen übervollen Teller an und lacht laut. »Warum nehmen Sie nicht gleich die ganze Platte?«

»Gute Idee. Schön, hier zu sein«, antworte ich.

Erik setzt sich mir direkt gegenüber und sagt: »Morgen, Bill.« Hinter ihm steht ein großer Koffer, den er mitgebracht hat.

Ich blinzle den Koffer an. Das letzte Mal, dass ich einen Koffer ohne Räder gesehen habe, war vor 20 Jahren in der Abstellkammer meiner Mutter.

Eriks Haar ist tropfnass und befeuchtet die Schultern seines Jeanshemds. War er heute Morgen zu spät und musste aus dem Hotel rennen, ohne sich noch die Haare trocknen zu können? Oder sieht er jeden Morgen so aus? Wo hat Steve den Kerl eigentlich aufgetrieben?

»Guten Morgen«, begrüßt Steve die Gruppe. »Zuallererst möchte ich mich dafür bedanken, dass alle so früh hergekommen sind. Insbesondere, weil ich weiß, dass Sie und Ihre Teams in den letzten zwei Wochen so unglaublich viel gearbeitet haben.«

»Ha!«, schnaubt Erik. »Das ist wohl die Untertreibung des Jahrhunderts.« Jeder lacht nervös und sehr darum bemüht, den anderen bloß nicht in die Augen zu sehen.

Steve lächelt gequält. »Ich weiß, dass die letzten Wochen grauenhaft waren. Ich erkenne jetzt, wie groß meine Verantwortung dafür ist. Nicht nur für das Phoenix-Desaster, sondern für alles, was zu dem Audit-Problem geführt hat, zu den Pannen mit den Rechnungen und der Lagerverwaltung in den letzten Tagen und zu dem Ärger, den wir mit den Auditoren haben.«

Er stoppt, offensichtlich verzweifelt, und braucht einen Moment, um sich wieder zu sammeln.

Hat er Tränen in den Augen?

Das ist eine Seite von Steve, die man nicht jeden Tag sieht. Was zum Henker ist mit ihm passiert, seit ich weg war?

Er legt eine Karteikarte beiseite, die er in der Hand gehalten hat, zuckt mit den Schultern und weist auf Erik. »Erik hat die Beziehung zwischen einem CEO und einem CIO als dysfunktionale Ehe bezeichnet. Beide Seiten fühlen sich machtlos und vom Gegenüber als Geisel gehalten.«

Seine Finger zerknittern die Karte. »Es gibt zwei Dinge, die ich im letzten Monat gelernt habe. Eines ist, dass IT wichtig ist. IT ist nicht einfach nur eine Abteilung, die ich wegdelegieren kann. IT ist an jeder größeren Aktion in der Firma beteiligt und für so gut wie jeden Aspekt der tagtäglichen Aufgaben wichtig.«

Er sagt: »Ich weiß, dass gerade aktuell nichts, aber auch gar nichts, wichtiger für den Erfolg der Firma ist als ein erfolgreiches Führungsteam.

Das Zweite, das ich gelernt habe, ist, dass meine Aktionen fast alle unsere IT-Probleme nur noch schlimmer gemacht haben. Ich habe Chris’ und Bills Anfragen nach mehr Budget abgelehnt, ebenso wie Bills Wunsch nach mehr Zeit, um Phoenix ordentlich auszuliefern, und dann habe ich die Dinge per Mikromanagement gesteuert, als ich nicht die gewünschten Ergebnisse erhalten habe.«

Steve schaut mich an. »Die Person, der ich am meisten Unrecht getan habe, war Bill. Er hat mir Dinge gesagt, die ich nicht hören wollte, und ich habe ihn abblitzen lassen. Im Nachhinein hatte er in allem recht, und ich hatte unrecht. Und das, Bill, tut mir sehr leid.«

Ich sehe, wie Wes die Kinnlade herunterfällt.

Ganz verlegen sage ich nur: »Das ist jetzt Schnee von gestern. Wie ich Ihnen schon sagte, Steve: Eine Entschuldigung wird nicht erwartet, aber gewürdigt.«

Steve nickt und schaut eine Zeit lang auf seine Karte. »Für die vor uns liegenden großen Herausforderungen brauchen wir ein außergewöhnliches Team, das sein Bestes gibt. Aber noch vertrauen wir einander nicht. Ich weiß, dass ich daran zum Teil schuld bin, aber das muss jetzt ein Ende haben.

Am Wochenende habe ich über meine Karriere nachgedacht, die – wie Sie vielleicht wissen – jeden Moment ein Ende haben kann, wie mir der Aufsichtsrat klargemacht hat. Ich weiß, dass ich meine besten Zeiten immer dann hatte, wenn ich Teil eines tollen Teams war. Das gilt sowohl für mein Berufs- als auch für mein Privatleben.

Ein großartiges Team bedeutet nicht, dass es nur aus den klügsten Köpfen besteht. Ein Team wird dann gut sein, wenn sich alle vertrauen können. Es entsteht viel Power, wenn diese Magie zwischen den Leuten existiert.«

Steve fährt fort: »Eines meiner Lieblingsbücher über Teamdynamik ist Die 5 Dysfunktionen eines Teams von Patrick Lencioni. Er schreibt, dass man für gegenseitiges Vertrauen verletzlich sein muss. Daher werde ich Ihnen ein wenig über mich und meine Motivation erzählen. Und dann werde ich Sie bitten, das Gleiche zu tun.

Das mag unbequem sein, aber es ist ein Teil dessen, was ich von Ihnen als Führungskräfte brauche. Wenn Sie es nicht für sich tun können, tun Sie es für die Existenz der fast 4000 Mitarbeiter von Parts Unlimited und deren Familien. Ich nehme diese Verantwortung nicht auf die leichte Schulter, und Sie sollten das auch nicht.«

Oh, Scheiße. Das ist ein weiterer Teil von »Management-Offsites«, den ich verdrängt hatte. Gefühlsmist.

Steve ignoriert die greifbare Spannung im Raum, die entsteht, weil jeder – ich eingeschlossen – seine Abwehrschilde in Position bringt. »Meine Familie war sehr arm, aber ich bin sehr stolz darauf, der Erste gewesen zu sein, der es tatsächlich auf das College geschafft hat. Keiner vor mir ist über die Highschool hinausgekommen. Ich bin aufgewachsen in Texas auf dem Land, meine Eltern haben in einer Baumwollspinnerei gearbeitet. Als meine Brüder und ich noch zu jung waren, um dort zu arbeiten, haben wir im Sommer Baumwolle auf den Feldern gepflückt.«

Die Leute haben im letzten Jahrhundert Baumwolle geerntet? Ich rechne im Kopf nach und frage mich, ob das möglich war.

»Also stand ich da nun, endlich am Ziel meiner Wünsche angekommen: an der University of Arizona. Meine Eltern hatten kein Geld für die Studiengebühren, daher habe ich mir einen Job in einer Kupfermine organisiert.

Ich weiß nicht, ob die Berufsgenossenschaft damals schon existierte, aber wenn sie die Mine besucht hätte, wäre diese sofort geschlossen worden. Es war ein gefährlicher und schmutziger Ort.« Er zeigt auf sein linkes Ohr und sagt: »Ich habe auf diesem Ohr einen Großteil meines Hörvermögens verloren, als ich bei einer Sprengung zu nahe dran war.

Es wurde besser, als ich eine Arbeit bei einem Rohrproduzenten ergattern konnte, wo ich bei der Wartung der Ausrüstung mithalf. Das war der Job, bei dem ich für das Denken bezahlt wurde.

Ich studierte Management und wollte nach dem College auf jeden Fall in den Verkauf gehen. Aus meiner Sicht hatten die Verkäufer die beste Arbeit der Welt. Sie wurden dafür bezahlt, mit Kunden essen zu gehen, und reisten von Stadt zu Stadt, um zu sehen, was die besten Fabriken boten.«

Steve schüttelt reumütig seinen Kopf. »Aber das wurde es dann doch nicht. Um das College bezahlen zu können, ging ich zum ROTC, wo ich das erste Mal mitbekam, wie die Mittelstandskids so ticken. Nach dem College ging es daher nicht in die Industrie, stattdessen musste ich meine Pflichten gegenüber der US Army erfüllen, wo ich meine Liebe zur Logistik entdeckte. Ich sorgte dafür, dass die Materialien dahin gelangten, wo sie gebraucht wurden. Ich hatte bald den Ruf, so gut wie alles besorgen zu können.«

Ich bin gefesselt. Steve kann gut erzählen.

»Aber es ist hart, ein armes Landei zu sein, umgeben von Leuten aus begüterten Familien. Ich hatte das Gefühl, mich jedem gegenüber beweisen zu müssen. Ich war 25 Jahre alt, und es gab immer noch Offiziere, die mich wegen meines Dialekts und meiner Erziehung als dumm bezeichneten ...«, sagt er mit etwas rauer Stimme.

»Das hat mich nur noch mehr darin bekräftigt, mich zu beweisen. Nach neun Jahren verließ ich die Army nach einer hervorragenden Karriere. Kurz bevor ich entlassen wurde, erzählte mir mein befehlshabender Offizier etwas, das mein Leben verändern würde.

Er sagte, dass ich zwar über die Jahre hinweg fortlaufend beste Bewertungen erhalten hätte, dass aber keiner der Leute, die unter mir gedient hatten, je wieder mit mir würde arbeiten wollen – ohne Ausnahme. Gäbe es einen Arschloch-des-Jahrzehnts-Pokal – ich hätte ihn mit großem Vorsprung gewonnen. Und wenn ich etwas aus mir machen wollte, müsste ich das ändern.«

Aus dem Augenwinkel sehe ich, wie Wes sich Chris zugewendet und seine Augen verdreht, was der geflissentlich ignoriert.

»Ich weiß, was Sie denken«, sagt Steve und nickt Wes zu. »Aber das war einer der vernichtendsten Momente in meinem Leben, und ich erkannte, dass ich einen großen Fehler gemacht hatte, als ich meine eigenen Werte verriet.

In den nächsten drei Jahrzehnten lernte ich immer besser, wie man Teams aufbaut, die einander vertrauen. Erst als Logistiker, dann als Werksleiter, als Marketingchef und dann als Vertriebsleiter. Vor zwölf Jahren hat mich dann Bob Strauss, unser damaliger CEO, als neuen Chief Operating Officer hergeholt.«

Steve atmet langsam aus, reibt sich die Stirn und sieht mit einem Mal sehr müde und alt aus. »Irgendwie habe ich aber wieder den falschen Weg gewählt – so wie in der Army. Ich wurde derjenige, der ich eigentlich nie wieder sein wollte.«

Er wird still und sieht sich im Raum um. Eine ganze Weile beobachten wir ihn, wie er aus dem Fenster starrt. Die helle Sonne flutet langsam den Besprechungsraum.

Steve sagt: »Wir haben große Probleme vor uns, die wir lösen müssen. Erik hat recht. IT ist nicht einfach irgendeine Abteilung. IT ist eine Kompetenz, die wir als ganze Firma erwerben müssen. Und ich weiß: Wenn wir uns als Team neu erfinden, wenn wir alle einander vertrauen können – dann können wir Erfolg haben.«

Dann sagt er: »Wollen Sie den Weg mit mir gehen, ein Team zu werden, das einander vertraut?«

Steve schaut die Leute am Tisch an. Ich sehe, dass jeder mit gespannter Aufmerksamkeit zurückschaut.

Die Stille im Raum wird langsam ungemütlich.

Schließlich ist Chris der Erste, der etwas sagt. »Ich bin dabei. Es ist grausam, in einem kaputten Team zu arbeiten. Wenn Sie also anbieten, das zu reparieren, mache ich mit.«

Ich sehe, dass Patty und Wes ebenfalls nicken, dann schauen alle mich an.

KAPITEL 19

Dienstag, 23. September

Schließlich nicke ich auch.

Patty sagt: »Weißt du, Bill, ich denke, du hast in den letzten Wochen deine Sache wirklich fantastisch gemacht. Und es tut mir leid, wie ich bei deiner Kündigung reagiert habe. Ich habe gesehen, wie vollkommen anders die gesamte IT-Organisation jetzt arbeitet. Die Organisation hat sich bisher immer mit Händen und Füßen dagegen gewehrt, irgendwelche Prozesse zu übernehmen, und es gab echte Vertrauensprobleme zwischen den Abteilungen. Es ist toll, wie sich das ändert, und den größten Anteil daran hast du.«

»Ich sehe das genauso. Ich glaube, ich bin auch froh, dass du wieder da bist, du Drückeberger.« Wes lacht laut. »Was auch immer ich am ersten Tag gesagt habe – ich will deinen Job nicht haben. Wir brauchen dich hier.«

Beschämt lächle ich nur und freue mich über ihre Kommentare. Aber ich will nicht, dass das so weitergeht, daher sage ich: »Okay. Vielen Dank, Leute.«

Steve nickt, während er unser Gespräch beobachtet. Dann sagt er: »Lassen Sie uns reihum gehen. Jeder erzählt etwas Privates aus seiner Vergangenheit. Wo wurden Sie geboren? Wie viele Geschwister haben Sie, und wo fühlen Sie sich zu Hause? Welche Erlebnisse aus der Kindheit haben Sie zu dem gemacht, was Sie jetzt als Erwachsener sind?«

Steve fährt fort: »Ziel dieser Übung ist, die anderen als Menschen kennenzulernen. Sie haben ein bisschen über mich und meine Schwachstellen erfahren. Aber das reicht nicht. Wir müssen mehr übereinander wissen. Und das legt die Grundlage für Vertrauen.«

Er sieht sich um. »Wer will anfangen?«

Oh je.

Marines mögen diesen Gefühlskram überhaupt nicht. Ich wende sofort meinen Blick ab, weil ich nicht der Erste sein will.

Zu meiner großen Erleichterung meldet sich Chris freiwillig.

»Ich wurde in Beirut geboren als jüngstes von drei Kindern. Bevor ich 18 wurde, hatte ich schon in acht verschiedenen Ländern gelebt. Daher spreche ich vier Sprachen.«

Chris erzählt uns, wie er und seine Frau fünf Jahre lang versucht haben, Kinder zu bekommen, über den Kampf mit den Fertilitätsspritzen für seine Frau und die fehlende Kraft, das Ganze noch ein drittes Mal durchzuziehen.

Dann erzählt er über das Wunder, Eltern von eineiigen Zwillingsjungs zu werden, die aber, zu früh geboren, viele Komplikationen durchleiden, sodass er und seine Frau drei Monate auf der Frühchen-Intensivstation verbringen. Und Nacht um Nacht beten, dass beide gesund werden, damit nicht einer von ihnen ohne den anderen aufwachsen muss, wo sie doch eine besondere Bindung haben, die niemand anderes ihnen bieten könnte.

Und wie diese Erfahrung ihm gezeigt hat, wie selbstsüchtig er war und wie schön es ist, jetzt selbstlos zu sein.

Zu meiner Überraschung kämpfe ich mit den Tränen, als ich Chris’ ehrliche Hoffnung auf eine gute Zukunft für seine Kinder sehe. Verstohlen bemerke ich, dass es den anderen auch so ergeht.

»Vielen Dank, dass Sie uns davon erzählt haben«, sagt Steve nach einem Moment ernst, dann schaut er sich am Tisch um. »Wer möchte als Nächstes?«

Zu meiner Überraschung und Erleichterung meldet sich Wes.

Ich lerne, dass er schon drei Mal verlobt war, es aber immer in letzter Minute schiefging. Und als er dann endlich verheiratet war, kam bald schon die Scheidung, weil seine Frau von seiner Manie für Autorennen genervt war.

Wie kann jemand, der fast 130 Kilogramm wiegt, an Autorennen teilnehmen?

Wes hat vier Autos, und wäre er nicht Mitarbeiter bei Parts Unlimited geworden, wäre er ihr bester Kunde. Er verbringt einen Großteil seiner Freizeit mit seinem Mazda Miata und seinem alten Audi, mit dem er fast jedes Wochenende an Rennen teilnimmt. Anscheinend kämpft er sein Leben lang mit seinem Gewicht, selbst schon als kleines Kind. Immer war er der Außenseiter. Und immer noch versucht er, abzunehmen. Nicht, um eine Freundin zu finden oder wegen der Gesundheit, sondern um bei den Rennen mit den dünnen Asiaten mithalten zu können, die nur halb so alt sind wie er. Selbst ein Abnehm-Camp hat er schon besucht. Zwei Mal.

Es folgt eine lange Stille.

Ich bin zu nervös, um zu lachen.

Dann sagt Steve schließlich: »Vielen Dank für Ihre Geschichte, Wes. Wer will nun?«

Ich presse die Lippen aufeinander und bin wieder erleichtert, dass Patty sich meldet.

Wir lernen, dass sie eigentlich Kunst als Hauptfach studiert hat. Sie ist eine von denen, über die ich mich mein ganzes Leben lang lustig gemacht habe? Aber sie scheint doch so vernünftig zu sein!

Patty erzählt uns, wie es ist, als »Streberin mit großen Möpsen und Brille« aufzuwachsen, die versucht, herauszufinden, was sie werden will. Im College hat sie fünf Mal das Hauptfach gewechselt, wurde schließlich Singer-Songwriter in Athens, Georgia, und ist zwei Jahre mit ihrer Band durch Klubs getourt. Dann ging sie zurück aufs College, um ihren Master of Fine Arts zu machen, aber nachdem ihr klar wurde, wie wenig Geld sie vermutlich als Künstlerin verdienen würde, bewarb sie sich bei Parts Unlimited. Aufgrund einer Verurteilung wegen zivilen Ungehorsams, die noch in ihrem Führungszeugnis stand, hätte sie den Job fast nicht bekommen.

Als Patty fertig ist, bedankt sich Steve bei ihr. Dann lächelt er über mein Unbehagen und sagt: »Vielen Dank. Damit bleiben nur noch Sie, Bill ...«

Obwohl ich wusste, dass dieser Moment kommen würde, scheint der Raum vor meinen Augen zu verschwimmen.

Ich hasse es, über mich selbst zu reden. Bei den Marines konnte ich eine Rolle spielen, in der ich Leute anbrüllte und ihnen sagte, was zu tun war. Ich wurde dafür bezahlt, meine Leute am Leben zu halten, indem ich ein bisschen klüger war als sie und ein lauteres Organ besaß.

Ich teile meine Gefühle nicht mit meinen Kollegen.

Oder eigentlich mit fast niemandem.

Ich schaue den Notizblock vor mir an, auf dem ich mir Ideen dazu aufgeschrieben habe, was ich erzählen könnte. Aber irgendwie sehe ich da nur nervöses Gekritzel.

Die Stille ist erdrückend, jeder schaut mich erwartungsvoll an. Nicht ungeduldig, wie mir auffällt. Alle sind ruhig und freundlich.

Patty schaut mich mitfühlend an.

Ich schürze die Lippen einen Moment, dann platzt es aus mir heraus. »Was hat mich am meisten beeinflusst? Dass ich erkannte, dass meine Mutter alles für uns tat und mein Vater völlig unzuverlässig war. Er war Alkoholiker, und wenn es unerfreulich wurde, habe ich mich mit meinen Brüdern und Schwestern vor ihm versteckt. Aber irgendwann kam ich an einen Punkt, an dem es zu viel wurde und ich weglief. Ich habe alle zurückgelassen, obwohl meine jüngste Schwester erst acht Jahre alt war.«

Ich fahre fort: »Wisst ihr – eingesperrt zu werden, war eines der besten Dinge, das mir passieren konnte. Die Alternative war, nach Hause gehen zu müssen. Stattdessen bin ich zu den Marines gegangen. Dort habe ich eine völlig neue Welt kennengelernt mit einer ganz anderen Art zu leben. Es zeigte mir, dass man dafür belohnt werden konnte, wenn man etwas richtig machte und sich um seine Kameraden kümmerte.

Was habe ich daraus gelernt? Mein wichtigstes Ziel ist es, ein guter Vater zu sein, nicht so ein Arschloch wie der, den ich hatte. Ich will der Mann sein, den meine Söhne verdient haben.«

Ich fühle, wie mir Tränen die Wangen hinunterlaufen. Ich wische sie weg und ärgere mich über meinen Körper, der mich verrät.

»Ist das so in Ordnung, Steve?«, sage ich mit mehr Wut in meiner Stimme, als ich hineinlegen wollte.

Steve nickt mit einem verhaltenen Lächeln und sagt langsam: »Danke sehr, Bill. Ich weiß, dass es für Sie genauso schwierig war wie für uns alle.«

Ich atme langsam aus. Und noch einmal tief durch, während ich versuche, wieder ins Gleichgewicht zu kommen, von dem ich gar nicht wusste, dass ich es verloren hatte.

Die unangenehme Stille hält an.

»Ich weiß, dass mir das nicht zusteht, Bill«, sagt Wes langsam. »Aber ich bin ziemlich sicher, dass dein Vater unglaublich stolz auf dich wäre. Und er würde erkennen, was für ein unsägliches Arschloch er im Vergleich zu dir gewesen ist.«

Ich höre Gelächter am Tisch, und Patty sagt leise: »Ich sehe das wie Wes. Deine Kinder haben mehr Glück, als ihnen je klar werden wird.«

Wes grunzt zustimmend, und Chris nickt mir zu. Und ich selbst heule das erste Mal seit 30 Jahren.

Beschämt reiße ich mich zusammen und blicke wieder auf die anderen.

Zum Glück wenden diese ihre Aufmerksamkeit nun wieder Steve zu, der seinen Blick durch den Raum schweifen lässt.

»Zuerst einmal möchte ich Ihnen allen danken, dass Sie etwas von sich preisgegeben und diese Übung mitgemacht haben», sagt er. »Auch wenn es schön ist, jeden von Ihnen nun besser zu kennen, würde ich das nicht machen, wenn ich nicht der Meinung wäre, es sei wichtig. Das Lösen komplexer Businessprobleme erfordert Teamwork, und Teamwork erfordert Vertrauen. Lencioni hat uns dargestellt, dass das Zeigen von Verwundbarkeit dabei helfen kann, die Grundlage dafür zu legen.

Ich weiß, dass es unrealistisch ist, zu denken, dass wir dieses Meeting verlassen und genau wissen, was wir zu tun haben – mit Prioritäten versehen und zugewiesenen Verantwortlichkeiten«, fährt er fort. »Aber ich würde gerne eine gemeinsame Vision haben, wie wir zu einer Lösung finden können.«

Steve legt beide Hände auf den Tisch und sagt: »Um das Ganze ins Rollen zu bringen, möchte ich vorlegen und behaupten, dass eines unserer Hauptprobleme ist, dass wir jede Zusage brechen und jeden Zeitplan, den wir erstellen, sprengen. Die Leute außerhalb von IT meckern schon immer, dass wir alle gesetzten Erwartungen verfehlen. Bei Weitem.

Was mich zu der Überlegung bringt«, sagt er und schaut uns an, »dass wir anscheinend nicht gut darin sind, interne Zusagen innerhalb von IT zu machen. Ideen dazu?«

Ungemütliche Stille.

Schließlich sagt Chris verteidigend: »Ich will hier ja keine Haare spalten, aber wenn man sich die Metriken anschaut, hat meine Gruppe so gut wie jedes größere Projekt pünktlich abgeliefert. Wir halten unsere Termine ein.«

»Ja, so wie ihr es bei Phoenix gemacht habt, oder?«, sagt Wes höhnisch. »Das war ein großer Erfolg. Ich habe gehört, dass Steve sehr stolz auf eure Leistung von letzter Woche war.«

Chris wird rot und hebt beide Hände. »So habe ich das nicht gemeint.« Er denkt einen Moment nach und fügt dann hinzu: »Es war ein völliges Desaster. Aber technisch gesehen, haben wir den Termin eingehalten.«

Interessant.

»Wenn das wahr ist«, sage ich und steige in das Gespräch ein, »ist unsere Definition von einem ›abgeschlossenen Projekt‹ total falsch. Wenn es bedeutet: ›Hat Chris all seine Phoenix-Aufgaben erledigt?‹, war es ein Erfolg. Aber wenn wir Phoenix produktiv haben wollten und die Businessziele erreicht werden sollten, ohne die gesamte Geschäftstätigkeit zu unterbrechen, sollten wir es einen totalen Fehlschlag nennen.«

»Reden wir doch nicht um den heißen Brei herum«, unterbricht Steve. »Ich habe Sarah schon gesagt, dass Phoenix eines der am schlechtesten durchgeführten Projekte in der Geschichte unserer Firma war. Was ist also eine bessere Definition von Erfolg?«

Ich denke einen Moment nach und sage dann: »Ich weiß es nicht. Aber das ist ein immer wiederkehrendes Muster. Chris’ Gruppe berücksichtigt nie die ganze Arbeit, die Operations noch zu erledigen hat. Und selbst wenn sie es tut, verbraucht sie die gesamte eingeplante Zeit und lässt uns nichts übrig. Wir müssen danach dann immer noch lange das Chaos beseitigen.«

Chris nickt verständnisvoll. »Wir beide wollen das ja gerade beheben. Ein Teil davon sind Planungs- und Architekturprobleme, über die wir uns schon unterhalten haben. Aber ihr unterschätzt, was für ein Flaschenhals eure Gruppe ist. Wir haben noch einen Haufen weiterer Anwendungen, die ausgeliefert werden müssen, aber weil euer Team so beschäftigt ist, werden auch alle anderen Deployments verzögert.«

Er fügt hinzu: »Jede Woche warten fünf oder sechs Anwendungsgruppen darauf, dass ihr das eine oder andere deployt. Und wenn irgendetwas schiefgeht, stapelt es sich erst recht. Nichts für ungut, aber wenn ihr spät dran seid, ist das wie ein Flughafen, der schließt. Bevor man es recht bemerkt, kreist schon ein Haufen Flugzeuge darüber, die eigentlich landen wollen.«

Wes grummelt laut: »Ja, genau, das passiert, wenn das Flugzeug, das ihr gebaut habt, eine Bruchlandung hinlegt und die Landebahn zerstört.«

Dann hebt Wes abwiegelnd die Hand. »Ich will euch ja nichts vorwerfen. Ich sage nur, wie es ist. Wenn Deployments nicht wie gewünscht ablaufen – egal ob der Plan von deiner oder meiner Gruppe entworfen wurde –, ist jeder betroffen. Mehr will ich gar nicht sagen.«

Ich nicke und stimme Wes’ Einschätzung zu. Und überraschenderweise nickt auch Chris.

Ich antworte: »Erik hat mir dabei geholfen, zu verstehen, dass es vier Typen von Arbeit in IT Operations gibt: Businessprojekte, Projekte in IT Operations selbst, Änderungen und ungeplante Arbeit. Aber wir reden nur über die erste Art von Arbeit und über die ungeplante Arbeit, die entsteht, wenn wir falsch vorgehen. Wir reden nur über die Hälfte der Arbeit, die wir in IT Operations haben.«

Ich drehe mich zu Steve und sage: »Ich habe Ihnen unsere Projektliste gezeigt. Zu diesen 35 Businessprojekten kommen ungefähr noch weitere 75 Ops-Projekte, an denen wir arbeiten. Wir haben ein Backlog mit Tausenden von Änderungen, die aus dem einen oder anderen Grund ausgeführt werden müssen. Und dazu kommt ein immer weiter wachsender Berg von ungeplanter Arbeit – meist verursacht durch all unsere instabilen Anwendungen, die immer wieder kaputtgehen, wie zum Beispiel Phoenix.«

Freimütig ergänze ich: »Angesichts der Arbeit, die vor uns liegt, sind unsere Kapazitäten schon weit mehr als ausgelastet. Und wir haben noch nicht einmal die Ergebnisse des großen Audit-Projekts eingerechnet, das laut Steve ebenfalls höchste Priorität hat.«

Ich sehe, wie bei Steve und Chris Verständnis aufschimmert.

Da wir schon dabei sind ...

Ich schaue mich verwundert um. »He, wo ist John? Wenn wir über Compliance reden – sollte er dann nicht auch hier sein? Und ist er nicht auch Teil des IT-Führungsteams?«

Wes grummelt leise, verdreht die Augen und sagt: »Oh super, genau den brauchen wir jetzt noch.«

Steve ist aufgeschreckt. Er schaut auf die Karteikarte, die er einige Zeit zuvor in der Hand gehabt hat. Dann geht er einen Kalenderausdruck durch, den er vor sich liegen hat. »Mist. Ich habe vergessen, ihn einzuladen.«

Chris murmelt: »Mann, wir haben schon so viel erreicht. Das ist doch Glück im Unglück.«

Es folgt ein etwas unbehagliches Lachen, aber den meisten ist es peinlich, dass wir Witze über John in seiner Abwesenheit machen.

»Nein, nein, so meinte ich das nicht«, sagt Steve schnell und sieht dabei am verlegensten von allen aus. »Bill hat recht – wir brauchen ihn hier. Wir machen eine Viertelstunde Pause. Ich werde Stacy bitten, ihn aufzutreiben.«

Ich entscheide mich, einen kurzen Spaziergang zu machen, um den Kopf freizubekommen.

Als ich zehn Minuten später zurückkomme, finde ich die Überreste einer laufenden Besprechung vor: Pappbecher, die zur Hälfte mit Kaffee gefüllt sind, Platten mit ein paar übrig gebliebenen Schnittchen, zerknüllte Servietten.

Auf der anderen Seite des Raums führen Patty und Wes eine angeregte Diskussion mit Chris. Am gegenüberliegenden Ende des Tischs telefoniert Steve mit seinem Handy, während sich Erik die Bilder mit Autoteilen anschaut, die an der Wand hängen.

Ich will gerade zu Patty und Wes gehen, als John den Raum betritt. Unter seinem Arm trägt er natürlich den unvermeidlichen schwarzen Ordner.

»Stacy hat gesagt, Sie haben mich gesucht, Steve?« Er schaut sich langsam im Raum um und erkennt, dass hier schon länger ein Meeting läuft, bei dem er nicht dabei war. »Habe ich eine Mail verpasst? Oder wurde ich mal wieder nicht eingeladen?«

Wie immer versucht jeder, ihm nicht in die Augen zu sehen, daher sagt er lauter: »Hey, hier riecht es so, als ob irgendjemand gerade Sex hatte. Habe ich etwas Spannendes verpasst?«

Chris, Patty und Wes brechen ihr Gespräch ab und nehmen mit übertriebener Lässigkeit wieder ihre Plätze ein.

»Ah, gut, dass Sie hier sind. Ich freue mich, dass Sie es einrichten konnten«, sagt Steve anscheinend völlig unbeeindruckt. »Bitte setzen Sie sich. Lassen Sie uns alle weitermachen.

John, ich möchte mich bei Ihnen entschuldigen, dass ich Sie nicht eingeladen habe. Das ist ganz allein meine Schuld«, sagt Steve, während er sich wieder an seinen Platz begibt. »Ich habe dieses Meeting gestern in letzter Minute organisiert, direkt nach dem Audit-Komitee-Meeting. Da ich meinen Anteil an den schlimmer gewordenen IT-Problemen erkannt habe, wollte ich das IT-Führungsteam zusammenbringen, um zu schauen, ob wir uns auf eine Lösungsrichtung einigen können, mit der die Probleme mit unseren Projekten, der Stabilität im Betrieb und der Compliance angegangen werden.«

John sieht mich fragend an und hebt eine Augenbraue.

Ich frage mich, warum Steve die Verletzlichkeitsübung von vorhin nicht erwähnt. Vielleicht hat er erkannt, dass er sie nicht wiederholen kann, und lässt sie daher unter den Tisch fallen.

Ich nicke John beruhigend zu.

Steve wendet sich mir zu. »Bill, bitte machen Sie weiter.«

»Als Sie die Zusagen von IT erwähnten, hat mich das an etwas erinnert, das Erik mich letzte Woche gefragt hat und das mir im Hinterkopf geblieben ist«, sage ich. »Er fragte, auf welcher Basis wir entscheiden, ob wir ein neues Projekt annehmen können. Als ich sagte, dass ich das nicht weiß, nahm er mich auf eine weitere Tour mit zur Fertigungshalle MRP-8. Wir gingen zu Allie, dem Manufacturing Resource Planning Coordinator, und Erik fragte sie, wie sie entscheidet, ob eine neue Bestellung angenommen wird.«

Ich blättere in meinen Notizen. »Sie sagte, dass sie zuerst auf die Bestellung und dann auf die Stückliste und die beteiligten Arbeitsstationen schaut. Abhängig davon prüft sie die Auslastung der relevanten Arbeitsstationen und entscheidet dann, ob ein Annehmen der Bestellung bestehende Zusagen in Gefahr bringen würde.

Erik fragte mich also, wie wir solche Entscheidungen in IT treffen«, erinnere ich mich erneut, »und ich habe ihm damals das Gleiche gesagt, das ich auch heute noch sage: Ich weiß es nicht. Ich bin ziemlich sicher, dass wir unsere Kapazität und die Anforderungen gar nicht prüfen, bevor wir eine Aufgabe annehmen. Das bedeutet, dass wir immer wieder ins Schleudern geraten, Abkürzungen nehmen müssen und damit mehr wacklige Anwendungen im Produktivbetrieb haben. Was wiederum zu mehr ungeplanter Arbeit und Feuerlöschen in der Zukunft führt. So drehen wir uns immer im Kreis.«

Zu meiner Überraschung werde ich von Erik unterbrochen. »Sehr gut, Bill. Sie haben gerade eine ›technische Schuld‹ beschrieben, die nicht zurückgezahlt wird. Sie entsteht durch Abkürzungen, die kurzfristig sinnvoll sind. Aber wie bei Geldschulden wachsen sie mit der Zeit. Zahlt eine Organisation ihre technischen Schulden nicht zurück, kann es sein, dass sie nur noch für die Zinsen arbeitet – in Form von ungeplanter Arbeit.

Wie Sie wissen, gibt es ungeplante Arbeit nicht umsonst«, fährt er fort. »Ganz im Gegenteil. Sie ist sehr teuer, weil ungeplante Arbeit auf Kosten von was geht?«

Er schaut sich professorenhaft um.

Wes antwortet schließlich: »Geplanter Arbeit?«

»Exakt!«, sagt Erik jovial. »Ja, das ist die richtige Antwort, Chester. Bill hat die vier Arten von Arbeit erwähnt: Businessprojekte, IT Operations-Projekte, Änderungen und ungeplante Arbeit. Kümmert man sich nicht um seine technische Schuld, führt das dazu, dass irgendwann nur noch ungeplante Arbeit erledigt werden kann!«

»Das hört sich nach uns an«, sagt Wes zustimmend. Dann schaut er Erik steif an und sagt: »Und ich bin Wes, nicht Chester. Wes.«

»Ja, sicher sind Sie das«, sagt Erik liebenswürdig.

Er wendet sich an den Rest im Raum. »Ungeplante Arbeit hat einen weiteren Nebeneffekt. Wenn Sie Ihre ganze Zeit damit verbringen, Feuer zu löschen, bleiben wenig Zeit und Energie für Planung übrig. Wenn Sie nur noch reagieren, gibt es nicht genug Zeit für die harte mentale Arbeit, die nötig ist, um herauszufinden, ob Sie neue Arbeit annehmen können. Also werden mehr Projekte angenommen mit weniger Zeit für jedes einzelne, mehr Eskalationen aufgrund schlechten Codes, also wieder mehr Abkürzungen. Wie Bill sagte: ›Immer nur im Kreis.‹ Das ist die Todesspirale der IT-Kapazität.«

Ich amüsiere mich darüber, wie Erik Wes’ Namen durcheinanderbringt. Ich bin nicht sicher, was für ein Spiel er hier spielt, aber es macht Spaß, das zu beobachten.

Unsicher frage ich Steve: »Dürfen wir denn Nein sagen? Jedes Mal, wenn ich Sie gebeten habe, die Arbeit für ein Projekt zu priorisieren oder abzulehnen, haben Sie mir den Kopf abgerissen. Wenn jeder daran glaubt, dass Nein zu sagen keine Option ist, nehmen wir nur noch fügsam Anweisungen entgehen und marschieren blind ins Verderben. Ich frage mich, ob das meinen Vorgängern auch zugestoßen ist.«

Wes und Patty nicken leicht.

Selbst Chris nickt.

»Natürlich können Sie Nein sagen!«, antwortet Steve hitzig und mit echter Verwirrung. Dann atmet er tief durch und sagt: »Lassen Sie mich eines klarstellen: Ich brauche Sie zum Neinsagen! Wir können es uns nicht leisten, dass diese Führungsmannschaft nur noch aus Befehlsempfängern besteht. Wir bezahlen Sie für das Denken, nicht für das Tun!«

Steve sieht zunehmend wütender aus und sagt: »Die Firma steht hier auf dem Spiel! Die Ergebnisse dieses Projekts entscheiden, ob die gesamte Firma Erfolg hat oder zugrunde geht!«

Er sieht mich direkt an: »Wenn Sie – oder irgendjemand – weiß, dass ein Projekt fehlschlagen wird, müssen Sie das sagen. Und ich brauche dafür Daten. Geben Sie mir Daten, so wie die Koordinatorin in der Fertigungshalle Ihnen das gezeigt hat, damit wir verstehen, warum das so ist. Sorry, Bill. Ich mag Sie sehr, aber einfach nur Nein zu sagen, weil Sie ein schlechtes Gefühl haben, reicht nicht aus.«

Erik schnaubt und brummelt: »Das haben Sie sehr schön gesagt, Steve. Ausgesprochen bewegend. Aber wissen Sie, was Ihr Problem ist? In den Businessabteilungen seid ihr trunken vor Projekten. Ihr übernehmt neue Aufgaben, ohne zu wissen, ob sie erfolgreich sein können. Warum? Weil ihr keinen Plan davon habt, wie groß eure Kapazitäten sind. Ihr seid wie der Kerl, der dauernd Schecks ausstellt, die alle platzen, weil er nicht weiß, wie viel Geld er hat, und auch nie seine Post öffnet.

Lassen Sie mich eine Geschichte erzählen«, sagt er. »Ich will erzählen, wie es im Gebäude MRP-8 aussah, bevor ich dort anfing. Die armen Kerle dort erhielten Mappen mit allen möglichen verrückten Aufträgen. Die Businessabteilungen gaben absurde Zusagen, etwas zu einem unmöglichen Zeitpunkt auszuliefern – unbeirrt von den Aufgaben, die schon anstanden.«

Er fährt fort: »Es war jeden Tag ein Albtraum. Die Zwischenprodukte stapelten sich bis zur Decke. Und gab es einen systematischen Weg, WIPs durch die Fertigungsschritte zu bewegen? Natürlich nicht! Erfolgreich war, wer am lautesten oder am häufigsten schrie, wer die besten Deals mit den Disponenten machte oder wer bei der obersten Führungskraft am beliebtesten war.«

Erik ist so lebhaft, wie ich ihn noch nie erlebt habe. »Wir haben damit begonnen, das Ganze wieder auf eine vernünftige Ebene zu bringen, indem wir überlegt haben, was unser Flaschenhals ist. Dann haben wir den geschützt und sichergestellt, dass seine Zeit nie verschwendet wurde. Und wir haben alles dafür getan, dass die Arbeit durch ihn ›hindurchfließen‹ konnte.«

Er grummelt noch einmal und sagt nur: »Um Ihr Problem zu beheben, müssen Sie viel mehr tun, als lediglich zu lernen, Nein zu sagen. Das ist nur die Spitze des Eisbergs.«

Wir schauen ihn alle an und warten darauf, dass er fortfährt. Stattdessen steht er auf, geht zu seinem Koffer und öffnet ihn. Man sieht einen Haufen Klamotten, einen Schnorchel, eine Mülltüte und Boxershorts.

Erik wühlt im Koffer herum, holt einen Müsliriegel hervor, schließt den Koffer wieder und kommt zum Tisch zurück.

Wir beobachten alle, wie er die Packung aufreißt und den Riegel verspeist.

Steve, genauso verwirrt wie der Rest von uns, sagt schließlich: »Erik, das ist eine interessante Geschichte. Bitte erzählen Sie weiter.«

Erik seufzt. »Nein, mehr wollte ich nicht sagen. Wenn Ihnen das nicht reicht, um zu wissen, was Sie tun müssen, gibt es keine große Hoffnung mehr für Sie.«

Steve haut genervt auf den Tisch.

Aber meine Gedanken rasen.

Es reicht nicht, einfach nur besser zu priorisieren. Ich habe, wenn auch unschön, schon gelernt, welche Prioritäten wir haben: Phoenix. Die Audit-Ergebnisse abarbeiten. Währenddessen alles andere am Laufen halten.

Wir sind der Meinung, dass wir den Flaschenhals kennen. Brent. Brent, Brent, Brent. Und wir haben schon Maßnahmen eingeleitet, um Brent vor ungeplanter Arbeit zu schützen. Ich weiß, dass ich nicht mehr Leute einstellen kann.

Ich weiß auch, dass die Arbeitsbelastung in meiner Gruppe jenseits von Gut und Böse ist.

Ich sehe keine Möglichkeit, die große Welle an Arbeit, die auf uns stürzt, irgendwie zu reduzieren. Weil nie jemand Nein gesagt hat.

Unser Fehler wurden lange vor meiner Zeit gemacht. Der Fehler war, das Projekt und alle daraus resultierenden Abkürzungen, die Chris machen musste, zu akzeptieren, bevor ich dazukam.

Wie können wir diesen Wahnsinn rückgängig machen?

Dann habe ich eine verrückte Idee.

Ich denke darüber nach. Es klingt total absurd, aber ich kann keinen Fehler in meiner Logik finden.

Ich sage: »Steve, ich habe eine Idee. Aber lassen Sie mich erst ausreden, bevor Sie etwas sagen.«

Und dann erzähle ich ihm, was ich denke.

Steve ist der Erste, der etwas sagt. »Sie müssen völlig verrückt sein«, und sein Unglaube verwandelt sich in Verärgerung. »Sie wollen einfach aufhören, Arbeit zu erledigen? Was glauben Sie, wer wir sind? Subventionierte Kartoffelbauern, die dafür bezahlt werden, kein Getreide anzubauen?«

Aber bevor ich antworten kann, meldet sich John zu Wort: »Dem stimme ich zu. Ihre Idee klingt nicht richtig. Uns brennt die Hütte, aber jetzt können wir es endlich richtig machen. Wir müssen das Eisen schmieden, solange es heiß ist.

Jetzt können wir das Budget fordern, das wir brauchen, um nicht nur die richtigen Dinge zu tun, sondern die Dinge auch richtig zu tun.«

Er zählt an seinen Fingern ab: »Wir haben die Audit-Ergebnisse, die dem Aufsichtsrat bekannt sind, das wichtige Projekt, das kein Fehlschlag sein darf, und einen Fehler in einem produktiven System, der auch nicht wieder passieren darf. Wir sollten jetzt Gas geben und die Sicherheitsmaßnahmen umsetzen, die wir brauchen – ein für alle Mal.«

Wes mischt sich ein und grinst John an. »Ich bin überrascht! Ich dachte, Sie würden Bills Idee mögen. Ich meine, Sie lieben es doch, dafür zu sorgen, dass Dinge nicht erledigt werden, und Nein zu sagen, oder? Hier sollte doch ein Traum für Sie wahr werden!«

John wird knallrot und will gerade zu einer beißenden Antwort ansetzen, als Wes ihm seine große, fleischige Hand auf die Schulter legt und lächelnd sagt: »Hey, das war ein Witz, okay? Ich habe nur Spaß gemacht.«

Alle reden nun gleichzeitig, als Erik plötzlich aufsteht, die Verpackung seines Müsliriegels zusammenknüllt und sie quer durch den Raum in den Mülleimer wirft – den er komplett verfehlt. Er lehnt sich in seinem Stuhl zurück und sagt: »Bill, ich denke, Ihr Vorschlag ist sehr klug.«

Er sieht John an und fährt fort: »Denken Sie daran, Jimmy, das Ziel ist, den Durchsatz des gesamten Systems zu erhöhen, nicht nur die Anzahl der erledigten Aufgaben. Und wenn Sie kein vertrauenswürdiges Arbeitssystem haben, warum sollte ich dann Ihrem System von Sicherheitsmaßnahmen trauen? Bah. Totale Zeitverschwendung.«

John schaut Erik verwirrt an. »Was?«

Erik seufzt und verdreht die Augen. Statt John zu antworten, wendet er sich Steve zu. »Sie waren ein Betriebsleiter. Stellen Sie sich vor, Sie würden keine weiteren Materialien mehr freigeben, bis genug WIPs abgearbeitet sind und die Halle verlassen haben. Um dieses System unter Kontrolle zu bringen, müssen wir die Zahl der beteiligten Komponenten verringern.«

Da Steve nicht überzeugt scheint, lehnt sich Erik in seinem Stuhl vor und fragt ihn: »Stellen Sie sich vor, Sie wären der Manager von MRP-8, und die Zwischenprodukte würden sich bis zur Decke stapeln. Was würde passieren, wenn Sie keine Aufträge und Materialien mehr freigeben würden?«

Überrascht von der Richtung der Frage, überlegt Steve einen Moment. »Die Menge an WIPs würde sich verringern, weil die fertigen Produkte das Gebäude verlassen würden.«

»Korrekt«, sagt Erik und nickt zustimmend. »Und was wird wahrscheinlich mit der Liefertreue geschehen?«

»Die wird nach oben gehen, weil WIP nach unten geht«, sagt Steve zunehmend argwöhnisch und ablehnend angesichts der Richtung, die diese Unterhaltung einschlägt.

»Ja, sehr gut«, sagt Erik ermutigend. »Aber was passiert andererseits mit der Menge an Zwischenprodukten, wenn die Fertigungsplätze weiterhin Aufträge annehmen und freigeben?«

Nach einem Moment sagt er: »WIP geht nach oben.«

»Exzellent«, sagt Erik. »Und was passiert mit der Liefertreue?«

Steve sieht aus, als müsste er etwas sagen, das ihm gar nicht passt. »Jeder weiß, dass in der Fertigung die Liefertreue sinkt, wenn die WIP steigt.«

»Moment mal«, sagt er und schaut Erik skeptisch an. »Sie meinen doch nicht etwa, dass das auch in der IT gilt, oder? Dass wir die Menge an WIPs in der IT verringern, wenn wir alle anderen Arbeiten außer Phoenix einstellen, und dass wir dadurch irgendwie unsere Liefertreue verbessern? Meinen Sie das ernst?«

Erik lehnt sich zufrieden in seinem Stuhl zurück. »Ja.«

Wes sagt: »Würden dann nicht die meisten von uns nur Däumchen drehen, weil sie nichts zu tun hätten? 130 Leute in IT Operations würden nur herumsitzen. Klingt das nicht ein bisschen ... wie Verschwendung?«

Erik schnaubt und sagt: »Ich werde Ihnen etwas zu Verschwendung erzählen. Wie wäre es mit über 1000 Änderungen, die im System festhängen – ohne Chance, sie je abzuschließen?«

Wes runzelt die Stirn. Dann nickt er und sagt: »Das stimmt. Die Menge an Karten an Pattys Change-Board wächst die ganze Zeit. Wenn das Work in Process ist, gerät sie definitiv außer Kontrolle. In ein paar Wochen werden sich diese Karten vermutlich auch bis zur Decke stapeln.«

Ich nicke. Er hat recht.

Die Idee ist, dass IT Operations und die Entwicklung für zwei Wochen keine neuen Projekte annehmen und sämtliche Arbeit in IT Operations gestoppt wird, die nichts mit Phoenix zu tun hat.

Ich schaue mich um. »Wenn wir uns zwei Wochen nur um das wichtigste Projekt kümmern und es dann immer noch nicht geschafft haben, echte Fortschritte zu machen, sollten wir uns alle neue Jobs suchen.«

Chris nickt. »Ich denke, wir sollten es versuchen. Wir werden weiter an den anderen aktiven Projekten arbeiten, aber alle Auslieferungen stoppen – außer Phoenix. Aus Bills Perspektive wird das so aussehen, als würden wir nur daran arbeiten. Ohne Zweifel wird Phoenix dann bei jedem ganz oben in der Priorität stehen.«

Patty und Wes nicken beide zustimmend.

John verschränkt die Arme. »Ich weiß nicht, ob ich diesem wahnwitzigen Vorschlag zustimmen kann. Erstens habe ich noch keine Organisation erlebt, die auch nur entfernt so etwas getan hat. Und zweitens mache ich mir Sorgen, dass wir unsere Chance verpassen, die ganzen Audit-Probleme zu beheben. Wie Steve schon sagte – die Audit-Probleme können unsere Firma ebenfalls ins Aus schießen.«

»Wissen Sie, was Ihr Problem ist?«, sagt Erik und zeigt auf John. »Sie sehen nie den End-to-End-Businessprozess, daher garantiere ich Ihnen, dass viele der Maßnahmen, die Sie umsetzen wollen, gar nicht notwendig sind.«

John sagt: »Was?«

Erneut wischt Erik Johns Frage beiseite. »Machen Sie sich darum jetzt keine Sorgen. Lassen Sie das Unvermeidliche geschehen, und dann schauen wir, was wir daraus lernen können.«

Steve wendet sich an John. »Ich verstehe Ihre Sorgen bezüglich der Sicherheit. Aber die ungelösten Audit-Probleme sind nicht das größte Risiko für die Firma. Das größte Risiko ist, dass wir nicht überleben. Wir brauchen Phoenix, um mit der Konkurrenz wieder gleichzuziehen.«

Er macht eine Pause und sagt dann: »Geben wir dem Projekt-Freeze eine Woche und sehen dann, ob das der Arbeit an Phönix weiterhilft. Wenn nicht, bekommen die Audit-Ergebnisse wieder mehr Aufmerksamkeit. Okay?«

John nickt widerstrebend. Dann blättert er eine Seite in seinem Ordner um und macht sich Notizen. Vermutlich dokumentiert er Steves Versprechen.

»Steve, wir brauchen dabei definitiv Ihre Hilfe«, sage ich. »Meine Leute werden regelmäßig dazu genötigt, bei den Lieblingsprojekten von so gut wie jedem Manager in dieser Firma mitzumachen. Ich denke, wir benötigen von Ihnen eine E-Mail an die gesamte Firma, in der Sie nicht nur erklären, warum wir das tun, sondern auch, was die Konsequenzen sein werden, wenn jemand versucht, nicht genehmigte Aufträge ins System zu schmuggeln.«

Erik gibt ein ermunterndes Grunzen von sich.

»Kein Problem«, gibt Steve zurück. »Ich werde Ihnen allen nach diesem Meeting einen Entwurf schicken. Schauen Sie ihn sich an, und wenn es keine Einwände gibt, werde ich ihn an alle Manager in der Firma schicken. Ist das in Ordnung?«

Ich versuche, so gut es geht meinen Zweifel aus meiner Stimme rauszuhalten, und antworte nur: »Ja.«

Erstaunlich, worauf wir uns in der nächsten Stunde einigen. IT Operations friert alle Nicht-Phoenix-Projekte ein. Die Entwicklung kann ihre über 20 Nicht-Phoenix-Projekte nicht einfach liegen lassen, wird aber keine Auslieferung starten. Mit anderen Worten: Zwei Wochen lang wird keine Arbeit von der Entwicklungsabteilung an IT Operations gehen.

Zudem werden wir die größten technischen Schulden ausfindig machen, die die Entwicklung dann angeht, um die ungeplante Arbeit, die durch kritische Anwendungen im Produktivbetrieb entsteht, zu minimieren.

Das wird die Arbeitslast in meinem Team deutlich ändern.

Zudem werden Chris und Kirsten alle Phoenix-Aufgaben begutachten, an denen nicht gearbeitet wird, und Ressourcen von anderen Projekten abziehen, um sie weiterzubringen.

Alle scheinen aufgeregt und begeistert davon zu sein, den Plan umzusetzen – selbst John.

Bevor wir gehen, sagt Steve: »Vielen Dank an Sie alle für Ihre guten Ideen und dafür, etwas von sich preiszugeben. Ich habe das Gefühl, dass ich Sie jetzt besser kenne. Und so unglaublich Bills verrückte Idee mit dem Einfrieren der Projekte ist – es könnte klappen. Hoffen wir, dass dies die erste von vielen großartigen Entscheidungen ist, die dieses Team treffen wird.

Wie ich schon sagte: Eines meiner Ziele ist, ein Team aufzubauen, in dem wir einander vertrauen können«, fährt er fort. »Hoffentlich haben wir einen kleinen Schritt in diese Richtung gemacht, und ich bitte Sie, weiterhin ehrlich und wahrhaftig miteinander umzugehen.«

Er schaut sich im Raum um und fragt: »Gibt es etwas, das Sie bis dahin von mir brauchen?«

Es gibt keine Wünsche, also vertagen wir uns.

Beim Aufstehen sagt Erik dann laut: »Tolle Arbeit, Bill. Ich hätte es nicht besser machen können.«

KAPITEL 20

Freitag, 26. September

Drei Tage später sitze ich an meinem Schreibtisch und versuche, an meinem Laptop einen Bericht von Kirsten über den Fortschritt bei Phoenix zu lesen. Während der Rechner brummt und pfeift, frage ich mich, wie viele Wochen es jetzt her ist, dass Johns Sicherheitspatch meinen Laptop plattgemacht hat.

Einen Ersatzlaptop zu bekommen, ist ein Glücksspiel. Es ist verführerisch, einen der Service-Desk-Kollegen zu bestechen, wie es einer der Marketing-Manager vorgeschlagen hat, aber ich will mich nicht vordrängeln. Ich muss mich an die Regeln halten, da ich derjenige bin, der für sie verantwortlich ist und für deren Umsetzung sorgen soll. Ich mache eine Notiz, mit Patty darüber zu sprechen, dass wir die Bearbeitungszeit für das Austauschen von Laptops unbedingt verringern müssen.

Schließlich kommt diese E-Mail an:

Von: Kirsten Fingle

An: Steve Masters

Cc: Bill Palmer, Chris Allers, Sarah Moulton

Datum: 26. September, 10:33

Betreff: Tolle Nachrichten von der Projekt-Front!

Wir machen endlich Fortschritte. Der Projekt-Freeze und der daraus entstandene IT-Fokus auf Phoenix hat die Blockade aufgebrochen. In den vergangenen sieben Tagen haben wir mehr geschafft als sonst in einem ganzen Monat.

Vielen Dank an alle im Team!

Allerdings sind viele Projektsponsoren sehr frustriert, weil ihre Projekte auf Eis gelegt wurden. Insbesondere Sarah Moulton glaubt, dass ihre Projekte von dem Freeze ausgenommen sind. Ich habe sie an Sie verwiesen.

Im Anhang finden Sie den formalen Statusbericht. Bitte melden Sie sich, wenn Sie Fragen dazu haben.

Kirsten

Auch wenn ich mich über die Anmerkung zu Sarah ärgere, die wieder Stress macht, sind das ansonsten ausgesprochen tolle Neuigkeiten.

Wir haben das zwar erwartet, aber diese gute Nachricht ist trotzdem willkommen – insbesondere nach dem Vorfall Anfang der Woche. Wir hatten einen dicken Dämpfer erhalten, weil ein Sev-1-Vorfall alle internen Telefone und Voicemail-Systeme lahmlegte. Vertrieb und Fertigung standen still – und das an einem der letzten Tage des Quartals.

Zwei Stunden nach Beginn des Ausfalls entdecken wir die Ursache. Einer unserer Netzwerkhersteller hatte unabsichtlich eine Änderung am produktiven Telefonsystem vorgenommen statt wie geplant am Ersatzsystem.

Der Ausfall wird unsere Quartalserträge beeinflussen, aber wir wissen noch nicht, wie sehr. Um zu verhindern, dass das wieder passiert, setzen wir ein Projekt auf, mit dem unsere kritischen Systeme auf unberechtigte Änderungen hin überwacht werden.

Über dieses Monitoring-Projekt reden Wes, Patty und John gerade, als sie an Pattys Besprechungstisch sitzen.

Ich sage: »Entschuldigt die Störung, aber ich wollte euch gute Neuigkeiten mitteilen.« Dann zeige ich ihnen Kirstens E-Mail.

Wes lehnt sich zurück und sagt: »Nun, damit ist es offiziell. Dein Projekt-Freeze funktioniert tatsächlich.«

Patty schaut ihn überrascht an. »Hast du wirklich daran gezweifelt? Wir haben doch beide darüber gesprochen, dass wir die Leute noch nie so konzentriert haben arbeiten sehen. Erstaunlich, wie sehr der Projekt-Freeze Prioritätenkonflikte und schlechtes Multitasking verringert hat. Die Produktivität ist massiv angestiegen.«

Wes zuckt mit den Schultern und lächelt. »Bis Kirsten uns dafür gelobt hat, war das aber alles nur in unseren Köpfen.«

Da hat er recht. Es ist wirklich toll, dass Kirsten unseren Fortschritt würdigt.

»Ach übrigens«, sagt Patty, »das mit den Businessmanagern, die stinkig werden, stimmt. Mich rufen immer mehr VPs an und fordern eine Sonderfreigabe für ihre diversen Lieblingsprojekte. Oder sie möchten, dass etwas inoffiziell erledigt wird. Das ist nicht nur Sarah – sie macht es nur am lautesten und am offensichtlichsten.«

Ich runzle die Stirn. »Okay, das gehört zu unserem Job, und wir haben es erwartet. Aber ich will nicht, dass unsere Leute diesen Druck abbekommen. Wes?«

»Ich habe allen in meinem Team gesagt, dass sie sämtliche Beschwerden zu mir weiterleiten sollen. Und glaube mir – ich rufe jeden diese Typen an und verpasse ihm einen Einlauf«, sagt er.

Patty ergänzt: »Ich mache mir schon Sorgen, was wir tun, wenn der Projekt-Freeze aufgehoben wird. Würden wir damit nicht einfach die Schleusentore öffnen?«

Wieder einmal hat sie den Finger auf etwas Wichtiges gelegt. Ich antworte: »Ich werde Erik anrufen, aber zuvor möchte ich noch wissen: Wie priorisieren wir momentan unsere Arbeit? Wenn wir zusagen, an einem Projekt, einer Änderung, einer Serviceanfrage oder irgendetwas anderem zu arbeiten – wie wird entschieden, woran zu einem bestimmten Zeitpunkt gearbeitet wird? Was passiert, wenn es konkurrierende Prioritäten gibt?«

»Das passiert jeden verdammten Tag!«, sagt Wes und blickt skeptisch. »Das ist doch das Tolle an dem Freeze – nur ein Projekt. Keiner muss entscheiden, woran er arbeitet. Kein Multitasking.«

»Das habe ich nicht gefragt«, sage ich. »Wie entscheiden die Leute zu einem beliebigen Zeitpunkt, woran gerade gearbeitet werden muss, wenn wir mehrere Projekte unterstützen?«

»Na ja«, sagt Wes, »wir vertrauen darauf, dass sie anhand der vorhandenen Daten die richtige Entscheidung treffen. Deswegen stellen wir ja kluge Köpfe ein.«

Das ist nicht gut.

Ich erinnere mich an die 20 Minuten, die ich Brent vor dem Projekt-Freeze beobachtet habe, und frage: »Und welche Daten sind das, auf denen all unsere klugen Köpfe ihre Entscheidungen aufbauen?«

Wes verteidigt sich: »Wir versuchen doch alle, die konkurrierenden Prioritäten so gut wie möglich gegeneinander abzuwägen. So ist halt das Leben, Prioritäten ändern sich.«

»Seien wir mal ehrlich«, sagt Patty. »Priorität 1 erhält der, der am lautesten schreit, wobei der im Vorteil ist, der es zum wichtigeren Manager eskalieren kann. Oder sie machen es subtiler. Ich habe einige meiner Leute beobachtet, die die Anfragen eines bestimmten Managers bevorzugen, weil er sie einmal im Monat zum Mittagessen einlädt.«

Na toll. Nicht nur, dass manche Techniker bedrängt werden, ich habe auch welche, die wie Corporal Max Klinger von M*A*S*H ihren eigenen Schwarzmarkt mit IT-Arbeit laufen lassen.

»Wenn das stimmt, sehe ich keine Möglichkeit, den Projekt-Freeze wieder aufzuheben. Seht ihr denn nicht, dass wir keine Arbeit in die IT-Abteilung geben können mit dem Vertrauen, dass sie auch erledigt wird?«

Ich versuche, nicht allzu resigniert zu klingen, und sage: »Patty hat recht. Wir müssen uns noch vieles überlegen, bevor der Projekt-Freeze endet. Was in genau einer Woche der Fall sein wird.«

Ich entscheide mich für einen kurzen Spaziergang über den Campus, um meine neuen Gedanken erst mal zu ordnen.

Ich bin unsicherer denn je. Wie wollen wir verhindern, dass die Arbeit dauernd unterbrochen wird oder die Prioritäten von Leuten aus dem Business oder anderen IT-Kollegen gegeneinander ausgespielt werden, wenn wir mehr als ein Projekt gleichzeitig betreuen?

Die Sonne scheint. Es ist 11 Uhr am Vormittag, und die Luft riecht nach Herbst. Die Blätter an den Bäumen beginnen, sich orange und braun zu färben, und die ersten Laubhaufen entstehen auf dem Parkplatz.

Trotz der Sorgen, die ich mir mache, merke ich, wie erfrischend es ist, darüber nachdenken zu können, welche Arbeit erledigt werden muss und wie sie priorisiert und freigegeben werden kann. Einen Moment wundere ich mich über das Fehlen des ständigen Feuerlöschens, das meine IT-Karriere bisher verlässlich begleitet hat.

Die Art von Problemen, die wir in letzter Zeit lösen mussten, war ... ja, intellektuell herausfordernd.

Als ich meinen MBA machte, dachte ich, dass es beim Managen genau darum gehen würde.

Ich bin überzeugt: Wenn wir uns beim Denken anstrengen, können wir wirklich etwas bewirken. Jetzt rufe ich erst einmal Erik an.

»Hallo?«, höre ich ihn sagen.

»Hallo, hier ist Bill. Haben Sie ein paar Minuten Zeit? Ich habe einige Fragen zum Projekt-Freeze.« Ich mache eine Pause, dann füge ich hinzu: »Oder eher, was passiert, wenn wir ihn aufheben.«

»Ah, das wurde auch Zeit. Ich habe mich schon gefragt, wann Sie bemerken würden, dass Sie ein riesiges neues Problem vor sich haben.«

Ich erzähle ihm kurz von den guten Nachrichten von Kirsten. Dann beschreibe ich die Probleme, über die wir gestolpert sind, als wir uns Gedanken über das Monitoring-Projekt gemacht haben, und wie wir die Aktivitäten im System schützen.

»Nicht schlecht, Junior!«, sagt Erik. »Sie haben offensichtlich unsere Unterhaltung über Engpässe in die Praxis umgesetzt und alles, was möglich war, getan, um diesen Engpass vor ungeplanter Arbeit zu schützen. Sie stellen ein paar sehr wichtige Fragen über den Ersten Weg und wie Sie den Fluss der geplanten Arbeit verwalten können. Bevor Sie das nicht können, lässt sich eigentlich gar nichts richtig verwalten, oder?

Sie sind verwirrt, weil Sie feststellen, dass Sie nicht wissen, wie Aufgaben tatsächlich abgearbeitet werden«, fährt er fort.

Ich unterdrücke ein irritiertes Seufzen.

»Ich glaube, es ist Zeit für einen weiteren Ausflug nach MRP-8. Wie schnell können Sie dort sein?«, fragt er.

Überrascht entgegne ich: »Sie sind in der Stadt?«

»Jepp«, sagt er. »Heute Nachmittag gibt es ein Meeting mit den Auditoren und den Finance-Leuten, das ich um keinen Preis der Welt verpassen möchte. Sorgen Sie dafür, dass Sie auch da sind. Wir werden John dort einen Kopf kürzer machen.«

Ich sage ihm, dass ich in 15 Minuten bei MRP-8 sein kann.

Erik wartet im Eingangsbereich auf mich.

Ich muss zweimal hinsehen. Er trägt ein ausgeblichenes T-Shirt und einen Hoodie mit einem verwaschenen Gewerkschaftslogo. Mit seinem Besucherausweis in der Hand winkt er mir ungeduldig zu.

»Ich bin so schnell gekommen, wie ich konnte«, sage ich.

Erik grummelt nur kurz und bedeutet mir, ihm zu folgen. Erneut steigen wir die Treppen hinauf und gelangen auf den Laufsteg über dem Fertigungsbereich. »Erzählen Sie mir, was Sie hier sehen«, sagt er und gestikuliert nach unten.

Ich schaue dorthin und bin verwirrt, weil ich nicht weiß, was Erik hören will. Also fange ich mit dem Offensichtlichen an: »Wie beim letzten Mal sehe ich Rohmaterialien, die an der Laderampe links ausgeladen werden. Und rechts sehe ich die fertigen Produkte, die dort an der Laderampe verladen werden.«

Überraschenderweise nickt Erik zustimmend. »Gut. Und dazwischen?«

Ich schaue mir die Szenerie an. Ich fühle mich irgendwie ein bisschen dumm und habe Angst, dass ich wie Karate Kid aussehe, der von Mr. Miyagi befragt wird. Aber ich habe um dieses Treffen gebeten, also rede ich weiter: »Ich sehe Zwischenprodukte und Work in Process, die von links nach rechts fließen – aber offensichtlich sehr langsam.«

Erik späht über das Geländer hinaus und sagt: »Wirklich? Wie eine Art Fluss?«

Er wendet sich mir zu und schüttelt missbilligend den Kopf. »Was, glauben Sie, soll das hier sein? Eine Art Poesiekurs? Plötzlich ist WIP wie Wasser, das über glatte Steine plätschert? Jetzt mal im Ernst. Was würde ein Betriebsleiter auf die Frage antworten? Von wo nach wo geht die Arbeit und warum?«

Ich versuche es erneut. »Okay, okay. WIP geht von Arbeitsstation zu Arbeitsstation, bestimmt durch die Stückliste und den Arbeitsplan. Und all das steht im Arbeitsauftrag, der dort drüben am Schreibtisch freigegeben wurde.«

»Das ist besser«, sagt Erik. »Und entdecken Sie die Arbeitsstationen, die in dieser Halle die Engpässe sind?«

Erik hatte mir das schon bei unserem ersten seltsamen Ausflug hierhin erzählt.

»Die Härtungsöfen und die Trockenkabinen«, sage ich schnell.

»Dort drüben«, zeige ich, nachdem ich in der Halle gesucht und schließlich auf der anderen Seite eine Reihe großer Maschinen gefunden habe. »Und dort«, sage ich und zeige auf einen großen Raum mit den Schildern »Trockenraum 30-A« und »Trockenraum 30-B«.

»Gut. Der Schlüssel zum Erreichen des Ersten Wegs ist, den Arbeitsfluss zu verstehen«, sagt Erik nickend. Ernster fragt er dann: »Dann sagen Sie mir jetzt noch mal, welche Arbeitsstationen Sie in Ihrer Organisation als Engpässe erkannt haben.«

Ich lächle und antworte problemlos: »Brent. Darüber haben wir schon gesprochen.«

Er schnaubt, dreht sich von mir weg und lässt seinen Blick über die Halle schweifen.

»Was?«, brülle ich fast. »Wieso ist es nicht Brent? Sie haben mir sogar gratuliert, als ich Ihnen vor ein paar Wochen gesagt habe, es sei Brent!«

»Ist Brent plötzlich ein automatischer Härtungsofen? Sie wollen mir sagen, Ihr Äquivalent zu dieser Trockenkabine dort unten sei Brent?«, sagt er mit vorgetäuschtem Unglauben. »Wissen Sie, das ist vielleicht das Dümmste, was ich je gehört habe.«

Er fährt fort: »Was wären dann Ihre beiden Manager, Chester und Penelope? Hmm, mal überlegen. Vielleicht entsprechen sie dieser Standbohrmaschine und der Stanzmaschine da drüben? Oder dem Metallschleifer dort?«

Erik sieht mich ernst an. »Jetzt mal ehrlich. Ich habe Sie gefragt, welche Arbeitsstationen Ihre Engpässe sind. Denken Sie nach.«

Völlig verwirrt schaue ich in die Halle.

Ich weiß, dass ein Teil der Antwort Brent ist. Aber als ich das so zuversichtlich hinausposaunt habe, hat mir Erik nur einen Schlag auf den Hinterkopf verpasst. Mal wieder.

Erik scheint bestürzt zu sein, dass ich eine Person genannt habe und es damit so aussah, als wäre Brent ein Teil des Equipments.

Ich schaue nochmals zum Härtungsofen. Und dann sehe ich es. Es gibt dort zwei Personen, die Overalls, Schutzhelme und Schutzbrillen tragen. Einer steht vor einem Computerbildschirm und gibt etwas ein, der andere untersucht Teile auf einem Laderost und scannt etwas mit einem Handheld.

»Oh«, sage ich und denke laut. »Der Härtungsofen ist eine Arbeitsstation, dem Arbeiter zugeordnet sind. Sie haben gefragt, welche Arbeitsstationen unsere Engpässe sind, und ich habe Ihnen gesagt, dass das Brent sei – was aber nicht stimmen kann, denn Brent ist keine Arbeitsstation.

Brent ist ein Arbeiter, keine Arbeitsstation«, sage ich nochmals. »Und ich wette, dass Brent ein Arbeiter ist, der viel zu viele Arbeitsstationen bedient. Darum ist er ein Engpass.«

»Jetzt kommen wir weiter!«, sagt Erik lächelnd. Er weist über die Fertigungshalle und sagt: »Stellen Sie sich vor, 25 Prozent aller Arbeitsstationen dort unten könnten nur von einer Person namens Brent bedient werden. Was würde mit dem Arbeitsfluss geschehen?«

Ich schließe die Augen und denke nach.

»Die Arbeit könnte nicht rechtzeitig fertig werden, weil Brent immer nur an einer Arbeitsstation gleichzeitig sein kann«, sage ich. Enthusiastisch fahre ich fort: »Das ist genau das, was bei uns passiert. Ich weiß, dass mit einem Haufen geplanter Änderungen gar nicht erst begonnen werden kann, wenn Brent nicht zur Verfügung steht. Wenn das geschieht, übergeben wir es Brent und fordern ihn auf, alles stehen und liegen zu lassen, damit eine andere Arbeitsstation bedient werden kann. Wenn wir Glück haben, bleibt er dort lange genug, um die Änderung vollständig umzusetzen, bevor er von etwas anderem unterbrochen wird.«

»Genau!«, sagt Erik.

Ich bin ein bisschen bestürzt über das angenehme Gefühl, das ich durch die Bestätigung verspüre.

»Offensichtlich«, fährt er fort, »besteht jede Arbeitsstation aus vier Dingen: der Maschine, den Menschen, der Methode und der Messung. Nehmen wir den Härtungsofen als Beispiel. Die Menschen sind die zwei Personen, die notwendig sind, um die vorgegebenen Schritte umzusetzen, und die Messung muss offensichtlich auf dem Ergebnis der Ausführung dieser Schritte basieren.« Ich runzle die Stirn. Diese Begriffe sind mir aus meinen MBA-Jahren noch vage vertraut.

Aber ich hätte nie gedacht, dass sie auch im IT-Umfeld relevant wären.

Ich suche nach etwas zum Schreiben und stelle dabei fest, dass ich meinen Notizblock im Auto habe liegen gelassen. Ich klopfe meine Taschen ab und finde nur eine kleine, zerknitterte Karteikarte in meiner hinteren Hosentasche.

Schnell schreibe ich mir auf: »Arbeitsstation: Maschine, Mensch, Methode, Messung«.

Erik fährt fort: »Natürlich ist in dieser Fertigungshalle nicht ein Viertel aller Arbeitsstationen von einer Person abhängig. Das wäre absurd. Unglücklicherweise trifft das aber bei Ihnen zu. Wenn Brent Urlaub macht, kommen alle möglichen Arbeiten zum Erliegen, weil nur er weiß, wie bestimmte Schritte erledigt werden – Schritte, von denen vermutlich nur er selbst überhaupt weiß, dass sie existieren, oder?«

Ich nicke und kann mir ein Grummeln nicht verkneifen. »Sie haben recht. Ich habe schon gehört, wie sich meine Manager darüber beschwert haben, dass wir komplett geliefert wären, wenn Brent von dem sprichwörtlichen Bus überfahren würde. Keiner weiß, was alles in Brents Kopf steckt. Das ist einer der Gründe, warum ich den Level-3-Eskalationspool aufgesetzt habe.«

Kurz erkläre ich, was ich getan habe, um Eskalationen an Brent bei Ausfällen zu verhindern, um ihn vor ungeplanter Arbeit zu schützen, und wie ich das Gleiche auch für geplante Änderungen vorhabe.

»Gut«, sagt er. »Sie standardisieren Brents Arbeit, sodass auch andere Personen sie durchführen können. Und weil Sie diese Schritte endlich dokumentieren lassen, können Sie auch eine gewisse Konsistenz und Qualität sicherstellen. Sie reduzieren nicht nur die Anzahl an Arbeitsstationen, für die Brent notwendig ist, sondern Sie schreiben auch noch eine Dokumentation, die es Ihnen ermöglicht, einige davon zu automatisieren.«

Er fährt fort: »Bis Sie das durchgezogen haben, ist es übrigens egal, wie viele Brents Sie noch einstellen – Brent wird immer Ihr Engpass bleiben. Jeder, den Sie einstellen, wird nur herumstehen.«

Ich nicke und verstehe. Das ist genau das, was Wes beschrieben hat. Obwohl er zusätzliche Leute eingestellt hat, um mehr Brents zu bekommen, konnten wir unseren Durchsatz nie wirklich erhöhen.

Ich fühle eine plötzliche Heiterkeit in mir aufsteigen, als sich die Puzzlestücke in meinem Kopf zusammensetzen. Erik bestätigt einige meiner langjährigen Erfahrungen und liefert eine begründete Theorie dazu.

Meine Freude ist nur von kurzer Dauer. Er sieht mich missbilligend an: »Sie fragen, was Sie machen sollen, wenn der Projekt-Freeze wieder aufgehoben wird. Ihr Problem ist, dass Sie zwei Dinge durcheinanderbringen. Bis Sie die in Ihrem Kopf trennen können, werden Sie sich nur im Kreis drehen.«

Er geht weiter, und ich haste hinter ihm her. Bald stehen wir in der Mitte der Fabrikhalle.

»Sehen Sie die Arbeitsstation dort hinten, die mit dem gelb blinkenden Licht?«, fragt er und zeigt an einen Platz.

Ich nicke und er sagt: »Erzählen Sie mir, was Sie dort sehen.«

Ich frage mich, wie eine normale Unterhaltung mit ihm aussehen würde, aber ich bleibe in meiner Rolle als kleiner Schüler. »Ein Teil der Maschine scheint nicht zu laufen – darum wohl das gelbe Blinklicht. Fünf Leute beschäftigen sich damit, unter anderem zwei Vorarbeiter. Alle sehen besorgt aus. Drei weitere Personen krabbeln unter der Maschine herum und scheinen sich die Elektronik anzuschauen. Sie haben Taschenlampen dabei und – ah ja, auch Schraubendreher. Definitiv ein Maschinenschaden ...«

»Gute Einschätzung«, sagt Erik. »Das ist vermutlich eine computergesteuerte Schleifmaschine, die gerade nicht läuft, und das Wartungsteam versucht, sie wieder in Gang zu bekommen. Was würde passieren, wenn jede Maschine dort unten von Brent repariert werden müsste?«

Ich lache. »Jeder Ausfall landet direkt bei Brent.«

»Ja.« Er fährt fort: »Beginnen wir mit Ihrer ersten Frage. Welche Projekte können wieder sicher angegangen werden, wenn der Projekt-Freeze aufgehoben wird? Mit Ihrem Wissen über den Arbeitsfluss durch bestimmte Arbeitsstationen und die Notwendigkeit, Brent einsetzen zu müssen oder nicht – wie ist Ihrer Meinung nach die Antwort?«

Ich wiederhole langsam, was Erik gerade gesagt hat, und versuche, die Antwort zu finden.

»Ich hab’s«, sage ich lächelnd. »Gute Kandidaten sind Projekte, die Brent nicht brauchen.«

Ich lächle noch mehr, als er sagt: »Bingo. Ziemlich einfach, oder?«

Mein Lächeln gefriert, als ich an die Folgen denke. »Moment. Woher weiß ich denn, bei welchen Projekten Brent nicht benötigt wird? Wir sind immer der Meinung, dass Brent nicht gebraucht wird, bis die Arbeit schon zur Hälfte erledigt ist.«

Schnell ergänze ich: »Entschuldigung, ich werde es herausfinden. Wissen Sie, ich werde sehr erleichtert sein, wenn wir ausgemacht haben, für welche Arbeiten Brent wirklich notwendig ist.«

»Da haben Sie verdammt recht«, sagt er. »Sie erstellen die Stückliste für alle Arbeiten, die Sie in IT Operations ausführen. Aber statt einer Liste mit Teilen und Halbwerkzeugen, zum Beispiel Formen, Schrauben und Gießern, katalogisieren Sie alle Voraussetzungen, die erfüllt sein müssen, um eine Arbeit zu erledigen – Laptopmodellnummern, Spezifikationen von Benutzerinformationen, benötigte Software und Lizenzen, die Konfigurationen, Versionsinformationen, Security-, Kapazitäts- und Kontinuitätsanforderungen und so weiter und so fort.«

Er unterbricht sich selbst und sagt dann: »Na ja, genauer gesagt, erstellen Sie eine Ressourcenliste. Das ist die Stückliste zusammen mit der Liste der notwendigen Arbeitsstationen und dem Arbeitsplan. Haben Sie all das – zusammen mit den Arbeitsaufträgen und Ihren Ressourcen –, haben Sie auch einen Überblick über Ihre Kapazität und Ihre Anforderungen. So werden Sie endlich wissen, ob Sie einen neuen Auftrag annehmen können, und ihn dann auch richtig einplanen.«

Erstaunlich. Ich glaube, ich habe es fast verstanden.

Ich will noch mehr Fragen stellen, aber Erik sagt: »Ihre zweite Frage war, ob es richtig ist, Ihr Monitoring-Projekt nun zu starten. Sie haben es schon so eingerichtet, dass Brent nicht gebraucht wird. Zudem haben Sie gesagt, dass das Ziel dieses Projekts ist, Ausfälle zu vermeiden, womit Eskalationen an Brent verringert werden. Dazu kommt: Tritt ein Ausfall ein, brauchen Sie weniger Zeit von Brent, um diesen zu beheben. Sie haben schon den Engpass erkannt, versuchen, ihn so gut wie möglich auszunutzen, und beschränken den Zufluss dorthin. Wie wichtig ist also dieses Monitoring-Projekt?«

Ich denke einen Moment nach. Und dann grummle ich angesichts der offensichtlichen Antwort.

Ich fahre mir durchs Haar. »Sie haben gesagt, dass wir immer nach Wegen suchen müssen, den Engpass auszunutzen, also muss ich so viel wie möglich aus Brent herausholen. Und genau das tut das Monitoring-Projekt!«

Etwas ungläubig, dass ich das vorher nicht erkannt habe, sage ich: »Das Monitoring-Projekt ist vermutlich das wichtigste Verbesserungsprojekt, das wir haben – wir müssen sofort damit anfangen.«

»Ganz genau«, sagt Erik. »Das saubere Durchführen vorbeugender Arbeit macht das Herz von Programmen wie Total Productivity Maintenance aus, das von der Lean Community übernommen wurde. Bei TPM dreht es sich darum, dass wir alles Notwendige tun, um die Verfügbarkeit von Maschinen durch rechtzeitige Wartung sicherzustellen. Wie einer meiner Senseis sagen würde: ›Das Verbessern der täglichen Arbeit ist noch wichtiger als das eigentliche Ausführen der täglichen Arbeit.‹ Beim Dritten Weg geht es darum, sicherzustellen, dass wir ständig Spannung ins System bringen, sodass wir kontinuierlich Gewohnheiten überprüfen und etwas verbessern. Beim Resilience Engineering lernen wir, dass wir regelmäßig und häufig Fehler in das System bringen sollten, um sie weniger schmerzhaft werden zu lassen.

Mike Rother sagt, dass es nahezu egal ist, was Sie verbessern, solange Sie überhaupt etwas verbessern. Warum? Wenn Sie nichts verbessern, sorgt schon die Entropie dafür, dass es schlechter wird. Es gibt dann keinen Weg zu null Fehlern, null Arbeitsunfällen und null Verlusten.«

Plötzlich ist es so offensichtlich. Ich habe das Gefühl, ich muss sofort Patty anrufen und sie bitten, direkt mit dem Monitoring-Projekt zu beginnen.

Erik fährt fort: »Rother nennt dies das Verbesserungs-Kata. Er verwendet den Begriff Kata, weil er verstanden hat, dass sich durch Wiederholung Gewohnheiten bilden und Gewohnheiten zur Meisterschaft führen. Ob Sie über Sporttraining, das Erlernen eines Musikinstruments oder Militär-Spezialkommandos sprechen – nichts hilft auf dem Weg zur Meisterschaft besser als Übung und Drill. Studien haben gezeigt, dass ein tägliches, fünfminütiges Training besser hilft als ein dreistündiges Training nur einmal pro Woche. Und wenn Sie eine echte Kultur der Verbesserung entstehen lassen wollen, müssen Sie für diese Gewohnheiten sorgen.«

Er wendet sich zur Fabrikhalle und fährt fort: »Bevor wir gehen, richten Sie Ihre Aufmerksamkeit von den Arbeitsstationen hin zu dem Bereich zwischen den Stationen. Genauso wichtig wie die kontrollierte Freigabe von Aufträgen ist die Übergabe. Die Wartezeit einer beliebigen Ressource ist der Prozentwert, den die Ressource belegt ist, geteilt durch den Prozentwert, den die Ressource nichts tut. Wenn eine Ressource also zu 50 Prozent belegt ist, beträgt die Wartezeit 50/50 oder 1 Einheit. Wenn die Ressource zu 90 Prozent belegt ist, beträgt die Wartezeit 90/10 oder 9-mal länger. Und wenn die Ressource zu 99 Prozent belegt ist?«

Auch wenn ich nicht ganz verstehe, was daran wichtig ist, berechne ich das Ergebnis: 99/1. Ich sage: »Neunundneunzig.«

»Richtig. Wenn eine Ressource zu 99 Prozent belegt ist, müssen Sie 99 Mal länger warten, als wenn diese Ressource nur zu 50 Prozent belegt ist.«

Er gestikuliert heftig. »Ein entscheidender Teil des Zweiten Wegs ist, die Wartezeiten sichtbar zu machen, sodass Sie sehen können, ob Ihre Arbeit Tage damit verbringt, in irgendeiner Warteschlange rumzusitzen – oder schlimmer noch, ob die Arbeit den Weg zurückgeht, weil Teile fehlen oder das Produkt überarbeitet werden muss.

Denken Sie daran, dass es unser Ziel ist, den Fluss zu maximieren. Hier im MRP-8 hatten wir vor vielen Jahren die Situation, dass bestimmte Komponenten nie fertiggestellt wurden. Lag es daran, dass wir nicht genug Ressourcen hatten oder weil bestimmte Arbeitsschritte zu lange dauerten?

Nein! Als wir die Teile auf ihrem Weg durch die Arbeitsstationen einmal verfolgten, stellten wir fest, dass sie den größten Teil der Zeit in irgendwelchen Warteschlangen verbrachten. Mit anderen Worten: Die ›Bearbeitungszeit‹ war nur ein winziger Teil der ›Gesamtfertigungszeit‹. Unsere Dispatcher mussten Berge von Zwischenprodukten durchforsten, um die Teile zu finden und sie durch die Arbeitsstationen zu schleusen«, sagt er skeptisch.

»Das passiert auch in Ihrer Fabrik, halten Sie also die Augen offen«, ergänzt er.

Ich nicke und sage: »Erik, ich hadere immer noch mit dem Anstoßen des Monitoring-Projekts. Die Leute bestehen alle darauf, dass ihre speziellen Projekte dringend sind und auch auf Kosten der anderen zu bearbeiten seien. Wo passen da all die unabwendbaren Audit- und Sicherheitsprojekte rein, nach denen John ruft?«

Erik schaut mich unverwandt an und sagt schließlich: »Haben Sie auch nur ein Wort von dem verstanden, was ich Ihnen in den letzten zwei Wochen erzählt habe?«

Er schaut auf seine Uhr und sagt: »Ich muss jetzt gehen.«

Erik geht zügig zum Abgang des Laufstegs, und ich muss rennen, um ihn einzuholen. Er ist groß, vermutlich etwas über 50 Jahre alt. Trotz des nicht geringen Gewichts bewegt er sich schnell.

Als ich zu ihm aufschließe, sage ich: »Warten Sie. Soll das heißen, dass die Audit-Themen nicht wichtig genug sind, um sie zu bearbeiten?«

»Das habe ich nie gesagt«, sagt er, als er stehen bleibt und mich anschaut. »Sie lassen etwas ausfallen und sorgen so dafür, dass die Firma bestimmte Regeln und Gesetze nicht befolgen kann? Besser, Sie beheben das – oder Sie werden gefeuert.«

Er geht wieder weiter und sagt über seine Schulter zu mir: »Sagen Sie mal: All die Projekte, die Ihr CISO Jimmy vorantreibt – verbessern sie den Fluss der Projektarbeit in der IT-Organisation?«

»Nein«, antworte ich schnell und muss mich wieder beeilen, um mit ihm Schritt zu halten.

»Verbessern sie die Stabilität der Produktivsysteme, oder verringern sie die Zeit, die erforderlich ist, um Ausfälle oder Sicherheitslücken zu entdecken und zu beheben?«

Ich denke etwas länger nach. »Vermutlich nicht. Viele davon sind reine Arbeitsbeschaffungsmaßnahmen, und in den meisten Fällen sind die gewünschten Änderungen riskant oder sorgen tatsächlich für Ausfälle.«

»Erhöhen diese Projekte Brents Kapazität?«

Ich lache humorlos. »Nein, im Gegenteil. Die Audit-Themen alleine würden Brent das nächste Jahr beschäftigen.«

»Und wie würden sich all die Projekte von Jimmy auf das WIP-Niveau auswirken?«, fragt er, während er die Tür zum Treppenhaus öffnet.

Während wir die Treppen hinuntergehen, sage ich genervt: »Das würde durch die Decke gehen. Wieder.«

Als wir das Erdgeschoss erreichen, bleibt Erik plötzlich stehen und sagt: »Okay. Diese ›Sicherheits‹ -Projekte verschlechtern den Durchsatz Ihrer Projekte, was einen Engpass für die gesamte Firma darstellt. Und sie verschlingen die kritischsten Ressourcen in Ihrer Organisation. Und sie tun nichts für die Skalierbarkeit, Verfügbarkeit, Überlebensfähigkeit, Sicherheit, Wartbarkeit oder den Schutz der Organisation.«

Ganz ausdruckslos fragt er: »Also, Sie Genie: Klingt das so, als wäre die Unterstützung von Jimmys Projekten ein sinnvoller Einsatz Ihrer Ressourcen?«

Als ich antworten will, öffnet er einfach die Ausgangstür und geht. Anscheinend war das eine rhetorische Frage.

KAPITEL 21

Freitag, 26. September

Obwohl ich mich an keine Geschwindigkeitsbegrenzung auf der Strecke halte, komme ich 20 Minuten zu spät zum Audit-Meeting in Gebäude 2. Als ich den Besprechungsraum betrete, bin ich überrascht, wie voll er ist.

Es ist sofort klar, dass es sich hier um ein sehr wichtiges Meeting handelt – mit politischer Brisanz. Dick und unser Firmenjurist sitzen am einen Ende des Tischs.

Auf der anderen Seite finden sich die externen Auditoren, die nach dem Gesetz dafür verantwortlich sind, Fehler und Fälschungen in den Finanzberichten zu finden, uns aber gleichzeitig nicht als Kunden verlieren wollen.

Dick und sein Team wollen zeigen, dass alles, was die Auditoren gefunden haben, nur ein großes Missverständnis ist. Ihr Ziel ist es, aufrichtig zu erscheinen, gleichzeitig aber zu zeigen, dass es unverantwortlich ist, ihre wertvolle Zeit damit verschwenden zu müssen.

Das ist alles zwar ein großes politisches Theater, aber eines auf höchster Ebene und definitiv deutlich über meiner Kragenweite.

Ann und Nancy sind ebenfalls hier, außerdem Wes und ein paar andere bekannte Gesichter.

Dann sehe ich John und muss zweimal hinsehen.

Meine Güte, sieht er furchtbar aus – wie jemand, der den dritten Tag auf Entzug ist. Er scheint darauf zu warten, dass sich gleich der ganze Raum ihm zuwenden wird, um ihn in der Luft zu zerreißen – was vielleicht gar nicht so weit von der Realität entfernt ist.

Neben John sitzt Erik, der die Gelassenheit in Person ist.

Wie konnte er so schnell hierherkommen? Und wo hat er sich diese Kakihosen und das Baumwollhemd angezogen? Im Auto? Im Gehen?

Als ich mich neben Wes setze, lehnt er sich zu mir. Er zeigt auf einen Stapel Papier und flüstert: »Die Agenda dieses Meetings sieht vor, diese beiden kritischen und die 16 mittelschweren Schwachstellen durchzugehen. Schau dir John an, er sieht aus, als würde er vor dem Erschießungskommando stehen und auf die Kugel warten.«

Ich sehe die Schweißflecken unter John Armen und denke: Meine Güte, John. Reißen Sie sich zusammen. Ich bin der Operational Manager, bei dem all diese IT-Probleme liegen, also stehe ich hier in der vordersten Reihe und nicht Sie.

Aber anders als John hat mir Erik die ganze Zeit versichert, dass alles in Ordnung sein wird.

Andererseits hat Erik auch nichts zu befürchten, und einen kurzen Moment frage ich mich, ob ich genauso nervös sein sollte wie John.

Fünf Stunden später ist der Besprechungstisch übersät mit vollgekritzelten Papieren und leeren Kaffeebechern, und die Luft im Raum ist abgestanden und schwitzig von all der Anspannung und den hitzigen Diskussionen.

Ich schaue auf, als der Audit-Partner seine Tasche zuklappt.

Er sagt zu Dick: »Angesichts dieser neuen Daten scheint es ja so zu sein, dass bei den beiden potenziell kritischen Schwachstellen die IT-Sicherheitsmaßnahmen nicht mehr passten, was sich leicht beheben lässt. Vielen Dank im Voraus, dass Sie uns die Dokumentation zukommen lassen werden, um diese Probleme so schnell wie möglich abhaken zu können.

Wir werden das in unsere Überlegungen einfließen lassen und Ihnen in den nächsten Tagen etwas schicken«, fährt er fort. »Sehr wahrscheinlich werden wir weitere Tests dieser neu dokumentierten Sicherheitsmaßnahmen ansetzen, um sicherzustellen, dass sie laufen und ihren Zweck erfüllen – nämlich die Finanzdaten abzusichern, die Sie herausgeben.«

Als er aufsteht, starre ich ungläubig auf den Audit-Partner. Wir sind tatsächlich gerade so davongekommen. Ich schaue mich am Tisch um, und der Rest des Parts Unlimited-Teams sieht genauso überrascht aus.

Eine Ausnahme bildet Erik. Er nickt zustimmend und scheint nur irritiert zu sein, dass es so lange gedauert hat, die Auditoren auf unsere Seite zu bringen.

Die andere Ausnahme ist John. Er sieht sehr bestürzt aus und sitzt mit hängenden Schultern da, sodass ich mir kurz Sorgen um seine Gesundheit mache.

Ich will gerade aufstehen und mich um John kümmern, als der Audit-Partner Dick die Hand schüttelt und Erik zu meiner Überraschung aufsteht und ihn umarmt.

»Erik – GAIT und Orlando sind schon ganz schön lange her«, sagt der Audit-Partner warmherzig. »Ich war mir sicher, dass sich unsere Wege wieder kreuzen würden, aber ich hätte nie gedacht, dass das bei einem Kunden der Fall wäre! Was haben Sie denn so getrieben?«

Erik lacht und sagt: »Ach, den größten Teil der Zeit war ich mit meinem Segelboot unterwegs. Ein Freund hat mich gefragt, ob ich mich nicht dem Aufsichtsrat von Parts Unlimited anschließen wolle – zum Teil deshalb, weil wohl deren externe Auditoren ein paar Frischlinge losgelassen haben, die über das Ziel hinausgeschossen sind. Ich hätte es wissen müssen, dass Sie da Ihre Finger im Spiel haben.«

Der Audit-Partner ist tatsächlich verlegen, und sie unterhalten sich flüsternd weiter.

In den letzten fünf Stunden saßen John, Wes und ich an der Seitenlinie und sahen zu, wie die Businessmanager den Auditoren bis ins Detail erklärten, warum die Probleme mit den IT-Sicherheitsmaßnahmen schlicht nicht zu einem unerkannten Fehler im Finanzbericht hätten führen können. Sie holten ein Dokument mit dem Titel »GAIT-Prinzipien« hervor und zeigten einige der dort enthaltenen Flowcharts.

Wie bei einem Tennismatch flog der Ball zwischen unserem Team und den Auditoren hin und her, wobei Worte wie »Verknüpfung«, »Signifikanz« und »Vertrauen in Sicherheitsmaßnahmen« fielen. Ab und zu holte Dick ein paar Experten aus den entsprechenden Businessbereichen dazu, um zu zeigen, dass, selbst wenn ein Bösewicht ein Versagen der IT-Sicherheitsmaßnahmen verursachen könnte, der Betrug trotzdem von einer anderen, darauffolgenden Sicherheitsmaßnahme erkannt würde.

Manager aus Materialwirtschaft, Auftragserfassung, Finanzabteilung und Personalverwaltung zeigten, dass böswillige Transaktionen auch dann noch von einem täglichen oder wöchentlichen Abstimmungsbericht erkannt werden würden, wenn Anwendung, Datenbank, Betriebssystem und Firewall löchrig wie ein Sieb wären.

Immer und immer wieder gingen sie Szenarien durch, in denen davon ausgegangen wurde, dass die gesamte IT-Infrastruktur völlig unzureichend geschützt wäre und sich unzufriedene oder vorsätzlich böswillige Mitarbeiter oder auch externe Hacker einloggen und ungestraft Geld abzweigen könnten.

Aber man würde trotzdem solche Fehler in den Finanzberichten erkennen.

Einmal wies Dick sogar darauf hin, dass eine ganze Abteilung mit 20 Leuten dafür verantwortlich sei, fehlerhafte oder gar betrügerische Bestellungen zu entdecken. Dieses Team – und nicht eine IT-Sicherheitsmaßnahme – würde als Sicherheitsnetz dienen.

Jedes Mal erkannten die Auditoren, wenn auch häufig nur widerstrebend, an, dass spätestens beim Erstellen der Finanzberichte auf die Sicherheitsmaßnahmen gebaut wird. Und nicht auf die IT-Systeme oder deren Maßnahmen.

Das war mir neu. Aber ich hätte mich da bestimmt nicht eingemischt. Wenn es Parts Unlimited geholfen hätte, dass ich nur sabbere und kein Wort lesen kann, um sich aus den Audit-Ergebnissen herauszuwinden, hätte ich auch das getan.

»Haben Sie eine Minute für mich?«, fragt John neben mir mit krächzender Stimme.

Er ist immer noch fertig und hält sich den Kopf.

»Sicher«, sage ich und schaue mich im nahezu leeren Raum um. Es sind nur noch John und ich hier, Erik und der Audit-Partner flüstern weiterhin am anderen Ende des Raums miteinander.

John sieht furchtbar aus. Wenn sein Hemd noch etwas knittriger wäre und ein oder zwei Flecken hätte, könnte er glatt als Obdachloser durchgehen.

»John, ist etwas mit Ihnen? Sie sehen nicht gut aus«, sage ich.

Sein Gesicht nimmt einen düsteren Ausdruck an. »Wissen Sie, wie viel politisches Kapital ich in den letzten zwei Jahren investiert habe, um jeden dazu zu bringen, das Richtige zu tun? Diese Firma hat sich seit einem ganzen Jahrzehnt nicht um die IT-Sicherheit gekümmert. Ich bin ein großes Risiko eingegangen. Jedem habe ich erzählt, dass die Welt untergeht, wenn sie nur Lippenbekenntnisse abgäben und nicht wenigstens versuchen würden, ein paar der systemischen IT-Sicherheitsprobleme zu beheben ... Ich meine, wir müssen doch wenigstens so tun, als ob wir uns darum kümmern.«

Auf der anderen Seite des Raums dreht sich Erik zu uns um. Der Audit-Partner scheint John nicht gehört zu haben. Trotzdem legt Erik den Arm um ihn und führt ihn jovial auf den Flur hinaus, um die Tür laut und deutlich hinter sich zu schließen.

Unbeirrt fährt John fort: »Es gibt Zeiten, in denen denke ich, ich sei der Einzige in der ganzen Firma, der sich wirklich um die Sicherheit unserer Systeme und Daten kümmert. Wissen Sie, wie man sich fühlt, wenn die gesamte Entwicklungsabteilung ihre Aktivitäten vor einem verbirgt und man die Leute anbetteln muss, damit sie einem sagen, wo ihre Meetings stattfinden? Bin ich denn hier im Kindergarten? Ich versuche doch, ihnen dabei zu helfen, ihre Arbeit zu erledigen!«

Als ich nichts sage, lächelt er mich nur höhnisch an. »Schauen Sie mich nicht so an. Ich weiß, dass Sie auch auf mich herabsehen.«

Ich schaue ihn ehrlich überrascht an.

»Ich weiß, dass Sie nie meine E-Mails lesen. Ich muss Sie anrufen, damit Sie sie überhaupt öffnen – das weiß ich, weil ich die Lesebestätigungen erhalte, während wir telefonieren, Sie Mistkerl.«

Ah.

Aber ich habe viele seiner E-Mails gelesen, ohne dass er mich erst anrufen musste. Wie auch immer, bevor ich antworten kann, schimpft er weiter. »Sie alle schauen auf mich herab. Wissen Sie, früher habe ich auch Server betreut, so wie Sie. Aber ich fand meine Berufung in der IT-Sicherheit. Ich wollte dabei helfen, die bösen Jungs zu fassen. Ich wollte dabei helfen, dass sich Firmen vor Leuten schützen, die dort eindringen wollen. Es war eine Art Pflicht für mich und der Wunsch, die Welt zu einem besseren Ort zu machen.

Aber seit ich hier bin, kämpfe ich nur gegen die Firmenbürokratie und das Business, obwohl ich doch versuche, sie vor sich selbst zu schützen.« Er lacht hart und sagt: »Die Auditoren sollten uns eigentlich die Daumenschrauben ansetzen. Sie sollten uns Sünder für die Dinge bestrafen, die wir getan haben. Und wissen Sie was? Den ganzen Nachmittag hat uns der Audit-Partner mit Glacéhandschuhen angefasst. Wofür braucht man dann überhaupt ein IT-Sicherheitsprogramm? Selbst die Auditoren scheren sich nicht drum! Für ein Golfspiel wurde alles unter den Teppich gekehrt.«

Jetzt schreit John fast schon. »Unsere Auditoren sollten wegen Inkompetenz vor Gericht stehen! All die Ergebnisse, die sie verworfen haben, waren grundlegende Dinge! Wir sitzen in einer Kloake. Ich bin erstaunt, dass dieser Ort nicht unter seinem eigenen Gewicht zusammenbricht, weil er sich nicht kümmert. Ich warte seit Jahren darauf, dass hier alles einstürzt.«

Er macht eine Pause, dann flüstert er: »Und doch sind wir immer noch hier ...«

Gerade da betritt Erik den Raum wieder und knallt die Tür hinter sich zu. Er lässt sich auf den Sitz neben der Tür fallen und schaut John ernst an.

»Wissen Sie, was Ihr Problem ist, Jimmy?«, sagt Erik und zeigt auf John. »Sie sind wie der Politikkommissar, der durch die Fabrikhalle geht, sein Abzeichen stolz den Bandarbeitern zeigt, sadistisch überall seine Nase reinsteckt und die Leute einschüchtert, damit sie Ihre Befehle ausführen, nur um Ihr kümmerliches Selbstwertgefühl zu vergrößern. Die Hälfte der Zeit machen Sie mehr kaputt, als Sie reparieren. Schlimmer noch: Sie bringen die Arbeitspläne von jedem durcheinander, der tatsächlich wichtige Arbeit zu erledigen hat.«

Das geht deutlich zu weit.

John platzt heraus: »Was glauben Sie, wer Sie sind? Ich versuche, diese Firma sicher zu machen und uns die Auditoren vom Hals zu halten! Ich ...«

»Na danke für gar nichts, Mr. CISO«, sagt Erik und unterbricht ihn. »Wie Sie gerade sehen konnten, kann die Firma die Auditoren auch ganz ohne Sie fernhalten. Sie sind wie der Klempner, der nicht einmal bemerkt, dass er ein Flugzeug steuert, die Route nicht kennt und auch nicht weiß, wie die Fluggesellschaft arbeitet.«

Mittlerweile ist John kreideweiß, und ihm ist die Kinnlade heruntergeklappt.

Ich will mich gerade einmischen, als Erik aufsteht und John anbrüllt: »Ich habe Ihnen nichts mehr zu sagen, bis Sie mir zeigen, dass Sie verstanden haben, was hier gerade im Raum passiert ist. Business hat es geschafft, das SOX-404-Audit zu retten – und zwar ganz ohne Hilfe durch Ihr Team. Bis Sie herausgefunden haben, wie und warum das so ist, mischen Sie sich mit Ihrer Arbeit nicht mehr in die tagtägliche Arbeit der Firma ein. Das sollte Ihre Leitlinie sein: Sie gewinnen, wenn Sie die Firma schützen, ohne das IT-System mit unsinniger Arbeit zu belasten. Und Sie gewinnen noch mehr, wenn Sie das IT-System von unsinniger Arbeit entlasten können.«

Dann dreht er sich zu mir und sagt: »Bill, vielleicht haben Sie recht. Ihre Leute hier haben die IT-Sicherheit wohl komplett versemmelt.«

So etwas habe ich nie gesagt. Ich wende mich zu John, um ihm zu sagen, dass ich keine Ahnung habe, worüber Erik gerade redet, aber John bemerkt mich gar nicht. Er starrt Erik voller Hass an.

Erik fährt an mich gewandt fort: »Dieser Kerl ist wie der QA-Manager, der seine Gruppe Millionen neuer Tests für ein Produkt schreiben lässt, das wir gar nicht mehr ausliefern, um dann Millionen von Fehlermeldungen für Features zu erzeugen, die gar nicht mehr existieren. Offensichtlich tut er etwas, das Sie und ich als ›Scoping Error‹ bezeichnen würden.«

John zittert vor Empörung. Er sagt: »Wie können Sie nur! Ich kann nicht glauben, dass Sie uns als potenzielles Aufsichtsratsmitglied anweisen, unsere Kundendaten und Bilanzen einem Risiko auszusetzen!«

Erik schaut John ruhig an. »Sie raffen es nicht, oder? Das größte Risiko von Parts Unlimited ist, in Konkurs zu gehen. Und Sie scheinen wild entschlossen, es noch schneller dorthin zu treiben mit all Ihrem unausgereiften, irrelevanten technischen Klein-Klein. Kein Wunder, dass Sie keiner ernst nimmt! Alle anderen versuchen wenigstens, dabei zu helfen, dass die Firma überlebt. Wenn wir hier bei Expedition Robinson wären, hätte man Sie schon längst rausgewählt!«

Mittlerweile steht Erik über John. »Jimmy, Parts Unlimited hat mindestens vier Kreditkartennummern meiner Familie in ihrem System. Ich brauche Sie dafür, diese Daten zu schützen. Aber Sie werden sie nie adäquat schützen können, wenn die Anwendung schon produktiv ist. Sie müssen die Daten bereits in den Prozessen schützen, die zu der Anwendung führen.«

Er steckt die Hände in die Taschen und sagt etwas sanfter: »Sie wollen einen Tipp? Gehen Sie ins Gebäude MRP-8 und suchen Sie dort die Sicherheitsverantwortliche. Reden Sie mit ihr und finden Sie heraus, was sie dort zu erreichen versucht und wie sie das tut.«

Eriks Gesichtsausdruck wird freundlicher, er fügt hinzu: »Und bitte grüßen Sie sie von mir. Ich werde wieder mit Ihnen reden, wenn Dick sagt, dass er Sie tatsächlich braucht.«

Damit verlässt er den Raum.

John sieht mich an. »Was zur Hölle ...?«

Ich stehe auf und sage: »Nehmen Sie es nicht persönlich. Mir hat er ähnliche Dinge gesagt. Ich bin müde und gehe nach Hause. Vielleicht ist es das Beste, wenn Sie das auch tun.«

John steht wortlos auf. Mit ruhigem Gesichtsausdruck pfeffert er seinen Ordner vom Tisch. Als dieser auf den Boden knallt, verteilt sich der Inhalt über den ganzen Raum. Hunderte Seite fliegen herum.

Er sieht mich mit einem freudlosen Lächeln an und sagt: »Das werde ich. Nach Hause gehen. Ich weiß nicht, ob ich Montag wieder da bin – oder ob ich überhaupt noch komme. Wozu sollte ich?« Dann verlässt auch er den Raum.

Ich starre Johns Ordner an und kann nicht ganz glauben, dass er ihn so nachlässig behandelt hat. John hat ihn seit zwei Jahren überall mit hingenommen. Dort, wo er gesessen hat, liegt ein kleines Blatt. Fast leer, nur mit ein paar Zeilen darauf. Ich frage mich, ob das ein Abschiedsbrief oder eine Kündigung ist, daher werfe ich einen Blick darauf und finde ein Gedicht vor.

Ein Haiku?

Hier sitze ich gefesselt

Raum ist wütend, ich könnte sie retten

Wenn sie nur wüssten

KAPITEL 22

Montag, 29. September

Am folgenden Montag ist John verschwunden. Im NOC laufen Wetten, ob er einen Nervenzusammenbruch hatte, gefeuert wurde, sich einfach nur versteckt oder ob etwas Schlimmeres passiert ist.

Wes und ein paar seiner Techniker lachen laut – vermutlich auf Johns Kosten.

Ich räuspere mich, um Wes’ Aufmerksamkeit zu erlangen. Als er zu mir kommt, drehe ich mich vom NOC weg, sodass keiner hört, was ich ihm sagen will. »Tust du mir einen Gefallen? Heiz bitte nicht noch die Gerüchteküche rund um John an. Denk daran, was Steve uns bei dem Offsite-Meeting sagen wollte. Wir müssen gegenseitig Respekt zeigen und uns vertrauen.«

Wes’ Lächeln verschwindet, und nach einem Moment sagt er: »Ja, ich weiß. Ich mache doch nur Spaß, okay?«

»Gut«, sage ich und nicke. »Aber zu etwas anderem. Komm mal mit. Ich muss mit dir und Patty über das Monitoring-Projekt reden.« Wir gehen zu ihrem Büro, wo sie an ihrem Schreibtisch sitzt und an einer Projektmanagement-Software voll mit Gantt-Charts arbeitet.

»Hast du eine halbe Stunde für uns?«, frage ich sie.

Als sie nickt, setzen wir uns an ihren Besprechungstisch. Ich sage: »Ich habe am Freitag vor dem Audit-Meeting mit Erik gesprochen. Und das habe ich dabei gelernt ...«

Ich erzähle den beiden von Eriks Überlegungen zum Monitoring-Projekt und wie wichtig es ist, um Brent besser einsetzen zu können. Dann versuche ich, die Gedankengänge zu erklären, die wir durchgehen sollten, um herauszufinden, welche Projekte wir sicher wieder angehen können – und zwar basierend darauf, ob sie von Brent abhängig sind oder nicht.

»Warte mal. Stücklisten und Arbeitsstationen?«, fragt Wes und sieht dabei sehr kritisch aus. »Bill, ich muss dich doch nicht daran erinnern, dass wir hier keine Fabrik leiten. Das ist IT-Arbeit. Wir nutzen unsere Köpfe, um Dinge zu erledigen, nicht unsere Hände. Ich weiß, dass Erik durchaus hier und da kluge Sachen sagt, aber mal ehrlich ... Das klingt wie irgendwelches Blabla von Beratern.«

»Sieh mal, ich habe auch noch Probleme damit, das ganz zu verstehen«, sage ich. »Aber kannst du wirklich sagen, dass die Folgerungen aus diesen Überlegungen falsch sind? Glaubst du, es ist nicht sicher, das Monitoring-Projekt zu starten?«

Patty runzelt die Stirn. »Wir wissen, dass IT-Arbeit aus Projekten oder Änderungen bestehen kann. Und in vielen der Projekte gibt es viele Aufgaben und Unterprojekte, die wieder und wieder vorkommen. Wie das Einrichten eines Servers. Wiederkehrende Arbeit. Ich vermute, man könnte das als Baugruppe bezeichnen.«

Sie steht auf, geht zum Whiteboard und zeichnet ein paar Kästchen. »Nehmen wir das Beispiel eines zu konfigurierenden Servers. Dazu gehört das Besorgen, das Installieren des Betriebssystems und der Anwendungen gemäß irgendwelchen Spezifikationen und schließlich das Einbauen in ein Rack und das Anschließen. Dann prüfen wir, ob der Server wie gewünscht funktioniert. Jeder dieser Schritte wird normalerweise von anderen Leuten durchgeführt. Vielleicht ist jeder Schritt wie eine Arbeitsstation mit eigenen Maschinen, Methoden, Menschen und Messungen.«

Etwas unsicherer fährt sie fort: »Aber ich bin nicht sicher, was die Maschine wäre.«

Ich lächle über Pattys Zeichnungen. Sie denkt weiter, als ich es konnte. Ich weiß nicht, wo sie landen wird, aber ich glaube, sie ist auf dem richtigen Weg.

»Vielleicht ist die Maschine«, spekuliere ich, »die Sammlung an Tools, die notwendig sind, um die Arbeit zu erledigen? Die Virtualization Management Consoles, die Terminal Sessions und eventuell der Virtual Disk Space, mit dem wir den Server verbinden?«

Patty schüttelt den Kopf. »Vielleicht. Die Konsolen und Terminals könnten wirklich die Maschine sein. Aber ich denke, der Disk Space, die Anwendungen, Lizenzschlüssel und so weiter sind eigentlich die Rohmaterialien oder Eingangswerte, die nötig sind, um das fertige Produkt zu erzeugen.«

Sie starrt auf das Whiteboard. Schließlich sagt sie: »Ich vermute, dass wir so lange nur im Nebel herumstochern, bis wir das ein paar Mal gemacht haben. Vielleicht passt diese ganze Arbeitsstationssache doch ganz gut als Beschreibung für IT-Arbeit. Bei dem Beispiel mit dem Server-Setup wissen wir, dass dies eine Arbeitsstation ist, die für so gut wie jedes Business- und IT-Projekt wichtig ist. Wenn wir das ordentlich machen, können wir sogar bessere Abschätzungen an Kirsten und all ihre Projektmanager liefern.«

»Moment mal, Leute«, sagt Wes. »Unsere Arbeit ist doch nicht repetitiv. Und hier wird sehr viel Wissen gebraucht – anders als bei den Leuten, die nur Teile zusammensetzen oder Schrauben anziehen. Wir stellen sehr kluge Menschen mit Erfahrung ein. Vertraut mir. Wir können unsere Arbeit nicht wie in einer Fabrik standardisieren.«

Ich überlege, was Wes gesagt hat. »Letzte Woche hätte ich dir noch zugestimmt, Wes. Aber dann habe ich eine der komplexeren Arbeitsstationen 15 Minuten lang beobachtet. Ich war beeindruckt, was da alles passiert. Ehrlich gesagt, würde ich mir das nicht zutrauen. Obwohl sie versuchen, alles repetitiv und wiederholbar zu machen, müssen sie viel improvisieren und Probleme lösen, um die täglichen Produktionsziele zu erreichen. Sie machen viel mehr, als nur Schrauben anzuziehen. Dort werden auch jeden Tag Heldentaten vollbracht, bei denen alle Erfahrung und Pfiffigkeit notwendig sind.«

Ich sage ernsthaft: »Die Leute dort verdienen all meinen Respekt. Wenn es sie nicht gäbe, hätten wir alle gar keinen Job. Ich glaube, wir können vom Verwalten eines Fertigungsbereichs noch viel lernen.«

Nach einer Pause sage ich: »Lasst uns mit dem Monitoring-Projekt so schnell wie möglich beginnen. Je früher wir damit anfangen, desto schneller können wir davon profitieren. Wir müssen jede unserer Ressourcen so schützen, als wäre sie ein Brent, also sollten wir loslegen.«

»Da ist noch etwas«, sagt Patty. »Ich denke immer noch über die Fertigungsstrecken nach, die wir nutzen wollen. Ich würde gerne ein paar dieser Konzepte mit den eintreffenden Service Requests ausprobieren, zum Beispiel Accounts erzeugen/ändern/löschen, Passwörter zurücksetzen und – na ja – das Ersetzen von Laptops.«

Sie sieht meinen riesigen Laptop unbehaglich an, der sich in einem noch schlechteren Zustand befindet als vor drei Wochen. Ich musste noch mehr Klebeband einsetzen, weil ich meine Autoschlüssel missbraucht hatte, um ihn aufzubekommen. Und mittlerweile ist von der Klappe auch schon die Hälfte der Farbschicht ab.

»Oh Mann», grummelt Wes, als er sich den Rechner peinlich berührt anschaut. »Ich kann nicht glauben, dass du immer noch keinen Ersatz hast. So schlecht sind wir auch nicht besetzt, Patty. Ich werde jemanden finden, der sich um das Laptop- und Desktop-Backlog kümmert.«

»Super«, antwortet Patty. »Ich habe da ein kleines Experiment im Kopf, das ich gerne ausprobieren möchte.«

Ich will da nicht im Weg sein, also zitiere ich nur: » Make it so.«

Als ich am folgenden Montag ins Büro komme, wartet Patty schon auf mich. »Hast du eine Sekunde?«, fragt sie und will mir offensichtlich unbedingt etwas zeigen.

Kurz darauf stehen wir in Pattys Change Coordination Room. An der Rückwand sehe ich sofort ein neues Board. Darauf sind Karteikarten in vier Reihen angeordnet.

Die Reihen sind beschriftet mit: »Arbeitsplatz umziehen«, »Account anlegen/ändern/löschen«, »Neuer Desktop-/Laptoprechner« und »Passwort zurücksetzen«.

Jede Reihe ist nochmals in drei Spalten unterteilt, die mit »To Do«, »Doing« und »Done« beschriftet sind.

Interessant. Das sieht vage vertraut aus. »Was ist das? Ein weiteres Change-Board?«

Patty muss grinsen und sagt: »Das ist ein Kanban-Board. Nach unserem letzten Meeting habe ich mir MRP-8 selbst angeschaut. Das mit den Arbeitsstationen ist mir nicht mehr aus dem Kopf gegangen, und ich wollte sie live und in Farbe sehen. Ich habe mir dort einen der Vorarbeiter geschnappt, und er hat mir tatsächlich eine ganze Stunde lang gezeigt, wie sie den Arbeitsfluss dort organisieren.«

Patty erklärt, dass ein Kanban-Board – neben vielem anderen – eines der wichtigsten Werkzeuge ist, um auf unseren Fertigungsstrecken Arbeit zu planen und durch das System zu steuern. Anforderungen und WIPs werden dadurch sichtbar, und man kann erkennen, welche Stationen als Nächstes dran sind.

»Ich habe damit experimentiert, Kanbans um unsere Schlüsselressourcen zu legen. Jede Aktivität, an der sie arbeiten, muss durch das Kanban gehen. Nicht per E-Mail, Instant Message, Telefon oder sonst etwas.

Wenn etwas nicht auf dem Kanban-Board steht, wird es nicht erledigt«, sagt sie. »Wichtiger ist aber: Wenn es sich auf dem Kanban-Board befindet, wird es schnell erledigt. Du wärst erstaunt, wie schnell Arbeit erledigt wird, weil wir die Work in Process einschränken. Nach den bisherigen Ergebnissen würde ich sagen, dass wir die Bearbeitungszeiten vorhersagen können und einen schnelleren Durchsatz als je zuvor erhalten werden.«

Diese Patty klingt ein wenig wie Erik. Das ist gleichzeitig verstörend und aufregend.

»Ich habe also«, fährt sie fort, »einige unserer am meisten genutzten Service Requests genommen, die Schritte und Ressourcen dafür genau dokumentiert und berechnet, wie lange jeder Vorgang dauert. Das ist das Ergebnis.«

Stolz übergibt sie mir ein Blatt.

Darauf steht: »Ersatzlaptop-Queue«. Darunter befindet sich eine Liste mit jedem, der entweder einen neuen oder einen Ersatzlaptop oder einen Desktop-computer angefordert hat. Dazu die Information, wann die Anforderung kam und wann sie vermutlich erledigt sein wird. Das Ganze ist so sortiert, dass die älteste Anforderung oben steht.

Ich bin anscheinend Nummer 14, und mein Laptop soll in vier Tagen bereit sein.

»Und du glaubst wirklich an den Zeitplan?«, frage ich skeptisch. Es wäre auf jeden Fall toll, wenn wir diese Information an jeden herausgeben und die Termine auch noch halten könnten.

»Wir haben das ganze Wochenende dran gearbeitet«, antwortet Patty. »Wir haben Probeläufe gemacht und sind ziemlich sicher, dass wir die notwendigen Zeiten richtig abgeschätzt haben. Wir haben uns sogar überlegt, wie wir uns einen Haufen Schritte ersparen können, wenn wir Disk Images einsetzen. Unter uns – ich würde behaupten, dass wir die dort angegebenen Zeitangaben noch unterbieten können.«

Sie wiegt nachdenklich ihren Kopf hin und her. »Ich habe mich bei den Leuten umgehört, die von uns Laptops bekommen haben. Es dauert normalerweise 15 Runden, bis endlich alles korrekt konfiguriert ist. Ich habe da jetzt ein Auge drauf und versuche, das auf drei zu reduzieren. Wir setzen überall Checklisten ein, insbesondere wenn wir innerhalb des Teams etwas weitergeben. Das macht viel aus. Die Fehlerraten sind deutlich kleiner geworden.«

Ich lächle und sage: »Das ist wichtig. Managern und Mitarbeitern die Werkzeuge zu geben, die sie brauchen, um ihre Aufgaben zu erledigen, ist eine unserer Hauptaufgaben. Ich sage nicht, dass ich dir nicht glaube, aber lass uns diese geschätzten Zeiten erst einmal für uns behalten. Wenn die Daten eine Woche lang zeigen, dass sie stimmen, können wir sie an die Anforderer und deren Manager weitergeben, okay?«

Patty lächelt erneut. »Genau das habe ich auch gedacht. Stell dir vor, wie sich das auf die Benutzerzufriedenheit auswirkt, wenn wir ihnen sagen können, wie lang die Warteschlange ist und wann sie ihr Ergebnis erhalten, und das dann auch tatsächlich erfüllen, weil unsere Techniker nicht unterbrochen werden oder tausend Sachen gleichzeitig machen müssen!

Mein Vorarbeiterkumpel hat mir auch noch von dem Verbesserungs-Kata erzählt, das sie einsetzen. Ob du es glaubst oder nicht – Erik hat ihnen vor vielen Jahren dabei geholfen, das dort einzuführen. Sie haben fortlaufende, zweiwöchige Verbesserungszyklen, in denen jeweils ein kleines Plan-Do-Check-Act-Projekt umgesetzt wird, um ihr Ziel zu erreichen. Ich hoffe, es stört dich nicht, dass ich mir die Freiheit genommen habe, diese Praxis in unserer Gruppe zu übernehmen, damit wir uns unseren eigenen Zielen nähern können?«

Erik hat dieses Kata und die Zweiwochenzyklen schon erwähnt. Wieder einmal ist mir Patty einen Schritt voraus. »Das ist tolle Arbeit, Patty. Wirklich, sehr gut gemacht.«

»Danke sehr«, antwortet sie bescheiden, aber sie grinst von einem Ohr zum anderen. »Ich bin begeistert davon, was ich gerade lerne. Ich sehe so zum ersten Mal, wie wir unsere Arbeit organisieren sollten, und selbst für diese einfacheren Service-Desk-Aufgaben weiß ich, dass es einen großen Unterschied machen wird.«

Sie zeigt auf das Change-Board an der Wand. »Wirklich interessant wird es, wenn wir diese Techniken auf komplexere Aufgaben anwenden. Haben wir erst einmal herausgefunden, welche regelmäßigen Aufgaben wir am häufigsten erledigen, müssen wir Arbeitsstationen und Ablaufpläne erstellen, so wie ich das für meine Service Requests gemacht habe. Vielleicht können wir dann auch einen Teil dieser Planungsboards loswerden und auf Kanban-Boards umsteigen. Unsere Techniker könnten sich dann eine Karte aus der ›To Do‹-Spalte nehmen, sie nach ›Doing‹ verschieben und dann irgendwann auf ›Done‹ setzen!«

Das kann ich mir leider noch nicht richtig vorstellen. »Mach weiter. Achte nur darauf, Wes mit einzubeziehen, okay?«

»Schon geschehen«, antwortet sie schnell. »Tatsächlich treffe ich mich nachher noch mit ihm, um zu diskutieren, ob wir Brent mit einem Kanban-Board versehen, um ihn stärker von den täglichen Katastrophen abzuschotten. Ich möchte weiter formalisieren, wie Brent Aufgaben erhält, und das, woran er arbeitet, besser standardisieren. So können wir sicherer herausfinden, woher die ganze Arbeit für Brent kommt – sowohl von oben als auch von unten. Und natürlich haben wir dadurch einen besseren Schutz vor Leuten, die einfach nur bei Brent reinschneien.«

Ich gebe ihr ein »Daumen hoch« und will gerade gehen. »Moment, das Change-Board sieht anders aus. Warum haben die Karten unterschiedliche Farben?«

Sie wirft einen Blick auf das Board und sagt: »Oh, habe ich dir das noch nicht erzählt? Wir nutzen die Farben, um besser darauf vorbereitet zu sein, wenn der Projekt-Freeze aufgehoben wird. Irgendwie müssen wir sicherstellen können, dass wir an den wichtigsten Dingen arbeiten. Die lilafarbenen Karten sind die Änderungen, die für eines der fünf wichtigsten Businessprojekte nötig sind, während die anderen gelbe Karten erhalten. Die grünen Karten stehen für interne IT-Verbesserungsprojekte. Dabei probieren wir aus, 20 Prozent unserer Zyklen nur dafür zu reservieren, so wie Erik es vorgeschlagen hat. So können wir die richtige Balance zwischen lilafarbenen und grünen Karten sicherstellen.«

Sie fährt fort: »Die pinkfarbenen Aufkleber markieren die Karten, die irgendwie geblockt werden. Das schauen wir uns zwei Mal pro Tag an. Wir tragen die Karten zudem in unser Change-Tracking-Tool ein und übernehmen die Change-IDs von dort wiederum auf die Karten. Das ist ein bisschen mühsam, aber so ist zumindest ein Teil des Trackings automatisiert.«

»Wow, das ist ... unglaublich«, sage ich ehrfürchtig.

Am Nachmittag sitze ich mit Wes und Patty an einem anderen Besprechungstisch, um herauszufinden, wie wir den Projektfluss wieder langsam erhöhen können, ohne dabei gleich zu ertrinken.

»Wie Erik gesagt hat: Wir haben eigentlich zwei Projekt-Queues, die wir kombinieren müssen – Business- und interne Projekte«, sagt Patty und zeigt auf die beiden kleineren Papierstapel vor uns. »Lasst uns die Businessprojekte zuerst durchgehen, weil es da einfacher ist. Wir haben die fünf wichtigsten Projekte schon mithilfe der Projektsponsoren herausgefunden. Vier davon brauchen Brents Unterstützung. Ich schlage vor, nur diese fünf Projekte freizugeben, wenn der Freeze aufgehoben wird.«

»Das war einfach«, lacht Wes.«Ich kann nicht glauben, wie viel Diskussion, Wichtigtuen, Kuhhandel und Hinterhältigkeit da passiert ist, bis diese fünf Projekte feststanden. Das war schlimmer als in der Chicagoer Politik!«

Er hat recht. Aber immerhin haben wir jetzt diese Liste.

»Jetzt zum schwierigeren Teil. Wir sind uns immer noch nicht sicher, wie wir unsere eigenen 73 internen Projekte priorisieren wollen«, sagt sie verdrießlich. »Es sind weiterhin viel zu viele. Wir haben Tage mit allen Teamleitern verbracht und versucht, irgendeine Form von Wichtigkeitsstufen festzulegen. Aber außer zu diskutieren haben wir nicht viel geschafft.«

Sie blättert zur zweiten Seite. »Die Projekte scheinen in diese Kategorien zu fallen: Ersetzen instabiler Infrastruktur, Hersteller-Upgrades und das Unterstützen irgendwelcher interner Businessanforderungen. Der Rest ist Krimskrams mit Audit- und Sicherheitskram, Data-Center-Upgrades und so weiter.«

Ich schaue mir die zweite Seite an und kratze mich am Kopf. Patty hat recht. Wie entscheidet man objektiv, ob »Konsolidieren und Upgraden der E-Mail-Server« mehr oder weniger wichtig ist als »35 Instanzen von SQL-Datenbanken upgraden«?

Ich lasse meinen Finger über die Seite gleiten und schaue, ob mir etwas ins Auge springt. Es ist dieselbe Liste, die ich schon in meiner ersten Woche als VP gesehen habe, und immer noch sieht alles gleich wichtig aus.

Wes und Patty haben schon fast eine ganze Woche damit verbracht, also versuche ich, anders heranzugehen. Es muss einen einfacheren Weg geben, diese Liste zu priorisieren, ohne irgendwelche Kästchen hin- und herzuschieben.

Plötzlich erinnere ich mich daran, wie Erik auf die Wichtigkeit präventiver Arbeit eingegangen ist – wie zum Beispiel des Monitoring-Projekts. Ich sage: »Es ist mir egal, wie wichtig jeder sein eigenes Projekt sieht. Wir müssen wissen, ob es die Kapazität unseres Engpasses erhöht, der immer noch Brent ist. Wenn das Projekt nicht seine Arbeitslast reduziert oder es jemand anderem ermöglicht, ihm Arbeit abzunehmen, sollten wir es vielleicht nicht starten.

Wenn ein Projekt andererseits Brent gar nicht braucht, gibt es keinen Grund, es nicht zu beginnen.«

Ich sage nachdrücklich: »Gebt mir drei Listen mit Projekten. Eine, bei denen Brent mitmachen muss, eine, die Brents Durchsatz erhöht, und die letzte mit allem anderen. Sucht bei jeder Liste die wichtigsten Projekte zusammen. Wendet dafür nicht zu viel Zeit auf – ich will nicht wieder tagelang diskutieren. Die wichtigste Liste ist die zweite. Wir müssen Brents Kapazität verbessern, indem wir die ungeplante Arbeit verringern, die ihn immer wieder trifft.«

»Das klingt vertraut«, sagt Patty. Sie stöbert in der Liste mit fragilen Services, die wir für den Change-Management-Prozess erstellt haben. »Wir sollten sicherstellen, dass wir ein Projekt zum Ersetzen oder Stabilisieren jedes dieser Services haben. Und vielleicht sollten wir alle Infrastrukturprojekte dauerhaft auf Eis legen, wenn der entsprechende Service stabil läuft.«

»Jetzt wartet mal eine Minute«, sagt Wes. »Bill, du hast selbst gesagt, dass präventive Arbeit wichtig ist, aber immer verschoben wird. Einige Projekte versuchen wir schon seit Jahren umzusetzen! Das ist unsere Chance, da aufzuholen.«

Patty sagt schnell: »Hast du nicht gehört, was Bill von Erik erfahren hat? Jede Verbesserung, die nicht am Flaschenhals vorgenommen wird, ist überflüssig. Ich will dir nicht zu nahetreten, aber du hörst dich gerade wie John an.«

Ich kann es nicht ändern, aber ich muss lachen.

Wes wird einen Moment rot, dann lacht er selbst laut. »Autsch. Okay, gewonnen. Aber ich versuche doch nur, das Richtige zu tun.«

»Nein!«, unterbricht er sich selbst. »Schon wieder!«

Wir lachen alle. Ich frage mich, wie es John geht. Meines Wissens hat ihn noch keiner gesehen.

Während sich Wes und Patty Notizen machen, überfliege ich noch mal die Liste der internen Projekte. »Hey, warum ist da ein Projekt für das Upgraden der BART-Datenbank, wenn die doch sowieso nächstes Jahr stillgelegt wird?«

Patty schaut auf ihre Liste und sagt dann verschämt: »Oh jesses. Das habe ich nicht gesehen, weil wir die beiden Listen nie miteinander abgeglichen haben. Also müssen wir noch mal über die Listen gehen und solche Abhängigkeiten finden. Davon gibt es bestimmt noch mehr.«

Patty denkt einen Moment nach. »Seltsam. Obwohl wir so viele Daten zu Projekten, Änderungen und Tickets besitzen, haben wir sie nie auf diese Art und Weise zusammengebracht.

Ich glaube, es gibt noch etwas, das wir aus der Fertigung lernen können«, fährt sie fort. »Wir machen das, was die Fertigungskontrolle tut. Dort wird die Produktion geplant und kontrolliert, sodass alle Kundenanforderungen erfüllt werden können. Wenn sie einen Auftrag annehmen, bestätigen sie, dass es genug Kapazität gibt und die notwendigen Vorprodukte an jeder Arbeitsstation zur Verfügung stehen. Wenn nötig, beschleunigen sie andere Arbeiten. Sie arbeiten mit den Vertriebsleitern und den Betriebsleitern zusammen, um einen Produktionsplan aufzustellen, der alle Anforderungen erfüllt.«

Wieder ist mir Patty voraus. Damit wird eine der ersten Fragen beantwortet, die mir Erik gestellt hatte, bevor ich kündigte. Ich notiere mir, dass wir uns MRP-8 anschauen müssen, um deren Fertigungskontrolle kennenzulernen.

Ich habe den heimlichen Verdacht, dass »Verwalten des IT Operations-Fertigungsplans« irgendwo in meiner Jobbeschreibung stehen sollte.

Zwei Tage später bin ich überrascht, in meinem Büro einen neuen Laptop vorzufinden. Mein alter wurde abgestöpselt und beiseite gestellt.

Ich schaue auf meinen Notizblock und blättere zu dem Laptop-/Desktop-Austauschplan zurück, den mir Patty Anfang der Woche gegeben hatte.

Wow!

Patty hatte mir den Laptop für Freitag zugesagt, jetzt habe ich ihn sogar zwei Tage früher bekommen.

Ich melde mich an, um sicherzugehen, dass alles ordentlich eingerichtet ist. Alle Anwendungen scheinen da zu sein, alle Daten wurden übertragen, die E-Mails funktionieren, die Netzlaufwerke sind vorhanden, und ich kann neue Anwendungen installieren.

Mir kommen vor Dankbarkeit fast die Tränen, als ich feststelle, wie schnell mein neuer Laptop ist. Ich werfe einen Blick auf Pattys Terminplan und gehe direkt zu ihr. »Ich liebe meinen neuen Laptop. Sogar zwei Tage vor Plan. Und alle anderen vor mir haben auch ihre Rechner bekommen?«

Patty grinst. »Jepp. Jeder einzelne. Ein paar der ersten, die wir ausgeliefert haben, hatten noch Konfigurationsprobleme, oder es fehlte etwas. Wir haben die Arbeitsanweisungen angepasst und scheinen in den letzten beiden Tagen einhundert Prozent der Systeme sauber ausgeliefert zu haben.«

»Tolle Arbeit, Patty!«, sage ich begeistert. »Dann mach den Zeitplan jetzt öffentlich. Ich will ein bisschen angeben!«

KAPITEL 23

Dienstag, 7. Oktober

Während ich am folgenden Dienstagmorgen zur Arbeit fahre, erhalte ich einen dringenden Anruf von Kirsten. Anscheinend hängt Brent jetzt fast eine ganze Woche mit der Auslieferung eines weiteren Phoenix-Tasks hinterher – angeblich etwas, das laut Brent nur eine Stunde dauern sollte. Erneut steht der gesamte Testplan für Phoenix auf der Kippe.

Hinzu kommt, dass sich eine Reihe weiterer wichtiger Arbeiten meiner Gruppe verzögert und die Deadline damit noch mehr unter Druck gerät. Das ist ausgesprochen entmutigend. Ich hatte gedacht, dass all die Durchbrüche, die wir in letzter Zeit erzielt haben, diese Lieferprobleme lösen würden.

Wie können wir weitere Projekte in Gang setzen, wenn wir schon jetzt nicht alles schaffen?

Ich hinterlasse Patty eine Nachricht auf der Mailbox. Zu meiner Überraschung braucht sie drei Stunden, um mich zurückzurufen. Irgendetwas geht mit ihren Zeiteinschätzungen total schief, und wir müssen uns sofort treffen.

Abermals finde ich mich in einem Besprechungsraum wieder – mit Patty am Whiteboard und Wes, der in den von ihr mitgebrachten Ausdrucken stöbert.

»So viel weiß ich bisher«, sagt Patty und zeigt auf einen Papierstapel. »Bei der Aufgabe, von der Kirsten spricht, geht es um das Bereitstellen einer Testumgebung für QA. Wie sie sagte, hat Brent geschätzt, dass das nur 45 Minuten dauern sollte.«

»Das klingt realistisch«, sagt Wes. »Man muss nur einen neuen virtualisierten Server erzeugen und dann das Betriebssystem und ein paar Pakete installieren. Vermutlich hat er sogar seinen echten Zeitbedarf verdoppelt, um auf der sicheren Seite zu sein.«

»Das habe ich auch gedacht«, sagt Patty, aber sie schüttelt dabei ihren Kopf. »Nur ist das nicht nur ein Task. Was Brent da vorhatte, ist eher ein kleines Projekt – es sind über 20 Schritte in mindestens sechs verschiedenen Teams! Du brauchst das Betriebssystem und all die Softwarepakete, Lizenzschlüssel, dedizierte IP-Adressen, Benutzeraccounts für spezielle Anwender, konfigurierte Mountpoints, und dann muss die IP-Adresse in einer ACL-Liste auf irgendeinem Dateiserver eingetragen werden. In diesem Fall sagen die Anforderungen zudem noch, dass wir einen echten Server brauchen, also kommen noch ein Routerport, die Verkabelung und ein Server-Rack, in dem Platz ist, dazu.«

»Oh ...«, sagt Wes verärgert und liest sich durch, worauf Patty gezeigt hat. Er murmelt: »Echte Server sind immer so nervig.«

»Darum geht es nicht. Das würde auch fast alles nötig sein, wenn der Server virtualisiert wäre«, sagt Patty. »Erstens ist Brents ›Task‹ deutlich mehr als nur ein Task. Und zweitens stellen wir fest, dass es mehrere Tasks sind, die von mehreren Leuten zu bearbeiten sind, von denen jeder seine eigenen dringenden Aufgaben zu erledigen hat. Wir verlieren bei jeder Übergabe Tage. Bei dieser Rate wird es Wochen dauern, bis QA das bekommt, was sie brauchen, wenn wir nicht ernsthaft etwas ändern.«

»Wenigstens brauchen wir keine Änderung an der Firewall«, sagt Wes höhnisch. »Letztes Mal brauchte Johns Truppe dafür fast einen Monat. Vier Wochen für eine Änderung von 30 Sekunden!«

Ich nicke und weiß genau, worauf Wes sich da bezieht. Die Bearbeitungszeiten für Firewall-Änderungen sind legendär. Moment Mal. Hat Erik nicht so etwas erwähnt? Wenn eine Firewall-Änderung eigentlich nur 30 Sekunden benötigt, man aber trotzdem vier Wochen darauf wartet?

Das ist im Kleinen das, was mit Brent passiert. Aber was uns gerade passiert, ist viel, viel schlimmer, weil es die Übergaben gibt.

Grummelnd lasse ich meinen Kopf auf die Tischplatte sinken.

»Alles okay?«, fragt Patty.

»Eine Sekunde«, sage ich. Ich gehe zum Whiteboard und versuche vergeblich, mit einem der Marker ein Diagramm zu zeichnen. Nach ein paar Versuchen sieht es dann so aus:

Ich erzähle den beiden, was Erik mir im MRP-8 erzählt hat – inwieweit die Wartezeit davon abhängt, wie belegt eine Ressource ist. »Die Wartezeit ist der Prozentwert, den die Ressource belegt ist, geteilt durch den Prozentwert, den die Ressource nichts zu tun hat. Mit anderen Worten: Wenn eine Ressource zu 50 Prozent beschäftigt ist, ist sie auch 50 Prozent der Zeit nicht beschäftigt. Die Wartezeit ist dann 50 Prozent geteilt durch 50 Prozent, also eine Zeiteinheit. Nehmen wir eine Stunde an. Im Durchschnitt wartet unser Task also eine Stunde in der Queue, bevor er bearbeitet wird.

Wenn eine Ressource andererseits zu 90 Prozent beschäftigt ist, beträgt die Wartezeit 90 Prozent geteilt durch 10 Prozent – oder 9 Stunden. Unser Task würde also neunmal länger in einer Warteschlange herumhängen, als wenn die Ressource zu 50 Prozent ausgelastet ist.«

Meine Schlussfolgerung: »Gehen wir beim Phoenix-Task davon aus, dass wir 7 Übergaben haben und dass jede dieser Ressourcen zu 90 Prozent ausgelastet ist, würde der Task insgesamt 9 Stunden mal 7 Schritte in Warteschlangen hängen ...«

»Was? 63 Stunden reine Wartezeit?«, sagt Wes ungläubig. »Das ist unmöglich!«

Patty sagt süffisant lächelnd: »Oh, natürlich. Weil es doch nur 30 Sekunden tippen sind, oder?«

»Ach Mist«, sagt Wes und starrt auf das Diagramm.

Plötzlich erinnere ich mich wieder an meine Unterhaltung mit Wes in Kirstens Meeting, bevor Sarah und Chris sich dazu entschieden hatten, Phoenix auszuliefern. Wes hatte sich darüber beschwert, dass Tickets rund um Phoenix wochenlang unterwegs waren, was zu Verzögerungen bei der Auslieferung führte.

Damals passierte es auch schon. Und da gab es nicht nur Übergaben zwischen Leuten aus IT Operations, sondern zwischen der Entwicklungsorganisation und IT Operations – viel komplexer also.

Das Festlegen und Priorisieren von Arbeit innerhalb einer Abteilung ist hart, aber Arbeit über mehreren Abteilungen hinweg zu verwalten, muss mindestens zehn Mal schlimmer sein.

Patty sagt: »Das Diagramm zeigt, dass jeder freie Zeit oder ›Slack Time‹ benötigt. Wenn keiner Slack Time hat, bleibt die WIP im System stecken. Oder genauer gesagt – in den Warteschlangen.«

Während wir diese Information verdauen, fährt Patty fort: »Jeder Zettel hier am Board ist wie dieser Phoenix-›Task‹«, sagt sie, wobei sie mit ihren Händen Anführungszeichen in die Luft malt. »Er sieht aus wie eine Aufgabe für eine einzelne Person, aber das stimmt nicht. Es sind tatsächlich mehrere Schritte mit mehreren Übergaben zwischen verschiedenen Personen. Kein Wunder, dass Kirstens Projektplanung den Bach runtergeht.

Wir müssen das in Kirstens Zeitplan und in ihrer Work Breakdown Structure beziehungsweise WBS anpassen. Angesichts dessen, was ich gesehen habe, fallen ein Drittel unserer Zusagen an Kirsten in diese Kategorie.«

»Ganz toll«, sagt Wes. »Das ist ja wie bei Gilligans Insel. Wir schicken Leute auf eine dreistündige Tour, und Monate später wundern wir uns, warum keiner von ihnen zurückkommt.«

Patty sagt: »Ich frage mich, ob wir eine Kanban-Spalte für jeden dieser ›Tasks‹ erstellen könnten.«

»Ja, das ist es«, sage ich. »Erik hatte recht. Du hast gerade einen großen Haufen immer wiederkehrender Arbeit entdeckt! Wenn wir diese Arbeit dokumentieren und standardisieren und uns darin verbessern – so wie du es mit dem Laptopaustausch gemacht hast –, bin ich sicher, dass wir den Arbeitsfluss beschleunigen!«

Ich ergänze: »Wisst ihr, wenn wir all unsere wiederkehrenden Deployment-Aufgaben standardisieren können, werden wir es endlich schaffen, unsere Produktkonfigurationen zu vereinheitlichen. Das wäre unser Infrastruktur-Schneeflocken-Problem – ihr wisst schon, keine zwei sind gleich. Brent konnte nur deshalb zu Brent werden, weil wir ihm erlaubt haben, Infrastruktur zu bauen, die nur er versteht. Das darf nicht wieder passieren.«

»Gutes Argument«, knurrt Wes. »Das ist schon seltsam. So viele der Probleme, denen wir gegenüberstehen, werden durch Entscheidungen ausgelöst, die wir getroffen haben. Wir haben den Feind gefunden – uns selbst.«

Patty sagt: »Wisst ihr, die Deployments sind wie die Endmontage in einer Fertigungsstraße. Jeder Arbeitsfluss muss dort durch, und man kann das Produkt ohne sie nicht ausliefern. Jetzt weiß ich, wie das Kanban genau aussehen muss.«

In den nächsten 45 Minuten erstellen wir unseren Plan. Patty wird mit Wes’ Team daran arbeiten, die 20 am häufigsten wiederkehrenden Tasks zusammenzutragen.

Und sie wird herausfinden, wie die Tasks besser gesteuert und überwacht werden können, die in einer Warteschlange hängen. Patty schlägt eine neue Rolle vor – eine Kombination aus Projektmanager und Dispatcher. Statt nur Tag für Tag den Status zu prüfen, behält diese Person ihn minütlich im Blick. Sie sagt: »Wir brauchen schnelle und effektive Übergaben von erledigter Arbeit an die nächste Arbeitsstation. Falls nötig, wartet diese Person bei der Arbeitsstation, bis die Arbeit erledigt ist, und sie trägt dann zur nächsten Station. Wir werden kritische Aufgaben nicht wieder in einem Stapel Tickets verschwinden lassen.«

»Was? Jemand soll Tasks von einer Person zur nächsten tragen, wie ein Ober?«, fragt Wes ungläubig.

»In MRP-8 haben sie eine ›Wasserspinnen‹ -Rolle, die genau das tut«, entgegnet sie. »Fast alle Verzögerungen bei Phoenix in der letzten Zeit entstanden durch Tasks, die in Warteschlangen oder bei Übergaben herumlagen. So stellen wir sicher, dass das nicht wieder passiert.

Irgendwann«, fügt sie hinzu, »werde ich all die Kanbans ins Intranet schieben, sodass wir keine Person mehr brauchen, die für Übergaben Kärtchen verschiebt. Keine Sorge, in ein paar Tagen habe ich dafür eine Lösung.«

Wes und ich hegen da keine Zweifel.

KAPITEL 24

Samstag, 11. Oktober

Der folgende Samstag verläuft ziemlich friedlich. Tatsächlich ist es das entspannendste Wochenende, das ich mit meiner Familie genießen kann, seit ich meinen neuen Job habe. Halloween ist nur noch ein paar Wochen entfernt, daher bestand Paige darauf, dass die ganze Familie zu einem Kürbisfeld aufbricht.

Es war ein kühler Morgen, und wir waren schon erschöpft, als wir die Kinder endlich warm eingepackt im Auto verstaut hatten. Als wir an der nahe gelegenen Farm ankamen, konnten Paige und ich uns kaum einkriegen über Parker, der eingepackt in seinen blauen Anorak wie ein riesiges, wütendes Würstchen aussah. Sie konnte es sich nicht nehmen lassen, Fotos davon zu machen, während Grant begeistert um uns herumwuselte und mit seiner eigenen Kamera Bilder machte.

Später gingen wir in eine kleine, lokale Brauerei und genossen auf der Terrasse ein Mittagessen in der warmen Sonne.

»Ich bin so froh, dass wir das machen konnten«, sagt Paige. »Es ist wirklich schön. Du scheinst in letzter Zeit weniger gestresst zu sein. Ich habe wirklich das Gefühl, dass es besser läuft.«

Sie hat recht. Es scheint, als hätten wir bei der Arbeit irgendwie einen Durchbruch geschafft. So, wie ich jetzt nicht mehr so viel Zeit damit verbringe, mit meinem antiken Laptop zu kämpfen, so hat mein Team jetzt mehr und mehr Zeit für produktive Arbeit, statt nur Feuer löschen zu müssen.

Auch wenn mir klar ist, dass ein neuer Laptop nichts mit der Performance unseres Teams zu tun hat, war es, als wäre ich einen superschweren Anker losgeworden, den mir jemand beim Durchschwimmen des Ozeans umgehängt hatte.

Wir sind immer noch damit beschäftigt, den Projekt-Freeze langsam aufzulösen. Ich vermute, dass wir etwa 25 Prozent aller Projekte werden freigeben können, dazu einen Haufen anderer, neuer Projekte, die dazu dienen, Brent besser einsetzen zu können.

Es gibt zwar immer noch ziemlich viele Unsicherheiten, aber anders als zuvor scheinen wir die Herausforderungen verstehen und angehen zu können. Es sieht so aus, als ob unsere Ziele tatsächlich erreichbar wären. Ich habe nicht länger das Gefühl, dass mir dauernd die Leute im Nacken sitzen, mehr und mehr Aufgaben unterjubeln und versuchen, mich ins Straucheln zu bringen.

Die Businessabteilungen – Sarah ausgenommen – sehen die Prioritäten wie ich, und so scheint mein Job tatsächlich ziemlich gut zu laufen. Ich habe das Gefühl, dass wir die Initiative haben und das Problem angehen statt umgekehrt.

Das gefällt mir.

Ich schaue hoch, und Paige und ich lächeln uns an. Dann bekomme ich einen Heidenschreck, weil ich sehe, wie Parker ihr Bierglas umwirft.

Der Rest des Nachmittags vergeht viel zu schnell, aber es ist einer der schönsten Tage, den ich in diesem Jahr hatte.

Später am Abend haben Paige und ich uns auf das Sofa gekuschelt. Wir sehen uns den Clint-Eastwood-Streifen Pale Rider an. Die Kinder schlafen, und es ist das erste Mal seit Monaten, dass wir gemeinsam einen Film schauen.

Ich lache herzhaft über die Hauptfigur, den von Eastwood gespielten »Prediger«, der sich nacheinander die Gang mit den neun teuflischen Deputies vornimmt. Paige sieht mich mit amüsiertem Kopfschütteln an.

»Was ist daran so lustig?«, fragt sie.

Das lässt mich noch mehr lachen. Als ein weiterer Deputy erschossen wird, sage ich: »Schau dir das an! Du weißt, was passieren wird, aber der Marshal steht einfach da – mitten auf der Straße – und sieht sich das Gemetzel an! Wie der Wind durch seinen Mantel fährt! Und er hat nicht einmal den Revolver gezogen! Ich liebe es!«

»Ich werde dich nie verstehen«, sagt Paige und schüttelt wieder lächelnd den Kopf. Gerade da klingelt mein Handy. Ich greife instinktiv danach.

Ach du Scheiße. Es ist John. Seit dem Audit-Meeting vor zwei Wochen hat ihn keiner mehr gesehen, und niemand hat etwas von ihm gehört. Wir sind uns ziemlich sicher, dass er nicht gefeuert wurde, aber mehr ist auch nicht bekannt. Ich wollte schon in den örtlichen Krankenhäusern nachfragen, ob ihm etwas passiert ist und er irgendwo alleine liegt.

So sehr ich mit ihm reden möchte, will ich doch Paige und den Film nicht im Stich lassen. Ich schaue auf die Uhr – noch etwa 15 Minuten bis zum Ende. Die Abschlussschießerei will ich auf keinen Fall verpassen, daher stelle ich das Telefon stumm. Ich werde ihn zurückrufen, wenn der Film vorbei ist.

Ein paar Sekunden später klingelt mein Handy schon wieder, und ich drücke erneut die Mute-Taste.

Und noch mal klingelt es. Das dritte Mal drücke ich die Mute-Taste, schicke aber noch schnell SMS hinterher: Schön, von Ihnen zu hören. Kann gerade nicht. Rufe Sie in 20 min an.

Unglaublich – mein Handy klingelt erneut. Also schalte ich den Klingelton ab und stecke das Telefon unter ein Kissen.

Paige fragt: »Wer ruft denn da an?«

Als ich »John« sage, verdreht sie die Augen, und wir schauen den Rest des Films an.

»Ich kann nicht glauben, dass ich den Film noch nie gesehen habe!«, sage ich und drücke Paige. »Das war eine tolle Idee von dir, Schatz!«

»Es war ein schöner Tag. Sein normales Leben wiederzuhaben, ist richtig erholsam«, sagt sie und drückt mich auch. Dann steht sie lächelnd auf und nimmt die leeren Bierflaschen mit.

Ich stimme zu. Dann nehme ich mein Handy, und mein Herz setzt kurz aus, als ich sehe: »15 Anrufe in Abwesenheit«.

In der Sorge, dass irgendetwas Kritisches passiert ist, schaue ich nach, von wem sie sind. Von John. Alle. Ich rufe ihn direkt zurück.

»Billy, so schön, deine Stimme wieder zu hören – mein Freund, mein guter, alter Freund«, lallt er. Meine Güte. Er ist total betrunken.

»Es tut mir leid, dass ich Sie nicht direkt zurückrufen konnte. Ich war mit Paige essen«, sage ich und fühle mich angesichts dieser kleinen Lüge ein wenig schuldig.

»Kein Problem. Hör mal, ich wollte dich noch ein ... ein letztes Mal sehen, bevor ich ... weg bin«, sagt er.

»Bevor Sie weg sind? Was meinen Sie mit ›weg sein‹? Wohin gehen Sie?« Ich bin alarmiert und frage mich, wie lange er schon Alkohol in sich hineinschüttet. Vielleicht hätte ich früher zurückrufen sollen. Ich stelle ihn mir plötzlich am anderen Ende der Leitung mit einer offenen Packung Schlaftabletten vor, die schon halb leer ist.

Ich höre ihn lachen, vielleicht ein bisschen hysterisch. »Keine Sorge, Billy. Ich werde mich nicht umbringen. Ich habe noch nicht genug getrunken – bisher. Haha! Ich wollte dich nur noch mal sehen, bevor ich heute Nacht in eine andere Stadt gehe. Lass mich dir einen letzten Drink ausgeben.«

»Ähm, kann das nicht bis morgen warten? Es ist schon fast Mitternacht«, sage ich, ein wenig entspannter.

Er erzählt mir, dass er morgen schon lange weg sein wird, und überzeugt mich, ihn im Hammerhead Saloon in der Stadt zu treffen.

Als ich dort parke, sehe ich gleich Johns Kombi, an dem ein U-Haul-Hänger angekuppelt ist. Direkt neben der Fahrertür stapeln sich leere Bierdosen.

Ich finde John an einem Tisch im hinteren Bereich der vollen Bar, und es ist offensichtlich, dass er schon den ganzen Tag hier ist. Seit ich ihn das letzte Mal gesehen habe, scheint er sich weder gewaschen noch die Kleidung gewechselt zu haben. Sein Haar ist fettig, und es steht wild vom Kopf ab – so als ob er gerade aufgewacht wäre. John ist nicht rasiert, und auf seinem Shirt sind Essensreste zu sehen. Seine Schlüssel und die Geldbörse liegen achtlos hingeworfen neben den Salz- und Pfefferstreuern.

John winkt mit ungelenken Bewegungen nach einer Bedienung. Er braucht einen Moment, um seine Worte zu finden, dann sagt er immer noch undeutlich: »Ich hätte gerne zwei doppelte Scotchs für mich und meinen Freund. Und diese leckeren Nachos ... bitte.«

Sie sieht mich fragend an – anscheinend hat sie ihm schon eine ganze Menge serviert. Ich nicke, sage aber leise: »Fangen wir besser mit zwei Tassen Kaffee an. Ich werde mich um ihn kümmern.« Während ich das sage, greife ich mir seine Autoschlüssel.

Sie sieht mich einen Moment skeptisch an, dann aber lächelt sie kurz und geht davon.

»John, Sie sehen scheiße aus«, sage ich offen.

»Danke, Kumpel. Du auch«, antwortet er, bevor er in Gelächter ausbricht.

»Sehr nett. Wo zum Henker haben Sie sich rumgetrieben? Alle haben sich gefragt, wo Sie sind«, sage ich.

»Ich war zu Hause«, sagt er und nimmt sich Popcorn vom Tisch. »Gelesen habe ich und Fernsehen geschaut. Mann, heutzutage gibt es ganz schön viel Scheiße im Fernsehen. Verrückt! Aber dann habe ich mir gedacht, es sei Zeit, die Zelte abzubrechen, also habe ich heute den Tag über gepackt. Ich wollte dir nur eine letzte kleine Frage stellen, bevor ich weg bin.«

»Sie haben das am Telefon erwähnt«, sage ich, während die Bedienung mit zwei Tassen Kaffee und den Nachos zurückkommt. John sieht die Tassen verwirrt an, daher sage ich: »Keine Sorge, unsere Drinks sind schon unterwegs.«

Während ich ihn dazu bringe, einen Schluck Kaffee zu trinken, fragt er: »Sei ehrlich: Stimmt es wirklich, dass ich nie etwas von Wert für Sie getan habe? In all den drei Jahren, die wir zusammengearbeitet haben, war ich niemals hilfreich?«

Ich atme tief durch und versuche zu entscheiden, was ich sage. Ein Freund hat mir mal vor vielen Jahren gesagt: »Die Wahrheit zu sagen, ist ein Akt der Liebe. Sie zu verbergen, ist ein Akt des Hasses. Oder schlimmer noch, der Apathie.«

Damals habe ich darüber gelacht, aber im Lauf der Jahre habe ich erkannt, dass es ein seltenes Glück ist, wenn einem jemand ehrliches Feedback gibt. Ich schaue mir John an. Er sieht zwar schon aus wie ein gebrochener Mann, aber ich frage mich, ob es richtig ist, ihn jetzt in dem Glauben gehen zu lassen, alles wäre in Ordnung gewesen.

Schließlich sage ich: »Hören Sie, John. Sie sind ein guter Kerl, und ich weiß, dass Ihr Herz am rechten Fleck sitzt, aber bis zu dem Zeitpunkt, als Sie uns die PCI-Auditoren während der Phoenix-Katastrophe vom Hals gehalten haben, hätte ich Nein gesagt. Ich weiß, das ist nicht das, was Sie hören wollen, aber ... Ich wollte sichergehen, dass ich Ihnen keinen Mist erzähle.«

John sieht nun noch niedergeschlagener aus als vorher.

»Wo bleibt der verdammte Scotch?«, brüllt er. Er dreht sich wieder zu mir um und sagt: »Ernsthaft? Nach drei gottverdammten Jahren, die wir zusammengearbeitet haben, erzählst du mir, dass ich dir keine Hilfe war, nicht einmal das kleinste bisschen?«

»Na ja, den größten Teil der Zeit war ich ja für die Midrange-Gruppe verantwortlich, mit der Sie nur wenig zu tun hatten«, erkläre ich ruhig. »Wir haben unsere Sicherheitstipps aus dem Netz geholt. Wenn wir miteinander zu tun hatten, haben Sie nur versucht, mir viel Arbeit aufzuhalsen. Sicherheit ist mir wichtig, und wir schauen immer, welchen Risiken unsere Systeme und Daten ausgesetzt sind, aber wir sind auch immer bis zum Anschlag mit dringenden Aufgaben in Beschlag genommen und müssen versuchen, nicht unterzugehen. Und in meiner neuen Rolle muss ich vor allem versuchen, der Firma beim Überleben zu helfen.«

John sagt: »Aber siehst du denn nicht, dass ich genau das auch versuche? Ich will doch nur, dass du und das Business überleben!«

Ich antworte: »Ich weiß. Aber in meiner Welt bin ich dafür verantwortlich, dass all unsere Services laufen und dass neue Services wie Phoenix bereitgestellt werden. Sicherheit muss da manchmal zurückstehen. Glauben Sie mir, mir sind die Risiken schlechter Sicherheitsmaßnahmen durchaus bewusst, und ich weiß, dass meine Karriere zu Ende ist, wenn sich unter meiner Verantwortung ein großes Sicherheitsleck auftut.«

Ich zucke mit den Schultern. »Ich versuche, mit meinem Wissen über die Risiken die bestmöglichen Entscheidungen zu treffen. Ich glaube nur einfach nicht, dass all der Kram, den ich Ihrer Meinung nach tun sollte, dem Business so viel geholfen hätte wie die anderen Dinge, um die ich mich kümmern musste.

Kommen Sie«, fahre ich fort, »macht es Sie wirklich so fertig, dass die Businessleute das SOX-404-Audit auch ohne Sie durchgestanden haben? Stellen Sie deswegen die Wichtigkeit und Gültigkeit Ihrer Empfehlungen infrage?«

John starrt mich nur an.

Wie auf Befehl kommt die Bedienung mit den beiden Scotchs. John nimmt sich seinen und trinkt ihn in einem Zug leer. »Noch eine Runde, bitte.«

Als sie mich ansieht, schüttle ich den Kopf und forme mit meinen Lippen lautlos die Worte: »Die Rechnung, bitte. Und ein Taxi.«

Sie nickt und verschwindet. Ich nippe einmal an meinem Scotch und schaue dann John wieder an. Sein Kopf ist nach hinten gekippt, und er murmelt irgendetwas Unverständliches.

Ich habe Mitleid mit ihm.

Dann nehme ich seine Geldbörse vom Tisch.

»He!«, sagt er.

»Unsere Bedienung hat Feierabend, und ich muss bezahlen, aber leider habe ich mein Geld zu Hause vergessen«, sage ich.

Er lacht mich aus und schaut mich benebelt an. »Kein Problem, Kumpel. Das geht auf mich. Es geht doch immer auf mich, oder?«

»Danke sehr«, sage ich und hole seinen Ausweis hervor. Ich winke der Bedienung und zeige ihr die Adresse.

Dann lege ich Johns Geldbörse zurück, zücke meine eigene und bezahle.

Ich helfe John hoch und verfrachte ihn ins Taxi, wobei ich sicherstelle, dass seine Geldbörse und seine Schlüssel wieder in seiner Tasche sind. Da ich nicht will, dass er sich noch mit dem Fahrer herumschlagen muss, bezahle ich ihn im Voraus.

Nachdem ich beobachtet habe, wie er weggefahren wird, schaue ich seinen Kombi und den Anhänger an, in dem sich nur ein Bruchteil seines Besitzes befinden kann. Ich schüttle den Kopf, steige wieder in mein Auto und frage mich, wann ich ihn das nächste Mal sehen werde.

Am übernächsten Tag rufe ich John ein paar Mal auf seinem Handy an, aber er geht nie ran. Schließlich hinterlasse ich ihm auf der Mailbox die Nachricht, dass ich hoffe, er wäre gut nach Hause gekommen, dass sein Auto noch vor der Bar stünde und dass er mich anrufen solle, wenn er etwas bräuchte.

Die Gerüchteküche brodelt. Es wird behauptet, dass er im Krankenhaus gelandet ist, im Gefängnis, von Aliens entführt wurde oder in der Psychiatrie steckt.

Ich bin nicht sicher, wie die Gerüchte aufgekommen sind, da ich niemandem von unserem mitternächtlichen Treffen erzählt habe – und das auch niemals tun werde.

Ich bin am Montagabend gerade damit fertig, Grant ins Bett zu bringen, als ich eine SMS von John erhalte. Danke für das Nach-Hause-Bringen neulich. Habe nachgedacht. Ich habe Dick erzählt, dass Sie an unserem Meeting morgen früh um 8 Uhr teilnehmen. Sollte interessant sein.

Welches Meeting mit Dick?

Ich starre mein Handy an. Andererseits scheint John am Leben zu sein und arbeiten zu können. Das ist gut.

Aber er redet von einem Meeting mit Dick, dem zweitwichtigsten Manager der Firma, morgen früh. Eventuell ist John geistig nicht ganz auf der Höhe, hat aber schon allen erzählt, dass ich ein Mitverschwörer sei.

Das ist nicht gut. Ich tippe schnell eine Antwort an ihn: Schön, von Ihnen zu hören. Ich hoffe, es ist alles in Ordnung? Worum geht es bei dem Meeting? Eventuell schaffe ich es nicht.

Er antwortet sofort: Ich war arrogant. Gestern erkannt, dass ich gar nichts über Dick weiß. Muss das ändern. Zusammen.

Ich mache mir Sorgen, dass John jetzt ganz von der Rolle ist, und rufe ihn an. Er geht beim ersten Klingeln ran. »Guten Abend, Bill. Nochmals danke sehr für Samstagnacht. Was gibt es?«

»Was genau haben Sie vor, John?«, sage ich. »Worum geht es in diesem Meeting morgen früh mit Dick, und warum ziehen Sie mich da mit rein?«

Er antwortet: »Ich habe den größten Teil des Tages gestern im Bett verbracht, weil ich es kaum ins Bad und zurück geschafft habe. Mein Kopf fühlte sich an, als ob eine Dampfwalze drübergefahren wäre. Was haben Sie mir bloß für Drinks gekauft?«

Er wartet nicht auf meine Antwort, sondern fährt fort: »Ich habe über unsere Unterhaltung in der Bar nachgedacht. Dabei habe ich erkannt, dass, wenn ich schon nichts Nützliches für Sie tun konnte, mit dem ich doch am meisten gemeinsam haben müsste, es doch sehr unwahrscheinlich ist, dass ich für irgendwen anderen nützlich wäre, mit dem ich nichts gemeinsam habe.

Das muss sich ändern«, sagt er bestimmt.

Ich beiße mir auf die Zunge, denn ich will hören, was er noch zu sagen hat, bevor ich ihm empfehle, das Meeting abzublasen.

Er fährt fort: »Ich habe darüber nachgedacht, was Erik gesagt hat. Dass er erst dann wieder mit reden würde, wenn Dick mich braucht.«

»Ähm, ich glaube nicht, dass so ein halbstündiges Kennenlern-Meeting Sie dahin bringt«, sage ich skeptisch.

Er antwortet ganz ruhig: »Würden Sie denn nicht zustimmen, dass wir – wie bei so vielen Dingen im Leben – immer erst einmal ein Verständnis für die Person erlangen müssen, mit der wir es zu tun haben? Was kann schon schiefgehen? Ich möchte einfach mehr über seine Arbeit erfahren.«

Ich stelle mir direkt vor, wie John irgendetwas Dummes sagt oder fragt und Dick damit komplett verärgert, sodass er ihn auf der Stelle feuert – und mich gleich mit, damit sich das gar nicht erst verbreitet.

Trotzdem höre ich mich sagen: »Okay, ich werde da sein.«

KAPITEL 25

Dienstag, 14. Oktober

Am nächsten Morgen um 7:50 bin ich auf dem Weg zu Dicks Büro. Als ich um die Ecke biege, sehe ich, wie sich John freundlich mit Dicks Assistentin unterhält. Mir klappt die Kinnlade herunter. Johns Erscheinungsbild hat sich komplett verändert.

Offensichtlich hat er sich geduscht und rasiert. Er trägt etwas, das ich nur als Hemd im europäischen Stil bezeichnen kann, dazu eine Weste. Anders als die eher zu großen Hemden, die er sonst trägt, passt das pinkfarbene Hemd perfekt. Kombiniert mit der Weste, sieht er aus wie ein – Model? London Clubber? Croupier aus Las Vegas?

Mit dem rasierten Kopf, seinem freundlichen Lächeln und der perfekten Körperhaltung sieht er aus wie eine Art erleuchteter Mönch.

Noch offensichtlicher aber ist, dass ich seinen schwarzen Ordner nirgendwo sehe. Stattdessen hält er nur ein schlichtes schwarz-weißes Notizbuch sowie einen Stift in der Hand.

»Guten Morgen, Bill«, sagt John glücklich und ruhig.

»Hi«, sage ich schließlich. »Ähm, Sie sehen besser aus als das letzte Mal.«

Er lächelt nur und sagt leise etwas zu Dicks Assistentin, die nur die Hand vor den Mund schlägt und laut lacht. Dann steht sie auf, geht zu Dicks Tür und bedeutet uns, ihr zu folgen. Sie sagt: »Schauen wir mal, ob wir das Meeting etwas früher beginnen lassen können. Dann haben Sie mehr Zeit mit ihm.«

Ich folge John in Dicks Büro.

»Nette Frisur«, sagt Dick lächelnd zu John und zeigt dabei auf seine eigene Glatze. Dann wird er förmlicher: »Was kann ich für Sie tun? Ich habe um 8:30 den nächsten Termin, verschwenden wir also keine Zeit.«

John schlägt das Notizbuch auf der erste Seite auf, die noch ganz leer ist. »Vielen Dank, dass Sie sich so kurzfristig Zeit für uns nehmen konnten. Ich verspreche, dass wir sie nicht verschwenden. Und um sicherzustellen, dass ich keine falschen oder vorgefassten Vorstellungen habe, könnten Sie uns erzählen, was genau Sie hier bei Parts Unlimited machen? Wie sieht Ihre Rolle genau aus?«

Meine Augen weiten sich vor Panik angesichts Johns Frage. Das ist eine Frage, die man an einem Bring-Your-Kids-To-Work-Tag erwartet, aber nicht von einem Manager.

Ich schaue schnell zu Dick hinüber, um seine Reaktion zu sehen. Er sieht kurz überrascht aus, aber dann antwortet er höflich: »Eine interessante Frage.«

Er macht eine kurze Pause und scheint dann mitzuspielen. »Ich habe vor 15 Jahren hier bei Parts Unlimited als CFO begonnen, was damals recht klassisch definiert war. Ich musste mich vor allem um die finanziellen Risiken der Firma und die Finanzplanung sowie um die Umsetzung der Prozesse kümmern. Selbst damals hatten wir schon viele Probleme mit dem Erfüllen aller Regeln und Vorschriften, was ebenfalls mein Bereich war.

Kurz nachdem Steve CEO wurde, sagte er mir, dass wir eine leitende Führungskraft bräuchten, die sich um Planung und Umsetzung in der gesamten Firma kümmert. Das wurde dann ich. Um sicherzustellen, dass die Firma unsere Ziele erreicht, habe ich das Objectives- und Measurements-Programm für das gesamte Management-Team aufgesetzt. Ich wollte dafür sorgen, dass sich alle Manager verantwortlich fühlen und darauf achten, dass sie die für den Erfolg notwendigen Fertigkeiten haben. Aufwendige Initiativen sollten immer von den richtigen Leuten begleitet werden und so weiter.«

John hat wie wild alles mitgeschrieben und sieht nun hoch. »Ich habe gehört, dass Sie von vielen Leuten als der ›De-facto-COO‹ bezeichnet werden und dass Sie im Prinzip Steves rechte Hand sind.«

Dick überlegt seine Antwort eine Weile, dann sagt er: »In meinem offiziellen Titel kommt der Begriff ›Operations‹ nicht vor, aber es ist der Teil meines Jobs, den ich am meisten liebe. Wenn eine Firma so groß ist wie unsere, mit so vielen Geschäftsprozessen, so vielen Managern und Arbeitern, ist nahezu alles komplex. So klug Steve auch ist, selbst er braucht Hilfe, um sicherzugehen, dass die Firmenstrategie und die Ziele realistisch sind und das objektiv widerspiegeln, wozu wir tatsächlich in der Lage sind.«

Mit einem sehr dünnen Lächeln fügt er hinzu: »Soll ich Ihnen etwas Lustiges erzählen? Die Leute sagen, dass ich umgänglicher wäre als Steve! Steve ist unglaublich charismatisch, und ich bin, seien wir ehrlich, ein Arschloch. Aber wenn die Leute Sorgen haben, wollen sie nicht, dass ihnen das ausgeredet wird. Sie wollen, dass ihnen jemand zuhört und dabei hilft, sicherzustellen, dass Steve die Nachricht versteht.«

Ich lehne mich gespannt vor, denn ich bin überrascht, dass Dick John – und damit auch mir – so ehrliche und informative Antworten gibt.

»Wie unterscheiden Sie einen guten von einem schlechten Tag?«, fährt John fort.

Einen kurzen Moment ist Dick verblüfft, dann lacht er laut. »Ich werde Ihnen erzählen, wie sich ein guter Tag anfühlt. Er fühlt sich an wie das Ende des Jahres, wenn wir die Konkurrenz um Längen geschlagen haben – wenn die Bücher noch nicht geschlossen sind, aber jeder weiß, dass das ein Mega-Quartal gewesen ist. Alle Vertriebler haben ihr Soll erfüllt, und die besten sind noch weiter vorgeprescht. Ein guter Tag fühlt sich so an, dass meine Mitarbeiter Panik bekommen, wenn sie die Zahlen auf den Provisionsschecks sehen, die wir ausstellen.

Ich habe dann aber keine Angst, denn solche großen Provisionsschecks bedeuten ja, dass die Firma Geld macht«, sagt er und lächelt noch breiter. »Steve würde sich darauf freuen, der Wall Street und den Analysten erzählen zu können, wie gut die Firma läuft – all das, weil wir eine gute Strategie haben und weil der richtige Plan sauber umgesetzt wurde. Das heißt, dass alle Teile dieser Firma als Team zusammenarbeiten und erfolgreich sind.

Das ist ein guter Tag für mich. Wir können bis in alle Ewigkeit planen, aber solange wir die Pläne nicht ausführen und die Ziele nicht erreichen, ist das alles reine Theorie«, sagt er. Dann verschwindet sein Lächeln. »Natürlich hatten wir solch einen Tag in den letzten vier Jahren nicht mehr ...

Ein schlechter Tag ist wie der vor zwei Wochen«, sagt er, nun frustriert und verärgert. »Wir können das Quartal wegen irgendwelcher IT-Fehler nicht abschließen, wir scheinen eines unserer wichtigsten Projekte nicht umzusetzen, mit dem wir wieder zur Konkurrenz aufgeschlossen hätten, wir verlieren weiter Kunden, die Auditoren meckern wegen der Neuformulierung von Finanzdaten, und der Aufsichtsrat überlegt, uns alle zu feuern, weil wir solche Versager sind.«

Dick schüttelt den Kopf und lächelt blass und müde. »In solchen Momenten frage ich mich, ob das Problem in der Wirtschaftslage, unserer Strategie, unserem Führungsteam, bei euch IT-Leuten oder – offen gesagt – bei mir selbst liegt. Das sind Tage, an denen ich gerne in den Ruhestand gehen würde.«

John wirft einen Blick auf seine Notizen und fragt dann: »Was sind Ihre Ziele und Messgrößen für dieses Jahr?«

Dick steht auf, geht zu seinem Schreibtisch und sagt: »Hier, ich werde es Ihnen zeigen.«

Er nimmt einen dünnen, schwarzen Hefter von seinem Tisch, setzt sich uns wieder gegenüber und zeigt uns den Inhalt. »Das sind zwei Seiten, die ich mir jeden Tag anschaue.«

CFO-Ziele

Wohlergehen der Firma

Umsatz

Marktanteil

Durchschnittliche Auftragsgröße

Profitabilität

Gesamtkapitalrendite

Wohlergehen von Finance

Auftragsabwicklung

Außenstände

Genaue und pünktliche Finanzberichte

Kreditkosten

»Das sind die Firmenziele und die von mir für Finance definierten Ziele«, erklärt er. »Ich habe gelernt, dass die Finance-Ziele zwar wichtig sind, aber nicht das Wichtigste. Finance kann all seine Ziele erreichen, und trotzdem ist es möglich, dass die Firma Probleme hat. Denn selbst das beste Debitorenteam der Welt kann uns nicht retten, wenn wir im falschen Markt mit der falschen Produktstrategie unterwegs sind und ein F&E-Team haben, das nicht liefern kann.«

Mir ist plötzlich klar, dass er über Eriks Ersten Weg redet. Es geht um systemweites Denken und darum, dass die gesamte Firma und nicht nur ein Teil von ihr das Firmenziel erreichen muss.

Während ich darüber nachdenke, zeigt Dick auf das zweite Blatt und sagt: »Das hier ist die zweite Seite, die zeigt, was meiner Meinung nach die wichtigeren Firmenziele sind. Auch die schaue ich mir jeden Tag an.«

Sind wir konkurrenzfähig?

Kundenbedürfnisse verstehen: Wissen wir, was wir herstellen müssen?

Produktportfolio: Haben wir die richtigen Produkte?

F&E-Effektivität: Können wir die Produkte effektiv bauen?

Time to Market: Können wir die Produkte rechtzeitig liefern?

Sales-Pipeline: Können wir für Produkte interessieren?

Sind wir effektiv?

Pünktliche Lieferung an Kunden: Erhalten sie das, was wir ihnen versprochen haben?

Kundenbindung: Gewinnen oder verlieren wir Kunden?

Genauigkeit der Umsatzprognose: Können wir sie in unseren Planungsprozessen einsetzen?

John und ich lehnen uns vor, um die Seite zu lesen. Normalerweise sehen Manager wie ich nur unsere Abteilungsziele. Diese Seite zeigt das große Ganze.

Während ich darüber nachdenke, zeigt John auf die Seite und fragt: »Welche dieser Werte sind am kritischsten?«

Dick lacht humorlos. »Alle! Aus Produktportfoliosicht machen uns die Konkurrenten fertig und nehmen uns jeden Tag Marktanteile weg. Wir haben 20 Millionen Dollar und einige Jahre in Projekt Phoenix gesteckt und sind immer noch nicht konkurrenzfähig. Auf der Filial- und Herstellungsseite der Firma geht die Kundenzufriedenheit nach unten, und wir verlieren Kunden, obwohl uns der Vertrieb verspricht, dass wir sie irgendwie wieder zurückgewinnen können.«

John unterstreicht einige seiner Notizen. »Können wir davon eine Kopie haben? Bill und ich würden uns das gerne näher anschauen und darauf achten, dass unsere Teams es verstehen, sodass wir sicherstellen können, dass alles, was wir tun, diese Ziele unterstützt.«

Dick denkt einen Moment nach. »Sicher. Ich glaube nicht, dass das schlecht wäre. Ich werde, wenn Sie gehen, meine Assistentin bitten, Ihnen beiden eine Kopie zu machen.«

»Noch eine Sache«, sagt John. »Wer sind die Manager, die für jede dieser Initiativen und Messgrößen verantwortlich sind?«

Dick taxiert John – genau wie ich. Diese Seite von John habe ich noch nie gesehen.

Er sagt: »Meine Assistentin wird Ihnen ebenfalls die Tabelle mit den Namen geben.«

John bedankt sich bei ihm und sieht dann auf seine Uhr. »Die Zeit ist schon fast rum. Das war wirklich fantastisch. Vielen Dank, dass Sie sich die Zeit genommen haben, uns etwas über Ihre tagtägliche Arbeit zu erzählen. Gibt es etwas, das einer von uns für Sie tun kann?«

»Sicher«, antwortet Dick. »Konzentrieren Sie sich weiterhin auf Phoenix und halten Sie es am Laufen. Ohne dieses Projekt kommen wir nicht voran.«

Ich runzle die Stirn und werfe nochmals einen Blick auf die zweite Seite. Irgendwie habe ich das Gefühl, dass Phoenix nicht das ist, worauf ich mich konzentrieren sollte.

Mir ist nicht klar, warum, daher sage ich nur knapp: »Jawohl, Sir. Wir werden Ende des Monats sicherlich gute Neuigkeiten haben.« Ich bin nicht sicher, was für gute Neuigkeiten das sein werden, aber ich habe gelernt, dass es im Umgang mit leitenden Führungskräften den richtigen Moment gibt, schlechte Neuigkeiten zu überbringen. Das wäre jetzt nicht der Fall.

»Gut«, sagt er und lächelt uns schmallippig an.

Wir tauschen noch ein paar Höflichkeiten aus und verlassen dann sein Büro.

Als sich die Tür des Fahrstuhls öffnet, sagt John zu mir: »Wissen Sie, ich glaube, es gibt da ein paar Gemeinsamkeiten zwischen dem, wie wir das SOX-404-Audit gemeistert haben, und dem, was auf dieser zweiten Seite von Dick steht. Ich weiß im Moment nicht genau, was es ist, aber ich glaube, wir müssen das noch etwas besser verstehen.«

»Sie haben recht«, sage ich. »Ich denke nicht, dass Dick bewusst ist, wie viele seiner Ziele von der IT abhängen. Er hat etwas über Phoenix gesagt, aber er hätte über alle Ziele sprechen sollen.«

Wir betreten beide den Fahrstuhl. Ich fahre fort: »Haben Sie später Zeit, damit wir uns noch mal treffen? Vielleicht können wir dann die Zusammenhänge herausfinden. Ich habe das Gefühl, die fehlende Verknüpfung, die erklärt, warum sowohl die Firma ihre Ziele verfehlt als auch IT dauernd unterschätzt wird, sitzt vor unserer Nase, aber wir sehen sie noch nicht.«

»Auf jeden Fall«, sagt er begeistert.

Ich kann meine Aufregung kaum verbergen. Johns verrücktes Meeting mit Dick scheint etwas wirklich Wichtiges aufgedeckt zu haben.

Ich glaube ganz sicher, dass das, was wir herauszubekommen versuchen, für den Ersten Weg ausgesprochen entscheidend ist. John hat darüber gesprochen, den wirklichen Businesskontext verstehen zu müssen, in dem IT läuft.

Und ich bin auch ziemlich sicher, dass noch keiner Dicks Topmaßnahmen mit den erforderlichen IT-Zielen verknüpft hat.

Kein Wunder, dass Dick glaubt, dass IT nur alles durcheinanderbringt – es ist ein dumpfer, pochender Schmerz, den er nicht lokalisieren kann. Unser nächster Schritt ist daher offensichtlich: Wir müssen diese Schmerzen beschreibbar und sichtbar machen, um Dick davon zu überzeugen, dass IT nicht nur dazu in der Lage ist, weniger durcheinanderzubringen, sondern auch dem gesamten Business dabei helfen kann, zu gewinnen.

Das ist zu wichtig und dringend, um einfach nur im Dunkeln zu tappen, daher brauche ich Eriks Rat. Ich stehe im Eingangsbereich von Gebäude 2 und rufe ihn an.

»Ja?«, höre ich ihn fragen.

Ich sage: »Guten Morgen, Erik. Ich hatte gerade ein bemerkenswertes Meeting mit Dick. Haben Sie ein wenig Zeit, um mir dabei zu helfen, das nachzuarbeiten?«

Als er zustimmend »Ja« grummelt, beschreibe ich ihm, wie das Meeting verlief, wie es dazu kam und dass ich sicher sei, dabei etwas Wichtiges erkannt zu haben.

»Ah, sehr gut für Jimmy. Oder vielleicht sollte ich ihn › John‹ nennen. Jetzt hat er ja endlich seinen Kopf aus dem Sand gezogen und kann besser sehen«, höre ich Erik sagen, während er nicht unfreundlich lacht. »Als Teil des Ersten Wegs müssen Sie das Businesssystem, das IT betreut, wirklich verstehen. W. Edwards Deming hat das als › Verständnis für das System‹ bezeichnet. Wenn es um IT geht, haben Sie zwei Probleme: Einerseits sehen Sie jetzt auf Dicks zweiter Seite, dass es Verbindlichkeiten der Firma gibt, bei deren Erfüllung IT mit im Boot sitzt, aber die niemand exakt beschrieben hat. Andererseits hat John erkannt, dass manche der IT-Sicherheitsmaßnahmen, die er mit viel Aufwand umgesetzt hat, gar nicht notwendig sind, weil sich andere Teile der Firma um diese Risiken schon adäquat kümmern.

In der IT geht es immer darum, den Rahmen richtig festzulegen. Und so wie Mr. Sphere es jedem in Flächenland erzählt hat, müssen auch Sie die Gefilde der IT verlassen, um zu erkennen, wo Business auf IT aufbaut, um seine Ziele zu erreichen.« Er fährt fort: »Ihre Mission besteht aus zwei Elementen: Sie müssen herausfinden, wo IT zu schwach aufgestellt ist – wo also bestimmte Teile der Prozesse und Technologien, für die Sie verantwortlich sind, das Erreichen der Geschäftsziele gefährden –, und dafür auf Dicks Auswertungen zurückgreifen. Und John muss herausfinden, wo er IT zu stark aufgestellt hat, wie zum Beispiel bei diesen ganzen SOX-404-IT-Maßnahmen, die gar nicht notwendig waren, um Probleme in den Abschlüssen zu erkennen.

Sie denken vielleicht, dass wir hier Äpfel mit Birnen vergleichen, aber ich versichere Ihnen, dass das nicht der Fall ist«, fährt er fort. »Einige der klügsten Auditoren sagen, dass es nur drei interne Kontrollziele gibt: Man muss sich auf die Zahlen in den Abschlüssen verlassen können, man muss sich an Regelungen und Gesetze halten, und der Betrieb muss effizient und effektiv sein. Das ist alles. Worüber Sie und John sich unterhalten, sind nur zwei Seiten dessen, was als ›COSO-Würfel‹ bezeichnet wird.«

Ich höre mit Interesse zu und notiere mir alles, um diese Begriffe später bei Google zu suchen.

Erik fährt fort: »Sie und John müssen Folgendes tun: Reden Sie mit den Verantwortlichen für die Ziele auf Dicks zweiter Seite. Finden Sie heraus, was genau ihre Aufgaben sind und welche Geschäftsprozesse ihre Ziele unterstützen, und sammeln Sie dann von ihnen die Liste mit den Dingen ein, die das Erreichen dieser Ziele am ehesten gefährden.

Sie müssen die Wertketten verstehen, die notwendig sind, um jedes von Dicks Zielen zu erreichen – einschließlich der Ziele, die nicht so sichtbar sind, wie etwa in der IT. Wenn Sie beispielsweise eine Spedition wären, die Pakete mit einer Flotte von 100 Trucks ausliefert, würden zu Ihren Firmenzielen Kundenzufriedenheit und pünktliche Lieferung gehören.«

Er fährt fort: »Jeder weiß, dass eine pünktliche Lieferung durch Fahrzeugpannen gefährdet ist. Das passiert gerne durch vergessene Ölwechsel. Um dieses Risiko abzufangen, würden Sie also mit Ihrem Fuhrpark ein Service-Level-Agreement vereinbaren, das Öl alle 7500 Kilometer zu wechseln.«

Er hat offensichtlich viel Freude an dieser Beschreibung. »Der Key Performance Indicator (KPI) der Firma ist die pünktliche Lieferung. Um diesen zu erfüllen, würden Sie also einen zukunftsgerichteten KPI definieren, der zum Beispiel den Prozentsatz der Fahrzeuge berechnet, bei denen der Ölwechsel wie gewünscht durchgeführt wurde.

Denn wenn nur 50 Prozent unserer Fahrzeuge entsprechend den Richtlinien gewartet werden, kann man davon ausgehen, dass der KPI ›Pünktliche Lieferung‹ sehr bald in den Keller gehen wird, weil die Trucks regelmäßig am Straßenrand stranden – mit all den Paketen, die auszuliefern waren.

Die Leute denken immer, dass in IT keine präventiven Maßnahmen notwendig wären, weil kein Motoröl genutzt wird und keine echten Pakete durch die Gegend transportiert werden«, sagt Erik und muss darüber selbst kichern. »Nur weil die Arbeit und das Gut, das IT transportiert, unsichtbar sind, müsste lediglich etwas Feenstaub auf die Computer gestreut werden, damit wieder alles läuft.

Metaphern wie Ölwechsel helfen den Leuten, diese Verbindung herzustellen. Rechtzeitige Ölwechsel und Wartungsrichtlinien für die Fahrzeuge sind wie präventive Hersteller-Patches und Change-Management-Richtlinien. Indem Sie zeigen, wie IT die Leistungsfähigkeit des Business gefährden kann, können in Zukunft bessere Businessentscheidungen getroffen werden.

Okay, noch eine letzte Anmerkung, bevor ich weg muss«, sagt er. »Achten Sie darauf, dass John seine Mission erfüllt. Er muss mit den Finance-Kollegen aus dem SOX-404-Audit-Team sprechen. Er muss lernen, wie genau Business es geschafft hat, das letzte Audit zu bestehen, wie die Sicherheitsmaßnahmen wirklich aussehen und wo Fehler abgefangen werden. Und er muss es Ihnen dann erklären.

Sie werden für Ihr Meeting mit Dick bereit sein, wenn Sie die Wertketten ausgebaut haben und ihm zeigen können, wie IT seine Ziele gefährden kann. Seien Sie ausreichend vorbereitet.«

Und dann sagt er noch: »Sie können mich auch dazu einladen. Ich möchte zu gerne Dicks Gesichtsausdruck sehen, wenn Sie ihm Ihre Erkenntnisse vorstellen.« Dann legt er auf.

KAPITEL 26

Freitag, 17. Oktober

Als Patty den Besprechungsraum betritt, schnappt sie beim Anblick von John hörbar nach Luft. »Mein Gott, John. Sie sehen fantastisch aus!« Überraschenderweise scheint Wes bei seinem Eintreffen überhaupt keinen Unterschied zu bemerken.

Als alle da sind, erzähle ich kurz, was ich von Erik gelernt habe. Wir entscheiden, dass Patty und ich uns um die Gespräche mit den Prozessverantwortlichen kümmern werden, um zu verstehen, was die Kunden brauchen und wollen, und um Produktportfolio, Time-to-Market und die Sales-Pipeline kennenzulernen. John wird sich um die SOX-404-Sicherheitsmaßnahmen des Business kümmern, so wie Erik es vorgeschlagen hat.

Es ist Freitag, und wir haben einen Termin mit Ron Johnson vereinbart, dem VP of Manufacturing Sales. Ich habe mit ihm vor Jahren im Integrationsprojekt für eine Firmenübernahme zusammengearbeitet und bin überrascht, dass er in der Stadt ist. Normalerweise reist er in der Weltgeschichte umher und hilft dabei, Verträge abzuschließen und verärgerte Großkunden zu besänftigen. Er ist als einer der witzigsten Menschen in der Firma bekannt, mit dem eine Reise immer viel Spaß macht. Die Höhe seiner Reisekostenabrechnungen fällt dann auch entsprechend aus.

Patty und ich sitzen vor seinem Schreibtisch in Gebäude 2. Während wir ihm zuhören, wie er seine Kollegen in einer Telefonkonferenz anbrüllt, schaue ich mir die vielen Bilder von ihm an der Wand an: beim Golfen, mit seinen besten Vertrieblern in Hotels in exotischen Gefilden und beim Händeschütteln mit Kunden. In der Ecke steht ein künstlicher Gummibaum, der über und über mit Namensschildern von Konferenzen und Schlüsselbändern behängt ist.

Das ist definitiv das Büro von jemandem, der gern Publikum hat. Er ist ein großer, geselliger Kerl mit einer ausgesprochen lauten Lache.

Nach vielen Scotchs, die ich einen Abend mit ihm zusammen in Chicago getrunken habe, hat es mich überrascht zu entdecken, dass ein Großteil seines Auftretens Teil einer sorgfältig entworfenen Rolle ist. Während er sich nach außen hin sehr laut und direkt gibt, ist er eigentlich von Natur aus introvertiert, sehr analytisch und achtet auf Disziplin – auch bei seinen Vertrieblern. Als ich jetzt höre, wie er jemanden am Telefon zurechtstutzt, denke ich darüber nach, wie verrückt es ist, dass selbst ein Bereich wie Sales – bekannt für seine chaotische und unberechenbare Natur – besser vorhersagbar ist als IT.

Immerhin gibt es einen voraussagbaren Rahmen aus Marketingkampagnen, potentielle Interessenten, ernsthaften Interessenten und Absatzmöglichkeiten, die dann zu einer Sales-Pipeline führen. Ein Vertriebler, der seine Vorgaben nicht erfüllt, gefährdet im Allgemeinen nicht die gesamte Abteilung.

Ich hingegen kann durch einen Techniker mit einer scheinbar kleinen, harmlosen Änderung, die zu einem firmenweiten Ausfall führt, schnell auf der Straße sitzen.

Ron knallt den Hörer auf die Gabel. »Sorry, Leute. Trotz all des Trainings, das ich durchziehe, benimmt sich mein Team manchmal wie ein Haufen wilder Tiere«, sagt er, immer noch genervt. Das getackerte Dokument, das er in den Händen hält, reißt er in zwei Teile und wirft es in die Mülltonne.

»Oh Mann, Ron«, kann ich mir nicht verkneifen, »dein Papierkorb ist doch rechts von dir!«

»Ich werde schon lange tot sein, bevor die Müllkippen voll sind!«, sagt er mit lautem Lachen.

Er mag bald tot sein, meine Kinder aber nicht. Während ich ihm erkläre, warum wir hier sind, greife ich unter den Schreibtisch, fische die Papiere aus dem Mülleimer und verfrachte sie ins Altpapier. »Du bist in Dicks Tabelle als Verantwortlicher für die Parameter ›Sales-Pipeline‹ und ›Genauigkeit der Umsatzprognose‹ eingetragen. Was kannst du uns über die Herausforderungen beim Erfüllen dieser Zahlen erzählen?«

»Hört mal, ich weiß nicht viel über IT. Da gibt es unter meinen Mitarbeitern bestimmt jemanden, der euch besser helfen kann«, antwortet er.

»Keine Sorge, uns geht es nicht um IT. Uns interessieren die Zahlen ganz allgemein«, versichere ich ihm.

»Okay, wenn ihr wollt ...«, sagt er. »Wenn ihr über die Genauigkeit der Umsatzprognose sprechen möchtet, müsst ihr erst einmal wissen, warum sie so ungenau ist. Es geht damit los, dass Steve und Dick mir ein verrücktes Umsatzziel vorgeben und ich mir dann überlegen darf, wie wir das erreichen wollen. Seit Jahren muss ich meinem Team schon viel zu hohe Quoten vorgeben, da ist es doch klar, dass wir die Ziele nicht erreichen! Immer wieder versuche ich, Steve und Dick das klarzumachen, aber sie hören nicht zu. Vermutlich, weil ihnen selbst ein willkürliches Umsatzziel vom Aufsichtsrat vorgesetzt wurde.

Aber so kann man keine Firma führen. Mein Team ist demoralisiert, und meine besten Leute kündigen in Scharen. Natürlich ersetzen wir sie, aber es dauert mindestens ein Jahr, bis der Nachfolger die gleichen Zahlen erreichen kann. Selbst in der aktuellen schlechten Wirtschaftslage dauert es zu lange, gute Verkäufer zu finden.

Wisst ihr, was mich ärgert?«, fährt er fort. »Sarah hat versprochen, dass die Übernahme der Läden unsere Verkäufe verbessern würde. Und, ist das geschehen? Natürlich nicht!

Die Durchführung versemmeln wir auch komplett. Heute Morgen hat ein Bezirksleiter Zeter und Mordio geschrien, weil er Unmengen unserer neuen Einspritzdüsen-Kits braucht, denn die sind in all seinen Läden ausverkauft. Wir verpassen die einfachsten Umsatzmöglichkeiten! Unsere Kunden wollen kaufen, aber sie müssen mit leeren Händen den Laden verlassen und gehen dann vermutlich zur Konkurrenz, wo sie schlechtere Ware erhalten.«

Ron sagt ärgerlich: »Wir wissen nicht, was unsere Kunden wollen! Wir haben zu viele Produkte, die wir nie verkaufen, und nie genug von denen, die sich verkaufen lassen.«

Seine Worte klingen vertraut. Ich schaue mir Dicks Seite nochmals an.

»Du sagst, dass die ›Genauigkeit der Umsatzprognose‹ aufgrund unseres ›geringen Wissens über die Wünsche und Bedürfnisse unserer Kunden‹ gefährdet ist? Und dass wir die Verkaufszahlen verbessern könnten, wenn wir wüssten, welche Produkte in den Läden ausverkauft sind?«

»Genau«, sagt er. »Mit dem Kundendurchsatz in den Filialen ist das der schnellste und einfachste Weg, den Umsatz zu erhöhen. Es ist viel einfacher, als sich mit den Launen unserer großen Automotive-Kunden herumzuschlagen, das kann ich euch sagen.«

Ich mache mir eine Notiz, dass ich herausfinden muss, wie die Bestandsdaten erzeugt werden, und sehe, dass sich Patty auch vieles notiert.

Dann frage ich Ron nach dem Sales Pipelining-Prozess und seinen Herausforderungen und erfahre von ihm eine ganze Menge. Er erzählt uns in epischer Breite, wie schwierig es für seine Mitarbeiter ist, die benötigten Reports aus dem Customer Relationship Management-System (CRM) zu ziehen, und von dem endlosen Kampf mit seinen Vertrieblern, dass sie diese auch in ihrer täglichen Arbeit einsetzen.

Aber die Schleusen öffnen sich erst so richtig, als ich ihn frage, was für ihn ein schlechter Tag ist.

»Ein schlechter Tag?«, wiederholt er und starrt mich missbilligend an. »Na ja, Bill, es ist zum Beispiel eine Katastrophe, wenn das Material Requirement Planning und das Telefonsystem, die du betreust, nicht nutzbar sind, wie vor ein paar Wochen. Allein wegen des MRP-Ausfalls hatten wir haufenweise Kunden, die sich über verspätete Bestellungen beschwerten, und zwei von ihnen haben gleich ganz zwei Viertelmillionen-Dollar-Bestellungen storniert.

Wir versuchen gerade zu verhindern, dass einige unserer besten Kunden Verträge im Wert von 1,5 Millionen Dollar neu ausschreiben.«

Er lehnt sich an seinem Schreibtisch vor. »Und als die Telefone in den letzten Tagen des Quartals ausfielen und die Kunden keine Bestellungen oder Änderungen in letzter Minute aufgeben konnten! Damit sind uns noch mal 1,5 Millionen Dollar durch die Lappen gegangen, und zehn Kunden prüfen ihre Verträge, was im Bereich von weiteren 5 Millionen Dollar liegt.

»Du machst mir meinen Job ganz schön schwer, Kumpel«, sagt er. »Viele meiner Vertriebler haben ihre Quote knapp nicht erreicht, weil Dinge geschehen sind, für die sie nichts konnten. Um die Moral hochzuhalten, habe ich gefordert, dass Steve die Bestellungen der Folgezeit mit einrechnen lässt, wenn sie wegen der Ausfälle verzögert wurden.«

Ich ziehe eine Grimasse. Steve wird diese Idee genauso lieben wie Sarahs Idee, Gutscheine an verärgerte Phoenix-Kunden auszuteilen.

»Es tut mir wirklich leid, dass das unter meiner Ägide passiert ist. Dafür gibt es keine Entschuldigung«, sage ich aufrichtig. Ich beschreibe, was passiert ist, als der Hersteller unerlaubterweise Änderungen an der Telefonanlage vorgenommen hat, und welche Schritte wir eingeleitet haben, damit das nicht wieder passiert.

Dann erkläre ich: »Wir haben Change-Control-Richtlinien, aber wie du weißt, kommt man nur mit Training und Vertrauen nicht weit – ab einem gewissen Punkt müssen wir ein Monitoring durchführen, um diese Richtlinien sicherzustellen. Das Problem ist, dass wir dafür mehr Lizenzen brauchen, als Information Security bereitgestellt hat, und zusätzliches Geld heutzutage schwer aufzutreiben ist. Insbesondere für IT Operations.«

Ron wird knallrot. »Was? Wofür sparen die denn das Geld auf? Vermutlich für eine weitere wahnsinnige Akquisition, von der Sarah träumt.« Er lacht humorlos. »Von wie viel Geld reden wir hier?«

Als ich es ihm erzähle, ist er empört. »Wir geben jede Woche mehr Geld für das Bewässern unserer Rasenflächen hier auf dem Campus aus! Da wird Dick aber was von mir zu hören bekommen. Wenn er das Geld nicht bereitstellen will, verlieren wir vielleicht Aufträge – selbst wenn dein Projekt nur eine Maßnahme ist, um die harte Arbeit meiner Vertriebsleute abzusichern, muss man darüber doch gar nicht nachdenken!«

»Wir sehen das auch so. Vielen Dank für deine Unterstützung«, sage ich. »Die Zeit ist gleich rum. Gibt es noch andere Herausforderungen oder Hindernisse, bei denen wir dir helfen können?«

Er schaut kurz auf seine Uhr. »Nein, sorgt einfach dafür, dass dieser Hersteller nicht wieder unsere Telefonanlage lahmlegt, okay?«

Patty sieht sehr motiviert aus, während sie vor dem Fahrstuhl ihre Notizen durchblättert. Sie sagt: »Ron hat erwähnt, wie kritisch die Telefon- und MRP-Systeme sind, aber ich bin sicher, dass es weitere gibt, zum Beispiel die Warenwirtschaftssysteme. Ich werde eine vollständige Liste mit Anwendungen und der Infrastruktur erstellen, die Ron unterstützen. Wenn etwas davon instabil ist, müssen wir es mit auf unsere Austauschliste nehmen. Das ist eine tolle Gelegenheit, proaktiv tätig zu werden.«

»Du hast meine Gedanken gelesen«, sage ich lächelnd. »Diese präventive Arbeit unterstützt die wichtigsten Ziele der Firma. Woher wissen wir das? Wir haben mit den Messgrößen begonnen, um die sich Dick am meisten sorgt.«

Ich bin zufrieden. Jetzt freue ich mich wirklich auf unser nächstes Gespräch, das mit Maggie Lee stattfinden wird. Sie ist der Sponsor von Phoenix.

Patty und ich treffen sie am folgenden Montag. Am Wochenende hat Sarah mir E-Mails geschrieben und die Agenda für das Meeting eingefordert mit der Drohung, es ansonsten abzusagen. Als ich bei meinen Antworten Dick und Steve mit auf CC setze, gibt sie nach, warnt mich aber, mich nicht in ihre Abteilung einzumischen.

Ich mache mir keine Sorgen. Sowohl Patty als auch ich arbeiten regelmäßig mit Maggie zusammen. Sie ist der Businesssponsor von über der Hälfte der IT-Projekte. Unter anderem ist Maggie für die Auswahl der Produkte in unseren Filialen zuständig, zudem kümmert sie sich um die Kategorien- und Preispläne.

Beim Beschreiben ihrer Verantwortlichkeiten fasst sie zusammen: »Ich messe letztendlich unser Verständnis für die Kundenbedürfnisse daran, ob sie uns ihren Freunden empfehlen. Wie man es auch dreht und wendet – unsere Metriken sind nicht sehr gut.«

Als ich frage, warum das so ist, seufzt sie. »Die meiste Zeit fliegen wir blind. Idealerweise würden uns unsere Verkaufszahlen zeigen, was die Kunden möchten. Eigentlich sollte man das ja aus all den Daten in unseren Auftrags- und Lagerverwaltungssystemen herausfinden können. Aber das ist nicht möglich, weil die Daten so gut wie immer falsch sind.«

Patty schaut mich kurz bedeutungsvoll an, während Maggie fortfährt: »Die Qualität unserer Daten ist so schlecht, dass wir damit keinerlei Vorhersagen treffen können. Die besten Daten, die wir noch haben, stammen aus Fragerunden mit unseren Filialleitern, die wir alle zwei Monate durchführen, und mit unseren Customer Focus Groups, die zwei Mal im Jahr stattfinden. Man kann doch keine Firma mit einem Milliardenumsatz so führen und dann noch Erfolge erwarten!

Bei meinem vorherigen Arbeitgeber haben wir jeden Tag Verkaufs- und Bestandslisten bekommen«, fährt sie fort. »Hier erhalten wir sie einmal im Monat von Finance, aber sie sind voller Fehler. Aber was soll man auch erwarten? Das machen immer ein paar Praktikanten vom College, die die Zahlen zwischen einem Haufen Spreadsheets hin- und herschieben.«

»Wenn du einen Zauberstab hättest, was würdest du dann tun?«, frage ich.

»Wie mächtig wäre der denn?«, fragt sie.

»Du könntest alles damit tun«, antworte ich lächelnd.

»Das ist dann aber ein großer Zauberstab«, sagt sie lachend. »Ich möchte genaue und zeitnahe Auftragsinformationen aus unseren Läden und dem Onlinestore haben. Ich möchte auf eine Taste drücken und die Daten bekommen, statt den ganzen Zirkus mitmachen zu müssen, der bei uns geschieht. Ich würde diese Daten dann nutzen, um Marketingkampagnen aufzusetzen, die fortlaufend A/B-Tests für Angebote durchführen, um diejenigen herauszufinden, die die Kunden ansprechen. Wenn wir das wissen, würden wir die Angebote auf die gesamte Kundenliste ausweiten. Dadurch würden wir für Ron eine große und vorhersagbare Verkaufs-Pipeline erzeugen.

Mit diesen Informationen würde ich unseren Produktionsplan füttern, sodass wir unsere Angebot-und-Nachfrage-Kurven verwalten können. Wir könnten die richtigen Produkte in die Regale der richtigen Filialen stellen und immer genug auf Lager haben. Unsere Erträge pro Kunde würden durch die Decke gehen. Unsere durchschnittliche Auftragshöhe würde steigen. Wir könnten schließlich unsere Marktanteile erhöhen und uns wieder gegen die Konkurrenz durchsetzen.«

Während sie uns das erzählt, sieht sie begeistert und munter aus. Dann verschwindet ihre Überschwänglichkeit wieder. Niedergeschlagen sagt sie: »Aber leider sind wir gefangen in den Systemen, die wir haben.«

»Warte mal. Ich dachte, Phoenix sollte all das lösen?«, frage ich.

Sie schnaubt empört. »Von Phoenix haben wir nur Versprechungen bekommen. Es sollte viele dieser Berichte bieten, aber es gab so viel politischen Druck, etwas zu liefern, dass immer mehr Features wegfielen. Und ratet mal, welche Features auf das nächste Jahr verschoben wurden?« Genervt rollt sie die Augen.

»Reporting?«, vermute ich und fürchte das Schlimmste.

Als Maggie nickt, versuche ich, optimistisch zu klingen. »Gehen wir einmal davon aus, dass der Zauberstab funktioniert hat. Wir haben jetzt gute Daten, die aus den Läden kommen. Du schaffst es, die richtigen Produkte in den Filialen zu platzieren, und die Kampagnen, die du dir erträumt hast, sind erfolgreicher, als irgendjemand vermutet hat. Was dann?«

»Das Leben ist schön, das ist dann!«, sagt sie, und ihre Augen leuchten. »Letztes Jahr haben wir ein eigenes Einspritzsystem für einen neuen Sportwagen geliefert. Wir hatten nur sechs Monate, es marktreif zu bekommen – vom Zeichenbrett bis in die Regale. Und wir haben es geschafft! Die Designer, die Leute aus Forschung und Entwicklung und das Marketing haben perfekte Arbeit geliefert. Wir hatten das richtige Produkt zur richtigen Zeit, die richtige Marke, den richtigen Preis und die richtige Qualität. Es war eines der bestverkauften Produkte des Jahres.

Wir sind ein Risiko eingegangen und haben gesiegt«, sagt sie. »Wenn wir einen besseren Einblick in unsere Retail-Daten hätten, könnten wir mit unseren erstaunlichen F&E- und Herstellungsfertigkeiten 50 solcher Dinger im Jahr rausbringen. Ich wette, vier davon wären jeweils echte Kracher! Wir wären nicht einfach nur profitabel, wir wären irrsinnig profitabel.«

Patty fragt dazwischen: »Was ist eine akzeptable Time to Market für deine Produkte?«

Maggie antwortet schnell: »Heutzutage? Produkte müssen in sechs Monaten auf dem Markt sein. Höchstens in neun. Ansonsten schnappt sich eine chinesische Firma unsere Idee, bringt sie in die Läden unserer Konkurrenz und bekommt damit einen großen Marktanteil.

In diesen Zeiten starker Konkurrenz muss man schnell im Markt sein und auch die Fehler schnell machen. Wir können uns keine mehrjährigen Entwicklungszyklen mehr leisten und erst am Ende erkennen, ob das Produkt gut ist oder beim Kunden durchfällt. Es müssen kurze und schnelle Zyklen sein, in denen das Feedback aus dem Markt fortlaufend einfließt.

Aber das ist nur die eine Hälfte der Geschichte«, fährt sie fort. »Je länger der Produktentwicklungszyklus ist, desto mehr Kapital ist gebunden, das uns in der Zeit auch keine Rendite liefern kann. Dick erwartet, dass von unseren F&E-Investitionen mehr als zehn Prozent wieder zurückkommen. Das ist unsere interne Mindestrendite. Wenn wir die nicht erreichen, wäre das Kapital besser im Aktienmarkt oder am Pokertisch oder bei Pferdewetten eingesetzt worden.

Wenn das F&E-Kapital mehr als ein Jahr als WIP gebunden ist und keinen Ertrag liefern kann, wird es für das Business nahezu unmöglich, das wieder reinzuholen«, schließt Maggie.

Heilige Scheiße. Maggie fängt bereits auf unheimliche Weise an, wie Erik zu reden. Die Notwendigkeit, Taktzeiten kontinuierlich zu verringern, ist Teil des Ersten Wegs. Der Bedarf, mehr Feedback einzuholen – möglichst vom Kunden –, ist Teil des Zweiten Wegs.

Aber maximal neun Monate, um der Firma Erträge zu bringen? Wir sitzen jetzt an Phoenix fast drei Jahre, und es gibt noch immer keine Vorteile für das Business.

Ich habe das furchtbare Gefühl, dass wir mit Phoenix den völlig falschen Weg beschreiten ...

Ein Blick auf die Uhr zeigt mir, dass die Zeit fast rum ist. Meine Gedanken an Phoenix schiebe ich erst einmal beiseite und frage Maggie nach anderen Stellen, an denen IT das Erreichen ihrer Ziele behindert.

Ihre Mine verfinstert sich. »Na ja, da gibt es noch eine Sache ...«

Dann beschreibt sie die große Konkurrenz beim Kampf um IT-Projektressourcen. »Unser Planungshorizont beträgt sechs bis zwölf Monate. Wie soll man wissen, an welchen Projekten in drei Jahren gearbeitet werden soll?«, sagt sie verärgert und erinnert mich plötzlich an Ron.

Nichts eint die Leute mehr als das Meckern über IT.

»Ich verstehe deine Frustration«, sage ich ruhig. »Hast du eine Idee, wie man das besser machen kann?«

Sie hat einige – mehr IT-Leute einstellen, ihrer Gruppe exklusiv IT-Mitarbeiter zuteilen, genauer prüfen, ob Projekte wirklich nötig sind, damit die Projekt-Queue in IT nicht verstopft wird und so weiter.

Die meisten Ideen sind nicht neu, und ich hebe bloß die Augenbrauen, als sie ein größeres IT-Budget anspricht. Steve und Dick werden das nie genehmigen.

»Unglaublich!«, ruft Patty, als wir Maggies Büro verlassen. »Ich hätte nicht gedacht, dass Maggie und Ron so frustriert sind. Kannst du dir vorstellen, dass es schon wieder um unzuverlässige Daten in den Auftrags- und Lagerverwaltungssystemen geht? Und ich kann nicht glauben, dass Phoenix in seinem aktuellen Design die Probleme mit der Datenqualität gar nicht löst!«

Ich nicke und sage entschieden: »Organisiere bitte ein Meeting mit John und Wes. Wir werden ihnen zeigen, was wir bisher erfahren haben. Du kannst auch Chris dazu einladen. Das betrifft nicht nur IT Operations, sondern es ändert vielleicht auch die Art und Weise, wie wir unsere Anwendungen priorisieren und entwickeln.«

Als sie geht, schaue ich mir meine Berechnungen zu Phoenix nochmals an.

Wir haben in drei Jahren über 20 Millionen Dollar für Phoenix ausgegeben. Mit all der WIP und dem Kapital, das in dem Projekt gebunden ist, wird es die Mindestrendite von zehn Prozent wohl nie erreichen. Mit anderen Worten: Phoenix hätte gar nicht genehmigt werden dürfen.

KAPITEL 27

Dienstag, 21. Oktober

Ich bin mit Patty, Wes, Chris und John in einem Besprechungsraum, um von dem Fortschritt zu berichten, den Patty und ich gemacht haben.

Ich beginne: »Wir haben mit Ron und Maggie gesprochen – den Business Process Owners auf Dicks Übersicht. Ich habe mir dann Gedanken darüber gemacht, was wir dort erfahren haben.«

Ich hole meine Notizen hervor und gehe zum Whiteboard, um zu schreiben: »Parts Unlimited: gewünschte Geschäftsziele: Einnahmen erhöhen, Marktanteil vergrößern, durchschnittliche Auftragsgröße vergrößern, Profitabilität wiederherstellen, Kapitalrendite erhöhen«. Dann zeichne ich die folgende Tabelle an:

Maßnahme | IT-Beteiligung | Businessrisiko durch IT | Genutzte IT-Maßnahmen
1. Kundenbedürfnisse verstehen | Auftrags- und Lagerverwaltungssysteme | Daten nicht genau, Berichte nicht zeitnah und überarbeitungsbedürftig |
2. Produktportfolio | Auftragssysteme | Daten nicht genau |
3. F&E-Effektivität |  |  |
4. Time to Market (F&E) | Phoenix | lange Entwicklungszeiten (drei Jahre) und WIPs sorgen dafür, dass interne Mindestrendite wohl nicht erreicht wird |
5. Sales-Pipeline | CRM, Marketingkampagne, Telefon/Mailbox, MRP-Systeme | Vertriebsleitung kann Pipeline nicht einsehen/verwalten, Kunden können keine Aufträge ergänzen/ändern |
6. Termintreue | CRM, Telefon/Mailbox, MRP-Systeme | Kunden können Aufträge nicht ergänzen/ändern |
7. Kundenbindung | CRM | Vertrieb kann Kundenzufriedenheit nicht verwalten |
8. Genauigkeit der Umsatzprognose | (siehe 1.) | (siehe 1.)

Ich zeige auf das Whiteboard und sage: »In der ersten Spalte stehen die Businessmaßnahmen und -prozesse, die für das Erreichen von Dicks Zielen notwendig sind. In der zweiten Spalte finden sich die IT-Systeme, auf denen diese Businessprozesse aufbauen. In der dritten Spalte steht, was mit den IT-Systemen oder Daten passieren kann. Und in der vierten Spalte werden wir die Gegenmaßnahmen aufschreiben, mit denen die Effekte aus Spalte drei verhindert oder wenigstens erkannt werden können.«

In der nächsten halben Stunde gehen wir die Tabelle und die Beschwerden, auf denen sie beruhen, durch. »Anscheinend ist bei allen Dingen, die für Dick am wichtigsten sind, IT eine bedeutende Komponente«, sage ich trocken. Wes sagt: »Ach komm. Ich bin ja bestimmt nicht der Klügste hier im Raum. Aber wenn wir doch so wichtig sind – warum versuchen sie dann, uns alle outzusourcen? Seien wir mal ehrlich – wir werden doch schon seit Jahrzehnten hin- und hergeschoben.«

Keiner von uns hat eine gute Antwort.

»Wisst ihr, ich mag ja Bills dritte Spalte am liebsten: ›Businessrisiko durch IT‹«, sagt John. »Indem wir beschreiben, was in der IT schiefgehen kann und was damit verhindert, dass Businessziele erreicht werden, helfen wir den Business Process Owners, ihre Boni zu erhalten. Das sollte sehr überzeugend sein. Vielleicht bedankt sich Business sogar bei uns, dass wir all ihre Arbeit machen. Das wäre doch mal eine erfrischende Änderung.«

»Das sehe ich auch so. Gute Arbeit, Bill«, sagt Chris schließlich. »Aber wie sieht die Lösung aus?«, frage ich. »Hat jemand eine Idee?«

Überraschend meldet sich John als Erster. »Das scheint ziemlich offensichtlich zu sein. Wir müssen uns IT-Maßnahmen überlegen, mit denen die Risiken aus der dritten Spalte minimiert werden können. Dann zeigen wir Ron und Maggie diese Tabelle und überzeugen sie davon, dass unsere Gegenmaßnahmen ihnen dabei helfen, ihre Ziele zu erreichen. Wenn sie uns das abnehmen, arbeiten wir mit ihnen zusammen daran, IT in ihre Maßnahmen zu integrieren ...

Das Beispiel, das Erik genannt hat, ist perfekt. Dort wurde ›Truck-Wartungspläne einhalten‹ als entscheidender Indikator für ›pünktliche Lieferung‹ und ›Kundenzufriedenheit‹ mit aufgenommen. Das müssen wir auch tun.«

Also rollen wir die Ärmel hoch und machen uns an die Arbeit.

Bei den Telefon- und MRP-Systemen legen wir schnell fest, dass zu den präventiven Maßnahmen das Befolgen des Change-Management-Prozesses, die Supervision und Nachbetrachtung von Änderungen in der Produktivumgebung, das Durchführen regelmäßiger Wartungsvorgänge und das Ausmerzen aller bekannter Single Points of Failure gehören.

Als wir uns dem Bereich »Kundenbedürfnisse« zuwenden, kommen wir ins Stolpern.

Erneut bringt uns John voran. »Hier ist das Ziel nicht ›Systemverfügbarkeit‹, sondern ›Datenintegrität‹, zufällig also zwei der drei Seiten des Dreiecks ›Vertraulichkeit, Integrität und Verfügbarkeit‹ – oder auch ›Confidentiality, Integrity and Availability‹, also CIA.« Er fragt Chris: »Was verursacht denn die Probleme mit der Datenintegrität?«

Chris schnaubt empört. »Phoenix hat ein paar der Probleme gelöst, aber es gibt immer noch welche. Die meisten entstehen bei der Zulieferung der Daten, weil die Marketingleute immer wieder falsch formatierte Artikelnummern eingeben. Die müssen ihren Laden auch auf Vordermann bringen.«

Also gehört zu unseren vorgeschlagenen Maßnahmen für »Marketingbedürfnisse« die Fähigkeit von Phoenix, wöchentliche oder sogar tägliche Berichte liefern zu können, den Prozentsatz der vom Marketing gelieferten korrekten Artikelnummern zu erhöhen und so weiter.

Am Ende der Besprechung haben wir eine Präsentation zusammengestellt, die Patty und ich mit zu Ron und Maggie nehmen und die wir dann gemeinsam Dick vorstellen wollen.

»Na, das ist doch mal ein solider Vorschlag«, sagt Wes stolz. Mit lautem Lachen ergänzt er: »Selbst ein Affe könnte den Punkten folgen, die wir gerade zusammengestellt haben!«

Am nächsten Tag erhalten Patty und ich begeistertes Feedback von Ron und Maggie, und sie sagen zu, unseren Vorschlag gegenüber Dick zu unterstützen. Als Ron erfährt, dass wir immer noch kein Budget für unser Monitoring-Projekt erhalten haben, ruft er Dick in unserem Beisein an und hinterlässt ihm eine hitzige Nachricht auf der Mailbox – er will wissen, warum Dick nicht in Gang kommt.

Bei all dieser Unterstützung kann das Meeting mit Dick am Donnerstag ja nur ein voller Erfolg werden.

»Sie haben mir bisher nur erzählt, dass Sie am Steuer eingeschlafen sind!«, sagt Dick ernst und offensichtlich überhaupt nicht von dem beeindruckt, was ich gerade präsentiert habe. Plötzlich fühle ich mich daran erinnert, wie Steve sich die vorbereiteten Spreadsheets nicht einmal angeschaut hat, als ich ihn bat, Phoenix und die Arbeit an den Audit-Ergebnissen gegeneinander abzuwägen.

Aber Dick ist nicht ablehnend – er ist tatsächlich wütend. »Sie erzählen mir etwas, das der letzte Depp hätte herausfinden können. Sie wussten nicht, dass diese Maßnahmen wichtig sind? Bei jedem All-Hands-Meeting redet Steve darüber. Sie stehen in unseren Firmen-Newslettern, und Sarah geht in all ihren Strategie-Meetings darauf ein. Wie konnten Sie alle etwas so Wichtiges übersehen?«

Ich sehe, wie sich Chris und Patty links und rechts von mir winden, während wir Dick am Tisch gegenübersitzen. Erik steht am Fenster und lehnt sich gegen die Wand.

Ich habe einen Flashback zu meiner Zeit als Marine-Sergeant. Ich war Flaggenträger bei einer Parade. Aus dem Nichts erschien ein Colonel und putzte mich vor der ganzen Einheit herunter: »Das ist ein unzulässiges Armband, Sergeant Palmer!« Ich wäre am liebsten auf der Stelle im Boden versunken, weil ich wusste, dass ich es versaut hatte.

Aber heute bin ich sicher, dass ich die Mission verstanden habe, und damit die Firma Erfolg hat, muss Dick verstehen, was ich gerade gelernt habe. Aber wie?

Erik räuspert sich und sagt zu Dick: »Ich stimme zu, dass der letzte Depp das hätte wissen können. Dann erklären Sie doch mal bitte, warum Sie in Ihrem kleinen Spreadsheet für jede Ihrer Maßnahmen vier Management-Ebenen angeben, aber nirgendwo IT-Manager auftauchen. Warum?«

Er wartet nicht darauf, dass Dick antwortet, sondern fährt fort: »Jede Woche werden IT-Mitarbeiter von Managern in letzter Minute in irgendwelche Rettungsaktionen hineingezogen, damit diese Ziele erreicht werden können – so wie Brent bei Sarahs letzter Sales Promotion eingreifen musste.« Erik macht eine Pause, dann sagt er: »Ganz ehrlich – ich glaube, Sie sind genauso ein Depp wie Bill.«

Dick grummelt, scheint aber nicht empört zu sein. Schließlich sagt er: »Kann sein, Erik. Wissen Sie, vor fünf Jahren haben wir unseren CIO mit zu unseren vierteljährlichen Business Reviews eingeladen, aber er hat nie etwas gesagt außer: ›Das ist unmöglich.‹ Nach einem Jahr hat Steve ihn dann nicht mehr eingeladen.«

Dick wendet sich mir zu. »Bill, Sie sagen, dass jeder im Business alles richtig machen könnte, aber wir aufgrund dieser IT-Probleme trotzdem alle diese Ziele verpassen würden?«

»Genau«, sage ich. »Die operativen Risiken der IT müssen genau so behandelt werden wie alle anderen Businessrisiken. Mit anderen Worten: Es sind keine IT-Risiken, sondern Businessrisiken.«

Erneut grummelt Dick. Er lässt sich in seinen Sessel sinken und reibt sich die Augen. »Mist. Wie zum Teufel sollen wir einen IT-Outsourcing-Vertrag aushandeln, wenn wir nicht einmal wissen, was das Business braucht?«, sagt er und schlägt mit der Hand auf den Tisch.

Dann fragt er: »Okay, was ist Ihr Vorschlag? Sie haben doch einen, oder?«

Ich setze mich auf und stelle die Ideen vor, die ich mit dem Team so häufig durchgesprochen habe. »Ich würde gerne drei Wochen mit jedem Business Process Owner bekommen, der auf diesem Spreadsheet aufgeführt ist. Wir müssen die durch IT verursachten Businessrisiken besser definieren und uns über sie einig werden, um Ihnen dann einen Weg vorzuschlagen, wie diese Risiken in die wichtigen Performanceindikatoren eingebunden werden können. Unser Ziel ist nicht nur, das Business leistungsfähiger zu machen, sondern auch, rechtzeitige Hinweise darauf zu erhalten, ob wir die Ziele erreichen werden oder nicht, um noch entsprechend reagieren zu können.

Zudem«, fahre ich fort, »würde ich gerne mit Ihnen und Chris ein Meeting zum Thema Phoenix vereinbaren.« Dann erkläre ich, warum Phoenix meiner Meinung nach so, wie es aktuell definiert ist, gar nicht hätte genehmigt werden dürfen.

Ich sage: »Wir kommen viel zu langsam voran, haben zu viele WIPs und zu viele Features in Arbeit. Wir müssen unsere Releases kleiner machen, dafür aber schneller rausbringen, um damit auch schneller Geld zu machen, sodass wir die interne Mindestrendite erreichen. Chris und ich haben ein paar Ideen, aber die gehen in eine ganz andere Richtung als unsere bisherigen Pläne.«

Dick bleibt still. Dann scheint er sich entschieden zu haben: »Ich stimme beiden Vorschlägen zu. Ann wird Ihnen helfen. Sie brauchen die besten Leute aus der Firma.«

Aus dem Augenwinkel heraus sehe ich Chris und Patty lächeln.

»Vielen Dank, Sir. So machen wir es.« Ich stehe auf und befördere alle aus dem Raum, bevor Dick eventuell seine Meinung ändert.

Als wir vor dem Büro stehen, legt mir Erik die Hand auf meine Schulter. »Nicht schlecht, Junior. Ich gratuliere Ihnen dazu, dass Sie den Ersten Weg immer besser meistern. Jetzt helfen Sie John dabei, das auch zu schaffen, denn Sie werden alle Hände voll damit zu tun haben, den Zweiten Weg anzugehen.«

Verwirrt frage ich: »Warum? Was wird denn passieren?«

»Das werden Sie noch früh genug herausfinden«, sagt Erik kichernd.

Am Freitag ruft John ein Meeting mit Wes, Patty und mir zusammen, um ein paar tolle Neuigkeiten zu verkünden. Überschwänglich sagt er: »Toll, wie ihr IT mit Dicks operativen Zielen verknüpft habt. Ich habe endlich gelernt, wie wir die Audits meistern können, und ich bin ziemlich sicher, dass wir etwas genauso Tolles schaffen können, um die Arbeitslast zu reduzieren, die wir mit Audits und Compliance haben.«

»Weniger Audit-Arbeit?«, fragt Wes und legt sein Handy beiseite. »Ich bin ganz Ohr!«

Auch meine Aufmerksamkeit hat er. Wenn es eine Möglichkeit gäbe, die ganze Arbeit aus den Audit-Ergebnissen zu vermeiden, ohne wieder an so einem unwürdigen Meeting teilnehmen zu müssen, wäre das nicht weniger als ein Wunder.

Er wendet sich Wes und Patty zu. »Ich musste herausfinden, wie wir uns vor all den Resultaten der internen und externen Auditoren drücken konnten. Zuerst dachte ich, der Audit-Partner würde einfach beide Augen zudrücken, um uns als Kunden zu behalten. Aber das war es gar nicht unbedingt ...

Ich habe mich mit jedem aus dem Team von Parts Unlimited getroffen, der bei diesem Meeting dabei war, um herauszufinden, von wem das Wundermittel stammte. Zu meiner Überraschung waren das nicht Dick oder unser Firmenanwalt. Zehn Meetings später traf ich schließlich auf Faye, eine Finanzanalystin, die für Ann arbeitet.

Faye hat einen technischen Hintergrund, sie hat vier Jahre in der IT gearbeitet«, sagt er und gibt jedem von uns Ausdrucke. »Sie hat diese SOX-404-Sicherheitsmaßnahmen-Dokumente für das Finance-Team erstellt. Darin findet sich der Informationsfluss für die wichtigsten Businessprozesse in jedem finanziell relevanten Account – vom Anfang bis zum Ende. Sie hat dokumentiert, wo Geld in das System hineinfließt, und es bis zum Hauptbuch verfolgt.

Das ist mehr oder weniger Standard, aber sie ist noch einen Schritt weitergegangen: Faye hat sich die IT-Systeme gar nicht angeschaut, sie wollte zunächst genau verstehen, wo Schwachstellen auftreten könnten und wo sie erkannt würden. In den meisten Fällen würden sie bei einer manuellen Kontenabstimmung auffallen, bei der Kontostände aus verschiedenen Quellen miteinander verglichen werden – normalerweise wöchentlich.

Und wenn das der Fall war«, sagt John mit Ehrfurcht, »wusste sie, dass die zugrunde liegenden IT-Systeme für das Audit uninteressant waren.«

»Das hat sie den Auditoren gezeigt«, fährt John fort und blättert zur zweiten Seite um. »Ich zitiere: ›Die Sicherheitsmaßnahme, mit der Schwachstellen zuverlässig entdeckt werden, ist die manuelle Kontenabstimmung. Es muss keine Sicherheitsmaßnahme in einem der zugrunde liegenden IT-Systeme implementiert sein.‹ Ich bin alle Unterlagen von Faye durchgegangen, und in allen Fällen haben die Auditoren ihr Okay gegeben und die Einwände wegen der IT-Schwachstelle zurückgezogen.

Darum hat Erik die ganzen Audit-Ergebnisse als ›Scoping Error‹ bezeichnet. Er hat recht. Wenn der Audit-Testplan von Anfang an auf die richtigen Bereiche ausgerichtet gewesen wäre, hätte es auch keine IT-Funde gegeben!«, schließt er.

John sieht uns an, aber Patty, Wes und ich starren nur zurück.

Ich sage: »Ich kann Ihnen nicht folgen. Was hat das mit dem Reduzieren der Audit-Arbeitslast zu tun?«

»Ich baue unser Compliance-Programm von Grund auf neu auf. Dieses Mal basiert es auf unserem neuen Verständnis von den eingesetzten Sicherheitsmaßnahmen«, antwortet John. »Das gibt vor, was wichtig ist. Es ist, als hätte man eine magische Brille auf, die unterscheiden kann, welche Sicherheitsmaßnahmen auf jeden Fall unabdingbar sind und welche keinen Nutzen haben.«

»Ja!«, sage ich. »Diese ›magische Brille‹ hat uns auch dabei geholfen, endlich zu erkennen, was für Dick für die Firma wichtig ist. Wir hatten es all die Jahre direkt von unserer Nase, aber wir konnten es nicht sehen.«

John nickt und lächelt breit. Er blättert zur letzten Seite des Handouts. »Ich schlage fünf Dinge vor, die unsere sicherheitsbezogene Arbeitslast um 75 Prozent reduzieren kann.«

Was er vorstellt, ist atemberaubend. Sein erster Vorschlag verringert den Rahmen des SOX-404-Compliance-Programms drastisch. Während er erklärt, warum das ohne Sicherheitsverlust umgesetzt werden kann, erkenne ich, dass John ebenfalls den Ersten Weg meistert und tatsächlich eine »profunde Würdigung des Systems« erreicht hat.

Für seinen zweiten Vorschlag müssen wir herausfinden, wie die Schwachstellen in das System kommen konnten, und dann dafür sorgen, dass das nicht wieder passiert, indem wir unseren Deployment-Prozess anpassen.

Sein dritter Vorschlag beinhaltet eine Kennzeichnung aller Systeme in Pattys Change-Management-Prozess, die im Rahmen von Compliance-Audits zu begutachten sind – so können wir Änderungen vermeiden, die unsere Audits gefährden –, und das Erstellen einer fortlaufenden Dokumentation, nach der die Auditoren fragen werden.

John sieht sich um und wundert sich, dass wir ihn alle geschockt anstarren. »Habe ich etwas Falsches gesagt?«

»Nichts für ungut, John ...«, sagt Wes langsam. »Aber ... ähm ... ist alles in Ordnung mit dir heute?« Ich sage: »John, ich glaube nicht, dass jemand aus meinem Team etwas an deinen Vorschlägen auszusetzen hat. Das sind großartige Ideen.« Wes und Patty nicken zustimmend.

Zufrieden fährt er fort: »Mein vierter Vorschlag ist, den Umfang unseres PCI-Compliance-Programms zu reduzieren, indem wir alles loswerden, was Kreditkartendaten speichert oder verarbeitet – denn das ist wie Giftmüll. Verliert man die Daten oder verarbeitet sie falsch, kann das tödlich sein, und der Schutz ist zu teuer.

Beginnen wir mit dem blöden POS-System in der Cafeteria. Für diesen Müll möchte ich nicht noch einmal ein Sicherheits-Review durchführen. Ehrlich gesagt, ist es mir auch egal, wer sich darum kümmert, selbst wenn es Sarahs Cousin Vinnie ist. Es muss weg.«

Patty hält die Hand vor ihrem Mund, und selbst Wes’ Kinnlade ist auf den Tisch gefallen. Hat John jetzt komplett den Verstand verloren? Dieser Vorschlag klingt ... potenziell waghalsig.

Wes denkt einen Moment nach, dann ändert er seine Meinung. »Genau! Ich wünschte, wir wären es schon vor Jahren losgeworden. Wir haben Monate damit verbracht, dieses System für die Audits abzusichern. Es geriet sogar in den Sog der SOX-404-Audits, weil es mit dem Payroll-System kommuniziert hat!«

Patty nickt schließlich auch. »Ich denke, keiner kann sagen, dass das Cafeteria-POS zu unserer Kernkompetenz gehört. Es hilft dem Business nicht, kann ihm aber definitiv schaden. Und es zieht wertvolle Ressourcen von Phoenix und unseren POS-Systemen in den Filialen ab, was beides definitiv zu unseren Kernkompetenzen zählt.« »Okay, John, machen wir es so. Vier von vier Leuten unterstützen das«, sage ich entschieden. »Aber glauben Sie wirklich, wir können es noch rechtzeitig loswerden?« »Jepp«, sagt John und lächelt zuversichtlich. »Ich habe schon mit Dick und der Rechtsabteilung gesprochen. Wir müssen nur noch einen passenden Outsourcer finden und uns davon überzeugen, dass er vertrauenswürdig genug ist, die Systeme und Daten zu verwalten und abzusichern. Wir können die Arbeit outsourcen, aber nicht die Verantwortung.« Wes wirft hoffnungsvoll ein: »Können Sie nicht auch noch irgendwas tun, damit Phoenix aus den Audits rausgehalten wird?«

»Nur über meine Leiche«, sagt John rundweg und verschränkt seine Arme. »Mein fünfter und letzter Vorschlag ist, alle technische Schuld in Phoenix zurückzuzahlen und dafür all die Zeit zu nutzen, die wir durch die anderen Vorschläge einsparen. Wir wissen, dass in Phoenix viele Risiken stecken: strategische Risiken, operative Risiken, hohe Sicherheitsanforderungen und Compliance-Risiken. So gut wie alle wichtigen Ziele von Dick hängen davon ab.

Wie Patty schon sagte – unsere Auftrags- und Lagerverwaltungssysteme sind eine Kernkompetenz. Wir verlassen uns auf sie, um gegenüber der Konkurrenz einen Vorsprung zu bekommen, aber mit all den schmutzigen Abkürzungen, die wir genommen haben, handelt es sich eher um ein Pulverfass, das nur darauf wartet, uns um die Ohren zu fliegen.«

Wes seufzt und sieht genervt aus. Sein Gesichtsausdruck sagt: Der schlechte alte John ist zurück.

Ich sehe das anders. Dieser John ist weitaus komplexer und nuancenreicher als der alte. Innerhalb weniger Minuten ist er einerseits gewillt, größere, fast unvernünftige Risiken einzugehen und unser Cafeteria-POS-System outzusourcen, und andererseits weiterhin auf jeden Fall darauf zu bestehen, Phoenix sicherer und stabiler zu machen.

Ich mag diesen neuen John.

»Sie haben absolut recht, John. Wir müssen die technische Schuld zurückzahlen«, sage ich unnachgiebig. »Wie sieht Ihr Vorschlag aus?«

Wir einigen uns schnell darauf, Kollegen aus Wes’ und Chris’ Gruppen und Kollegen aus Johns Team paarweise zusammenzustellen, sodass wir das Sicherheits-Know-how verbreiten können. Dadurch werden wir die Sicherheitsaspekte bald in unsere tägliche Arbeit einfließen lassen können und die Dinge nicht erst dann absichern, wenn sie ausgeliefert werden.

Johns Agenda scheint abgearbeitet zu sein, und er bedankt sich bei allen. Ich schaue auf die Uhr. Wir haben noch 30 Minuten übrig. Das muss ein neuer Weltrekord sein – so schnell haben wir uns noch nie auf irgendetwas Sicherheitsbezogenes geeinigt.

KAPITEL 28

Montag, 27. Oktober

Auf der Fahrt ins Büro muss ich die Sitzheizung anmachen – viel früher als sonst.

Ich hoffe, dass der Winter dieses Jahr nicht so schlimm werden wird wie letztes Jahr. Paiges Verwandte, die skeptischsten Menschen, die ich je getroffen habe, fragten sich schon, ob es wirklich so etwas wie eine globale Klimaerwärmung gibt.

Im Büro angekommen, nehme ich meinen Laptop aus der Tasche und freue mich darüber, wie schnell er startet. Als ich einen Bericht für Steve schreibe, in dem zusammengefasst ist, wie weit wir in den letzten sechs Wochen gekommen sind, erwähne ich meinen neuen Laptop nicht, auch wenn ich das gern würde.

Für mich steht der Laptop für alles, was mein Team gemeinsam erreicht hat. Ich bin unglaublich stolz auf die Leute. Das Leben ist jetzt ein anderes. Die Anzahl der Sev-1-Zwischenfälle ist in diesem Monat um mehr als zwei Drittel zurückgegangen. Und auch die Dauer der Zwischenfälle ließ sich verringern – ungefähr auf die Hälfte.

Die Einsichten, die wir aus diesem ersten seltsamen Meeting mit Dick und John gewonnen haben, zeigen, dass wir dem Verständnis, wie wir dem Business wirklich beim Siegen helfen können, dicht auf der Spur sind.

Ich öffne meine E-Mails und sehe eine Nachricht von Kirsten. Alle ihre Projektmanager schwärmen davon, wie viel besser die Projekte jetzt fließen. Die Anzahl der Aufgaben, die auf Brent und den Rest von IT Operations warten, ist deutlich nach unten gegangen. Wenn ich den Bericht richtig verstehe, ist Brent mit seiner Arbeit anscheinend kaum noch im Rückstand.

An der Projektfront stehen wir fantastisch da – insbesondere mit Phoenix.

Freitag soll es ein weiteres Phoenix-Deployment geben. Es geht nur um einen Haufen behobener Fehler ohne größere funktionale Änderungen, daher sollte es dieses Mal viel besser ablaufen als beim letzten Mal. Wir haben all unsere Aufgaben rechtzeitig abgeschlossen, aber wie üblich gibt es immer noch Millionen Details, an denen gearbeitet werden muss.

Ich bin dankbar, dass sich mein Team auf Phoenix konzentrieren kann, weil wir unsere Infrastruktur stabilisiert haben. Wenn die unvermeidbaren Ausfälle und Störungen auftreten, funktionieren wir wie eine gut geölte Maschine. Wir bauen eine Wissensdatenbank auf, die uns dabei hilft, die Probleme schneller als je zuvor zu beheben. Müssen wir doch eskalieren, geschieht dies kontrolliert und geordnet.

Aufgrund unseres immer weiter verbesserten Monitorings der Anwendungen und der produktiven Infrastruktur erfahren wir jetzt viel häufiger von Problemen, bevor das Business es tut.

Unser Projekt-Backlog ist deutlich reduziert – vor allem durch das Entfernen veralteter und unnötiger Projekte aus der Queue. Und John hat geliefert. Wir haben einen ganzen Haufen unnötiger Sicherheitsprojekte aus unserer Audit-Vorbereitung und den Nachbesserungsarbeiten geworfen und sie durch präventive Sicherheitsprojekte ersetzt, an denen mein gesamtes Team beteiligt ist. Durch Anpassungen an unseren Entwicklungs- und Deployment-Prozessen stabilisieren und sichern wir sowohl die Anwendungen als auch die produktive Infrastruktur auf vernünftige und systematische Art und Weise. Und wir gewinnen Vertrauen darin, dass diese Probleme in Zukunft nie wieder auftauchen werden.

Unsere Change-Management-Meetings laufen glatter und ordentlicher denn je ab. Wir haben nicht nur bessere Einblicke in das, was unsere Teams tun, sondern die Arbeit geht auch viel leichter von der Hand.

Mehr als zuvor wissen die Leute genau, woran sie arbeiten müssen. Sie freuen sich darüber, Dinge zu reparieren. Ich höre, dass die Kollegen glücklicher und optimistischer sind, weil sie tatsächlich ihre Arbeit machen können.

Seltsam, wie viel klarer ich die IT-Welt jetzt sehe und wie anders sie jetzt aussieht – verglichen mit der Zeit vor ein paar Monaten.

Pattys Experimente mit dem Einrichten von Kanbans rund um Brent sind ein großer Erfolg. Wir stolpern manchmal sogar über Aufgaben, die zurück an Brent gehen, weil wir die Schritte oder das Ergebnis nicht komplett verstanden oder spezifiziert haben. Der übersetzt es dann oder korrigiert es.

Wenn das passiert, klinken wir uns ein, um dafür zu sorgen, dass es nicht wieder geschieht.

Und wir verbessern nicht nur Brents Arbeit. Dadurch, dass wir die Anzahl der aktiven Projekte verringert haben, bleiben die Arbeitsabläufe übersichtlicher, und die Arbeiten können schneller von einer Arbeitsstation zur nächsten wandern, wodurch sie in Rekordzeit fertig werden.

Aus unserem Ticket-System haben wir völlig veraltete Einträge rausgeschmissen. Dabei sind wir sogar auf ein Ticket von Wes gestoßen, das er vor über zehn Jahren als Junior-Techniker angelegt hat und das sich auf eine Aufgabe für einen Rechner bezog, der schon lange abgebaut ist. Jetzt können wir sicher sein, dass alle Einträge in dem System wichtig sind und auch sehr wahrscheinlich erledigt werden können.

Wir sind nicht mehr länger das Bates-Motel für Arbeit.

Entgegen den Erwartungen meiner Mitarbeiter steigt die Anzahl an Projekten, die wir unserer Meinung nach gleichzeitig stemmen können. Weil wir besser wissen, wie unser Arbeitsfluss aussieht, und sorgfältig darauf achten, wann Brent einbezogen wird, merken wir, dass wir mehr Projekte angehen können, ohne unsere bestehenden Verpflichtungen zu vernachlässigen.

Ich glaube schon länger nicht mehr, dass Erik ein verrückter Irrer ist – exzentrisch bleibt er aber trotzdem. Nachdem ich die Ergebnisse mit meinen eigenen Augen und in meiner eigenen Organisation gesehen habe, weiß ich, dass die Arbeit in IT Operations doch der in der Fertigung sehr stark ähnelt. Erik hat allerdings wiederholt darauf hingewiesen, dass unsere bisherigen Verbesserungen nur die Spitze des Eisbergs wären.

Er meint auch, dass wir uns wirklich dem Meistern des Ersten Wegs nähern. Wir steuern die Übergabe von Fehlern an nachfolgende Arbeitsstationen, wir verwalten den Arbeitsfluss, geben das Tempo anhand unserer Beschränkungen vor und verstehen jetzt, basierend auf den Ergebnissen aus dem Audit und von Dick, besser denn je, was wichtig ist und was nicht.

Schließlich habe ich das Retrospektive-Meeting geleitet, in dem wir selbst geprüft haben, wie erfolgreich wir waren und wo wir uns noch verbessern können. Als jemand erwähnt, dass wir eigentlich Leute aus der Entwicklung zu unseren Post-mortem-Analyse-Meetings nach Ausfällen einladen sollten, erkenne ich, dass wir jetzt auch Eriks Dritten Weg besser verstehen.

Erik erinnert mich immer wieder daran, dass ein gutes Team am besten funktioniert, wenn es in Übung ist. Durch Übung entstehen Gewohnheiten, und Gewohnheiten führen dazu, dass man Prozesse oder Fertigkeiten besser meistert – seien es Fitnessübungen, Sport, Musizieren oder, wie in meiner Vergangenheit, die endlosen Drills bei den Marines. Wiederholung, besonders bei Dingen, für die Teamwork nötig ist, sorgt für Vertrauen und Transparenz.

Letzte Woche war ich sehr beeindruckt, als ich unsere zweiwöchentliche Ausfallübung begleitet habe. Darin werden wir richtig gut.

Ich bin ziemlich sicher: Wenn der Payroll-Ausfall von meinem ersten Arbeitstag als VP jetzt passieren würde, hätten wir den gesamten Payroll-Lauf problemlos durchbekommen.

John hat schnell die Genehmigung von Dick und Steve erhalten, einen Outsourcer für die Betreuung des Cafeteria-POS-Systems zu finden und es durch eine Lösung von der Stange zu ersetzen.

Für Wes, Patty und mich war es eine beeindruckende Übung, mit John zusammen die Anforderungen für den Outsourcer zusammenzustellen. Im Rahmen der Begutachtung potenzieller Kandidaten haben wir von allen Anbietern die Dogmen zu hören bekommen, an die wir selbst glaubten, bevor Erik dazukam. Es wird interessant sein, herauszufinden, ob wir sie umtrainieren können.

Ich habe das Gefühl, dass ein Managen der IT ohne die Drei Wege nur dann möglich ist, wenn man von gefährlich falschen Voraussetzungen ausgeht. Während ich darüber nachdenke, klingelt mein Telefon. Es ist John.

Als ich mich melde, sagt er: »Mein Team hat heute ein paar unerfreuliche Sachen entdeckt. Um zu verhindern, dass sich bei uns ein unerwünschter IT-Schwarzmarkt ausbreitet, haben wir damit begonnen, alle Projekte routinemäßig zu überprüfen, die bei Kirstens Projektmanagement-Büro vorbeikommen. Zudem haben wir die Firmenkreditkarten auf regelmäßig auftretende Ausgaben überprüft, die für Online- oder Cloud-Services stehen könnten, denn das ist nur eine andere Form unerlaubter IT. Manche umgehen also den Projekt-Freeze. Haben Sie ein paar Minuten Zeit?«

»Treffen wir uns in zehn Minuten«, sage ich. »Aber machen Sie es nicht so spannend. Wer versucht, sich am System vorbeizuschummeln?«

Am anderen Ende der Leitung lacht John laut auf. »Sarah. Wer sonst?«

Ich lade Wes und Patty zu dem spontanen Meeting mit ein, aber nur Patty hat Zeit dafür.

John präsentiert uns, was er herausgefunden hat. In Sarahs Gruppe werden an vier Stellen externe Firmen und Online-Services genutzt. Zwei sind recht harmlos, aber die beiden anderen sind kritischer: Sie hat eine Entwicklungsfirma für 200.000 Dollar beauftragt, in den Kundendaten Data-Mining zu betreiben, und eine andere Firma soll all unsere POS-Systeme anzapfen, um Verkaufsdaten für Kundenanalysen zu erhalten.

»Das erste Problem ist, dass beide Projekte die Datenschutzerklärungen verletzen, die wir gegenüber unseren Kunden abgegeben haben«, sagt John. »Wir versprechen immer wieder, dass wir die Daten nicht an andere herausgeben. Ob wir diese Erklärung anpassen oder nicht, ist natürlich eine Firmenentscheidung. Aber wie man es auch dreht und wendet – wenn wir mit der Data-Mining-Initiative so weitermachen, verstoßen wir gegen unsere eigene Richtlinie. Eventuell sind auch gesetzliche Regelungen im Spiel, an die wir uns halten müssen.«

Das klingt nicht gut, aber Johns Ton legt nahe, dass das Schlimmste noch kommt. »Das zweite Problem ist, dass die externe Firma die gleiche Datenbanktechnologie nutzt, die wir für unser Cafeteria-POS-System eingesetzt haben. Und von dem wissen wir, dass es nahezu unmöglich ist, es sauber abzusichern und es produktiv zu unterstützen, wenn es Teil der täglichen Arbeit wird.«

Ich fühle, wie der Ärger in mir aufsteigt. Es geht nicht nur um ein weiteres Cafeteria-POS-System, das wir für den produktiven Einsatz anpassen müssen. Es geht darum, dass solche Anwendungen zu den fehlerhaften Daten in den Auftrags- und Lagerverwaltungssystemen beitragen. Wir haben zu viele Köche am Brei und keinen, der für die Integrität der Daten verantwortlich ist.

»Mir ist egal, was für Tools Sarah für das Projektmanagement und die Rechnungsstellung nutzt – wenn sie dadurch produktiver wird, soll sie sie verwenden«, sage ich. »Vermutlich sind diese Tools sicher, solange sie nicht mit einem bestehenden Businesssystem verbunden werden, vertrauliche Daten speichern, die Finanzberichte beeinträchtigen oder was auch immer. Aber wenn das der Fall ist, müssen wir mit im Boot sein und zumindest bestätigen, dass keine unserer bestehenden Zusagen beeinflusst wird.«

»Ich stimme dem zu«, sagt John. »Soll ich mir mal das Dokument mit den Outsourcing-Richtlinien vornehmen?«

»Das wäre klasse«, sage ich. Etwas unsicherer fahre ich fort: »Aber wie gehen wir mit Sarah um? Ich habe das Gefühl, dass das nicht meine Kragenweite ist. Steve schirmt sie die ganze Zeit ab. Wie können wir ihn von dem potenziellen Chaos überzeugen, für das sie mit ihren nicht genehmigten Projekten sorgen wird?«

Ich prüfe, ob Johns Bürotür geschlossen ist, bevor ich zu John und Patty sage: »Ihr müsst mir da helfen. Was sieht Steve in ihr? Wie kann sie immer wieder mit der ganzen Scheiße davonkommen, die sie veranstaltet? In den letzten paar Wochen habe ich erlebt, wie rücksichtslos Steve sein kann, aber Sarah schafft es immer wieder, sich durchzumogeln. Wie macht sie das?«

Patty schnaubt. »Wenn Steve eine Frau wäre, würde ich sagen, sie wird von gefährlichen Männern angezogen. Darüber haben sich schon viele von uns den Kopf zerbrochen. Ich habe eine Theorie, die sich in unserem letzten Offsite-Meeting meiner Meinung nach bestätigt hat.«

Als sie sieht, dass John und ich uns konspirativ vorbeugen, lächelt sie. »Steve ist darauf stolz, ein operativer Typ zu sein, und er hat in Firmen-Meetings schon mehrfach zugegeben, keinen Sinn für Strategie zu haben. Ich glaube, das ist auch der Grund dafür, dass er so gerne mit unserem alten Chef und neuen Vorsitzenden Bob zusammengearbeitet hat. Ein ganzes Jahrzehnt war Bob der Stratege, und Steve musste nur die Vision ausführen.

Steve hat jetzt mehrere Jahre lang eine strategieorientierte Person als seine rechte Hand gesucht. Er hat einige Leute ausprobiert und sogar Führungskräfte gegeneinander antreten lassen. Ziemlich machiavellistisch, muss ich sagen«, fährt sie fort. »Und Sarah hat gewonnen. Die Gerüchteküche sagt, dass es ziemlich hinterhältige und heimliche Taktiken gab, aber ich vermute, das gehört einfach dazu, wenn man an die Spitze kommen will. Offensichtlich hat sie Steve aber die richtigen Dinge ins Ohr geflüstert und seine Paranoia und Sehnsüchte verstärkt.«

Pattys Erklärung ist viel ausgefeilter als alles, was ich mir überlegt hatte. Tatsächlich klingt es genauso passend wie Paiges Spekulationen, wenn ich beim Essen so abwesend bin.

John sagt unbehaglich: »Ähm, glaubst du nicht, dass irgendetwas zwischen den beiden läuft?«

Ich hebe die Augenbrauen. Das habe ich mich auch schon gefragt.

Patty bricht in schallendes Gelächter aus. »Ich habe eine ziemlich gute Menschenkenntnis. Sowohl mein Vater als auch meine Mutter sind Psychologen. Wenn das wahr wäre, würde ich deren Diplome fressen.«

Als sie unseren Gesichtsausdruck sieht, lacht sie noch lauter. »Schaut mal, selbst Wes glaubt das nicht, und der ist doch der Meister im Ausdenken von Verschwörungen. Sarah hat vor Steve eine Heidenangst! Ist euch noch nie aufgefallen, dass Sarah immer zu Steve schaut, wenn jemand spricht, um seine Reaktion abzuwarten? Eigentlich ganz schön schräg.«

Sie fährt fort: »Steve hat bezüglich Sarahs Fehlern einen blinden Fleck, weil sie etwas besitzt, was er braucht und bewundert, nämlich die Fähigkeit, kreative Strategien zu entwickeln. Ob die gut oder schlecht sind, ist erst einmal egal. Andererseits tut Sarah alles, um nicht schlecht dazustehen, weil sie so unsicher ist.

Sie kümmert sich einfach nicht um die Leichen, die ihren Weg pflastern, weil sie die nächste CEO von Parts Unlimited werden will. Und offensichtlich ist das auch Steves Plan. Er baut sie schon seit Jahren als seine Nachfolgerin auf.«

»Sie soll unsere nächste CEO werden? Ich halte das nicht für sehr wahrscheinlich, er durchschaut sie doch«, sage ich skeptisch.

»Oh Mann, Chef. Du treibst dich aber auch gar nicht in den Kaffee-Ecken herum, oder?«, sagt Patty.

Es ist Deployment-Tag für Phoenix, und ich habe Halloween mit meinen Kindern verpasst.

Mittlerweile zeigt die Uhr 23:40 an. Während wir uns wieder einmal um den Besprechungstisch im NOC versammeln, habe ich das beunruhigende Gefühl eines Déjà-vu. Ich zähle 15 Leute, einschließlich Chris und William.

Die meisten sind mit ihren Laptops beschäftigt, während überall Pizzaschachteln und leere Süßigkeitenverpackungen herumliegen. Andere stehen am Whiteboard und diskutieren über Checklisten oder Diagramme.

Es hat drei Stunden länger als geplant gedauert, Phoenix in die QA-Testumgebung zu migrieren und alle Tests zu bestehen. Auch wenn das viel besser läuft als bei dem früheren Deployment, dachte ich, wir würden weniger Probleme haben – angesichts dessen, wie hart wir daran gearbeitet haben, den Deployment-Prozess zu verbessern.

Um 21:30 konnten wir letztlich die Migration in die Produktivumgebung anstoßen. Alle Tests waren endlich grün, und Chris und William gaben ihr Okay. Wes, Patty und ich haben uns die Testberichte angeschaut und ebenfalls grünes Licht gegeben.

Dann war plötzlich die Hölle los.

Einer der kritischen Datenbankmigrationsschritte schlug fehl. Es waren erst 30 Prozent der Deployment-Schritte abgearbeitet, und wieder konnten wir nicht umkehren. Wegen der Datenbankänderungen und der schon laufenden Skripten war es unmöglich, in der Zeit bis zum Öffnen der Läden am nächsten Morgen alles wieder zurückzusetzen.

Und wieder müssen wir eine Bresche in den Dschungel schlagen und versuchen, zu den nächsten Schritten zu kommen, um das Deployment fortzusetzen.

Ich lehne mich gegen die Wand und beobachte die anderen mit verschränkten Armen, während ich versuche, mich zu beruhigen. Es ist frustrierend, dass wir schon wieder mit einem Phoenix-Deployment hadern, das möglicherweise erneut zu katastrophalen Ergebnissen führen wird.

Andererseits läuft es heute verglichen mit dem letzten Mal viel ruhiger ab. Es gibt zwar Spannungen und viele hitzige Diskussionen, aber jeder konzentriert sich darauf, die Probleme zu lösen. Wir haben schon alle Filialleiter über den Stand der Dinge informiert, und überall sind die manuellen Fallback-Prozeduren vorbereitet, falls die POS-Systeme immer noch nicht wieder laufen, wenn die Läden geöffnet werden.

Ich sehe, wie Wes etwas zu Brent sagt, aufsteht, sich müde die Stirn reibt und dann zu mir kommt. Chris und William stehen ebenfalls auf und kommen dazu.

Ich gehe ihnen entgegen. »Nun?«, frage ich.

»Nun«, sagt Wes, als er so nahe ist, dass ich ihn verstehe, obwohl er leise spricht. »Wir haben den Beweis gefunden. Eben haben wir erfahren, dass Brent vor ein paar Wochen eine Änderung an der produktiven Datenbank vorgenommen hat, um ein Business Intelligence-Modul von Phoenix zu unterstützen. Keiner wusste davon, geschweige denn, dass es dokumentiert wurde. Es steht einigen Änderungen an der Phoenix-Datenbank im Weg, daher müssen Chris’ Leute ein paar Codeänderungen vornehmen.«

»Scheiße«, sage ich. »Moment mal. Welches Phoenix-Modul?«

»Das ist eines von Sarahs Projekten, die angegangen wurden, nachdem der Projekt-Freeze aufgehoben wurde«, antwortet er. »Das war, bevor wir Brent hinter dem Kanban versteckt haben. Es ging um eine Änderung am Datenbankschema, die uns durch die Lappen gegangen ist.«

Ich fluche leise. Schon wieder Sarah?

Chris schaut verdrießlich drein. »Das wird knifflig. Wir müssen einen Haufen Datenbankspalten umbenennen, was möglicherweise Hunderte von Dateien betrifft. Und die ganzen Supportskripten. Das wird viel manuelle und fehleranfällige Arbeit.«

Er wendet sich an William. »Wie können wir wenigstens ein paar grundlegende Tests durchführen, bevor wir mit dem Deployment fortfahren?«

William sieht ein wenig krank aus und wischt sich den Schweiß von der Stirn. »Das ist sehr, sehr ... brenzlig ... Wir können testen, aber eventuell finden wir die Fehler erst, wenn wir genau diese Codezeilen erreichen. Wir werden also Fehler in der Produktivumgebung haben, bei denen die Anwendung einfach abraucht. Eventuell werden sogar die POS-Systeme in den Läden betroffen sein, was ziemlich übel wäre.«

Er schaut auf die Uhr. »Wir haben nur sechs Stunden, um damit fertig zu werden. Weil wir nicht genug Zeit haben, alle Tests nochmals laufen zu lassen, müssen wir ein paar Abkürzungen nehmen.«

In den nächsten zehn Minuten entwerfen wir einen überarbeiteten Zeitplan, der ebenfalls um 6 Uhr morgens fertig sein wird, sodass die Läden normal öffnen können und trotzdem noch eine Stunde Puffer da ist. Als Chris und William zu ihren Teams gehen, um sie zu informieren, bitte ich Wes, noch kurz zu bleiben.

»Wenn wir aus dem Gröbsten raus sind«, sage ich, »müssen wir uns überlegen, wie wir verhindern können, dass so etwas noch mal passiert. Es sollte auf keinen Fall vorkommen, dass die Dev- und QA-Umgebungen nicht der Produktivumgebung entsprechen.«

»Du hast recht«, sagt Wes und schüttelt ungläubig den Kopf. »Ich weiß nicht, wie wir das schaffen wollen. Aber du wirst auch keinen Widerspruch von mir hören.« Er dreht sich zu Brent um und sagt ungläubig: »Warum hängt Brent hier schon wieder mit drin?«

Viel später, als das Deployment abgeschlossen ist, gibt es Applaus. Ich schaue auf die Uhr. Es ist 5:42 am Samstagmorgen. Das Team hat wieder die ganze Nacht durchgearbeitet und das Deployment tatsächlich 20 Minuten vor dem Plan erledigt. Also – 20 Minuten vor dem Notfallzeitplan, den wir zusammengeschustert haben. Nach dem ursprünglichen Plan sind wir fast sechs Stunden zu spät.

William hat bestätigt, dass die Test-POS-Systeme laufen, genauso wie die E-Commerce-Website und alle zugehörigen Phoenix-Module.

Patty hat damit begonnen, die Filialleiter zu benachrichtigen, dass das Deployment »erfolgreich« war. Sie hängt jeweils eine Liste mit bekannten Fehlern an, auf die man achten sollte, eine interne Webseite, auf der der aktuellste Status von Phoenix zu sehen ist, sowie Anweisungen, wie neue Probleme gemeldet werden können. Alle Service-Desk-Mitarbeiter bleiben zunächst vor Ort, und sowohl Chris’ Teams als auch meine haben Bereitschaft, um kurzfristig Probleme lösen zu können. Im Prinzip bleiben wir alle verfügbar, um das Business zu unterstützen.

Während sich Wes und Patty um die Bereitschaftsplanung kümmern, bedanke ich mich bei allen für ihre gute Arbeit und suche meine Sachen zusammen. Auf dem Weg nach Hause zerbreche ich mir den Kopf darüber, wie wir dafür sorgen können, dass nicht jedes Phoenix-Deployment zu einem Notfall wird.

KAPITEL 29

Montag, 3. November

Am folgenden Montag um 7:10 sitzen Chris, Wes, Patty und John wieder zusammen mit mir im Vorstandsbesprechungsraum. Während wir auf Steve warten, reden wir über die Auswirkungen der zweiten Phoenix-Auslieferung.

Erik sitzt weiter hinten im Raum. Vor sich hat er eine Schüssel, eine leere Packung Instant-Haferbrei und eine Kaffeepresse voll mit grünlichem Wasser und darin schwimmenden Blättern stehen.

Als er meinen fragenden Gesichtsausdruck sieht, sagt er: »Yerba Mate. Mein Lieblingsgetränk aus Südamerika. Ich bin nie ohne es unterwegs.«

Steve kommt zur Tür herein mit dem Handy am Ohr. »Hören Sie zu, Ron, zum letzten Mal: Nein! Keine weiteren Rabatte – selbst wenn er unser letzter Kunde wäre. Wir müssen irgendwo eine Grenze ziehen. Verstanden?«

Er legt genervt auf, setzt sich an die Kopfseite des Tischs und brummelt: »Entschuldigung, ich bin zu spät.« Dann schlägt er seine Mappe auf und liest sich etwas darin durch.

»Unabhängig davon, wie das Phoenix-Deployment am Wochenende lief, bin ich außerordentlich stolz auf das, was Sie in den letzten paar Wochen erreicht haben. Viele Leute haben mir erzählt, wie begeistert sie von der IT sind, selbst Dick«, sagt er skeptisch. »Er hat mir berichtet, wie Sie ihm dabei helfen, unsere wichtigsten Firmenziele zu erreichen, und er glaubt, dass dies das Blatt wenden wird.«

Er lächelt. »Ich bin sehr stolz darauf, ein Teil dieses Teams zu sein, das offensichtlich besser denn je zusammenarbeitet, einander vertraut und unglaubliche Ergebnisse erzielt.«

Dann wendet er sich John zu. »Dick hat mir übrigens auch erzählt, dass sie es mit Ihrer Hilfe geschafft haben, dass die Korrektur des Finanzberichts keine rechtlichen Folgen haben wird.« Er grinst und sagt: »Gott sei Dank. Ich hätte mich ungern auf dem Titelbild des Fortune-Magazins gesehen – mit Handschellen.«

Gerade da klopft Sarah an die Tür und betritt den Raum.

»Guten Morgen, Steve«, sagt sie, während sie steif durch den Raum geht und sich neben Erik setzt. »Sie wollen mich wegen meiner neuen Marketinginitiativen sprechen?«

»Sie meinen die nicht genehmigten Arbeitsschichten, die Sie von der IT-Fabrik ausführen lassen – wie ein skrupelloser chinesischer Fabrikmanager?«, fragt Erik. Sarah sieht Erik von oben bis unten an. Offensichtlich versucht sie, ihn einzuschätzen.

Steve nickt John zu, damit der seine Erkenntnisse vorstellt. Als er fertig ist, sagt Steve ernst: »Sarah, ich hatte eine deutliche Anweisung erteilt. Niemand darf neue IT-Initiativen starten – egal ob extern oder intern – ohne meine explizite Erlaubnis. Erklären Sie sich bitte.«

Sarah nimmt sich ihr iPhone und tippt ärgerlich für kurze Zeit darauf herum. Dann legt sie es wieder hin und sagt: »Unsere Konkurrenten treten uns dauernd in den Hintern. Wir brauchen jeden möglichen Vorteil. Um die von Ihnen gesetzten Ziele zu erreichen, kann ich nicht auf IT warten. Ich bin sicher, sie arbeiten sehr hart und tun mit den verfügbaren Ressourcen ihr Bestes – aber das reicht nicht. Wir müssen schnell sein, und manchmal müssen wir dazukaufen, statt selbst zu entwickeln.«

Wes verdreht die Augen.

Ich antworte: »Ich weiß, dass IT in der Vergangenheit nicht immer liefern konnte, was Sie brauchten, und ich weiß auch, dass Marketing und Sales echt zu kämpfen hatten. Aber das Problem ist, dass einige Ihrer kreativen Initiativen andere wichtige Firmenziele in Gefahr bringen, wie zum Beispiel, Gesetze und Vorschriften zum Datenschutz zu befolgen, aber auch die Notwendigkeit, sich auf Phoenix zu konzentrieren.

Das, was Sie beabsichtigen, könnte in unseren Auftrags- und Lagerverwaltungssystemen zu zusätzlichen Problemen mit der Datenintegrität führen. Dick, Ron und Maggie haben deutlich gemacht, dass wir diese Daten aufräumen müssen und sie dann auch aufgeräumt zu halten haben. Nichts ist wichtiger, als die Bedürfnisse der Kunden zu verstehen, das richtige Produktportfolio zu haben, unsere Kunden zu halten und letztendlich unseren Umsatz und den Marktanteil zu erhöhen.«

Ich ergänze: »Die Projekte von Ihnen zu unterstützen, würde zudem sehr viel zusätzliche Arbeit bedeuten. Wir müssten den externen Firmen Zugriff auf unsere produktiven Datenbanken erteilen, ihnen erklären, wie wir sie aufgesetzt haben, einen Haufen Firewall-Änderungen vornehmen und vermutlich noch hundert weitere Dinge erledigen. Es reicht nicht, einfach nur eine Rechnung zu bestätigen.«

Sie sieht mich vernichtend an. So wütend habe ich sie noch nie gesehen.

Ganz offensichtlich findet sie es nicht toll, dass ich Dicks Firmenziele zitiere und damit ihre Pläne ablehne.

Ich glaube, ich habe mir gerade eine gefährliche Feindin gemacht.

An alle gerichtet, sagt sie: »Da Bill das Business so viel besser zu verstehen scheint als ich – warum erzählt er uns dann nicht, wie seine Vorschläge aussehen?«

»Sarah, keiner versteht besser, was Ihr Geschäftsbereich braucht, als Sie. Sie dürfen gerne externe Firmen einsetzen, um diese Bedürfnisse zu erfüllen, wenn wir selbst dazu nicht in der Lage sind. Aber nur, wenn wir das so entscheiden, weil wir verstanden haben, wie das andere Teile der Firma in Gefahr bringen kann«, sage ich so vernünftig wie möglich. »Wie wäre es, wenn Sie, Chris und ich uns regelmäßig treffen, um herauszufinden, wie wir Ihnen mit Ihren anstehenden Initiativen helfen können?«

»Ich bin sehr beschäftigt«, sagt sie. »Ich kann nicht einen ganzen Tag in Meetings mit Ihnen und Chris verbringen. Denn schließlich habe ich einen ganzen Bereich zu leiten.«

Zu meiner Erleichterung mischt sich Steve ein. »Sarah, Sie werden sich diese Zeit nehmen. Ich erwarte, von Ihnen zu erfahren, was bei diesen Meetings herauskommt und wie Sie das mit Ihren beiden nicht genehmigten IT-Initiativen lösen. Haben Sie mich verstanden?«

Verärgert antwortet sie: »Ja. Ich versuche nur, das Beste für Parts Unlimited zu erreichen. Ich werde tun, was ich kann, aber ich sehe die Ergebnisse nicht sehr optimistisch. Sie binden mir hier wirklich die Hände.«

Sarah steht auf. »Ach übrigens, ich hatte gestern eine Unterhaltung mit Bob Strauss. Ich glaube nicht, dass Ihr Spielraum so groß ist, wie Sie denken. Bob sagt, wir müssen uns strategische Optionen anschauen, zum Beispiel das Aufteilen der Firma. Meiner Meinung nach hat er recht.«

Als sie geht und die Tür hinter sich zuknallt, sagt Erik ironisch: »Nun, ich bin sicher, dass wir von ihr nichts mehr hören werden ...«

Steve starrt einen Moment auf die Tür, dann richtet er sich mich. »Wenden wir uns nun dem letzten Punkt der heutigen Agenda zu. Bill, Sie haben Sorgen, dass wir bei Phoenix den falschen Weg eingeschlagen haben – nicht nur, dass die Dinge schlimmer werden können, sondern auch, dass wir niemals die gewünschten Businessergebnisse erhalten werden. Das ist außerordentlich beunruhigend.«

Ich zucke mit den Schultern. »Sie wissen alles, was auch ich weiß. Ich hatte tatsächlich gehofft, Erik könnte uns ein paar Einsichten geben.«

Erik sieht auf und wischt sich seinen Schnurrbart mit einer Serviette ab. »Einsichten? Meiner Meinung nach ist die Antwort auf Ihre Probleme offensichtlich. Beim Ersten Weg geht es darum, den Arbeitsfluss von der Entwicklung nach IT Operations zu steuern. Sie haben ihn verbessert, indem Sie einen Projekt-Freeze verhängten und die Projekte danach kontrolliert angestoßen haben. Aber Ihre Batch-Größen sind immer noch viel zu umfangreich. Die Deployment-Probleme am Freitag sind ein Beweis dafür. Es sind zudem viel zu viele WIPs in der Fertigung gefangen – und dann auch noch welche von der schlimmsten Art. Ihre Deployments verursachen ungeplante Arbeit an den Folgestationen.«

Er fährt fort: »Jetzt müssen Sie zeigen, dass Sie den Zweiten Weg beherrschen, indem Sie dauerhafte Feedback-Schleifen von IT Operations zurück an die Entwicklung einrichten und das Produkt auf diese Weise von Anfang an qualitativ so gut wie möglich entwerfen. Dazu können Sie keine Release-Zyklen von neun Monaten nutzen. Das Feedback muss viel früher kommen.

Sie werden die Ziele nie erreichen, wenn Sie nur einmal in neun Monaten einen Schuss abgeben. Denken Sie nicht mehr an Kanonen zu Bürgerkriegszeiten. Denken Sie an Flakgeschütze.«

Erik steht auf, um seine Haferschleimschüssel in den Abfalleimer zu werfen. Dann späht er wieder hinein und fischt seinen Löffel heraus.

Schließlich dreht er sich um und sagt: »In jedem Arbeitssystem ist das theoretische Ideal ein Single Piece Flow, durch das der Durchsatz maximiert und die Varianz minimiert wird. Das erreichen Sie, indem Sie kontinuierlich die Batch-Größen reduzieren.

Sie machen genau das Gegenteil, wenn Sie die Release-Zyklen von Phoenix vergrößern und die Anzahl der Features pro Release erhöhen. Sie haben sogar die Fähigkeit verloren, die Varianz von einem Release zum nächsten zu steuern.« Er macht eine Pause. »Das ist wahnsinnig angesichts der Investitionen, die Sie in das Virtualisieren Ihrer Produktivsysteme gesteckt haben. Ihre Deployments laufen immer noch so ab, als hätten Sie echte Server. Goldratt würde sagen, dass Sie eine erstaunliche Technologie ausgeliefert haben, aber weil Sie Ihre Arbeitsweise nicht geändert haben, haben Sie tatsächlich keinen Engpass beseitigt.«

Ich schaue mich um und sehe mich darin bestätigt, dass niemand versteht, worüber Erik gerade spricht. Ich sage: »Das letzte Phoenix-Release hatte Probleme wegen einer Änderung am produktiven Datenbankserver, die nicht in die Entwicklungs- und QA-Systeme repliziert wurde. Ich würde Chris zustimmen: Wir sollten mit weiteren Auslieferungen warten, bis uns klar ist, wie wir all die Umgebungen synchronisiert halten können. Das bedeutet doch, dass wir die Releases langsamer ausliefern, oder?«

Erik schnaubt. »Bill, das ist zugleich eines der klügsten Dinge, das ich in letzter Zeit gehört habe – und eines der dümmsten.«

Ich reagiere nicht, während Erik sich eine der Zeichnungen an der Wand anschaut. Er zeigt darauf und sagt: »Wilbur, was für ein Motor ist das?«

Wes schneidet eine Grimasse und sagt: »Das ist ein 1300cc-Motor für ein Motorrad, die 2007 Suzuki Hayabusa Dragster. Und ich heiße übrigens ›Wes‹, nicht ›Wilbur‹. Ich habe meinen Namen nicht geändert.«

»Natürlich«, antwortet Erik. »Dragster-Motorräder sind nett anzuschauen. Das hier wird vermutlich über 370 Kilometer pro Stunde schaffen. Wie viele Gänge hat diese Rennmaschine?«

Ohne überlegen zu müssen, antwortet Wes: »Sechs. Aphongetriebe mit einem 532er-Kettenantrieb.«

»Besitzt sie einen Rückwärtsgang?«, fragt Erik.

»Dieses Modell hat keinen Rückwärtsgang«, weiß Wes.

Erik nickt, während er sich die Zeichnung genauer anschaut. Dann sagt er: »Interessant, oder? Kein Rückwärtsgang. Warum sollte dann Ihr Arbeitsfluss einen Rückwärtsgang haben?«

Die Stille hält an, bis Steve schließlich sagt: »Erik, können Sie nicht einfach sagen, was Sie denken? Für Sie mag das ein nettes Spielchen sein, aber wir müssen eine Firma retten.«

Erik sieht Steve ins Gesicht. »Denken Sie wie ein Betriebsleiter. Wenn Sie sehen, dass Arbeit zurückwandert, was bedeutet das für Sie?«

Steve antwortet schnell: »Der Arbeitsfluss sollte idealerweise immer nur nach vorne gerichtet sein. Wenn ich sehe, dass Arbeit zurückfließt, denke ich: ›Verschwendung‹. Das kann an Fehlern liegen, an fehlenden Spezifikationen oder an der Notwendigkeit, etwas zu überarbeiten ... Aber egal, woran es liegt – wir sollten es beheben.«

Erik nickt. »Ausgezeichnet. Das ist auch meine Meinung.«

Er nimmt sich seine leere Kaffeepresse und den Löffel vom Tisch, legt beides in seinen Koffer und beginnt, ihn zu verschließen. »Der Arbeitsfluss geht immer nur in eine Richtung: nach vorne. Erzeugen Sie ein Arbeitssystem in IT, in dem das auch gilt. Denken Sie daran, das Ziel ist Single Piece Flow.«

Er wendet sich mir zu. »Im Übrigen löst das auch das Problem, an dem Sie mit Dick sitzen. Eine zwangsläufige Konsequenz langer Release-Zyklen ist, dass Sie nie die interne Mindestrendite erreichen werden, wenn Sie die Arbeitskosten mit einbeziehen. Sie brauchen kürzere Zyklen. Wenn Phoenix Sie davon abhält, überlegen Sie sich, wie Sie die Features anders ausliefern können.

Natürlich ohne sich so zu verhalten wie Sarah«, sagt er lächelnd. Er nimmt seinen Koffer und fügt noch hinzu: »Dazu müssen Sie Brent an vorderste Front stellen, so wie Herbie in Das Ziel. Brent muss so früh wie möglich am Entwicklungsprozess beteiligt werden. Bill, Sie sollten das noch am ehesten hinbekommen.

Viel Glück, Leute«, sagt er, und wir sehen alle zu, wie er die Tür hinter sich schließt.

Schließlich sagt Steve: »Hat jemand Vorschläge?«

Chris antwortet als Erster. »Wie schon gesagt: Selbst kleinere Phoenix-Releases zum Beheben von Fehlern sind so problematisch, dass wir es uns nicht erlauben können, sie monatlich durchzuführen. Egal was Erik sagt, ich denke, wir müssen unsere Releases langsamer angehen. Ich schlage vor, alle zwei Monate ein Release herauszubringen.«

»Das ist nicht akzeptabel«, sagt Steve und schüttelt den Kopf. »Letztes Quartal haben wir so gut wie jedes gesetzte Ziel weit verfehlt. Das wird unser fünftes Quartal in Folge sein, in dem wir die Ziele nicht erreicht haben – und dabei haben wir schon unsere Prognosen an der Wall Street reduziert. Alle unsere Hoffnungen liegen darin, Phoenix fertigzubekommen. Sie erzählen mir, dass wir sogar noch länger auf die benötigten Features warten müssen, während unsere Konkurrenz uns immer weiter davonzieht? Unmöglich.«

»Für Sie mag es ›unmöglich‹ sein, aber betrachten Sie es aus meiner Perspektive«, sagt Chris ruhig. »Meine Entwickler müssen neue Features bauen. Sie können nicht die ganze Zeit mit Bills Team zusammenhängen und sich um Deployment-Probleme kümmern.«

Steve antwortet: »Dieses Quartal ist entscheidend. Wir haben der Welt versprochen, dass wir Phoenix im letzten Monat herausbringen würden, aber aufgrund der ganzen verschobenen Features können wir nicht die Vorteile daraus ziehen, auf die wir gehofft haben. Jetzt ist das neue Quartal schon einen Monat alt, und die Weihnachtssaison beginnt in weniger als 30 Tagen. Uns läuft die Zeit davon.«

Ich denke darüber nach und zwinge mich dazu, zu akzeptieren, dass Chris seine Realität darstellt, die auf Fakten basiert. Das Gleiche gilt aber auch für Steve.

Ich sage zu Chris: »Wenn du sagst, dass das Phoenix-Team langsamer machen muss, will ich da nicht widersprechen. Wenn bei den Marines in einer Kompanie von 100 Mann einer verwundet ist, verliert man als Erstes die Mobilität.

Aber wir müssen trotzdem herausfinden, wie wir das erreichen, was Steve benötigt«, fahre ich fort. »Wie Erik gesagt hat: Wenn wir das nicht innerhalb des Phoenix-Frameworks erreichen können, schaffen wir es vielleicht außerhalb von Phoenix. Ich schlage vor, wir bilden ein SWAT-Team mit einer Handvoll Leuten aus dem Phoenix-Team. Die sollen sich überlegen, welche Features uns dabei helfen können, unsere Umsatzziele so schnell wie möglich zu erreichen. Wir haben nicht viel Zeit, daher müssen wir die Features sorgfältig auswählen. Wir werden ihnen erlauben, wenn nötig alle Regeln zu brechen, um ihre Aufgaben zu erledigen.«

Chris denkt einen Moment darüber nach und nickt schließlich. »Bei Phoenix geht es darum, den Kunden zu helfen, Artikel bei uns zu kaufen – mehr und schneller. Mit den letzten beiden Releases haben wir die Grundlagen dafür gelegt, aber die Features, die die Verkäufe wirklich ankurbeln sollen, hängen immer noch in der Warteschleife. Wir müssen uns darauf konzentrieren, gute Kundenempfehlungen zu erzeugen, und es dem Marketing ermöglichen, Werbeaktionen zu starten, um profitable Produkte aus unseren Lagerbeständen zu verkaufen.«

»Wir haben Jahre an Auftragsdaten, und aufgrund unserer gebrandeten Kreditkarten kennen wir die Demografie und Vorlieben unserer Kunden«, wirft Steve ein, während er sich vorbeugt. »Das Marketing hat mir versichert, dass wir unseren Kunden ein paar wirklich unwiderstehliche Angebote machen können, wenn wir diese Features bloß ausgeliefert bekämen.«

Chris, Wes und Patty beteiligen sich an der folgenden Diskussion, während John noch skeptisch dreinblickt. Schließlich sagt Wes: »Wisst ihr, das könnte glatt funktionieren.« Als alle – einschließlich John – nicken, meine ich, dass es ein Gefühl der Begeisterung und Machbarkeit gibt, das vor ein paar Minuten noch nicht da war.

Teil 3

KAPITEL 30

Montag, 3. November

Eine Stunde nach dem Meeting mit Steve grüble ich immer noch über Eriks kryptische Kommentare. Ich habe das Gefühl, wir sind etwas wirklich Großem auf der Spur, aber ich habe zu viele Fragen. Schließlich entscheide ich mich dazu, ihn anzurufen.

»Ja?«, meldet er sich.

»Ich bin es, Bill«, sage ich. »Ich bräuchte noch ein paar Tipps dazu, was zum Henker wir eigentlich tun sollen ...«

»Kommen Sie vor das Gebäude«, sagt er und legt auf.

Als ich nach draußen komme, ist es windig und kühl. Ich schaue mich gerade suchend um, als ich jemanden hupen höre. Erik sitzt in einem teuer aussehenden roten BMW-Cabrio, das Verdeck heruntergeklappt. »Steigen Sie ein, schnell!« »Nette Kiste«, sage ich und klettere auf den Beifahrersitz.

»Danke sehr«, sagt Erik. »Mein Freund hat darauf bestanden, dass ich mir den Wagen ausleihe, solange ich in der Stadt bin.«

Als er das Gaspedal durchtritt, halte ich mich an der Armlehne fest und beeile mich mit dem Anschnallen. Auf dem Boden liegt eine Geldbörse, und ich frage mich plötzlich, wer dieser »Freund« ist.

»Wir fahren wieder zu MRP-8«, sagt er.

Als ich ihn bitte, das Verdeck wieder zuzuklappen, schaut er mich an und sagt: »Ich dachte, es würde gelten: ›Einmal Marine, immer Marine.‹ Vielleicht seid ihr Jungs doch nicht mehr so hart wie zu meiner Zeit.«

»Sie waren in der Armee?«, frage ich, während ich versuche, meine Zähne nicht allzu laut klappern zu lassen. Er lacht. »Über 20 Jahre.«

»Ich vermute, Sie waren zum Schluss Offizier?«, frage ich.

»Major, Special Forces, US Army«, antwortet er und schaut mich an. Ich wünschte mir eher, er möge seinen Blick der Straße zuwenden angesichts der Geschwindigkeit, mit der wir unterwegs sind. Stattdessen fährt er fort: »Der gleiche Bereich wie Steve, aber er fing schon als Offizier an. Ich war dagegen ein einfacher Soldat, so wie Sie.«

Er sagt nichts weiter, aber ich weiß jetzt genug, um seine militärische Karriere zu verstehen. Offensichtlich war er mindestens ein Gunnery Sergeant, mit denen ich in meiner aktiven Zeit viel zu tun hatte. Jetzt erkenne ich auch das allzu vertraute Auftreten und die Körperhaltung wieder. Er muss von den höheren Dienstgraden als einer dieser wenigen High-Potentials erkannt worden sein, die dann entschieden, in seine Zukunft zu investieren. Er ging zum College und zur Officer Candidate School, dann kehrte er als Second Lieutenant zur Truppe zurück – wo er vermutlich zehn Jahre älter war als alle anderen.

Man muss schon etwas Besonderes sein, um das durchzustehen.

Wir sind in Rekordzeit an der Fertigungshalle und stehen nun auf dem Laufsteg. Er beginnt mit der Rede, die ich erwartet habe. »Eine Fertigungshalle ist ein System. Die Rohmaterialien beginnen an der einen Seite, und ein ganzer Haufen Dinge muss in der richtigen Reihenfolge geschehen, damit auf der anderen Seite die fertigen Produkte pünktlich verladen werden können. Alles arbeitet zusammen. Wenn sich eine Arbeitsstation mit den anderen beharkt, insbesondere wenn die Herstellung mit der Entwicklung streitet, kommt man nur zentimeterweise voran.«

Erik wendet sich mir zu und zeigt auf mich. »Sie müssen damit aufhören, wie der Vorarbeiter einer Arbeitsstation zu denken. Denken Sie größer – wie ein Betriebsleiter oder, besser noch, wie die Person, die diese Fertigungshalle und alle Prozesse, die darin laufen, entworfen hat. Diese Person schaut sich den gesamten Arbeitsablauf an, erkennt, wo die Grenzen liegen, und nutzt jede mögliche Technologie und das Wissen über die Prozesse, um sicherzustellen, dass die Arbeit effektiv und effizient abläuft. Sie stärkt ihren ›inneren Allspaw‹.«

Ich will gerade fragen, was er mit einem »Allspaw« meint, als er meine Frage einfach beiseite wischt. »In der Fertigung haben wir eine Maßeinheit namens Taktzeit. Das ist die Zeit, die benötigt wird, um mit den Kundenanforderungen mitzuhalten. Wenn ein Vorgang im Arbeitsfluss mehr als die Taktzeit benötigt, werden Sie die Anforderungen nicht erfüllen können.

Wenn Sie also herumlaufen und ›Oh nein! Die Umgebungen für Phoenix sind nicht fertig! Hilfe! Oh, nein! Wir können nicht deployen, weil irgendjemand wieder die Phoenix-Umgebungen kaputt gemacht hat!‹ schreien«, sagt er mit hoher Stimme, »bedeutet das, dass der Zeitbedarf für einen wichtigen Vorgang in Ihrem Verantwortungsbereich größer ist als die Taktzeit. Das ist der Grund, warum Sie die Kundenanforderungen nicht erfüllen können.

Als Teil des Zweiten Wegs müssen Sie eine Feedback-Schleife einrichten, die bis zu den frühesten Elementen der Produktdefinition, dem Design und der Entwicklung reicht«, sagt er. »Angesichts der Gespräche, die Sie mit Dick hatten, sollte es sogar möglich sein, noch früher im Prozess einzusteigen.«

Er zeigt auf die Fertigungshalle und sagt: »Schauen Sie sich die langen Bahnen mit Geräten zwischen dem orangefarbenen Klebeband auf dem Boden an. In diesen Bahnen entstehen einige der Produkte mit dem größten Profit, die wir haben. Aber wie es das Schicksal so will, gehören zu diesem Arbeitsfluss zwei Schritte, die die längsten Rüst- und Prozesszeiten haben: das Auftragen eines Pulverlacks und das Brennen im Härtungsofen.«

Er hat die Arme weit ausgebreitet und sieht mich an. »Damals war der Zeitbedarf für diese beiden Schritte viel größer als die Taktzeit, und wir konnten die Kundenwünsche nicht erfüllen. Wie kann das Leben nur so unfair sein? Die profitabelsten Produkte benötigten unsere beiden Engpässe: den Härtungsofen und die Trockenkabinen! Was sollten wir also tun?

Die Kunden haben uns mit Geld beworfen, damit wir mehr von diesen Produkten herstellen, aber wir mussten sie wegschicken. Die Rüstzeit für jeden Schritt betrug Stunden oder gar Tage. Wir mussten riesige Batch-Größen nutzen, um die Anforderungen zu erfüllen. Die Farbe wurde auf riesigen Gestellen aufgebracht, und wir brannten so viele Einheiten gleichzeitig wie möglich. Wir wussten, dass wir die Batch-Größe verringern mussten, um den Durchsatz erhöhen zu können, aber jeder sagte, dass das nicht möglich wäre.

Wie Toyota dieses Problem gelöst hat, ist legendär«, sagt Erik. »In den 1950ern hatten sie einen Stanze für die Motorhauben, deren Wechselzeit fast drei Tage betrug. Es mussten riesige, schwere Pressen bewegt werden, die mehrere Tonnen wogen. Wie bei uns waren die Rüstzeiten so lang, dass sie große Batch-Größen nutzen mussten, wodurch sie mit der Stanze Motorhauben für mehrere Automodelle nicht gleichzeitig fertigen konnten. Sie können keine Haube für einen Prius und dann für einen Camry herstellen, wenn Sie drei Tage für den Werkzeugwechsel brauchen, oder?

Was haben sie also getan?«, fragt er rhetorisch. »Sie haben sich alle Schritte genau angeschaut, die für den Wechsel notwendig waren, und dann eine Reihe von Anpassungen und Verbesserungen vorgenommen, die die Wechselzeit auf unter zehn Minuten gesenkt hat. Und da kommt auch der legendäre Begriff ›Single Minute Exchange of Die‹ her.

Wir haben uns alle die Arbeiten von Ohno, Spear und Rother angeschaut. Wir wussten, dass wir unsere Batch-Größen verringern mussten, aber wir hatten es nicht mit Stanzen für Motorhauben zu tun. Bei uns ging es um Lackieren und Härten«, fährt er fort. »Nach Wochen des Brainstormens, Untersuchens und Experimentierens zusammen mit den Ingenieuren hatten wir eine verrückte Idee: Vielleicht könnten wir das Lackieren und Härten in einer einzelnen Maschine zusammenfassen. Wir schusterten einen Ofen zusammen, der auch das Farbpulver auf die Teile auftrug. Die wurden von einer Kette und einem Zahnrad durchgezogen, die wir von einem Fahrrad abgebaut hatten.

Wir haben vier Arbeitsstationen in einer zusammengefasst, über 30 manuelle, fehleranfällige Schritte ausgemerzt, den Arbeitsablauf vollständig automatisiert, einen Single Piece Flow erreicht und die gesamte Rüstzeit eliminiert. Der Durchsatz ging damit durch die Decke.

Die Vorteile waren enorm«, sagt er stolz. »Erstens konnten wir Defekte direkt an dem einen kaputten Teil beheben, statt auch alle anderen Teile des Batchs ausrangieren zu müssen. Zweitens ging die WIP nach unten, weil an keiner Arbeitsstation mehr zu viele Produkte hergestellt wurden, die dann nur in der Warteschlange vor der nächsten Arbeitsstation herumgammelten. Am wichtigsten aber war, dass die Auftragsdurchlaufzeit von einem Monat auf weniger als eine Woche eingedampft wurde. Egal was der Kunde wollte – und wie viel er davon wollte –, wir konnten es bauen, ohne unser Lager mit Dingen vollzustellen, die wir dann später zu Spottpreisen abverkaufen mussten.

Jetzt sind Sie dran«, sagt Erik ernst und tippt mir auf die Brust. »Sie müssen sich überlegen, wie Sie Ihre Wechselzeiten reduzieren und kürzere Deployment-Zyklen erreichen.

Ich denke, Ihr Ziel sollten ...«, sagt er und denkt einen Moment nach, »zehn Deployments pro Tag sein. Warum nicht?«

Mir fällt die Kinnlade herunter. »Das ist unmöglich.«

»Wirklich?«, sagt er ausdruckslos. »Ich will Ihnen eine Geschichte erzählen. 2009 war ich Vorstandsvorsitzender einer Technologie-Firma, als einer unserer Entwickler zur Velocity Conference ging und als verrückter Irrer zurückkam, seinen Kopf voll mit gefährlichen, unmöglichen Ideen. Er hatte eine Präsentation von John Allspaw und seinem Kollegen Paul Hammond gesehen, die sein Weltbild auf den Kopf stellte. Allspaw und Hammond waren die Leiter der IT Operations- und Engineering-Gruppen bei Flickr. Statt sich die ganze Zeit nur zu bekämpfen, sprachen sie darüber, wie sie zusammenarbeiteten, um regelmäßig zehn Deployments pro Tag durchzuführen! Und das in einer Welt, in der die meisten IT-Organisationen jährliche oder höchstens vierteljährliche Deployments durchführten. Stellen Sie sich das einmal vor. Bei Flickr gab es Deployments mit einer tausendmal höheren Rate, als bisher üblich war.«

»Glauben Sie mir«, fährt er fort, »wir dachten alle, dass dieser Entwickler verrückt geworden wäre. Aber ich lernte, dass die Praktiken, die Allspaw und Hammond gemeinsam anwendeten, das zwangsläufige Ergebnis ist, wenn man die Drei Wege auf die IT-Wertkette anwendet. Das hat unser Vorgehen beim IT-Management total verändert und letztendlich unsere Firma gerettet.«

»Wie haben sie das gemacht«, frage ich verblüfft.

»Gute Frage«, entgegnet er. »Allspaw hat uns gelehrt, dass eine Zusammenarbeit von Dev und Ops mit QA und dem Business zu einem Team führt, das erstaunliche Dinge erreichen kann. Er wusste auch, dass erst dann Wert erzeugt wird, wenn der Code produktiv ist, denn zuvor handelt es sich nur um WIP, die im System feststeckt. Allspaw reduzierte die Batch-Größe und ermöglichte so einen schnelleren Feature-Fluss. Das erreichte er unter anderem dadurch, dass Umgebungen immer verfügbar waren, wenn man sie brauchte. Er automatisierte den Build- und Deployment-Prozess und erkannte, dass Infrastruktur als Code behandelt werden kann – so wie die Anwendung, die von der Entwicklung bereitgestellt wird. Auf diese Weise konnte er erreichen, dass mit einem Schritt eine Umgebung aufgebaut und der Code deployt wurde – so wie wir uns eine Möglichkeit überlegt hatten, Farbauftrag und Brennen in einem Schritt umzusetzen.

Wir wissen jetzt, dass Allspaw und Hammond doch nicht so verrückt waren. Jez Humble und Dave Farley kamen unabhängig davon zu den gleichen Schlussfolgerungen, und sie dokumentierten ihre Praktiken und Prinzipien für mehrere Deployments pro Tag in ihrem bahnbrechenden Buch Continuous Delivery. Eric Ries hat uns dann in seiner Arbeit rund um Lean Startups gezeigt, wie das Business mit diesen Möglichkeiten lernen und gewinnen kann.«

Während Erik erzählt, ist er so begeistert, wie ich ihn noch nie zuvor gesehen habe. Er schüttelt den Kopf und schaut mich ernst an.

»Ihr nächster Schritt sollte nun offensichtlich sein, Junior. Um mit den Kundenanforderungen mithalten zu können – wozu Ihre Kollegen in der Entwicklung zählen«, sagt er, »müssen Sie das einrichten, was Humble und Farley eine Deployment-Pipeline nennen. Das ist keine Kunst, das ist Fertigung. Alles muss unter Versionskontrolle stehen. Alles! Nicht nur der Code, sondern alles, was nötig ist, um die Umgebung aufzubauen. Dann müssen Sie den gesamten Prozess zum Aufbau der Umgebung automatisieren. Sie brauchen eine Deployment-Pipeline, in der Sie Test- und produktive Umgebungen erzeugen können, um dann den Code darin zu deployen – und das Ganze auf Anforderung. So reduzieren Sie Ihre Rüstzeiten und merzen Fehler aus, um schließlich jede Änderungsrate umsetzen zu können, die die Entwickler vorgeben.«

»Moment mal«, sage ich. »Was genau soll ich automatisieren?«

Erik sieht mich ernst an. »Fragen Sie Brent. Stecken Sie ihn in dieses neue Team und achten Sie darauf, dass er nicht abgelenkt wird. Mehr denn je gilt jetzt, dass er Ihr Engpass ist, bis Sie den Build-Prozess automatisiert haben. Nehmen Sie den Faktor Mensch aus dem Deployment-Umfeld. Überlegen Sie sich, wie Sie zehn Deployments pro Tag erreichen können.«

Ich kann meine Skepsis nicht verbergen. »Zehn Deployments pro Tag? Ich bin ziemlich sicher, dass das gar keiner braucht. Setzen Sie damit nicht ein Ziel, das höher liegt, als vom Business benötigt?«

Erik seufzt und verdreht die Augen. »Fokussieren Sie sich nicht so sehr auf die Deployment-Zielrate. Bei Businessagilität geht es nicht nur um die reine Geschwindigkeit. Es geht darum, wie gut Sie Änderungen im Markt erkennen und auf sie reagieren können und wie Sie größere und besser abgeschätzte Risiken eingehen können. Es geht um kontinuierliches Experimentieren, so wie Scott Cook es bei Intuit getan hat, wo sie über 40 Experimente während der Steuerhauptsaison durchführten, um herauszufinden, wie sie mehr Kunden gewinnen können. Während der Hauptsaison!

Wenn Sie nicht experimentieren und Ihre Konkurrenten in Bezug auf Time to Market und Agilität schlagen können, haben Sie verloren. Features sind immer ein Glücksspiel. Wenn Sie Glück haben, werden zehn Prozent den gewünschten Vorteil erbringen. Je schneller Sie also diese Features an den Markt bringen und sie testen können, desto besser. Gleichzeitig zahlen Sie damit dem Business auch das für Sie eingesetzte Kapital schneller zurück, sodass dort eher Geld verdient werden kann.

Steve hat sein Überleben auf Ihre Fähigkeit gesetzt, Features schneller auszuführen und bereitzustellen. Arbeiten Sie jetzt also mit Chris aus, wie Sie in jedem Schritt des agilen Entwicklungsprozesses nicht nur auslieferbaren Code, sondern auch eine funktionierende Umgebung haben, in die Sie deployen können!«

»Okay, okay«, sage ich. »Aber warum haben Sie mich hier in die Kälte geschleppt? Hätten Sie das nicht auch einfach an einem Whiteboard skizzieren können?«

»Sie glauben, dass IT Operations im Vergleich zur Fertigung besonders schwierig ist. Das ist aber totaler Quatsch«, sagt er geringschätzig. »So wie ich das sehe, waren die Leute in diesem Gebäude bisher deutlich kreativer und couragierter als alles, was ich von euch IT-Leuten bisher mitbekommen habe.«

KAPITEL 31

Montag, 3. November

Es ist 12:13, als ich zum Kick-off-Meeting des SWAT-Teams komme. Mein Haar ist klitschnass und mein Hemd von meiner Rückfahrt in Eriks Cabrio durchgeweicht. Chris spricht gerade. »... und so hat Steve dieses kleine Team dazu autorisiert, die Promotion-Funktionalität auszuliefern und alles zu tun, was nötig ist, damit das Ganze positive Auswirkungen auf die Weihnachtssaison hat.«

Chris wendet sich mir zu und zeigt auf das andere Ende des Raums. »Ich habe für alle etwas zu essen für dieses Meeting organisiert. Nimm dir ruhig – was ist denn mit dir passiert?«

Ich wische seine Frage beiseite. Dann schaue ich mich nach dem angebotenen Essen um und freue mich, dass es noch ein Putenbrust-Sandwich gibt. Ich schnappe es mir, setze mich und versuche, die Stimmung im Raum einzuschätzen, insbesondere die von Brent.

Brent sagt: »Erklärt mir doch noch mal, warum ich hier bin.«

»Das versuchen wir ja gerade herauszufinden«, sagt Wes aufrichtig. »Du weißt so viel wie wir. Einer der potenziellen Aufsichtsratskandidaten bestand darauf, dass du Teil dieses Teams bist. Und ehrlich gesagt, lag er in letzter Zeit mit seinen Ideen häufig genug richtig, daher vertraue ich ihm, auch wenn ich keine Ahnung habe, warum.«

Patty schaltet sich ein. »Na ja, er hat uns ein paar Hinweise gegeben. Er sagte, dass die Probleme, auf die wir uns konzentrieren müssen, den Deployment-Prozess und die Art und Weise, wie wir die Umgebungen aufbauen, betreffen. Er scheint zu glauben, dass wir angesichts der chaotischen Ergebnisse bei jeder Phoenix-Auslieferung etwas grundlegend falsch machen.«

Während ich mein Sandwich auspacke, sage ich: »Ich hatte gerade ein Meeting mit ihm. Er hat mir einiges gezeigt und erklärt, wie sie das damals bei Toyota mit dem Single Minute Exchange of Die gemacht haben. Er denkt, wir müssen die Fähigkeit für zehn Deployments pro Tag erlangen. Und er besteht nicht nur darauf, dass das möglich ist, sondern auch, dass es die Deployment-Zyklen unterstützt, die das Business braucht, um zu überleben, und auch, um im Markt wieder voranzukommen.«

Überraschenderweise widerspricht Chris heftig. »Was? Warum zum Henker bräuchten wir zehn Deployments pro Tag? Unsere Sprint-Intervalle sind drei Wochen lang. Wir haben gar nichts, was wir zehn Mal am Tag ausliefern könnten!«

Patty schüttelt den Kopf. »Bist du sicher? Wie ist es mit Bugfixes? Mit Performanceverbesserungen, wenn die Site stillsteht, wie während der letzten beiden großen Launches? Wäre es nicht klasse, diese Art von Änderungen routinemäßig in die Produktivumgebung einspielen zu können, ohne das notfallmäßig und gegen alle Regeln zu machen?«

Chris denkt einen Moment nach, dann antwortet er: »Interessant. Ich würde diese Art von Fixes normalerweise als Patch oder Minor Release bezeichnen. Aber du hast recht – das sind auch Deployments. Es wäre sehr gut, Fixes schneller herausrollen zu können, aber mal ehrlich – zehn Deployments pro Tag?«

Ich denke darüber nach, was Erik gesagt hat, und ergänze: »Wie wäre es, wenn wir es dem Marketing ermöglichen würden, ihre eigenen Änderungen am Inhalt oder an Businessregeln vorzunehmen oder schnellere Experimente und A/B-Tests durchzuführen, um zu sehen, was am besten funktioniert?«

Wes legt beide Hände auf den Tisch. »Merkt euch meine Worte, Leute. Das ist nicht möglich. Wir arbeiten hier gegen physikalische Gesetze. Vergesst nicht, wie lange es aktuell dauert – über eine Woche Vorbereitungszeit und über acht Stunden für das eigentliche Deployment! Man kann schließlich die Bits auf der Festplatte nur mit einer gewissen Geschwindigkeit ändern.«

Das ist genau das, was ich gesagt hätte, bevor ich mit Erik wieder in der Fertigungshalle war. Ernst sage ich: »Schaut mal, vielleicht habt ihr recht, aber versucht mal für den Moment, mir zu folgen: Wie viele Schritte sind für den Deployment-Prozess von Anfang bis Ende nötig? 20? 200? Oder 2000?«

Wes kratzt sich am Kopf, dann sagt er: »Was meinst du, Brent? Ich würde sagen, es sind rund 100 Schritte ...«

»Ehrlich?«, antwortet Brent. »Ich dachte, es sind eher so 20.«

William schaltet sich ein. »Ich bin nicht sicher, wo ihr mit dem Zählen beginnt, aber wenn wir da anfangen, wo die Entwicklung Code eincheckt und wir ihn als ›Release-Kandidat‹ markieren, komme ich vermutlich auf um die 100 Schritte – bevor wir das Ganze an IT Operations übergeben.«

Oh oh.

Wes unterbricht: »Nein, nein, nein. Bill hat von ›Deployment-Schritten‹ gesprochen. Lasst uns hier nicht ein Fass ohne ...«

Während Wes redet, denke ich darüber nach, dass mich Erik aufgefordert hat, wie ein Betriebsleiter zu denken und nicht wie ein Vorarbeiter. Plötzlich erkenne ich, dass er damit vermutlich meinte, die Abteilungsgrenzen von Entwicklung und IT Operations zu überwinden.

»Ihr habt beide recht«, unterbreche ich Wes und William.

»William, würde es dir etwas ausmachen, alle Schritte am Whiteboard aufzuschreiben? Ich schlage vor, mit dem ›Code-Commit‹ zu beginnen und dann fortzufahren, bis du beim Handover an unsere Gruppe angekommen bist.«

Er nickt, geht zum Whiteboard und beginnt mit dem Zeichnen von Kästchen, während er die einzelnen Schritte beschreibt. In den nächsten zehn Minuten zeigt sich, dass es tatsächlich über 100 Schritte sind – einschließlich der automatisierten Tests, die in der Dev-Umgebung laufen, dem Erstellen einer QA-Umgebung, die zu Dev passt, dem Deployen von Code dort hinein, dem Ausführen aller Tests, dem Deployen und Migrieren in eine saubere Staging-Umgebung, die zu QA passt, dem Load-Testen und schließlich der Übergabe des Stabs an IT Operations.

Als William fertig ist, gibt es 30 Kästchen auf dem Board.

Ich schaue zu Wes hinüber, aber statt irritiert zu gucken, scheint er tief in Gedanken versunken zu sein, und reibt sich das Kinn, während er auf das Whiteboard schaut.

Ich nicke Brent und Wes zu, damit einer von ihnen dort weitermacht, wo William aufgehört hat.

Brent steht auf und zeichnet jetzt auch Kästchen, in denen sich das Zusammenfassen des Codes für das Deployment, das Vorbereiten von neuen Serverinstanzen, das Laden und Konfigurieren des Betriebssystems, der Datenbanken und der Anwendungen, das Umsetzen aller Änderungen am Netzwerk, den Firewalls und den Load Balancers sowie das Testen zum erfolgreichen Deployment wiederfinden.

Ich grüble über das Diagramm, das mich erstaunlicherweise an die Fertigungshalle erinnert. Jeder dieser Schritte ist wie eine Arbeitsstation mit unterschiedlichen Maschinen, Menschen, Methoden und Maßnahmen. IT-Arbeit ist vermutlich doch viel komplexer als Fertigungsarbeit. Die Arbeit ist nicht nur unsichtbar, womit sie sich schlechter verfolgen lässt, es gibt auch noch viel mehr Dinge, die schiefgehen können.

Unzählige Konfigurationen müssen korrekt eingerichtet werden, Systeme brauchen genug Speicher, alle Dateien müssen an der richtigen Stelle liegen, und der gesamte Code sowie die gesamte Umgebung müssen korrekt laufen.

Es reicht ein kleiner Fehler, um alles zum Stillstand zu bringen. Ganz sicher brauchen wir noch mehr Strenge, Disziplin und Planung als bei der Fertigung.

Ich kann es kaum erwarten, Erik davon zu erzählen.

Die Aufgabe vor uns ist sehr wichtig und groß, also gehe ich zum Whiteboard und nehme mir einen roten Stift. Ich sage: »Ich werde ein großes, rotes Sternchen an jeden Schritt malen, mit dem wir bei den letzten Launches Probleme hatten.«

Ich beginne mit den Sternchen und erkläre: »Weil es keine saubere QA-Umgebung gab, haben wir eine alte Version genommen, weil alle Tests fehlschlugen, haben wir in QA Änderungen am Code und an der Umgebung vorgenommen, die nie zurück in die Dev- oder Produktivumgebungen gewandert sind, und weil wir nie all die Umgebungen synchronisiert haben, hatten wir beim nächsten Mal die gleichen Probleme.«

Ich hinterlasse eine Spur roter Sternchen und wende mich jetzt Brents Kästchen zu. »Weil wir keine korrekten Deployment-Anweisungen hatten, brauchten wir fünf Anläufe, die Packaging- und Deployment-Skripten richtig zu schreiben. Das flog uns dann in der Produktivumgebung um die Ohren, weil die Umgebung falsch aufgesetzt war – was ich schon erwähnt habe.«

Obwohl ich es nicht absichtlich tue, sind am Ende so gut wie alle Kästchen von William und Brent mit einem Sternchen markiert.

Ich drehe mich um und sehe in die entmutigten Gesichter meiner Kollegen. Als ich meinen potenziellen Fehler erkenne, sage ich schnell: »Hört mal, mein Ziel ist nicht, irgendwem die Schuld zu geben oder zu sagen, dass wir schlecht gearbeitet haben. Ich versuche nur, möglichst genau zu dokumentieren, was wir tun und was für Maßnahmen wir bei jedem Schritt ergreifen können. Lasst uns das Problem, das wir hier am Whiteboard sehen, als Team angehen und uns nicht gegenseitig die Schuld in die Schuhe schieben, okay?«

Patty sagt: »Wisst ihr, das erinnert mich an etwas, das die Leute in der Fertigung immer wieder nutzen. Wenn einer von denen jetzt hereinkäme, würde er vermutlich glauben, wir würden eine ›Wertstromanalyse‹ durchführen. Darf ich noch ein paar Dinge dazuschreiben?«

Ich übergebe ihr den Marker und setze mich wieder hin.

Bei jedem Kästchen fragt Patty, wie lange jeder dieser Schritte normalerweise dauert, und notiert die Zahlen darüber. Dann fragt sie, ob die Arbeit bei diesem Schritt typischerweise warten muss. Dort malt sie dann ein Dreieck vor die Box, was für Work in Process steht.

Heilige Scheiße. Für Patty ist die Äquivalenz zwischen unseren Deployments und einer Fertigungslinie nicht nur eine akademische Frage. Sie behandelt unsere Deployments, als ob sie eine Fertigungslinie wären!

Patty nutzt Lean-Tools und -Techniken, die die Fertigungsleute zum Dokumentieren und Verbessern ihrer Prozesse einsetzen.

Plötzlich verstehe ich, was Erik meinte, als er über die »Deployment-Pipeline« sprach. Auch wenn man unsere Arbeit nicht gleichsetzen kann mit der in einer Fertigungshalle, handelt es sich trotzdem um eine Wertkette.

Ich korrigiere mich selbst. Es ist unsere Wertkette, und ich bin zuversichtlich, dass wir kurz davor sind, herauszufinden, wie wir den Arbeitsfluss dramatisch verbessern können.

Nachdem Patty mit dem Notieren der Schrittdauern fertig ist, zeichnet sie die Kästchen neu und nutzt dabei kurze Bezeichnungen, um die Prozessschritte zu beschreiben. Auf einem neuen Whiteboard schreibt sie zwei Hauptpunkte auf: »Umgebungen« und »Deployment«.

Sie zeigt auf die Punkte und sagt: »Bei unserem aktuellen Prozess treten zwei Probleme auf: Bei jedem Teil des Deployment-Prozesses stehen die Umgebungen nie dann zur Verfügung, wenn wir sie benötigen, und selbst wenn sie da sind, muss viel Arbeit hineingesteckt werden, um alle synchron zu halten. Stimmt’s?«

Wes schnaubt und sagt: »Na, das ist ja mal was Neues. Aber ja, du hast natürlich recht.«

Sie fährt fort: »Die andere offensichtliche Quelle für Nacharbeiten und lange Rüstzeiten ist der Code-Packaging-Prozess, bei dem IT Operations die Objekte nimmt, die die Entwicklung in die Versionsverwaltung eingecheckt hat, und daraus die Deployment-Pakete generiert. Auch wenn Chris und sein Team ihr Bestes geben, um den Code und die Konfigurationen zu dokumentieren, rutscht uns immer irgendetwas durch, was erst dann entdeckt wird, wenn der Code nach dem Deployment in der Umgebung läuft. Richtig?«

Dieses Mal antwortet Wes nicht gleich. Brent ist schneller und sagt: »Du triffst den Nagel auf den Kopf. William wird mir da sicherlich zustimmen: Die Release-Anweisungen sind nie aktuell, sodass wir immer herumraten müssen, die Installer-Skripten auf gut Glück anpassen und die Installation wieder und wieder durchläuft ...«

»Jepp«, sagt William und nickt zustimmend.

»Ich würde vorschlagen, wir konzentrieren uns daher auf diese beiden Bereiche«, sagt Patty, schaut auf das Board und setzt sich dann wieder. »Irgendwelche Ideen?«

Brent sagt: »Vielleicht können William und ich zusammen ein Deployment-Handbuch schreiben, in dem all die Lehren zusammengefasst sind, die wir aus unseren Fehlern gezogen haben?«

Ich nicke, höre mir die Ideen von meinen Kollegen an, aber irgendwie scheint keine den massiven Durchbruch zu bringen, den wir benötigen. Erik hat die Reduzierung der Rüstzeit für den Motorhauben-Stanzprozess beschrieben. Er schien anzudeuten, dass das wichtig war. Aber warum?

»Wenn sich jede Gruppe eine Umgebung zusammenbastelt, wird das offensichtlich nicht funktionieren. Was auch immer wir tun – es muss uns einen großen Schritt vorwärts zu diesem ›Zehn-Deployments-pro-Tag-Ziel‹ führen«, sage ich. »Wir brauchen also einen deutlich höheren Automatisierungsanteil. Brent, was würde es uns bringen, wenn wir einen allgemeinen Prozess zum Erstellen von Umgebungen aufsetzen würden, sodass wir die Dev-, QA- und Produktivumgebungen zur selben Zeit erzeugen und sie synchron halten könnten?«

»Interessante Idee«, sagt Brent und schaut auf das Board. Er steht auf und zeichnet drei Kästchen mit »Dev«, »QA« und »Produktiv«. Dann zeichnet er darunter ein weiteres Kästchen mit der Beschriftung »Build-Prozedur«, von der er Pfeile zu den drei anderen Kästchen zieht.

»Das ist ziemlich brillant von dir, Bill«, sagt er. »Wenn wir eine allgemeine Build-Prozedur haben und jeder diese Tools nutzt, um seine Umgebung einzurichten, würden die Entwickler tatsächlich Code in einer Umgebung schreiben, die der Produktivumgebung zumindest ähnelt. Das alleine wäre schon ein Riesengewinn.«

Er nimmt die Verschlusskappe des Markers aus dem Mund. »Um die Phoenix-Umgebung aufzubauen, nutzen wir einen Haufen selbst geschriebener Skripten. Mit etwas Dokumentation und Aufräumen könnten wir bestimmt in ein paar Tagen so etwas zusammenstellen.«

Ich wende mich Chris zu und sage: »Das erscheint vielversprechend. Wenn wir die Umgebungen standardisieren und sie in der täglichen Arbeit von Entwicklung, QA und IT Operations einsetzen könnten, würden wir den Großteil der Unterschiede ausmerzen, die uns im Deployment-Prozess so viel Ärger bereiten.«

Chris scheint begeistert. »Brent, wenn das für dich und die anderen in Ordnung ist, würde ich dich gerne zu unseren Team-Sprints einladen, sodass wir das Erstellen der Umgebung so früh wie möglich in den Entwicklungsprozess einbinden können. Aktuell konzentrieren wir uns vor allem darauf, am Ende des Projekts auslieferbaren Code zu haben. Ich schlage vor, diese Anforderung zu ändern. In jedem dreiwöchigen Sprint-Intervall müssen wir nicht nur auslieferbaren Code haben, sondern auch genau die Umgebung, in die er wandern soll. Beides muss dann zudem in der Versionskontrolle stecken.«

Brent lächelt breit über den Vorschlag. Bevor Wes antworten kann, sage ich: »Ich stimme dem voll zu. Aber bevor wir weitermachen – können wir uns noch mit dem anderen Thema beschäftigen, das Patty aufgeschrieben hat? Auch wenn wir Chris’ Vorschlag übernehmen, gibt es immer noch das Problem mit den Deployment-Skripten. Wenn wir jetzt automatisch eine saubere QA-Umgebung haben – wie sollten wir den Code deployen? Jedes Mal wandern der Code, die Skripten und wer weiß was zwischen den Gruppen hin und her.«

Patty meldet sich zu Wort. »In der Fertigungshalle nennt sich es Nacharbeit, wenn Arbeit zurückfließt. Sobald das geschieht, kann man davon ausgehen, dass der Dokumentations- und Informationsfluss sehr mager ist. Dadurch lässt sich nichts reproduzieren, und das wird mit der Zeit immer schlimmer, wenn wir versuchen, schneller zu werden. Sie nennen das dort eine Arbeit, die keinen Wert liefert, oder ›Waste‹.«

Sie schaut auf das erste Whiteboard mit all den Kästchen und sagt: »Wenn wir den Prozess neu entwerfen, müssen von Anfang an die richtigen Leute beteiligt sein. Das ist wie beim Entwicklerteam für die Fertigung, die sicherstellt, dass alle Teile so entworfen sind, dass sie für die Fertigung optimiert sind, und dass die Fertigungslinien für die Teile optimiert sind – idealerweise im Single Piece Flow.«

Ich nicke und lächle über die Ähnlichkeiten zwischen dem, was Patty empfiehlt, und dem, was Erik heute Vormittag vorgeschlagen hat.

Ich wende mich William und Brent zu und sage: »Okay, Leute, ihr habt einen Zauberstab, und ihr seid die richtigen Leute dafür. Wie würdet ihr die Fertigungslinie entwerfen, sodass Arbeit niemals zurücklaufen muss und sich der Fluss zügig und effizient voranbewegt?«

Als sie mich beide fragend anstarren, sage ich leicht verzweifelt: »Ihr habt einen Zauberstab. Nutzt ihn!«

»Wie mächtig ist der Zauberstab?«, fragt William.

Ich wiederhole, was ich zu Maggie gesagt habe: »Es ist ein sehr mächtiger Zauberstab. Er kann alles machen.«

William geht zum Whiteboard und zeigt auf ein Kästchen namens »Code-Commit«. »Wenn ich so einen Zauberstab einsetzen könnte, würde ich diesen Schritt ändern. Statt den Quellcode oder den kompilierten Code von Dev über die Versionskontrolle zu erhalten, möchte ich gerne gepackten Code haben, der fertig zur Auslieferung ist.«

»Wisst ihr«, fährt er fort, »ich möchte das so sehr, ich würde mich sogar freiwillig dazu melden, für das Erstellen der Pakete verantwortlich zu sein. Und ich kenne auch genau die richtige Person, der ich diese Aufgabe zuteilen würde. Sie wäre dann verantwortlich für den Dev-Handoff. Wenn es Code mit dem Label ›Testbereit‹ gibt, würden wir dann den gepackten Code generieren und einchecken, was zu einem automatischen Deployment in die QA-Umgebung führen würde. Und später vielleicht sogar in die Produktivumgebung.«

»Wow, das würdest du wirklich tun?«, fragt Wes. »Das wäre toll. Lasst es uns so machen – sofern nicht Brent das Packen übernehmen will.«

»Machst du Witze?«, fragt Brent und bricht in schallendes Gelächter aus. »Ich würde dieser Person für den Rest des Jahres Drinks spendieren! Ich liebe diese Idee. Und ich möchte auch gerne beim Erstellen der neuen Deployment-Tools helfen. Wie ich schon sagte: Ich habe einen Haufen Tools geschrieben, die wir als Ausgangspunkt nutzen können.«

Ich kann die Energie und Erregung im Raum spüren. Ich bin begeistert, wie schnell wir vom Glauben, zehn Deployments pro Tag wären pure Fantasie, zur Frage gekommen sind, wie nahe wir diesem Ziel kommen können.

Plötzlich schaut Patty auf und sagt: »Wartet mal. Dieses ganze Phoenix-Modul hat mit Auftragsdaten zu tun, die geschützt werden müssen. Sollte nicht auch jemand aus Johns Team dabei sein?«

Wir sehen uns alle an und stimmen zu. Und erneut erstaunt mich, wie sehr wir uns als Organisation geändert haben.

KAPITEL 32

Montag, 10. November

Die nächsten beiden Wochen vergehen im Nu, weil ich zusammen mit Wes und Patty den größten Teil unserer Zeit mit SWAT-Team-Aktivitäten beschäftigt bin.

Es ist über ein Jahrzehnt her, dass ich tagtäglich mit Entwicklern zu tun hatte. Ich habe ganz vergessen, wie seltsam sie sein können. Mir erscheinen sie eher wie Indie-Musiker denn wie Ingenieure.

Zu meiner Zeit trugen Entwickler Taschenschoner – keine Vintage-T-Shirts und Sandalen – und hatten keine Skateboards dabei.

Die meisten dieser Leute sind in vielen Dingen das genaue Gegenteil von mir. Ich mag Menschen, die Prozesse erstellen und ihnen folgen, Menschen, die Strenge und Disziplin zu würdigen wissen. Aber diese Leute hier vermeiden Prozesse und pflegen lieber ihre Launen und Marotten.

Aber Gott sei Dank sind sie ja hier.

Ich weiß, es ist nicht fair, einen ganzen Berufsstand zu brandmarken. Ich weiß, dass all diese verschiedenen Fertigkeiten wichtig sind, wenn wir Erfolg haben wollen. Die Herausforderung ist, alle so zusammenzubringen, dass wir am gleichen Ziel arbeiten.

Die erste Herausforderung: dem SWAT-Team-Projekt einen Namen geben. Wir konnten es ja nicht »Mini-Phoenix« nennen, also haben wir eine ganze Stunde über den Namen diskutiert.

Meine Kollegen wollten es »Cujo« oder »Stiletto« nennen. Aber die Entwickler wünschen sich »Unicorn«.

Unicorn? Also Einhorn? Wie Regenbogen und Glücksbärchis?

Und entgegen meinen Erwartungen gewinnt »Unicorn« die Abstimmung. Entwickler – ich werde sie nie verstehen.

Trotz meines Widerwillens gegen den Namen macht sich Projekt Unicorn erstaunlich gut. Mit der Vorgabe, alles zu tun, was nötig ist, um effektive Kundenempfehlungen und -Promotions auszuliefern, haben wir mit einer sauberen Codebasis begonnen, die vollständig von dem Phoenix-Monstrum abgekoppelt ist.

Es war erstaunlich, mit anzusehen, wie dieses Team Probleme anging. Eine der ersten Herausforderungen war, die Auftragsdaten zu analysieren. Um auf die produktive Datenbank zugreifen zu können, hätte man sich mit ihren Libraries verbinden müssen, und jede Änderung daran hätte zu einer Diskussion mit dem Architekturteam geführt.

Da die gesamte Firma bis dahin hätte pleite sein können, entschieden sich die Entwickler und Brent dafür, eine komplett neue Datenbank mithilfe von Open-Source-Tools zu erstellen und die Daten nicht nur von Phoenix, sondern auch aus den Bestell- und Lagerverwaltungssystemen zu kopieren.

Dadurch konnten wir entwickeln, testen und sogar produktiv laufen, ohne Phoenix oder andere kritische Businessanwendungen zu beeinflussen. Und indem wir uns von den anderen Projekten abkoppelten, konnten wir beliebige Änderungen vornehmen, ohne die anderen Projekte zu gefährden. Gleichzeitig wurden wir nicht durch Prozesse aufgehalten, mit denen wir eigentlich nichts zu tun haben mussten.

Ich habe dieses Vorgehen voll und ganz unterstützt. Allerdings fragte sich ein kleiner Teil von mir, wie wir mit dem unabwendbaren Ausufern von Systemen umgehen wollen, wenn jedes Projekt mal eben eine neue Datenbank aufsetzen kann. Ich mache mir eine Notiz, darauf zu achten, dass wir die möglichen Datenbanktypen standardisieren müssen, die wir produktiv nutzen, um sicherzustellen, dass wir langfristig auch die notwendigen Fertigkeiten in der Gruppe haben.

Währenddessen hat Brent zusammen mit Williams Team an den Build-Prozeduren und Automatisierungsmechanismen gearbeitet, um simultan die Dev-, QA- und Produktivumgebungen zu erzeugen. Wir waren alle sehr erstaunt, dass während des dreiwöchigen Sprints vielleicht das erste Mal in der Geschichte alle Entwickler genau das gleiche Betriebssystem sowie die gleichen Bibliotheksversionen, Datenbanken, Datenbankeinstellungen und so weiter genutzt haben.

»Das ist unglaublich«, sagte einer der Entwickler bei der Sprint-Retrospektive, die am Ende jedes Sprints abgehalten wurde. »Bei Phoenix hat es uns drei oder vier Wochen gekostet, bei neuen Entwicklern die Builds auf deren Rechnern zum Laufen zu bringen, weil wir nie die vollständige Liste der Millionen Dinge zur Hand hatten, die installiert werden müssen, um eine erfolgreiche Kompilierung oder eine Ausführung zu erreichen. Aber jetzt müssen wir nur die virtuelle Maschine auschecken, die Brent und das Team gebaut haben, und können gleich loslegen.«

Genauso waren wir alle begeistert, dass wir sehr früh im Projekt eine QA-Umgebung zur Verfügung hatten, die der Dev-Umgebung entsprach. Das gab es bisher auch noch nicht. Wir mussten ein paar Anpassungen vornehmen, um die geringere Speicher- und Festplattenausstattung von Dev gegenüber QA zu berücksichtigen (das wiederum weniger als Production besaß). Aber der größte Teil der Umgebungen war identisch und konnte in Minuten angepasst und gestartet werden.

Automatische Code-Deployments funktionierten noch nicht, ebenso wenig die Migration von Code zwischen den Umgebungen, aber Williams Team hatte genug von diesen Fähigkeiten demonstriert, dass wir alle davon ausgingen, dieses Problem auch bald gelöst zu haben.

Das Tüpfelchen auf dem i war dann, dass die Entwickler ihre Feature-Sprint-Ziele früher als geplant erreichten. Sie erzeugten Berichte mit »Kunden, die dieses Produkt gekauft haben, kauften auch jenes«. Die Berichte dauerten zwar hundertmal länger als erwartet, aber es wurde versprochen, dass die Performance noch verbessert werden könnte.

Aufgrund unserer beachtlichen Fortschritte entschieden wir, die Sprint-Intervalle auf zwei Wochen zu verkürzen. Dadurch konnten wir unseren Planungshorizont verringern und damit Entscheidungen schneller treffen und umsetzen, statt an einem Plan festhalten zu müssen, der fast einen Monat alt ist.

Phoenix arbeitet weiterhin mit einem Plan, der vor über drei Jahren entworfen wurde. Darüber versuche ich möglichst nicht allzu intensiv nachzudenken.

Unser Fortschritt scheint sich exponentiell zu verbessern. Wir planen und führen schneller aus denn je, und der Geschwindigkeitsunterschied zwischen Unicorn und Phoenix wird immer größer. Die Phoenix-Teams bekommen das mit und beginnen damit, einzelne Praktiken von uns zu übernehmen. Dadurch erzielen auch sie Ergebnisse, mit denen keiner gerechnet hätte.

Unicorn hat so viel Fahrt aufgenommen, dass es nicht mehr zu stoppen scheint. Ich bezweifle, dass wir dieses Projekt noch mal auf den alten Weg zurückführen könnten, selbst wenn wir es wollten.

Ich sitze gerade in einem Budget-Meeting, als mich Wes anruft. »Wir haben ein großes Problem.«

Ich gehe vor die Tür und frage: »Was denn für eins?«

»Brent ist seit zwei Tagen unauffindbar. Weißt du, wo er sein könnte?«, sagt er.

»Nein«, antworte ich. »Moment, was heißt, er ist unauffindbar? Ist alles okay mit ihm? Du hast doch versucht, ihn auf dem Handy anzurufen, oder?«

Wes gibt sich nicht die Mühe, seine Verärgerung zu verbergen. »Natürlich habe ich ihn auf dem Handy angerufen! Ich hinterlasse stündlich Nachrichten auf seiner Mailbox. Alle versuchen, ihn zu finden. Wir haben hier einen Haufen Arbeit, und seine Team-Kollegen werden langsam echt ungnädig, dass – warte mal, hey, Brent ruft gerade an ...«

Ich höre, wie er sein Festnetztelefon abnimmt und sagt: »Wo zur Hölle bist du gewesen? Alle suchen nach dir! Nein ... nein ... Des Moines? Was machst du da denn? Keiner hat mir gesagt, dass ... Ein geheimer Auftrag von Dick und Sarah? Was zum Henker ...«

Ich höre Wes amüsiert zu, wie er versucht, sich einen Überblick über die Situation zu verschaffen. Schließlich höre ich ihn sagen: »Warte mal eine Sekunde. Ich will wissen, was Bill da tun möchte ...«, und er nimmt sein Handy wieder auf.

»Okay, du hast das meiste mitbekommen, oder?«, sagt er.

»Sag ihm, ich rufe ihn direkt an.«

Nachdem ich aufgelegt habe, rufe ich Brent an und frage mich, was Sarah schon wieder getan hat. »Hallo Bill«, höre ich ihn sagen.

»Könntest du mir erklären, was da vorgeht und warum du in Des Moines bist?«, frage ich höflich.

»Hat dir das keiner aus Dicks Büro erzählt?«, fragt er. Als ich nichts sage, fährt er fort: »Dick und das Finance-Team haben mich vorgestern Morgen aus dem Büro herausgeholt. Ich soll Teil einer Taskforce sein, die einen Plan zum Aufteilen der Firma ausarbeitet. Anscheinend ist das ein Projekt mit Top-Priorität, und sie müssen herausfinden, welche Auswirkungen es auf all die IT-Systeme hat.«

»Und warum hat Dick dich in das Team geholt?«, frage ich.

»Das weiß ich nicht«, antwortet Brent. »Glaub mir, ich will hier gar nicht sein. Ich hasse Flugzeuge. Eigentlich sollte das einer ihrer Businessanalysten machen, aber vielleicht liegt es daran, dass ich am meisten darüber weiß, wie die wichtigen Systeme miteinander verbunden sind, wo sie stehen, welche Services davon abhängen ... Ach übrigens: Ich kann dir jetzt schon sagen, dass ein Aufteilen der Firma der reinste Albtraum sein wird.«

Ich erinnere mich daran, als ich das Akquisitions-Integrations-Team für das Einbinden des großen Retailers geleitet habe. Das war schon ein gewaltiges Projekt. Ein Aufteilen der Firma würde noch schwieriger werden.

Wenn das jede der Hunderte von Anwendungen betrifft, die wir betreuen, hat Brent wohl recht. Das wird Jahre dauern.

IT ist überall dabei, daher schneidet man nicht einfach nur ein Glied ab. Es ist mehr so, als würde man das gesamte Nervensystem der Firma auseinanderfieseln.

Ich denke wieder daran, dass Dick und Sarah eine meiner wichtigsten Ressourcen entführt haben, ohne mich zu fragen, also sage ich langsam und mit Bedacht: »Brent, hör mir jetzt genau zu: Deine Top-Priorität ist, herauszufinden, was deine Unicorn-Kollegen brauchen und wie sie es bekommen können. Ich werde ein paar Telefonate führen, und es kann gut sein, dass meine Assistentin Ellen dir einen Rückflug für heute Abend buchen wird. Hast du verstanden?«

Du willst, dass ich abreise?«, fragt Brent.

»Genau.«

»Was soll ich Dick und Sarah erzählen?«, fragt er verunsichert.

Ich denke einen Moment nach. »Sag ihnen, du musst bei einem Notfall einspringen und dass du wiederkommst.«

»Okay ...«, sagt er. »Worum geht es hier eigentlich?«

»Das ist ganz einfach, Brent«, erkläre ich. »Unicorn ist unsere letzte Hoffnung, unsere Quartalszahlen zu erreichen. Noch ein weiteres verkacktes Quartal, und der Aufsichtsrat wird die Firma mit Sicherheit aufteilen – und dann wirst du auch der Taskforce helfen können. Aber wenn wir die Ziele erreichen, haben wir die Chance, die Firma doch noch zu erhalten. Darum hat Unicorn unsere absolute Priorität. Steve war da sehr eindeutig.«

Brent sagt zweifelnd: »Okay. Sag mir einfach, wohin ich gehen soll, dann werde ich dort sein. Die Diskussion mit den hohen Tieren überlasse ich dir.« Er ist deutlich genervt von den widersprüchlichen Signalen, die er empfängt.

Aber nicht so genervt wie ich.

Ich rufe Steves Assistentin Stacy an und sage ihr, dass ich gleich bei ihnen bin.

Auf dem Weg zu Gebäude 2 rufe ich Wes an.

»Du hast was getan?«, kichert er. »Super. Jetzt steckst du mitten in einer politischen Schlacht mit Steve auf der einen und Dick und Sarah auf der anderen Seite. Und ganz ehrlich – ich bin nicht sicher, dass du bei den Gewinnern sitzen wirst.«

Nach einem Moment sagt er: »Du glaubst wirklich, dass Steve uns da den Rücken freihalten wird?«

Ich unterdrücke einen Seufzer. »Ich hoffe doch sehr. Wenn wir Brent nicht Vollzeit zurückbekommen, ist Unicorn verloren. Und das bedeutet sehr wahrscheinlich, dass wir alle einen neuen CEO bekommen, outgesourct werden und uns überlegen können, wie wir die Firma aufteilen. Klingt das nach einem Klassejob?«

Ich lege auf und gehe in Steves Büro. Er lächelt mich matt an. »Guten Morgen. Stacy sagt, Sie haben schlechte Neuigkeiten für mich?«

Als ich ihm erzähle, was ich durch das Telefonat mit Brent erfahren habe, bin ich überrascht, dass sich sein Gesicht purpurrot färbt. Ich hätte gedacht, er wüsste das alles. Er ist doch schließlich der CEO.

Anscheinend nicht.

Nach einem Moment sagt er: »Der Aufsichtsrat hat mir versichert, dass das Aufteilen der Firma nicht weiter verfolgt wird, bis wir die Zahlen für dieses Quartal kennen. Ich denke mal, sie haben die Geduld verloren.«

Er fährt fort: »Erzählen Sie mir, was das für Auswirkungen auf Unicorn hat, wenn Brent nicht mehr dabei ist.«

»Ich habe mit Chris, Wes und Patty gesprochen«, antworte ich. »Projekt Unicorn wäre am Ende. Ich bin von Natur aus skeptisch, aber ich glaube wirklich, dass Unicorn funktionieren wird. Angesichts der Tatsache, dass schon in zwei Wochen Thanksgiving ansteht, brauchen wir Brent für einen großen Teil der Features, die wir bauen müssen. Und übrigens, viele der Durchbrüche, die wir machen, werden vom Phoenix-Team übernommen, was fantastisch ist.« Um meinen Standpunkt noch deutlicher zu machen, sage ich entschieden: »Ohne Brent werden wir die mit Unicorn verbundenen Verkaufs- und Profitziele nicht erreichen. Keine Chance.«

Steve schürzt die Lippen und fragt: »Und was passiert, wenn Sie Brent durch den nächstpassenden Kollegen ersetzen?«

Ich wiederhole, was Wes mir erzählt hat und was auch meiner eigenen Einschätzung entspricht. »Brent ist einmalig. Unicorn braucht jemanden, der den Respekt der Entwickler besitzt, genug Erfahrung mit so gut wie jeder IT-Infrastruktur hat, die wir hier einsetzen, und der beschreiben kann, was die Entwickler bauen müssen, sodass wir es tatsächlich produktiv einsetzen und warten können. Diese Fertigkeiten sind sehr selten, und wir haben niemanden, der im Moment diese besondere Rolle einnehmen könnte.«

»Und was, wenn Sie diese nächstpassende Person zu Dicks Taskforce schicken?«, fragt Steve.

»Ich vermute, die Aufteilungsplanung wäre nicht so exakt, aber sie würden immer noch fertig werden«, antworte ich.

Steve lehnt sich in seinem Stuhl zurück und sagt nichts.

Schließlich entscheidet er: »Holen Sie Brent zurück. Ich kümmere mich um den Rest.«

KAPITEL 33

Dienstag, 11. November

Am nächsten Tag ist Brent zurück beim Projekt Unicorn, und einer der Level-3-Techniker sitzt jetzt mit Dicks Team irgendwo im verschneiten Mittleren Westen. Innerhalb einer Stunde erhalte ich per CC eine E-Mail von Sarah:

Von: Sarah Moulton

An: Bob Strauss

Cc: Dick Landry, Steve Masters, Bill Palmer

Datum: 11. November, 07:24

Betreff: Jemand untergräbt Projekt Talon

Bob, ich habe herausgefunden, dass Bill Palmer, amtierender VP of IT Operations, die entscheidende Ressource von Projekt Talon abgezogen hat.

Bill, ich bin über Ihre Aktivitäten sehr besorgt. Bitte erklären Sie, warum Sie Brent zurückbeordert haben. Das ist nicht zu tolerieren. Der Aufsichtsrat hat uns angewiesen, strategische Optionen zu sondieren.

Ich fordere, dass Brent so schnell wie möglich wieder dem Talon-Team zugeordnet wird. Bitte bestätigen Sie, dass Sie diese Nachricht verstanden haben.

Sarah

Wirklich besorgt, dass ich in einer E-Mail an den Vorstandsvorsitzenden erwähnt werde, rufe ich Steve an, der ganz offensichtlich stinkwütend über Sarahs offenkundigen Loyalitätswechsel ist. Nachdem er etwas Unverständliches gemurmelt hat, versichert er mir, dass er sich darum kümmern wird und ich so weitermachen kann, wie es geplant war.

Im täglichen Unicorn-Scrum-Meeting sieht William nicht sehr glücklich aus. »Die gute Nachricht ist, dass wir letzte Nacht unseren ersten Kunden-Promotion-Bericht generiert haben und dass der korrekt zu sein scheint. Aber der Code läuft 50 Mal langsamer, als wir erwartet hätten. Einer der Clustering-Algorithmen lässt sich nicht so gut parallelisieren, wie wir dachten, daher brauchen die Vorhersageläufe mehr als 24 Stunden, selbst für unser kleines Daten-Testset.«

Im ganzen Raum wird gegrummelt und gemurmelt.

Einer der Entwickler sagt: »Können wir nicht per Brute Force darangehen? Einfach mehr Hardware nehmen? Mit genug Servern lassen sich die Laufzeiten auf jeden Fall verringern.«

»Machst du Witze?«, sagt Wes verärgert. »Wir haben nur ein Budget für 20 der schnellsten Server, die wir finden konnten. Du bräuchtest aber über 1000 Server, um die Laufzeiten da zu haben, wo wir sie brauchen. Das wären über eine Million Dollar, die wir nicht haben!«

Ich schürze die Lippen. Wes hat recht. Phoenix hat das Budget schon mit dem aktuellen Status weit überzogen, und wir reden hier über jede Menge zusätzliches Geld, das wir nie genehmigt bekommen werden, insbesondere angesichts unserer finanziellen Lage.

»Wir brauchen keine neue Hardware«, antwortet der Entwickler. »Wir haben doch den ganzen Aufwand getrieben mit den Rechner-Images, die wir deployen können. Warum schicken wir sie jetzt nicht in die Cloud? Wir könnten Hunderte oder Tausende Instanzen nach Bedarf erzeugen und sie wieder herunterfahren, wenn wir sie nicht mehr brauchen. Dann zahlen wir nur für die Rechenzeit, die wir benötigen.«

Wes sieht Brent an, der sagt: »Das wäre möglich. Wir nutzen schon in den meisten unserer Umgebungen Virtualisierung. Es sollte nicht so schwer sein, sie so umzuwandeln, dass sie bei einem Cloud-Computing-Provider laufen.«

Nach einer kurzen Pause fügt er hinzu: »Wisst ihr, das wäre sogar richtig interessant. Ich wollte so etwas schon immer einmal machen.«

Brents Begeisterung ist ansteckend.

Wir verteilen Aufgaben, um herauszufinden, ob das Ganze machbar ist. Brent arbeitet mit dem Entwickler zusammen, der die Idee vorgeschlagen hat, um einen Prototyp zusammenzuschustern und herauszufinden, ob das überhaupt geht.

Maggie, die ein so großes Interesse an Unicorn entwickelt hat, dass sie regelmäßig bei den Daily Scrums dabei ist, meldet sich freiwillig, um die Preise zu eruieren. Zudem will sie sich bei ihren Bekannten in der Branche umhören, ob das schon woanders gemacht wurde und welche Provider empfehlenswert sind.

Einer von Johns Sicherheitstechnikern hat aber Bedenken. »Wenn wir unsere Kundendaten in die Cloud schicken, kann das riskant sein. Eventuell werden unabsichtlich persönliche Daten bekannt, oder jemand hackt sich in diese Rechner.«

»Guter Hinweis«, sage ich. »Kannst du die kritischsten Punkte zusammenfassen, über die wir uns Gedanken machen sollten, und eine Liste möglicher Gegenmaßnahmen und Sicherheitschecks vorbereiten?«

Natürlich tut er das und freut sich, dass er darum gebeten wurde. Einer der Entwickler erklärt sich bereit, dabei zu helfen.

Am Ende des Meetings bin ich von den unerwarteten Vorteilen überrascht, die das Automatisieren unseres Deployment-Prozesses mit sich bringt. Die Entwickler können die Anwendung schneller skalieren lassen, und es sind möglicherweise nur wenige Änderungen dafür erforderlich.

Trotzdem ist meine Einstellung gegenüber diesem ganzen Cloud-Gedöns äußerst zwiespältig. Die Leute tun so, als wäre es ein Zaubertrank, mit dem sich die Kosten sofort verringern lassen. Meiner Meinung nach ist das nur eine andere Form von Outsourcing.

Aber wenn es ein Problem löst, das wir gerade haben, bin ich bereit, dem Ganzen eine Chance zu geben. Ich bitte Wes darum, ebenfalls unvoreingenommen an die Sache heranzugehen.

Eine Woche später steht eine Demo an. Wir befinden uns alle im Unicorn-Teambereich. Es ist Sprint-Ende, und der Entwicklungsleiter möchte unbedingt zeigen, was das Team erreicht hat.

»Ich kann kaum glauben, wie viel wir geschafft haben«, beginnt er. »Dank der ganzen Deployment-Automatisierung war das Einrichten von Rechnerinstanzen in der Cloud gar nicht so schwer, wie wir gedacht haben. Tatsächlich funktioniert es so gut, dass wir überlegen, sämtliche In-House-Produktivsysteme für Unicorn in Testsysteme umzuwandeln und die Cloud für all unsere Produktivsysteme zu verwenden.

Wir haben damit begonnen, die Empfehlungsberichte jeden Abend laufen zu lassen. Dazu lassen wir Hunderte von virtuellen Rechnern in der Cloud laufen, bis alles fertig ist – danach schalten wir sie wieder ab. Das haben wir in den letzten vier Tagen getan, und es läuft gut – sehr gut.«

Brent lächelt breit – wie auch der Rest des Teams.

Als Nächstes kommt normalerweise der Produktmanager dran, aber dieses Mal präsentiert Maggie etwas. Sie hat offensichtlich mehr als nur ein beiläufiges Interesse an diesem Projekt.

Sie zeigt eine PowerPoint-Präsentation über den Beamer. »Das sind die Unicorn-Promotions, die für mein Kundenkonto erzeugt wurden. Wie ihr sehen könnt, wurde meine Einkaufshistorie betrachtet, und ich erhielt die Information, dass ich für Winterreifen und Batterien zurzeit 15 Prozent Rabatt bekomme. Ich bin dann tatsächlich auf unsere Webseite gegangen und habe beides gekauft, weil ich es benötigte. Die Firma hat gerade Geld verdient, weil das alles Produkte sind, von denen wir viele vorrätig haben und die hohe Profite einbringen.«

Ich lächle. Das ist brillant.

»Und hier sind die Unicorn-Promotions für Wes«, fährt sie fort, zeigt die nächste Slide an und lächelt. »Es sieht so aus, als ob du einen Rabatt auf Rallye-Bremsbeläge und Kraftstoffzusätze erhalten würdest. Ist das für dich von Interesse?«

Wes lächelt. »Nicht schlecht!«

Maggie erklärt, dass all diese Angebote schon im Phoenix-System zu finden sind und nur auf die Promotion-Funktionalität warten, um sie zum Kunden zu bringen.

Sie fährt fort: »Mein Vorschlag: Ich möchte E-Mails an ein Prozent der Kunden schicken, um zu sehen, was passiert. Thanksgiving ist in einer Woche. Wenn wir ein paar Tests machen und alles gut läuft, würden wir am Black Friday richtig durchstarten – dem umsatzstärksten Tag des Jahres.«

»Das klingt wie ein guter Plan«, sage ich. »Wes, gibt es irgendwelche Gründe, das nicht zu tun?«

Wes schüttelt den Kopf. »Aus Ops-Sicht sehe ich keine. Die meiste Arbeit ist schon getan. Wenn Chris, William und das Marketing dem Code trauen, gebe auch ich mein Okay.«

Alle stimmen zu. Es gibt ein paar Dinge, die noch zu erledigen sind, aber Maggie sagt, dass ihr Team gerne die Nächte durcharbeitet, um sie zu erledigen.

Ich lächle in mich hinein. Das erste Mal sind es nicht wir, die die ganze Nacht durchmachen, weil etwas richtig schiefgegangen ist. Tatsächlich ist es das genaue Gegenteil. Die Leute bleiben auf, weil alles richtig läuft.

Am folgenden Montag ist es knapp über null Grad, als ich zur Arbeit fahre, aber die Sonne scheint. Es sieht so aus, als würde es für die anstehenden Thanksgiving-Feiertage eine tolle Woche werden. Am Wochenende haben mich die ersten Weihnachtswerbespots daran erinnert, dass auch dieses Fest nicht mehr allzu fern ist.

Im Büro angekommen, werfe ich meine schwere Jacke über den Stuhl. Ich drehe mich um, als ich Patty reinkommen höre. Sie grinst über das ganze Gesicht. »Hast du die tollen Neuigkeiten vom Marketing gehört?«

Als ich den Kopf schüttle, sagt sie nur: »Lies die E-Mail, die Maggie gerade verschickt hat.«

Ich öffne meinen Laptop und lese:

Von: Maggie Lee

An: Chris Allers, Bill Palmer

Cc: Steve Masters, Wes Davis, Patty McKee, Sarah Moulton

Datum: 24. November, 07:47

Betreff: Erste Unicorn-Promotion-Kampagne: UNGLAUBLICH!

Das Marketingteam hat sich das Wochenende um die Ohren geschlagen, um eine Testkampagne für 1 % unserer Kunden durchzuführen.

Die Ergebnisse waren unvorstellbar gut! Über 20 % der Angeschriebenen riefen unsere Website auf, und über 6 % haben etwas gekauft. Das sind unglaubliche Konversionsraten – vermutlich fünfmal höher als bei allen Kampagnen, die wir bisher durchgeführt haben.

Wir empfehlen, zu Thanksgiving eine Unicorn-Promotion für alle Kunden durchzuführen. Ich arbeite an einem Dashboard, damit jeder in Echtzeit Ergebnisse der Unicorn-Kampagnen sehen kann.

Denkt auch daran, dass alle beworbenen Produkte solche mit hoher Marge sind, sodass die Einnahmeeffekte besonders hoch ausfallen.

Ihr habt alle tolle Arbeit geleistet!

Maggie

PS: Bill, angesichts der Ergebnisse erwarten wir eine starke Zunahme des Web-Traffics. Können wir sicher sein, dass die Website dadurch nicht lahmgelegt wird?

»Toll«, sage ich zu Patty. »Setz dich bitte mit Wes zusammen, um herauszufinden, was wir tun müssen, um mit der Traffic-Last klarzukommen. Wir haben dafür nur drei Tage, es bleibt also nicht viel Zeit. Das wollen wir schließlich nicht in den Sand setzen und unsere zukünftigen Kunden gleich verärgern.«

Sie nickt und will gerade etwas sagen, als ihr Handy vibriert. Kurz danach vibriert auch meins. Sie sieht kurz drauf und sagt: »Die Dragon-Lady schlägt wieder zu.«

»Ich wünschte, ich hätte einen »›Unsubscribe‹ -Button für ihre E-Mails«, sagt Patty beim Hinausgehen.

Eine halbe Stunde später verschickt Steve eine Glückwunschmail an das gesamte Unicorn-Team, über die sich alle freuen. Besonders überraschend ist, dass er auch eine für alle lesbare Antwort an Sarah schreibt und fordert, dass sie »damit aufhören soll, so viel Unruhe zu stiften und Ärger zu machen« und dass sie ihn bitte »so bald wie möglich aufsuchen solle«.

Damit ist der ganze öffentliche E-Mail-Austausch zwischen Sarah, Steve und Bob natürlich nicht zu Ende. Es ist peinlich, mit anzusehen, wie Sarah sich bei unserem neuen Vorstandsvorsitzenden Bob einschleimt. Sie scheint sich gar nicht darum zu kümmern, wie offensichtlich sie das macht und wie viele Brücken sie hinter sich einreißt.

Ich gehe in einen Besprechungsraum, um mich mit John über das Lösen der SOX-404- und Unicorn-Sicherheitsprobleme zu unterhalten. Er trägt ein gestreiftes Hemd mit Manschettenknöpfen sowie eine Weste und sieht aus, als sei er direkt einem Fotoshooting der Vanity Fair entstiegen. Außerdem habe ich den Verdacht, dass er sich mittlerweile täglich den Kopf rasiert.

»Ich bin begeistert, wie schnell die Sicherheitsfixes bei Unicorn integriert werden«, sagt er. »Verglichen mit dem Rest von Phoenix, ist das Beheben von Sicherheitslücken bei Unicorn ein Kinderspiel. Die Zyklen sind so kurz, dass wir neulich einen Fix innerhalb von einer Stunde integriert hatten. Meist dauert es zwar ein oder zwei Tage, aber verglichen damit ist es bei Phoenix eher so, als ob man sich selbst einen Zahn ziehen würde – ohne Betäubung. Normalerweise mussten wir für relevante Änderungen ein ganzes Quartal warten, und der ganze Aufwand, den man treiben musste, um eine Notfallkorrektur durchzubekommen, war oft zu groß.

Wirklich«, fährt er fort, »das Patchen ist so einfach, weil wir in der Produktivumgebung alles per Knopfdruck neu bauen können. Wenn etwas kaputt ist, bauen wir es einfach neu auf.«

Ich nicke. »Ich bin auch davon begeistert, was wir mit den kurzen Unicorn-Zyklen erreichen. Bei Phoenix gibt es nur einmal pro Quartal genehmigte Änderungen. In den letzten drei Wochen haben wir dagegen über 20 Code-und Umgebungs-Deployments mit Unicorn durchgeführt. Das fühlt sich fast schon wie Routine an. Wie Sie sagen – es ist das Gegenteil von Phoenix.«

John sagt: »Die meisten Bedenken, die ich gegenüber Unicorn hatte, scheinen nicht mehr zuzutreffen. Wir haben regelmäßige Checks eingebaut, um sicherzustellen, dass die Entwickler, die Zugriff auf die Produktivumgebung haben, das nur lesend tun können, und wir machen gute Fortschritte beim Integrieren unserer Sicherheitstests in die Build-Prozeduren. Ich bin guter Dinge, dass alle Änderungen, die die Datensicherheit und die Authentifizierungsmodule betreffen, schnell erkannt werden.«

Er lehnt sich zurück und verschränkt seine Arme hinter seinem Kopf. »Ich habe mir bezüglich der Sicherheit von Unicorn vor Angst fast in die Hosen gemacht. Teilweise, weil wir bisher einen ganzen Monat gebraucht hatten, um einen Sicherheits-Review für eine Anwendung durchzuführen. In einem Notfall, aber auch als Reaktion auf einen kritischen Audit-Punkt, konnten wir das auch mal in einer Woche durchziehen.

Und die Idee von zehn Deployments pro Tag?«, fährt er fort. »Total verrückt! Aber nachdem wir gezwungen waren, unsere Sicherheitstests zu automatisieren und sie in den gleichen Prozess zu integrieren, den William für sein automatisiertes QA-Testen nutzt, testen wir jetzt jedes Mal, wenn ein Entwickler Code eincheckt. Wir haben so auf vielerlei Weise eine bessere Sichtbarkeit und Codeabdeckung als in irgendeiner anderen Anwendung in der Firma!«

Er ergänzt: »Ich wollte Ihnen noch erzählen, dass wir gerade den letzten unserer SOX-404-Punkte geschlossen haben. Wir konnten den Auditoren zeigen, dass alle aktuellen Sicherheitsmaßnahmen ausreichend sind, vor allem dank des neuen Change-Control-Prozesses, den Sie eingerichtet haben. Jetzt sind auch die Punkte abgehakt, die seit drei Jahren immer wieder angemeckert wurden.«

Lächelnd fügt er hinzu: »Herzlichen Glückwunsch, Bill. Sie haben etwas geschafft, was keiner Ihrer Vorgänger erreicht hat – uns endlich die Auditoren vom Hals zu halten!«

Zu meiner Überraschung verläuft die kurze Woche problemlos. Bevor am Mittwochabend jeder in seine Thanksgiving-Feiertage verschwindet, wird noch die große Unicorn-Kampagne vorbereitet. Die Codeperformance ist zwar weiterhin zehnmal schlechter als benötigt, aber das ist im Moment in Ordnung, da wir einfach Hunderte Rechnerinstanzen in der Cloud akquirieren können.

Einen echten Showstopper hatten wir, als QA feststellte, dass wir Produkte empfehlen, die gar nicht auf Lager sind. Das wäre ausgesprochen übel gewesen, wenn Kunden begeistert auf die Werbung klicken und dann herausfinden, dass das Produkt nicht lieferbar ist. Unglaublich, aber wahr: Die Entwicklung hat innerhalb eines Tages einen Fix gebaut und innerhalb einer Stunde deployt.

Es ist 18 Uhr, und ich packe meine Sachen zusammen, während ich mich auf das lange Wochenende freue. Wir haben es uns alle verdient.

KAPITEL 34

Freitag, 28. November

Donnerstagmittag – mitten an Thanksgiving – wussten wir, dass wir Probleme haben. Die nächtliche Unicorn-E-Mail-Promotion war ein unglaublicher Erfolg. Die Antwortrate war beispiellos hoch, und der Traffic auf unserer Website erreichte Rekordwerte, wodurch unser E-Commerce-System zu Boden ging.

Wir riefen einen Sev-1-Zwischenfall aus und führten allerlei Notfallmaßnahmen durch, um weiterhin Bestellungen entgegennehmen zu können – unter anderem durch das Einbinden weiterer Server und das Abschalten rechenintensiver Features.

Ironischerweise schlug einer der Entwickler vor, die Echtzeitempfehlungen abzuschalten, an denen wir doch so hart gearbeitet hatten. Warum sollte man weitere zu kaufende Produkte empfehlen, war sein Argument, wenn die Kunden sowieso keine Transaktion abschließen konnten?

Maggie stimmte schnell zu, aber die Entwickler brauchten trotzdem zwei Stunden, um die Änderung umzusetzen und zu deployen. Jetzt kann dieses Feature mit einer Konfigurationseinstellung abgeschaltet werden, sodass es das nächste Mal nur Minuten dauert und keinen kompletten Code-Roll-out benötigt.

Das ist doch mal ein Design für IT Operations! Es wird immer einfacher, den Code im Produktivumfeld zu verwalten.

Wir haben zudem Datenbank-Queries optimiert und die größten Bilder von der Site auf ein Content Distribution Network ausgelagert, um den Traffic noch mehr zu reduzieren. Am späten Nachmittag ist die Customer Experience wieder in einem akzeptablen Rahmen.

Die wirklichen Probleme begannen am folgenden Morgen. Es ist zwar offiziell ein freier Tag in der Firma, aber ich habe jeden Mitarbeiter meines Teams ins Büro geholt.

Wes, Patty, Brent und Maggie sind zum mittäglichen Meeting da. Chris ist ebenfalls anwesend, hat aber offensichtlich entschieden, dass an einem solchen Tag ein anderer Dresscode gilt. Er trägt ein buntes Hawaiihemd und Jeans und hat Kaffee und Donuts für jeden mitgebracht.

Maggie hat das Meeting vor ein paar Minuten eröffnet. »Heute Morgen haben unsere Filialleiter ihre Läden für den Black Friday geöffnet. Sobald die Türen offen waren, strömten Kunden herein und wedelten mit Ausdrucken ihrer Unicorn-Promotion-E-Mails. Die Kundenfrequenz in den Läden ist heute rekordverdächtig. Das Problem ist, dass die beworbenen Produkte mittlerweile fast alle ausverkauft sind. Unsere Filialleiter schieben langsam Panik, weil sie die Kunden verärgern und mit leeren Händen ziehen lassen müssen.

Wenn die Verkäufer dann versuchen, Gutscheine auszustellen oder ein Produkt an den Kunden liefern zu lassen, müssen sie die Bestellung per Hand eingeben. Das dauert jeweils mindestens 15 Minuten, was zu langen Warteschlangen und noch frustrierteren Kunden führt.«

Gerade da piept der Lautsprecher auf dem Tisch. »Sarah wählt sich ein. Wer ist da?«

Maggie verdreht die Augen, und mehrere Leute murmeln untereinander. Sarahs Versuche, Unicorn zu untergraben, sind mittlerweile wohlbekannt. Maggie braucht zwei Minuten, um jeden in der Telefonkonferenz aufzuzählen und Sarah auf den aktuellen Stand zu bringen. »Danke sehr«, sagt Sarah. »Bitte machen Sie weiter.« Maggie bedankt sich höflich und beginnt das Brainstorming zum Lösen der Probleme.

Eine Stunde später haben wir 20 Aktionen zusammengestellt, um die wir uns das ganze Wochenende kümmern werden. Wir werden eine Webseite für die Angestellten in den Läden aufsetzen, auf der sie den Promotion-Code vom Coupon abtippen können. Dadurch wird dann automatisch die Bestellung aus dem Lager aufgegeben. Zusätzlich legen wir ein neues Formular auf der Webseite mit dem Kundenkonto an, über das die Produkte direkt bestellt werden können. Es ist eine lange Liste.

Bis Montagmorgen hat sich die Situation stabilisiert – was gut ist, denn wir haben unser wöchentliches Status-Meeting mit Steve.

Chris, Wes, Patty und John sind bereits da. Anders als bei vorherigen Meetings ist heute auch Sarah dabei. Sie sitzt mit verschränkten Armen da, nur ab und zu tippt sie irgendetwas auf ihrem iPhone.

Steve sagt mit breitem Lächeln: »Ich möchte Ihnen allen für Ihre harte Arbeit danken. Das hat meine kühnsten Träume noch übertroffen. Dank Unicorn brechen wir sowohl in den Filialen als auch im Web einen Rekord nach dem anderen, was dann auch zu rekordverdächtigen Wochenumsätzen führt. Bei der aktuellen Rendite werden wir dieses Quartal tatsächlich profitabel sein – das erste Mal seit Mitte letzten Jahres.

Meinen herzlichsten Glückwunsch an Sie alle«, sagt er.

Alle freuen sich über diese Nachrichten – alle außer Sarah.

»Das ist aber nur die Hälfte der Geschichte«, sagt Chris. »Das Unicorn-Team gibt richtig Gas. Von zweiwöchentlichen Deployments ist es mittlerweile bei wöchentlichen Auslieferungen gelandet, und wir experimentieren mit täglichen Deployments. Weil die Batch-Größe so viel kleiner ist, können wir sehr schnell kleine Änderungen vornehmen. Wir machen ständig A/B-Tests. Kurz gesagt – wir konnten noch nie so schnell auf den Markt reagieren wie jetzt, und ich bin sicher, dass wir da noch mehr Überraschungen präsentieren können.«

Ich nicke nachdrücklich. »Ich würde sagen, wir werden das Unicorn-Modell jetzt bei jeder neuen Anwendung einsetzen, die wir intern entwickeln. Es ist einfacher skalierbar und leichter zu managen als jede Anwendung, die wir in der Vergangenheit betreut haben. Wir richten die Prozesse und Prozeduren so ein, dass wir mit einer beliebigen Rate deployen und damit schnell auf die Kunden reagieren können. In manchen Fällen erlauben wir sogar schon Entwicklern, den Code zu deployen. Der Entwickler kann dann einen Knopf drücken, und innerhalb von Minuten landet der Code in der Test- oder sogar Produktivumgebung.«

»Ich kann es nicht fassen, wie weit wir in so kurzer Zeit gekommen sind. Ich bin sehr stolz auf Sie alle«, sagt Steve. »Ich möchte Sie dafür loben, dass Sie so gut zusammenarbeiten und sich das gegenseitige Vertrauen auch verdienen.«

»Besser spät als nie, vermute ich«, sagt Sarah. »Wenn wir damit fertig sind, uns gegenseitig auf die Schultern zu klopfen, habe ich noch einen Weckruf für Sie alle. Anfang des Monats hat sich unser größter Retail-Konkurrent mit seinen Lieferanten zusammengetan, um Build-to-Order-Kits anzubieten. Die Verkäufe einiger unserer Topseller sind schon um 20 Prozent zurückgegangen, seit sie dieses Angebot machen.«

Verärgert fügt sie hinzu: »Seit Jahren habe ich versucht, die IT dazu zu bringen, die Infrastruktur so auszubauen, dass so etwas bei uns machbar ist, aber alles, was ich gehört habe, ist: ›Nein, das geht nicht.‹ Mittlerweile kann unsere Konkurrenz mit jedem Lieferanten zusammenarbeiten, der da mitmachen will.«

Sie ergänzt: »Das ist der Grund dafür, dass Bobs Idee, die Firma aufzuteilen, so viele Vorzüge hat. Wir werden von der veralteten Herstellung zu sehr eingeschränkt.«

Was? Das Kaufen der Retail-Firma war doch ihre Idee! Es ginge uns allen bestimmt besser, wenn sie dort arbeiten würde.

Steve runzelt die Stirn. »Das ist der nächste Punkt auf der Agenda. Als SVP of Retail Operations ist es Sarahs Vorrecht, Businessanforderungen und -risiken in diesem Team vorzustellen.«

Wes schnaubt. Zu Sarah sagt er: »Sie machen Witze, oder? Haben Sie verstanden, was wir gerade mit Unicorn erreicht haben und wie schnell das ging? Was Sie beschreiben, ist verglichen damit nicht wirklich schwierig.«

Am nächsten Tag kommt Wes mit einem ungewöhnlich verdrießlichen Gesicht herein. »Ähm, Chef, ich hasse es, das sagen zu müssen, aber ich glaube, es geht nicht.«

Als ich ihn um eine Erklärung bitte, sagt er: »Um das zu tun, was unser Konkurrent tut, müssten wir unser Manufacturing Resource Planning System, das die ganzen Produktionsstandorte unterstützt, komplett neu schreiben. Das ist eine alte Mainframe-Anwendung, die wir seit Jahrzehnten nutzen. Wir haben es vor drei Jahren outgesourct. Vor allem, weil alte Leute wie du bald in Rente gehen würden.

Nichts für ungut«, fügt er hinzu. »Wir haben viele unserer Mainframe-Leute vor Jahren entlassen – deren Gehälter waren weit über dem Durchschnitt. Irgendein Outsourcer hat unseren damaligen CIO davon überzeugt, dass er genug grauhaarige Mitarbeiter hätte, um unsere Anwendung zu betreuen, bis wir sie nicht mehr brauchen würden. Unser Plan war, sie durch ein neueres ERP-System zu ersetzen, aber offensichtlich hat das noch nicht geklappt.«

»Verdammt, wir sind doch die Kunden und die unser Anbieter«, sage ich. »Sag ihnen, dass wir sie nicht nur dafür bezahlen, dass sie die Anwendung warten, sondern auch, damit sie notwendige Businessänderungen umsetzen. Laut Sarah brauchen wir diese Änderung. Also versuche, herauszufinden, wie viel sie dafür haben wollen und wie lange wir warten müssen.«

»Das habe ich schon getan«, sagt Wes und zieht einen Stapel Papier unter seinem Arm hervor. »Das ist das Angebot, das sie uns schließlich geschickt haben, nachdem ich es geschafft habe, den blöden Account-Manager zu umgehen und direkt mit einem der technischen Analysten zu sprechen.

Sie brauchen sechs Monate, um die Anforderungen zusammenzustellen, weitere neun Monate zum Entwickeln und Testen, und wenn wir Glück haben, werden wir es in einem Jahr produktiv haben«, fährt er fort. »Das Problem ist, dass die benötigten Ressourcen nicht vor Juni verfügbar sind. Wir reden also über 18 Monate – Minimum. Um überhaupt mit dem Ganzen zu beginnen, wollen sie 50.000 Dollar für die Machbarkeitsstudie und zum Freihalten eines Slots in ihrem Entwicklungszeitplan haben.«

Wes ist mittlerweile knallrot und schüttelt den Kopf. »Dieser nutzlose Account-Manager besteht darauf, dass unser Vertrag es ihm leider nicht erlauben würde, uns zu helfen. So ein Arschloch. Offensichtlich ist es seine Aufgabe, sicherzustellen, dass alles, was in Rechnung gestellt werden kann, auch berechnet wird, und uns davon abzubringen, irgendetwas haben zu wollen, das nicht im Vertrag steht – wie zum Beispiel Entwicklung.«

Ich atme tief aus und überlege, was das für Konsequenzen hat. Diese Einschränkung, die uns daran hindert, das zu tun, was wir tun müssen, liegt außerhalb unserer Organisation. Aber wenn das der Fall ist – was können wir dann machen? Wir können einen Outsourcer nicht dazu bringen, seine Prioritäten oder seine Management-Praktiken so zu ändern, wie wir es getan haben.

Plötzlich manifestiert sich bei mir eine Idee.

»Wie viele Leute sind unserem Account zugewiesen?«, frage ich.

»Ich weiß das nicht genau«, sagt Wes. »Meiner Meinung nach sind es sechs Personen zu je 30 Prozent. Das hängt vermutlich von ihrer Rolle ab.«

»Hol mal Patty her und besorg dir eine Kopie des Vertrags. Dann rechnen wir das mal durch. Und versuche, jemanden aus dem Einkauf dazuzubekommen. Ich habe einen gewagten Vorschlag, den ich genauer anschauen möchte.«

»Wer hat die Anwendung outgesourct?«, fragt Steve hinter seinem Schreibtisch. Ich sitze zusammen mit Chris, Wes und Patty in seinem Büro. Sarah lehnt an einer Wand, aber ich versuche, sie zu ignorieren.

Ich erkläre ihm nochmals unsere Idee. »Vor vielen Jahren wurde entschieden, dass diese Anwendung kein kritischer Teil des Business ist, daher haben wir sie outgesourct, um Kosten zu sparen. Offensichtlich wurde es damals nicht als Kernkompetenz gesehen.«

»Nun, jetzt ist es offensichtlich eine Kernkompetenz!«, antwortet Steve. »Der Outsourcer hält uns als Geisel gefangen und hindert uns daran, etwas zu tun, was getan werden muss. Er ist nicht nur einfach ein Hindernis. Er gefährdet unsere Zukunft.«

Ich nicke. »Kurz gesagt, wir würden gerne den Outsourcing-Vertrag vorzeitig beenden und diese Ressourcen wieder zurück in unsere Firma holen. Wir reden über etwa sechs Leute, von denen einige sowieso schon hier vor Ort arbeiten. Den Vertrag zwei Jahre früher aufzulösen, würde uns fast eine Million Dollar kosten, aber wir würden wieder die volle Kontrolle über die MRP-Anwendung und die darunterliegende Infrastruktur erhalten. Alle in diesem Team glauben, dass das der richtige Schritt wäre, und wir haben sogar schon einen ersten Segen von Dicks Team erhalten.«

Ich halte den Atem an. Das war jetzt gerade eine ziemlich große Nummer, die ich in den Raum geworfen habe. Viel größer als die Budgeterhöhung, nach der ich vor zwei Monaten gefragt habe und bei der mich Steve aus dem Büro geworfen hat.

Schnell fahre ich fort: »Chris geht davon aus, dass wir eine Schnittstelle zu Unicorn bauen könnten, sobald wir diese MRP-Anwendung wieder zurückgeholt haben. Wir würden dann damit beginnen, die Fertigungsressourcen aufzubauen, mit denen wir von ›Build to Inventory‹ zu ›Build to Order‹ wechseln könnten – so wären die Custom-Kits möglich, die Sarah fordert. Wenn wir alles sauber umsetzen und die Integration mit den Auftrags- und Lagerverwaltungssystemen wie geplant abläuft, könnten wir das, was unsere Konkurrenz jetzt macht, in 90 Tagen erreichen.«

Aus dem Augenwinkel sehe ich, wie Sarah hektisch nachdenkt.

Steve lehnt die Idee nicht sofort ab. »Okay, Sie haben meine Aufmerksamkeit. Was sind die größten Risiken?«

Chris meldet sich zu Wort. »Der Outsourcer hat eventuell größere Änderungen an der Codebasis vorgenommen, von denen wir nichts wissen. Das würde die Entwicklung verzögern. Aber meiner persönlichen Meinung nach ist dieses Risiko minimal. Angesichts ihres bisherigen Verhaltens glaube ich nicht, dass sie signifikante Änderungen an der Funktionalität vorgenommen haben.

Um die technischen Herausforderungen mache ich mir keine Sorgen«, fährt er fort. »Das MRP wurde nicht für große Batch-Größen entworfen – und auf keinen Fall für eine Batch-Größe wie die, über die wir hier reden. Aber ich bin sicher, dass wir kurzfristig etwas zum Laufen bekommen und uns dann eine langfristigere Strategie überlegen können.« Als Chris fertig ist, fügt Patty noch hinzu: »Der Outsourcer könnte die Übergabe an uns verkomplizieren, und die betroffenen Techniker könnten verbittert sein. Als wir damals den Vertrag bekannt gegeben hatten, gab es viel Unmut – unter anderem wurde den Kollegen das Gehalt deutlich zusammengestrichen, als sie von Parts Unlimited zu der externen Firma wechseln mussten.«

Sie fährt fort: »Wir sollten John auf jeden Fall direkt mit einbeziehen, weil wir den Outsourcer-Technikern, die wir nicht zu uns holen, die Zugriffsrechte entziehen müssen.«

Wes lacht und sagt: »Dem Blödmann von Account-Manager möchte ich gerne persönlich das Benutzerkonto löschen. So ein Idiot.«

Steve hört aufmerksam zu. Dann wendet er sich an Sarah und fragt: »Was halten Sie von diesem Vorschlag?«

Sarah sagt einige Zeit nichts, dann meint sie überheblich: »Ich denke, wir sollten das mit Bob Strauss besprechen und uns die Erlaubnis des Aufsichtsrats holen, bevor wir ein Projekt angehen, das so groß und riskant ist. Angesichts des früheren Verhaltens der IT könnte das unsere gesamte Fertigung gefährden, was meiner Meinung nach ein zu hohes Risiko wäre. Kurz gesagt – ich persönlich unterstütze diesen Vorschlag nicht.«

Steve schaut Sarah an, dann sagt er mit einem verkniffenen Lächeln: »Denken Sie daran, dass Sie an mich berichten, nicht an Bob. Wenn Sie das nicht verstehen wollen, sollten Sie besser kündigen.«

Sarah wird bleich, und ihr klappt die Kinnlade herunter – offensichtlich hat sie erkannt, dass sie sich verzockt hat.

Sie versucht, ihre Fassung wiederzuerlangen, und lacht nervös über Steves Bemerkung, aber keiner lacht mit. Ich schaue heimlich zu meinen Kollegen, die wie ich mit weit aufgerissenen Augen verfolgen, wie sich dieses Drama entwickelt.

Steve fährt fort: »Im Gegenteil, dank der IT müssen wir uns nicht länger mit all diesen lästigen strategischen Optionen herumschlagen, die Sie und Bob vorbereiten. Aber Ihre Meinung werde ich durchaus berücksichtigen.«

Zum Rest von uns sagt Steve: »Ich bringe Sie mit einem von Dicks besten Leuten und unserem Hausjuristen zusammen. Die werden Ihnen dabei helfen, dieses Projekt sauber über die Bühne zu bringen und sicherzustellen, dass wir vom Outsourcer alles bekommen, was wir brauchen. Und ich werde dafür sorgen, dass Dick diesem Projekt seine volle Aufmerksamkeit widmet.«

Sarahs Augen weiten sich noch mehr. »Das ist eine ausgezeichnete Idee, Steve. So würde unser Risiko deutlich verringert. Ich denke, Bob wird es wirklich gefallen.«

Der Gesichtsausdruck von Steve zeigt, dass seine Geduld mit ihr langsam am Ende ist.

Er fragt uns, ob wir noch etwas benötigen. Als keiner weitere Wünsche hat, bedankt er sich bei allen und beendet das Meeting. Nur Sarah bittet er, noch zu bleiben.

Als wir den Raum verlassen, schaue ich mich noch mal kurz um. Sarah sitzt jetzt dort, wo ich vorher saß, und beobachtet nervös, wie wir gehen. Als sich unsere Blicke treffen, lächle ich ihr zu und schließe die Tür.

KAPITEL 35

Freitag, 9. Januar

Nervös lenke ich meinen Wagen zu Steves Haus. Er schmeißt eine Party für alle, die so hart an Phoenix und Unicorn gearbeitet haben, und hat Leute sowohl aus dem Business als auch aus der IT eingeladen. Die Straßen sind ungewöhnlich glatt, und das Eis darauf schmilzt auch nach Wochen voller Sonnenschein noch nicht. Aus diesem Grund hatten Paige und ich sogar entschieden, Silvester zu Hause zu bleiben, statt wie sonst bei ihrer Familie zu feiern.

Das letzte Meeting mit Steve und Sarah ist jetzt über einen Monat her. Sehr viel haben wir seitdem nicht mehr von ihr gesehen.

Während ich unterwegs bin, fällt mir auf, wie ruhig es gewesen ist. Ich warte eigentlich nur darauf, dass jemand einen weiteren Sev-1-Zwischenfall ausruft. Stattdessen sitzt mein Handy still in seiner Halterung – genau wie gestern und auch schon vorgestern.

Ich kann nicht sagen, dass ich die ganze Aufregung vermisse, aber manchmal habe ich mittlerweile tatsächlich nichts zu tun.

Glücklicherweise kann ich dadurch nun all meine Manager bei unseren zweiwöchigen Zyklen begleiten, die sich am Verbesserungs-Kata orientieren, sodass ich mich nicht ganz nutzlos fühle. Ich bin besonders stolz darauf, dass es meine Gruppe einen ganzen Monat lang geschafft hat, unser Ziel zu erreichen, 15 Prozent der Zeit für den Einsatz für präventive Infrastrukturprojekte aufzubringen. Und es zahlt sich aus.

Wir nutzen das gesamte Budget, das uns zugewiesen wurde. Wir schließen unsere Monitoring-Lücken, wir haben unsere zehn instabilsten Systeme oder Anwendungen refaktoriert oder ersetzt, sodass sie jetzt stabiler sind, und der Fluss der geplanten Arbeit ist schneller als je zuvor. Entgegen meinen Erwartungen hat sich jeder begeistert am Projekt Narwal beteiligt, das bisher unter dem Namen »Simian Army Chaos Monkey« bekannt war. Wie bei den legendären Geschichten um die Apple Mac OS- und Netflix-Cloud-Delivery-Infrastruktur haben wir Code deployt, der regelmäßig größere Ausfälle produziert und dabei zufällig Prozesse oder ganze Server abschießt.

Das sorgte eine ganze Woche lang für absolutes Chaos, weil unsere Test- und gelegentlich sogar die Produktivinfrastruktur wie Kartenhäuser in sich zusammenbrachen. Aber in den folgenden Wochen arbeiteten Entwicklung und IT Operations zusammen, um unseren Code und die Infrastruktur widerstandsfähiger gegen Ausfälle zu machen. Jetzt haben wir IT-Services, die belastbar, robust und haltbar sind.

John war davon total begeistert und hat ein neues Projekt namens »Evil Chaos Monkey« gestartet. Statt operationelle Ausfälle im Produktivumfeld zu erzeugen, wird hier versucht, fortlaufend Sicherheitslücken auszunutzen, unsere Anwendungen mit fehlerhaften Paketen zu fluten, Backdoors zu installieren, Zugriff auf vertrauliche Daten zu erhalten und andere schändliche Attacken auszuführen.

Natürlich hat Wes versucht, das aufzuhalten. Er bestand darauf, dass wir Penetration-Tests in vordefinierten Zeiträumen einplanen. Aber ich habe ihn davon überzeugt, dass dies die schnellste Möglichkeit ist, Eriks Dritten Weg umzusetzen. Wir müssen eine Kultur gestalten, in der man dabei unterstützt wird, Risiken einzugehen und aus seinen Fehlern zu lernen. Zudem macht die sprichwörtliche Übung den Meister.

Ich will keine Poster über Qualität und Sicherheit haben. Ich will Verbesserungen unserer täglichen Arbeit dort haben, wo sie benötigt werden – in unserer täglichen Arbeit.

Johns Team hat Tools entwickelt, die jede Test- und Produktivumgebung kontinuierlich mit einem Sperrfeuer aus Angriffen belegt. Und wie beim ersten Release des Chaos Monkey waren danach alle die Hälfte der Zeit damit beschäftigt, Sicherheitslücken zu schließen und ihren Code zu härten. Nach vielen Wochen waren die Entwickler dann aber verdientermaßen stolz auf ihre Arbeit und konnten erfolgreich alle Angriffe abwehren, die Johns Team losließ.

Diese Gedanken gehen mir durch den Kopf, während ich auf dem Weg zu Steves Haus bin. Die Gärten sind mit Schnee bedeckt, der die makellos manikürten Rasen versteckt.

Als ich – wie von Steve gewünscht – eine Stunde vor Partybeginn an der Tür klingle, höre ich ein lautes Bellen und das Geräusch eines sehr großen Hundes, der auf glattem Boden ins Rutschen kommt und gegen die Tür kracht.

»Kommen Sie herein, Bill. Schön, Sie wiederzusehen«, sagt Steve, hält den Hund mit der einen Hand am Halsband fest und weist mit einem Gemüsespieß in der anderen auf die Küche. Dort angekommen, zeigt er auf den Tresen. Ich sehe einen großen Eimer voller Eis, aus dem Flaschen ragen. »Möchten Sie etwas trinken? Bier? Wasser? Scotch?« Er schaut sich um und fügt hinzu: »Margarita?«

Ich nehme mir ein Bier aus dem Eimer, bedanke mich und gebe ihm dann einen kurzen Überblick über meine recht langweiligen Tage, während wir ins Wohnzimmer gehen.

Steve lächelt. »Schön, dass Sie früher kommen konnten. Wir werden ein Rekordquartal haben. Ohne Sie und Chris wäre das nicht möglich gewesen. Das erste Mal seit Jahren steigt unser Marktanteil! Wissen Sie, ich würde ja gern den Blick unserer Konkurrenten sehen. Vermutlich sind sie ganz durcheinander und fragen sich, wie wir das gemacht haben.«

Er lächelt jetzt noch breiter. »Gestern habe ich sogar gesehen, wie Dick kurz gelächelt hat. Na ja, immerhin hat man seine Zähne gesehen. Projekt Unicorn und dieses neue Projekt, Narwal, helfen uns dabei, zu verstehen, was die Kunden wirklich wollen. Unsere mittlere Auftragsgröße hat letzte Woche unbekannte Höhen erreicht, und Dick hat gesagt, dass Unicorn das sich am schnellsten amortisierende Projekt der jüngeren Geschichte ist.«

Er fährt fort: »Die Analysten haben uns wieder lieb. Einer hat mir letzte Woche erzählt, dass es für unsere nicht integrierten Konkurrenten sehr schwer sein wird, uns zu folgen, wenn wir so weitermachen. Ohne Zweifel werden sie unser Kursziel erhöhen, und Bob hat endlich seine Unterstützung für das Aufteilen der Firma zurückgezogen.«

»Wirklich?«, sage ich und hebe überrascht die Augenbrauen. »Ich dachte, dass Sarah davon überzeugt war, nur ein Aufteilen der Firma würde uns überleben lassen.«

»Ah, ja ...«, sagt er. »Sarah hat sich dazu entschieden, sich anderweitig umzusehen, und ist aktuell freigestellt.«

Mir klappt die Kinnlade herunter. Wenn ich das richtig verstehe, wurde Sarah aus der Firma komplimentiert. Ich lächle.

»Ach übrigens«, sagt Steve. »Projekt Narwal? Projekt Unicorn? Können Sie sich nicht mal bessere Namen ausdenken?«

Ich lache. »Keiner ärgert sich mehr darüber als Maggie. Sie ist davon überzeugt, dass sich all ihre Produktmanager schon über sie lustig machen. Ihrem Mann hat sie erzählt, dass sie kündigt, wenn das nächste Projekt ›Hello Kitty‹ heißen wird.«

Er lacht. »Wie Sie sicherlich vermuten, habe ich Sie nicht gebeten, früher zu kommen, um an Ihren Projektnamen herumzukritteln. Setzen Sie sich.«

Als ich es mir in einem Sessel bequem gemacht habe, erklärt er mir: »Seit Monaten ist bei uns der Posten des CIO unbesetzt. Sie haben ja einige Gespräche mit Kandidaten geführt. Was war da Ihr Eindruck?«

»Ganz ehrlich? Ich war enttäuscht«, sage ich langsam. »Das waren alles ältere Herren mit viel mehr Erfahrung, als ich sie habe. Aber sie redeten immer nur über kleine Teile des Problems. Vorgeschlagen wurde nur ein Bruchteil dessen, was wir in den letzten Monaten hier bei Parts Unlimited erreicht haben. Ich habe das Gefühl, dass wir eher wieder zu den schlechten alten Zeiten zurückkehren, wenn einer von denen CIO würde.«

»Da stimme ich Ihnen zu, Bill. Darum habe ich mich dazu entschlossen, diese Position intern neu zu besetzen. Haben Sie Vorschläge, wen wir da ins Auge fassen sollten?«

Ich gehe die möglichen Kandidaten im Kopf durch. Es ist keine lange Liste. »Ich denke, Chris ist deutlich die erste Wahl. Er war die treibende Kraft hinter Unicorn und auch hinter Narwal. Wenn er die Leitung nicht in der Hand gehabt hätte, würden wir sicherlich immer noch auf der Stelle treten.«

Er lächelt. »Wissen Sie, das ist lustig. Jeder, mit dem ich geredet habe, war der Meinung, dass Sie genau das sagen würden. Aber ich werde Ihrem Vorschlag nicht folgen.«

Steve fährt fort: »Dazu muss ich jetzt ein bisschen weiter ausholen. Sie waren bei allen der Lieblingskandidat für den neuen CIO. Aber um ganz ehrlich zu sein: Ich will Sie auf diesem Posten nicht haben.«

Ich fühle mich überrumpelt, und er beeilt sich zu sagen: »Hey, entspannen Sie sich. Lassen Sie es mich erklären. Der Aufsichtsrat hat mir die Verantwortung übertragen, die Firmenressourcen so gut wie möglich zu nutzen, um den Shareholder Value zu maximieren. Meine Hauptaufgabe ist, mein Management-Team so zu führen, dass das passiert.«

Er steht auf, geht zum Fenster und sieht auf den schneebedeckten Hof hinaus. »Sie haben mir dabei geholfen, zu erkennen, dass IT nicht einfach nur eine Abteilung ist. Stattdessen ist sie allgegenwärtig, so wie Elektrizität. Es ist eine Fertigkeit, so wie lesen oder rechnen zu können. Hier bei Parts Unlimited haben wir keine zentrale Lese- oder Rechenabteilung – wir erwarten, dass jeder, den wir einstellen, das beherrscht. Zu verstehen, was Technologie kann und was sie nicht kann, ist zu einer Kernkompetenz geworden, die jeder Teil dieses Business beherrschen muss. Wenn einer meiner Businessmanager ein Team oder ein Projekt leitet, ohne diese Fertigkeit zu besitzen, wird er keinen Erfolg haben.«

Steve fährt fort: »Jeder meiner Businessmanager muss kalkulierte Risiken eingehen, ohne die gesamte Firma zu gefährden. Die Leute im Business nutzen alle Technologie, daher ist es wieder wie im Wilden Westen – im Guten wie im Schlechten. Firmen, die sich in dieser neuen Welt nicht behaupten, werden verschwinden.«

Er wendet sich wieder mir zu und sagt: »Damit Parts Unlimited überleben kann, können Business und IT nicht mehr unabhängig voneinander Entscheidungen treffen. Ich weiß nicht, wohin das alles führen wird, aber ich weiß, dass wir in der momentanen Organisationsform nicht mit voller Kraft laufen.

Ich habe das in den letzten Monaten mit dem Aufsichtsrat diskutiert«, sagt er, setzt sich wieder hin und schaut mich an. Ich kenne diesen Ausdruck – von meinem ersten Meeting mit ihm im letzten Jahr. So sieht er jemanden an, wenn er ihn zu etwas bringen will. »Ich bin von Ihrer Leistung und von dem, was Sie aus der IT gemacht haben, sehr beeindruckt. Sie haben die gleichen Fertigkeiten genutzt, die ich auch von jemandem erwarten würde, der eine unserer großen Fertigungsabteilungen leitet.

Jetzt möchte ich sehen, wie Sie wachsen und lernen und neue Fertigkeiten erwerben, um möglichst allen bei Parts Unlimited zu helfen. Wenn Sie mitmachen, bin ich gerne bereit, in Sie zu investieren. Ich möchte, dass Sie zwei Jahre lang Erfahrungen sammeln. Sie werden überall hineinschnuppern – beim Vertrieb und im Marketing mitmachen, eine Fertigungsanlage leiten, internationale Erfahrungen sammeln, an den Beziehungen zu unseren wichtigsten Lieferanten arbeiten und unsere Lieferkette betreuen. Glauben Sie mir, das wird kein Zuckerschlecken sein. Sie werden Hilfe brauchen – und zwar viel. Erik hat sich freundlicherweise dazu bereit erklärt, Ihr Mentor zu sein, weil wir beide glauben, dass dies das Schwierigste sein wird, was Sie je getan haben.

Aber«, fährt er fort, »wenn Sie alle 15 spezifischen Performanceziele erreichen, die wir für Sie vorbereitet haben, werden Sie in zwei Jahren die Rolle eines vorläufigen Chief Operating Officer einnehmen. Dann arbeiten Sie eng mit Dick zusammen, während er sich auf seinen Ruhestand vorbereitet. Wenn Sie hart arbeiten, gute Ergebnisse liefern und geschickt vorgehen, werden Sie in drei Jahren der nächste COO der Firma sein.«

Mir steht der Mund offen, und von meiner Bierflasche tropft Kondenswasser auf meine Beine.

»Sie müssen jetzt noch nicht zusagen«, sagt Steve, offensichtlich zufrieden, dass sein Vorschlag den gewünschten Effekt hat. »Die Hälfte des Aufsichtsrats ist der Meinung, ich sei verrückt. Vielleicht haben sie recht, aber ich vertraue auf meine Instinkte. Ich weiß nicht, wie das ausgehen wird, aber ich bin zuversichtlich, dass dies das Beste für die Firma sein wird. Mein Bauch sagt mir, dass wir in zehn Jahren, wenn wir die letzten Reste der Konkurrenz in einer Ecke zusammenkehren, erkennen werden, dass dieser Schritt das möglich gemacht hat.

Und wenn wir schon dabei sind, zu träumen, will ich noch etwas sagen«, fährt er fort. »Ich bin sicher, dass in zehn Jahren jeder COO, der sein Geld wert ist, aus der IT kommen wird. Jeder COO, der nicht genau die IT-Systeme versteht, mit denen seine Firma läuft, wird dann nur ein Strohmann sein, der auf jemand anderen bauen muss, um seinen Job zu machen.«

Steves Vision raubt mir den Atem. Er hat recht. Alles, was mein Team gelernt hat – und was auch Chris und John gelernt haben –, zeigt, dass das Business verliert, wenn die IT verliert. Wenn die IT organisiert genug ist, um erfolgreich sein zu können, ist auch das Business erfolgreich.

Und Steve will mich zum Vorreiter dieser Bewegung machen.

Mich. Einen technischen Operationsmenschen.

Plötzlich muss ich daran denken, wie einer von Eriks Vorgesetzten beim Militär entschied, ihn von einem Gunnery Sergeant zu einem Second Lieutenant zu machen und ihn damit zu zwingen, die Karriereleiter wieder von ganz unten hochzuklettern. Offensichtlich hatte Erik die Courage, das zu tun, was sich für ihn (und seine Familie, so er denn eine hat) anscheinend ausgezahlt hat. Er lebt ein Leben, das abgehoben zu sein scheint von dem Leben von uns Normalsterblichen.

Als ob Steve wüsste, was ich gerade denke, sagt er: »Wissen Sie, als Erik und ich uns vor vielen Monaten das erste Mal trafen, sagte er, dass die Beziehung zwischen IT und Business wie eine nicht richtig funktionierende Ehe ist – beide fühlen sich machtlos und vom anderen als Geisel genommen. Ich habe darüber Monate nachgedacht und schließlich etwas erkannt.

Eine nicht funktionierende Ehe zwischen den beiden Bereichen geht davon aus, dass Business und IT zwei getrennte Einheiten sind. IT sollte entweder in Business Operations oder direkt in Business eingebunden werden. Voilà! Fertig. Keine Spannungen. Keine Ehe – und vielleicht auch keine IT-Abteilung.«

Ich starre Steve an. Auf irgendeine Erik-hafte Weise ist das, was er sagt, unausweichlich wahr.

In diesem Moment entscheide ich mich. Ich muss noch mit Paige reden, aber ich weiß ziemlich sicher, dass die Reise, auf die Steve mich schicken will, wichtig ist – sowohl für mich und meine Familie als auch für meinen ganzen Berufsstand.

»Ich werde darüber nachdenken«, sage ich ernst.

Steve lächelt breit und steht auf. Als ich seine ausgestreckte Hand ergreife, schlägt er mir kräftig auf die Schulter. »Gut. Das wird Spaß machen.«

Genau da klingelt es an der Tür, und innerhalb von ein paar Minuten ist die ganze Gang da – Wes, Patty, John und Chris, aber auch Maggie, Brent, Ann und – meine Güte – sogar Dick und Ron.

Als die Party in Fahrt kommt, gratuliert mir jeder. Es ist offensichtlich, dass alle Bescheid wussten – auch über Steves verblüffendes Angebot, ein dreijähriges Training durchzumachen, um der nächste COO zu werden.

Dick gesellt sich mit einem Glas Scotch zu mir. »Herzlichen Glückwunsch, Bill. Ich freue mich darauf, mit Ihnen in den nächsten Jahren eng zusammenzuarbeiten.«

Kurz darauf finde ich mich unter diesen vielen Leuten wieder, nehme ihre Glückwünsche entgegen und lache über Geschichten von der erstaunlichen Reise, auf der wir uns befinden.

Wes schlägt mir auf die Schulter. »Nachdem du jetzt befördert wurdest«, sagt er noch lauter und schnoddriger als normal, »haben wir gedacht, du sollst etwas bekommen, das dich daran erinnert, was wir erreicht haben. Etwas, das dich begleitet und das dich daran erinnert, das einfache Volk nicht zu vergessen.«

Als er in die Kiste zu seinen Füßen greift, sagt er: »Wir haben lange darüber diskutiert, was es sein soll. Aber letztendlich lag es doch ziemlich auf der Hand ...«

Als ich sehe, was er aus der Kiste holt, breche ich in schallendes Gelächter aus.

»Dein alter Laptop!«, ruft er und hält ihn hoch. »Es war ein Schande, ihn durch das Bronzieren unbenutzbar zu machen, aber du musst zugeben – er ist schick, oder?«

Ungläubig schaue ich ihn an, während alle lachen, klatschen und mich hochleben lassen. Es ist wirklich mein alter Laptop. Ich nehme ihn Wes ab und sehe das gebrochene Scharnier und das Klebeband, mit dem der Akku befestigt ist. Und jetzt ist der gesamte Laptop mit einer dicken Schicht Goldfarbe bedeckt und auf einer Mahagoniplatte befestigt.

Unten auf der Platte befindet sich eine Bronzetafel. Ich lese sie laut vor: »In guter Erinnerung an unseren lieben, von uns gegangenen Bill Palmer, VP of IT Operations«, in Klammern dahinter steht noch die Jahreszahl.

»Mensch, Leute«, sage ich, ehrlich gerührt von dieser Geste. »Das klingt ja so, als ob ich schon tot wäre!«

Alle lachen, auch Steve. Die Zeit geht schnell rum, und ich bin selbst überrascht, dass ich mich so wohlfühle. Eigentlich bin ich nicht so der Partyheld, aber heute habe ich das Gefühl, mich in Gesellschaft von Freunden und Kollegen zu befinden, die ich respektiere, denen ich vertraue und die ich wirklich mag.

Irgendwann später trifft Erik ein. Er kommt zu mir herüber und schaut sich den Bronzelaptop genauer an. »Wissen Sie, auch wenn ich Ihnen nur eine Fünfzig-Prozent-Chance gebe, dass Sie durchhalten, glaube ich trotzdem an Sie«, sagt er, während er sein Bier leert. »Herzlichen Glückwunsch, Junior. Sie haben es verdient.«

»Danke sehr«, sage ich breit lächelnd und wirklich gerührt von seinem kleinen Lob.

»Ja, aber enttäuschen Sie mich nicht«, sagt er barsch. »Ich habe diese Stadt noch nie gemocht, und Ihretwegen muss ich jetzt jahrelang hier an diesem furchtbaren Flughafen landen. Wenn Sie es vermasseln, war das alles umsonst.«

»Ich werde mein Bestes geben«, sage ich erstaunlich zuversichtlich. »Moment mal. Ich dachte, Sie würden sowieso immer zu den Aufsichtsrats-Meetings kommen.«

»Nach dem, was ich hier gesehen habe, will ich gar nicht dazugehören!«, sagt Erik und lacht laut. »Ich denke, Parts Unlimited wird viel Geld verdienen. Wir werden sehen, wie gut Ihre Konkurrenten wirklich sind, aber ich habe den Verdacht, dass sie keine Vorstellung haben, was sie da erwischt hat. Für mich ist das jedoch nicht nur graue Theorie. Wenn alles wie geplant läuft, werde ich in ein paar Wochen sehr wahrscheinlich einer der größten Investoren dieser Firma sein. Und das Letzte, was ich dann brauche, ist, dass mir ein Haufen Insiderinformationen meine Chancen auf den Aktienhandel verderben!«

Ich starre Erik an. Er hat genug Geld, um einer unserer größten Investoren zu werden, kleidet sich aber trotzdem immer noch wie ein Fabrikarbeiter? Ich hätte nie gedacht, dass er sich so um sein Geld kümmert.

Schließlich frage ich schlicht: »Was meinen Sie mit ›Insiderinformationen‹?«

»Ich glaube schon seit langer Zeit, dass das effektive Managen der IT nicht nur eine entscheidende Kompetenz ist, sondern auch ein signifikantes Zeichen für den Firmenerfolg«, erklärt er. »In den nächsten Tagen möchte ich gerne einen Hedgefonds einrichten, der per Long Position in Firmen mit erstklassigen IT-Organisationen investiert, die dem Business dabei helfen, erfolgreich zu sein, und eine Short Position für Firmen umsetzt, bei denen IT alles herunterzieht. Ich denke, das wird der Knaller. Wie kann man sonst die nächste Generation von CEOs dazu bringen, sich um IT zu kümmern?«

Er fährt fort: »All das kann ich nicht machen, wenn ich in diesen Firmen im Aufsichtsrat sitze. Das sähe nicht gut aus. Zu viel Konfliktpotenzial mit dem SEC, den Auditoren und dem ganzen Mist.«

»Ah«, sage ich.

»Hey, entschuldigen Sie die Störung«, mischt sich John ein, »aber ich möchte Ihnen gratulieren und meinen Respekt aussprechen.« Dann hält er auch Erik die Hand hin und sagt: »Und Ihnen auch, Sir.«

Erik ignoriert seine Hand und starrt ihn von oben bis unten an. Dann lacht er und schüttelt sie doch. »Sie haben einen weiten Weg hinter sich gebracht. Sehr gut. Und übrigens, ich mag Ihren neuen Look. Sehr Euro-Diskothek.«

»Danke, Erwin«, sagt er trocken. »Ohne Sie hätte ich das nicht geschafft. Ich bin Ihnen sehr dankbar.«

»Gern geschehen«, sagt Erik jovial. »Aber treiben Sie sich nicht zu viel mit den Auditoren herum. Das ist für niemanden gut.«

John nickt zustimmend und verschwindet wieder im Partytreiben. Erik wendet sich mir zu und sagt verschwörerisch: »Nun, das ist doch mal eine wirklich bemerkenswerte Wandlung, oder?«

Ich drehe mich zu John um. Er lacht und tauscht gerade Beleidigungen mit Wes aus.

»Also«, sagt Erik und unterbricht meine Gedanken, »wie sehen Ihre Pläne für den Rest der IT-Organisation aus? Mit Ihrer Beförderung müssen Sie jetzt ein paar Jobs neu besetzen.«

Ich wende mich wieder Erik zu. »Ganz ehrlich, das hätte ich nie geahnt.« Erik schnaubt ungläubig, was ich aber ignoriere. »Wes, Patty und ich haben viel darüber geredet. Ich bin sicher, dass ich Patty zur VP of IT Operations machen werde. Sie kommt einer Betriebsleiterin für IT Operations so nahe wie sonst niemand, und sie kann die Leute auch antreiben«, sage ich lächelnd.

»Gute Wahl«, sagt er. »Auf jeden Fall sieht sie nicht wie ein typischer IT Operations-Manager aus ... Und Wes?«

»Ob Sie es glauben oder nicht, Wes hat ziemlich deutlich gemacht, dass er auf keinen Fall VP of IT Operations sein möchte«, antworte ich. Etwas unsicherer sage ich: »Wenn ich meine Rolle als CIO in zwei Jahren wieder aufgeben soll, muss Wes meiner Meinung nach eine schwere Entscheidung treffen. Wenn ich einen Wunsch frei hätte, sollte er Patty als VP of IT Operations ablösen, und sie sollte die nächste CIO werden. Aber wie soll ich alle darauf vorbereiten, wenn Steve immer mehr Verantwortung auf mir ablädt?«

Erik verdreht die Augen. »Jetzt mal halblang. In Ihrer aktuellen Rolle langweilen Sie sich. Sie werden aber bald viel weniger Langeweile haben – sehr bald. Und denken Sie daran, dass Sie von vielen erfahrenen Leuten umgeben sind, die einen ähnlichen Weg zurückgelegt haben. Seien Sie also nicht der Idiot, der auf die Schnauze fliegt, weil er nicht um Hilfe bittet.«

Er will gehen, aber dann sieht er mich noch einmal mit einem Glitzern in seinen Augen an. »Wo wir gerade von Hilfe für andere Leute reden – ich denke, Sie schulden mir etwas.«

»Natürlich«, antworte ich aufrichtig und frage mich plötzlich, ob das nicht von Anfang an ein abgekartetes Spiel war. »Was auch immer Sie wollen.«

»Sie sollen mir dabei helfen, das Wissen um das Technologie-Management zu verbreiten. Seien wir doch einmal ehrlich. Das Leben in der IT ist ziemlicher Mist, wenn sie so missverstanden und schlecht gemanagt wird. Es wird undankbar und frustrierend, wenn die Leute merken, dass sie keinen Einfluss auf das Ergebnis haben – so wie ein sich immer wiederholender Horrorstreifen. Das kann das Selbstwertgefühl nachhaltig beschädigen, und das muss sich ändern«, sagt er leidenschaftlich. »Ich will in den nächsten fünf Jahren das Leben von einer Million IT-Mitarbeitern verändern. Und jemand sehr Weises hat mir einmal gesagt: ›Ein Messias ist gut, aber eine Heilige Schrift ist besser.‹«

Er sagt: »Ich möchte, dass Sie ein Buch schreiben, in dem die Drei Wege beschrieben werden und in dem steht, wie andere Leute die Wandlung wiederholen können, die Sie hier bei Parts Unlimited vollzogen haben. Nennen Sie es The DevOps Cookbook und zeigen Sie, wie IT wieder das Vertrauen von Business gewinnen kann und wie sich Jahrzehnte von Stammeskriegen beenden lassen. Können Sie das für mich tun?«

Ein Buch schreiben? Das meint er doch nicht ernst.

Ich antworte: »Ich bin kein Autor. Ich habe noch nie ein Buch geschrieben. Tatsächlich habe ich seit vielen Jahren nichts Längeres als eine E-Mail verfasst.«

Nicht sehr erfreut sagt er ernst: »Lernen Sie es.«

Ich schüttle kurz meinen Kopf, dann sage ich schließlich: »Natürlich. Es wäre mir eine Ehre und ein Privileg, The DevOps Cookbook für Sie zu schreiben, während ich mich auf meine vermutlich herausforderndsten drei Jahre meiner gesamten Karriere vorbereite.«

»Sehr gut. Das wird ein tolles Buch werden«, sagt er lächelnd. Dann schlägt er mir auf die Schulter. »Und jetzt genießen Sie wieder den Abend. Sie haben es sich verdient.«

Ich schaue mich um. Alle Kollegen haben wirklich Spaß und erfreuen sich an diesem Abend. Mit meinem Bier in der Hand denke ich darüber nach, wie weit wir gekommen sind. Während des Phoenix-Launchs wäre wohl keiner in dieser Gruppe auf die Idee gekommen, einmal Teil einer Gemeinschaft zu sein, die größer als nur Dev oder Ops oder Security ist. Es gibt einen Begriff, den wir in letzter Zeit häufiger gehört haben: »DevOps«. Vielleicht ist jeder, der heute hier ist, Teil von DevOps, aber ich vermute, es ist mehr als nur das. Es geht darum, dass Produkt-Management, Entwicklung, IT Operations und selbst IT-Sicherheit zusammenarbeiten und sich gegenseitig unterstützen. Selbst Steve ist Teil dieser Gemeinschaft.

In diesem Moment weiß ich, wie unglaublich stolz ich auf jeden hier im Raum bin. Es ist wirklich erstaunlich, was wir geschafft haben, und obwohl meine eigene Zukunft wohl so unsicher ist wie noch nie in meinem Berufsleben, freue ich mich auf die Herausforderungen der kommenden Jahre.

Während ich einen weiteren Schluck Bier nehme, fällt mir etwas auf. Ein ganzer Haufen meiner Mitarbeiter schaut auf ihre Smartphones. Kurz danach schaut auch einer der Entwickler, die mit Brent zusammenstehen, auf sein Smartphone, während sich alle um ihn herumdrängeln.

Meine alten Instinkte kommen wieder zum Vorschein, und ich suche den Raum nach Patty ab, die mit ihrem Telefon in der Hand schon auf dem Weg zu mir ist.

»Erst einmal herzlichen Glückwunsch, Chef«, sagt sie mit einem verhaltenen Lächeln auf den Lippen. »Willst du erst die guten oder erst die schlechten Nachrichten hören?«

Voll Ruhe und innerem Frieden sage ich: »Was ist denn passiert, Patty?«

ANHANG

Weiterführende Informationen

Einführung

Warum DevOps?

Woher DevOps kommt

Erklärung zu den drei Wegen

Topmythen von DevOps

Die vier Arten der Arbeit

Weitere Quellen

Einführung

Auch im Namen meiner Mitautoren möchte ich mich sehr dafür bedanken, dass Sie dieses Buch gelesen haben.

Projekt Phoenix handelt davon, wie ein tiefgreifender und chronischer Konflikt zwischen der Entwicklung und IT Operations die Grundlage für das Versagen der gesamten IT-Organisation und der von ihr betreuten Abteilungen liefert. Ungelöst, verlängert der Konflikt die Auslieferungszeit für die Entwicklungsgruppe, sorgt für längere und kompliziertere Deployments beim Veröffentlichen von neuen Features, lässt die Anzahl an Sev-1-Ausfällen größer werden, und IT Operations versinkt mehr und mehr in ungeplanter Arbeit, wodurch es schwer wird, die technischen Schulden abzuarbeiten.

Wir wissen jetzt, dass es möglich ist, diesen Konflikt zwischen Entwicklung und IT Operations aufzubrechen. Beweis dafür sind sehr gut laufende Firmen wie Amazon, Google, Twitter, Etsy und Netflix, die einen Satz neuer Techniken umgesetzt haben, die wir mittlerweile als DevOps bezeichnen. Diese Firmen deployen täglich Hunderte oder sogar Tausende produktiver Änderungen, bleiben dabei aber ausgesprochen zuverlässig, stabil und sicher. Durch das Einführen kultureller Normen, Prozesse und Praktiken erreichen diese High-Performer eine atemberaubende Leistung.

Sie können Änderungen schnell in die Produktivumgebung einfließen lassen, wobei die Code Deployment Lead Time¹ in Minuten oder Stunden zu messen ist. Dadurch bleiben die Firmen innovativ, sie können mit einem experimentellen Ansatz ihre Konkurrenz aus dem Feld schlagen, behalten aber eine hohe Qualität bei und sorgen für eine bessere Benutzererfahrung.

Warum DevOps?

Der Vorteil gegenüber der Konkurrenz, der durch DevOps entstehen kann, ist enorm – eine schnellere Auslieferung von Features, eine erhöhte Kundenzufriedenheit, mehr Marktanteile, eine bessere Mitarbeiterproduktivität und glücklichere Kollegen. Warum? Weil Technologie zum dominanten Wertschöpfungsprozess geworden ist und bei der Kundengewinnung in den meisten Unternehmen immer wichtiger (wenn nicht am wichtigsten) wird.

Firmen, die Wochen oder Monate für das Ausliefern von Software benötigen, müssen dagegen im Markt einen deutlichen Nachteil hinnehmen.

Firma | Auslieferungsfrequenz | Code Deployment Lead Time | Zuverlässigkeit | Reaktion auf Kundenwünsche
Amazon | 23.000/Tag | Minuten | hoch | hoch
Google | 5.500/Tag | Minuten | hoch | hoch
Netflix | 500/Tag | Minuten | hoch | hoch
Facebook | 1/Tag | Stunden | hoch | hoch
Twittera | 3/Woche | Stunden | hoch | hoch
Klassische Firma | 1/alle 9 Monate | Monate oder Quartale | niedrig/mittel | niedrig/mittel

a Für ein monolithisches Ruby on Rails-Frontend.

Die High-Performer zeichnet aus, dass sie »sich schneller von den anderen absetzen«. Mit anderen Worten: Die besten werden immer noch besser.

Diese konstante und schonungslose Performanceverbesserung geschieht auch in DevOps. 2009 wurden zehn Deployments pro Tag als schnell angesehen. 2012 hielt Amazon (laut eigener Aussage) den Rekord mit durchschnittlich 23.000 Deployments pro Tag.

Geschäftswerte durch das Übernehmen von DevOps-Prinzipien

Im Puppet Labs-Bericht »State of DevOps Report«² aus dem Jahr 2012 konnten wir 4.039 IT-Organisationen vermessen. Dies hatte zum Ziel, den Status und die Verhaltensweise von Organisationen in allen Stadien der DevOps-Adaption besser zu verstehen.

Die erste Überraschung war, wie sehr die High-Performance-Unternehmen, die DevOps-Praktiken einsetzen, ihre Nicht-High-Performance-Konkurrenten ausstachen. Das gilt sowohl für die Agilität:

• 30 Mal häufigere Code-Deployments

• 8.000 Mal kürzere Code Deployment Lead Time

Aber auch die Zuverlässigkeit ist größer:

• 2 Mal bessere Change Success Rate

• 12 Mal schnellere MTTR

Mit anderen Worten – sie waren agiler. Die Firmen haben Code 30 Mal häufiger deployt, und die Zeit vom Code-Commit bis zum erfolgreichen Einsatz im Produktivsystem war 8.000 Mal kürzer. High-Performer haben Lead Times, die in Minuten oder Stunden gemessen werden, während schlechtere Firmen Lead Times in Wochen, Monaten oder gar Quartalen vorzuweisen haben.

Aber die Unternehmen konnten nicht nur mehr Arbeit erledigen, sie hatten auch bessere Ergebnisse: Wenn die High-Performer Code ausgeliefert haben, war das doppelt so häufig erfolgreich (also ohne Produktionsausfälle oder Probleme mit dem Server), und wenn das Deployment doch fehlschlug, war die Zeit zum Lösen dieses Problems 12 Mal kürzer.

Diese Studie war insbesondere deshalb so interessant, weil sie empirisch zeigte, dass der grundlegende chronische Konflikt aufgebrochen werden kann: High-Performer liefern Features schneller aus, bieten dabei aber trotzdem beste Zuverlässigkeit, Stabilität und Sicherheit, wodurch sie ihrer Konkurrenz mit einem experimentellen Ansatz davonziehen können. Und noch erstaunlicher: Diese hohe Zuverlässigkeit ist gerade durch die vielen Änderungen gegeben!

In der Studie von 2014³ haben wir zudem herausgefunden, dass diese High-Performer nicht nur eine bessere IT-Performance bieten können, sondern dass sie als gesamte Organisation auch bessere Leistungen liefern – die Wahrscheinlichkeit, Profitabilität, Marktanteile und Produktivitätsziele zu verbessern, ist zwei Mal größer, und es gibt Hinweise darauf, dass sie auch im Kapitalmarkt eine deutlich bessere Leistung bieten können (wie Erik im letzten Kapitel vorhergesagt hat, als er den Hedgefonds aufbauen wollte).

Wie es sich anfühlt, in einer DevOps-Welt zu leben

Stellen Sie sich vor, Sie würden in einer DevOps-Welt leben, in der Product Owner, Entwicklung, QA, IT Operations und InfoSec unermüdlich zusammenarbeiten, um sich gegenseitig zu helfen und der gesamten Firma ein Gewinn zu sein. Sie ermöglichen einen schnellen Fluss geplanter Arbeit in die Produktivumgebung (zum Beispiel durch das Deployen von Code 10, 100 oder sogar 1.000 Mal pro Tag), behalten dabei aber ein höchstes Niveau in Bezug auf Stabilität, Zuverlässigkeit, Verfügbarkeit und Sicherheit bei.

Anstatt dass die Entwicklungsteams in den im Fluss folgenden Arbeitsbereichen (zum Beispiel QA, IT Operations und InfoSec) ständig Chaos verursachen, nutzen sie 20 Prozent ihrer Zeit dafür, sicherzustellen, dass die Arbeit problemlos die einzelnen Stationen passiert, dass automatische Tests beschleunigt werden, die Entwicklungsinfrastruktur besser wird und dass die Anwendungen nützliche Protokolldaten zu ihrem Einsatz liefern.

Warum? Weil jeder kurze Feedback-Schleifen benötigt, um zu verhindern, dass sich problematischer Code in der Produktivumgebung einnistet, und um ein schnelles Deployment von Code zu ermöglichen, damit Probleme im Produktivumfeld schnell erkannt und behoben werden.

Jeder, der an der Wertschöpfung beteiligt ist, honoriert die Zeit und die Beiträge der anderen, sorgt aber gleichzeitig fortlaufend dafür, dass das System mit Druck versorgt wird, damit die gesamte Organisation besser wird und dazulernt. Jeder wendet Zeit dafür auf, diese Lektionen in die Praxis umzusetzen und technische Schulden zurückzuzahlen. Jeder kümmert sich um nicht funktionale Anforderungen (zum Beispiel Qualität, Skalierbarkeit, Wartbarkeit, Sicherheit, Operabilität) genauso wie um neue Features. Warum? Weil nicht funktionale Anforderungen genauso wichtig sind, um die Firmenziele zu erreichen.

Wir haben eine kollaborative Kultur des gegenseitigen Vertrauens, in der jeder für die Qualität seiner Arbeit verantwortlich ist. Statt Genehmigungen und Konformitätsprozesse zu befolgen – das Kennzeichen einer Management-Kultur, die nicht vertraut und die auf »Teile und herrsche« setzt –, bauen wir auf Peer Review, um sicherzustellen, dass jeder Vertrauen in die Codequalität besitzt.

Zudem handelt es sich um eine auf Hypothesen basierende Kultur, in der jeder ein Wissenschaftler sein muss, der keine Annahme als gegeben hinnimmt und nichts macht, ohne es zu dokumentieren. Warum? Weil wir wissen, dass unsere Zeit wertvoll ist. Wir verbringen nicht Jahre damit, Features zu bauen, die unsere Kunden gar nicht haben wollen, Code auszuliefern, der nicht funktioniert, oder etwas zu reparieren, das gar nicht das Problem ist. All diese Faktoren helfen uns bei unserer Fähigkeit, tolle Features bereitzustellen, die unsere Kunden erfreuen und unserer Firma dabei helfen, erfolgreich zu sein.

Paradoxerweise wird das Durchführen von Code-Deployments zur langweiligen Routine. Statt nur des Nachts oder am Wochenende zu laufen, wenn alle gestresst sind und es chaotisch abläuft, liefern wir unseren Code tagsüber aus, ohne dass die meisten Leute es überhaupt mitbekommen. Und weil Code-Deployments am Nachmittag stattfinden und nicht am Wochenende, arbeitet IT Operations seit Jahrzehnten das erste Mal zu ganz normalen Arbeitszeiten – so wie jeder andere auch.

Aber wie wurde das Code-Deployment zur Routine? Weil Entwickler fortlaufend schnelle Rückmeldungen zu ihrer Arbeit bekommen: Schreiben sie Code, laufen in einer der Produktivumgebung ähnlichen Umgebung kontinuierlich automatisierte Unit-, Acceptance- und Integration-Tests, die uns die Sicherheit geben, dass der Code und die Umgebung wie gewünscht funktionieren und dass sich alles in einem auslieferbaren Zustand befindet. Und wenn der Code deployt wird, zeigen allgegenwärtige Messdaten aus der Produktion, dass alles läuft und dass der Kunde etwas Wertvolles in den Händen hält.

Selbst die anspruchsvollsten Feature-Releases sind zur Routine geworden. Wie? Weil der Code, der die neue Funktionalität bereitstellt, schon produktiv ist. Monate zuvor hat die Entwicklung Code in die Produktivumgebung ausgeliefert – für den Kunden unsichtbar, aber durch Kollegen ausführbar und testbar.

Wenn das Feature dann live geht, muss kein neuer Code eingebaut werden. Stattdessen legen wir nur einen Konfigurationsschalter um. Das neue Feature wird den Kunden erst nach und nach zur Verfügung gestellt und automatisch zurückgenommen, wenn etwas schiefgeht.

Nur dann, wenn wir sicher sein können, dass das Feature wie gewünscht funktioniert, stellen wir es der nächsten Gruppe von Anwendern zur Verfügung, und zwar so, dass der Rollout gesteuert, vorhersagbar, reversibel und entspannt verläuft. Das wiederholen wir, bis alle das Feature nutzen.

Auf diese Art und Weise verringern wir nicht nur deutlich die Deployment-Risiken, sondern wir erhöhen auch die Wahrscheinlichkeit, dass die Anwender tatsächlich etwas in ihrem Alltag damit anfangen können. Da wir schnell ausliefern können, ist es möglich, im Produktivumfeld kleine Experimente zu machen und unsere Geschäftshypothesen für jedes neue Feature zu testen. Wir können die Features iterativ testen und verbessern und dabei die Reaktionen der Kunden über Monate oder gar Jahre hinweg berücksichtigen.

Da ist es kein Wunder, dass wir unsere Konkurrenten per Experiment ausstechen und im Markt erfolgreicher sind.

All das ermöglicht DevOps, ein neuer Weg, auf dem nicht nur die Entwicklungs-, Test- und IT Operations-Abteilungen, sondern auch alle anderen Beteiligten zusammenarbeiten.

DevOps ist die industrielle Revolution unseres Zeitalters

Die Prinzipien hinter DevOps sind die gleichen, die die Herstellung revolutioniert haben. Statt in einer Fabrikhalle die Verwandlung von Rohmaterialien in fertige Produkte zu optimieren, zeigt DevOps, wie wir die Wertschöpfungskette in IT verbessern und Kundenanforderungen in Features und Services umwandeln, die den Anwendern etwas bringen.

In den 1980er-Jahren gab es einen wohlbekannten, ebenfalls grundlegenden und chronischen Konflikt bei der Herstellung:

• Vertriebszusagen erfüllen

• Herstellungskosten im Griff behalten

Um die Vertriebszusagen zu erfüllen, wollte die Verkaufsabteilung einen möglichst großen Lagerbestand in der Hinterhand haben, sodass die Kunden die gewünschten Produkte jederzeit erhalten konnten. Aber um Kosten zu verringern, wollten die Fertigungsleiter den Lagerbestand und die Work in Process (WIP) möglichst gering halten.

Da man nicht gleichzeitig die Lagerbestände erhöhen und verringern kann, waren Vertrieb und Fertigung in einem dauerhaften Konflikt gefangen.

Dieser Konflikt ließ sich lösen, indem Lean-Prinzipien übernommen wurden, wie zum Beispiel das Reduzieren der Losgröße und der Work in Process sowie das Verkürzen und Verstärken von Feedback-Schleifen. Das führte zu einem dramatischen Zuwachs an Fertigungsproduktivität, Produktqualität und Kundenzufriedenheit.⁴

In den 1980ern betrug die durchschnittliche Auftragsdurchlaufzeit⁵ sechs Wochen, wobei weniger als 70 Prozent der Bestellungen pünktlich geliefert wurden. Im Jahr 2005 ist die durchschnittliche Auftragsdurchlaufzeit auf drei Wochen gesunken, und mehr als 95 Prozent der Aufträge kommen pünktlich an. Organisationen, die diesem Leistungsschub nicht folgen konnten, verloren Marktanteile, wenn sie nicht sogar ganz aus dem Markt gedrängt wurden.⁶

Woher DevOps kommt

In einhundert Jahren werden sich Historiker unsere Dekade anschauen und daraus folgern, dass sich etwas gewandelt hat: Wie wir in der Entwicklung und in IT Operations gearbeitet haben, hat sich komplett geändert … Ich sage voraus, dass die Historiker diese Dekade als »kambrische Explosion der IT« bezeichnen werden – eine Zeit mit unglaublichen Innovationen und Disruptionen, als wir 50 Jahre nach der Geburt des Computers endlich gelernt haben werden, wofür Technologie gut ist.

John Willis, Cohost des »DevOps Cafe«-Podcast

Der Begriff »DevOps« wurde ursprünglich im Jahr 2008 von Patrick Debois und Andrew Shafer geprägt,⁷ allgemeine Verbreitung fand er dann 2009 rund um die Velocity Conference mit der berühmten Präsentation »10+ Deploys Per Day: Dev and Ops Cooperation at Flickr« von John Allspaw und Paul Hammond.⁸

In diesem Buch meinen wir mit »DevOps« das Ergebnis des Anwendens von Lean-Prinzipien auf die IT-Wertschöpfungskette. Diese Prinzipien basieren auf mehr als einem Jahrhundert vernünftiger Management-Praktiken. Aber statt sie auf die Umwandlung echter Güter anzuwenden, nutzen wir diese Prinzipien, um den Arbeitsfluss durch Produktmanagement, Entwicklung, Test, IT Operations und InfoSec zu beschleunigen.

DevOps hat sehr stark von der Arbeit in der Agile-Community profitiert, in der gezeigt wird, wie kleine Teams mit starkem gegenseitigem Vertrauen, kleinen Auftragsgrößen und kleineren, aber dafür häufigeren Software-Releases die Produktivität von Entwicklungsorganisationen massiv erhöhen können. Tatsächlich entstanden viele Schlüsselmomente der DevOps-Geschichte nach Agile-Konferenzen – natürlich neben den unglaublich dynamischen DevOpsDays, die es weltweit seit 2009 gibt.

Und natürlich nutzt und erweitert DevOps die Praktiken von »Infrastruktur als Code«, die von Dr. Mark Burgess entwickelt wurden, sowie Continuous Integration und Continuous Deployment (von Jez Humble und David Farley), die die Voraussetzung für solch schnelle Deployment-Abfolgen sind.

DevOps profitiert zudem von einer verblüffenden Konvergenz philosophischer Management-Bewegungen, wie zum Beispiel Lean Startup, Innovation Culture, Toyota Kata, Rugged Computing und der Velocity Community. All diese Bewegungen befruchten sich gegenseitig und bilden so den Rahmen für eine mächtige Koalition der Kräfte, die DevOps beschleunigen kann.

Erklärung zu den drei Wegen

In Projekt Phoenix beschreiben wir die zugrunde liegenden Prinzipien, von denen alle DevOps-Strukturen abgeleitet werden können, als »die Drei Wege«. Diese sollen die Werte und Philosophien beschreiben, die die DevOps-Prozesse und -Praktiken leiten.

Der Erste Weg beschäftigt sich mit dem Arbeitsfluss von der Entwicklung über IT Operations hin zum Kunden. Um diesen Fluss zu maximieren, brauchen wir kleine Losgrößen und Arbeitsintervalle, wir dürfen keine fehlerhaften Produkte weiterreichen und müssen uns fortlaufend auf die globalen Ziele hin optimieren (im Gegensatz zu lokalen Zielen wie zum Beispiel der Fertigstellungsrate von Entwicklungsfeatures, dem Verhältnis von gefundenen zu behobenen Fehlern oder der Verfügbarkeit im Ops-Bereich).

Zu den notwendigen Praktiken gehören ein kontinuierliches Build, Integration und Deployment, das Erstellen von Umgebungen auf Anforderung, das Beschränken der Work in Process und das Aufbauen von sicheren Systemen sowie Organisationen, die sich sicher ändern lassen.

Beim Zweiten Weg geht es um ein konstantes, schnelles Feedback zurück zu den Quellen der Wertschöpfungskette. Dadurch wird sichergestellt, dass Probleme schneller erkannt und behoben werden und nicht wieder vorkommen. So entstehen schon an der Quelle Qualität und Wissen – dort, wo wir es brauchen.

Zu den notwendigen Praktiken gehören:

• das »Stoppen des Fließbands«, wenn die Builds oder Tests in der Deployment-Pipeline fehlschlagen,

• das Hervorheben der Verbesserung täglicher Arbeit gegenüber der eigentlichen täglichen Arbeit,

• das Erstellen schneller, automatisierter Test-Suites, um sicherzustellen, dass sich der Code immer in einem potenziell auslieferbaren Zustand befindet,

• das Erstellen gemeinsamer Ziele und das vereinte Durchleben von Schmerzen von Entwicklung und IT Operations

• sowie das Erstellen allgegenwärtiger Messpunkte in der Produktivumgebung, damit jeder sehen kann, ob Code und Umgebung wie gewünscht funktionieren und die Kundenziele erfüllt werden.

Der Dritte Weg dreht sich um das Aufbauen einer Kultur, die zwei Dinge fördert: andauerndes Experimentieren, bei dem man Risiken eingehen und aus Erfolgen und Fehlschlägen lernen muss, und ein Verständnis dafür, dass Wiederholung und Übung die Grundlage des Könnens sind.

Experimentieren und das Eingehen von Risiken ermöglichen es uns, unser Arbeitssystem immer weiter zu verbessern. Dabei müssen wir häufig Dinge ganz anders tun, als wir es schon immer getan haben. Und wenn etwas schiefgeht, ermöglichen uns unsere fortlaufenden Wiederholungen und Übungen, mit den dadurch gewonnenen Fähigkeiten schnell wieder einen sicheren und normalen Zustand zu erreichen.

Zu den notwendigen Praktiken gehört das Aufbauen einer Kultur der Innovation und des Eingehens von Risiken (im Gegensatz zum ängstlichen Agieren oder gedankenlosen Empfangen von Befehlen), das Freihalten von wenigstens 20 Prozent der Entwicklungs- und IT Operations-Zeit für nicht funktionale Anforderungen und die ständige Versicherung, dass Verbesserungen unterstützt und gefördert werden.

Topmythen von DevOps

Wie jede transformative und disruptive Bewegung kann auch DevOps missverstanden oder falsch eingeschätzt werden. Hier finden Sie ein paar der verbreitetsten Mythen rund um DevOps:

DevOps ersetzt Agile

DevOps ist auf jeden Fall kompatibel zu Agile. Tatsächlich ist DevOps die logische Fortführung des Agile-Wegs, der 2001 begann, weil wir jetzt wissen, dass die echte Definition von »Done« nicht die ist, dass die Entwicklung fertig programmiert hat. Stattdessen ist Code erst dann »Done«, wenn er vollständig getestet wurde und wie gedacht in der Produktivumgebung läuft. (Beachten Sie, dass Agile keine Voraussetzung für die Übernahme von DevOps ist.)

DevOps ersetzt ITIL

Auch wenn manche DevOps als Gegenbewegung zu ITIL (IT Infrastructure Library) und ITSM (IT Service Management) sehen, sind DevOps und ITIL ebenfalls miteinander kompatibel. ITIL und ITSM bleiben weiterhin die besten Umsetzungen der Prozesse, die in IT Operations genutzt werden, und tatsächlich beschreiben sie viele der Fertigkeiten, die IT Operations braucht, um einen Arbeitsfluss im DevOps-Stil zu unterstützen.

Um die kürzeren Lead Times und die höhere Deployment-Frequenz zu unterstützen, die mit DevOps verbunden sind, benötigen viele Bereiche des ITIL-Prozesses Automatisierung, insbesondere rund um die Change-, Konfigurations- und Release-Prozesse.

Und weil wir auch ein schnelles Erkennen und Beheben von Serviceproblemen erreichen müssen, bleiben die ITIL-Bereiche des Servicedesigns sowie des Incident- und Problem-Managements so wichtig wie zuvor.

DevOps bedeutet NoOps

DevOps wird manchmal fälschlicherweise als NoOps interpretiert (dass also IT Operations gar nicht mehr benötigt wird). Genau betrachtet, wird bei DevOps dem Entwicklungsbereich mehr Verantwortung für Code-Deployments und Wartung übertragen. Das bedeutet aber nur, dass die Entwicklung viele der Funktionen von IT Operations übernimmt.

Um kurze Lead Times und eine hohe Produktivität der Entwickler zu ermöglichen, müssen bei DevOps viele Aufgaben von IT Operations zu Self-Services umgewandelt werden. Anstatt dass also die Entwicklung ein Ticket aufmacht und darauf wartet, dass IT Operations die Arbeit erledigt, werden viele dieser Aktivitäten automatisiert, sodass sie die Entwickler selbst erledigen können (zum Beispiel eine produktionsähnliche Entwicklungsumgebung aufsetzen oder einen Messwert für die Produktivitätstelemetrie anlegen).

DevOps ist nur für Open Source-Software gedacht

Auch wenn viele der Erfolgsgeschichten von DevOps in Organisationen spielen, die Software wie den LAMP-Stack⁹ nutzen, setzen auch Firmen DevOps-Strukturen um, die Microsoft .NET, SAP oder sogar COBOL-Anwendungen auf Mainframes und HP-LaserJet-Firmware einsetzen.

DevOps-Prinzipien sind universell und weitgehend unabhängig von der zugrunde liegenden Technologie. Manche der DevOps-Strukturen haben spezifische Anforderungen an die Technologie (zum Beispiel das Unterstützen automatisierter Tests oder das Einchecken von Konfigurationen in die Versionskontrolle), die sich in Open Source-Software oft besser umsetzen lassen.

DevOps ist nur »Infrastruktur als Code« oder Automatisierung

Obwohl viele der DevOps-Strukturen, die in diesem Buch gezeigt wurden, Automatisierung benötigen, gehören zu DevOps auch gemeinsame Ziele und gemeinsame »Schmerzen« in der IT-Wertschöpfungskette. Das geht weit über die reine Automatisierung hinaus.

DevOps ist nur für Start-ups und Einhörner sinnvoll

DevOps lässt sich in jeder Organisation anwenden (und ist für sie relevant), die den Fluss der geplanten Arbeit durch die Entwicklung erhöhen muss, während gleichzeitig Qualität, Zuverlässigkeit und Sicherheit für den Kunden bestehen bleiben müssen.

Tatsächlich behaupten wir sogar, dass DevOps für die »Arbeitspferde« wichtiger ist als für die »Einhörner«. Denn wie Richard Foster schreibt: »Von den Firmen, die 1955 zu den Fortune 500 gehörten, sind 87 Prozent vom Markt verschwunden. 1958 befanden sich die Unternehmen im Schnitt 61 Jahre in diesem Ranking, mittlerweile sind es nur noch 18 Jahre.«¹⁰ Wir wissen, dass die Abwärtsspirale jede IT-Organisation trifft. Aber die meisten Unternehmens-IT-Organisationen führen unzählige Gründe auf, warum sie DevOps nicht umsetzen können oder warum es nicht relevant für sie ist.

Eines der Hauptargumente der Arbeitspferde ist, dass all die Einhörner (zum Beispiel Google, Amazon, Twitter oder Etsy) schon so geboren wurden. Mit anderen Worten: Einhörner haben schon immer DevOps gemacht.

Tatsächlich war so gut wie jedes DevOps-Einhorn früher ein Arbeitspferd mit all den Problemen, die damit verbunden sind.

• Amazon nutzte bis 2001 das OBIDOS Content Delivery System, das immer problematischer und kritischer in der Wartung wurde, bis Werner Vogels, CTO von Amazon, die gesamte Organisation und den Code in eine serviceorientierte Architektur umwandelte.¹¹

• Twitter hatte 2009 Probleme damit, die Kapazität seines monolithischen Ruby on Rails-Systems für das Frontend skalieren zu können, und begann ein mehrjähriges Projekt zum kontinuierlichen Redesign der Architektur.¹²

• LinkedIn haderte sechs Monate nach ihrem erfolgreichen Börsengang mit Deployments, die so schmerzhaft wurden, dass Operation InVersion gestartet wurde – ein zweimonatiger Feature-Freeze, in dem die Serverumgebungen, Deployments und die Architektur überarbeitet wurden.¹³

• Etsy kämpfte 2009 laut Michael Rembetsy damit, dass sie »in einem Meer aus eigenem Entwicklerdreck lebten« und sich mit problematischen Software-Deployments und technischen Schulden herumschlagen mussten. Sie entschieden sich dazu, einen Kulturwandel vorzunehmen.¹⁴

• Facebook befand sich ebenfalls 2009 an der Schmerzgrenze für Infrastrukturoperationen. Es war kaum noch möglich, mit der wachsenden Benutzerzahl Schritt zu halten, Code-Deployments wurden zunehmend gefährlich, und die Mitarbeiter waren damit beschäftigt, Feuer zu löschen. Jay Parikh und Pedro Canahuati begannen daher mit einer Umwandlung des Systems, um Code wieder sicher deployen zu können.¹⁵

Kurz gesagt, alle Einhörner waren einmal normale Pferde. DevOps ist der Weg, wie man ein Pferd zu einem Einhorn machen kann, wenn es denn eines werden will. Und tatsächlich wächst die Liste der großen Unternehmen, die DevOps übernehmen, kontinuierlich:

• Finanzdienstleistungen: BNY Mellon, Bank of America, World Bank, Paychex, Nationwide Insurance

• Großhändler: The Gap, Nordstrom, REI, Macy’s, GameStop, Target

• Hochschulen: Seton Hill University, Kansas State University, University of British Columbia

• Behörden: UK.GOV, Department of Homeland Security

Christopher Little schreibt: »Wenn es etwas gibt, das alle Pferde (IT-Organisationen von Unternehmen) hassen, dann sind das Geschichten über Einhörner (Firmen, die DevOps umsetzen). Was seltsam ist, denn Pferde und Einhörner gehören vermutlich zur gleichen Spezies. Einhörner sind einfach Pferde mit Hörnern.«

Die vier Arten der Arbeit

Weil Arbeit mittlerweile immer mehr Wege zu den Menschen findet (per E-Mail, Telefonanruf, Flurgespräch, Chat, Ticket-System, Meetings und so weiter), wollen wir unsere bestehenden Zusagen sichtbar machen.

Erik hat Bill überzeugt, dass es im IT-Bereich vier Arten von Arbeit gibt:

Businessprojekte

Dabei handelt es sich um Anforderungen aus den Fachabteilungen. Den meisten Entwicklungsprojekten liegt ein Businessprojekt zugrunde. Diese Projekte werden im Allgemeinen vom Projektmanagement-Büro betreut, das sich um alle offiziellen Projekte eines Unternehmens kümmert.

Interne IT-Projekte

Dazu gehören die Infrastruktur- oder IT Operations-Projekte, die eventuell aus Businessprojekten entstehen, aber auch intern aufgesetzte Projekte zum Verbessern der Umgebung (zum Beispiel das Erstellen neuer Server oder das Automatisieren des Deployments). Häufig werden diese Projekte nicht zentral verwaltet, sondern verbleiben bei den Budgetverantwortlichen (zum Beispiel dem Datenbank-Manager, dem Storage-Manager oder dem Manager für Distributed Systems).

Das führt zu Problemen, wenn IT Operations der Engpass ist, denn so lässt sich nicht einfach herausfinden, wie viel Kapazität schon für interne Projekte gebunden ist.

Änderungen

Änderungen entstehen oft aus den beiden vorigen Arten von Arbeit, und sie werden meist in einem Ticket-System verwaltet (zum Beispiel Remedy für IT Operations, JIRA oder ein Agile-Planning-Tool für die Entwicklung). Es kann zu Problemen führen, wenn zwei Systeme existieren, die die Arbeit von zwei verschiedenen Bereichen der Wertschöpfungskette verwalten – insbesondere dann, wenn Übergaben erforderlich sind.

In manchen Teams, die sich sowohl um Entwicklung als auch um die operativen Aspekte kümmern, wird übrigens meist sämtliche Arbeit in einem System verwaltet. Das hat Vorteile, da dann Aktivitäten aus dem operativen Umfeld neben Fehlermeldungen und neuen Features im Backlog erscheinen.

Ungeplante Arbeit oder Recovery-Arbeit

Dazu gehören operative Zwischenfälle und Probleme – häufig verursacht durch die anderen drei Arten von Arbeit und immer auf Kosten anderer geplanter Aufgaben.

Warum müssen wir IT-Aufgaben sichtbar machen und WIP steuern?

Meine Lieblingsgrafik im Projekt Phoenix (und gleichzeitig die einzige) zeigt die Wartezeit als Funktion der Auslastung einer Ressource an einer Arbeitsstation. Erik hat diese Grafik genutzt, um zu zeigen, warum die einfachen und von Brent in einer halben Stunde zu erledigenden Änderungen erst nach mehreren Wochen fertig wurden.

Der Grund ist natürlich, dass Brent als Engpass der gesamten Arbeit fortlaufend zu 100 Prozent oder mehr ausgelastet ist, daher Aufgaben, die er erledigen soll, ganz hinten in einer Warteschlange landen und erst dann abgearbeitet werden, wenn Druck gemacht oder eskaliert wird.

Das zeigt die Grafik: Auf der x-Achse ist die Auslastung einer Ressource an einer Arbeitsstation in Prozent aufgetragen, auf der y-Achse die ungefähre Wartezeit (oder genauer gesagt: die Länge der Warteschlange). Die Form der Kurve zeigt, dass die Wartezeit durch die Decke geht, sobald die Ressourcenauslastung über 80 Prozent steigt.

Im Projekt Phoenix erkennen Bill und sein Team die verheerenden Konsequenzen dieses Zusammenhangs auf die Bearbeitungszeit für die Zusagen, die sie gegenüber dem Projektmanagement-Büro machen:

Ich erzähle den beiden, was Erik mir im MRP-8 erzählt hat – inwieweit die Wartezeit davon abhängt, wie belegt eine Ressource ist. »Die Wartezeit ist der Prozentwert, den die Ressource belegt ist, geteilt durch den Prozentwert, den die Ressource nichts zu tun hat. Mit anderen Worten: Wenn eine Ressource zu 50 Prozent beschäftigt ist, ist sie auch 50 Prozent der Zeit nicht beschäftigt. Die Wartezeit ist dann 50 Prozent geteilt durch 50 Prozent, also eine Zeiteinheit. Nehmen wir eine Stunde an. Im Durchschnitt wartet unser Task also eine Stunde in der Queue, bevor er bearbeitet wird.

Wenn eine Ressource andererseits zu 90 Prozent beschäftigt ist, beträgt die Wartezeit 90 Prozent geteilt durch 10 Prozent – oder 9 Stunden. Unser Task würde also neunmal länger in einer Warteschlange herumhängen, als wenn die Ressource zu 50 Prozent ausgelastet ist.«

Meine Schlussfolgerung: »Gehen wir beim Phoenix-Task davon aus, dass wir 7 Übergaben haben und dass jede dieser Ressourcen zu 90 Prozent ausgelastet ist, würde der Task insgesamt 9 Stunden mal 7 Schritte in Warteschlangen hängen ...«

»Was? 63 Stunden reine Wartezeit?«, sagt Wes ungläubig. »Das ist unmöglich!«

Patty sagt süffisant lächelnd: »Oh, natürlich. Weil es doch nur 30 Sekunden tippen sind, oder?«

Bill und sein Team erkennen, dass ihre einfache, 30 Minuten dauernde Aufgabe tatsächlich sieben Übergaben erfordert (zum Beispiel an das Serverteam, das Netzwerkteam, das Datenbankteam, das Virtualisierungsteam und – natürlich – an Brent, Brent und Brent). Angenommen, alle Arbeitsstationen sind zu 90 Prozent ausgelastet. Die Grafik zeigt, dass die durchschnittliche Wartezeit bei jeder Station 9 Stunden beträgt – und weil die Arbeit 7 Stationen durchlaufen muss, summiert sich die Gesamtwartezeit zu 63 Stunden.

Mit anderen Worten: Die »Gesamt-Wertschöpfungszeit in Prozent« (manchmal als »Touch Time« bezeichnet) beträgt nur 0,16 Prozent der Gesamtbearbeitungszeit (30 Minuten geteilt durch 63 Stunden). 99,8 Prozent der Gesamtbearbeitungszeit langweilt sich die Arbeit also in irgendwelchen Warteschlangen (zum Beispiel in einem Ticket-System oder in einer E-Mail).

Mein Koautor George Spafford und ich lernten diese Grafik, die so wundervoll die destruktive Natur langer Wartezeiten aufgrund von stark ausgelasteten Ressourcen zeigt, erstmals kennen, als wir den Kurs EM 526 (Constraints Management) von Dr. James Holt an der Washington State University belegten. (Details dazu finden Sie im Abschnitt »Weitere Quellen«.)

Leider kenne ich die genaue Herkunft dieser Grafik nicht. Manche (unter anderem ich) glauben, dass es sich dabei um eine vereinfachte Form von Little’s Law handelt, bei der wir vereinfachende Annahmen treffen: eine einzelne Arbeitsstation, eine vereinfachte Warteschlange (alle Aufgaben werden in der gleichen Zeit erledigt), keine Verzögerung zwischen den Aufgaben und so weiter.

In der Grafik ist die »Wartezeit« meiner Meinung nach ein Synonym für »Länge der Warteschlange«. Mit anderen Worten: Da keine Zeit damit verbunden ist, fehlen auch Zeiteinheiten (es sind also weder Minuten noch Stunden oder Tage).

Die beste Diskussion zur Herkunft (und zu Gültigkeit/Ungültigkeit) dieser Grafik finden Sie in der LinkedIn-Gruppe zum (englischsprachigen) Originaltitel The Phoenix Project.¹⁶ Der Diskussionsstil ist zwar manchmal ein bisschen rau, aber trotzdem intellektuell erstklassig.

Meine Meinung? Das Ziel der Wissenschaft ist, möglichst viele beobachtete Phänomene mit möglichst wenigen Prinzipien zu erklären und überraschende Einblicke zu ermöglichen. Ich denke, die Grafik erfüllt diesen Zweck, und sie ist der effizienteste Weg, die katastrophalen Konsequenzen überlasteter IT-Mitarbeiter und die Trugschlüsse üblicher Projektmanagement-Techniken für IT Operations deutlich zu machen.

Weitere Quellen

Einer der am häufigsten geäußerten Wünsche ist eine Liste von weiteren Quellen und empfehlenswerter Literatur, um mehr über die Philosophien, Tools und Techniken zu erfahren, die in diesem Buch erwähnt werden. Ich habe beim Schreiben dieses Buchs viele Quellen begutachtet. Ich bin ausgebildet als Theory of Constraints Jonah, als Kanban Practitioner und als Akolyth im Toyota Kata. Ich habe Visible Ops in das Buch einfließen lassen. Hier finden Sie eine Liste dieser Ressourcen sowie weitere Informationsquellen, die Sie dabei unterstützen, Bills Wandlung von Parts Unlimited (mit Eriks Hilfe) folgen können.

Das Ziel: Ein Roman über Prozessoptimierung

Dr. Eliyahu Goldratt schrieb sein wegweisendes Buch Das Ziel: Ein Roman über Prozessoptimierung (Original: The Goal: A Process of Ongoing Improvement) im Jahr 1984. Es handelt sich dabei um einen sokratischen Roman über Alex Rogo, einen Fertigungsleiter, der seine Kosten- und Lieferprobleme in neunzig Tagen lösen muss – ansonsten wird seine Fabrik geschlossen. Dieses Buch wird in vielen MBA-Kursen durchgenommen, es hat Generationen von Firmenchefs beeinflusst und wurde bislang über sechs Millionen Mal verkauft.

Mein Koautor und ich haben dieses Buch nahezu zehn Jahre lang studiert und uns damit auf das Schreiben von Projekt Phoenix vorbereitet. Ich sehe unser Buch in vielerlei Hinsicht als Hommage an Das Ziel. Wir haben versucht, einen Großteil der Strukturelemente und der Handlung zu berücksichtigen, während es gleichzeitig aktuell, relevant und – hoffentlich – dramatischer ist. (Ich stelle mir gerne vor, dass Projekt Phoenix das ist, was Dr. Goldratt heutzutage schreiben würde – mit Tarantino oder Scorsese als Lehrer.)

In Das Ziel beginnt Dr. Goldratt mit der Beschreibung der Schritte in der Theory of Constraints-(TOC-)Methode. Kurz gesagt, sind die fünf ursprünglichen TOC-Schritte:

• Den Engpass identifizieren.

• Den Engpass auslasten.

• Alles andere dem Engpass unterordnen.

• Den Engpass beheben.

• Den nächsten Engpass finden.

Im Buch besteht der Engpass aus dem berühmten Roboter NCX-10, dann aus den Härtungsöfen, und schließlich werden die Marktanforderungen der Engpass. In Projekt Phoenix ist der Engpass zunächst Brent, weil er sich immer mit der ungeplanten Arbeit herumschlagen muss, dann der Deployment-Prozess für die Anwendung, und schlussendlich wandert der Engpass aus der Firma heraus, weil der benötigte MRP-Anwendungssupport ausgelagert worden war.

In Dr. Goldratts folgendem Buch Das Ziel – Teil II (Original: It’s Not Luck) beschreibt er die sogenannten Thinking Processes, bei denen es sich um eine fantastische (wenn auch recht sperrige und häufig sehr langsame) Methode handelt, grundlegende chronische Konflikte zu erkennen, die aktuelle Realität zu erfassen und die gewünschte Zukunft zu beschreiben. Dazu gehört eine Reihe von Planungstechniken, um die Wahrscheinlichkeit für eine erfolgreiche Umsetzung der Methode zu erhöhen.

Den bei Weitem besten Überblick über die gesamte TOC, die Thinking Processes und Dr. Goldratts Wissen liefert ein Hörbuch namens Beyond The Goal. Darin finden sich alle aufgezeichneten Vorlesungen von 2005, und es handelt sich um eine atemberaubende Reise durch Dr. Goldratts Leben mit seinen Management-Beiträgen, Werkzeugen und Fallstudien.

Vor acht Jahren war es durchaus bekannt, dass die Thinking Processes die Werkzeuge und Techniken waren, mit deren Hilfe er Das Ziel aufgebaut hat. Darum wollten meine Koautoren und ich mehr darüber lernen, aber wir konnten neben Dr. Goldratts Schriften keine Kurse oder Bücher finden, die uns da weiterhalfen. Auch gab es keine nicht trivialen (oder korrekten) Beispiele im Internet. Seitdem hat sich viel geändert.

Jedem, der sich dafür interessiert, Expertenwissen in der TOC und den Thinking Processes aufzubauen, lege ich ans Herz, Dr. James Holts Kurse EM 526 (»Constraints Management«) und EM 530 (»Applications of Constraints«) zu belegen, die online an der Washington State University angeboten werden. Beide bereiten Studenten darauf vor, als »Jonah« trainiert zu werden – das ist der Yoda-ähnliche Charakter aus Das Ziel, der offensichtlich die Verkörperung von Dr. Goldratt selbst darstellt.¹⁷

Wollen Sie mehr über die Thinking Processes lernen, empfehle ich Dr. H. William Dettmers Lehrbuch The Logical Thinking Process, auch wenn es keine leichte Kost ist. Und es gibt viele Vereinfachungen, die nicht in Dr. Dettmers Buch zu finden sind, daher sollten Sie es mit Vorsicht genießen.

Die fünf Dysfunktionen eines Teams

Die Techniken, die Steve, CEO von Parts Unlimited, in Kapitel 18 einsetzt, basieren auf Patrick Lencionis Methode, die in Die 5 Dysfunktionen eines Teams (Original: The Five Dysfunctions of A Team: A Leadership Fable) beschrieben ist. Er postuliert, dass eine der wichtigsten Ursachen dafür, Ziele nicht erreichen zu können, das Fehlen von Vertrauen innerhalb eines Teams ist. In seinem Modell werden die fünf Dysfunktionen beschrieben als:

• Fehlendes Vertrauen – der fehlende Wille, sich in der Gruppe verletzbar zu zeigen.

• Angst vor Konflikten – künstliche Harmonie suchen, statt konstruktiv zu diskutieren.

• Fehlendes Engagement – durch Zurückhaltung bei Gruppenentscheidungen entstehen Unsicherheiten in der gesamten Organisation.

• Scheu vor Verantwortung – das Abwälzen von Verantwortung auf andere ist kontraproduktiv und führt zu niedrigen Standards.

• Fehlende Erfolgsorientierung – Konzentration auf persönlichen Erfolg, Status und Ego statt auf den Erfolg des Teams.

Wenn ich an die langen, bitteren Stammeskriege zwischen Entwicklung und IT Operations, aber auch zwischen IT und Business denke, befürchte ich, dass wir uns die Lektionen von Lencioni noch sehr lange anschauen müssen, um das DevOps-Ideal zu erreichen.

Häufig besteht bei Führungskräften der erste Schritt beim Einsatz von Patrick Lencionis Methode darin, sich verletzlich zu zeigen (oder wenigstens verletzliche Verhaltensweisen zu entwickeln).¹⁸ In Projekt Phoenix hat Steve diese Praktik schon seit Jahrzehnten verinnerlicht und leitet eine »Personal History Exercise«.¹⁹

Ich hatte das Glück, selbst von dieser Technik profitieren zu können. Als mein früherer Chef Jim B. Johnson diese Technik einsetzte, als er als CEO zu Tripwire, Inc. kam, hat mich das wirklich beeindruckt. Er erzählte uns seine Geschichte, die so privat und berührend war, dass wir anderen im Führungsteam (fast alle) Tränen in den Augen hatten.

Im Gegenzug mussten wir alle auch etwas von uns preisgeben, uns den anderen gegenüber verletzbar machen und damit den nächsten Schritt vorbereiten – die Angst vor Konflikten zu verringern. Jim gab mit seiner Ehrlichkeit und Aufrichtigkeit den Ton vor, den er auch von den anderen erwartete. Und glauben Sie mir – unser Verhalten änderte sich, und wir benahmen uns mehr wie ein Team.

Das war vermutlich eine der wichtigsten Lektionen in meinem Leben. Ich strebe mittlerweile in allen Bereichen an, Konflikten nicht mehr aus dem Weg zu gehen und keine Angst davor zu haben, die Wahrheit oder auch nur meine Meinung zu sagen. Natürlich ist mir klar, dass ich das nie ganz erreichen werde, aber ich finde, es ist trotzdem ein erstrebenswertes Ziel.

Ich konnte schon Führungsteams dabei beobachten, wie sie schlechter als notwendig arbeiteten und sich untereinander stritten, weil sie nicht dazu in der Lage waren, sich gegenseitig zu vertrauen. Und wenn sich schon die Manager nicht vertrauen, werden das auch die zugehörigen Teams nicht tun.

Aus meiner professionellen Erfahrung heraus führt das Vermeiden ehrlicher Diskussionen über allen bekannte Probleme, denen man sich nicht stellen will, zu unglaublich hohen Kosten und unerfreulichen Konsequenzen. Ein Aufgreifen dieser Probleme erfordert das Überwinden tief verwurzelter und erlernter Verhaltensweisen, aber es lohnt sich.

Die Kata des Weltmarktführers: Toyotas Erfolgsmethoden

Ein weiteres Buch, das uns stark beeinflusst hat, ist Die Kata des Weltmarktführers: Toyotas Erfolgsmethoden (Original: Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results) vom Shingo-Prize-Gewinner Mike Rother.²⁰ Ich traf ihn bei seinem dreitägigen Kurs »Improvent Kata and Coaching Kata«, der von der University of Michigan angeboten wird. Dazu gehörten auch zwei Tage Praktikum in einer echten Fabrikanlage.

Wenn ich mir die Freiheit nehmen darf, Mike Rothers Reise in meinen eigenen Worten zu beschreiben, würde ich sie vor 20 Jahren beginnen lassen, als er zusammen mit einem Team von Forschern und Führungskräften der amerikanischen Automobilindustrie Fertigungsanlagen von Toyota besuchte. Er beschreibt dies als Beobachten und Dokumentieren der Praktiken von Toyota, die zu ihrer außerordentlichen und marktbeherrschenden Leistung geführt haben.

Aber wenn er jetzt auf diese Phase seiner Karriere zurückblickt, charakterisiert er sie eher so, dass den Leuten beigebracht wurde, das bei Toyota beobachtete Verhalten nur nachzumachen, während die wichtigsten Elemente der Kultur und Werte von Toyota fehlten, die deren Management-Praktiken begleiteten.

Hört man ihn darüber reden, ist das so, als wäre ein Großteil der Lean Community, die er mit unterrichtet hat, nur ein »Cargokult«.²¹

Mike Rothers Lektionen wurden im Kata-Buch niedergeschrieben. Dort finden sich das Denkmodell und die Kultur, die existieren muss, um den Lean-PDCA-Zyklus (Plan, Do, Check, Act) überhaupt zu ermöglichen. Ich glaube, dass dies einer der wichtigsten Beiträge in der Welt der Prozessverbesserung überhaupt ist.

Die offensichtlichste Manifestation des Toyota Kata ist der zweiwöchige Verbesserungszyklus, innerhalb dessen jeder Leiter einer Arbeitsstation etwas (irgendetwas!) verbessern muss. Um Mike Rother zu zitieren: »Das Anwenden des Kata ist das kontinuierliche Einüben einer Vorgehensweise, die so zur zweiten Natur wird. Für sein tägliches Management lehrt Toyota eine Arbeitsweise – ein Kata –, das dabei geholfen hat, in den letzten sechs Jahrzehnten so erfolgreich zu sein.«

Die Idee der täglichen Wiederholung, um ein Verhalten einzuüben und die Ergebnisse zu verbessern, sind beim Sporttraining, beim Erlernen eines Musikinstruments, bei der Schulung von militärischen Spezialeinheiten und mittlerweile auch in der modernen Produktion verbreitet. Das ist die Grundlage von Eriks Drittem Weg. Er erklärt: »Er zeigt uns, wie wir eine Kultur aufbauen, in der man experimentieren kann, aus Fehlern lernt und versteht, dass Wiederholung und Übung die Voraussetzungen für den Weg zum Meister sind.«

Ich finde, Pattys ITIL/ITSM-Kreuzzug ähnelt stark den von Rother beschriebenen Lean-Profis, die es nie geschafft haben, die Leistung von Toyota zu replizieren. Warum? Sie machen einmal im Jahr ein Lean Kaizen, das das restliche Jahr über im Tagesgeschäft wieder untergeht.

Um die Performancegewinne zu erhalten, die uns von ITIL/ITSM, Lean oder was auch immer versprochen werden, müssen wir eine Kultur nicht endender Verbesserungen erreichen, die von Rother beschrieben wird.

Kata beeinflusst Ihre Organisation durch:

• das Anbieten einer systematischen, wissenschaftlichen Prozedur, die auf jedes Problem und jede Herausforderung angewendet werden kann,

• das Vereinheitlichen des Entwickelns von Lösungen in einer Organisation,

• das Verwandeln von Managern in eine Trainer- und Mentorenrolle, indem sie Coaching-Zyklen einüben, und

• das Umsetzen von PDCA, sodass die Leute jeden Tag kleine Schritte vorankommen.

Diese zweiwöchentlichen Verbesserungszyklen sorgen für einen konstanten Druck im System, wodurch es gezwungen wird, besser zu werden. Mike Rother versichert, dass ein System eben nicht in einem stabilen Zustand verharrt, wenn es nicht verbessert wird. Stattdessen wird die Leistung der Organisation dank der Entropie abnehmen.

In einer der beeindruckendsten Fallstudien beschreibt Rother, wie an einer bestimmten Arbeitsstation die Anzahl der Arbeiter von sechs auf vier reduziert werden konnte. Im Lauf der nächsten sechs Wochen stieg die Anzahl aber wieder langsam auf sechs. Entropie!

Solche Muster der Netflix-Kultur wie fortlaufende Verbesserung und Erneuerung, radikales Ausmerzen von Abweichungen und das Einbringen von Fehlern in die Produktivumgebung (zum Beispiel über solch interessante Tools wie Chaos Monkey) sind die perfekte Verkörperung des Verbesserungs-Kata, das Rother beschreibt.

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

Eriks Erster Weg unterstreicht die Wichtigkeit der Performance des gesamten Systems – im Gegensatz zur Leistung eines einzelnen Arbeitsbereichs, der so groß wie eine ganze Abteilung (zum Beispiel die Entwicklung oder IT Operations) oder so klein wie ein einzelner Mitarbeiter sein kann (zum Beispiel ein Entwickler oder ein Systemadministrator).

In der IT-Wertschöpfungskette geht es immer um den Arbeitsfluss von der Entwicklung zu IT Operations. Die vermutlich beste Umsetzung dieser Arbeit ist das bahnbrechende Buch Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation von Jez Humble und David Farley.

Sie beschreiben viele der Techniken, die notwendig sind, um die beeindruckende Präsentation auf der Velocity Conference 2009, »10+ Deploys Per Day: Dev and Ops Cooperation at Flickr«, nachvollziehen zu können, die von John Allspaw und Paul Hammond sowie der Agile System Administration-Bewegung gehalten wurde.²²

Continuous Delivery ist die Weiterentwicklung der Continuous Integration, bei der es sich um Entwicklungspraktiken handelt, zu denen Continuous Builds, Continuous Testing, die tägliche Integration von Branches zurück in den Trunk, das Testen in einem Klon der Produktivumgebung und so weiter gehören. Continuous Delivery-Techniken erweitern diesen Prozess bis in die Produktivumgebung.

(Als ich dieses Buch las, hatte ich fast körperliche Schmerzen angesichts der Erkenntnis, wie viel Ärger und schlechte Entscheidungen ich hätte vermeiden können, wenn ich es vier Jahre zuvor gelesen hätte. Ich hatte es mit einer ungenannt bleibenden Softwarefirma zu tun, in der wir für über ein Jahr kein funktionierendes Build-System besaßen. Ohne automatisierte Builds können Sie keine automatisierten Tests haben, und ohne automatisierte Tests ist die Integration von Entwickler-Branches ein sehr schmerzhafter Prozess. Das wiederum führt dazu, dass die Integration seltener und dadurch noch schmerzhafter durchgeführt wird. Das wieder verzögert das Ausliefern von Features und reduziert die Softwarequalität.)

Stellen Sie sich meine Freude vor, als Jez Humble mir erzählte, dass die Übung zum Abbilden der Wertschöpfungskette von der Entwicklung zu IT Operations, die Bill und das Team in Kapitel 31 durchspielen, fast genauso aussieht wie das, was er und Farley in ihrem Buch beschrieben haben. Erstaunlich.

Continuous Delivery ist die perfekte Umsetzung des Ersten, Zweiten und Dritten Wegs, denn es unterstützt kleine Losgrößen (zum Beispiel ein tägliches Einchecken in den Trunk), das Anhalten der Fertigung, wenn Probleme auftauchen (zum Beispiel ist keine neue Arbeit erlaubt, wenn Builds, Tests oder Deployments fehlschlagen – die Integrität des Systems ist wichtiger als die Arbeit an sich), und die Notwendigkeit, fortlaufend an Validierungstests zu arbeiten, mit denen Fehler in der Produktivumgebung bestenfalls verhindert oder wenigstens erkannt und schnell korrigiert werden können (zum Beispiel durch das Umwandeln manueller Prozess-Reviews in automatisierte Tests, insbesondere in den ITSM-Prozessbereichen Release, Change und Configuration).

Continuous Deployment ist eine Voraussetzung für hohe Deployment-Raten, die DevOps charakterisieren, und daher eine notwendige Fertigkeit für den modernen DevOps-Praktiker. Zudem wird es die Rettung für eine ganze Generation von ITSM-Anwendern sein. Lesen Sie dieses Buch.

Release It!: Design and Deploy Production-Ready Software

Wenn Sie auf der Velocity Conference Vorträgen darüber lauschen, wie Firmen wie Google, Netflix, Amazon, Twitter, Pinterest und andere ihren Code und ihre Umgebungen so entwerfen, dass sie skalierbar sind, hören Sie häufig von Ideen, die zuerst von Michael T. Nygard in seinem fantastischen Buch Release It!: Design and Deploy Production-Ready Software veröffentlicht wurden.²³

Dieses Buch hilft dabei, den Graben zwischen Entwicklung und IT Operations ein wenig zuzuschütten, indem es Entwicklern und Architekten zeigt, wie man Anwendungen baut, die selbst in der feindlichsten Produktivumgebung überleben und deployt und gewartet werden können. Lesen Sie dieses Buch, werden Sie in dessen Mustern und Lektionen die Horrorgeschichten aus Ihrer eigenen Vergangenheit wiederfinden.

Aber auch Leute aus IT Operations müssen dieses Buch lesen, um zu verstehen, wie bestimmte Entscheidungen in der Entwicklung, die sie schon aus der Vergangenheit kennen, zu schlechten Ergebnissen im Produktivumfeld führen. Wichtiger ist aber noch, dass sie auf diese Weise mit konkreten Vorschlägen zu Architektur- oder Entwicklungsmeetings gehen können, um diese Fehler in Zukunft zu vermeiden.

Als Chris und sein Team in Projekt Phoenix ihr Projekt Unicorn so erfolgreich deployten, hatten sie offensichtlich Nygards Buch gelesen.

Eine kleine Geschichte am Rande: Ich besuchte eine Präsentation von Michael Nygard auf den DevOpsDays 2010 in Mountain View, und es war einer der besten Vorträge, den ich je gehört habe. Dort gab Nygard eine so intensive Beschreibung einer desaströsen Anwendungsauslieferung zum Besten, die noch wochenlange Nachwehen und heroische Einsätze von IT Operations nach sich zog, dass ich nur insgeheim hoffen kann, dass die Szenen aus den Phoenix-Deployment-Katastrophen ähnlich verstörend wirken.

Visible Ops und ITIL Service Support

Als Kevin Behr und ich im Jahr 1999 mit der Untersuchung von IT-Organisationen begannen, die sehr gut liefen, fanden wir heraus, dass es sich dabei um die Organisationen handelte, die gleichzeitig »die höchsten IT-Service-Levels erreichten (zum Beispiel MTTR, MTBF, Change Success Rate), frühestmöglich Information Security in den Software- oder Service-Entwicklungs-Lifecycle einbanden, Compliance am besten erfüllten (zum Beispiel die geringste Zahl an wiederholten Audit-Findings) und erstaunlicherweise die beste IT-Effizienz lieferten (zum Beispiel beim Verhältnis Server/Sysadmin).«²⁴

Wir haben uns elf sehr gut laufende IT-Organisationen angeschaut, unter anderem eine Bank, eine Aktienbörse, einen Dienst für kontaktloses Bezahlen, einen Domain-Name-Serviceprovider und zwei IT-Serviceprovider.

Kevin und ich versuchten gemeinsam, herauszufinden, wie es diese Organisationen geschafft hatten, ihre schon gute IT großartig zu machen, und wir haben unsere Erkenntnisse in den Büchern The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps und Visible Ops Security: Achieving Common Security and IT Operations Objectives in 4 Practical Steps dokumentiert, die von den gleichen Autoren wie Projekt Phoenix geschrieben wurden.

Ein entscheidender Teil dieser Reise wurde nur möglich durch das ITIL Service Support Book (V2), das zweifelsohne zu jeder Diskussion über IT Operations dazugehört. Ich habe dieses Buch geliebt, als ich es 2000 das erste Mal las, da es die Schlüsselprozesse, die in jeder gut laufenden IT-Organisation vorhanden sein müssen, katalogisiert und normiert. Aber ITIL ist ein beschreibendes Framework, und Organisationen machen keine beschreibenden Frameworks – sie machen Projekte.

Unser Ziel der Visible-Ops-Serie war, einen Satz von Schritten (Projekten) zusammenzustellen, mit denen die Ergebnisse wiederholt werden können, die die High-Performer erreichen. (Zufälligerweise ist das auch das, was wir mit dem anstehenden DevOps Cookbook erreichen wollen.)

Zwei großartige Bücher über Kanbans

Ich habe Sie jetzt hoffentlich davon überzeugt, dass die Probleme, die mit zu viel WIP in der IT zusammenhängen, wirklich verheerend sind. Viele Praktiker glauben, dass Kanbans zu den effektivsten (und einfachsten) Gegenmaßnahmen gehören.

Zwei Bücher zu Kanbans möchte ich jedem empfehlen, der auch nur entfernt Interesse daran hat.

Das erste Buch ist Personal Kanban: Mapping Work | Navigating Life von Jim Benson und Tonianne DeMaria Barry. Dieses Buch ist mehr eines zur persönlichen Produktivität als zu komplexen Wertschöpfungsketten. Tatsächlich würde ich es eher als moderne Version von David Allens tollem Buch Wie ich die Dinge geregelt kriege: Selbstmanagement für den Alltag (Original: Getting Things Done: The Art of Stress-Free Productivity) bezeichnen.

Wo Allen die Natur der Arbeit behandelt, die Wichtigkeit eines Kalenders zum Einhalten von Zusagen und die Theorie rund um To-do-Listen, geht es bei Benson und Barry darum, wie notwendig es ist, unsere Arbeit sichtbar zu machen und die Menge an WIP zu steuern. Sie schlagen vor, dass jeder sein eigenes Kanban-Board einrichten sollte, auf dem sich drei einfache Spalten befinden: Bereit, In Arbeit und Erledigt.²⁵

Und obwohl ich ein echter Fan von David Allens GTD bin, habe ich nach dem Lesen von Personal Kanban schnell meine kontextuellen To-do-Listen an den Nagel gehängt, die mich mehr als zehn Jahre begleitet hatten, und bin auf ein Kanban-Board umgestiegen. Das hat mir auf vielerlei Weise dabei geholfen, einen der kritischsten Aspekte der GTD-Methodik aufzulösen: die wöchentlichen Ausführungs-Meetings, in denen wir unsere Zusagen neu priorisieren sollten, unsere To-do-Listen aufräumen und so weiter. Es gab Jahre, in denen ich das kein einziges Mal getan habe.

Bei Kanban-Boards ist meine Arbeit hingegen immer sichtbar, und es gibt WIP-Grenzen, die verhindern, dass ein vorgegebenes Limit überschritten wird. Ich habe auf Jim Bensons Kanban-Board in seinem Büro gesehen, dass seine »In Arbeit«-WIP-Grenze bei vier liegt (es sind also nicht mehr als vier Karten in der Spalte »In Arbeit« erlaubt).

Das zweite empfehlenswerte Buch ist Kanban: Successful Evolutionary Change for Your Technology Business von Davin J. Anderson – es konzentriert sich mehr auf den Einsatz von Kanban-Boards in Unternehmen.

Dieses Buch brachte mir überraschende Erkenntnisse, da es auch eine Microsoft-IT-Fallstudie behandelt, die ich im Rahmen des Kurses EM 526 (»Constraints Management«) gelesen hatte. Es handelt sich dabei um einen Artikel aus dem Jahr 2005: »From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department« von David J. Anderson und Dragos Dumitriu.²⁶ Die Welt ist klein.

Sowohl Anderson als auch Dumitriu waren damals bei Microsoft beschäftigt, und sie beschrieben einen katastrophalen Zustand, der den meisten IT-Praktikern vertraut sein dürfte:

• Aufgaben aus dem Business brauchten zu lange für ihre Erledigung: Die durchschnittliche Bearbeitungszeit betrug 155 Tage.

• Die Verärgerung über Verspätungen und lange Bearbeitungszeiten zwang das IT-Management dazu, mehr Arbeitsabschätzungen abzugeben, wodurch die Manager gezwungen waren, ihre Zeit mit dem Erstellen von PowerPoints zu verbringen (weil das Business davon ausging, dass sie ihre Arbeit schlecht machten), statt echte Arbeit zu erledigen.

• Egal, wonach Business fragte – die Antwort war immer: »Es dauert fünf Monate.«

• Jede Aufgabe war mit 20 Tagen geschätzt, aber keiner wusste, woher die anderen 135 Tage kamen.

Dumitriu richtete ein neues Feld »Waiting For Dragos« in ihrem Ticket-System ein (tatsächlich handelte es sich dabei um das Defect Tracking System von Microsoft), um festhalten zu können, wenn Arbeit blockiert war. Er fand schnell heraus, dass 70 Prozent der Zeit des Teams durch andere Leute blockiert wurde – mit anderen Worten: Die Arbeit lungerte zu 70 Prozent der Zeit in Warteschlangen herum.

Dumitriu erkannte zudem, dass sein Team nur drei Arbeitsaufträge pro Monat fertigstellen konnte und dass es bei dieser Rate drei Jahre dauern würde, bis alle Arbeit erledigt wäre. Folgende Gegenmaßnahmen führten dann zu den erstaunlichen Ergebnissen:

• Sie schätzten den Arbeitsaufwand nicht mehr ein, sondern nutzten echte Zeitwerte aus vergangenen Aufträgen – sie hatten 80 Mannjahre Arbeit in ihrem Ticket-System stecken, die konnten sie auswerten. Das führte direkt zu einer 30-prozentigen Beschleunigung der Dev- und Test-Produktivität.

• Sie führten keine Kostenrechnung mehr durch, sondern nutzten stattdessen einen einfachen »ROI basierend auf Budgetbeiträgen«. Damit bekam PM weitere 20 Prozent Kapazität frei.

• Sie erkannten, dass die Entwicklung der Engpass war. Also übernahm PM viele der Entwickleraufgaben, womit deren Kapazität um 20 Prozent anstieg. Außerdem waren die Entwickler glücklich, weil sie jetzt mehr programmieren konnten, statt sich mit Aufwandsabschätzungen herumschlagen zu müssen.

• Sie holten sich einen Usability-Experten ins Team, um die Change-Request-Formulare anzupassen. (Der witzelte: »Um ein Glas Wasser zu bekommen, mussten wir ein vierseitiges Formular ausfüllen. Das haben wir durch ein zweiseitiges Formular ersetzt, in dem viele Felder freie Texteingabe ermöglichten. So konnte sichergestellt werden, dass die Person, die die Arbeit erledigt, alle notwendigen Informationen besitzt.«)

• Sie verringerten die maximal erlaubte Menge an WIP im System: Ursprünglich gab es durchschnittlich 40 bis 60 offene Punkte im System. Diese wurden auf 5 reduziert.

• Sie legten dann einen Arbeitspuffer an, sodass jeder blockierte Entwickler oder Tester an etwas im Puffer arbeiten konnte.

• Die Bearbeitungszeit reduzierte sich von 155 auf 22 Tage. Das war so gut, dass sie ein neues SLA aufsetzten, das 25 Tage garantierte. (Wow!)

• Der nächste große Produktivitätsschub entstand durch das Erhöhen der Anzahl der Entwickler. Denn für jeweils zwei Tage Entwicklung wurde ein Tag Testen gebraucht. Sie beförderten Tester, die in die Entwicklung wechseln wollten, und veränderten das Dev/Test-Verhältnis von 1/1 auf 2/1.

• Das Ergebnis? Ihr komplettes Backlog mit drei Jahren Arbeit wurde in neun Monaten abgearbeitet, ihre Dienste wurden gefragter, und sie schafften es weiterhin, jeden Monat das zu liefern, worum sie gebeten wurden. Keiner wurde entlassen, stattdessen gab es Beförderungen.

Dumitriu sagt: »Wir hatten Erfolg, weil wir uns die ganze Zeit darauf konzentriert haben, die Bearbeitungszeit zu senken, während Dev und Test nur ihren eigenen Bereich optimierten.«

Diese Geschichte ist nur eine der vielen erstaunlichen Transformationen, die detailliert beschrieben werden. Interessanterweise beruhen diese Transformationen gar nicht primär auf Automatisierung. Stattdessen kommen die größten Verbesserungen aus angepassten Richtlinien rund um das Arbeitssystem und das Steuern der WIP, dem Sicherstellen, dass es effektive, funktionsübergreifende Teams gibt, dem Unterordnen aller Abläufe unter den Engpass und dem guten Verwalten von Übergaben.

Anderson dokumentiert in seinem Buch auch die Änderungen seiner Einstellung gegenüber der Steuerung der Arbeit in der IT-Wertschöpfungskette. Es ist klar, dass er Dr. Goldratts Arbeit sehr schätzt (zum Beispiel Theory of Constraints und Drum-Buffer-Rope), aber er fand auch heraus, dass der Einsatz von Kanban-Boards die größten Vorteile durch das Sichtbarmachen der Arbeit bringt.

Ich empfehle unbedingt, dieses Buch zu lesen, da es echte Verbesserungen in echten Firmen wie Sprint, Motorola, Microsoft und Corbis beschreibt.

Danksagungen

Zuallererst möchte ich mich für die Unterstützung durch meine geliebte Frau Margueritte bedanken, die viel mehr ertragen musste, als ich angekündigt hatte, und bei meinen Söhnen Reid, Parker und Grant.

Ich bedanke mich bei Todd Sattersten, Tim Grahl, Merridawn Duckler und Kate Sage für ihre unglaubliche Hilfe und Unterstützung bei der Entstehung dieses Buchs. Mein tiefer Dank für unermüdliche Beiträge und Hinweise geht auch an Paul Muller von HP, Paul Proctor von Gartner, Branden Williams von RSA, Dr. Tom Longstaff von der Johns Hopkins University, Julia Allen von SEI/CMU, Adrian Cockcroft von Netflix, Christopher Little von BMC, Bob McCarthy, Lisa Schwartz von ITSM Academy, Jennifer Bayuk, Ben Rockwood von Joyent, Josh Corman von Akamai, James Turnbull von Puppet Labs, Charlie Betz von Enterprise Management Associates, Dr. Gene Spafford von CERIAS an der Purdue University, Dwayne Melancon von Tripwire und Michael Krigsman von Asuret.

Auch möchte ich die Beiträge meiner Koautoren des DevOps Cookbook hervorheben: Patrick DeBois, John Wills und Mike Orzen. Sie haben unter anderem die Praktiken herausgearbeitet, die zu den Drei Wegen wurden, über die Erik spricht.

Ich bedanke mich bei John Allspaw, Paul Hammond und Jez Humble für ihre bahnbrechenden und wegweisenden Beiträge zum Ermöglichen eines schnellen Flusses der IT-Wertkette.

Und vielen Dank an all die anderen Korrekturleser, die dabei halfen, das Manuskript zu verbessern: David Allen, David Bills, Kip Boyle, Shane Carlson, Carlos Casanova, Scott Crawford, Iris Culpepper, Mike Dahn, Chris Eng, Paul Farrall, Daniel Francisco, Kevin Hood, Matt Hooper, Tom Howarth, Kevin Kenan, Paul Love, Norman Marks, Tom McAndrew, Ally Miller, David Mortman, Wendy Nather, Michael Nygard, John Pierce, Dennis Ravenelle, Sasha Romanosky, Susan Ryan, Fred Scholl, Lawrence »Butch« Sheets, Bill Shinn, Adam Shostack, Ariel Silverstone, Dan Swanson, Joe »Feech« Telafici, Jan Vromant und Lenny Zeltser.

Die Methode zum Erstellen, Verknüpfen und Berechnen von Dicks Firmenzielen mit IT-Aktivitäten basiert auf der »Risk-Adjusted Value Management«-Methode, die von Paul Proctor und Michael Smith bei Gartner, Inc., entwickelt wurde.

Das Tool zum Beschränken bestimmter interner Audit-Sicherheitsmaßnahmen auf bestimmte IT-Sicherheitsmaßnahmen trägt den Namen GAIT, und es wurde vom Institute of Internal Auditors entwickelt.

Meinen herzlichsten Dank an meine Assistentin Hannah Concannon, die es mir ermöglicht hat, mich auf das Schreiben zu konzentrieren und das Buch abzuschließen, und die bei den letzten Änderungen mitgeholfen hat.

Auch möchte ich mich bei Tim Ferriss und den anderen Alumni der Kimono Group bedanken, die mir die Theorie und Praxis einer Buchveröffentlichung erklärt haben.

Gene Kim
Portland, Oregon, 10. Juni 2012

Ich möchte mich bei meiner Frau Erica und meinen Töchtern Emily und Rachel für ihre Geduld mit mir und ihr Verständnis für meine Berufswahl danken, wegen der ich so viel unterwegs bin. Mein besonderer Dank geht an meine freundlichen Mitverschwörer Gene Kim und George Spafford, die sehr anpassungsfähig waren und meine unzähligen Beschwerden ertragen haben.

Ich hatte das unglaubliche Glück, im Laufe der Jahre mit einigen der kreativsten und brillantesten CXOs meiner Zeit zusammenarbeiten zu können, wie zum Beispiel Will »Prefontaine« Weider, CIO von Ministry Healthcare, Robert Slepin, CIO von John C. Lincoln Health Network, Oliver Eckel, CEO von Cognosec, Rob Leahy, CFO von Transdermal Corporation, Jeff Hughes, VP bei Radiant Systems, Paul O’Neil, CEO von Kerzner International, und Nana Palmer, COO von Kerzner International. Sie alle haben mir viel über Mut zum Experimentieren und das radikale Verbessern des IT-Durchsatzes beigebracht.

Schließlich möchte ich mich noch bei meinem Freund und Komplizen bei vielen dieser Verbesserungslehren bedanken: John Dennin, Senior Engagement Manager bei Assemblage Pointe, Inc.

Kevin Behr
Lancaster, Pennsylvania, 1. Juni 2012

Die Reise von Visible Ops zu Projekt Phoenix hat meinen großen Respekt und meine Wertschätzung von Gene und Kevin noch mehr zementiert. Die Herausforderungen und Diskussionen, die wir beim Schreiben dieses Buchs hatten, haben unsere gemeinsamen Fähigkeiten gestärkt, unsere Beobachtungen zur IT-Branche niederzuschreiben.

Gentlemen – vielen, vielen Dank!

Noch wichtiger ist der Dank für die andauernde Liebe, Motivation, Unterstützung und Geduld meiner besseren Hälfte Rowena. Ich danke meinen Kindern Paolo, Alyssa und Erika, die sich alle selbstlos mit meinem chaotischen und zeitaufwendigen Terminplan arrangieren mussten, selbst in den Ferien. Dank geht auch an meine Eltern Carroll und Alpha, die in mir die Liebe zum Lernen geweckt haben. Ihr seid eine wichtige Hilfe auf meinem fortdauernden Weg zum Verbessern aller Aspekte meines Lebens.

George Spafford
Saint Joseph, Missouri, 1. Juni 2012

Fußnoten

Kapitel 1: Dienstag, 2. September

¹ Über das ROTC (Reserve Officers’ Training Corps) der US-Streitkräfte sind Studienstipendien möglich, im Gegenzug müssen sich die Studenten für eine gewissen Zeit zum Militärdienst verpflichten. [Anm. d. Übers.]

Anhang: Weiterführende Informationen

¹ Die Code Deployment Lead Time ist die Zeit, die von »Änderung ist in Versionskontrolle eingecheckt« bis »Läuft erfolgreich in der Produktivumgebung« benötigt wird.

² Jez Humble, Gene Kim und Puppet Labs, »2013 State of DevOps Infographic«, Puppet Labs Labs Website, abgerufen am 14. Juli 2014, https://puppetlabs.com/2013-state-of-devops-info-graphic/

³ Jez Humble, Nigel Kersten, Gene Kim und Nicole Forsgren Velasquez, »2014 State of DevOps Report«, Puppet Labs Website, abgerufen am 15. Juli 2014, http://puppetlabs.com/2014-devops-report

⁴ Neben der Übernahme von Lean-Prinzipien gehörten zu weiteren Techniken das Toyota Production System, Lean Manufacturing, Theory of Constraints, Six Sigma und so weiter.

⁵ Die Auftragsdurchlaufzeit ist die Zeit von »Auftrag von der Fertigungsverwaltung angenommen« bis »Auftrag an Kunden ausgeliefert«.

⁶ Dr. Eliyahu Goldratt, Beyond the Goal: Eliyahu Goldratt Speaks on the Theory of Constraints (Prince Frederick, Maryland: Gildan Media Corporation, 2005)

⁷ John Willis, »The Convergence of DevOps«, IT Revolution Press (Blog), 2012, abgerufen am 14. Juli 2014, http://itrevolution.com/the-convergence-of-devops/

⁸ John Allspaw und Paul Hammond, »10+ Deploys Per Day: Dev and Ops Cooperation at Flickr«, O’Reilly Velocity Conference Website, 23. Juni 2009, abgerufen am 14. Juli 2014, http://velocityconf.com/velocity2009/public/schedule/detail/7641

⁹ LAMP ist die Abkürzung für »Linux, Apache Web Server, MySQL-Datenbank, PHP oder Python oder Perl«.

¹⁰ Richard Foster und Sarah Kaplan, Creative Destruction: Why Companies That Are Built to Last Underperform the Market—and How to Successfully Transform Them (New York: Broadway Books, 2001)

¹¹ Jim Gray, »A Conversation with Werner Vogels: Learning from the Amazon Technology Platform«, Association for Computing Machinery Website, 20. Juni 2006, http://queue.acm.org/detail.cfm?id=1142065

¹² Raffi Krikorian, »Real-Time Systems at Twitter« (Präsentation auf der Velocity Conference), Slideshare Website, 26. Juni 2012, http://www.slideshare.net/raffikrikorian/realtime-systems-at-twitter

¹³ Ashlee Vance, »Inside Operation InVersion, the Code Freeze That Saved LinkedIn«, Enterprise Tech (Blog), Bloomberg BusinessWeek, 10. April 2013, http://www.businessweek.com/articles/2013-04-10/inside-operation-inversion-the-code-freeze-that-saved-linkedin

¹⁴ Michael Rembetsy und Patrick McDonnell, »Continuously Deploying Culture: Scaling Culture at Etsy« (Präsentation auf der Velocity Europe Conference), Slideshare Website, 4. Oktober 2012, http://www.slideshare.net/mcdonnps/continuously-deploying-culture-scaling-culture-atetsy-14588485

¹⁵ Pedro Canahuati, »From the Few to the Many: Scaling Ops at Facebook« (Präsentation auf der OmniTI Surge Conference), 12. September 2013, http://surge.omniti.com/2013/speakerslides/surge13_Scaling-Operations-Organization-at-Facebook_Canahuati.pdf

¹⁶ Shane H., »Wait time = (% busy) / (% idle)«, The Phoenix Project Discussion Group, LinkedIn Website, 29. März 2013, https://www.linkedin.com/groups/Wait-time-busy-idle-4865747.S.227406165?trk=groups_most_popular-0-b-ttl&qid=ab4853b8-10a5-4adf-a666-038c0a65471e&goback=.gmp_4865747

¹⁷ »Jonah Trained« wird gar nicht mehr benutzt. Mittlerweile existieren von der Theory of Constraints International Certification Organization offizielle Zertifizierungsprogramme. Zum Zeitpunkt der Entstehung dieses Buchs gibt Dr. Holt immer noch diese Kurse, deren Beschreibung online zu finden ist. (Siehe »EM 526 Constraints Management« (Kurs), Washington State University Website, abgerufen am 15. Juli 2014, http://public.wsu.edu/~engrmgmt/holt/em526/em526syl.htm; EM 530 »Applications in Constraints Management« (Kurs), Washington State University Website, abgerufen am 15. Juli 2014, http://public.wsu.edu/~engrmgmt/holt/em530/index.htm)

¹⁸ Siehe »Teamwork«, Table Group Website, abgerufen am 15. Juli 2014, http://www.tablegroup.com/teamwork

¹⁹ Siehe »Personal History Exercise«, Table Group Website, abgerufen am 15. Juli 2014, http://www.tablegroup.com/imo/media/doc/Personal%20Histories%20Exercise.pdf

²⁰ Der Shingo Prize wird häufig als »Nobelpreis der Produktion« bezeichnet. Mike Rothers wurde damit schon drei Mal ausgezeichnet.

²¹ Dieser Begriff bezieht sich auf das Verhalten präindustrieller Stämme in Neuguinea und Mikronesien kurz nach dem Zweiten Weltkrieg. Nachdem sie beobachtetet hatten, wie amerikanische und japanische Soldaten fortlaufend Güter ins Land brachten, waren sie überrascht, als der Krieg und damit die Lieferungen endeten. Sie versuchten, wieder neue Güter zu bekommen, indem sie das beobachtete Verhalten des US Corps of Engineers imitierten und Landebahnen und Funkstationen »nachbauten«. Trotz dieser Versuche kamen die Flugzeuge aber nie zurück.

²² Siehe John Willis, »The Convergence of DevOps«, IT Revolution Press (Blog), 2012, http://itrevolution.com/the-convergence-of-devops/

²³ Tatsächlich erinnere ich mich daran, wie ich in einer Session einer Velocity Conference neben Adrian Cockcroft saß und mitbekam, wie er das Kapitel und den Absatz benannte, wenn er eines der Nygard-Muster im Vortrag erkannte. Die Person, die den Vortrag hielt, hätte das Buch lesen sollen.

²⁴ Kevin Behr, Gene Kim und George Spafford, The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps (Information Process Technology Institute, 2005)

²⁵ Jim Benson, »Building Your First Personal Kanban«, Personal Kanban (Blog), 23. August 2009, http://www.personalkanban.com/pk/primers/building-your-first-personal-kanban/#sthash.XBF0Tntz.JhxVWjGG.dpbs

²⁶ David J. Anderson und Dragos Dumitriu, »From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department«, veröffentlicht von Microsoft und Theory of Constraints International Certification Organization, November 2005, http://images.itrevolution.com/images/kanbans/From_Worst_to_Best_in_9_Months_Final_1_3-aw.pdf. Ich entschuldige mich für meine Hervorhebungen im PDF – der Originalartikel ist online nicht mehr zu finden, und die einzige Version, die ich besitze, ist eben diese. Sie können sich vorstellen, wie begeistert ich war, als ich es 2007 las.