Nach dem SAP Go-Live: Betrieb, reale Kosten und versteckte Abhängigkeiten im Griff behalten

Der Go-Live ist geschafft. Das Projekt gilt als erfolgreich. Die Projektleitung atmet durch, das Steering Committee applaudiert, die Berater beginnen mit dem Abbau. Und dann beginnt der Teil, über den im Projekt niemand sprechen wollte.

In nahezu jedem S/4HANA-Projekt konzentrieren sich Aufmerksamkeit, Budget und Steuerungsenergie auf drei Dimensionen: Scope, Timeline und Budget. Was dabei systematisch unterschätzt wird: Der eigentliche Lebenszyklus eines SAP-Systems beginnt erst nach dem Go-Live. Und genau dort entstehen die größten Kosten, die ernsthaftesten Risiken und die tiefsten Abhängigkeiten.

Phase 1: Hypercare – unterschätzt, oft chaotisch, entscheidend für die Akzeptanz

Die ersten Wochen nach Go-Live sind die härteste Belastungsprobe für jedes SAP-System. Nicht weil das System schlecht gebaut wurde, sondern weil der Produktivbetrieb eine andere Realität schafft als jede Testphase zuvor.

Was in dieser Phase typischerweise auftritt:

Unerwartete Prozessabbrüche. Abläufe, die in der Testumgebung problemlos funktioniert haben, scheitern plötzlich an Datenkombinationen, Volumen oder Benutzerverhalten, das im Test nicht abgebildet wurde. Die Ursachenanalyse kostet Zeit, die im laufenden Betrieb kaum vorhanden ist.

Performanceprobleme. Unter echter Last – hunderte Nutzer gleichzeitig, reale Datenmengen, parallele Hintergrundprozesse – verhält sich ein System anders als in der Qualitätssicherungsumgebung. Besonders in den ersten Wochen nach Go-Live können Antwortzeiten und Systemstabilität erheblich hinter den Erwartungen zurückbleiben.

Dateninkonsistenzen. Migrationsfehler, die im Test unentdeckt blieben, zeigen sich erst wenn Fachbereiche mit echten Geschäftsvorfällen arbeiten. Die Korrektur ist aufwändig und bindet Ressourcen, die eigentlich für die Stabilisierung gebraucht werden.

Das eigentliche Problem in dieser Phase ist struktureller Natur: Fachbereiche testen im Echtbetrieb – nicht mehr im Projekt. Anforderungen, die im Testbetrieb als erfüllt galten, werden im Arbeitsalltag plötzlich als unzureichend bewertet. Ohne ein strukturiertes Hypercare-Modell mit klaren Ticketprozessen, definierten Prioritätsstufen und eindeutigen Zuständigkeiten eskaliert diese Phase schnell – und das zu einem Zeitpunkt, an dem die Projektressourcen bereits abgebaut werden.

Phase 2: Stabilisierung – der unsichtbare Aufwand nach den ersten Wochen

Nach der akuten Hypercare-Phase beginnt die eigentliche Stabilisierungsarbeit. Sie ist weniger dramatisch als die ersten Wochen, aber langwieriger und in ihrer Gesamtbelastung oft unterschätzt.

Die typischen Aufgaben dieser Phase:

• Prozessanpassungen: Abläufe, die konzeptionell sinnvoll waren, erweisen sich im Alltag als unpraktisch. Nutzer suchen Umgehungen, Key User melden Anpassungsbedarf, der im Projekt nicht sichtbar war.
• Berechtigungsfeinschliff: Berechtigungskonzepte, die auf dem Papier vollständig wirkten, zeigen in der Praxis Lücken – zu restriktive Einschränkungen hier, unbeabsichtigte Zugriffsmöglichkeiten dort. Die Anpassung ist kleinteilig und zeitintensiv.
• Reporting-Korrekturen: Berichte und Auswertungen, die im Test abgenommen wurden, liefern unter Produktivdaten abweichende Ergebnisse oder entsprechen nicht den tatsächlichen Informationsbedürfnissen der Entscheider.

Was dabei häufig passiert: Change Requests explodieren. Erfahrungsgemäß werden in dieser Phase 30 bis 50 Prozent der initialen Prozessdefinitionen angepasst. Die Gründe sind nachvollziehbar: Anforderungen waren im Projektverlauf nicht vollständig sichtbar, weil Nutzer abstrakte Konzepte erst im Arbeitsalltag wirklich verstehen. Und das tatsächliche Nutzerverhalten weicht fast immer von den Annahmen ab, die bei der Prozessmodellierung zugrunde lagen.

Ohne einen definierten Change-Management-Prozess – mit Aufwandsschätzung, Priorisierung und Freigabe – werden aus kleinen Anpassungswünschen kostspielige Folgeentwicklungen.

Phase 3: Dauerbetrieb – der größte Kostenblock im SAP-Lebenszyklus

Wer ein S/4HANA-System über fünf, zehn oder fünfzehn Jahre betreibt, stellt irgendwann fest: Die Projektkosten waren nicht der größte Posten. Der Betrieb ist es. In vielen Unternehmen entstehen 60 bis 80 Prozent der Gesamtkosten eines SAP-Systems nach dem Go-Live – verteilt auf drei zentrale Kostentreiber.

Application Management: Support, Weiterentwicklung und Release-Anpassungen

Das Application Management umfasst alles, was notwendig ist, damit ein SAP-System im Alltag funktioniert und mit veränderten Anforderungen Schritt hält: First- und Second-Level-Support für Anwenderprobleme, Weiterentwicklungen für neue fachliche Anforderungen und die kontinuierliche Anpassung an SAP-Releases und gesetzliche Änderungen.

Dieser Aufwand ist dauerhaft und wächst mit der Komplexität des Systems. Unternehmen, die ihn nicht von Anfang an in ihrer Kostenplanung verankern, sind regelmäßig überrascht.

Infrastrukturkosten – besonders bei RISE with SAP schwer transparent

Infrastrukturkosten sind im klassischen On-Premise-Betrieb gut planbar. In Cloud-Modellen – und besonders unter RISE with SAP – ist die Kostentransparenz geringer. Verbrauchsbasierte Komponenten, Add-on-Services und optionale Managed Services summieren sich zu Beträgen, die sich ohne aktives Monitoring und Kostensteuerung schwer kontrollieren lassen. Detailliertere Einblicke dazu bietet unser Beitrag zu den kritischen Herausforderungen von RISE with SAP.

Externe Abhängigkeiten: Berater, Integrationsplattformen, Add-ons

Der dritte Kostentreiber ist oft der am wenigsten sichtbare: die Abhängigkeit von externen Partnern. Beratungsunternehmen für Weiterentwicklungen, Lizenzkosten für Integrationsplattformen und Drittanbieter-Add-ons, die bei der initialen Implementierung als notwendig bewertet wurden – all das summiert sich zu laufenden Kosten, die in Budgetplanungen häufig unterschätzt oder vergessen werden.

Die größte unterschätzte Abhängigkeit: institutionelles Wissen

Es gibt eine Abhängigkeit, die in keiner Kostenaufstellung auftaucht und die dennoch zu den teuersten Konsequenzen eines SAP-Projekts gehört: der Verlust von institutionellem Wissen nach Go-Live.

In der Praxis folgt ein bekanntes Muster: Das Projektteam löst sich auf. Berater verlassen das Unternehmen. Interne Projektmitglieder kehren in ihre Linienrollen zurück oder wechseln das Unternehmen. Das Wissen über Architekturentscheidungen, Konfigurationsgründe und Sonderlösungen, das in den Köpfen dieser Menschen gespeichert war, ist damit weitgehend verloren – und häufig nicht oder nur unzureichend dokumentiert.

Was bleibt: überforderte Key User, die plötzlich als primäre Wissensträger fungieren sollen, ohne dass ihre Rolle dafür ausgestattet wurde. Und eine wachsende Abhängigkeit von externen Dienstleistern, die bei jedem Problem neu eingeführt werden müssen und deren Einarbeitungsaufwand sich direkt in Kosten niederschlägt.

Was erfolgreiche Unternehmen nach dem Go-Live anders machen

Unternehmen, die ihren SAP-Betrieb langfristig im Griff behalten, teilen einige strukturelle Gemeinsamkeiten – und die meisten davon wurden nicht nach dem Go-Live entwickelt, sondern bereits im Projekt verankert.

Betriebsmodell vor Go-Live definieren. Wer ist nach Go-Live für was zuständig? Wie werden Support-Anfragen aufgenommen, priorisiert und bearbeitet? Welche Ressourcen stehen im Betrieb zur Verfügung, und wo beginnt die Grenze zum externen Dienstleister? Diese Fragen müssen beantwortet sein, bevor das System produktiv geht – nicht danach.

Wissen systematisch sichern. Dokumentation ist kein Luxus, sondern eine strategische Investition. Das gilt für Architekturentscheidungen ebenso wie für prozessuale Sonderfälle, Konfigurationsbegründungen und bekannte Einschränkungen. Ergänzend dazu: ein strukturiertes Key-User-Programm, das Wissen in der Organisation verankert und nicht von einzelnen Personen abhängig macht.

Klare Governance für Changes etablieren. Jede Systemänderung nach Go-Live sollte einen definierten Prozess durchlaufen: Anforderungsaufnahme, Bewertung, Priorisierung, Umsetzung, Test und Dokumentation. Was ad hoc und ohne Steuerung passiert, wird teuer und führt zu einem System, das mit der Zeit schwerer wartbar wird.

KPIs für den Betrieb definieren und messen. Was wird nicht gemessen, wird nicht gesteuert. Ticketvolumen, Durchlaufzeiten im Support, Systemverfügbarkeit, Change-Request-Backlog – wer diese Kennzahlen regelmäßig auswertet, erkennt Probleme früh und kann gegensteuern, bevor sie kostspielig werden.

Fazit: Der Betrieb entscheidet über den Projekterfolg

Der Go-Live ist kein Ziel – er ist ein Startpunkt. Was danach kommt, entscheidet darüber, ob ein SAP-Projekt langfristig als Erfolg oder als Belastung wahrgenommen wird.

Hypercare, Stabilisierung und Dauerbetrieb sind keine Randthemen für die IT-Abteilung. Sie sind strategisch relevante Phasen, die Planung, Ressourcen und Governance erfordern. Unternehmen, die das ernst nehmen, behalten Kontrolle über ihre Kosten und ihre Systemqualität. Unternehmen, die es dem Zufall überlassen, verlieren beides – schrittweise und oft unmerklich, bis der Handlungsdruck zu groß wird.

Ihren SAP-Betrieb nachhaltig und kosteneffizient aufstellen?

Wir unterstützen Sie beim Aufbau eines tragfähigen Betriebsmodells – von Anfang an. Von der Hypercare-Strukturierung über das Key-User-Konzept bis hin zur langfristigen Application-Management-Strategie begleiten wir Sie dabei, die Zeit nach Go-Live genauso professionell zu gestalten wie das Projekt selbst.

Jetzt Kontakt aufnehmen und den Grundstein für einen stabilen, kosteneffizienten SAP-Betrieb legen.

Bis bald und viel Erfolg!

Euer amotIQ solutions Team