Warum S/4HANA Service kein Copy Paste aus SAP CS ist

Vorspann

Viele Unternehmen starten ihre S/4HANA-Serviceplanung mit einer scheinbar pragmatischen Annahme: Wir nehmen die heutigen SAP-CS- oder SAP-CRM-Prozesse und bauen sie im neuen System wieder auf. Für IT-Leitungen klingt das zunächst risikoarm. Die Fachbereiche erkennen ihre Abläufe wieder, das Projekt vermeidet Grundsatzdiskussionen und das Customizing kann schnell beginnen.

Genau hier entsteht das Risiko. S/4HANA Service ist kein Releasewechsel von SAP CS. Es ist auch keine neue Oberfläche für eine bekannte Servicelogik. In vielen Projekten ist der Wechsel fachlich näher an der Einführung einer neuen Servicelösung als an einer technischen Migration. Wer das zu spät erkennt, trifft Architekturentscheidungen, während das Projekt längst im Customizing steckt.

Der alte CS-Auftrag war oft mehr als ein Auftrag

In SAP CS und SAP CRM Service haben Unternehmen über Jahre ihre eigene Arbeitsweise aufgebaut. Der Serviceauftrag war nicht nur ein Beleg. Er war Arbeitsliste, technische Dokumentation, Kostenobjekt, Kommunikationsanker, Ersatzteilkontext, Abrechnungsgrundlage und manchmal auch eine Art Projektnotiz.

Diese Breite war praktisch. Sie hat aber auch verdeckt, welche fachlichen Entscheidungen wirklich getroffen wurden. Manche Logik steckte im Customizing, manche in Erweiterungen, manche in Routinen erfahrener Mitarbeiter. Wenn ein Unternehmen diese Welt unverändert nach S/4HANA Service übertragen will, nimmt es nicht nur bewährte Prozesse mit. Es nimmt auch alte Unschärfen, Workarounds und unausgesprochene Architekturentscheidungen mit.

S/4HANA Service folgt einer anderen Lösungslogik

S/4HANA Service arbeitet mit anderen Objekten, Rollen, Oberflächen, Integrationspunkten und Architekturprinzipien. Business Partner, Fiori-Rollen, Serviceverträge, Serviceaufträge, Rückmeldungen, Abrechnung, Advanced Execution, Clean Core und mögliche Finance-Themen wie Event-Based Revenue Recognition müssen neu designed werden.

Das bedeutet nicht, dass jede alte Anforderung falsch ist. Viele alte CS- oder CRM-Prozesse enthalten wertvolles Wissen über Kunden, Anlagen, Ersatzteile, Service-Level und interne Verantwortung. Aber dieses Wissen muss übersetzt werden. Es darf nicht automatisch als Bauplan für das neue System dienen.

Der entscheidende Perspektivwechsel lautet: Nicht fragen, wie der alte Ablauf wiederhergestellt wird. Sondern fragen, welches Service-Zielbild künftig tragfähig ist.

Warum Copy Paste für Entscheider so verführerisch ist

Für Entscheider wirkt Copy Paste attraktiv, weil es Sicherheit verspricht. Ein bekanntes Prozessbild scheint weniger Schulung, weniger Widerstand und weniger fachliche Diskussion zu bedeuten. Gerade in Unternehmen mit Maschinen, Anlagen, Medizintechnikprodukten oder komplexem After-Sales-Geschäft ist der Servicebetrieb empfindlich. Niemand möchte riskieren, dass Techniker, Ersatzteilprozesse, Rechnungen oder Kundeninformationen nach dem Umstieg ins Stocken geraten.

Doch diese Sicherheit ist oft nur scheinbar. Wenn S/4HANA Service wie eine andere Servicelösung eingeführt werden müsste, aber wie ein Releasewechsel behandelt wird, entsteht eine Lücke zwischen Projektplanung und Realität. Die Organisation plant mit Wiederverwendung, während das System neue Konzepte verlangt. Die Folge sind späte Grundsatzdiskussionen, Notlösungen, zusätzliche Erweiterungen und Entscheidungsdruck im falschen Moment.

Zu frühes Customizing verschiebt die eigentliche Entscheidung

Customizing ist nicht der Ort, an dem ein Projekt sein Service-Zielbild suchen sollte. Customizing setzt Entscheidungen um. Es ersetzt sie nicht.

Vor dem Customizing müssen mehrere Fragen beantwortet sein. Welche Serviceprozesse bleiben wirklich geschäftskritisch? Welche alten Sonderwege waren nur historisch gewachsen? Welche Aufgaben übernimmt künftig der Standard? Wo braucht es eine bewusste Erweiterung? Welche Rolle spielen Servicevertrag, Serviceauftrag, technische Ausführung, Ersatzteilprozess, Abrechnung und Reporting? Und welche Auswirkungen hat jede Abweichung auf Clean Core, Releasefähigkeit, Schulung und Betrieb?

Wenn diese Fragen fehlen, wird Customizing zur Ersatzstrategie. Dann entscheidet das Projekt schrittweise im System, ohne dass ein belastbares Zielbild existiert. Das ist besonders gefährlich, weil viele Entscheidungen später schwer zurückzudrehen sind.

Die knappe Ressource ist Übersetzungswissen

Viele Unternehmen unterschätzen außerdem, wie selten belastbares Übersetzungswissen geworden ist. Es reicht nicht, SAP CS oder SAP CRM Service zu kennen. Es reicht auch nicht, nur S/4HANA Service nach Dokumentation konfigurieren zu können. Entscheidend ist die Fähigkeit, alte Servicewirklichkeit in neue Lösungsarchitektur zu übersetzen.

Ein guter Solution Architect erkennt, welche alte Anforderung fachlich zwingend ist und welche nur aus Gewohnheit formuliert wird. Er kann erklären, warum ein vertrauter Ablauf im neuen System anders gedacht werden sollte. Und er kann mit IT, Fachbereich und Finance klären, welche Entscheidung Standardnähe schützt und welche spätere Komplexität erzeugt.

Was IT-Leitungen vor dem Projektstart prüfen sollten

Vor dem Customizing braucht das Projekt eine kurze, aber belastbare Klärung.

  • Welche heutigen CS- oder CRM-Prozesse sind wirklich wertschöpfend?
  • Welche alten Funktionen wurden nur genutzt, weil es damals keine bessere Lösung gab?
  • Welche Objekte und Rollen übernimmt S/4HANA Service künftig als führend?
  • Wo entstehen neue Integrations- und Reportinganforderungen?
  • Welche alten Erweiterungen widersprechen dem Clean-Core-Ziel?
  • Welche Entscheidungen müssen Fachbereich, IT und Finance gemeinsam treffen?
  • Wer im Projekt versteht sowohl die alte CS- und CRM-Welt als auch S/4HANA Service?

Diese Fragen verlangsamen das Projekt nicht. Sie verhindern, dass Geschwindigkeit an der falschen Stelle entsteht.

Schlussfolgerung

Der gefährlichste Satz im S/4HANA-Serviceprojekt lautet nicht: Das geht nicht. Gefährlicher ist: Das haben wir früher auch so gemacht.

Der Satz ist wertvoll, weil er Erfahrung sichtbar macht. Aber er darf nicht die Antwort sein. Er muss der Startpunkt einer Prüfung werden. S/4HANA Service verlangt ein neues Lösungskonzept, nicht nur eine technische Fortschreibung alter CS- oder CRM-Abläufe. Wer das vor dem Customizing klärt, schützt Standardnähe, reduziert spätere Korrekturen und schafft Serviceprozesse, die nicht nur vertraut wirken, sondern langfristig tragfähig sind.

by Armin Ohlerth

Viele Unternehmen beruhigen sich damit, dass bis 2030 noch genügend Zeit für die Umstellung auf S/4 Service ist. Für SAP-Serviceorganisationen ist dieser Gedanke gefährlich, denn eine Transition von SAP CS oder SAP CRM zu S/4 Service ist weder ein Releasewechsel noch eine Migration wie bei den anderen alten SAP Modulen.

Hinzu kommt die Problematik von

  • langjährigen gewachsene Serviceprozessen
  • alten Datenmodellen
  • eingespielten Transaktionen
  • kundeneigene Erweiterungen und Entscheidungen,

die im Alltag nie sauber dokumentiert wurden.

Im schlimmsten Fall wurde die SAP-IT outgesourced und die erfahrenen Experten stehen nicht mehr zur Verfügung.

SAP hat für die Kernanwendungen der SAP Business Suite 7 die Mainstream Maintenance bis Ende 2027 und eine optionale Extended Maintenance bis Ende 2030 angekündigt. Das ist der Zieltermin bis zu dem Unternehmen klären müssen, wie ihr Service künftig funktionieren soll. Serviceauftrag, Vertrag, Equipment, Ersatzteil, Rückmeldung, Fakturierung, Controlling, Außendienst und Kundenschnittstelle hängen oft enger zusammen, als es auf einer Roadmap sichtbar wird.

S/4HANA Service ist keine 1:1-Kopie von SAP CS mit neuer Oberfläche. Ein Brownfield-Ansatz würde versuchen, ein bestehendes System mit möglichst viel historischer Logik weiterzuführen. Für viele Servicebereiche reicht das nicht. Ein S/4HANA-Service-Projekt wird häufig eher wie ein Greenfield-Projekt gedacht, weil Prozesse, Datenstrukturen, Rollen, Berechtigungen und Erweiterungen neu bewertet werden müssen. Dafür ist ein tiefes Verständnis der alten CS- und CRM-Welt notwendig, um die richtigen Zielentscheidungen zu treffen.

Die eigentliche Umstellung drängt bereits heute, weil die eigentliche Arbeit vor der Implementierung beginnt:

  • Welche Auftragsarten werden wirklich genutzt?
  • Welche Sonderfälle sind geschäftskritisch und welche sind nur historische Altlasten?
  • Welche Daten führen Kunde, Anlage, Vertrag, Ersatzteil und Rechnung?
  • Wie werden Objekt wie die Meldung aus CS in der Zukunft aussehen?

Welche Optionen werden gewählt (EBRR, Legacy Orgmodell, Advanced Execution sind nur einige der neuen Begriffe)

Die richtige Beantwortung dieser Fragen entscheiden später darüber, ob S/4HANA Service verständlich, wartbar und wirtschaftlich steuerbar wird.

Dazu kommt die Architekturfrage. Clean Core heißt, dass das ERP-System möglichst nah am SAP-Standard bleibt. Erweiterungen, Sonderlogik und Integrationen sollten so gestaltet werden, dass der Kern updatefähig bleibt. Für IT-Leitung und Enterprise Architecture ist das keine technische Mode, sondern eine strategische Leitplanke. Wer jede Ausnahme wieder direkt in den Kern baut, erzeugt die nächste schwer wartbare Landschaft.

Wer Clean Core ernst nimmt, muss früh entscheiden:

  • welche Anforderungen im Standard gelöst werden
  • welche organisatorisch geklärt werden und
  • welche außerhalb des Kerns liegen können.

SAP BTP kann dabei eine Rolle spielen, ist aber nicht dasselbe wie Clean Core. Die SAP Business Technology Platform kann als Erweiterungs- und Integrationsschicht helfen, etwa für mobile Apps, Kundenportale, Datenservices oder Automatisierung. Sie ersetzt aber nicht die fachliche Entscheidung, wie der Serviceprozess selbst aussehen soll. Genau hier entstehen in Projekten häufig Missverständnisse. Erst das Zielbild, dann die Architektur.

Die Komplexität steckt oft in Details, die im Management zunächst klein wirken. Nummernkreise, Objektmodelle, erweiterte Retourenabwicklung (ARM), der neue Inhouse Service, Event Based Revenue Recognition und Item Based Accounting können erheblichen Abstimmungsbedarf auslösen. Gleichzeitig sind Berater mit tiefem SAP-CS- und SAP-CRM-Wissen seltener geworden, da die Einführungen oft vor vielen Jahren abgeschlossen wurden. Wer diese Erfahrung erst sucht, wenn das Projekt bereits unter Zeitdruck steht, verliert wertvolle Steuerungsmöglichkeiten.

Für Entscheider lautet die Kernfrage, wie soll das Servicegeschäft nach 2030 gesteuert werden. Welche Prozesse sollen standardisiert werden? Welche Differenzierung ist wirklich wichtig? Wo braucht der Außendienst bessere Unterstützung? Wie soll Serviceprofitabilität sichtbar werden? Welche Daten müssen bereinigt sein, bevor eine neue Oberfläche überhaupt Nutzen bringt?

Beratungsunternehmen sollte in genau dieser frühen Klärung Wert stiften. Nicht als reiner Modulberater, sondern als Solution Architekt und Prozessberater, der alte CS- und CRM-Logik versteht und in die neue S/4HANA-Service-Welt übersetzen kann. Die Transition vom Alt- zum Neusystem ist radikal genug, um sie nicht als spätes Upgrade zu behandeln. Unternehmen führen sonst zwar neue Software ein, behalten aber ihre alten Probleme.

Ein sinnvoller Start ist ein Transformationsbild mit folgenden Komponenten:

  • Systemlandkarte
  • Prozesslandkarte
  • Datenobjekte
  • kritische Varianten
  • Architekturprinzipien und Entscheidungsbedarfen

sind die Grundlage. Damit lässt sich besser entscheiden, ob ein Unternehmen standardisiert, neu modelliert, erweitert oder bewusst vereinfacht.

Genau diese Klarheit schützt Budget, Projektteam und Management vor falschen Erwartungen.

 

Autor: Armin Ohlerth, Rakentaa GmbH. Solution Architekt und Prozessberater für SAP Customer Service, SAP CRM und S/4HANA Service.

 

4. August 2026