Salesforce- und SAP-Integrationsmuster fuer Hersteller

Kurze Antwort: Fast jede Salesforce- und SAP-Integration in der Fertigung laesst sich auf vier Muster reduzieren: Batch-Synchronisation, Request and Reply, Datenvirtualisierung und Event-Streaming. Waehlen Sie eines pro Datenobjekt, und entscheiden Sie nur anhand von zwei Fragen: Welches System besitzt den Datensatz, und wie veraltet darf eine Kopie sein? Die Middleware folgt aus diesen Antworten, nicht umgekehrt.

Wir haben diese Entscheidung fuer Auftrags-, Produkt- und Servicedaten bei anlagenintensiven Herstellern getroffen. Projekte, die scheitern, scheitern fast nie an der falschen iPaaS. Sie scheitern, weil niemand aufgeschrieben hat, wem der Datensatz gehoert.

Was ist ein Salesforce- und SAP-Integrationsmuster?

Ein Integrationsmuster ist die Form eines Datenflusses, unabhaengig vom Werkzeug, das ihn traegt. Die Architekturleitlinien von Salesforce nennen eine kleine Menge: batch data synchronization, remote process invocation (request and reply oder fire and forget), remote call-in, UI update based on data changes und data virtualization. Jeder Konnektor, Adapter und jede iPaaS am Markt ist eines dieser Muster mit einem Logo darauf. Das Muster zu waehlen ist Architektur. Das Produkt zu waehlen ist Einkauf.

Welche SAP-Daten muessen bei einem Hersteller wirklich fliessen?

Drei Familien decken das meiste ab, und sie brauchen nicht dieselbe Behandlung.

• Auftragsdaten. Angebote und Opportunities entstehen in Salesforce, doch SAP besitzt den Auftrag, sobald er bestaetigt ist. Der Vertrieb braucht bestaetigte Menge, zugesagtes Datum und Status zurueck.
• Produkt-, Preis- und Bestandsdaten. SAP besitzt Materialstamm, Konditionen und Bestand. Salesforce ist hier Konsument, nie Autor.
• Service- und Anlagendaten. Hier teilt sich die Zustaendigkeit wirklich. SAP haelt Seriennummern, Stuecklisten und Garantiebedingungen; Salesforce haelt den Case, das Entitlement und den Aussendiensteinsatz.

Schreiben Sie den Eigentuemer neben jedes Objekt, bevor Sie ein einziges Werkzeug bewerten. Wenn zwei Systeme dasselbe Feld schreiben duerfen, haben Sie keine Integration entworfen. Sie haben einen Konflikt mit Zeitplan entworfen.

Welche vier Muster lohnen die Betrachtung?

Batch-Synchronisation

Ein geplanter Massentransfer, meist nachts. Geeignet fuer Materialstamm, Kostendaten, abgeschlossene Auftraege und historische Istwerte. Guenstig, nachvollziehbar und nach einem Fehler leicht erneut abspielbar. Der Preis ist Veralterung in Stunden und ein Nachtfenster, das mit wachsendem Volumen immer enger wird.

Request and Reply

Salesforce ruft SAP auf und wartet auf die Antwort: Verfuegbarkeitspruefung, Kreditpruefung, Preissimulation, Auftragsanlage. Geeignet, wenn die Nutzerin die Wahrheit genau in dieser Sekunde braucht und eine Kopie schlimmer waere als ein kurzer Ladeindikator. Der Preis: Die Verfuegbarkeit von SAP wird zur Verfuegbarkeit des CRM, und jeder Timeout ist ein Vertriebsgespraech.

Datenvirtualisierung

Salesforce Connect stellt SAP-Daten ueber OData 2.0 oder 4.0 als External Objects bereit, ueblicherweise ueber ein SAP-Gateway, sodass Datensaetze live gelesen und nie in Salesforce gespeichert werden. Geeignet fuer Referenzdaten im Long Tail, die man nachschlaegt, ueber die aber niemand berichtet: alte Rechnungen, Lieferbelege, abgeschlossene Serviceauftraege. Der Preis: schwaches Reporting, schwache Automatisierung und nichts offline.

Event-Streaming

SAP veroeffentlicht eine Aenderung und Salesforce reagiert: Lieferung bestaetigt, Charge freigegeben, Sendung gesperrt, Anlage in Betrieb genommen. Geeignet fuer Zustandswechsel, bei denen Minuten zaehlen und das Volumen Polling verbietet. Der Preis: Reihenfolge, Wiederholungen und Duplikate liegen nun bei Ihnen.

Wie waehlen Sie? Datenhoheit und Latenz, nicht die Middleware-Marke

1. Benennen Sie den Eigentuemer pro Objekt. Ein Schreiber, alle anderen lesen. Ins Designdokument, nicht in jemandes Kopf.
2. Setzen Sie ein Latenzbudget in Klartext. "Ein Vertriebler darf nie ein Datum zusagen, das das Werk nicht halten kann" ist ein Budget. "Echtzeit" ist kein Budget, sondern ein Wunsch.
3. Zaehlen Sie das Volumen ehrlich. Spitzen, nicht Durchschnitte. Ein Event-Muster, das bei tausend Nachrichten pro Tag bequem ist, verhaelt sich bei einer Million pro Woche anders.
4. Entscheiden Sie das Fehlerverhalten vor dem Happy Path. Was sieht ein Vertriebler, wenn SAP waehrend des Quartalsabschlusses nicht erreichbar ist? Schweigen ist die schlechteste Antwort.

Gehen Sie diese vier Schritte durch, und das Muster waehlt sich meist selbst. Die meisten Hersteller landen hybrid: Batch fuer Stammdaten, Events fuer Auftrags- und Lieferstatus, Request and Reply fuer die zwei oder drei Pruefungen, die live sein muessen, und Virtualisierung fuer das Archiv, das niemand kopieren will.

Wo laufen Hersteller in die Falle?

• Alles synchronisieren. Jedes kopierte Feld ist ein Feld, das Sie fuer immer abgleichen. Kopieren Sie, was ein Salesforce-Prozess wirklich nutzt.
• Keine stabile ID-Zuordnung. Ein Abgleich ueber Kundennamen oder Materialkurztext funktioniert in der Demo und faellt in Produktion um. Fuehren Sie den SAP-Schluessel als External ID mit.
• Nicht idempotente Auftragsbuchung. Eine Wiederholung, die einen zweiten Auftrag in SAP anlegt, ist der teuerste Fehler dieser Kategorie. Jeder Schreibvorgang braucht einen Korrelationsschluessel.
• Kein Abgleichjob. Drift ist keine Moeglichkeit, sondern eine Gewissheit. Etwas muss beide Seiten zaehlen und die Differenz melden.
• Zuerst Middleware kaufen. Dann diktiert das Werkzeug die Architektur, und die Architektur erbt genau das, worin dieses Werkzeug zufaellig gut ist.

Spielt die Middleware-Marke ueberhaupt eine Rolle?

Ja, an zweiter Stelle. Salesforce liefert MuleSoft-Direct-Integrationen fuer Manufacturing Cloud, die Kunden-, Produkt- und Auftragsdaten mit SAP synchron halten. Data 360 bietet einen SAP-HANA-Konnektor, bei dem die Batch-Ingestion allgemein verfuegbar ist, waehrend Zero Copy Federation noch Beta ist, was man wissen sollte, bevor man darauf eine Analytikschicht plant. SAP Integration Suite, Boomi und direkte API-Entwicklung bleiben alle valide. Jedes davon ist ein Muster in verpackter Form. Waehlen Sie zuerst das Muster, dann das Produkt, das es mit dem geringsten selbst gepflegten Code umsetzt.

Der Nutzen ist operativ, nicht kosmetisch. In einem Connected-Asset-Programm fuer ASSA ABLOY haben wir die woechentlichen Cases von 3.000 auf 350 gesenkt, eine Reduktion um 93% ueber 11.000 Geraete und bis zu 2,5 Millionen Events pro Woche, ohne zusaetzliches Supportpersonal. Moeglich war das, weil das Eventvolumen nach Muster geroutet und nicht durch eine generische Synchronisation gedrueckt wurde. Tekunda integriert Salesforce mit ueber 70 Unternehmenssystemen, SAP eingeschlossen, als zertifizierter Salesforce SI, ISV und PDO.

FAQ

Sollte Salesforce oder SAP den Kundenauftrag besitzen?

SAP, ab der Bestaetigung. Salesforce sollte Angebot und Opportunity besitzen und danach den Auftragsstatus zurueklesen, damit es genau einen Ort gibt, an dem ein bestaetigter Auftrag lebt.

Ist Echtzeit-Integration immer besser?

Nein. Echtzeit erhoeht Kosten, Kopplung und Fehleroberflaeche. Setzen Sie sie nur ein, wo ein veralteter Wert zu einer falschen Zusage an Kunden fuehren wuerde, und nutzen Sie sonst Batch.

Brauchen wir MuleSoft, um Salesforce und SAP zu verbinden?

Nein. MuleSoft passt gut zu API-led-Programmen mit vielen Konsumenten, aber dieselben Muster laufen auf SAP Integration Suite, anderen iPaaS-Plattformen oder direkter API-Entwicklung.

Wie lange dauert eine Salesforce- und SAP-Integration?

Das haengt weit mehr davon ab, wie viele Objekte Sie synchronisieren, als von den Werkzeugen. Zwei oder drei klar zugeordnete Objekte gehen in Wochen live; ein ungeklaertes Eigentuemermodell blockiert ein Projekt ein Jahr.