Manufacturing Cloud: ERP-Anbindung, KI und Rollout

Nach dem Funktionsdesign entscheiden drei Fragen über ein Manufacturing-Cloud-Projekt: welches System welche Daten führt, wo Agentforce wirklich Arbeit abnimmt und in welcher Reihenfolge die Länder live gehen. SAP bleibt führend für Accounts, Produkte, Aufträge und meist auch Preise. Die Manufacturing Cloud bekommt Ist-Mengen täglich und schickt freigegebene Boni und Garantiebeträge als Gutschrift zurück. Agentforce lohnt sich zuerst bei lesenden Prozessen mit hohem Volumen und einer API zum ERP. Der Rollout beginnt mit einem großen Land mit angemessener Komplexität, alle Länder arbeiten zu mindestens 80 Prozent gleich. Und keine Schnittstelle sollte sich nach dem 1. Dezember 2026 noch ungeprüft per SOAP login() anmelden.

Welches System führt welches Objekt?

Bevor jemand eine Schnittstelle baut, braucht jedes Objekt ein führendes System und eine verantwortliche Person. Die Manufacturing Cloud erzeugt die meisten ihrer Zahlen nicht selbst. Ein Sales Agreement aus Kapitel 2 vergleicht Plan und Ist, und das Ist entsteht in SAP. Bei Boni und Garantie aus Kapitel 3 und Kapitel 4 läuft es andersherum: Salesforce gibt frei, SAP zahlt.

So würde ich die Verantwortung bei einem typischen Hersteller mit SAP aufteilen:

Daten	Führendes System	Wofür Salesforce sie braucht
Accounts und Account-Hierarchie	SAP	Sales Agreements, Prognosen, Portal
Produkte und Produkthierarchie	SAP	Sales Agreements, Boni, Garantie
Preise und Konditionen	SAP, außer Sie entscheiden bewusst anders	Telesales, Händlerangebote
Aufträge oder Auftragssummen	SAP	Ist-Mengen, Auftragsstatus
Lagerbestand	SAP	Kennzahl neben dem Rückstand
Sales Agreements, Prognosen, Ziele	Salesforce	Planung im Vertrieb
Freigegebene Boni und Garantiebeträge	Salesforce, gezahlt in SAP	Gutschrift an den Händler

Für Objekte innerhalb der Org nutze ich die Object Ownership Matrix. Für ERP-Schnittstellen ergänze ich zwei Spalten, Richtung und Takt. Die häufigste Lücke liegt in der Account-Hierarchie: Liegt der Auftraggeber aus SAP nicht auf derselben Ebene wie der Account mit dem Sales Agreement, braucht es eine Zuordnungstabelle, und auch die braucht einen Verantwortlichen.

Datenflüsse zwischen SAP und der Manufacturing Cloud

Nach Salesforce fließen Stammdaten und Ist-Mengen, zurück fließt Geld. Den Takt bestimmt die Frage, die die Daten beantworten. Sales Agreements laufen über Monate, für ihre Ist-Mengen reicht ein täglicher Lauf. Ein Händler, der nach seinem Auftrag fragt, will den Stand von heute; diesen Status frage ich live in SAP ab, statt ihn zu kopieren, wie in Agentforce und SAP: Auftragsstatus über MuleSoft. Alle Flüsse mit Richtung und Takt stehen in Manufacturing Cloud und SAP: welche Daten wohin.

Der MuleSoft Accelerator for Manufacturing (öffnet in einem neuen Tab) liefert Vorlagen für zwei dieser Flüsse: den Abgleich von Accounts, Produkten und Aufträgen aus SAP S/4HANA und Gutschriften für freigegebene Bonusauszahlungen. Sales Agreements legt er nicht an, einen Garantiefluss nennt er nicht. Salesforce führt MuleSoft auf der Seite mit den Add-ons (öffnet in einem neuen Tab) nur mit “Request a quote”. Läuft MuleSoft bei Ihnen schon, sparen die Vorlagen Designzeit. Nur dafür zu kaufen, lohnt sich selten.

Für verspätete Aufträge und Korrekturen gibt es die Aktion Refresh Actuals Calculation (öffnet in einem neuen Tab). Sie ist seit API-Version 47.0 verfügbar und berechnet die Ist-Mengen eines Sales Agreements für den aktuellen, vergangene oder künftige Zeiträume neu. Bucht SAP eine Retoure für den Vormonat, ruft die Middleware sie für die betroffenen Agreements auf. Sonst rufen Account Manager Kunden wegen eines Rückstands an, den es nicht mehr gibt.

Wie dieselbe Frage für einen B2B-Shop aussieht, beschreibt das Kapitel ERP-Anbindung der Masterclass B2B Commerce. Beim Design solcher Schnittstellen unterstütze ich unter Salesforce-Schnittstellen.

Welche Login-Fristen gelten für ERP-Schnittstellen?

Viele ERP-Schnittstellen melden sich noch mit technischem Nutzer und Passwort an. Laut dem Developer Guide zu Winter ’27 (öffnet in einem neuen Tab) gelten diese Fristen:

1. 01.12.2026 · nächster TerminWer sich per SOAP API login() anmeldet, braucht die Berechtigung Use Any API Auth, sonst gibt es einen Fehler
2. Summer '27SOAP login() entfällt in den API-Versionen 31.0 bis 64.0
3. Summer '27SOAP-, REST- und Bulk-API 31.0 bis 40.0 bekommen keine Korrekturen mehr
4. Summer '28Aufrufe an SOAP-, REST- und Bulk-API 31.0 bis 40.0 schlagen fehl

Ein Ist-Mengen-Lauf, der still ausfällt, ist das Risiko dabei: Der Vertrieb sieht einen alten Rückstand und glaubt ihm. Wie Sie betroffene Schnittstellen finden, steht in Salesforce-Passwort-Integrationen enden 2027.

Wer führt die Preise: SAP oder Penny Perfect Pricing?

Mit Winter ’27, allgemein verfügbar seit 12. Oktober 2026 (öffnet in einem neuen Tab), bietet Salesforce eine eigene Preisfindung für Aufträge an. Penny Perfect Pricing berechnet laut Developer Guide (öffnet in einem neuen Tab) Preise für Positionen von Advanced Orders, also für den Telesales-Bestellablauf, und beschreibt 19 Objekte ab API-Version 68.0. Kalkulationsschema, Suchstrategien und Konditionssätze mit Staffeln erinnern stark an die SAP-Konditionstechnik.

Die Grenzen bleiben wie in den anderen Kapiteln: Angebote mit Konfigurator gehören zu Revenue Cloud, siehe Katalog, Konfigurator, Preise, und Shoppreise zu B2B Commerce, siehe Preise, Warenkorb, Checkout.

Wann lohnt sich Agentforce für Hersteller?

Wenn ein Prozess die Kriterien erfüllt, die ich in Agentforce für Hersteller: jetzt starten oder warten? beschreibe: genug Volumen, tragfähige Daten, Zugriff auf das ERP per API, ein passendes Kostenmodell und eine Edition, die dazu passt. Händleranfragen zu Auftragsstatus und Lieferterminen erfüllen sie oft. Eine Garantie-Vorprüfung, bei der in der installierten Basis der Garantiebeginn fehlt, erfüllt sie nicht.

Für die Kosten zählen zwei Zahlen. Eine Standard- oder Custom-Aktion kostet laut Flex Credits Rate Card (öffnet in einem neuen Tab) 20 Flex Credits, bei 500 € je 100.000 Credits (öffnet in einem neuen Tab) also 0,10 €. Und die Edition bestimmt den Pool: Laut Preisseite der Manufacturing Cloud (öffnet in einem neuen Tab) enthalten die Core-Editionen 500.000 Flex Credits pro Org und Jahr, die Max-Editionen 2,75 Millionen und als einzige die volle Agentforce-for-Industries-Ausstattung. Zu Core gibt es das Agentforce for Manufacturing Cloud Add-on: Die Add-on-Seite nennt 150 $ pro Nutzer und Monat, die Preisseite “from $ 150 login/month”. Lassen Sie sich die Einheit schriftlich bestätigen. Wie Sie Credits pro Aktion schätzen, steht im Kapitel Kosten und Token der KI-Masterclass.

20

Flex Credits kostet eine Standard- oder Custom-Aktion, also 0,10 €

500.000

Flex Credits pro Org und Jahr in den Core-Editionen

2,75 Mio.

Flex Credits pro Org und Jahr in den Max-Editionen

Die sichtbarste Industriereferenz zeigt, wo man anfängt. In der Meldung von Siemens und Salesforce (öffnet in einem neuen Tab) vom 15. September 2026 sind zwei Agenten für eingehende Leads live, für 18.000 Vertriebsmitarbeitende in 132 Ländern. Teamcenter-Antworten für den Service und das Lieferanten-Onboarding in SAP stehen im Futur. In Siemens und Agentforce: Lehren für den Mittelstand leite ich daraus eine Reihenfolge ab: erst nur lesen bei hohem Volumen, dann aus dem ERP lesen, dann Antworten aus PLM und Seriennummern, schreibende Schritte ins ERP zuletzt. Welche Agenten es für Vertrieb, Service und Garantie heute gibt, zeigt das Kapitel KI-Agenten in der Fertigung.

Ein Agent für Händler in vielen Sprachen

Für Exporteure mit Händlern in vielen Ländern ist die Sprache eine eigene Planungsfrage. Salesforce unterscheidet bei Agentforce zwischen allgemein verfügbaren Sprachen und Beta-Sprachen, und laut dem Leitfaden zur Mehrsprachigkeit (öffnet in einem neuen Tab) liegt die Qualitätssicherung bei Beta-Sprachen beim Kunden. Prüfen Sie jede Händlersprache gegen die aktuelle Liste, denn Salesforce ändert sie laufend. Die Übersetzung selbst ist günstig: Die Rate Card nennt 4.000 Flex Credits pro Million übersetzter Zeichen, zum Listenpreis also 20 €.

Teurer ist das Wissen. Laut demselben Leitfaden filtert der Retriever Wissensartikel heraus, deren Sprache nicht zur Sitzungssprache passt, ein italienischer Händler findet also nur italienische Artikel. Wer das nicht will, baut einen eigenen Retriever ohne Sprachfilter. Ich würde Wissen in ein oder zwei Sprachen pflegen, Sicherheits- und Gewährleistungsinhalte pro Land halten und jede freigegebene Sprache vor dem Go-live mit echten Händlerfragen testen. Rechenbeispiel und Aufteilung stehen in Mehrsprachige Agentforce-Agenten für Händler im Export. Im Rollout wird die Sprache eine Spalte in der Ländertabelle.

In welcher Reihenfolge rollt man Manufacturing Cloud weltweit aus?

Zuerst steht das Ziel fest, meistens die Harmonisierung von Prozessen. Daraus folgt ein globales Template mit den Entscheidungen, die sich nach dem ersten Land kaum noch ändern lassen: die Account-Ebene der Sales Agreements, die Regel, wann eine Konfiguration ein eigenes Produkt wird, und was Kunden und Händler im Portal sehen. In Manufacturing Cloud weltweit ausrollen beschreibe ich die Regeln, die ich daraus ableite:

Regel	Was sie bedeutet
Erstes Land	groß, mit angemessener Komplexität. Ein kleines Pilotland bestätigt ein Template, das später am ersten großen Land scheitert.
Große Region früh	Eine der größten Regionen kommt in die ersten zwei Phasen, damit das Template unter echter Last steht, solange Änderungen noch günstig sind.
Reihenfolge danach	eine Tabelle mit einer Zeile pro Land und Spalten für Prozesse, Business Units, IT-Landschaft und Marken. Für die Manufacturing Cloud ergänze ich zwei Spalten: eigenes ERP oder gemeinsames, und Händlersprachen.
80 Prozent gleich	Rechtliche Vorgaben sind gesetzt, jede andere lokale Anforderung wird begründet und von einer Stelle auf Kundenseite entschieden.
Change Management	Key User, Kommunikation vor dem Go-live und ein Blick auf die Nutzung danach, in jedem Land.

Die ERP-Spalte hat das meiste Gewicht. Ein Land mit eigenem SAP-System oder eigener Middleware braucht neue Schnittstellen für Ist-Mengen, Boni und Garantie. Teilt es das ERP mit einem schon eingeführten Land, ist der Weg kürzer. Wie ich einen Fahrplan mit Phasen und Freigaben aufbaue, steht im Kapitel Einführung und Fahrplan der DevOps-Masterclass, die Arbeit mit den Menschen in den Ländern unter Change Management für Salesforce-Programme.

Nach jedem Salesforce-Release neu testen

Salesforce bringt drei Releases im Jahr, und Preview-Sandboxes bekommen jedes davon vor der Produktion. Wie Sie das mit dem eigenen Release-Kalender abstimmen, beschreibt das Kapitel Release-Planung der DevOps-Masterclass. In einer Manufacturing-Cloud-Org gehören vor allem die Teile in den Regressionstest, die Zahlen erzeugen:

Was	Warum es nach jedem Release getestet wird
Forecast Sets	Sie sind Metadaten vom Typ AdvAccountForecastSet (öffnet in einem neuen Tab), seit API-Version 53.0, und legen die Prognosekonfiguration pro Geschäftsbereich fest.
Definitionen der Data Processing Engine	Sie rechnen Ist-Mengen, Prognosen und Boni zusammen; Salesforce führt sie als BatchCalcJobDefinition (öffnet in einem neuen Tab).
Expression Sets der Business Rules Engine	Der Metadatentyp heißt ExpressionSetDefinition (öffnet in einem neuen Tab); in vielen Orgs stecken darin Garantie- und Bonusregeln.
ERP-Schnittstellen	Jede neue API-Version ist ein Anlass, die API-Versionen Ihrer Schnittstellen gegen die Fristen oben zu prüfen.

Mein Test pro Release ist bewusst klein: eine Neugenerierung der Prognose, eine Neuberechnung der Ist-Mengen für drei Sales Agreements, ein Garantieanspruch durch das Expression Set und ein Bonuslauf für einen Zeitraum, jeweils in der Preview-Sandbox und verglichen mit Produktion. Weicht eine Zahl ab, wissen Sie es vor Ihren Account Managern. Damit diese Definitionen zwischen Orgs wandern wie jede andere Konfiguration, gehören sie ins Repository, wie im Kapitel Daten und Konfiguration beschrieben.

Erster Schritt: die Objektliste mit dem SAP-Team abstimmen

Stimmen Sie mit dem SAP-Team ab, welches System welches Objekt führt, bevor die erste Schnittstelle gebaut wird, und legen Sie das Template im ersten großen Land fest, bevor das zweite Land plant. Dieses Kapitel schließt die Masterclass ab. Es setzt die Entscheidungen aus Business Case, Rahmenverträgen, Händlerkanal und Garantie voraus und klärt, was sie im Betrieb und in vielen Ländern brauchen. Davor kam Kapitel 4 zu Garantie und After-Sales, alle fünf Kapitel finden Sie auf der Übersichtsseite.