Warum scheitern ERP-Projekte?

Die kurze Antwort

ERP-Projekte scheitern, weil ein Unternehmen zwei schwierige Dinge gleichzeitig versucht — seine Arbeitsweise zu verändern und seine Software zu wechseln — und nur das Zweite plant. Das Softwareprojekt hat ein Budget, einen Zeitplan und einen Partner. Die Veränderung des Geschäfts hat nichts davon. Sie hat einen Steuerungsausschuss, der monatlich tagt, Key-User, die «bei Bedarf einbezogen» werden, und Daten, die «später» bereinigt werden.

Die konkreten Ursachen sind über Unternehmen, Branchen und Jahrzehnte hinweg bemerkenswert konstant: Prozesse, die niemand definiert hat, Anforderungen, die nach dem Vertrag gewachsen sind, Daten, die nie bereinigt wurden, ein Standardsystem, das an alte Gewohnheiten angebogen wurde, die täglichen Nutzer, die nicht am Tisch sassen, Entscheide, die monatelang ausgehungert wurden, und ein Go-live, das als Datum statt als Zustand behandelt wurde. Jedes berühmte Desaster besteht aus drei oder vier davon gleichzeitig — und jedes war Monate vorher sichtbar.

Was seltener gesagt wird: All das sind Fehler bei der Übersetzung — bei der Arbeit, die nötig ist, um ein starres System von Hand und unter Zeitdruck an ein echtes Unternehmen anzupassen. Das ist eine Eigenschaft davon, wie ERP gebaut wird, und es lohnt sich, zu trennen, was der Kunde falsch gemacht hat und was die Architektur wahrscheinlich gemacht hat. Dieser Artikel tut beides.

Was «Scheitern» heisst — und wie oft es passiert

Sie werden lesen, dass «50 bis 75 Prozent der ERP-Projekte scheitern». Sie werden auch lesen, dass die meisten Unternehmen mit ihrem ERP zufrieden sind. Beides stimmt, denn «Scheitern» bedeutet vier verschiedene Dinge, und die Zahlen ändern sich mit der Definition.

Zusammen gelesen sagen die Zahlen etwas Nützlicheres als jede einzelne: Das normale ERP-Projekt ist etwas verspätet, etwas über Budget und liefert weniger, als die Präsentation versprochen hat. Die offene Katastrophe — das abgebrochene System, das Unternehmen, das nicht mehr liefern kann — ist seltener, vielleicht eines von fünf oder sechs Projekten. Aber das alltägliche Scheitern, das Projekt, das live geht und still nicht liefert, ist die Mehrheitserfahrung. Um dieses geht es in diesem Artikel vor allem, denn darüber lesen Sie nichts in der Zeitung.

Die berühmten Fälle und was jeder lehrt

Die Desaster, die es in die Zeitungen schafften, sind je eine Minute wert — nicht aus Schadenfreude, sondern weil jedes davon der Fehler eines kleinen Unternehmens ist, in einer Grösse, in der er sichtbar wurde.

Beachten Sie: Keinem dieser Unternehmen fehlte es an Geld, Beratern oder Softwaremarken. Was ihnen fehlte, war ein Entscheid, wie sie arbeiten wollten, ein Go-live, das ein Zustand war und kein Datum, und jemand, der bereit war, einem Steuerungsausschuss «noch nicht» zu sagen.

Die sieben Ursachen, in der Reihenfolge, in der sie zuschlagen

Scheitern ist selten eine einzelne Sache. Es ist eine Abfolge, und diese Abfolge ist so regelmässig, dass sich jede Ursache einer Projektphase zuordnen lässt.

1. Niemand hat entschieden, wie das Unternehmen arbeiten soll

Das Projekt beginnt mit «das System einführen» statt mit «so soll ein Auftrag ab jetzt durch das Unternehmen laufen». Die Analysephase wird dann zum Ort, an dem dieser Entscheid fallen soll — mit Beratern auf dem Taxameter, in Workshops, in denen drei Abteilungen je ihre Version verteidigen. Software vervielfacht Klarheit und Chaos mit derselben Begeisterung; ist der Prozess unentschieden, setzt das System den Streit getreu um.

2. Die Anforderungen kamen vom Anbieter — und dann wuchsen sie

Zwei Fehlerbilder mit einer Wurzel. Entweder stammten die Anforderungen aus der Vorlage des Anbieters — ein Katalog seiner Funktionen, formuliert als Ihre Bedürfnisse —, oder sie wurden nie aufgeschrieben und tauchen im sechsten Monat als «aber das brauchen wir doch offensichtlich» auf. Mitten im Projekt entdeckter Zusatzumfang ist die meistgenannte Ursache von Budgetüberschreitungen. Ein zwanzigseitiges Pflichtenheft, geschrieben vor der ersten Demo, ist die günstigste Versicherung des ganzen Projekts; wie das geht, steht in Wie wählt man das richtige ERP?

3. Die Daten sollten «später» bereinigt werden

Jedes Projekt entdeckt seine Daten beim ersten Migrationstest, und jedes unterschätzt, was es findet: doppelte Kunden, Artikelnummern in vier Formaten, Preise, die in jemandes Kopf leben, die 2019 zweckentfremdeten Felder. Die Bereinigung wird «dem Fachbereich» zugeteilt, der damit beschäftigt ist, das Geschäft zu führen, und verschoben, bis sie mit dem Go-live kollidiert. Dann beginnt das neue System sein Leben mit den Fehlern des alten — und anders als dem alten vertrauen ihm alle.

4. Der Standard wurde an alte Gewohnheiten angebogen

Der Instinkt will, dass das neue System genau das tut, was das alte tat, plus die Korrekturen. Jede Individualanpassung wird genehmigt, um einen Streit zu vermeiden, jede ist klein, und zusammen sind sie das Budget — und das Update-Problem des nächsten Jahrzehnts. Lidl ist der Extremfall; der Normalfall ist ein mittleres Unternehmen, das 40 Prozent seiner Einführung damit verbracht hat, um den Standard herumzuprogrammieren, und heute auf einer Version von 2021 festsitzt, weil die Anpassungen brechen würden.

5. Die Leute, die täglich damit arbeiten, sassen nicht am Tisch

Umfragen nennen das Change Management seit zwanzig Jahren als Grund Nummer eins für das Scheitern von ERP-Projekten, und das hat sich nicht geändert, weil sich der zugrunde liegende Fehler nicht geändert hat: Das Projekt wird von Geschäftsleitung und IT geführt, und die Leute, die acht Stunden am Tag im System verbringen werden, begegnen ihm in der Schulung, zwei Wochen vor dem Go-live. Niemand hat sie gefragt, wo das System schnell sein muss, welche Ausnahmen es gibt oder was sie tun würden, wenn es nicht passt. Also tun sie, was Menschen tun — sie umgehen es, und die Schatten-Tabellen kehren zurück.

6. Entscheide wurden ausgehungert, und die Projektleitung hatte einen zweiten Job

Projekte stocken weit häufiger auf Kundenseite als auf Anbieterseite. Ein Steuerungsausschuss, der monatlich tagt, macht aus einem Viermonatsprojekt ein Achtmonatsprojekt; eine Projektleitung, die den Job zusätzlich zum eigentlichen hat, beantwortet Fragen am Freitag. Derweil verrechnen die Berater, das Team wartet, und der Schwung des Kick-offs verpufft. Jedes Projekt braucht eine verantwortliche Person mit der Zeit und der Befugnis, innert Tagen zu entscheiden — und die meisten KMU-Projekte haben sie nicht, weil die Person, die es könnte, die Geschäftsführerin ist, und die ist beschäftigt.

7. Das Go-live war ein Datum, kein Zustand

Das Datum wurde im dritten Monat im Unternehmen angekündigt. Im neunten dient der Plan dem Datum: Tests werden komprimiert, Schulungen gekürzt, der Parallelbetrieb gestrichen, die Hochsaison ignoriert. Ein Go-live sollte eine Reihe von Bedingungen sein — diese Tests bestanden, diese Daten abgestimmt, diese Leute geschult, diese Rückfalllösung bereit —, und wenn die Bedingungen nicht erfüllt sind, verschiebt sich das Datum. Jedes Unternehmen im vorigen Abschnitt ist an einem Datum live gegangen.

Anatomie eines scheiternden Projekts

Legt man die sieben Ursachen auf einen Kalender, ergibt sich dieselbe Geschichte, in fast jedem Unternehmen, das sie erzählt. Wenn Sie gerade in einem Projekt stecken: Suchen Sie Ihren Monat.

Die letzte Zeile ist die wichtige. Die meisten gescheiterten ERP-Projekte werden nie als gescheitert bezeichnet. Sie gehen live, werden zum Erfolg erklärt, und das Unternehmen bezahlt das nächste Jahrzehnt für ein System, das es umgeht. So sehen «70 Prozent erreichen ihre Ziele nicht vollständig» von innen aus.

Frühwarnzeichen

Jede Ursache oben ist Monate sichtbar, bevor sie Schaden anrichtet. Das sind die Zeichen — und jedes hat eine Phase, in der es sich noch günstig beheben lässt.

Was die Überlebenden anders machten

Die Unternehmen, deren Projekte funktioniert haben, hatten weder bessere Software noch mehr Geld. Ihre Projekte sind langweilig zu beschreiben, weil sie eine Handvoll unspektakulärer Dinge in der richtigen Reihenfolge getan und sich geweigert haben, sie unter Druck zu überspringen.

Nichts davon ist geheim. Es steht in jeder Einführungsmethodik, die jeder Anbieter publiziert. Übersprungen wird es, weil jeder Punkt Zeit vor dem Go-live kostet und der Druck in einem ERP-Projekt immer in Richtung Datum zeigt. Die Überlebenden sind die Unternehmen, in denen jemand die Befugnis hatte, diesem Druck zu widerstehen — und sie genutzt hat.

Wessen Scheitern ist es?

Fragen Sie einen Anbieter, warum ERP-Projekte scheitern, und Sie hören die sieben Ursachen oben, alle auf der Kundenseite des Tisches: undefinierte Prozesse, langsame Entscheide, schmutzige Daten, fehlende Nutzer, wachsender Umfang. Fragen Sie einen Kunden, und Sie hören von Beratern, die das Geschäft nicht verstanden haben, einem System, das das Offensichtliche nicht konnte, und einem Preis, der sich verdoppelt hat. Beide beschreiben dasselbe Projekt, und beide haben recht — was Ihnen etwas über das Projekt sagen sollte.

Schauen Sie die sieben Ursachen noch einmal an. Jede einzelne ist ein Fehler bei der Übersetzung: bei der Arbeit, die nötig ist, um ein starres, generisches System an ein konkretes, lebendiges Unternehmen anzupassen — von Hand, über Berater, unter Termindruck. Der Prozess des Kunden muss im Voraus entschieden werden, weil das System sich später nicht mehr biegen lässt. Die Daten müssen vor der Migration perfekt sein, weil das System sie nicht versteht. Die Nutzer müssen geschult werden, weil das System sich nicht an sie anpasst. Jede Abweichung muss programmiert werden, weil der Standard fix ist. Und jeder dieser Schritte kostet Beratungstage — weshalb der Druck in Richtung Datum nie nachlässt.

Die Branche beschreibt das seit vierzig Jahren als Aufgabe des Kunden und als Versagen des Kunden. Ehrlicher wäre: Die Architektur hat das Scheitern wahrscheinlich gemacht und dann für den Versuch kassiert. Die Kundenfehler sind real. Aber es sind Fehler, die ein System, das sich an das Unternehmen anpasst — statt umgekehrt —, weit weniger folgenschwer machen würde. Das ist keine Verteidigung langsamer Entscheide oder schmutziger Daten. Es ist eine Beschreibung davon, warum dieselben Entscheide und dieselben Daten das eine Projekt versenken und dem anderen kaum eine Delle verpassen.

Wie KI die Chancen verändert

Wenn das meiste Scheitern Übersetzung ist, dann scheitert ein System, das weniger Übersetzung braucht, seltener. Das ist das ehrliche Argument für KI-natives ERP, und es lohnt sich, es präzise zu formulieren statt als Slogan.

Drei der sieben Ursachen betreffen direkt die Übersetzung, und sie schrumpfen. Individualisierung ist kein Programmierprojekt mehr, wenn die Menschen, die mit dem System arbeiten, es in normaler Sprache umformen können — ein Feld, einen Ablauf, eine Ansicht — und es nächsten Monat wieder ändern, sodass die Angst, den falschen Prozess zu zementieren, ihre Kraft verliert. Die Datenbereinigung ist kein Dreimonats-Sprint mehr, für den der Fachbereich keine Zeit hat, wenn die Migration von einem System begleitet wird, das versteht, was die alten Daten bedeuten, und beim Rest nachfragt. Und wachsender Umfang ist keine Budgetkatastrophe mehr, wenn die entdeckte Anforderung eine Änderung von einem Nachmittag ist statt ein Change Request zum Tagessatz.

Vier der sieben verschwinden nicht, und es wäre unehrlich, das zu behaupten. Ein Unternehmen muss immer noch entscheiden, wie es arbeiten will. Jemand muss das Projekt immer noch verantworten und innert Tagen entscheiden. Die Leute, die mit dem System arbeiten, müssen immer noch am Tisch sitzen — auch wenn ein System, das sich an sie anpasst, ihre Mitarbeit produktiv macht statt defensiv. Und das Go-live ist immer noch ein Zustand, kein Datum. Was sich ändert, sind die Kosten jedes Fehlers: In einem System, das sich anpasst, ist ein unentschiedener Prozess eine Woche Iteration statt eine sechsstellige Individualanpassung, und eine späte Entdeckung ein Dienstag statt eine Krise.

Häufige Fragen