Beitrag vom 9. Dezember 2013

Dynamics CRM mit SAP – Teil 7: Grundprozess „Interessent wird Kunde“

Sobald eine im CRM gepflegte Interessentenfirma einen Auftrag platziert, wird sie normalerweise durch den Innendienst bzw. das Stammdatenteam im SAP als Debitor angelegt. In der Folge muss die CRM-Firma (Account) aber auch im CRM vom Interessenten- in den Kundenstatus überführt werden. Die logische Kopplung kann über die im CRM manuell einzutragende Debitorennummer erfolgen. Die Integrationsprozesse sollten so angelegt sein, dass sie die Umwandlung dann automatisch abwickeln. Die Pflegehoheit geht ab dem Moment der Umwandlung auf das SAP über. Die importierten SAP-Felder sollten ab diesem Zeitpunkt also für die manuelle Pflege gesperrt werden.

Der Prozess kann durch CRM-Workflows und Aktivitäten unterstützt werden, um ihm abteilungsübergreifend eine Kontur zu geben (siehe dazu auch weiter unten). Wird z.B. vergessen, die Debitorennummer in den Interessenten einzutragen, kann potentiell durch den Import eine Dublette entstehen (im CRM existierender Interessent noch ohne eingetragene SAP-Nummer plus der von der Datenintegration neu angelegte Debitor aus SAP). Um die Anlage der Dublette zu vermeiden, könnte die Datenintegrationsschicht einen im CRM konfigurierten Dublettencheck nutzen und im Fall der Fälle eine Warnung im Log ausgeben oder eine Mail mit einem Hinweis auf das Problem verschicken. Dies erfordert aber einen CRM-Konnektor, der das auch unterstützt. Mit SSIS und dem Team4-Konnektor wäre das möglich.

Dies wäre ein pragmatischer Ansatz mit etwas mehr manuellem Aufwand.

SAP_02_Interessent wird Kunde

Ganz andere Herausforderungen ergeben sich bei einer direkten logischen Kopplung über eine Schnittstelle wie RFC oder SAP NetWeaver Application Service. Das Technische ist hierbei die kleinere Herausforderung: Zunächst müssen nämlich organisatorische und Fragen der Data-Governance geklärt sein – zum Beispiel, in welchem Umfang bzw. ob überhaupt CRM-Anwender SAP-Daten direkt ändern können sollen. Es müssten im CRM Voraussetzungen geschaffen werden, um Daten SAP-konform und in betriebswirtschaftlich angemessener Qualität erfassen zu können bzw. dies sogar zu erzwingen. Dabei ist zu bedenken, dass die Datenerfassung im CRM durch Vertriebsmitarbeiter erfolgt, nicht durch ein Stammdatenteam, welches in den häufig sehr strikten Kategorien des Datenqualitätsmanagements denkt. Über eine notwendig werdende extensive Datenvalidierung hinaus müssten daher Geschäftsregeln des SAP „wasserdicht“ im CRM abgebildet werden. Diese können komplex sein, je nachdem welche Freiheitsgrade die Schnittstelle haben soll, bzw. in welcher Tiefe die Daten aus dem CRM heraus änderbar sein sollen (z.B. ganze Partnergeflechte mit Partnerrollen, Vertriebsbereiche etc.).

Die sich in diesem Szenario ergebende Bidirektionalität zwischen CRM und SAP bringt eine hohe Komplexität durch Replikationslogiken und Strategien zur Konfliktauflösung mit sich. Das gilt für jede Middleware.

Man muss sich auch die Frage stellen, ob Aufwand und Nutzen in einem angemessenen Verhältnis stehen. Denn im B2B-Bereich erfolgt in der Regel keine massenhafte Anlage von Kunden, sodass sich der Aufwand für eine vollautomatische Schnittstelle nicht immer lohnt. Dabei muss auch bedacht werden, dass die Kernstammdaten ja nur einen kleinen Teil der im SAP notwendigen Datenpflege zu Neukunden ausmachen: Notwendig sind u.a. auch Vertriebs-, Buchungskreis- und Kreditkontrollbereichsdaten. Auslöser ist häufig ein Auftrag, der im SAP ebenfalls eingelastet werden muss.

In der Praxis hat es sich daher bewährt, Stammdatenänderungen über die CRM-Formulare selbst oder anhängende Änderungsanträge, die im CRM am besten per Knopfdruck aus der Firma generiert werden können, an das Stammdatenteam zu übergeben. Dabei bieten sich Workflows und Aktivitäten zur Unterstützung an. Das Stammdatenteam würde aus dem CRM automatisch per Mail benachrichtigt, sobald der Initiator den Status des Stammdatenantrags auf „Übergabe an SAP“ (sinngemäß) schaltet.

Das Stammdatenteam könnte eigene gefilterte Ansichten für seinen Arbeitsvorrat an Anträgen nach Status haben. Der Antragsteller sollte dann im Rahmen des Workflows Rückmeldung erhalten (z.B. wenn der Status auf „nach SAP übernommen“ oder „Übernahme abgelehnt“ gesetzt wird. Im zweiten Fall möglichst mit einem erklärenden Statusgrund). Hierfür benötigt das Stammdatenteam allerdings CRM-Lizenzen.

Bei einer Hybridlösung könnten die Daten aus dem CRM-Änderungsantrag an das SAP über einen RFC in eine Queue-Tabelle übergeben werden. Das Stammdatenteam kann die Daten dann direkt im SAP bearbeiten und Datensätze per BAPI freigeben. BAPI, Queue-Tabellen und Übernahmeprozess müssten im SAP entsprechend umgesetzt werden.

Im nächsten Beitrag werden Vertriebsbelege behandelt.

Weitere in Arbeit befindliche Artikel gehen dann auf folgende Inhalte ein:

  • Ansprechpartner
  • Konzerne und Key-Accounts
  • Produkte, Kundenprodukte und Preise
  • Schlüssellisten, darunter auch Mehrsprachigkeit und hierarchische Schlüssel

Hier geht’s zu Teil 8

Team4 / Jens Meyer-Beeck
Michael Büning