Wer im Maschinenbau seinen Service auf Salesforce aufsetzt, stößt früh auf dieselbe Frage: Manufacturing Cloud oder Service Cloud? Beide tragen „Cloud“ im Namen und laufen auf derselben Plattform, lösen im Alltag aber unterschiedliche Aufgaben. Wer sie verwechselt, baut den Servicebetrieb auf einem Werkzeug auf, das für einen anderen Zweck gedacht ist.
Kurz vorab, damit die Richtung klar ist:
- Manufacturing Cloud hilft dabei, das kommerzielle Geschäft mit Herstellern und Händlern zu steuern: Accounts, Absatzprognosen, Rahmenverträge, Rabattlogik.
- Service Cloud und Field Service tragen den operativen Service: Störungen aufnehmen, Fälle bearbeiten, Techniker disponieren, Ersatzteile abwickeln.
- Die eigentliche Entscheidung liegt eine Ebene tiefer: bei der Domänenschicht – der strukturierten installierten Basis, Servicehistorie und dem Fehlercode je Baureihe, die aus generischen Objekten einen belastbaren Serviceprozess machen.
Für Sie als IT-Leiter, Business Analyst oder Serviceleiter geht es also um zwei Fragen nacheinander: Welche Salesforce-Basis passt zu welcher Aufgabe? Und welche Daten braucht diese Basis, damit sie im Service tatsächlich trägt?
Zwei Salesforce-Produkte, zwei unterschiedliche Aufgaben
Manufacturing Cloud und Service Cloud stehen selten im direkten Wettbewerb. Sie decken verschiedene Teile der Wertschöpfung ab. Die Verwechslung entsteht meist dort, wo ein Hersteller ohnehin schon Manufacturing Cloud im Einsatz hat und prüft, ob sie „den Service gleich mitmacht“.
Wofür Manufacturing Cloud gebaut ist
Manufacturing Cloud ist auf die kommerzielle Steuerung ausgerichtet. Ihre Stärke liegt in der Planbarkeit von Nachfrage und Umsatz: Account-Planung, Absatzprognosen über Vertriebs- und Betriebsdaten hinweg, Rahmenverträge und Rabattkonditionen. Für Vertrieb und Sales-Operations ist das ein sinnvolles Fundament, weil es das Geschäft mit dem Kunden über die Zeit greifbar macht.
Im Servicebetrieb endet dieser Nutzen allerdings dort, wo es konkret wird. Eine Störungsmeldung, ein Technikereinsatz mit Disposition oder ein Ersatzteilfall mit Bezug zur verbauten Konfiguration gehören nicht zum Kern von Manufacturing Cloud. Das ist kein Mangel des Produkts, sondern eine Frage des Einsatzzwecks.
Was den operativen Service trägt: Service Cloud und Field Service
Der Servicebetrieb läuft über Service Cloud und Field Service. Hier entsteht die durchgängige Fallbearbeitung: Ein Case nimmt die Störung auf, eine Work Order steuert den Einsatz, die Disposition bringt den passenden Techniker mit dem richtigen Ersatzteil zur Anlage, und SLAs machen Zusagen messbar. Für eine Serviceorganisation mit vielen Anlagen im Feld und hohem Einsatzvolumen ist das die tragende Schicht.
Innerhalb des Servicebetriebs teilen sich die beiden Bausteine die Aufgaben klar auf:
| Serviceprozess | Service Cloud | Field Service |
|---|---|---|
| Störungsmeldung (E-Mail, Telefon, Portal) | Primär | – |
| SLA-Überwachung und Eskalation | Primär | – |
| Garantie- und Anspruchsprüfung | Primär | – |
| Techniker-Disposition nach Qualifikation | – | Primär |
| Mobile Einsatzdokumentation (auch offline) | – | Primär |
| Ersatzteilidentifikation vor Ort | Sekundär (Anfrage) | Primär (vor Ort) |
Damit ist die Produktfrage im Grundsatz beantwortet: Für das Verkaufen an Hersteller ist Manufacturing Cloud der richtige Ort, für den Servicebetrieb Service Cloud und Field Service. Nur greift diese Antwort zu kurz, solange die Daten fehlen, mit denen diese Prozesse arbeiten.
Unsicher, welche Salesforce-Lösung Ihren Service wirklich trägt?
In 30 Minuten ordnen wir Ihren Anwendungsfall ein – welche Aufgaben zu Manufacturing Cloud, Service Cloud und Field Service gehören und welche Datenbasis der Servicebetrieb dafür braucht. Kein Folientermin.
→ Erstgespräch vereinbaren
Warum die Produktwahl nur die halbe Antwort ist
Service Cloud und Field Service liefern generische Objekte: Case, Work Order, Asset. Ob daraus ein funktionierender Serviceprozess wird, entscheidet die Datenschicht darunter, nicht das Produktlogo. Genau hier trennt sich im Maschinenbau ein Serviceprojekt, das im Alltag trägt, von einem, das nach dem Go-live wieder im Innendienst landet.
Ein Asset-Datensatz ist zunächst nur eine leere Hülle. Damit ein Techniker daraus einen Nutzen zieht, braucht es die installierte Basis in ihrer realen Struktur: welche Variante unter einer Seriennummer verbaut ist, welche Umbauten und Softwarestände seither dazukamen, welche Servicefälle es an genau dieser Anlage gab und welcher Fehlercode für welche Baureihe typisch ist. Diese Domänenschicht ist der Teil, den kein Standardprodukt von sich aus mitbringt.
Die Digitale Maschinenakte (IOTAM) baut genau diese Schicht auf Salesforce auf: Jede Maschine wird als vollständiger Datensatz geführt, mit Konfiguration, Historie, Verträgen und Live-Daten. Wo aus diesen Daten Serviceentscheidungen werden sollen – Triage, Diagnose, Ersatzteil- oder Claim-Bewertung –, setzt Service Decision Intelligence (SDI) als Intelligenzschicht darüber an, mit Quellennachweis bei Empfehlungen und Datenhoheit in der Kundeninfrastruktur.
Die folgende Übersicht ordnet die drei Bausteine ihren Aufgaben zu:
| Dimension | Manufacturing Cloud | Service Cloud + Field Service |
|---|---|---|
| Kernzweck | Kommerzielle Steuerung: an Hersteller und Händler verkaufen | Servicebetrieb: Störungen lösen, Einsätze steuern |
| Typische Aufgaben | Account-Planung, Absatzprognose, Rahmenverträge, Rabatte | Case, Work Order, Disposition, Ersatzteil, SLA |
| Stärke | Planbarkeit von Nachfrage und Umsatz | Durchgängige Fallbearbeitung vom Ticket bis zum Einsatz |
| Grenze für den Service | Bildet Störungsabwicklung und Einsatzsteuerung nicht ab | Trägt erst mit strukturierten Maschinendaten (Domänenschicht) |
Beide Produkte laufen auf derselben Plattform. Der Unterschied im Serviceerfolg entsteht dadurch, wie gut die Maschinendaten darunter strukturiert sind.
„Reicht Manufacturing Cloud für den Service?“ – ein typisches Szenario
Ein typisches Szenario aus der Praxis: Ein Serienfertiger nutzt Manufacturing Cloud bereits im Vertrieb und plant Absatz und Rahmenverträge sauber darüber. Als der Service digitalisiert werden soll, liegt der Gedanke nahe, dieselbe Lösung „mitzunutzen“.
In der Bewertung zeigt sich schnell, wo die Grenze liegt. Die Abbildung von Störungen, die Disposition von Technikern und der maschinenbezogene Ersatzteilfall lassen sich damit nicht sauber führen. Der Hersteller entscheidet sich deshalb für Service Cloud und Field Service als Betriebsschicht und stellt zugleich fest, dass der eigentliche Engpass die Datenlage ist: Die installierte Basis liegt verteilt in ERP und Dateien, nicht als strukturierter Maschinenkontext. Erst mit dieser Grundlage greifen die Serviceprozesse im Alltag.
Das Muster wiederholt sich in vielen Projekten. Die Produktentscheidung ist selten der schwierige Teil. Über den Nutzen entscheidet, ob die Maschinendaten den gewählten Prozessen standhalten. Wo diese Basis fehlt, bleibt ein erheblicher Teil solcher Plattformprojekte hinter der erhofften Nutzung zurück, unabhängig vom gewählten Produkt.
Der Integrations-Einwand: lohnt sich Salesforce-nativ überhaupt?
In der Community ist regelmäßig zu lesen, Salesforce-Projekte im Maschinenbau erstickten an Integrationsaufwand, und mancher zieht daraus den Schluss, Serviceprozesse besser außerhalb der Plattform zu bauen. Der Einwand hat einen wahren Kern: Punkt-zu-Punkt-Verbindungen zwischen ERP, CRM, PLM und Servicewelt werden mit jeder Schnittstelle teurer und fragiler.
Die Antwort darauf liegt aber nicht im Verlassen der Plattform, sondern in der Datenarchitektur. Wenn die installierte Basis als eine gesteuerte Datenbasis auf Salesforce geführt wird, greifen Portal, Serviceprozess und Auswertung auf denselben Maschinenkontext zu, statt über viele Einzelschnittstellen synchronisiert zu werden. Der ERP-Abgleich läuft dann gegen eine Quelle, nicht gegen ein Geflecht.
Genau das ist der Beitrag der Domänenschicht: Sie senkt den Integrationsaufwand, weil die maschinenbezogene Wahrheit an einem Ort liegt. Die Salesforce-Produktwahl klärt, welche Prozesse Sie abbilden. Ob diese Prozesse ohne wachsende Integrationslast tragen, klärt die Datenbasis darunter. Für Serienfertiger mit großer installierter Basis ist das der Hebel, der über die laufenden Kosten der Serviceplattform entscheidet – mehr als die Frage, welches „Cloud“-Produkt auf dem Lizenzblatt steht. Wie sich dieser Fall je nach Herstellertyp unterscheidet, zeigt der Beitrag Serienfertiger vs. Anlagenbauer.
Entscheidungshilfe: erst die Aufgabe, dann das Produkt, dann die Daten
Für die Auswahl hilft eine einfache Reihenfolge. Klären Sie zuerst, welche Aufgabe im Vordergrund steht: das kommerzielle Geschäft mit Herstellern oder der operative Servicebetrieb. Ordnen Sie dann das passende Produkt zu – Manufacturing Cloud für das eine, Service Cloud und Field Service für das andere. Und prüfen Sie erst danach, ob die Maschinendaten die gewählten Prozesse tragen.
Welche Bausteine ein Serviceziel tragen, zeigt die folgende Matrix:
| Serviceziel | Manufacturing Cloud | Service Cloud + Field Service | Domänenschicht (Maschinenakte) |
|---|---|---|---|
| Forecast- und Vertragstransparenz | Hoch | Gering | Mittel |
| Service-Reaktionsgeschwindigkeit | Gering | Hoch | Mittel |
| Erstlösungsquote | Gering | Hoch | Hoch |
| Strukturierte installierte Basis | Gering | Gering | Hoch |
| KI-gestützte Erstbewertung | Mittel | Mittel | Hoch |
| Garantie- und Anspruchsprüfung | Hoch | Mittel | Hoch |
Die Spalte Domänenschicht macht sichtbar, an welchen Zielen die Maschinenakte den Ausschlag gibt: bei der Erstlösungsquote, der strukturierten installierten Basis und der KI-gestützten Erstbewertung.
Dieser dritte Schritt wird am häufigsten übersprungen und entscheidet am Ende über den Erfolg. Ein strukturierter Blick auf die Service-Strategie hilft, die Produktentscheidung nicht isoliert, sondern entlang des gesamten Servicegeschäfts zu treffen.
Der nächste Schritt hängt davon ab, wo Sie stehen:
- Installed Base Assessment – wenn Sie zuerst wissen wollen, ob Ihre Maschinendaten die gewünschten Serviceprozesse überhaupt tragen.
- Erstgespräch – wenn die Datenlage steht und Sie die passende Salesforce-Aufstellung für Ihren Service konkret durchsprechen wollen.
FAQs
Manufacturing Cloud oder Service Cloud – was brauche ich für den Service?
Für den operativen Servicebetrieb brauchen Sie Service Cloud und Field Service. Dort werden Störungen als Case aufgenommen, Einsätze über Work Orders gesteuert, Techniker disponiert und Ersatzteilfälle bearbeitet. Manufacturing Cloud ist auf die kommerzielle Steuerung ausgelegt: Account-Planung, Absatzprognose, Rahmenverträge und Rabatte. Beide laufen auf derselben Plattform, decken aber unterschiedliche Aufgaben ab. Für den Serviceerfolg im Maschinenbau ist zusätzlich die Domänenschicht entscheidend, also eine strukturierte installierte Basis mit Konfiguration, Servicehistorie und Fehlercode je Baureihe. Ohne diese Datenbasis bleiben auch Service Cloud und Field Service generische Werkzeuge, deren Nutzen im Alltag hinter den Erwartungen zurückbleibt.
Kann Manufacturing Cloud die Serviceabwicklung übernehmen?
In den meisten Fällen nicht sauber. Die Stärke von Manufacturing Cloud liegt in der Planbarkeit von Nachfrage und Umsatz, also im Geschäft mit Herstellern und Händlern. Störungsabwicklung, Technikerdisposition und maschinenbezogene Ersatzteilfälle gehören nicht zu ihrem Kern. Wer den Servicebetrieb darauf aufsetzt, arbeitet mit einem Werkzeug, das für einen anderen Zweck gebaut ist. Sinnvoll ist ein Zusammenspiel: Manufacturing Cloud für das kommerzielle Geschäft, Service Cloud und Field Service für den Servicebetrieb, verbunden über eine gemeinsame, maschinenbezogene Datenbasis.
Lohnt sich Salesforce für den Service trotz Integrationsaufwand?
Der Integrationsaufwand entsteht vor allem dort, wo ERP, CRM, PLM und Servicewelt über viele einzelne Punkt-zu-Punkt-Schnittstellen verbunden werden. Der Aufwand lässt sich deutlich senken, wenn die installierte Basis als eine gesteuerte Datenbasis auf Salesforce geführt wird. Dann greifen Portal, Serviceprozess und Auswertung auf denselben Maschinenkontext zu, und der ERP-Abgleich läuft gegen eine Quelle statt gegen ein Geflecht. Entscheidend ist damit weniger die Frage, ob Salesforce-nativ, sondern wie die Maschinendaten strukturiert sind. Für Serienfertiger mit großer installierter Basis ist diese Datenarchitektur der Hebel, der über die laufenden Kosten der Serviceplattform bestimmt.
