ERP & SAPERP & SAP

Warum ERP-Projekte selten an Software scheitern

Was ich aus ERP-Einführungen, internationalen Rollouts, Unternehmenswachstum und der Vorbereitung auf SAP S/4HANA gelernt habe.

Kategorie
ERP & SAP
Veröffentlicht
30. Mai 2026
Lesedauer
12 Minuten
  • ERP
  • SAP
  • S/4HANA
Warum ERP-Projekte selten an Software scheitern | Andreas Wöhrmann

Wenn ERP-Projekte scheitern, wird häufig zuerst über Software gesprochen. Die Lösung war zu komplex, das Customizing war falsch, die Migration schwierig, die Datenqualität schlecht, die Schnittstellen problematisch.

All diese Dinge können Herausforderungen sein. Trotzdem habe ich nach vielen Jahren mit ERP-Systemen eine andere Beobachtung gemacht: Die meisten ERP-Projekte scheitern nicht an der Software. Sie scheitern daran, dass Unternehmen hoffen, ein ERP-System würde organisatorische Probleme lösen.

Genau dort beginnt das eigentliche Missverständnis. Denn ERP ist selten ein IT-Projekt. ERP ist Unternehmenssteuerung.

ERP begleitet mich praktisch seit Beginn meiner Laufbahn

Eines der ersten großen Projekte meiner Karriere war die Auswahl und Einführung eines unternehmensweiten ERP-Systems. Damals bestand die IT aus einem sehr kleinen Team, viele Prozesse waren gewachsen, vieles funktionierte über Erfahrung, persönliche Abstimmung und Pragmatismus. Das ERP-System sollte Transparenz schaffen, Struktur bringen, Prozesse vereinheitlichen.

Mit etwas Abstand betrachtet war das System dabei nur ein Teil der Lösung. Die eigentliche Veränderung fand in der Organisation statt. Das war der Moment, in dem ich zum ersten Mal wirklich verstanden habe, was ein ERP-Projekt eigentlich ist. Nicht die Einführung einer Software. Sondern die Entscheidung, wie ein Unternehmen künftig arbeiten will.

Diese Erfahrung hat sich in den Jahren danach, über mehrere Gesellschaften, internationale Rollouts und unterschiedliche ERP-Generationen, immer wieder bestätigt.

ERP macht Probleme sichtbar

Ein weit verbreitetes Missverständnis besteht darin, ERP-Systeme als Problemlöser zu betrachten. In Wirklichkeit machen sie Probleme häufig erst sichtbar.

Plötzlich muss definiert werden: Wer ist für welche Stammdaten verantwortlich? Wie laufen Prozesse tatsächlich ab? Welche Gesellschaft arbeitet wie? Welche Informationen sind verbindlich? Welche Regeln gelten unternehmensweit?

Viele dieser Fragen existieren bereits vor dem ERP-Projekt. Sie werden lediglich nicht gestellt, weil niemand sie stellen muss, solange kein System sie erzwingt. Ein ERP zwingt Organisationen dazu, Antworten zu finden. Und genau deshalb wirken ERP-Projekte oft deutlich größer als ursprünglich geplant. Nicht weil das System komplex ist. Sondern weil die Organisation komplexer ist als angenommen.

Schlechte Prozesse werden durch SAP nicht gut

Diese Erkenntnis habe ich in unterschiedlichen Unternehmen immer wieder gemacht. Ein ineffizienter Prozess bleibt ineffizient, auch wenn er digitalisiert wird. Ein unklarer Verantwortungsbereich bleibt unklar, auch wenn er in SAP abgebildet wird. Eine schlechte Datenqualität bleibt schlechte Datenqualität, auch wenn sie in einem modernen ERP-System gespeichert wird.

ERP-Systeme standardisieren Prozesse. Sie verbessern sie nicht automatisch. Deshalb scheitern viele Projekte nicht an der Technologie; sie scheitern daran, dass bestehende organisatorische Probleme erstmals sichtbar werden, ohne dass die Organisation bereit ist, sie zu lösen.

Gartner betont das in seiner ERP-Forschung regelmäßig: ERP-Modernisierung ist primär eine Frage von Standardisierung, Prozessharmonisierung und Unternehmenssteuerung. Die Technologie ist dabei oft der einfachste Teil.

Die schwierigsten Diskussionen sind selten technisch

Wer noch nie an einem größeren ERP-Projekt beteiligt war, vermutet häufig technische Herausforderungen als Hauptproblem. Meine Erfahrung ist eine andere.

Die schwierigsten Diskussionen drehen sich fast immer um Fragen wie: Welcher Prozess wird künftig Standard? Welche Gesellschaft passt sich an? Welche Ausnahme bleibt bestehen? Wer trägt Verantwortung? Welche lokalen Besonderheiten werden aufgegeben?

Genau dort entstehen die eigentlichen Konflikte. Nicht zwischen SAP-Modulen. Sondern zwischen unterschiedlichen Arbeitsweisen, die über Jahre gewachsen sind und die Menschen mit guten Gründen verteidigen. Das zu moderieren ist eine Führungsaufgabe, keine IT-Aufgabe.

Intercompany-Prozesse zeigen die Wahrheit

Besonders deutlich wird das bei internationalen Unternehmensgruppen. Auf dem Papier wirken viele Prozesse ähnlich. In der Realität unterscheiden sie sich oft erheblich. Jede Gesellschaft hat ihre Historie, eigene Kunden, eigene Anforderungen, eigene Gewohnheiten.

Das wird häufig erst sichtbar, wenn Intercompany-Prozesse harmonisiert werden sollen. Plötzlich entstehen Fragen: Wann gilt ein Auftrag als abgeschlossen? Welche Daten sind führend? Welche Buchungslogik ist verbindlich? Wer trägt Verantwortung für Stammdaten?

Das sind keine SAP-Fragen. Das sind Organisationsfragen. Ich habe bei der Harmonisierung einer SAP-Landschaft über mehrere internationale Standorte genau das erlebt: Man denkt, man diskutiert über Systemkonfiguration, und merkt irgendwann, dass man eigentlich über Machtfragen, Prozesshoheit und Unternehmenskultur diskutiert. Das ist unbequem. Aber es ist die ehrlichste Bestandsaufnahme, die eine Organisation haben kann.

ERP-Konsolidierung ist meist ein Standardisierungsprojekt

Viele Organisationen wachsen über Jahre. Neue Gesellschaften kommen hinzu, Akquisitionen entstehen, Standorte entwickeln eigene Lösungen, Systemlandschaften wachsen. Irgendwann entsteht die Frage: Wie viele unterschiedliche Prozesse können wir uns langfristig leisten?

Ab diesem Punkt wird ERP-Konsolidierung relevant. Nicht weil Systeme vereinheitlicht werden sollen, sondern weil Steuerbarkeit, Transparenz und Skalierbarkeit wichtiger werden als lokale Flexibilität.

Die eigentliche Herausforderung besteht dabei selten in der technischen Migration. Sie besteht darin, sich auf gemeinsame Standards zu einigen. Und das bedeutet, dass jemand entscheiden muss, auch dort, wo verschiedene Einheiten verschiedene Antworten bevorzugen. Das ist der Moment, in dem ERP-Projekte zur Führungsaufgabe werden.

S/4HANA ist oft kein Technologieprojekt

Die Diskussion rund um SAP S/4HANA wird häufig technisch geführt: neue Architektur, neue Benutzeroberflächen, neue Funktionen, neue Datenmodelle. All das ist relevant.

Aus meiner Sicht greift diese Perspektive jedoch zu kurz. Die eigentliche Chance einer S/4-Transformation liegt oft an anderer Stelle. Sie zwingt Unternehmen dazu, grundlegende Fragen zu beantworten: Welche Prozesse wollen wir künftig standardisieren? Welche Individualentwicklungen sind noch sinnvoll? Welche Komplexität erzeugt keinen Mehrwert mehr? Welche Strukturen sind noch zeitgemäß?

SAP selbst beschreibt S/4HANA zunehmend als Business-Transformation und nicht als reine technische Migration, mit besonderem Fokus auf Prozessharmonisierung, Datenqualität und Standardisierung. Das ist kein Marketing. Das ist die zutreffendere Beschreibung dessen, was tatsächlich passiert, wenn Unternehmen diesen Schritt ernsthaft angehen.

McKinsey kommt in seiner Analyse erfolgreicher ERP-Transformationen zu einem ähnlichen Befund: Der Erfolg hängt vor allem an Governance, Prozessen, Organisation und Change Management, deutlich weniger an der Technologie selbst.

Stammdaten entscheiden häufiger über Erfolg als Technologie

Kaum ein Thema wird in ERP-Projekten so unterschätzt wie Stammdaten. Materialstämme, Kunden, Lieferanten, Konten, Organisationseinheiten, Berechtigungen.

Wenn diese Grundlagen nicht sauber gepflegt werden, hilft die beste Software wenig. Das klingt trivial, und trotzdem ist es in jedem größeren ERP-Projekt eines der hartnäckigsten Probleme.

Interessanterweise sind Stammdaten fast nie ein IT-Thema. Die IT stellt die Plattform bereit. Die Qualität entsteht im Unternehmen, in den Fachbereichen, die täglich damit arbeiten und täglich Entscheidungen treffen, die sich in Daten niederschlagen. Wer das nicht von Anfang an als Führungsaufgabe versteht, kämpft am Ende mit Qualitätsproblemen, die kein System lösen kann.

ERP zeigt, wie ein Unternehmen wirklich arbeitet

Vielleicht ist das die wichtigste Erkenntnis überhaupt: Ein ERP-System zeigt nicht, wie ein Unternehmen gerne arbeiten würde. Es zeigt, wie es tatsächlich arbeitet: welche Prozesse existieren, welche Verantwortlichkeiten klar sind, welche Standards gelebt werden, welche Ausnahmen entstanden sind, welche Komplexität historisch gewachsen ist.

Genau deshalb sind ERP-Projekte oft so wertvoll. Nicht weil sie neue Software einführen. Sondern weil sie Transparenz schaffen, manchmal mehr, als mancher Beteiligte ursprünglich wollte.

Die eigentliche Frage

In vielen Projekten wird lange über Software diskutiert: Welches System, welche Funktionen, welche Module, welche Erweiterungen. Diese Fragen sind wichtig. Die entscheidendere Frage lautet jedoch: Wie wollen wir als Organisation künftig arbeiten?

Wenn darauf keine klare Antwort existiert, wird auch das beste ERP-System Schwierigkeiten haben. Wenn die Antwort klar ist, wird Software deutlich einfacher.

Die meisten ERP-Projekte scheitern nicht an SAP. Sie scheitern dort, wo Organisationen versuchen, technologische Lösungen für organisatorische Probleme einzusetzen, ohne die organisatorischen Probleme vorher zu lösen.

Denn ERP ist am Ende nicht primär Technologie. ERP ist Unternehmenssteuerung. Und genau deshalb gehört die Verantwortung dafür nicht nur in die IT. Sondern ins Management.

Quellen

Portrait von Andreas Wöhrmann.

Autor

Andreas Wöhrmann

Andreas Wöhrmann ist IT-Führungskraft mit Schwerpunkt auf IT-Transformation, Governance, Cybersecurity, ERP/SAP und Operational Excellence im industriellen Mittelstand. Er schreibt über IT-Strukturen, die strategisch sinnvoll, operativ belastbar und organisatorisch wirksam sind.

Weiterführende Artikel