Ein Produktionsstandort arbeitet mit SAP als führendem ERP, ein anderer mit einer historisch gewachsenen Instanz desselben Systems, während ein drittes Werk Aufträge, Bestände und Qualitätsdaten über lokale Zusatzlösungen steuert. Auf Managementebene wirkt das wie ein IT-Thema. Operativ entstehen daraus verspätete Monatsabschlüsse, unklare Bestände, manuelle Abstimmungen und ein hoher Aufwand bei jedem Rollout. Diese Fallstudie zur ERP Harmonisierung zeigt, warum die Konsolidierung nicht am Software-Template entscheidet, sondern an Prozessen, Daten, Governance und einer kontrollierten Umsetzung im laufenden Betrieb.
Die Ausgangslage: Drei Werke, drei Realitäten
Das betrachtete Unternehmen ist ein international tätiger Industriekonzern mit mehreren Produktionswerken und zentralen Funktionen für Finance, Supply Chain und Einkauf. Über Jahre hatten einzelne Standorte ihre ERP-Prozesse an lokale Anforderungen angepasst. Das war kurzfristig nachvollziehbar: Ein Werk benötigte spezielle Fertigungslogik, ein anderes eigene Lagerprozesse, ein drittes lokale Berichtsvorgaben.
Mit zunehmender Internationalisierung kippte der Nutzen dieser Sonderwege. Materialstammdaten waren unterschiedlich strukturiert, Kunden- und Lieferantendaten mehrfach vorhanden und Kennzahlen nur mit erheblichem manuellen Aufwand vergleichbar. Für die zentrale Planung bedeutete dies: Zahlen waren verfügbar, aber nicht verlässlich genug für schnelle Entscheidungen.
Der konkrete Auslöser für die Harmonisierung war kein reines Modernisierungsprogramm. Ein bestehendes ERP-System am ersten Standort erreichte das Ende seines Wartungsfensters. Gleichzeitig sollte ein neues Werk angebunden werden. Die Geschäftsführung wollte vermeiden, dass sich eine weitere lokale Variante etabliert und die Komplexität nochmals steigt.
Das Ziel war daher klar: ein gemeinsames Prozess- und Datenmodell für die Kernbereiche Finance, Procurement, Planung, Lager und Produktion. Lokale Abweichungen sollten nur dort bestehen bleiben, wo rechtliche Vorgaben oder nachweisbare betriebliche Anforderungen dies verlangten.
Warum ERP-Harmonisierung häufig ins Stocken gerät
In der Praxis scheitern Programme selten daran, dass ein Projektteam kein Zielbild formulieren kann. Kritisch wird die Übersetzung in belastbare Entscheidungen. Fachbereiche wollen ihre bewährten Abläufe absichern. Die IT will technische Altlasten reduzieren. Die Produktion akzeptiert Änderungen nur, wenn Lieferfähigkeit, Rückverfolgbarkeit und Schichtbetrieb geschützt bleiben.
Der typische Konflikt lautet: Das zentrale Template verspricht Standardisierung, deckt aber nicht jeden Sonderfall eines Werks ab. Werden Ausnahmen zu schnell akzeptiert, entsteht ein Template mit zahlreichen Varianten. Werden sie pauschal abgelehnt, drohen Akzeptanzprobleme und Workarounds außerhalb des Systems.
Im betrachteten Programm fehlte zunächst genau diese Entscheidungslogik. Workshops dokumentierten mehr als 180 Anforderungen, aber es gab keine einheitliche Bewertung: Was ist eine gesetzliche Pflicht? Was schützt tatsächlich die Produktionsleistung? Was ist lediglich eine historisch gewachsene Präferenz? Ohne diese Einordnung wurde jede Anforderung wie ein gleichwertiger Change Request behandelt.
Hinzu kam ein Governance-Problem. Die zentrale IT koordinierte das Programm, besaß aber kein klares Mandat, standortübergreifende Prozessentscheidungen durchzusetzen. Entscheidungen wurden in Arbeitsgruppen vertagt und erreichten das Steering Committee erst, wenn Zeitplan oder Budget bereits unter Druck standen.
Fallstudie zur ERP-Harmonisierung: Der Projektansatz
Das Programm wurde nicht mit einer zusätzlichen Workshop-Serie stabilisiert, sondern mit einer klaren Arbeitsstruktur. Zuerst musste Transparenz entstehen: über den tatsächlichen Prozessumfang, über technische Abhängigkeiten und über die Folgen jeder lokalen Abweichung.
1. Prozesse und Anforderungen sauber trennen
Das Projektteam führte für jeden Prozessbereich einen Fit-to-Standard-Abgleich durch. Entscheidend war nicht die Frage, ob ein Standort seinen bisherigen Ablauf bevorzugt. Entscheidend war, ob der Standardprozess den geschäftlichen Zweck erfüllt.
Jede Abweichung wurde in drei Kategorien überführt: verpflichtend, geschäftskritisch oder verzichtbar. Verpflichtende Abweichungen bezogen sich etwa auf lokale steuerliche Vorgaben oder regulatorische Dokumentationspflichten. Geschäftskritische Anforderungen mussten mit messbaren Auswirkungen auf Produktion, Qualität, Kundenversorgung oder Kosten belegt werden. Verzichtbare Anforderungen wurden nicht direkt gestrichen, aber in einen späteren Optimierungs-Backlog verschoben.
Diese Trennung reduzierte die Zahl der offenen Designentscheidungen deutlich. Gleichzeitig wurde sichtbar, welche Fachbereiche tatsächlich eine belastbare Begründung liefern konnten und wo bislang Gewohnheit mit Notwendigkeit verwechselt worden war.
2. Stammdaten als eigenes Teilprogramm behandeln
Die technische Migration war planbar. Die Datenqualität war es zunächst nicht. Materialnummern enthielten Dubletten, Mengeneinheiten wurden unterschiedlich genutzt und Lieferanten waren mehrfach mit abweichenden Schreibweisen angelegt. Eine Übernahme ohne Bereinigung hätte dieselben Fehler in das Zielsystem übertragen.
Daher wurde ein eigenes Data-Governance-Teilprogramm eingerichtet. Für Material, Kunde, Lieferant, Stückliste und Arbeitsplan wurden fachliche Datenverantwortliche benannt. Sie entschieden nicht nur über die Bereinigung bestehender Daten, sondern auch über künftige Anlage- und Freigaberegeln.
Das war ein relevanter Unterschied zur üblichen Migrationslogik. Daten wurden nicht als technische Lieferposition kurz vor dem Cutover behandelt, sondern als betrieblicher Vermögenswert. Erst nachdem Verantwortlichkeiten, Qualitätsregeln und Freigabeprozesse definiert waren, konnte die Bereinigung verlässlich skaliert werden.
3. Schnittstellen vom Rand in den Kern holen
Besonders im Produktionsumfeld ist ein ERP nicht isoliert. Es tauscht Daten mit MES, Lagertechnik, Qualitätsmanagement, Planungstools, EDI-Plattformen und lokalen Reporting-Lösungen aus. Im Ausgangszustand existierten zahlreiche punktuelle Schnittstellen, teilweise ohne aktuelle Dokumentation oder eindeutigen Owner.
Das Projekt erstellte deshalb ein Schnittstellenregister mit Datenobjekt, Richtung, Frequenz, fachlichem Besitzer, technischem Betreiber und Kritikalität. Nicht jede Schnittstelle wurde automatisch migriert. Manche Berichte konnten durch Standardfunktionen ersetzt werden, andere lokale Tools wurden gezielt abgelöst.
Der Trade-off war bewusst: Eine vollständige Bereinigung vor dem Go-live verlängert die Vorbereitungsphase, senkt aber das Risiko instabiler Abläufe nach dem Start. In kritischen Werken ist diese Zeit meist besser investiert als ein hektischer Parallelbetrieb mit manuellen Ersatzprozessen.
4. Governance entlang echter Entscheidungen aufbauen
Das PMO etablierte ein verbindliches Entscheidungsmodell. Prozessentscheidungen lagen bei benannten Global Process Ownern. Technische Architekturentscheidungen beim Enterprise Architecture Board. Budget-, Termin- und Risikofragen wurden im monatlichen Steering Committee entschieden.
Wichtig war die Eskalationslogik. Offene Punkte erhielten einen Owner, ein Entscheidungsdatum, eine Auswirkungsbewertung und eine dokumentierte Empfehlung. So wurde aus einer langen Liste offener Themen ein steuerbares Entscheidungsportfolio. Das Steering Committee musste nicht mehr in Detaildiskussionen einsteigen, sondern konnte Zielkonflikte mit klaren Konsequenzen entscheiden.
Ein externes Projektmanagement kann in dieser Phase besonders wirksam sein. Es schafft Transparenz zwischen Fachbereich, IT, Implementierungspartner und Standortleitung, ohne selbst Teil lokaler Interessenkonflikte zu sein. Entscheidend ist dabei nicht zusätzliche Administration, sondern die Fähigkeit, Risiken früh sichtbar zu machen und Entscheidungen konsequent nachzuhalten.
Die Umsetzung im laufenden Werkbetrieb
Ein Big Bang für alle Standorte wurde verworfen. Zwar hätte ein gleichzeitiger Start die Programmdauer verkürzen können, das Risiko für Produktion und Lieferkette war jedoch unverhältnismäßig hoch. Das Unternehmen entschied sich für einen Pilotstandort mit mittlerer Komplexität, gefolgt von zwei Rollout-Wellen.
Der Pilot war nicht das einfachste Werk. Er musste ausreichend repräsentativ sein: diskrete Fertigung, mehrere Lagerbereiche, relevante MES-Anbindung und internationale Beschaffung. Nur so ließ sich prüfen, ob Template, Datenmodell, Schnittstellen und Supportmodell auch unter realen Bedingungen tragfähig waren.
Vor dem Go-live wurden End-to-End-Tests nicht nur mit dem Projektteam, sondern mit Key Usern aus Schichtbetrieb, Disposition, Einkauf, Finance und Qualität durchgeführt. Getestet wurden konkrete Geschäftsvorfälle: von der Bedarfsplanung über Fertigungsauftrag und Wareneingang bis zur Rechnung und dem Monatsabschluss. Einzelne Transaktionen erfolgreich auszuführen, hätte nicht gereicht.
Für die Hypercare-Phase galt ein klares Führungsmodell. Ein tägliches Lagebild zeigte Ticketvolumen, kritische Prozessunterbrechungen, Datenfehler, Schnittstellenstatus und Auswirkungen auf den Betrieb. Probleme wurden nach Business Impact priorisiert. Ein fehlender Druckauftrag in einer Testumgebung war nicht gleich kritisch wie eine blockierte Materialbuchung an einer Produktionslinie.
Messbare Wirkung und verbleibende Aufgaben
Nach dem Pilot konnten die ersten beiden Standorte auf ein gemeinsames Template überführt werden. Die Zahl lokaler Schnittstellen sank, Reporting wurde vergleichbarer und der Aufwand für standortübergreifende Abstimmungen ging spürbar zurück. Besonders relevant war jedoch die neue Transparenz: Verantwortliche konnten Bestände, Auftragsstatus und Prozessabweichungen auf einer konsistenten Datenbasis bewerten.
Nicht alle Sonderfälle verschwanden. Das sollte auch nicht das Ziel sein. Einige lokale Anforderungen blieben aus regulatorischen Gründen bestehen, andere wegen spezieller Produktionsabläufe. Der Unterschied: Diese Abweichungen waren dokumentiert, entschieden und mit einem klaren Owner versehen. Sie waren keine unkontrollierten Nebenlösungen mehr.
Die wichtigste Erkenntnis aus dieser ERP-Harmonisierung ist deshalb operativ: Ein Template schafft noch keine Standardisierung. Standardisierung entsteht erst, wenn Entscheidungen verbindlich getroffen, Daten aktiv verantwortet und Schnittstellen als geschäftskritische Abhängigkeiten geführt werden.
Unternehmen sollten vor dem nächsten Rollout nicht zuerst fragen, ob das Zielsystem technisch bereit ist. Die bessere Frage lautet: Sind Prozessowner, Datenverantwortliche und Entscheider bereit, lokale Komplexität kontrolliert zu reduzieren? Dort entscheidet sich, ob aus einem ERP-Projekt eine tragfähige Transformation wird.