Mit der Ankündigung des neuen S/4HANA-Systems wurden eine Vielzahl der Prozessmodule im neuen S/4 Core implementiert. Doch kaum ein Modul war im bisherigen Release-Zyklus so vielen Anpassungen unterworfen wie das aus dem ECC bekannte Modul SAP CS. Von der Entfernung grundlegender Funktionalitäten, wie der Möglichkeit zur Erzeugung von aufwandsbezogenen Fakturen, über den DPP in den ersten Release, zur Übernahme ehemaliger CRM-Belegtypen und einer grundlegenden Integration in CRM-Bestandsprozesse bietet das aktuelle Release 09/2023 erstmals wieder ein Tool-Set, um bestehende Kundenanforderungen auch in der Fläche abbilden zu können.
1. Einführung in den neuen S/4 HANA Service Core
Die Strategie der SAP zur Integration der neuen S/4HANA-Kernprozesse im Service wurde über die Iterationen der letzten Releases zunehmend detaillierter und gibt zum Stand 09/2023 erstmals ein homogenes Bild wieder.
Die Referenzarchitektur stellt den Service Core zentral eingebettet in den Prozessfluss der Serviceabwicklung dar. Er umfasst alle operativen Komponenten der Serviceabwicklung wie Angebotswesen, Reparatur, Wartung, Inbetriebnahme, Garantie- sowie Ersatzteilabwicklung und die Integration von Faktura- und angeschlossenen Rechnungswesen-Prozessen.
Dem vorgeschaltet bietet die SAP Service Cloud Funktionalitäten zur Customer Interaction und stellt Basisinformationen, wie z. B. kanalübergreifende Kontaktinformationen, ein Ticketing und kundenspezifische Informationen zum SLA- und Entitlement-Handling hierfür bereit. Dem Service Core nachgelagert findet sich das Modul SAP Field Service Management (FSM), das operative Funktionen für die Technikereinsatzplanung und -durchführung bereitstellt. Auf der Planungsebene können Einsätze von technischen Servicefachkräften geplant und dispatched werden. Die Technikerin oder der Techniker on-site bekommt ein Tool-Set zur Verfügung gestellt, mit dem sie oder er Rückmeldungen, Materialentnahmen, Formularausgaben sowie mit einer GISIntegration die eigenen Einsätze gestalten und durchführen kann.
Abgerundet wird die Referenzarchitektur durch ausgewählte Elemente des Asset Managements. Hier können Anlagenleistungen durch das SAP Asset Performance Management gemessen werden. Eine Integration von GIS- und Standortservices ermöglicht die Visualisierung durch den Service und Asset Manager. Intelligente Wartungsszenarien (reactive, predictive & preventive maintenance) bieten Optionen zur Optimierung des Anlagenzustandes und der Bereitschaftszeit.
Die Prozessarchitektur der neuen S/4HANA-Service-Szenarien bildet mit dem Release 09/2023 auf der Makroebene ein vollständiges Bild der Einsatzszenarien der Serviceprozesse ab und ermöglicht so strategisch eine Planung der Servicelandschaft. Im Detail gibt es nach wie vor (Unter)Prozesse, die derzeit nicht oder noch nicht wieder vollständig verfügbar sind. Hier werden die kommenden Releases Aufschluss darüber geben mit welcher Geschwindigkeit diese wieder verfügbar sind.
2. Kernprozesse im Service Core
Nach der Einordnung des neuen Service Cores in die ganzheitliche SAP-gestützte Serviceabwicklung wollen wir nun zunächst einmal die Kernprozesse des Services erläutern. Dies wird ein Verständnis der aktuellen Heraus- und Anforderungen an die Prozessarchitektur schaffen und eine Grundlage für die später aufgeführten Prozess- und Transformationsvarianten liefern.
2.1 Customer Service to Field Service
Der klassische Technikerprozess beschreibt die Abwicklung von Serviceprozessen im Feldeinsatz.
Nach der Aufnahme der Serviceanfrage wird ein Angebot auf Basis der relevanten Kundenstammdaten und der Durchführung der Kreditkontrolle aufgenommen. Bereits zu diesem Zeitpunkt ist es möglich, auf Basis von Plandaten Kosten sowie Erlöse zu ermitteln. Aufbauend auf dem Angebotscharakter können bereits Materialverfügbarkeiten ermittelt, Stücklistenauflösungen durchgeführt und ggf. ein Vorabversand der Teile aus dem Lager zum Einsatzort initiiert werden.
Anschließend erfolgt die Planung des Serviceszenarios und die terminliche Planung des Technikereinsatzes. Der erzeugte Serviceauftrag dient als Kostenträger und ermöglicht den Mitarbeitenden die Zeiten, Einsatzkilometer sowie entnommenes Material nach Durchführung der Tätigkeiten zurückzumelden und so Ist-Kosten zu realisieren sowie die Ermittlungsvorbereitung der Ist-Erlöse durchzuführen. Zum Abschluss des Prozesses erfolgt die Faktura-Abwicklung im ermittelten Szenario (aufwandsbezogen, Time & Material oder zum Festpreis).
2.2 Service Contract to Recurring Service
Der nächste Kernprozess “Service Contract to Recurring Service” beschreibt die klassische Wartungsabwicklung auf Basis des Vertragswesens.
Nach dem initialen Abschluss eines Servicekontraktes erfolgt die Durchführung der Wartungsplanung, abhängig von Anlagenzustand, Betriebszyklus und Wartungsintervallen. Hier kann in Abhängigkeit vom Servicekontrakt ein Vorabangebot erzeugt werden. Verbrauchsmaterial für die Durchführung der Wartungstätigkeiten wird bereits vorab auf Verfügbarkeit geprüft und bereitgestellt.
Bei der Serviceplanung wird im Einzelfall geprüft, ob die Tätigkeiten von eigenen Technikfachkräften durchgeführt werden können oder ob eine externe Beschaffung von Dienstleistungen notwendig ist und diese ggf. erledigt. Während der Durchführung der Tätigkeit erfolgt eine Verrechnung von offenen Garantieanforderungen, die unter Umständen kostenwirksam auf den erzeugten Wartungsauftrag wirken. Den Abschluss des Prozesses bildet dann auch wieder die Rückmeldung auf den Auftrag sowie die finanzielle Abwicklung – hier in der Regel über den Fakturaplan des Servicevertrages.
Eine große Änderung in diesem Kontext ist die Einführung der neuen Service-Belegarten. D. h., dass das bisher bekannte Zusammenspiel zwischen SD- (Wartungsvertrag im ECC) und CS-Belegen (generierten Wartungsmeldungen und -aufträgen) hier bewusst getrennt und auf spezifische Service-Belegarten umgestellt wird. Der zuvor erwähnte Servicekontrakt ist also kein SDBeleg mehr, sondern wird auf Basis der bisher bekannten CRM-Belegtypen generiert. Eine Schnittstelle zum SD-Modul kommt im neuen Service Core erst wieder in der Abrechnung und der Überführung in die Faktura zum Tragen. Zum Servicekontrakt wird dann ein „billing document request“ (BDR) erzeugt, dass sich dann über den Fakturavorrat in eine SD-Faktura transformieren lässt.
2.3 Return to Inhouse Repair
Der Kernprozess zur Inhouse-Reparatur beinhaltet die Vereinnahmung von Materialien, die Inspektion und Ableitung von Reparaturaufgaben und der erneuten Bereitstellung des Materials beim Endkunden.
Initial erfolgt die Aufnahme der Reparaturanfrage in der Regel zentral durch einen Customer Service Agent. Im nächsten Zuge erfolgt die Anlieferung des defekten Gerätes. Hier werden Ergänzungsprozesse wie die Integration in die erweiterte Retourenabwicklung oder die parallele Auslieferung eines Ersatzgerätes zur Verfügung gestellt. Nach der Vereinnahmung des zu reparierenden Objektes kann eine Kreditkontrolle des Kunden durchgeführt werden. Anschließend erfolgt die Inspektion und Begutachtung des Gerätes und eine Ableitung des (standardisierten) Fehlerbildes.
Auf dieser Basis kann ein Angebot zur Reparatur erzeugt werden. Nach Angebotsannahme wird der Reparaturauftrag erzeugt und kann individuell oder durch Checklisten geführt abgewickelt werden. Wird die Nicht-Reparierbarkeit festgestellt erfolgt im Zuge des Reparaturauftrages eine Aussonderung des Gerätes sowie die Verschrottung. Konnte die Reparatur erfolgreich durchgeführt werden wird das reparierte Objekt an den Kunden ausgeliefert. Abhängig von der Ausprägung des Angebotes wird zum Prozessabschluss eine Faktura entweder zum Festpreis und dynamisch nach Aufwand erzeugt.
3. Prozessvarianten und Implementierungsansätze
Durch die hohe strukturelle Neuausrichtung stellt die SAP AG verschiedene Implementierungsansätze des neuen Service Cores bereit, die im Einzelfall auf Implementierungstauglichkeit zu prüfen sind. Der nachstehende Abschnitt gibt hier eine Übersicht.
3.1 Kompatibilitätsmodus
Der Kompatibilitätsmodus stellt zunächst die einfachste Möglichkeit zur Umstellung der Serviceprozesse auf S/4HANA dar. Dieser Modus bildet den Übergang vom ECC in das S/4HANA
ab, in dem Kernfunktionalitäten des alten SAP CS 1 : 1 übernommen werden. Bestehende Belegarten werden weiterhin aus den SD-Prozessen verwendet und neue Belegobjektmodelle finden noch keine Anwendung.
Im Zuge der Prozessvereinheitlichung stellt der Kompatibilitätsmodus eine auslaufende Lösung dar, die nach aktuellem Stand bis 31.12.2030 fortgeführt wird. Hier sind Migrationsszenarien denkbar einfach: Bestandsdaten werden in das neue S/4HANA-System übernommen und können ohne weitere Anpassungen fortgeführt werden. Prozessoptimierungen, die Integration in servicespezifische Module (Cloud Integration, Asset Management) sind hier nur rudimentär möglich.
3.2 S/4HANA Service Core
Der ursprünglich ausgeprägte S/4HANA Service Core beinhaltet die Trennung von alten SD- und neuen CS-Belegobjektmodellen und bietet eine Prozessintegration für die zuvor vorgestellten Kernprozesse im Service.
Einer der schwerwiegendsten Nachteile im ursprünglichen Service Core ist das Fehlen eines dynamischen Posten-Prozessors, der die Erzeugung von aufwandsbezogenen Faktura-Prozessen ermöglicht. Eine Abrechnung der neuen Service-Belegarten ist damit nur zum Festpreis möglich. Weiterhin fehlt hier eine vollständige Integration in umliegende Serviceszenarien (Service Cloud, Asset Management).
Aus diesem Grund wird die Umstellung auf den ursprünglichen S/4HANA Service Core nicht empfohlen.
3.3 S/4HANA Service 2023 with advanced execution
Mit dem Release 09/2023 implementierte die SAP AG umfangreiche Anpassungen in die Service-Core-Prozesse. Diese werden unter dem Arbeitstitel „S/4HANA Service 2023 with advanced execution“ veröffentlicht. In diesem Einsatzszenario werden neue Serviceobjektmodelle mit bestehenden Funktionalitäten aus SAP PM und SAP SD kombiniert und schaffen so eine Prozessfläche, um Bestandsprozesse mit neuen Funktionalitäten aus dem Service Core kombiniert abbilden zu können.
Im Prozessablauf wird zunächst auf die neuen Service-Belegtypen zurückgegriffen, um servicespezifische Verträge, Anfragen, Angebote oder auch Aufträge abbilden zu können. Soll eine Abrechnung zum Festpreis erfolgen, so reichen die neuen Servicebelege und der Prozess kann über die SD Billing Integration bis in die Finanzbuchhaltung abgewickelt werden. Sollen jedoch aufwandsbezogene Szenarien abgebildet werden oder Rückmeldungen zur Ist-Kostenermittlung
zum Einsatz kommen, so wird aus der Position der Service Order ein bis „n“ Instandhaltungsaufträge erzeugt, die dann alle benötigten Folgefunktionalitäten zur Verfügung stellen. Falls notwendig können diese über den DPP aufwandsbezogen fakturiert werden. Wie im vorigen Schaubild zu sehen, spielen SD-Belege zu Vertrag, Angebot und Auftrag in der Service-Abwicklung mit advanced execution keine Rolle mehr.
4. Implementierung neuer Belegarten und Dokumententypen
Nicht direkt ein Kernprozess in der Serviceabwicklung, sondern eher als strukturelle Übersicht zu sehen, ist das nachstehende Prozessbild zum „Service with advanced execution“. Hier wird ein Schnittbild der Belegtypen und Objektmodelle erzeugt, die sich in den wiederkehrenden Serviceprozess-Schritten (Anfrage, Customer Interaction, Serviceverkauf, Planung, Durchführung und Abrechnung) integrieren. Diese Prozessarchitektur wird im S/4 Service Core als „Service with advanced execution” bezeichnet und umfasst Elemente aus dem neuen Service sowie den bekannten Modulen SAP PM, SAP SD und dem SAP FI.
Im linken Bereich erfolgt die Abbildung der neuen Service-Objektmodelle, also denjenigen Belegarten, die es im alten SAP CS nicht gab. Hier wird die Trennung von Elementen des SAP-SDModuls besonders deutlich. Für Servicekontrakte, Angebote sowie der kaufmännischen Service Order gibt es neue Belegarten. Aus der Service Order wird für ausführbare Positionen sogenannte „Execution Order Items“ ein Instandhaltungsauftrag erzeugt, der auch bereits in einer Angebotsphase als Planungselement für Arbeitsvorgänge und Materialeinsatz verwendet werden kann.
Auf Basis dieses Instandhaltungsauftrages werden alle weiteren relevanten Objekte zur Durchführung abgeleitet. Checklisten werden im Auftrag ausgelöst, erzeugte Reservierungen, Fremdbeschaffungen sowie Elemente des Vorabversandes erfolgen in Referenz zum Instandhaltungsauftrag und nicht zur Service Order. Auch die folgenden Prozess-Schritte wie bspw. die Rückmeldung von Zeiten oder Materialien erfolgen in Referenz zum Instandhaltungsauftrag. Die Ableitung des Billing Requests als Schnittstelle zum SAP-SD-Modul kann dann in Referenz zur Service Order oder zum Instandhaltungsauftrag erfolgen.
5. Zusammenfassung und Abschluss
Nach einem holprigen Weg der S/4HANA Releases der letzten Jahre steht mit dem aktuellen Release 09/2023 das erste Mal ein Funktionsumfang im S/4HANA Service Core zur Verfügung, der Kundenanforderungen in der Breite abbilden kann und damit als solide Ausgangsbasis für die Erarbeitung von perspektivischen Migrationsszenarien geeignet ist.
Die Integration der neuen Belegobjektmodelle ist zunächst noch gewöhnungsbedürftig, bildet die Bestandswelt aber sauber ab.
Natürlich gibt es auch weiter offene Themen der Release-List, die laufend aufgenommen, bewertet und abgearbeitet werden. So wird der Funktionsumfang step-by-step sinnvoll erweitert.
Die Entwicklung seit dem Release 09/2017 ist unterworfen von Änderungen der strategischen Ausrichtung in Bezug auf die Ausgestaltung der Serviceprozesse. Seit der letzten Neuausrichtung mit dem Release 09/2021 und den sukzessiven Anpassungen sowie Erweiterungen stellt das aktuelle Release 09/2023 eine solide Basis dar, um Serviceprozesse neu zu implementieren oder einfache Szenarien auch bereits auf eine neue S/4HANA-Installation zu migrieren. Um für komplexe Serviceszenarien einen geeigneten Migrationsansatz determinieren zu können ist es sinnvoll, zunächst Erfahrung mit der neuen Architektur und der Prozessintegration zu sammeln. Bei der weiteren Entwicklung können diese Prozesse dann im Hinblick auf ihre Migrierbarkeit und die fehlende Prozessintegration dann neu bewertet werden.
