IBP-Rollout, Monat 18: was wir falsch gemacht haben

Der Go-live fand an einem Dienstag im Oktober statt. Der Programmdirektor schickte eine E-Mail an das Steering Committee. Grünes Dashboard. Alle Meilensteine erreicht. Das System war in sechs Märkten live, deckte 78 Prozent des Umsatzes ab, mit 14 Monaten geladener Historiendaten und der nächtlich laufenden statistischen Forecasting-Engine.

Bis zum folgenden März waren drei der sechs Märkte dazu zurückgekehrt, parallel zum System Excel-Dateien zu pflegen. Die Demand Plannerin im größten Markt hatte still und heimlich ihre gesamte Planungs-Arbeitsmappe neu aufgebaut und exportierte jeden Morgen aus dem System dorthin. Der S&OP-Prozess, den das IBP-Tool ermöglichen sollte, lief auf ungefähr demselben Reifegrad wie vor der 4,2-Millionen-Dollar-Implementierung.

Dies ist ein Post-Mortem. Namen wurden geändert. Das Muster ist nicht ungewöhnlich.

---

Was IBP liefern soll

Integrated Business Planning ist die weiterentwickelte Form des S&OP – dieselbe funktionsübergreifende Abstimmungslogik, erweitert auf den vollständigen Planungshorizont (typischerweise 24–36 Monate), vollständig integriert mit der Finanzplanung, und ermöglicht durch eine einzige Planungsplattform statt des Excel-und-ERP-Flickenteppichs, mit dem die meisten Unternehmen arbeiten.

Die Anbieter – SAP IBP, o9 Solutions, Kinaxis, OMP, Anaplan – versprechen Varianten desselben Ergebnisses: eine Version der Wahrheit, Szenarioplanungsfähigkeit, Echtzeit-Abgleich von Angebot und Nachfrage und die Beseitigung des manuellen Abstimmungsaufwands, der die Produktivität in den meisten Planungsteams zunichtemacht.

Der Gartner Market Guide for Supply Chain Planning Solutions (2023) schätzt, dass Unternehmen mit ausgereifter IBP-Fähigkeit Bestandsreduktionen von 15–20 Prozent, eine Verbesserung der Forecast-Genauigkeit um 10–15 Prozent und eine Reduktion des Planungszyklus um 20–30 Prozent erzielen. Das sind reale Zahlen aus realen Implementierungen. Es sind auch die Zahlen aus dem obersten Quartil der Implementierungen. Die mittlere Geschichte sieht anders aus.

---

Was die Forschung über das Scheitern von IBP-Implementierungen sagt

Der 2023 ERP/Planning Report von Panorama Consulting, der 271 Implementierungen umfasste, ergab, dass 58 Prozent der Supply-Chain-Planungsimplementierungen ihr ursprüngliches Budget überschritten, mit einer durchschnittlichen Kostenüberschreitung von 24 Prozent. Die durchschnittliche Zeitplanüberschreitung betrug 33 Prozent. Bedeutsamer noch: nur 41 Prozent der Befragten gaben an, dass ihre Implementierung innerhalb von drei Jahren nach Go-live den erwarteten geschäftlichen Nutzen lieferte.

Eine Gartner-Studie aus 2022 ergab, dass die Hauptursache für das Scheitern von Supply-Chain-Planungsimplementierungen das organisatorische Change Management war, genannt von 67 Prozent der Befragten – noch vor Technologieproblemen (31 Prozent), Datenqualität (48 Prozent) und Lücken im Prozessdesign (44 Prozent). Bemerkenswert: Datenqualität wurde von fast der Hälfte der Befragten genannt, rangiert aber dennoch unter Change Management.

Die Analyse der Boston Consulting Group von 2023 zu digitalen Supply-Chain-Transformationen ergab, dass 70 Prozent der digitalen Supply-Chain-Transformationen ihre erklärten Ziele nicht erreichten – eine Zahl, die mit der breiteren Misserfolgsrate digitaler Transformationen übereinstimmt, die McKinsey branchenübergreifend auf 70 Prozent schätzt.

Was die aggregierten Statistiken nicht erfassen, ist die spezifische Textur davon, wie IBP-Implementierungen scheitern. Das System funktioniert. Die Daten laden. Die statistischen Modelle laufen. Das Scheitern liegt in der Adoption – und die Adoptionsfehler folgen einem konsistenten Muster.

---

Monat 1–3: die Flitterwochen

Die ersten drei Monate nach Go-live sind wirklich produktiv. Das Planungsteam wurde intensiv geschult. Die Berater sind noch vor Ort. Das Steering Committee ist aufmerksam. Datenqualitätsprobleme, die im alten System bekannt, aber toleriert waren, werden aktiv angegangen, weil das neue System sie sichtbar macht.

Die Forecast-Genauigkeit verbessert sich moderat – typischerweise um 3–5 Prozentpunkte –, weil die neuen statistischen Modelle besser sind als die Excel-basierten, die sie ersetzen, und weil die während der Implementierung durchgeführte Datenbereinigung einen Teil des Rauschens in der Historie entfernt hat.

Das Team lernt das Tool. Jeder Planungszyklus ist langsamer als zuvor, weil der Prozess ungewohnt ist. Das ist erwartet und wird kommuniziert. Die Berater erklären, dass es vor dem Anstieg der Kurve zunächst zu einem Produktivitätsrückgang kommt. Das Steering Committee akzeptiert das. Der Programmdirektor berichtet, dass die Adoptionskennzahlen auf Kurs sind.

---

Monat 4–6: die erste Krise

Etwas geht mit den Daten schief. Es ist immer etwas mit den Daten.

Im hier beschriebenen Fall war es die Promotionshistorie. Das Unternehmen führte umfangreiche Handelsaktionen durch – BOGOF-Angebote, Mengenrabatte, mit Schlüsselkunden abgestimmte Preisaktionen –, und die in das System geladenen historischen Daten kennzeichneten diese Zeiträume nicht systematisch. Der statistische Forecast extrapolierte daher aus einer Historie, die Promotions-Uplifts enthielt, ohne zu wissen, dass es sich um Promotions-Uplifts handelte. Das Ergebnis war ein Baseline-Forecast, der für bestimmte SKUs strukturell zu hoch verzerrt war.

Die Demand Planner wussten das. Sie wussten es seit Jahren. Im alten System korrigierten sie das manuell, mithilfe institutionellen Wissens darüber, welche Zeiträume Promotionen betrafen und ungefähr wie stark die Historie zu diskontieren war. Das neue System verfügte nicht über dieses Wissen. Die Korrekturlogik sollte während der Implementierung gebaut werden. Sie wurde teilweise gebaut – genug, um den UAT zu bestehen –, aber nicht robust genug, um die gesamte Bandbreite der vom Unternehmen genutzten Promotionsmechanik abzudecken.

Die Demand Plannerin in Markt drei, die seit neun Jahren in dieser Rolle war, machte in Woche sechs darauf aufmerksam. Die Antwort des Implementierungsteams war, dass eine Behebung geplant werde. Die Behebung dauerte elf Wochen bis zur vollständigen Umsetzung. Während dieser elf Wochen pflegte sie ihre Excel-Datei weiter.

Sie hörte nie vollständig auf.

---

Monat 7–12: der Abzug der Berater

Das Beraterteam zog sich in Monat acht zurück. Das ist Standard. Der Implementierungsvertrag deckt Go-live und eine Stabilisierungsphase ab. Bis Monat acht wird die Stabilisierung für abgeschlossen erklärt. Die Berater übertragen Wissen an das interne Team, dokumentieren den Prozess und gehen.

Was mit ihnen geht: das institutionelle Wissen darüber, warum bestimmte Designentscheidungen getroffen wurden, die Fähigkeit, Datenprobleme schnell innerhalb der Support-Struktur des Anbieters zu eskalieren, und die Veränderungsenergie, die das Steering Committee engagiert hielt.

Was bleibt: ein internes Team, das das Tool auf Anwenderebene, aber nicht auf Konfigurationsebene versteht, eine Reihe von Prozessdokumenten, die beschreiben, wie der Prozess aussehen soll, statt wie er tatsächlich aussieht, und ein Support-Vertrag des Anbieters, der Fehler behebt, aber nicht Adoption fördert.

Der erste S&OP-Zyklus nach dem Abzug der Berater dauerte drei Tage länger als der vorherige Zyklus. Das Demand-Review-Meeting lief zwei Stunden über den Zeitplan hinaus, weil ein Datenproblem im System nicht im Raum diagnostiziert werden konnte. Das kommerzielle Team, das die langsameren Zykluszeiten aus Rücksicht auf das Programm toleriert hatte, begann offen zu fragen, ob das neue System tatsächlich besser sei als das alte.

---

Monat 13–18: das Problem der parallelen Dateien

Bis Monat dreizehn waren die parallelen Excel-Dateien sichtbar, wenn man wusste, wo man hinschauen musste.

Sie waren nicht geheim. Die Planer versteckten sie nicht. Sie waren praktische Anpassungen an spezifische Lücken im System. Die Demand Plannerin in Markt eins hatte eine Datei für die Verwaltung neuer Produkteinführungen – der NPI-Prozess des Systems war zu langsam für die Geschwindigkeit, mit der der Vertrieb Produkte einführte. Der Planer in Markt vier hatte eine Datei für die Verwaltung kundenspezifischer Forecasts – drei Schlüsselkunden verlangten wöchentliche Forecast-Einreichungen, die nicht auf die Planungsstruktur des Systems passten. Die Planerin in Markt drei hatte ihre Datei zur Korrektur der Promotionshistorie, die nie vollständig abgelöst worden war.

Jede Datei war eine vernünftige Antwort auf eine reale Lücke. Jede Datei war auch ein Bruch in der "einen Version der Wahrheit", die mit der IBP-Implementierung verkauft worden war.

Das Problem verstärkt sich, weil die Dateien nicht isoliert bleiben. Sobald eine Planerin eine parallele Datei hat, der sie für einen Zweck mehr vertraut als dem System, weitet sich die Grenze dieses Vertrauens aus. Sie beginnt, die Systemzahl mit ihrer Datei abzugleichen, bevor sie sich darauf festlegt. Weichen die Zahlen voneinander ab, nutzt sie ihre eigene. Das System wird zum Input ihres Prozesses statt zu dessen Output.

Bis Monat achtzehn konnte der Planungsdirektor dem Steering Committee nicht mehr zuversichtlich versichern, dass die Zahlen im IBP-System die Zahlen waren, mit denen die Märkte tatsächlich planten.

---

Was tatsächlich gescheitert ist

Nicht die Technologie. SAP IBP ist ein leistungsfähiges System. Die Forecasting-Engine funktioniert. Die Szenarioplanungstools funktionieren. Die Finanzintegration funktioniert.

Nicht die Daten. Die Datenqualität wurde durch die Implementierung tatsächlich verbessert – Stammdaten waren sauberer, historische Daten vollständiger, und das Problem der Promotionshistorie wurde, obwohl es drei Monate dauerte, behoben.

Was scheiterte, waren drei Dinge, die die Implementierungsmethodik nicht angemessen adressierte:

Der Prozess wurde für die Organisation entworfen, die man sich erhoffte, nicht für die, die existierte. Der Future-State-Prozess ging davon aus, dass der Vertrieb strukturierte Promotionsvolumeneingaben monatlich liefern würde. In der Praxis lieferte der Vertrieb Promotionsinformationen Deal für Deal, oft zwei Wochen vor der Ausführung, in Formaten, die je nach Markt und Key-Account-Manager variierten. Die Prozessdesign-Lücke zwischen "der Vertrieb liefert monatliche Volumen-Uplifts" und "der Vertrieb ruft das Planungsteam den Donnerstag vor einer Promotion an" wurde nie geschlossen.

Die Anreize änderten sich nicht. Die Demand Planner wurden an der Forecast-Genauigkeit gemessen. Der statistische Forecast des IBP-Systems war ihre Baseline – aber ihr Bonus wurde anhand der Genauigkeit des Konsens-Forecasts berechnet, für dessen Anpassung von der statistischen Baseline sie verantwortlich waren. War die statistische Baseline des Systems falsch (wie im Fall der Promotionshistorie), verbesserte eine korrekte Anpassung die Genauigkeit. Aber die Anpassung kostete Zeit und erforderte, den Override gegenüber dem kommerziellen Team zu verteidigen. Der Weg des geringsten Widerstands war, die Excel-Datei zu pflegen, damit die richtige Zahl zu erzeugen und diese Zahl ins System einzutragen. Das System erfasste das Ergebnis. Die Excel-Datei enthielt die Begründung.

Das Change-Management-Programm endete beim Go-live. Der Change-Management-Workstream in der Implementierung – Kommunikation, Schulung, Stakeholder-Management – war auf die Adoption des Tools ausgerichtet, nicht auf die Adoption des Prozesses. Er maß, ob Nutzer das System bedienen konnten, nicht, ob sie ihm genug vertrauten, um Alternativen aufzugeben. Nach dem Go-live war das Change-Management-Budget aufgebraucht und die Aufmerksamkeit wanderte weiter. Der Widerstand der Organisation gegen den Prozess – der während der Implementierung durch die Programmenergie unterdrückt worden war – trat erneut zutage, sobald diese Energie entzogen wurde.

---

Was eine echte IBP-Transformation erfordert, wofür aber niemand budgetiert

Basierend auf dem Post-Mortem und dem, was ich in anderen Implementierungen gesehen habe:

Jahr 2 ist die eigentliche Implementierung. Das erste Jahr ist Systembereitstellung. Das zweite Jahr ist, in dem der Prozess tatsächlich Fuß fasst – was engagierte interne Ressourcen, anhaltende Aufmerksamkeit der Führung und ein Budget für die Nachbesserungen erfordert, die aus dem realen Einsatz entstehen. Die meisten Implementierungsverträge budgetieren für Jahr 1. Jahr 2 ist ein Nachgedanke.

Ein Prozessarchitekt, der kein Angestellter des Anbieters ist. Die Implementierungsberater der Anbieter sind Experten darin, das Tool innerhalb der Referenzarchitektur des Anbieters einzuführen. Sie haben keinen Anreiz, Ihnen zu sagen, dass der kommerzielle Prozess Ihrer Organisation strukturell mit monatlichen Planungszyklen unvereinbar ist. Dieses Urteil erfordert jemanden, der Ihren Geschäftsergebnissen Rechenschaft schuldet, nicht dem Implementierungsprojekt.

Anreizabstimmung vor der Prozessneugestaltung. Wenn die Bonusstruktur des kommerziellen Teams den Umsatz im laufenden Jahr belohnt, ohne die Forecast-Genauigkeit zu berücksichtigen, wird kein IBP-Prozess ehrliche Nachfragesignale erzeugen. Der Prozess ist dem Anreiz nachgelagert. Den Prozess zu korrigieren, ohne den Anreiz zu korrigieren, erzeugt korrekt aussehende Zahlen, die nicht die kommerzielle Realität widerspiegeln.

Eine ehrliche Bewertung der parallelen Dateien. In Monat achtzehn war die richtige Antwort auf das Problem der parallelen Dateien nicht, den Planern vorzuschreiben, sie nicht mehr zu nutzen. Es war, zu verstehen, warum jede Datei existierte, die Lücken zu beheben, die sie verursacht hatten, und das Vertrauen zu gewinnen, das die Planer bereit machen würde, sie aufzugeben. Wir haben das nicht schnell genug getan.

---

Die Zahl, auf die es ankommt

In den achtzehn Monaten vom Go-live bis zu dem Zeitpunkt, an dem dieses Post-Mortem in Auftrag gegeben wurde, hatte die IBP-Implementierung die ursprüngliche Implementierungsgebühr von 4,2 Millionen Dollar gekostet, plus rund 1,1 Millionen Dollar für Stabilisierung und Nachbesserungen, plus geschätzte 2.400 Personenstunden interner Planungszeit, die für die Bewältigung der Lücke zwischen dem System und den parallelen Dateien aufgewendet wurden.

Die Forecast-Genauigkeit, die Schlüsselkennzahl, hatte sich gegenüber der Baseline um 4 Prozentpunkte verbessert. Der Bestand hatte sich in zwei Märkten um 8 Prozent reduziert und war in einem Markt um 3 Prozent gestiegen, in dem das Problem der Promotionshistorie vor der Behebung zu Überbestellungen geführt hatte. Die Finanzintegration funktionierte in vier von sechs Märkten sauber.

Der Programmdirektor nannte das einen Teilerfolg. Er hatte wahrscheinlich recht. Es war auch nicht das, was versprochen worden war, nicht das, was gekauft worden war, und nicht das, was die 5,3 Millionen Dollar Gesamtkosten rechtfertigten.

Die Lehre daraus ist nicht, dass IBP nicht funktioniert. Die Lehre ist, dass der Implementierungsvertrag die Technologie und den Go-live bepreist. Die Transformation wird separat bepreist – in Führungszeit, internen Ressourcen, Prozessneugestaltung und Anreizanpassung – und dieser Preis wird selten von vornherein genannt.

---

Quellen

• Panorama Consulting Group. (2023). 2023 ERP Report. Panorama Consulting.
• Gartner. (2023). Market Guide for Supply Chain Planning Solutions. Gartner Research.
• Gartner. (2022). "Top Reasons Supply Chain Planning Implementations Fail." Gartner Research Note.
• Boston Consulting Group. (2023). "Digital Supply Chain Transformation: Why Most Fail and How to Succeed." BCG.
• McKinsey & Company. (2018). "Unlocking success in digital transformations." McKinsey Digital.
• Oliver Wight International. (2023). IBP Maturity Assessment Framework. Oliver Wight.
• ASCM. (2022). Supply Chain Resilience and Digital Readiness Report. ASCM.
• Wallace, T. F. (2004). Sales & Operations Planning: The Executive's Guide. T.F. Wallace & Company.
• Cecere, L. (2022). Supply Chain Metrics That Matter. Supply Chain Insights LLC.
• Lapide, L. (2011). "IBP: Not your father's S&OP." The Journal of Business Forecasting. 30(3).