Unter Strom

Wer Kundendaten in zwei Systemen speichert, braucht Mechanismen zum Abgleichen zwischen ihnen. Kostengünstig lässt sich unter anderem das freie Werkzeug Pentaho Data Integration dafür verwenden.

In Pocket speichern vorlesen Druckansicht 1 Kommentar lesen
Lesezeit: 10 Min.
Von
  • Ralf Hohoff
Inhaltsverzeichnis

Aufgabe einer CRM-Anwendung (Customer Relationship Management) ist die Anreicherung, Verknüpfung und Auswertung unterschiedlicher Informationen über Kunden, Interessenten, Wettbewerber und Partner, zum Beispiel Kontakthistorien, Profile oder Kampagnenteilnahmen. Bei seiner Einführung existiert häufig bereits ein ERP-System (Enterprise Resource Planning), das mit den Kundendaten der letzten Jahre die wichtigsten Informationen zur Verfügung stellt. Deshalb liegt es nahe, vom CRM direkt auf die Kundenstammdaten im ERP zuzugreifen, ohne zusätzlichen Export/Import oder redundante Datenhaltung.

Dieser auf den ersten Blick naheliegende Ansatz erhöht jedoch die Komplexität der Anwendung deutlich: Direkte Zugriffe auf fremde Datenstrukturen erzeugen eine hohe Abhängigkeit. Da sich die Datenbankschemata von SAP, Navision & Co. unterscheiden, müsste ein CRM-Hersteller für jeden Anbieter eine spezifische Variante programmieren. Bei Änderungen des ERP-Systems wären immer wieder Anpassungen fällig. Schnell entstehen so beim CRM-Hersteller bereits für wenige angebundene ERP-Systeme enorme laufende Programmierkosten.

Auch die Recherche in unterschiedlichen Datenbanksystemen, zum Beispiel ERP-Kundenstammdaten mit Oracle und die CRM-Kontakthistorie mit SQL Server, ist nicht trivial. Beim Bewältigen solcher Aufgaben entpuppt sich oft die propagierte Datenbankunabhängigkeit der CRM-Anbieter als hehrer Wunsch.

Um diese und weitere Schwierigkeiten zu umgehen und gleichzeitig offen für fast alle Fremdsysteme zu sein, importieren CRM-Systeme die Informationen über Schnittstellen und können nach der Datenübernahme autark arbeiten. Doch auch dieser einmaligen Datenmigration oder dem zyklischen Abgleich stehen häufig Hindernisse entgegen. Dazu gehören unstrukturierte Stammdaten oder kundenspezifische Änderungen der ERP-Systeme. Zusätzlich beeinflusst die gewählte Vorgehensweise, ob Anpassungen und Erweiterungen während der Erstumsetzung oder im Betrieb einen hohen Aufwand zur Folge haben.

Einen praktikablen dritten Weg, der die Komplexität nicht erhöht und keine Abhängigkeit von Fremdsystemen schafft, eröffnen spezialisierte Werkzeuge zur Datenübernahme. Allgemein laufen diese Tools unter dem Kürzel „ETL“, was für „Extract, Transform, Load“ steht. Pentaho Data Integration (PDI, Onlinequellen [a]) ist ein solches Produkt mit einer Open-Source-Lizenz. An seinem Beispiel sei im Folgenden der Datenabgleich zwischen dem ebenfalls freien SugarCRM und einem ERP-System wie R3, Baan/Infor oder Navision demonstriert.

Mit dem in PDI integrierten grafischen Editor Spoon entwirft man interaktiv die einzelnen Schritte der Datenintegration (Abb. 1).

PDI ist eine Komponente der Pentaho-BI-Suite und als Java-Applikation betriebssystemunabhängig einsetzbar. Mit einem grafischen Designer erstellt man darin die ETL-Prozesse per Drag & Drop. Die Teilschritte zur Verarbeitung der Datenströme sind Klassiker wie das Lesen von Datenbanktabellen und Textdateien oder das Umschreiben (Mapping) von Werten. Jobs können mehrere Transformationen zusammenfassen und im Batch zu einer festgelegten Zeit laufen.

Im Wesentlichen gibt es drei Wege, SugarCRM per ETL-Prozess mit Kundendaten des ERP zu befüllen: manueller oder teilautomatischer Export, kommerzieller Konnektor für ERP-Systeme und direkter Zugriff auf die zugrunde liegende Datenbank.

In der Evaluierungs- oder Testphase eines Projekts kommt häufig der Export von Dateien (zum Beispiel CSV oder Excel) zum Einsatz, den jede aktuelle Anwendung anbietet. Dieses Verfahren ist jedoch bei manuellen Tätigkeiten fehleranfällig und nicht ausreichend flexibel. Deshalb eignet es sich für den Produktiveinsatz nur in wenigen Fällen.

Mehr Infos

Onlinequellen

[a] Pentaho DataIntegration
[b] SugarCRM
[c] Talend
[d] JBoss ESB
[e] Xaware

Kommerzielle Konnektoren für PDI, zum Beispiel ProERPconn für SAP, bieten eine hohe Integration in das ERP-System. Durch die Nutzung seines Berechtigungskonzepts und die komfortable Tabellen- und Feldauswahl ist dies bei größeren Anwendungen der bevorzugte Ansatz, Fachabteilungen einfache Anpassungen oder Erweiterungen von ETL-Prozessen zu ermöglichen.

Historisch gewachsene ERP-Landschaften mit einer deutlichen Abweichung vom Standard erfordern jedoch vielfach eine „Interpretation“ von Informationen, zum Beispiel die mehrstufige Übersetzung von Feldinhalten für das Zielsystem (Mapping) verbunden mit dem Zusammenführen verteilter Datenwerte. Bei dieser Detailtiefe in der Prozessmodellierung kommen die Vorteile eines kommerziellen Adapters weniger zum Tragen, denn mehr als die Fach- ist hier die IT-Abteilung gefragt.

Eine flexible und kostengünstige Alternative zu den beiden ersten Verfahren bildet der (fast) direkte Zugriff auf die ERP-Datenbank. Er benutzt jedoch nicht die Tabellen selbst, sondern Views. Das hat mehrere Vorzüge:

  • Änderungen im ERP-System erfordern nicht zwingend das Anpassen aller Importprogramme, da diese auf den Views aufbauen.
  • Views können Datensätze nach Attributen selektieren und Informationen aus verschiedenen Tabellen zusammenführen. Das Unternehmen entscheidet selbst, welche Informationen es zur Weiterverarbeitung anbietet.
  • Die Voraggregation von Daten ist möglich, zum Beispiel für monatliche Umsatzsummen.
  • Statt wenig aussagekräftiger ERP-Spaltennamen lassen sich sprechende Bezeichner verwenden.

Mit dem integrierten Assistenten (Wizard) ist die Einrichtung der Datenbankverbindungen für das Quell- und Zielsystem schnell erledigt. Per ODBC und JDBC bietet PDI Zugriff auf alle gängigen Datenbanken. Alle Verbindungen stehen in einer zentralen XML-Datei, was das Verteilen der Einstellungen auf Entwicklungs-, Test und Produktivsystem erleichtert.

Um zwei Systeme kontinuierlich abzugleichen, braucht man identifizierende Schlüssel. Häufig übernimmt die Kundennummer aus dem ERP-System diese Rolle. SugarCRM verwendet einen 36-stelligen alphanumerischen Schlüssel, den Universally Unique Identifier (UUID). Er kann Datensätze auch in verteilten Systemen eindeutig kennzeichnen.

Da die im Folgenden beschriebene Transformation die Kundendaten aus dem ERP-System ins Ziel-CRM überträgt und ein Zurückspielen nicht erfolgt, braucht nur SugarCRM die Kundennummer des ERP-Systems zu speichern. Zu diesem Zweck legt man dort mit dem Studio im Administrationsbereich (Studio/Firmen/Felder) ein neues Feld an. Es sollte denselben Datentyp haben wie das Schlüsselfeld im ERP-System.

SugarCRM speichert die Standardkundendaten in einer Tabelle und alle selbst definierten Felder in einer weiteren. Dazu gehört im Beispiel unter anderem das Feld customer_no_c für die Kundennummer. Zum Erstellen der Transformation dient Spoon, der grafische Designer von PDI. Man beginnt mit dem Aufbau der Datenströme (Streams). Zum Lesen von Informationen gibt es unter anderem den „Tabellen-Input“. Dort wählt der Anwender die Datenbankverbindung und definiert die auszuführende SQL-Abfrage.

Der Schritt „erp view customers“ (s. Abb. 1 oben) liest alle ERP-Kunden durch den festgelegten View ein und baut den ersten Datenstrom auf. Ein zweiter Input-Stream liefert die Kunden aus dem SugarCRM samt der Zuordnung der UUID-Werte zu den Kundennummern. Felder, die keiner Veränderung im weiteren ETL-Prozess unterliegen, sollte man schon in diesem ersten Schritt nach ihrer Zielspalte benennen.

In einem Merge-Join-Schritt erfolgt die spaltenweise Vereinigung der beiden separaten Datenströme. Analog zur gleichnamigen Datenbankfunktion führt ein Left Join den ERP-Stream mit den Informationen aus SugarCRM zusammen. Er ordnet jedem Kundendatensatz gegebenenfalls die passende UUID zu, falls sie bereits existiert.

Für die einwandfreie Zusammenführung im Merge Join erwartet PDI, dass die Datenströme nach den Join-Feldern, hier den Kundennummern, sortiert sind. Da verschiedene Datentypen, etwa Zahlen und Strings, zu unterschiedlicher Sortierung führen, ist hier Aufmerksamkeit gefragt. Gegebenenfalls helfen die PDI-Funktionen für Typkonvertierung und Sortierung, die Reihenfolge in Form zu bringen.

Bei der Erstellung des ETL-Prozesses unterstützt der integrierte Debugger. Er erlaubt das sukzessive Durchführen der Transformation. In der Vorschau ist stets ein Blick auf das Resultat möglich, ohne das Skript vollständig auszuführen.

Nach dem Zusammenführen der Streams aus ERP und CRM prüft ein Filter-Schritt für jeden Datensatz, ob zur ERP-Kundennummer eine UUID existiert. Ist dies nicht der Fall, entfernt er die leere UUID. Dies ist notwendig, da der folgende „Append“-Schritt keine Felder überschreiben kann. Nach der Erzeugung einer zufälligen UUID („Add UUID“) vereinigt er die Einträge mit alter und zufälliger UUID. Append ist darauf angewiesen, dass die Felder beider Quellen in derselben Reihenfolge auftreten und identische Datentypen haben.

Mit dem Insert-/Update-Schritt in PDI lässt sich das Einfügen beziehungsweise Aktualisieren von Datensätzen einfach und transparent bis auf Feldebene steuern (Abb. 2).

Der nächste Schritt hübscht das Ganze etwas auf, indem „industry“ den in ERP üblicherweise benutzten Zahlen für Industriezweige einen lesbaren Namen zuordnet. Ähnlich könnte man an dieser Stelle auch unterschiedliche Mitarbeiterkennungen der zwei Systeme umsetzen. Abschließend verteilen die „Insert/Update“-Schritte die Streams auf die Zieltabellen accounts und accounts_cstm, indem sie anhand der UUID das Einfügen beziehungsweise Aktualisieren der Datensätze übernehmen (s. Abb. 2). Dabei steuern Parameter bis auf Feldebene, ob das CRM Werte nur einmalig zur weiteren Pflege übernimmt oder zyklisch durch das ERP-System aktualisiert wird.

Da SugarCRM auch Interessenten erfassen kann, die erst später zu Kunden aufsteigen, fehlen deren Daten im ERP-System. Bei dem geschilderten unidirektionalen Prozess kann das zu Dubletten führen, wenn die Kundendaten erneut im ERP-System erfasst werden. Einfache Abhilfe schafft das einmalige Eintragen der neu angelegten Kundennummer in SugarCRM vor dem nächsten Abgleich, auf diese Weise sind Interessent und Neukunde dauerhaft verbunden.

Die beschriebene Umsetzung mit PDI lässt sich an andere Anforderungen anpassen und kann als Basis für neue Transformationen dienen. Selbst umfangreiche Erweiterungen sind durchführbar, ohne Einbußen in der Transparenz oder Wartbarkeit in Kauf nehmen zu müssen. Dies ist ein Vorteil gegenüber einem Konglomerat aus selbst geschriebenen Skripten und Datenbankprozeduren. Selbst Mitarbeitern aus der Fachabteilung ist es mit diesem Lösungsweg möglich, kleinere Änderungen wie die Umstellung des Mapping für die Branchen schnell eigenständig durchzuführen.

Für den zeitgesteuerten Abgleich verschiedener Systeme können mit PDI oder ähnlichen Tools [c] die notwendigen ETL-Prozesse erstellt werden. Für die synchrone Kommunikation in Echtzeit stehen serviceorientierte Produkte wie JBoss ESB [d] oder Xaware [e] zur Verfügung. Die Nutzung von Open-Source-Komponenten und die mit der Technik verbundenen Einsparungen bei den Ressourcen ermöglichen es, mehr Geld in den Funktionsumfang statt in die Migration zu stecken. Das erfreut die Anwender im Fachbereich und den Projektsponsor.

ist Senior Consultant bei der buw consulting GmbH in Osnabrück und tätig in der Konzeption und Implementierung von IT-Systemen mit den Schwerpunkten CRM und Wissensmanagement.

iX-Link
(ck)