SAP Service Cloud V2 + S/4HANA Public Cloud: Vom Fall über den Serviceauftrag zur Faktura

Ein Kunde ruft wegen einer defekten Maschine an. Sieht der Agent, um welche Maschine es geht, ob sie noch in der Garantie ist, und kann er den ERP-Serviceauftrag eröffnen, ohne das System zu wechseln? Mit SAP Service Cloud V2 und SAP S/4HANA Public Cloud, verbunden über die SAP Integration Suite, lautet die Antwort ja, und der Mechanismus besteht grösstenteils aus SAP-Standardinhalten statt aus eigenem Code.

Dieser Beitrag behandelt die Serviceseite der Verbindung: wo der Fall lebt, wo die Abwicklung lebt, welche Daten in welche Richtung fliessen und welche Spielregeln wir in Projekten anwenden. Für die Vertriebsseite derselben Topologie lesen Sie die Integrationsarchitektur von Sales Cloud V2; das Gesamtbild zeigt unser Leitfaden zum integrierten Stack aus S/4HANA Public Cloud und Sales Cloud V2.

Kurzfassung: Der Fall lebt in Service Cloud V2, die Abwicklung (Serviceauftrag, Ersatzteile, Rückmeldung, Faktura) in S/4HANA Public Cloud. SAP liefert Standard-Integrationspakete auf der SAP Integration Suite für Stammdaten (Geschäftspartner, Produkte, Equipments) und für Serviceprozesse (Serviceaufträge, Verträge, Angebote, Retouren). Erst die Stammdaten replizieren, dann den Prozess anbinden. Eigene Logik gehört als Side-by-Side-Erweiterung auf SAP BTP, nie in eines der Kernsysteme.

Wie wird Service Cloud V2 mit S/4HANA Public Cloud integriert?

Die Integration läuft über die SAP Integration Suite (Cloud Integration) auf SAP BTP. Service Cloud V2 stellt REST-APIs bereit; S/4HANA Public Cloud stellt freigegebene APIs bereit, die im SAP Business Accelerator Hub dokumentiert sind und pro Szenario über Kommunikationsvereinbarungen aktiviert werden. Keines der Systeme ruft das andere direkt auf. Die Integration Suite mappt, routet und überwacht jede Nachricht. Das ergibt eine Fehlerwarteschlange, eine Wiederholungslogik und ein Betriebshandbuch.

SAP liefert die Integrationsinhalte einsatzbereit aus. Für den Service zählen zwei Pakete:

• Das Stammdatenpaket für Sales und Service Cloud V2 mit S/4HANA Cloud Public Edition: Geschäftspartner und Kontaktbeziehungen in beide Richtungen, Produkte, Organisationsdaten sowie Equipments und technische Plätze aus S/4HANA.
• Das Servicepaket für Service Cloud V2 mit S/4HANA: Serviceaufträge in beide Richtungen, Serviceverträge und Serviceangebote aus S/4HANA, Retouren sowie ein Folge-Kundenauftrag für die Fakturierung.

Deployment heisst: das Paket in Ihren Integration-Suite-Tenant kopieren, Verbindungen und Wertemappings konfigurieren und die iFlows aktivieren. Vorher muss die Integration Suite auf Ihrem BTP-Subaccount bereitgestellt sein, und in S/4HANA müssen die Kommunikationsvereinbarungen existieren. Teams, die diese Einrichtung als Fussnote behandeln, verlieren zu Beginn der Integrationsphase typischerweise einen Sprint. Die Dokumentation der SAP Integration Suite beschreibt die Plattformseite.

Wo der Fall lebt, wo die Abwicklung lebt

Die Architektur beginnt mit einer bewussten Arbeitsteilung. Der Fall lebt in Service Cloud V2. Dort laufen alle Kanäle (E-Mail, Telefon, Kundenportal) im selben Objekt zusammen, mit Fallkategorien, Service-Level-Vereinbarungen, Eskalationen und der gesamten Kommunikation mit dem Kunden. Der Agent sieht auf einen Blick, wer anfragt, was schon gelaufen ist und wie viel Zeit bis zur SLA-Verletzung bleibt.

Die Abwicklung lebt in S/4HANA: Serviceauftrag, Retoure, Ersatzteillogistik, Rückmeldung, Faktura oder Gutschrift. Hinter diesen Belegen stehen Bestandsführung, Kostenrechnung und Finanzbuchhaltung. Ein CRM sollte das nicht nachbauen; wer Lagerbestand oder Fakturierung im CRM abbildet, baut ein zweites, schwächeres ERP.

Zwei Systeme, zwei Rollen. Die Integration verbindet sie, ohne sie zu vermischen.

Stammdaten zuerst, Prozess danach

Der häufigste Fehler in solchen Projekten ist die Reihenfolge. Alle wollen zuerst den Prozessfluss bauen: den Serviceauftrag aus dem Fall anlegen, die Statusrückmeldung sehen. Ohne synchronisierte Stammdaten läuft davon nichts.

Kunden. Accounts in Service Cloud V2 und Geschäftspartner in S/4HANA müssen dieselben Datensätze sein, mit sauberem ID-Mapping über die Standardreplikation. Dubletten hier werden später zu doppelten Servicehistorien.

Installationsbasis. S/4HANA ist das führende System für Equipments, technische Plätze und Serviceverträge. Die Standard-iFlows replizieren Equipments und technische Plätze nach Service Cloud V2, wo sie als registrierte Produkte am Account erscheinen, mit Seriennummer, Produkt und Installationsdatum. Ruft ein Kunde an, sieht der Agent die Maschine, nicht nur den Kunden.

Garantie- und Vertragsstatus. Auch Serviceverträge werden aus S/4HANA repliziert. Das macht die Triage konkret: Der Agent sieht, ob der Defekt unter Garantie fällt oder durch einen Vertrag abgedeckt ist, bevor er einen kostenpflichtigen Einsatz zusagt.

Das Mapping zwischen den technischen Objekten von S/4HANA und dem Modell der registrierten Produkte in Service Cloud V2 braucht Aufmerksamkeit. Der Standardinhalt übernimmt die Grundübersetzung, eigene Felder und Hierarchieregeln müssen aber explizit konfiguriert werden. Planen Sie dafür einen Sprint ein. Stammdatenintegration ist unspektakulär, aber sie entscheidet, ob die Prozessintegration danach Wochen oder Monate dauert.

Vom Fall über den Serviceauftrag zur Faktura

Das ist der zentrale Belegfluss und der, der dem Service am meisten ungeliebte Handarbeit abnimmt:

1. Der Fall entsteht in Service Cloud V2, egal über welchen Kanal. Anruf, E-Mail oder Portaleintrag landen im selben Fall, verknüpft mit Kunde und registriertem Produkt.
2. Der Agent kategorisiert und prüft. Fallkategorie gesetzt, Garantie und Anspruch gegen die replizierten S/4HANA-Daten geprüft, die SLA-Uhr läuft.
3. Der Folgebeleg entsteht. Aus dem Fall legt der Agent einen Serviceauftrag an, den der Standard-iFlow nach S/4HANA repliziert. Je nach Szenario kann es auch eine Retoure sein.
4. S/4HANA wickelt ab. Ersatzteile werden gegen den Bestand reserviert, Zeit und Material des Technikers auf dem Serviceauftrag rückgemeldet, und die Fakturierung läuft in S/4HANA, wo der Standardinhalt dafür einen Folge-Kundenauftrag anlegen kann.
5. Der Status fliesst zurück in den Fall. Der S/4HANA-Serviceauftrag wird mit seinem Status nach Service Cloud V2 zurückrepliziert, und der Agent informiert den Kunden aus dem Fall.

Der letzte Punkt ist der wichtigste: Die Kundenkommunikation bleibt im CRM. Der Kunde hat einen Ansprechpunkt, einen Faden und eine Historie und erfährt über den Fall, was im ERP passiert.

Ein typisches Beispiel ist eine beschädigt angelieferte Sendung. Der Anruf kommt rein, der Fall wird mit der Kategorie «Transportschaden» angelegt, und die per E-Mail gesendeten Fotos hängen am selben Fall. Der Agent prüft die Lieferung im verknüpften S/4HANA-Beleg und stösst Retoure und Ersatzlieferung an. Sobald S/4HANA die Ersatzlieferung bestätigt, geht die Information aus dem Fall an den Kunden. Ein Vorgang, eine Referenz, kein Suchen.

Ersatzteile und die Übergabe an FSM

Für ausrüstungsintensive Servicebetriebe ist die Ersatzteilverfügbarkeit oft der kritische Pfad. Reservierungen erfolgen gegen den S/4HANA-Serviceauftrag, die Teile hängen also am Auftrag und nicht am Fahrzeugbestand eines Technikers. Bei mehreren Lagern hält genau das die Verfügbarkeitszusagen verlässlich.

Braucht es einen Einsatz vor Ort und wird die Planung anspruchsvoll (Schichten, Skills, Routen), ist SAP Field Service Management die Schicht für Disposition und mobile Ausführung. Der Fall bleibt in Service Cloud V2, die Disposition läuft in FSM, und die vom Techniker rückgemeldeten Zeiten und Materialien werden für die Fakturierung auf den S/4HANA-Serviceauftrag gebucht. Legen Sie einen einzigen führenden Auslöser für den Einsatz fest, meist den S/4HANA-Serviceauftrag, und dokumentieren Sie ihn: Zwei Systeme, die für denselben Fall FSM-Aufträge anlegen können, erzeugen doppelte Einsätze. Unsere Beiträge zu FSM mit S/4HANA Public Cloud und zur Integrations-Checkliste für FSM, Sales Cloud und S/4HANA gehen ins Detail.

Was der Serviceagent sieht

Ein Agent, der für eine einzige Frage zwischen CRM, ERP und FSM hin- und herwechselt, macht Fehler und braucht zu lange. Im integrierten Setup sieht der Agent in Service Cloud V2:

• Installationsbasis: Equipments, Seriennummern und Vertragsstatus (aus S/4HANA)
• Serviceaufträge: die mit dem Fall verknüpften ERP-Aufträge und ihren Status (aus S/4HANA)
• Serviceverträge und Serviceangebote: repliziert aus S/4HANA
• Fallhistorie: frühere Fälle, Lösungsnotizen und Bearbeitungszeit (nativ in Service Cloud V2)

Der Agent muss nicht in S/4HANA arbeiten, um dem Kunden zu antworten. Wo Aussendienst und ERP verschiedenen Teams gehören, ist das eine echte Veränderung: Der Agent mit Kundenkontakt hat den Kontext, ohne auf eine Kollegin in der Logistik zu warten.

Was sich in Projekten bewährt hat

Die Fallkategorien klein halten. Ein Kategorienbaum mit vierzig Ästen zum Go-Live führt dazu, dass Agenten irgendetwas Naheliegendes wählen und das Reporting wertlos wird. Unsere Regel: fünf bis acht Kategorien zum Start, nach drei Monaten anhand der echten Fälle nachschärfen.

Telefonie anbinden. Im B2B-Service ist das Telefon weiterhin der stärkste Kanal. Eine CTI-Integration, die den Anrufer identifiziert und den Kundenkontext einblendet, während das Telefon noch klingelt, spart bei jedem Anruf die erste Minute. Wir haben solche CTI-Adapter für Service Cloud V2 mehrfach gebaut; wie das funktioniert, zeigt unser Beitrag zum nativen Screen Pop im Agent Desktop.

Das ERP-Statusmodell im ERP lassen. Der Fall braucht keinen Zwilling jedes S/4HANA-Belegstatus, sondern die Antwort auf die Kundenfrage: in Arbeit, unterwegs, erledigt. Wer jeden Belegfluss spiegelt, pflegt ab dann zwei Statusmodelle.

Hierarchien an einem Ort pflegen. Produkt- und Equipmenthierarchien haben ein Zuhause, das ERP, und werden von dort repliziert. Zwei handgepflegte Hierarchien laufen auseinander; offen ist nur, wann.

Clean-Core-Muster für die Integration

Das Clean-Core-Prinzip von SAP für S/4HANA Public Cloud heisst: keine Modifikationen am SAP-Code. Dieselbe Disziplin gilt für die Integrationsschicht.

Erst kopieren, dann konfigurieren. SAP pflegt die Standard-iFlows und liefert Updates. Wer einen Standard-iFlow direkt ändert, kann diese Updates nicht mehr sauber einspielen. Kopieren Sie ihn, ändern Sie die Kopie und dokumentieren Sie die Abweichung.

Eigene Logik auf BTP. Routingregeln nach Equipmenttyp und Region oder Eskalationen nach Vertragsstufe gehören in eine CAP-Anwendung oder einen eigenen iFlow auf SAP BTP, nicht in Workflows von Service Cloud V2 oder Serviceprozesse von S/4HANA. Unser Leitfaden zu Clean-Core-Erweiterungen mit SAP CAP zeigt das Muster.

Eine Integrationsplattform. Alle Flüsse (Stammdaten, Fall zum Serviceauftrag, FSM, Fakturastatus) laufen über denselben Integration-Suite-Tenant: eine Überwachungssicht, eine Fehlerwarteschlange, ein verantwortliches Team. Punkt-zu-Punkt-Aufrufe zwischen Systemen sind ein Wartungsproblem mit Ansage.

Alerting ab dem ersten Tag. Die Standardpakete enthalten Fehlerbehandlung, aber jemand muss festlegen, wer bei einer fehlgeschlagenen Nachricht benachrichtigt wird, wie oft wiederholt wird und wer was behebt. In der Projektumsetzung wird das oft ausgelassen und fällt beim ersten Produktivfehler auf.

Was am Ende steht

Ein Fall, der vom ersten Anruf bis zur Gutschrift nachvollziehbar ist. Ein Agent, der Garantie und Lieferstatus sieht, ohne das System zu wechseln. Ein Kunde, der einmal anruft statt dreimal. Und zwei Systeme, die im Standard bleiben, weil keines die Arbeit des anderen imitiert.

Wer beide Seiten plant, fährt mit einem Team für beide Hälften besser; das ist das Argument unseres Leitfadens zur Wahl eines SAP-Partners für Cloud ERP und CRM in der Schweiz. Liegt S/4HANA Public Cloud selbst noch vor Ihnen, klärt das S/4HANA Readiness Assessment zuerst die Ausgangslage.

Häufige Fragen

Kann ein Fall in SAP Service Cloud V2 einen Serviceauftrag in S/4HANA Public Cloud anlegen?

Ja. Der Agent legt aus dem Fall in Service Cloud V2 einen Serviceauftrag an, und das Standard-Integrationspaket von SAP repliziert ihn nach S/4HANA, wo Ersatzteile, Rückmeldungen und Fakturierung abgewickelt werden. Der S/4HANA-Serviceauftrag wird mit seinem Status zurückrepliziert, sodass der Agent dem Kunden aus dem Fall heraus antworten kann, ohne das ERP zu öffnen.

Wie fliessen Daten der Installationsbasis zwischen S/4HANA und Service Cloud V2?

S/4HANA ist das führende System. Das Stammdatenpaket von SAP repliziert Equipments und technische Plätze aus S/4HANA Public Cloud nach Service Cloud V2, wo sie als registrierte Produkte am Kundenaccount erscheinen. Der Agent sieht im Fall Seriennummer, Installationsdatum und Vertragsstatus, und die Hierarchie wird nie doppelt gepflegt.

Wie passt SAP Field Service Management dazu?

FSM ist die Schicht für Disposition und mobile Ausführung. Legen Sie einen einzigen Auslöser für den Technikereinsatz fest, typischerweise den S/4HANA-Serviceauftrag, und lassen Sie FSM ihn planen und ausführen. Die vom Techniker rückgemeldeten Zeiten und Materialien werden auf den Serviceauftrag gebucht, der dann die Fakturierung in S/4HANA steuert.

Ersetzt Service Cloud V2 ein separates Ticket-Tool?

Für den kundenbezogenen Service ja: Omnichannel-Eingang, Fallkategorien, SLAs, Wissensdatenbank und Kundenhistorie sind an Bord, und die ERP-Anbindung ist der eigentliche Vorteil gegenüber einem generischen Ticket-Tool. Für internes IT-Ticketing bleibt ein dediziertes Werkzeug oft die bessere Wahl, weil es ein anderer Anwendungsfall ist.

Welcher Aufwand ist für den Ablauf vom Fall zur Lösung realistisch?

Das hängt vor allem an den Stammdaten. Werden Accounts und Equipments bereits sauber repliziert, ist der Ablauf vom Fall zum Serviceauftrag eine Sache von Wochen, weil die Integrationsinhalte von SAP die Belegflüsse abdecken. Teuer wird es, wenn Stammdaten fehlen oder in einem der Systeme eigene Statuslogik gebaut wird.

---

Ihre Reklamationen leben im Sammelpostfach und Ihr Service sucht Lieferstatus im ERP zusammen? Wir gehen den Ablauf gern mit Ihren eigenen Serviceprozessen durch. Sprechen Sie mit unserem Team.