Case-to-Resolution: SAP Service Cloud V2 mit S/4HANA Public Cloud verbinden

Eine Lieferung kommt verbeult beim Kunden an. Der Anruf landet im Service, die E-Mail mit Fotos folgt eine Stunde später, und ab da beginnt in vielen Unternehmen eine Wanderung: Die Reklamation lebt im Sammelpostfach, der Ersatzauftrag in einer Excel-Liste, die Gutschrift irgendwo in der Buchhaltung. Der Kunde ruft dreimal an, um zu erfahren, wo sein Fall steht, und bekommt dreimal eine andere Antwort. Genau diesen Ablauf haben wir bei einem B2B-Hersteller neu aufgesetzt: Fall in SAP Service Cloud V2, Abwicklung in S/4HANA Public Cloud, Status zurück in den Fall. Dieser Beitrag zeigt, wie die Verbindung sauber aussieht und welche Spielregeln sich im Projekt bewährt haben.

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 zusammen: E-Mail, Telefon, Kundenportal, alles wird zum selben Objekt, dem Case. Dort sitzen auch die Fallkategorien, die Service-Level-Vereinbarungen mit ihren Fristen und Eskalationen, und die gesamte 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: alles Belege mit Bestandsführung, Kostenrechnung und Finanzbuchhaltung dahinter. Ein CRM kann diese Dinge nicht, und es soll sie auch nicht können. Wer versucht, Lagerbestand oder Fakturierung im CRM nachzubauen, baut ein zweites ERP, nur schlechter.

Zwei Systeme, zwei Rollen. Die Integration verbindet sie, sie vermischt sie nicht.

Stammdaten zuerst, Prozess danach

Der häufigste Fehler in solchen Projekten ist die Reihenfolge. Alle wollen sofort den Prozessfluss bauen, den Serviceauftrag aus dem Case heraus anlegen, die Statusrückmeldung sehen. Nur: Ohne synchronisierte Stammdaten läuft davon nichts. Bevor irgendein Beleg fliesst, müssen zwei Dinge stehen.

Erstens die Kunden. Accounts in Service Cloud V2 und Geschäftspartner in S/4HANA müssen dieselben sein, mit sauberem ID-Mapping über die Standardreplikation. Zweitens die registrierten Produkte, in der ERP-Welt das Equipment. Der Agent muss im Fall sehen, welche Maschine, welches Gerät, welche Anlage beim Kunden steht, mit Seriennummer und Installationsdatum.

Erst dann wird der Fall intelligent: Die Garantie- und Anspruchsprüfung läuft gegen die S/4-Daten. Ist das Gerät noch in der Gewährleistung? Gibt es einen Servicevertrag? Wer das nicht angebunden hat, lässt den Agenten raten oder im ERP nachschlagen, und beides kostet bei jedem einzelnen Fall Minuten. Stammdatenintegration ist unspektakulär, aber sie ist das Fundament. De facto entscheidet sie darüber, ob die Prozessintegration danach Wochen oder Monate dauert.

Der saubere Ablauf: vom Fall zur Lösung

So sieht Case-to-Resolution aus, wenn beide Systeme ihre Rolle spielen:

1. Der Fall entsteht in Service Cloud V2, egal über welchen Kanal. Anruf, E-Mail, Portaleintrag: alles landet im selben Case, mit Kunde und registriertem Produkt verknüpft.
2. Der Agent kategorisiert und prüft. Fallkategorie setzen, Garantie und Anspruch gegen die S/4-Daten prüfen, SLA läuft ab jetzt.
3. Der Folgebeleg entsteht in S/4HANA. Aus dem Fall heraus wird die passende Transaktion angestossen: Serviceauftrag, Retoure oder Gutschriftsanforderung, je nach Szenario.
4. S/4HANA wickelt ab. Ersatzteil kommissionieren, Techniker rückmelden, fakturieren oder gutschreiben. Das ERP führt, wie es das immer tut.
5. Der Status fliesst zurück in den Fall. Der Agent sieht im Case, dass die Ersatzlieferung raus ist oder die Gutschrift gebucht wurde, und informiert den Kunden von dort.

Der letzte Punkt ist der wichtigste: Die Kundenkommunikation bleibt vollständig im CRM. Der Kunde hat einen Ansprechpunkt, einen Faden, eine Historie. Was im ERP passiert, sieht er nie direkt, er erfährt es über den Fall.

Unser Beispielszenario, die verbeulte Lieferung, läuft dann so: Anruf kommt rein, Fall wird mit Kategorie Transportschaden angelegt, Fotos hängen per E-Mail am selben Case. Der Agent prüft die Lieferung im verknüpften S/4-Beleg, stösst Retoure und Ersatzlieferung an, die Gutschriftsanforderung gleich mit. Sobald S/4 die Ersatzlieferung bestätigt, geht die Info aus dem Fall an den Kunden. Ein Vorgang, eine Nummer, kein Suchen.

Was sich im Projekt bewährt hat

Die Fallkategorien klein halten. Die Versuchung ist gross, zum Go-Live einen Kategorienbaum mit vierzig Ästen zu bauen, für jeden denkbaren Fall einen. Das Ergebnis: Agenten wählen irgendwas, das Reporting wird wertlos. Unsere Regel: fünf bis acht Kategorien zum Start, nach drei Monaten anhand der echten Fälle nachschärfen. Die Daten zeigen dann selbst, wo es feinere Äste braucht.

Telefonie anbinden. Im B2B-Service ist das Telefon weiterhin der stärkste Kanal. Eine CTI-Integration, die den Anrufer identifiziert und dem Agenten beim Klingeln den Kundenkontext aufblendet, spart pro Anruf die erste Minute und die lästige Frage nach der Kundennummer. Wir haben solche CTI-Adapter für Service Cloud V2 mehrfach gebaut; der Aufwand ist überschaubar, der Effekt im Alltag gross.

Und was man besser lässt: Erstens, die ERP-Statuslogik im CRM nachbauen. Der Fall braucht keinen Zwilling jedes S/4-Belegstatus, er braucht die Antwort auf die Kundenfrage: in Arbeit, unterwegs, erledigt. Wer jeden Belegfluss spiegelt, wartet ab dann zwei Statusmodelle. Zweitens, Produkthierarchien doppelt pflegen. Die Hierarchie hat einen Ort, das ERP, und wird von dort repliziert. Zwei handgepflegte Hierarchien laufen garantiert auseinander, die Frage ist nur wann.

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.

Häufige Fragen

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; das ist ein anderer Anwendungsfall.

Können Servicetechniker im Aussendienst damit arbeiten?

Ja, für einfache Einsätze direkt mit dem Fall und dem S/4-Serviceauftrag. Wird die Einsatzplanung anspruchsvoll, mit Schichten, Skills und Routenoptimierung, ist SAP Field Service Management die richtige Ergänzung: Der Fall bleibt in Service Cloud V2, die Disposition läuft in FSM. Die Brücke dazwischen ist Standard.

Welcher Aufwand ist realistisch?

Wenn die Stammdatenintegration steht, also Accounts und Equipment bereits repliziert werden, reden wir für den Case-to-Resolution-Fluss über Wochen, nicht Monate. Die Standardintegration über die SAP Integration Suite deckt die Belegflüsse ab. Teuer wird es nur, wenn die Stammdaten fehlen oder jemand Sonderlocken in die Statuslogik baut.

Ihre Reklamationen leben im Sammelpostfach und Ihr Service sucht Lieferstatus im ERP zusammen? Wir zeigen Ihnen den Ablauf gern live, mit Ihren Serviceprozessen. Sprechen Sie mit uns.