Warum Transformationsprojekte immer wieder dieselben Fehler wiederholen

Jedes gescheiterte ERP-Projekt hinterlässt Daten, Erfahrungen und Ursachen. Trotzdem wiederholen Unternehmen dieselben Fehler. Warum das so hartnäckig funktioniert und was konkret hilft.

Kaum ist eine Krise überstanden, läuft die nächste Transformation an, als hätte es die letzte nie gegeben. Das war nach der Pandemie so, und in Industrieprojekten ist es bis heute so.

Jedes gescheiterte ERP-Projekt, jede misslungene Digitalisierung, jeder abgebrochene Change hinterlässt Daten, Erfahrungen und Ursachen. Trotzdem stellen wir bei fast jedem neuen Vorhaben dieselben Fragen, treffen dieselben Annahmen und wiederholen dieselben Fehler.

Die Frage ist, warum das so hartnäckig funktioniert. Und was ein Unternehmen konkret anders machen kann.

Was Unternehmen nach einem Projekt tatsächlich festhalten

In den meisten Organisationen gibt es am Projektende eine Abschlussdokumentation. Darin steht, was erreicht wurde, wie das Budget gelaufen ist, welche Meilensteine wann erfüllt waren und welche offenen Punkte übergeben werden.

Das ist sauber gearbeitet und trotzdem weitgehend wertlos für das nächste Projekt. Denn es dokumentiert Ergebnisse. Was fehlt, sind die Entscheidungen, die zu diesen Ergebnissen geführt haben.

Wer im Nachhinein liest, dass ein Hochlauf sechs Monate zu spät kam, weiss danach genau so wenig wie vorher. Interessant wäre gewesen, wer im Januar auf welcher Grundlage entschieden hat, dass die Qualifizierung parallel zur Serienfertigung laufen kann. Diese Information steht nirgends. Sie war der eigentliche Wendepunkt.

Warum Lessons Learned in der Praxis selten etwas verändern

Fast jedes Unternehmen kennt das Format. Am Projektende wird ein Termin angesetzt, die Beteiligten sammeln, was gut lief und was nicht, jemand schreibt es auf, die Datei landet auf einem Laufwerk.

Drei Dinge sorgen dafür, dass daraus nichts folgt.

Erstens findet der Termin zu spät statt. Wer sechs Monate nach der kritischen Phase zusammensitzt, erinnert sich an das Ergebnis, nicht mehr an den Informationsstand von damals. Rückblickend wirkt jede Fehlentscheidung offensichtlich, und genau deshalb lernt niemand etwas daraus.

Zweitens sind die Falschen im Raum. Es kommen die, die das Projekt abgeschlossen haben, nicht die, die es geplant haben. Die Annahmen, auf denen alles aufbaute, kennt aber nur die Planungsseite.

Drittens, und das ist der eigentliche Grund, kippt die Analyse in die Schuldfrage. Sobald jemand ahnt, dass die Aufarbeitung auf ihn zurückfällt, wird nicht mehr erklärt, sondern verteidigt. Ab diesem Punkt ist der Termin inhaltlich beendet, auch wenn er noch eine Stunde dauert.

Der Unterschied zwischen Ergebnissen dokumentieren und Entscheidungen analysieren

Ergebnisse zu dokumentieren beantwortet die Frage: Was ist passiert?

Entscheidungen zu analysieren beantwortet eine andere Frage: Auf welcher Grundlage haben wir damals gehandelt, und was davon war eine Annahme statt einer Tatsache?

Wer Fehler nur abschliesst, wiederholt sie. Wer sie versteht, baut daraus bessere Prozesse, bessere Organisationen und bessere Entscheidungen.

Der Unterschied ist erheblich. Nicht die Software entscheidet über den Erfolg eines Projekts, nicht das Budget und nicht die Methode. Sondern die Fähigkeit, aus dem letzten Vorhaben tatsächlich etwas mitzunehmen.

Wie eine ehrliche Projektanalyse konkret abläuft

Das Verfahren ist unspektakulär und braucht keine Methode aus dem Lehrbuch. Vier Schritte reichen.

• Die Entscheidungen auflisten, nicht die Ereignisse. Man geht das Projekt durch und notiert jeden Punkt, an dem eine Richtung festgelegt wurde. Lieferant beauftragt, Termin zugesagt, Ressource abgezogen, Umfang erweitert. In einem mittelgrossen Vorhaben sind das selten mehr als fünfzehn bis zwanzig Punkte.
• Zu jeder Entscheidung den damaligen Wissensstand rekonstruieren. Was war zu diesem Zeitpunkt bekannt, was war Annahme, was war Hoffnung? Diese Trennung ist der ganze Kern der Übung. Fast jedes gescheiterte Projekt enthält zwei oder drei Annahmen, die nie als solche benannt wurden, sondern von Anfang an als Tatsachen behandelt wurden.
• Prüfen, ob die Entscheidung mit dem damaligen Wissen vertretbar war. Das ist die Frage, die vor der Schuldzuweisung schützt. Eine Entscheidung kann richtig gewesen sein und trotzdem zu einem schlechten Ergebnis geführt haben. Und sie kann falsch gewesen sein, obwohl es am Ende gut ausging. Wer beides nicht auseinanderhält, lernt aus dem Zufall statt aus dem Verlauf.
• Ableiten, welche Frage künftig früher gestellt werden muss. Am Ende steht keine Massnahmenliste mit dreissig Punkten, sondern eine Handvoll Fragen, die im nächsten Projekt zu Beginn beantwortet werden. Genau diese Fragen sind das Ergebnis, das sich weitergeben lässt.

Der zeitliche Aufwand dafür liegt bei einem halben Tag. Der Termin sollte innerhalb weniger Wochen nach der kritischen Phase stattfinden, nicht nach dem formellen Projektabschluss, und moderiert werden von jemandem, der keine Verantwortung für das Ergebnis trägt.

Warum das trotzdem so selten passiert

Weil ehrliche Analyse unbequem ist. Sie legt offen, dass eine Zusage gegeben wurde, für die es keine Grundlage gab. Dass eine Warnung im Raum stand und niemand sie hören wollte. Dass ein Termin nicht am Markt hing, sondern an einer Präsentation.

Solange Fehler in einer Organisation als persönliches Versagen gelten, wird niemand freiwillig zur Aufklärung beitragen. Deshalb ist die Voraussetzung für jede brauchbare Analyse nicht eine Methode, sondern eine Haltung: Es geht um die Entscheidung, nicht um die Person.

Diese Haltung lässt sich nicht anordnen. Sie muss von dem vorgelebt werden, der am meisten zu verlieren hat, also von der Führung selbst. Wer als Geschäftsführer die erste eigene Fehlentscheidung offen auf den Tisch legt, bekommt danach eine Analyse, die etwas wert ist.

Wie wir damit umgehen

Wenn wir ein Mandat übernehmen, ist die erste Frage nicht, was jetzt geplant werden soll. Sondern was beim letzten Anlauf passiert ist. In den meisten Fällen gab es einen, und in den meisten Fällen kennt im Haus jeder die inoffizielle Version.

Diese Version ist wertvoller als jede Abschlussdokumentation. Sie steht nur in keiner Datei, sondern man erfährt sie in der Halle, im Gespräch mit Schichtführern und Meistern, meistens nach der dritten oder vierten Frage.

Genau hier liegt der Unterschied zu einer klassischen Grossberatung. Ein Konzept, das die Zukunft beschreibt, ohne die letzte Vergangenheit verstanden zu haben, wiederholt die Fehler des Vorgängers auf höherem Niveau. Wir übernehmen operative Verantwortung und bleiben, bis es läuft. Der Massstab ist nicht der Bericht am Ende, sondern die Frage, ob es noch läuft, wenn wir weg sind.

Transformation beginnt deshalb nicht mit dem nächsten Projekt. Sie beginnt mit der ehrlichen Analyse des letzten.

Über SMART iNTERIM

SMART iNTERIM Management begleitet produzierende Unternehmen bei operativer Transformation: Restrukturierung, Werksaufbau, Werksverlagerung, Turnaround und Prozessoptimierung. Wir kommen aus der Praxis, nicht aus der Distanz, und übernehmen operative Verantwortung statt nur Empfehlungen abzugeben. Hauptsitz Schweiz, Niederlassung Dubai.