Globale ERP-Programme im Spannungsfeld von Strategie, Governance und Kultur

Internationale ERP-Programme verändern, wie ein Unternehmen über Bereiche, Länder und Funktionen hinweg gesteuert wird. Für Programmverantwortliche bedeutet das, Geschäftsstrategie, Zielbild und Systemlandschaft so zusammenzuführen, dass ein globales Template Skalierbarkeit und Transparenz ermöglicht und zugleich sinnvolle Spielräume für Länder und Einheiten offenlässt. Teil 1 zeigt, warum ERP-Initiativen in der Praxis als strategische Geschäftsprogramme geführt werden müssen und nicht als „IT-Projekt“. Das merkt man spätestens dann, wenn die ersten Länder mit echten Zielkonflikten aufschlagen: Standard vs. lokale Besonderheit, Tempo vs. Qualität, Kosten vs. Nutzen. Er ordnet das Zielbild über WHY-HOW-WHAT, Strategie-Pyramide und Global-Template-Logik ein, beschreibt Führungs- und Priorisierungsmechaniken über D/R/I-Governance, Portfolio-Entscheidungen und Decision Logs und macht die organisatorische Realität über Reifegrad, Kultur und Bias-Checks sichtbar. Damit schafft Teil 1 den Bezugsrahmen für die operative Ausgestaltung in Teil 2 (Anforderungs- und Governance-Mechanik, Betriebsmodell, Partner-/Lizenz-/TCO-Steuerung sowie Change und digitale Arbeitsräume).

Internationale ERP-Programme sind komplexe Veränderungsvorhaben und weit mehr als ein Systemwechsel. Sie greifen tief in Wertschöpfungsketten, Rollenmodelle, Datenhoheiten und Entscheidungswege ein, während das Tagesgeschäft weiterlaufen muss. In vielen Organisationen wirkt eine ERP-Einführung wie ein Umbau im laufenden Betrieb: Kernprozesse und Steuerungslogiken werden parallel verändert, ohne dass Lieferfähigkeit, Fakturierung oder Zahlungsverkehr ausfallen dürfen. Genau deshalb ist die Weichenstellung in der Kommunikation und Steuerung entscheidend: Wird das Vorhaben als IT-Projekt gelesen, wandert Verantwortung einseitig in Richtung IT. Wird es als Geschäftsprogramm verstanden, rückt das zukünftige Betriebsmodell in den Mittelpunkt.

In den ersten Steering-Runden entscheidet sich, ob die Beteiligten über dasselbe sprechen. Deshalb braucht die Programmleitung eine klare Klärung von Begriffen und Scope. Ein Programm ist ein länder- und gesellschaftsübergreifendes, mehrjähriges Veränderungsprogramm mit einem gemeinsamen Zielbild für Prozesse, Daten und Systemlandschaft. Es bündelt mehrere Projekte (Rollouts, Upgrades, Pilotierungen), setzt den strategischen Rahmen aus Zielbild, Architektur und Governance und sorgt dafür, dass Entscheidungen über Länder und Rollouts hinweg konsistent bleiben. Ein Projekt ist dagegen ein zeitlich und inhaltlich abgegrenztes Teilvorhaben innerhalb dieses Rahmens, zum Beispiel ein Landes-Rollout oder ein Modul-Upgrade. Diese Unterscheidung ist wichtig: Sie beeinflusst Erwartungsmanagement, Priorisierung und die Frage, wer politische, fachliche und organisatorische Verantwortung trägt. Sobald beispielsweise Entscheidungen zu Standardisierungsgrad, Datenmodell und Rollout-Frequenz programmweit getroffen werden müssen, gehört das Thema ins Steering Committee und ins Decision Log.

Die strategische Verankerung beginnt nicht auf der Ebene von Tabellen, Belegen oder Systemparametern, sondern auf der Ebene der Unternehmensstrategie. In der Golden-Circle-Logik wird prüfbar, warum die Organisation ihr Betriebsmodell verändert, nach welchen Prinzipien die Transformation gestaltet wird und welche Schwerpunkte daraus abgeleitet werden. Eine Kombination aus WHY-HOW-WHAT und Strategie-Pyramide ist in Bild 1 zusammengefasst.

Das WHY beschreibt das Zielbild: ein globales Betriebsmodell, das skalierbar ist, transparente und vergleichbare Daten liefert, steuerbar bleibt und regulatorisch belastbar ist. Das HOW beschreibt handlungsleitende Prinzipien, etwa den Vorrang eines globalen Templates, ein gemeinsames Datenmodell mit klarer Verantwortlichkeit für Datenqualität, Transparenz als Grundlage für Priorisierung sowie nachvollziehbare Entscheidungswege. Das WHAT übersetzt diese Ambition in konkrete Arbeitspakete und Deliverables wie Template-Design, Master-Data-Governance, Rollout-Wellen, Migrations- und Cutover-Strategien, Enablement sowie ein Betriebsmodell für Run und Change. In der Zielarchitektur ist das ERP als „System of Record“: Es bildet die verbindliche Daten- und Prozesswahrheit für Steuerung, Compliance und Vergleichbarkeit. Ergänzend kann ein „Innovation Layer“ genutzt werden, um nutzernahe Erweiterungen, Automatisierungen und Auswertungen schneller umzusetzen, ohne das globale Template zu destabilisieren.

Aus dieser Verankerung folgt die zentrale Template-Entscheidung: Welche Inhalte sind weltweit verbindlich (Global, ca. 75 %), welche sind zwingend durch Gesetze oder Aufsicht vorgegeben (Regulatorisch, ca. 15 %) und welche werden als bewusst freigegebene lokale Ergänzung neben dem Template betrieben (Lokal, „next-to-Template“, ca. 10 %)? Die Global/Regulatorisch/Lokal-Logik trennt „müssen“ von „wollen“ und „sollen“ und verhindert Schattenprozesse, Workarounds, Excel-Inseln und ein Template, das über Jahre zerfasert. Gleichzeitig zwingt sie dazu, Differenzierung zu begründen: Lokale Ergänzungen sind dann kein reflexartiger Sonderweg, sondern eine nachvollziehbar freigegebene Abweichung mit klarem Business-Mehrwert und klarer Verantwortung. Die Definitionen oder Modelle helfen Diskussionen zu entemotionalisieren. Wenn ein Land beispielsweise etwas „unbedingt“ braucht, hilft kein Bauchgefühl. Dann hilft ein klarer Entscheidungsrahmen: Was ist Kernstandard? Was ist regulatorisch? Was ist wirklich lokal und was wäre nur „nice to have“? Als Regel kann herangezogen werden: Sobald eine Anforderung die globale Daten- und Reporting-Logik berührt oder mehr als eine Landesgesellschaft betrifft, wird sie nicht als lokale Ausnahme entschieden.

Im Alltag trägt dieses Rahmenwerk nur, wenn Business und IT zusammenarbeiten. Die IT verantwortet Architektur, Integrationen, Security und Datenmodelle. Die Business-Seite definiert, welche globalen Fähigkeiten erreicht werden sollen und welche KPIs Nutzen und Fortschritt abbilden. Praktisch wird Alignment, wenn Nutzen-KPIs und Zielkonflikte in einem festen Rhythmus gemeinsam gereviewt werden und eine benannte Business-Rolle die fachliche Ergebnisverantwortung trägt. Fehlt diese Abstimmung, entstehen widersprüchliche Prioritäten, parallel laufende Initiativen und ein uheitliches Zielbild, das sich später in inkonsistenten Prozessvarianten und Reporting-Logiken zeigt.

Schließlich entscheidet eine bewusste Vorbereitungsphase darüber, ob das Programm auf „wackligem Boden“ startet oder mit Klarheit in die Umsetzung geht. Vor Workstreams, Timelines und Go-live-Terminen braucht es abgestimmte Prinzipien, Scope und Nicht-Scope, ein messbares Nutzenbild, eine konsolidierte Prozessanalyse über mehrere Einheiten sowie eine strukturierte Fit/Gap-Betrachtung der Kernprozesse. In Cloud- und SaaS-Szenarien gehört dazu eine TCO-Sicht über mehrere Jahre, inklusive laufender OPEX-Effekte. Diese Vorarbeit ist häufig der erste Baustein, der unter Zeitdruck wegfällt und später als fehlender Unterbau schmerzhaft spürbar wird.

Führung und Priorisierung: Verantwortung statt IT-Delegation

Ein globales ERP-Programm lässt sich nicht durch Delegation an die IT „erledigen“. Sobald Prozesse, Datenhoheiten und Steuerungslogiken verändert werden, ist Führung gefragt: sichtbar, wiederkehrend und entscheidungsfähig. Nicht in PowerPoint, sondern im Steering Committee, wenn ein Land sagt: „Wir brauchen das so, sonst gehen wir nicht live.“ Dann entscheidet sich, ob das Programm führt oder ob das Programm geführt wird. In der Praxis entsteht hier ein Spannungsfeld: Programme sind organisatorisch in der IT verankert, während Business-Verantwortung zwar benannt, aber nicht konsequent gelebt wird. Für die Programmleitung bedeutet das, Business-Ownership einzufordern, ohne das Vorhaben inhaltlich wieder zum IT-Projekt zu machen.

Im Programmalltag zeigt sich Führung selten in Konzeptpapieren, sondern in der Woche dazwischen: wenn Ressourcen knapp werden und Prioritäten kollidieren. Priorisierung wird prüfbar, sobald Zeitbudgets für Process Owner, Key User, Datenbereinigung und Tests verbindlich freigegeben werden. Nicht nebenbei und nicht nur in Pilotphasen. Ebenso wichtig ist die Portfolioperspektive: Ein ERP-Programm konkurriert mit anderen Initiativen um dieselben Mitarbeitenden. Ohne explizite Portfolio-Entscheidungen wandern Konflikte still in die Linie und tauchen später als Verzug, Qualitätseinbußen oder wiederholte Go-live-Verschiebungen wieder auf. Entscheidungsfähigkeit wird sichtbar, wenn Zielkonflikte strukturiert gelöst werden: Welche Themen werden jetzt umgesetzt, welche später, welche bewusst nicht. Und welche Konsequenz hat das für Timeline, Scope und Nutzenbild?