Irgendwo in Deutschland, irgendwann zwischen 2018 und heute, sitzt ein Vorstand in einem Besprechungsraum im sechsten Stock. Der Raum heißt "Innovation Lab" oder "Think Tank" oder "Columbus", weil Besprechungsräume in deutschen Konzernen immer nach etwas benannt werden, das Aufbruch suggeriert, während drinnen Stillstand verwaltet wird.
Der Vorstand hat ein Problem. Die IT ist alt. Die Systeme reden nicht miteinander. Der Vertrieb benutzt Excel. Das Lager benutzt ein anderes Excel. Die Buchhaltung benutzt ein drittes. Und irgendwo im Keller steht ein Server, auf dem eine Software läuft, die ein Mann geschrieben hat, der seit 2014 in Rente ist.
Der Vorstand sagt den Satz, den alle Vorstände irgendwann sagen: "Wir brauchen eine Transformation."
Was danach passiert, ist immer dasselbe. Es passiert seit dreißig Jahren. Es passiert gerade jetzt, in diesem Moment, in Konzernen und Mittelständlern und Behörden. Es passiert mit der Zuverlässigkeit einer Naturkatastrophe, nur dass Naturkatastrophen irgendwann aufhören.
Das Eiserne Gesetz
Bent Flyvbjerg ist Professor in Oxford und hat sein Berufsleben damit verbracht, Großprojekte zu vermessen. Nicht zu beurteilen, nicht zu beraten. Zu vermessen. Mit Daten. Über 16.000 Projekte in seiner Datenbank, aus allen Branchen, allen Ländern, allen Jahrzehnten. Das Ergebnis hat er das "Eiserne Gesetz der Megaprojekte" genannt:
Über Budget. Über Zeit. Unter Nutzen. Immer wieder.
Die Zahlen: 92 Prozent aller Großprojekte sprengen Budget oder Zeitplan oder beides. Nur 8 Prozent kommen pünktlich und im Budget ins Ziel. Und nur 0,5 Prozent, ein halbes Prozent, kommen pünktlich, im Budget und liefern den versprochenen Nutzen.
0,5 Prozent. Wenn ein Medikament eine Erfolgsquote von 0,5 Prozent hätte, würde es niemand nehmen. Wenn eine Fluggesellschaft in 0,5 Prozent der Fälle sicher landen würde, gäbe es sie nicht mehr. Aber bei IT-Transformationsprojekten investieren Unternehmen trotzdem Millionen, Hunderte Millionen, manchmal Milliarden, in etwas, das in 99,5 Prozent der Fälle nicht so funktioniert wie versprochen.
Warum?
Weil das Versprechen zu schön ist. Weil PowerPoint alles kann. Weil der Berater im Anzug überzeugend lächelt. Und weil die Alternative, also nichts tun, noch beängstigender klingt.
Lidl, oder: Eine halbe Milliarde für nichts
2011 entschied Lidl, sein Warenwirtschaftssystem zu ersetzen. Das alte System hieß "Wawi". Intern entwickelt. Funktionierte. Nicht elegant, nicht modern, aber es funktionierte. 12.000 Filialen in über 30 Ländern wurden damit gesteuert.
Das neue System sollte auf SAP laufen. SAP for Retail, powered by HANA. Der Name allein klingt wie etwas, das einem ein Berater an einem Whiteboard erklärt, mit Pfeilen und Wolken und einem Wort in jeder Wolke. Das Projekt hieß intern "eLWIS". Budget: 201 Millionen Euro.
Sieben Jahre später, 2018, war eLWIS tot. Eingestampft. Kosten bis dahin: 500 Millionen Euro. Eine halbe Milliarde.
Was war passiert?
Das Problem war banal. Lidl rechnet sein Warenwirtschaftssystem über Einkaufspreise. SAP rechnet über Verkaufspreise. Eine grundlegende Architekturentscheidung, die niemand in den ersten Monaten der Evaluation bemerkt oder thematisiert hat. Statt das eigene Geschäftsmodell anzupassen (undenkbar) oder SAP zu wechseln (zu spät), entschied Lidl, SAP umzubauen. Customizing. In der alten SaaS-Welt bedeutet das: Man nimmt ein starres Standardprodukt und biegt es so lange, bis es dem eigenen Geschäft ähnelt. Es ähnelt nie genug. Denn das Produkt wurde für den Durchschnitt gebaut, und kein Unternehmen ist Durchschnitt. Das Problem war nie, dass Firmen individuelle Anforderungen haben. Individuelle Anforderungen sind der Grund, warum sie existieren. Das Problem war, dass die Software nicht dafür gemacht war, ihnen zu folgen.
500 Millionen Euro. Sieben Jahre. Am Ende ging Lidl zurück zu Wawi. Dem alten System. Das die ganze Zeit über funktioniert hatte.
Die Anatomie des Scheiterns
Ich habe fünf Jahre in einem großen amerikanischen Beratungskonzern gearbeitet. Im Bereich Sales & Service, mit Schwerpunkt auf Business-Transformationen, oft SAP-nah. Ich sage das nicht, um Autorität zu beanspruchen, sondern um zu erklären, warum mir die Muster so vertraut sind.
Man erkennt ein scheiterndes Großprojekt nicht am Ergebnis. Man erkennt es am Anfang. An bestimmten Sätzen, die in bestimmten Meetings fallen, mit einer Regelmäßigkeit, die beunruhigt, wenn man sie einmal gesehen hat.
Der erste Satz: "Wir machen das einmal richtig."
Das klingt vernünftig. Das Gegenteil trifft zu. "Einmal richtig" heißt: alles auf einmal. Alle Systeme. Alle Prozesse. Alle Standorte. Ein Big Bang. Ein Projektplan, der drei Jahre umspannt und achthundert Zeilen hat und in einer Schriftgröße gedruckt wird, die niemand lesen kann, was vielleicht der Punkt ist.
Flyvbjerg nennt das Think Big, Start Big. Die tödlichste Kombination. Denn je größer das Projekt, desto mehr Variablen, desto mehr Schnittstellen, desto mehr Abhängigkeiten. Und jede Abhängigkeit ist eine Stelle, an der etwas schiefgehen kann. Nicht theoretisch. Praktisch. Garantiert.
Der zweite Satz: "Der Implementierungspartner hat Erfahrung."
Der Implementierungspartner hat Erfahrung mit der Implementierung. Nicht mit eurem Geschäft. Er kennt das System, nicht euer Lager, nicht eure Kunden, nicht eure gewachsenen Prozesse, die auf dem Papier irrational aussehen, aber seit fünfzehn Jahren funktionieren, weil Frau Meier aus der Logistik jeden Donnerstag manuell eine Liste abgleicht, die in keinem Prozessdiagramm vorkommt.
Frau Meier wird nicht gefragt. Frau Meier steht in keinem Steering Committee. Frau Meier erfährt vom neuen System in einer Townhall, bei der ein Mann mit Headset auf einer Bühne steht und "Change" sagt.
Der dritte Satz: "Wir sind anders."
Jedes Unternehmen, das ein Großprojekt startet, glaubt, anders zu sein. Glaubt, dass die Statistik für die anderen gilt. Für die, die es falsch gemacht haben. Wir sind besser vorbereitet. Wir haben die richtigen Leute. Wir haben Lessons Learned aus der Branche.
92 Prozent. Alle glaubten, anders zu sein.
Die deutschen Beispiele
Es gibt eine Liste. Sie ist lang.
Toll Collect: Das LKW-Mautsystem. Geplanter Start 2003. Tatsächlicher Start 2005. Zwei Jahre Verspätung. Ein Konsortium aus Daimler, Deutsche Telekom und Cofiroute. Hunderte Ingenieure. Tausend Experten. Die On-Board-Units funktionierten nicht. Manche funktionierten gar nicht. Der Staat verzichtete zwei Jahre lang auf Mauteinnahmen und übernahm das Unternehmen schließlich selbst.
BER: Geplante Eröffnung 2011. Tatsächliche Eröffnung 2020. Neun Jahre Verspätung. Ursprüngliches Budget: 2,83 Milliarden. Endkosten: über 7 Milliarden. Der Brandschutz funktionierte fundamental nicht.
Und dann die namenlosen. Die, die keine Schlagzeilen machen. Die SAP-Migration eines Mittelständlers in Baden-Württemberg. Budget: 3 Millionen. Tatsächliche Kosten: 8 Millionen. Dauer statt acht Monaten: zweiundzwanzig. Bei Go-Live konnte das System keine Rechnungen drucken. Rechnungen. Das Grundlegendste, was ein ERP tun muss. Der Mittelständler ist nicht pleite. Aber er hat zwei Jahre verloren, die er nicht hatte.
Durchschnittliche Kostenüberschreitung bei ERP-Implementierungen: 189 Prozent. Faktor drei, ungefähr. Ein Projekt, das eine Million kosten soll, kostet am Ende knapp drei. Ein Projekt über zehn Millionen kostet neunundzwanzig. Ein Projekt über hundert Millionen kostet zweihundertneunzig.
Peter Jacobs und die Elefanten
Peter Jacobs war CIO bei ING Netherlands. Davor McKinsey. Danach wieder McKinsey. Dazwischen hat er etwas getan, das in der Branche für Aufsehen gesorgt hat: Er hat ING nach dem Spotify-Modell umgebaut. Kleine, autonome Teams. Squads. Tribes. 350 Neun-Personen-Teams in 13 Tribes. Keine Wasserfall-Projekte. Keine dreijährigen Transformationspläne. Stattdessen: kleine Einheiten, schnelle Zyklen, direkter Kundenkontakt.
Bei einem Vortrag, den ich nicht verlinken kann, weil er nicht öffentlich ist (SFS München, circa 2019), hat Jacobs etwas gesagt, das ich seitdem nicht vergessen habe. Sinngemäß: Jeder Konzern, der eine "globale Transformation" startet, startet dasselbe Projekt. Er nannte es Project Globe. Nicht weil es so heißt. Sondern weil es immer so heißt. Oder "Horizon". Oder "Compass". Oder "Atlas". Die Namen klingen nach Entdeckung, und am Ende entdeckt man nur die eigene Unfähigkeit.
Die Alternative, die Jacobs bei ING eingeführt hat: den Elefanten in kleine Stücke schneiden (metaphorisch) und jedes Stück laufen lassen. Viele kleine Pläne statt eines großen. Autonome Teams statt eines Steering Committee. Hundert Go-Lives in drei Monaten statt eines in drei Jahren.
Was wäre, wenn
Stellt euch vor, ihr seid der Vorstand im sechsten Stock. Ihr habt das Problem. Alte Systeme. Medienbrüche. Excel-Listen.
Variante A: Ihr startet Project Globe. Ihr engagiert einen der großen Implementierungspartner. Ihr plant drei Jahre. Ihr budgetiert zwölf Millionen. In achtzehn Monaten seid ihr bei neunzehn Millionen und dem dritten Projektleiter. Das Steering Committee tagt monatlich und niemand sagt die Wahrheit. In drei Jahren habt ihr ein System, das funktioniert, aber nicht so, wie versprochen, und die Hälfte eurer Mitarbeiter hasst es.
Variante B: Ihr fangt klein an. Ein Prozess. Ein Team. Vier Wochen. Ihr nehmt den einen Prozess, der am meisten schmerzt, den einen, über den Frau Meier seit Jahren klagt, und baut dafür eine Lösung. Nicht ein System, das alles kann. Eines, das dieses eine Ding kann. In vier Wochen. Dann den nächsten Prozess. Und den nächsten.
In sechs Monaten habt ihr zehn Prozesse digitalisiert. Nicht perfekt. Aber funktionierend. Und Frau Meier hat am Donnerstag zwei Stunden weniger Arbeit. Und jeder einzelne Schritt war klein genug, um zu scheitern, ohne dass es wehtut.
Das klingt unspektakulär. Es soll unspektakulär klingen. Denn das Gegenteil von "spektakulär scheitern" ist "unspektakulär funktionieren". Und unspektakulär funktionieren ist das Einzige, was zählt.
Das Geschäft mit der Komplexität
Hier wird es unangenehm. Denn die Frage ist: Warum macht es niemand so?
Die Antwort ist, dass es ein Geschäft mit der Komplexität gibt. Große Implementierungspartner verkaufen große Projekte, weil große Projekte große Rechnungen erzeugen. Ein Vier-Wochen-Projekt ist für eine Beratung mit 500.000 Mitarbeitern kein Geschäft. Ein Drei-Jahres-Projekt mit achtzig Beratern vor Ort schon.
Große Softwarehersteller verkaufen große Lizenzen, weil große Lizenzen große Umsätze erzeugen. Ein modulares System, bei dem man nur bezahlt, was man benutzt, ist für einen Anbieter, der an Enterprise-Lizenzen gewöhnt ist, eine Bedrohung.
Das heißt nicht, dass alle Berater betrügen oder alle Softwarehersteller lügen. Es heißt, dass die Incentive-Struktur in eine Richtung zeigt, die nicht eure ist. Der Berater wird nicht bezahlt, wenn das Projekt schnell fertig ist. Er wird bezahlt, solange es läuft.
Kein Skandal. Marktwirtschaft. Aber man sollte es wissen, bevor man den Vertrag unterschreibt.
Zurück im sechsten Stock
Es ist spät. Der Vorstand sitzt noch im "Innovation Lab". Die PowerPoint ist durch. Hundertzwanzig Slides. Der Berater hat "Synergien" gesagt, vierzehn Mal, er hat mitgezählt.
Draußen regnet es. In Deutschland regnet es immer, wenn Entscheidungen anstehen.
Der Vorstand denkt an seine Optionen. Project Globe oder etwas anderes. Drei Jahre oder vier Wochen. Zwölf Millionen (die neunzehn werden) oder kleine Schritte (die funktionieren könnten).
Er denkt an Lidl. 500 Millionen. Sieben Jahre. Zurück zu Wawi.
Er denkt an den Server im Keller, auf dem die Software läuft, die der Mann geschrieben hat, der seit 2014 in Rente ist. Die Software funktioniert. Weder schön noch modern noch cloud-native. Aber sie funktioniert.
Manchmal ist das Beste, was man tun kann, die Dinge klein zu halten. Klein genug, um sie zu verstehen. Klein genug, um sie zu reparieren, wenn sie kaputtgehen. Klein genug, um am Montag damit anzufangen und am Freitag ein Ergebnis zu haben.
Immer wieder ein bisschen besser. Statt "einmal richtig" und dann nie wieder.
Das wussten wir vor sechs Jahren. Warum machen wir es immer noch nicht?