Service mit CS oder PM oder CRM?

Ein Unternehmen, das Serviceprozesse mit Hilfe der SAP-Software abbilden will, steht vor einer nicht trivialen Entscheidung: Sollen die Module CS, PM oder das CRM-System eingebunden werden – und wenn ja, ist es eine entweder/oder-Entscheidung?

CRM auf der einen Seite und CS/PM auf der anderen Seite decken zu einem großen Teil identische Funktionalität ab. Im Gegensatz zu CRM gehen die Ursprünge der ERP-Module CS und PM weit in die 90er Jahre zurück, als SAP ERP noch R/3 hieß – und sogar davor, bereits in R/2 in den 80ern gab es das Modul RM-INST (Instandhaltung). Die Anwendungen des Customer Service (früher SM – Service Management) sind in Verbindung mit der Ausweitung der objektbasierten Instandhaltungsfunktionalität entstanden und konnten sich über viele Jahre der Entwicklung ausweiten und in die übrigen Module integrieren, konkret in Verkauf und Vertrieb (SD) Beschaffungswesen und Bestandsverwaltung (MM), Finanzbuchhaltung und Controlling (FI und CO) , Projektsystem (PS), Qualitätsmanagement (QM), Human Resources (HR) sowie Produktionsplanung (PP).
Das SAP CRM System entstand dagegen erst gegen Ende der 90er Jahre, die ersten Kunden gingen zu Beginn der 2000er Jahre live, damals noch mit der Version 2.0. Die Servicefunktionalitäten des CRM entstanden aus dem Hintergrund des Verkaufs von Serviceleistungen, Dienstleistungsprodukten, kaufmännischer Service also – Anlagenstrukturen komplexer Objekte, also der technische Service, standen dagegen im Hintergrund.

Betrachtet man die Funktionalitäten in CRM fällt auf, dass die Wartung komplexer Anlagen, wie sie im Modul PM abgebildet ist, jede Verbindung zu ebendiesem vermissen lässt. Ebenso fehlt eine Integration in das Modul CS. Die Meldungen aus dem Modul CS oder PM, mit denen Corrective oder Preventive Maintenance-Prozesse in der Regel oft beginnen, haben zwar ein entsprechendes Pendant im CRM aber bei Weitem nicht identische Funktionalität. Dasselbe gilt für den PM Instandhaltungsauftrag oder den CS Serviceauftrag oder auch für Serviceverträge oder Rückmeldungen – es gibt jede Menge gleich oder ähnlich benannter Vorgangsarten im CRM mit umfangreicher aber eben nicht identischer Funktionalität und keinen standardmäßig vorgesehenen Austausch dieser Belege. Wer die enge Integration und den vielfältigen Datenaustausch zwischen CRM und ERP SD kennt, wird darüber überrascht sein.

SAP CRM ist ein eigenes System, nicht nur ein Modul, also eine eigene SAP-Installation mit eigener Datenbank. Das bedeutet doppelte Datenhaltung, das gilt für Stammdaten wie auch für Bewegungsdaten wie auch für Customizing. Da das CRM über keine Funktionalität im Bereich Logistik, Finanzbuchhaltung, Controlling und Personalwirtschaft verfügt, diese aber in der Regel oder auch zwingend (externes Rechnungswesen) Teil von Serviceprozessen sind, erstrecken sich diese Prozesse fast immer, abgesehen von Spezialfällen, über beide Systeme.
Dabei sind bestimmte „Sollbruchstellen“ vorgesehen – so erzeugen bestimmte Positionstypen in CRM-Servicevorgängen im ERP SD Kundenaufträge mit unterschiedlichen Positionstypen, um den weiteren Prozessverlauf auseinanderzusteuern oder auch direkt Warenbewegungen – und müssen dabei auf identische und fortlaufend synchronisierte Daten (Stammdaten, Customizing) aufbauen. Der Austausch der Daten wird dabei teilweise von der Middleware erledigt, teils muss er immer wieder manuell durchgeführt werden, beispielsweise bei sich ändernden Customizing-Inhalten. Prozessseitig rufen sich Funktionsbausteine aus den Systemen per RFC gegenseitig auf, beispielsweise bei der CO-Integration, aber auch hier ist aber vorab ein Abgleich spezieller CO-Customizing-Settings notwendige Voraussetzung.

Dieser Systembruch kann also nur mit erheblichem Aufwand überbrückt werden und ist letztlich der Grund, warum – bildlich gesprochen – „an beiden Ufern des Flusses“ die gleichen Gebäude entstanden sind – aber diese Stadteile für seine Bewohner jeweils nur an bestimmten Punkten in Form einer Brücke zugänglich sind. Entwicklungstechnisch und entwicklungsgeschichtlich stehen sich hier Fluch und Segen gegenüber, die Möglichkeit, auf der einen Seite alte Zöpfe abzuschneiden und weitere Innovationen unkompliziert vorzunehmen und auf der anderen Seite die Gefahr, bestehende Errungenschaften zu verlieren oder aus Gründen der Abwärtskompatibilität einen immer kleiner werdenden Spielraum für Innovationen vorzufinden. Dies gilt für den Bereich Sales zunächst gleichermaßen wie für den Bereich Service – allerdings sind Serviceprozesse in der Regel länger, vielfältiger und komplexer als Prozesse im Sales und bedürfen nicht nur eines höheren Grades an Integration sondern auch noch eines höheren Grades an Variation innerhalb der Integration, anders formuliert wiegt eine mangelnde Integration beider Systeme hier doppelt schwer.

Was sind dann die Vorteile von CRM im Bereich Service? Diese scheinen im direkten Vergleich – abgesehen von ein paar funktionalen Details – nicht primär mit den Servicefunktionalitäten per se in Verbindung zu stehen sondern mit Features, die das CRM als Ganzes mitbringt – die im vorigen Absatz erwähnten Innovationen.
Vorrangig sind das die WebUI-Bedienungsoberfläche, die dabei rollenbasierte Auskonfiguration der Oberfläche und der problemlose Einbezug von Channel Partnern, Kunden, Field Staff oder Home Office-Employees über das Internet, das „Fließen“ und Verteilen der Arbeit zu zuständigen Mitarbeitern einschließlich Aufgaben-, Termin- und Mitteilungsverwaltung, die inwzischen mögliche Integration von MS-Word und MS-Outlook, die durch Customizing an vielen Stellen implementierbaren (und bereits im Auslieferzustand implementierten) Automatismen (siehe Blogcontent-> Darfs ein bisschen mehr sein – Automatismen). Weiterhin das mächtige CRM Interaction Center mit vielen servicespezifischen Funktionen, die höhere Übersichtlichkeit einer mehr zentralisierten Informationsaufbereitung und Verkettung von Belegen und Objekten, eine Umfrage- bzw. Feedbackfunktion für Kunden- und Servicetechniker, Customer Self Service über das Internet (E-Service)(ICSS), die Integration von Marketing mit Servicedienstleistungen, Case Management für komplexe Fälle…und nicht zuletzt die Zugänglichkeit der ERP SAP GUI Transaktion über HTML-gerenderten Browserzugriff von CRM aus (der Weg andersherum ist nicht vorgesehen) – das bedeutet vereinfacht gesagt, man kommt im Zweifelsfall über die CRM WebUI an alle ERP Transaktionen ran; die SAP GUI wird nicht benötigt. Alles Dinge, die im Servicealltag in Anbetracht der im Service typischerweise sehr heterogenen Anwenderschar und diversen, über Systeme und Module verstreuten Transaktionen einen großen Mehrwert darstellen können.

Der CS-Serviceauftrag als zentrales Objekt im Serviceprozess ist im ERP ein mächtiges, ausgereiftes Instrument bei der Planung und Steuerung von unternehmenszugehörigen Ressourcen sowie deren Kosten auf Arbeitsplan- (Task Lists) und Arbeitsplatzebene (Work Center) sowie beim transparenten Tracking von (in CO verwalteten) unternehmensinternen Plan- und Istkosten mit einer von SD-Aufträgen unabhängigen Integration in die Material- und Beschaffungslogistik und der vielfältigen Integration in die oben genannten Module. Er wird im ERP oft automatisch durch eine SD-Kundenauftragsposition mit einem Dienstleistungsmaterial ausgelöst. Seine Stärken spielt der CS-Serviceauftrag aber nicht nur bei der Planung aus, sondern auch bei der nachgelagerten Fakturierung, die über den mächtigen und flexiblen dynamischen Postenprozessor (DPP) eine echte aufwandsbezogene Abrechnung aller erbrachten Leistungen zu intern kalkulierten Tarifen ermöglicht (oder auch das Verangeboten von geplanten Leistungen)(siehe Blogcontent -> Aufwandsbezogen oder eher Flat Rate). Der Output des Postenprozessors dient als Grundlage für die nachfolgenden SD-Belege mit der SD-Preisfindung und damit der vertrieblichen Bezuschlagung der hausinternen Kosten und Aufwände, ermittelt über das interne Rechnungswesen.

Für den mächtigen ERP CS-Auftrag gibt es – abgesehen vom Namen – im CRM kein entsprechendes Pendant und wird es mit ziemlicher Sicherheit systembedingt auch nie geben. Werden diese Funktionen benötigt – und das werden sie vor allem dann, je zentraler das Unternehmen den Verkauf von Dienstleistungen bzw. das Projektgeschäft als Geschäftsmodell zum Gegenstand hat – dann muss der CS-Servicevertrag im ERP in den Prozess mit eingebunden werden, was zusammen mit CRM dann schon fast einer scheinbaren – zumindest für Außenstehende erklärungsbedürftigen – Doppelimplementierung gleichkommt : Es gibt dann eine CRM-Serviceauftrag und einen ERP CS Serviceauftrag, die kaum etwas miteinander zu tun haben, zwischen den beiden einen SD-Kundenauftrag und am Ende als Fakturierungsgrundlage noch einen SD-Verkaufsbeleg, die Fakturaanforderung.
Der Grund dafür ist: Wenn Service mit CRM abgebildet wird, ist der technische Ablauf anders: Der Serviceauftrag im CRM steht dann in der Prozesskette vor dem SD-Kundenauftrag bzw. hat der CRM Serviceauftrag den ERP-Kundenauftrag nur als „Erfüllungsgehilfen“, der im ERP dann im weiteren Verlauf auf Positionsebene verschiedene servicetypische logistische Aktionen auslöst, Ersatzteil- oder Leihgeräteversand oder Retouren-Wareneingang beispielsweise. Der CRM Serviceauftrag ist allein schon aufgrund der UI schlichter aufgebaut und bietet bei Weitem nicht alle Möglichkeiten des CS Serviceauftrages, weder funktional noch bei der Integration, er bietet jedoch wiederum einige zusätzliche, die sich wiederum nicht im CS Serviceauftrag finden lassen. Gegebenenfalls muss detailliert untersucht werden, welches System aufzustellende Kriterien besser erfüllt.

Was soll nun implementiert werden? Die Antwort ist ganz offensichtlich: Es kommt darauf an. Für Unternehmen, die über ein eingeführtes SAP ERP verfügen und bereits größere Investitionen in die Abbildung ihrer Service- und Wartungsprozesse mittels SAP ERP CS und PM vorgenommen haben, kann eine zusätzliche Implementierung über SAP CRM Sinn machen, um die oben genannten wichtigen und modernen Features zu nutzen – genauso aber muss bei einem bereits eingeführten SAP ERP zusammen mit einem Neueinstieg in den Geschäftsbereich Service und Wartung die Implementierung nicht unbedingt zwingend SAP CRM mit berücksichtigen. In speziellen Fällen kann sogar eine SAP CRM Service Standalone Implementierung sinnvoll sein – ein entsprechender Best Practice Konfigurationsleitfaden ist erhältlich.
Viele Faktoren werden die Entscheidung beeinflussen – sicher ist nur: Es gibt nicht den einen richtigen Weg, der für alle passt. „One size fits all“ trifft hier noch weniger zu, als bei anderen Problemstellungen

posted in services

Share this story!


  •       

  • Zufrieden oder nicht zufrieden – Das ist hier die Frage      

One Comment “Service mit CS oder PM oder CRM?

  1. Dietmar Baur say: 2 years ago Reply

    Interessanter Artikel – der förmlich nach einem Update schreit: “Service mit CS oder PM oder CRM – oder C4S?”

Leave us a Comment