Die meisten ERP-Implementierungen beginnen mit Konfiguration. Die dauerhaften beginnen mit einem Betriebsmodell.
ERP-Systeme gehören zu den bedeutendsten operativen Investitionen, die ein Unternehmen tätigen kann. Sie bestimmen, wie Prozesse strukturiert sind, wie Daten fließen, wie Teams koordinieren und wie das Management das Unternehmen sieht. Wenn sie funktionieren, schaffen sie ein zuverlässiges operatives Fundament. Wenn sie scheitern, ist das Scheitern teuer und schwer umkehrbar.
Die Mehrheit der ERP-Implementierungen, die hinter den Erwartungen zurückbleiben, teilt ein gemeinsames Merkmal: Sie beginnen mit dem System statt mit dem Betriebsmodell.
Konfigurationsentscheidungen, die am Anfang neutral erscheinen — wie Produkte strukturiert, Rollen zugewiesen oder Genehmigungsketten modelliert werden — sind nicht neutral. Sie schreiben Annahmen über die Funktionsweise des Unternehmens fest. Wenn diese Annahmen nie explizit gemacht werden, werden sie zu unsichtbaren Einschränkungen, die sich mit der Zeit verstärken.
1. Warum ERP-Projekte enttäuschen
Forschungen zu ERP-Projektergebnissen zeigen konsistent hohe Raten von Budget-Überschreitungen, verzögerten Zeitplänen und Unzufriedenheit nach der Implementierung. Die am häufigsten genannten Ursachen sind nicht technischer Natur. Sie sind organisatorisch: unklare Anforderungen, schlechte Prozessdefinition, unzureichendes Change-Management und nicht aufeinander abgestimmte Erwartungen.
Was diese Ursachen gemeinsam haben: Sie sind alle verkleidete Architekturprobleme. Unklare Anforderungen spiegeln ein Betriebsmodell wider, das nicht explizit gemacht wurde.
2. Die Konfigurationsfalle
ERP-Systeme wie Odoo sind hochgradig konfigurierbar. Das ist einer ihrer wesentlichen Vorteile. Es ist auch eine der häufigsten Quellen von Implementierungsversagen.
Konfigurationsflexibilität bedeutet, dass nahezu jede Organisationsstruktur im System abgebildet werden kann. Aber es bedeutet auch, dass schlechte Strukturen, schlecht definierte Prozesse und ungelöste organisatorische Unklarheiten gleichermaßen abgebildet werden können.
Sobald diese in der Konfiguration eingebettet sind, werden sie zur Baseline. Teams bauen darauf auf. Berichte hängen davon ab. Die Architektur verhärtet sich — aber es ist die falsche Architektur.
3. Datenmodelldisziplin
Das Datenmodell ist dort, wo Architekturentscheidungen dauerhaft werden. Wie Produkte kategorisiert, Kunden segmentiert, Kostenstellen strukturiert und Bestände verfolgt werden — diese Entscheidungen werden nach dem Go-live selten überarbeitet.
Dennoch behandeln die meisten ERP-Projekte das Datenmodell als Konfigurationsaufgabe und nicht als architektonische. Das Ergebnis ist ein System, das Berichte erstellen kann, aber nicht die Fragen beantwortet, die die Unternehmensführung tatsächlich stellen muss, weil die Daten nie für diese Fragen strukturiert wurden.
4. Workflow-Design vor Implementierung
Jeder ERP-Workflow schreibt eine Prozessannahme fest. Einkaufsgenehmigungsworkflows setzen eine Autorisierungsstruktur voraus. Produktions-Workflows setzen ein Produktionsmodell voraus. Kunden-Onboarding-Workflows setzen einen Verkaufsprozess voraus.
Wenn diese Prozessannahmen nicht explizit sind, bevor die Implementierung beginnt, werden sie während der Konfiguration aufgelöst — von wem auch immer das System konfiguriert. Diese Entscheidungen werden nicht dokumentiert, nicht überprüft. Sie werden einfach zu der Funktionsweise des Systems.
Workflow-Design ist Betriebsmodelldesign. Es gehört vor die erste Systemberührung.
5. Die Architekturvoraussetzung
Was ein ERP-System vor der Implementierung benötigt, ist eine Architektur: eine klare Definition des Betriebsmodells, das das System unterstützen soll.
Dazu gehören: eine dokumentierte Rollenstruktur, explizite Prozessgrenzen, ein überprüftes Datenmodell, gesteuerte Zugriffsrichtlinien und eine klare Menge von Berichtsanforderungen.
All das erfordert keine teuren Beratungsaufträge oder langwierige Designphasen. Es erfordert, die Architektur als Voraussetzung zu behandeln und nicht als Ergebnis der Implementierung selbst.
Ein ERP-System kann nur so gut strukturiert sein wie das Betriebsmodell, dem es dienen soll.
Fazit
ERP-Systeme schaffen keine Struktur. Sie spiegeln die Struktur wider, die zum Zeitpunkt der Implementierung im Betriebsmodell vorhanden ist. Wenn diese Struktur undefiniert ist, schreibt das ERP die Ambiguität fest und skaliert sie über jedes Team, das das System nutzt.
Architektur vor Implementierung ist keine Projektphase. Es ist die Bedingung, die bestimmt, ob die Implementierung ein zuverlässiges Betriebssystem oder eine teure Quelle operativer Schulden produziert.
