Quote-to-Cash zwischen SAP Sales Cloud V2 und S/4HANA Public Cloud: wer besitzt welchen Beleg?

Wenn ein CRM und ein ERP denselben Verkaufsprozess tragen, entscheidet eine einzige Frage darüber, ob die Integration Jahre hält oder zur Dauerbaustelle wird: Wer besitzt welchen Beleg? Nicht welche Schnittstelle man nimmt, nicht welches Mapping-Tool. Sondern: In welchem System entsteht ein Angebot, wo entsteht der Auftrag, und wer darf was ändern? Aus Projekterfahrung können wir sagen: Fast jede zähe Quote-to-Cash-Integration, die wir sanieren durften, hatte am Anfang keine klare Antwort auf diese Frage.

Für die Kombination SAP Sales Cloud V2 und S/4HANA Public Cloud gibt es eine saubere Antwort. Sie steht in keinem einzelnen SAP-Dokument, aber sie ergibt sich aus dem Standard, wenn man ihn konsequent liest. Hier ist sie, inklusive der Stellen, an denen wir uns in Projekten schon die Finger verbrannt haben.

Die Besitzmatrix: ein Objekt, ein führendes System

Die Grundregel ist einfach: Jedes Objekt hat genau ein führendes System. Dort wird es angelegt und geändert. Überall sonst ist es eine Kopie, und Kopien sind nur lesbar.

Das Angebot wird im CRM geboren, weil dort der Vertrieb lebt: Opportunity, Kontakthistorie, Aktivitäten, alles in einem Bild. Der Kundenauftrag wird in S/4HANA geboren, weil dort Verfügbarkeit, Kreditlimit, Logistik und Faktura hängen. Der Übergang vom einen zum anderen läuft als Folgebeleg über die Standard-iFlows der SAP Integration Suite. Und die Rückrichtung: Der Auftrag erscheint im CRM als replizierter Beleg, den der Vertrieb sieht, aber nicht anfasst.

Diese Matrix gehört an die Wand des Projektraums, bevor der erste iFlow deployed wird. De facto ist sie wichtiger als jedes technische Designdokument.

External Pricing: eine Preiswahrheit, nicht zwei

Der eleganteste Teil dieser Architektur ist der, der gar nicht repliziert: die Preisfindung. Das CRM-Angebot ruft die S/4HANA-Preisfindung live auf. Konditionen, kundenspezifische Preise, Staffeln, Rabatte: alles kommt in dem Moment aus dem ERP, in dem der Vertriebsmitarbeiter die Position erfasst.

Warum das zählt: Sobald Preise in zwei Systemen gepflegt werden, gibt es zwei Preiswahrheiten, und irgendwann offeriert jemand mit der falschen. Mit External Pricing existiert genau eine Konditionspflege, im ERP, und das Angebot im CRM rechnet mit denselben Zahlen wie später der Auftrag und die Rechnung. Keine nächtlichen Preisreplikationen, kein Abgleichsjob, kein Erklärungsbedarf beim Kunden, warum Angebot und Rechnung nicht zusammenpassen.

Zwei Stolpersteine aus der Praxis

Die Architektur oben klingt aufgeräumt, und sie ist es auch. Gescheitert sind Projekte in unserer Erfahrung nicht an der Technik, sondern an zwei fachlichen Details, die niemand vor dem Integrationsbau geklärt hatte.

Stolperstein 1: Der Gewonnen/Verloren-Status lebte auf zwei Ebenen. In einem unserer Projekte führte das ERP den Angebotsstatus auf Kopfebene: ein Angebot ist gewonnen oder verloren, fertig. Das CRM führte denselben Status pro Position, weil ein Kunde ja drei von fünf Positionen bestellen kann. Beides ist vertretbar. Beides gleichzeitig ist Gift: Die Win-Rate-Auswertung im CRM zählte Positionen, das ERP-Reporting zählte Köpfe, und das Management bekam zwei Wahrheiten präsentiert, die um zweistellige Prozentpunkte auseinanderlagen. Die Lehre: Die Statusebene wird einmal definiert, identisch auf beiden Seiten, und zwar bevor der erste Integrationsbaustein gebaut wird. Nachträglich kostet dieselbe Entscheidung ein Vielfaches.

Stolperstein 2: Ablehnungsgründe als Freitext. Warum wurde ein Angebot verloren? Wenn die Antwort ein Freitextfeld ist, bekommt man »Preis«, »zu teuer«, »Preis zu hoch«, »Konkurrenz billiger« und vierzig weitere Varianten desselben Grundes. Damit stirbt jedes Reporting, bevor es beginnt. Ablehnungsgründe gehören in eine bewirtschaftete Werteliste, die auf beiden Seiten identisch gemappt ist und einen Eigentümer hat, der neue Werte freigibt. Das ist eine Stunde Governance-Arbeit im Konzept und erspart Jahre an unbrauchbaren Auswertungen.

Monitoring: wer repariert was

Replikation heisst asynchrone Nachrichten, und asynchrone Nachrichten schlagen irgendwann fehl. Ein Kunde ohne gültige Umsatzsteuernummer, ein gesperrtes Produkt, ein Mapping-Wert, den es auf der Zielseite nicht gibt. Das ist normal. Nicht normal ist, wenn es niemand merkt.

Das Message Monitoring der Integration Suite zeigt jede fehlgeschlagene Nachricht mit Payload und Fehlergrund. Darauf gehört ein Alerting, das nicht in einem Sammelpostfach verstaubt, sondern eine benannte Person erreicht. Und dann die Zuständigkeitsfrage, die man nota bene vor dem Go-Live klärt: Der CRM-Administrator behebt, was im CRM entsteht, also Angebotsdaten, fehlende Pflichtfelder, Werteliste-Mappings auf CRM-Seite. Der ERP-Key-User behebt, was im ERP wurzelt, also Stammdatenfehler, Konditionsprobleme, gesperrte Business Partner. Wer diese Trennung nicht definiert, bekommt das bekannte Ping-Pong: Jede fehlgeschlagene Nachricht wandert dreimal zwischen zwei Teams hin und her, bevor sie jemand anfasst.

Die eine Regel, die alles zusammenhält

Wenn Sie aus diesem Artikel einen Satz mitnehmen, dann diesen: Derselbe Belegtyp darf niemals in zwei Systemen editierbar sein. Sobald ein Auftrag im CRM und im ERP änderbar ist, beginnt der Wettlauf der Versionen, und die Integration verkommt zum Schiedsrichter, der nur verlieren kann. Die Standardintegration von SAP erzwingt diese Regel grösstenteils von selbst, replizierte Belege sind drüben nur lesbar. Widerstehen Sie jeder Anforderung, das per Erweiterung aufzuweichen. Jede Ausnahme, die heute bequem wirkt, ist der Datenabgleich-Workshop von übermorgen.

Häufige Fragen

Können Aufträge auch direkt im CRM angelegt werden?

Technisch ja, Sales Cloud V2 kennt den Kundenauftrag als Objekt. Das saubere Muster bleibt trotzdem: Angebot im CRM, Auftrag im ERP. Der Auftrag braucht Verfügbarkeitsprüfung, Kreditlimit und Logistikdaten, und die leben in S/4HANA. Ein im CRM erfasster Auftrag ist im besten Fall eine Vorerfassung, die im ERP nochmals geprüft wird, und damit ein zweiter Pflegeort mehr.

Werden Angebote aus S/4HANA Public Cloud zurück ins CRM repliziert?

Nein. Die Angebots-Replikation aus S/4HANA Public Cloud ins CRM wird im Standard nicht unterstützt. Wer Angebote im ERP anlegt, sieht sie im CRM nicht. Auch deshalb gilt: Angebote entstehen im CRM, dann bleibt die Sicht des Vertriebs vollständig.

Was ist mit dem Aussendienst ohne Netzabdeckung?

External Pricing braucht eine Verbindung zum ERP. Offline kann der Aussendienst Positionen und Mengen erfassen; die verbindliche Preisfindung läuft, sobald das Gerät wieder online ist. Für den Kundentermin selbst hat sich ein Richtpreis auf dem replizierten Produktstamm bewährt, klar als unverbindlich gekennzeichnet, verbindlich wird es mit der Synchronisation.

Was passiert, wenn eine Replikation fehlschlägt?

Die Nachricht bleibt im Message Monitoring der Integration Suite stehen, mit Payload und Fehlergrund, und kann nach der Korrektur erneut verarbeitet werden. Entscheidend ist das Alerting und die vorab definierte Zuständigkeit: CRM-Admin für CRM-seitige Ursachen, ERP-Key-User für Stammdaten- und Konditionsfehler. Dann ist so ein Fehler eine Sache von Minuten, nicht von Wochen.

Sie planen die Integration von Sales Cloud V2 und S/4HANA Public Cloud, oder Ihre bestehende produziert zwei Wahrheiten? Wir bringen die Besitzmatrix gern mit Ihnen an die Wand. Sprechen Sie mit uns.