SAP Field Service Management Integration

Bei Integration wird häufig zuerst an die technische Verbindung zweier Systeme gedacht: Ein Auftrag wird übertragen, ein Status kommt zurück, einige Stammdaten werden synchronisiert. Für ein einfaches Szenario kann das ausreichen. In einer komplexen Serviceorganisation ist Integration jedoch deutlich mehr als Datentransport.

Eine belastbare SAP Field Service Integration muss verstehen, welche fachliche Bedeutung die Daten im jeweiligen Prozess haben und welche Aktionen in den verbundenen Systemen daraus entstehen sollen.

Schon der Ursprung eines Außendiensteinsatzes kann in einer gewachsenen SAP-Landschaft sehr unterschiedlich sein. Je nach Geschäftsmodell und Prozess im SAP-Backend können beispielsweise relevant sein:

Nicht jedes Unternehmen benötigt alle diese Szenarien. Entscheidend ist aber, dass die Integrationsarchitektur nicht nur einen idealtypischen Standardfall abbildet, sondern zu den realen Serviceprozessen, der bestehenden SAP-Landschaft und der geplanten Weiterentwicklung passt.

SAP-Backend -> Integration & Prozesslogik -> Planung und mobile Ausführung ->
Rückmeldung & Automatisierung -> SAP-Backend

Tiefe Integration verbindet deshalb Stammdaten, Geschäftsvorgänge, Statuslogik und Folgeprozesse. Sie sorgt nicht nur dafür, dass Informationen in der mobilen Anwendung sichtbar sind, sondern dass eine Aktion im Field Service im SAP-Backend die richtige geschäftliche Wirkung entfaltet.

Genau hier entsteht häufig mehr Nutzen als durch die mobile Digitalisierung allein. Der Techniker sollte möglichst einfach arbeiten können. Komplexe Regeln müssen nicht zwingend in der mobilen Anwendung abgebildet werden – sie können in der Integration und im SAP-Backend automatisiert werden.

Ein gutes Beispiel ist die Arbeitszeiterfassung. Für den Techniker kann es sinnvoll sein, nur Beginn und Ende einer Tätigkeit zu erfassen. Dahinter kann ein Regelwerk die Zeit automatisch in unterschiedliche Kategorien aufteilen – zum Beispiel normale Arbeitszeit, Pausen, Überstunden, Nachtarbeit oder Arbeit an Feiertagen – und die richtigen Folgeprozesse im SAP-Backend anstoßen.

Dasselbe Prinzip gilt für Material, Statuswechsel, Rückmeldungen, Smartforms oder technische Abschlussinformationen: Die Eingabe im Field Service ist nur der sichtbare Teil. Den größeren Hebel liefert die Automatisierung des durchgängigen Prozesses.

Das Ziel ist nicht, möglichst viel Logik in die mobile Field-Service-Anwendung zu verlagern. Das Ziel ist, den Gesamtprozess für den Anwender einfach und für das Unternehmen durchgängig zu machen.

Standardisierung ist die Grundlage für Skalierbarkeit. Gleichzeitig unterscheiden sich reale Serviceorganisationen in ihren Produkten, Ländern, Vertragsmodellen, Prozessen und Informationsbedarfen. Deshalb gehört kontrollierte Erweiterbarkeit zu einer tragfähigen Unternehmensarchitektur.

In SAP Field Service and Asset Management können beispielsweise Zusatzfelder, Smartforms, zusätzliche Informationen für die Disposition oder mobile Prozessschritte erforderlich sein. Die entscheidende Frage ist dann nicht nur, ob sich die Field-Service-Anwendung erweitern lässt, sondern ob diese Erweiterung im gesamten Prozess erhalten bleibt.

Ein Zusatzfeld, das nur in der mobilen Anwendung existiert und an der Systemgrenze verloren geht, ist keine durchgängige Erweiterung.

Unternehmensweit tragfähige Erweiterbarkeit bedeutet deshalb, Anpassungen kontrolliert durch die gesamte Prozesskette zu führen: von Backend-Daten und Zuordnungen über Planung und mobile Ausführung bis zurück in die Folgeprozesse. Dazu gehören Versionierung, Überwachung und ein sauberer Umgang mit Upgrades genauso wie die eigentliche Funktion.

Auch das Clean-Core-Prinzip spielt hier eine wichtige Rolle. Kundenindividuelle Anforderungen sollten nicht automatisch zu tiefen Modifikationen im ERP-Kern führen. Wo möglich, sollten standardisierte Integrationsmechanismen, definierte Erweiterungspunkte, SAP BTP und sauber gekapselte Erweiterungen genutzt werden. Clean Core bedeutet dabei nicht, auf Differenzierung zu verzichten – sondern sie an der richtigen Stelle umzusetzen.

Ein typisches Beispiel ist die Material- und Komponentenplanung. Zusatzinformationen entfalten erst dann ihren vollen Nutzen, wenn sie nicht als isolierte Erweiterung in einer einzelnen Anwendung verbleiben, sondern in Planung, mobile Ausführung, Bestandsführung und Rückmeldung durchgängig genutzt werden können.

Eine projektspezifische Punkt-zu-Punkt-Integration kann für einen klar abgegrenzten Prozess oder einen schnellen Start sinnvoll sein. Problematisch wird es, wenn sie als langfristige Architektur für eine wachsende Serviceorganisation behandelt wird.

Was zunächst wie eine einfache Verbindung aussieht, muss später häufig zusätzliche Länder, Gesellschaften, Prozessvarianten, Backend-Releases, Zusatzfelder, neue mobile Anforderungen oder weitere Automatisierung unterstützen. Spätestens dann zeigt sich, ob die Integration als wiederverwendbare Plattform gedacht wurde oder als einmaliges Projektartefakt.

Unternehmen sollten deshalb nicht nur fragen: „Können die beiden Systeme Daten austauschen?“ Wichtiger sind Fragen wie:

Unternehmensweit tragfähige Integration misst sich nicht daran, ob Daten heute übertragen werden können – sondern daran, ob sich der Prozess morgen weiterentwickeln lässt.

Genau deshalb greift die Gegenüberstellung „Standard oder individuell“ zu kurz. Entscheidend ist eine Architektur, die standardisierte Integrationsbausteine nutzt und dort kontrolliert erweitert, wo der reale Geschäftsprozess es erfordert.

Für SAP-zentrierte Unternehmen beginnt die SAP Field Service & Asset Management Integration nicht auf einem leeren Blatt. SAP dokumentiert unterschiedliche Integrationsansätze für verschiedene Backend-Landschaften und Transformationsszenarien.

Zwei besonders relevante Wege sind die von SAP entwickelte native Integration für S/4HANA-Szenarien sowie der von proaxia entwickelte proaxia FSA Cloud Connector (PCC) für SAP ECC und entsprechende S/4HANA-Landschaften.

Welcher Weg passt, hängt unter anderem von Backend-Version, Betriebsmodell, bestehenden CS-/PM-/Service-Prozessen, benötigter Prozessbreite, kundenspezifischen Zuordnungen und der geplanten S/4HANA-Transformation ab.

Die Architekturentscheidung sollte deshalb nicht als Grundsatzfrage „native Integration oder Connector“ geführt werden. Entscheidend ist, welcher standardisierte Pfad die aktuelle Landschaft sauber abbildet und gleichzeitig den nächsten Transformationsschritt unterstützt.

Der aktuelle Produktname lautet proaxia FSA Cloud Connector (PCC). In der aktuellen SAP Feature Scope Description wird dieselbe Lösung weiterhin unter dem Lizenznamen „SAP Field Service Management, connector for SAP ERP“ geführt und als von proaxia entwickelt und gepflegt sowie im OEM-Modell durch SAP vertrieben beschrieben. In älteren Unterlagen findet sich außerdem die Bezeichnung „FSM Cloud Connector“.

Die Diskussion über Integration wird noch relevanter, wenn künstliche Intelligenz in den Serviceprozess kommt. KI kann nur mit dem Kontext arbeiten, der verfügbar ist. Und ein Agent kann nur dort sinnvoll handeln, wo Prozesse, Daten und Aktionen technisch zugänglich und sauber orchestriert sind.

KI braucht Kontext. Agenten brauchen Prozesse, in denen sie handeln können. Durchgängige Integration schafft beides.

Ein KI-Assistent, der nur die Daten einer Field-Service-Anwendung kennt, kann einen Techniker bereits unterstützen. Ein wirklich integrierter Serviceprozess bietet aber wesentlich mehr Kontext: Anlagen und installierte Basis, Servicehistorie, Verträge, Service-Level-Vereinbarungen, Materialverfügbarkeit, Bestände, Auftragsstatus, Kundeninformationen, technische Dokumentation und nachgelagerte Backend-Prozesse.

Damit werden deutlich umfassendere Szenarien möglich. Ein digitaler und durchgängiger Serviceprozess könnte beispielsweise:

Der entscheidende Punkt: KI wird nicht als isolierte Zusatzanwendung neben den Serviceprozess gestellt. Sie arbeitet auf einem bereits digital verbundenen Prozess und kann dadurch Schritt für Schritt mehr operative Aufgaben unterstützen – immer innerhalb definierter Berechtigungen, Governance- und Kontrollmechanismen.

Digitaler Außendienst -> Tiefe Integration ->
Prozessautomatisierung -> Serviceintelligenz -> KI-Assistenten & KI-Agenten

Die Entwicklung folgt einer klaren Logik: Zuerst wird der Außendienst digitalisiert. Danach werden Field Service und SAP-Backend tief verbunden. Auf dieser Grundlage lassen sich Folgeprozesse automatisieren und Informationen über Systemgrenzen hinweg nutzbar machen.

Eine leistungsfähige Field-Service-Plattform bleibt dabei ein zentraler Baustein. Der zusätzliche Nutzen entsteht durch das Zusammenspiel mit Kundenservice, ERP, Instandhaltung, Materialwirtschaft, Abrechnung und Analyse – und damit durch einen durchgängigen Serviceprozess.

Das gilt auch für KI: Entscheidend ist nicht die Zahl einzelner KI-Funktionen, sondern ihre Verbindung mit realen Serviceprozessen, Daten und Entscheidungen. Die Zielarchitektur sollte deshalb so gewählt werden, dass sich die Integrationstiefe Schritt für Schritt erweitern lässt.

Eine moderne Field-Service-Lösung liefert bereits für sich genommen relevante Vorteile: bessere Planung, mobile Prozesse, Transparenz und schnellere Rückmeldungen. In komplexen SAP-Serviceorganisationen ist das jedoch nur der erste Teil der Wertschöpfung.

Der größere Hebel entsteht, wenn Field Service tief mit den vor- und nachgelagerten Prozessen verbunden wird. Dann können Informationen nicht nur angezeigt, sondern Geschäftsprozesse automatisiert, Backend-Logik genutzt und Folgeprozesse durchgängig gesteuert werden.

Diese durchgängige Digitalisierung schafft zugleich die Grundlage für KI-Assistenten und KI-Agenten, die den Kontext des gesamten Serviceprozesses verstehen und – kontrolliert – über Systemgrenzen hinweg Aktionen unterstützen können. Entscheidend ist deshalb nicht nur, wie Field Service an das ERP angebunden wird, sondern wie daraus ein skalierbarer, erweiterbarer und KI-fähiger Serviceprozess entsteht.

Dr. Marcin Granowicz verfügt seit 1986 über umfassende Erfahrung in Systemintegration und Softwareentwicklung. Er leitete internationale Teams mit über 100 Mitarbeitenden und war Vorstandsmitglied eines Software-Development-Zentrums. Dank seiner Expertise aus hunderten Projekten, seiner internationalen Erfahrung und hohen sozialen Kompetenz ist er ein geschätzter Ansprechpartner für Kunden, Partner und Mitarbeitende.