SAP-Einführung oder Rollout: Unterschiede und die richtige Wahl

Eine SAP-Einführung baut das System dort auf, wo keines existiert. Ein Rollout nimmt ein SAP-System, das irgendwo im Konzern bereits läuft, und erweitert es auf ein neues Land, eine neue Gesellschaft oder Geschäftseinheit. Die meisten nehmen an, ein Rollout sei nur eine kleinere Einführung. Diese Annahme verursacht in solchen Programmen mehr Nacharbeit als jede technische Entscheidung.

Ich habe einmal zugelassen, dass ein CFO glaubte, ein regionaler SAP-Rollout laufe Plug-and-play. Ich habe die Risiken erklärt, aber nicht darauf bestanden. Wir nutzten ein globales Template, und er nahm an, jeder Standort füge sich ohne großen Aufwand ein. So lief es nicht. Eine Region brauchte zusätzliche steuerliche Behandlung. Eine andere hatte wegen lokaler Gesetze verpflichtende Mitarbeiterdatenfelder. Was nach Copy-and-paste aussah, brauchte echte Anpassung.

Die Wahl verändert also, wie Sie Ressourcen planen, budgetieren und die Arbeit steuern. Liegen Sie falsch, geht das System womöglich trotzdem live, nur nicht so, wie Sie es geplant haben.

Eine Einführung beginnt bei null. Sie definieren den Scope, bilden Prozesse ab, konfigurieren, migrieren Daten und bauen Integrationen. Sie kommt zum Tragen, wenn eine Organisation kein SAP hat oder ein Altsystem komplett ersetzt.

Ein Rollout nutzt ein Design wieder, das bereits funktioniert: Prozesse, Konfiguration, Stammdatenstandards. Die Arbeit ist die Lücke zwischen diesem Template und dem, was der neue Standort braucht. Steuern, gesetzliche Berichterstattung, Währungen, Sprachen, lokale Integrationen und die Menschen, die es nutzen werden.

1. 05Lokale AnwenderSchulung, angepasst an den lokalen Prozess, in der Landessprache
2. 04Lokale IntegrationenBanken, Steuermeldung und Logistiksysteme im neuen Land
3. 03Lokale DatenKunden-, Lieferanten- und Materialdaten, abgebildet auf die globalen Standards
4. 02Lokale AnforderungenSteuern, gesetzliche Berichterstattung und Pflichtfelder. Nur Anforderungen, keine Präferenzen
5. 01Globales TemplateProzesse, Konfiguration und Stammdatenstandards, die bereits funktionieren

So unterscheiden sich beide in der Praxis:

Bereich	SAP-Einführung	SAP-Rollout
Ausgangslage	Kein SAP oder ein Altsystem, das ersetzt wird	SAP läuft bereits in der Zentrale oder in einer anderen Gesellschaft
Design	Neues Design, Fit-to-Standard	Globales Template mit kontrollierten lokalen Abweichungen
Typische Dauer	12 bis 24 Monate, bei großen Konzernen länger	6 bis 12 Monate je Standort
Hauptrisiko	Unbekannte in jedem Arbeitsstrang	Lokalisierung und lokale Bereitschaft
Daten	Vollständiges Laden aus Altsystemen	Lokale Daten, abgebildet auf globale Stammdatenstandards
Tests	Voller Zyklus: Einzeltest, Integration, UAT, Performance	Lokalisierung, lokale Schnittstellen, UAT
Change Management	Vollständiges Programm von null	Vorhandene Materialien, angepasst an die lokalen Teams

Eine Einführung passt, wenn:

1. Die Organisation hat SAP noch nie genutzt.
2. Das aktuelle System versagt und muss als Ganzes ersetzt werden.
3. Eine Fusion, eine Übernahme oder ein neues Betriebsmodell bedeutet, dass das alte Design nicht mehr passt.
4. Eine Branchenlösung kommt erstmals hinzu, etwa SAP for Utilities oder SAP for Public Sector.
5. Kein vorhandenes Template deckt den Scope ab, den Sie brauchen.

Einführungen dauern länger und kosten zu Beginn mehr. Dafür bekommen Sie ein Design, das zu Ihrem Geschäft passt, und ein Team, das jede Entscheidung dahinter versteht. Unternehmen, die die Anforderungen durchhetzen, geben am Ende 30 bis 50 Prozent mehr aus, um später Fehler zu beheben. Ich habe das immer wieder erlebt.

Ein Rollout passt, wenn SAP irgendwo im Konzern bereits gut läuft, die Kernprozesse stabil sind und das Template flexibel genug ist, um lokale Anforderungen aufzunehmen, ohne zu brechen. Wackelt eine dieser drei Bedingungen, reparieren Sie das Template, bevor Sie es irgendwo ausrollen.

Die technische Seite wird meist termingerecht fertig. Die Verzögerungen kommen von den Menschen und von Annahmen, die im neuen Land nicht tragen.

Ein Template, das den lokalen Teams aufgezwungen wird

Was in Nordamerika gut funktionierte, kann in Asien oder im Nahen Osten zu kurz greifen. Steuerstrukturen, Freigabe-Workflows und Regeln für die Dateneingabe unterscheiden sich. Ich habe einmal mit einem Unternehmen gearbeitet, das annahm, sein europäisches Template funktioniere im Nahen Osten. Es führte zu Verzögerungen, Neuentwicklungen und reichlich Spannungen. Die Geschäftsprozesse waren schlicht zu verschieden.

Die Lösung ist, dem neuen Standort einen Business Owner mit Entscheidungsbefugnis zu geben. Wenn Teams der Zentrale Prozesse für Orte festlegen, die sie nicht verstehen, entstehen Designs, die beim ersten Kontakt mit den lokalen Anwendern scheitern.

Lokalisierung, die erst im Test auffällt

Steuerbehandlung, gesetzliche Berichte und Pflichtfelder müssen bestätigt sein, bevor das Design beginnt. Ich habe einmal einen Kunden begleitet, bei dem ein einfacher Unterschied in der Steuerkonfiguration das Go-live um über einen Monat verzögerte. Mit Technik hatte das nichts zu tun. Niemand hatte den lokalen Bedarf früh genug validiert.

Stammdaten, die nicht zusammenpassen

Produktcodes, Kundennummern und Lieferantenklassifikationen müssen den globalen Standards entsprechen. Abweichungen, die nach dem Go-live auffallen, sind teuer zu beheben und zerstören das konsolidierte Reporting. Bilden Sie lokale Daten im Design auf das globale Modell ab, nicht erst im UAT.

Schulungen, die das globale System erklären, nicht das lokale

Rollouts greifen gern auf die Schulungen der ursprünglichen Einführung zurück. Dieses Material erklärt, wie das System in der Zentrale funktioniert. Die lokalen Anpassungen erklärt es nicht. Anwender, die nicht verstehen, warum ihre Version abweicht, bauen sich Umgehungslösungen.

Der Rahmen von oben gilt weiterhin. Das Bereitstellungsmodell des Templates verändert einen Teil der Wirtschaftlichkeit und der Erweiterungsregeln.

Bei RISE with SAP (Private Edition) kommen mit jedem neuen Land Anwender zu einem Abonnement hinzu, das nach Full User Equivalents (FUEs) bepreist ist. Sie erhalten planbare Kosten und weniger Infrastrukturarbeit. Die Kosten laufen aber auch nach dem Go-live weiter, vergleichen Sie die Optionen daher über mehrere Jahre, nicht nur über das erste.

Bei GROW with SAP (Public Edition) prüfen Sie zuerst, ob SAP für das Land eine lokale Version ausliefert. SAP führte Stand Februar 2024 lokale Versionen für 59 Länder und Regionen auf. Für andere Länder können Partner über das SAP-Programm zur Lokalisierung als Self-Service mit dem Configuration Localization Tool eine kundeneigene lokale Version bauen, derzeit über einen Early-Adopter-Weg (SAP Learning). Trifft keines von beiden zu, haben Sie ein Scoping-Problem und keinen Rollout.

Clean Core gilt für jede lokale Abweichung. Die Public Edition akzeptiert Erweiterungen nur über freigegebene Schnittstellen. In der Private Edition ist es eine Governance-Entscheidung, doch jede lokale Modifikation, die Sie zulassen, ist ein weiteres Objekt, das bei jedem Upgrade neu getestet werden muss, multipliziert mit jedem Land. Die Disziplin, auf die ich dränge, ist einfach: Steuergesetze, gesetzliche Berichterstattung und regulatorische Vorgaben rechtfertigen eine Abweichung. Lokale Präferenzen nicht.

Bevor Sie für das nächste Land einen Termin zusagen, brauchen Sie bei jedem dieser Punkte ein Ja. Jeder hat einen Verantwortlichen.

1. Lokaler Business Owner (neues Land): benannt, mit der Befugnis, das lokale Design freizugeben.
2. Steuer- und Rechtsberater: Steuern, gesetzliche Berichterstattung und Pflichtfelder sind dokumentiert, bevor das Design beginnt.
3. Template Owner (Zentrale): Liste der vorgeschlagenen Abweichungen, jede als Anforderung oder Präferenz markiert.
4. Datenverantwortlicher: Lokale Kunden-, Lieferanten- und Materialdaten sind auf die globalen Standards abgebildet.
5. Integrationsverantwortlicher: Lokale Systeme, die angebunden werden müssen, etwa Banken, Steuermeldung oder Logistik, sind identifiziert und im Scope erfasst.
6. Change-Verantwortlicher: Die Schulung ist an den lokalen Prozess angepasst, in der Landessprache, mit lokalen Beispielen.
7. Programmleiter: ein Standort nach dem anderen, mit den Erkenntnissen aus dem letzten Go-live für den nächsten.

Mein Leitfaden zur Scope-Vorlage hilft bei Punkt 3, und der Leitfaden zur Projekt-Charta behandelt, wie man Entscheidungsrechte festhält.

Eine Greenfield-Einführung in Ägypten. Ein regionales Fertigungsunternehmen mit Sitz in Ägypten steckte mit alten, unverbundenen Systemen und viel Handarbeit fest. Lieferkette, Produktionsverfolgung und Finanzberichte sprachen nicht miteinander. Das Unternehmen führte SAP S/4HANA von Grund auf ein und verband Finanzwesen, Einkauf und Produktion in einem System. Es richtete eine automatisierte Lieferkettenplanung ein und schulte vor dem Go-live über 5.000 Mitarbeitende in vier Ländern. Es hat nichts überstürzt. Die Betriebskosten sanken um 25 Prozent, die Prognosefehler um 35 Prozent.

Ein Rollout in 15 Märkten. Ein Handelsunternehmen hatte SAP S/4HANA bereits in der Zentrale im Einsatz und brauchte es in 15 neuen Märkten. Jeder hatte andere Steuerregeln, Währungen und Geschäftspraktiken. Das Unternehmen startete von einem globalen Template, passte es je Standort an, rollte über zwei Jahre in Phasen statt auf einmal aus und baute Schulungen für jede Region auf. Das Ergebnis waren eine schnellere Finanzkonsolidierung, Bestandsverfolgung in Echtzeit über alle Filialen und ein um 20 Prozent genaueres Reporting auf Konzernebene.

Das eine baute etwas auf, das es nicht gab. Das andere erweiterte etwas, das funktionierte. Keines war Plug-and-play. Stehen Sie am Anfang der ersten Art, ist mein Leitfaden dazu, wie man eine SAP-Einführung richtig startet, der richtige Einstieg.

Was ist der Unterschied zwischen SAP-Einführung und SAP-Rollout?

Eine Einführung baut SAP von null auf: Anforderungen, Prozessdesign, Konfiguration, Datenmigration, Integration, Tests und Go-live. Ein Rollout erweitert ein bestehendes SAP-System und sein globales Template auf ein neues Land, eine neue Gesellschaft oder Geschäftseinheit. Die Rollout-Arbeit ist die Lücke zwischen dem Template und dem lokalen Bedarf: Steuern, gesetzliche Berichterstattung, Sprache, lokale Integrationen und Schulung.

Wann sollte ein Unternehmen sich für eine Einführung statt für einen Rollout entscheiden?

Entscheiden Sie sich für eine Einführung, wenn es kein SAP zum Erweitern gibt oder ein Altsystem als Ganzes ersetzt wird. Sie ist auch der bessere Weg, wenn sich das Geschäftsmodell so weit verändert hat, dass das bestehende Design nicht mehr passt, oder wenn kein Template den benötigten Scope abdeckt. Einen Rollout mit dem falschen Template zu erzwingen, erzeugt mehr Nacharbeit als ein sauberes Design.

Wie lange dauert ein SAP-Rollout im Vergleich zu einer Einführung?

Eine Einführung dauert in der Regel 12 bis 24 Monate, bei großen Konzernen länger. Ein Rollout dauert in der Regel 6 bis 12 Monate je Standort, abhängig von Lokalisierung, Integrationen und Daten. Die größte Variable ist, wie gut die lokalen Anforderungen validiert wurden, bevor das Design begann.

Was sind die größten Herausforderungen bei einem SAP-Rollout in mehreren Ländern?

Vier kommen immer wieder vor. Templates, die den lokalen Teams ohne deren Mitsprache aufgezwungen werden. Lokalisierungsanforderungen, die erst während der Tests auffallen. Stammdaten, die nicht den globalen Standards entsprechen. Schulungen, die das globale statt das lokale System erklären. Die meisten sind Probleme von Menschen und Planung, keine technischen.

Ist ein SAP-Rollout immer günstiger als eine vollständige Einführung?

Meistens, weil das Design bereits existiert und sich bewährt hat. Die Ersparnis schrumpft, wenn ein Land komplexe Steuer- oder Gehaltsabrechnungsregeln hat, mehrere lokale Integrationen braucht oder schlechte Daten hat. Unter RISE with SAP läuft das Abonnement für jedes neue Land nach dem Go-live weiter, vergleichen Sie die Kosten daher über mehrere Jahre.

Wie funktioniert ein globales Template bei einem SAP-Rollout?

Das globale Template ist das dokumentierte, konfigurierte SAP-Design für die Standardprozesse des Konzerns. Jeder Rollout startet davon und ergänzt nur die lokalen Änderungen, die wirklich nötig sind. Jede Abweichung erzeugt bei jedem Upgrade eine Pflegeverpflichtung, steuern Sie sie also: Anforderungen wie das Steuerrecht rechtfertigen eine Abweichung, Präferenzen nicht.