Wie viele ERP-Projekte scheitern wirklich?

Eine belastbare Scheiterquote für ERP-Projekte gibt es nicht. Die Zahlen, die in Präsentationen kursieren, reichen von 50 bis über 70 Prozent und stammen aus Erhebungen, die „Scheitern“ jeweils anders oder überhaupt nicht definieren. Belegt sind zwei andere Werte: 65 bis 80 Prozent der großen Technologieprogramme überschreiten Budget oder Zeitplan, und nur 25 bis 35 Prozent erreichen die geplante Wirkung auf Ergebnis und Liquidität. Beide stammen von McKinsey und beschreiben große Technologieprogramme, nicht speziell ERP-Einführungen. Für die eigene Planung sind sie deshalb ein Hinweis, keine Prognose.

Warum es keine belastbare Quote gibt

Das Problem ist nicht die Datenlage, sondern die Definition. Fragen Sie fünf Leute, wann ein ERP-Projekt gescheitert ist, und Sie bekommen fünf Antworten. Ist es gescheitert, wenn es abgebrochen wurde? Wenn es live ging, aber ein halbes Jahr später? Wenn das Budget um vierzig Prozent überschritten wurde, das System aber läuft? Wenn alles im Plan war, das Unternehmen aber keinen der erhofften Effekte sieht?

Je nachdem, welche dieser Linien man zieht, liegt dieselbe Projektlandschaft bei 20 Prozent Fehlschlägen oder bei 70. Genau das erklärt die Spannweite der zitierten Zahlen. Eine Prozentangabe ohne mitgelieferte Definition ist deshalb eine Meinung mit Nachkommastelle, und sie trägt keine Entscheidung.

Dazu kommt ein Auswahleffekt: Über abgebrochene Projekte spricht niemand gern, und veröffentlichte Erfahrungsberichte stammen überwiegend von denen, bei denen es gut ging. Wer die Quote aus öffentlichen Quellen schätzt, schätzt aus einer verzerrten Stichprobe.

Die zwei Zahlen, die belegt sind

65 bis 80 Prozent überschreiten Budget oder Zeitplan. Das ist die am häufigsten zitierte Zahl, und sie wird fast immer falsch wiedergegeben. Sie sagt nicht, dass so viele Projekte scheitern. Sie sagt, dass so viele teurer oder länger werden als geplant. Ein Projekt, das drei Monate länger dauert, ist über dem Plan und trotzdem erfolgreich.

25 bis 35 Prozent erreichen die geplante Wirkung. Das ist die unbequemere Zahl und die, über die zu wenig gesprochen wird. Sie beschreibt nicht den Projektverlauf, sondern das Ergebnis: ob die erhofften Effekte auf Ergebnis und Liquidität tatsächlich eintreten. Hier liegt der eigentliche Verlust, und er wird meist nie gemessen, weil nach dem Go-live niemand mehr nachrechnet.

Beide Werte stammen aus derselben McKinsey-Untersuchung und gelten für große Technologieprogramme, nicht für ERP-Einführungen im Besonderen. Wer sie als „ERP-Zahlen“ zitiert, verengt sie unzulässig. Wir nennen sie trotzdem, weil sie die einzigen mit nachvollziehbarer Herkunft sind, und wir nennen die Einschränkung gleich mit.

Was das für den Mittelstand bedeutet

Die Wirkmechanismen sind dieselben, die Größenordnung ist es nicht. Ein Programm mit dreistelligem Millionenbudget scheitert an Koordination zwischen Dutzenden Teilprojekten. Eine Business-Central-Einführung mit dreihundert Mitarbeitenden scheitert an etwas anderem, und zwar meistens an denselben drei Dingen.

• Prozesse, die erst im Projekt geklärt werden. Was vorher niemand entschieden hat, wird im Projekt entschieden, unter Zeitdruck und von den Falschen.
• Stammdaten, die niemand vorher angesehen hat. Dubletten, uneinheitliche Einheiten und gewachsene Kontenlogik wandern mit und tauchen beim Testen als Überraschung auf.
• Entscheidungen, die zu lange dauern. Nicht die falsche Entscheidung kostet das Projekt, sondern die ausbleibende.

Keiner dieser drei Punkte ist ein Softwareproblem, und alle drei lassen sich vor dem Projektstart bearbeiten. Das ist der Grund, warum wir die Quotenfrage für die weniger nützliche halten.

Die Gründe im Einzelnen: Warum ERP-Projekte scheitern

Die nützlichere Frage als die Quote

Eine Branchenquote sagt Ihnen nichts über Ihr Projekt. Zwei eigene Zahlen tun das sehr wohl, und beide lassen sich in einer Woche erheben.

Erstens die Entscheidungsdauer. Wie viele Tage vergehen bei Ihnen zwischen einer Entscheidungsvorlage und der Freigabe? Liegt der Wert bei Wochen, hat Ihr Projekt ein Steuerungsproblem, und zwar ungeachtet dessen, wie gut der Partner ist.

Zweitens der Zuwachs an Anforderungen. Wie viele Punkte sind seit dem Start dazugekommen, die im ursprünglichen Umfang nicht standen? Ein stetiger Zuwachs ohne gestrichene Gegenposten ist der verlässlichste Frühindikator, den es gibt.

Diese beiden Werte ersetzen jede Quote. Sie beschreiben nicht, was anderen passiert ist, sondern was bei Ihnen gerade passiert.

Die konkreten Anzeichen: Woran erkenne ich, dass mein ERP-Projekt scheitert?

Wenn es Sie bereits getroffen hat: Das ERP-Projekt ist gescheitert. Lässt es sich retten?