Fallstudie
Zehn Datensätze für ein Krankenhaus, und die Zwischentabelle, die das löste
Die Kundendaten von AliMed vermehrten sich. Ein Krankenhaus konnte zehnmal in Microsoft Dynamics AX stehen, während der ganze Klinikverbund als ein einziger Kunde zählte. Niemand konnte also sagen, welcher Standort tatsächlich bestellte. Rapidi verband AX mit Salesforce über eine Zuordnungstabelle, die die Dubletten auflöste, ohne das ERP anzurühren.
AliMed entwickelt und vertreibt Produkte für das Gesundheitswesen, bekannt vor allem für maßgefertigte Lagerungshilfen, die alles vom einzelnen Körperteil bis zum ganzen Patienten in Position halten. Nach einem gescheiterten Integrationsversuch brachte Rapidis Mirroring-Funktion eine kommerzielle Liste aller US-Gesundheitsstandorte nach Salesforce, obwohl die Quelle keine Zeitstempel hatte, und eine eigene SQL-Tabelle band viele AX-Konten an einen Salesforce-Datensatz. Die Gruppierung nach Lieferpostleitzahl machte aus einem Konzernklumpen Konten je Einrichtung.
Mit einem Integrationsberater sprechen
Das Unternehmen
AliMed entwickelt und liefert seit 1970 Produkte für das Gesundheitswesen. Damals verkauften Julian und Barbara Cherubini von zu Hause in Boston aus, nicht weit vom heutigen Sitz in Dedham, Massachusetts. Die ersten Eigenprodukte, Einlagen und Bandagen, kamen 1974.
Von dort trug ein Direktversandmodell das Geschäft. Die Kataloge wurden dick genug, um in Krankenhäusern, Pflegeeinrichtungen, OP-Zentren und der häuslichen Versorgung zum gewohnten Anblick zu werden. Heute steht der Katalog online und wächst weiter, ebenso wie der Kundenstamm.
Am bekanntesten ist das Unternehmen für maßgefertigte Lagerungshilfen, die die Position von allem zwischen einem einzelnen Körperteil und dem ganzen Patienten steuern. Viele davon lassen sich in Sondergrößen bestellen. Mehr über das Unternehmen unter alimed.com.
Datensätze, die sich vermehrten wie Kaninchen
Um den Vertrieb besser zu unterstützen, als Microsoft Dynamics AX das allein konnte, hatte AliMed Microsoft CRM 2013 gekauft und eine Fremdfirma mit einer selbst gebauten AX-Anbindung beauftragt. Jimmy Mathew wurde geholt, um das CRM zu aktualisieren und die Datenqualitätsprobleme in den Griff zu bekommen, die damit einhergingen.
Das größte davon waren Dubletten. Ein bestehender Kunde besuchte die Website und legte ein neues Konto an, das in AX landete, statt mit dem vorhandenen Konto verknüpft zu werden. Oder er rief an, der Kundenservice fand den Datensatz nicht, und es entstand spontan ein neuer.
Wir hatten ein Datenqualitätsproblem im System, und wir hatten nicht die Werkzeuge, um es zu lösen.
Die ursprüngliche Integration machte es eher schlimmer. „Das Microsoft CRM hat einfach Datensätze aus AX gezogen, also hatten wir am Ende dort ebenfalls alle Dubletten“, sagt Mathew. „Mein Ziel beim Einstieg war, dass wir sowohl ein CRM als auch eine Integration bekommen, die unsere Anforderungen besser tragen. Alles stand zur Disposition.“ Er fand in Salesforce die bessere Antwort für die Kundendatenpflege, und AliMed wechselte. Das Integrationsproblem blieb genau dort, wo es war.
Der Versuch, der scheiterte
Dieser Teil gehört ehrlich erzählt, denn er erklärt, warum die späteren Anforderungen so genau formuliert waren.
Mathews Team prüfte zuerst Jitterbit. Das Werkzeug berücksichtigte die Eigenheiten von AX nicht und half beim Datenqualitätsproblem überhaupt nicht; es wollte Datensatz für Datensatz abgleichen, und genau das erzeugt am anderen Ende Dubletten. „Als wir mit der Umsetzung anfingen, entdeckten wir all diese Einschränkungen, und es stellte sich schlicht als nicht machbar heraus“, sagt Mathew. „Schlimmer noch: Als wir nach sieben oder acht Monaten Design und Entwicklung den ersten Test machten, ist er kläglich gescheitert.“
Dem Team war da schon klar, dass es nicht alle AX-Kundendatensätze in Salesforce haben wollte, weil zu viele davon Dubletten waren. Der Plan war stattdessen, „Definitive Data“ zu importieren, eine kommerzielle Liste aller Gesundheitsstandorte in den USA, und die doppelten AX-Datensätze auf je einen Datensatz pro realem Ort abzubilden. Das ging über das hinaus, was das Werkzeug konnte.
Die Lösung
Bei seiner Recherche stieß Mathew auf Rapidi, und dessen Mirroring-Funktion leistete genau das, woran alles andere gescheitert war: Sie schob die Definitive-Data-Kundendaten nach Salesforce, obwohl die Quelle keinen Zeitstempel zum Abgleichen hatte.
Darum herum definierte das Team eine SQL-Tabelle in der Mitte. „Wir haben vielleicht zehn Konten in AX, und die konnten wir an einen Datensatz in der Zwischentabelle binden“, erklärt Mathew. Rapidi kam mit der individuellen Konfiguration ohne Murren zurecht, und der Betrieb blieb einfach: „Wir aktualisieren einfach einen Datensatz in der Zwischentabelle, lassen Rapidi seinen Job laufen, und die Änderung landet ohne Probleme in Salesforce.“
Die Zwischentabelle löste zugleich ein Altlastproblem des ERP. AX behandelte einen ganzen Klinikverbund als einen Kunden, selbst eine große Krankenhauskette. Die Gruppierung der Zwischentabellen-Datensätze nach Lieferpostleitzahl erzeugte sinnvolle Salesforce-Konten auf Ebene der einzelnen Einrichtung, mit historischen Aufträgen am Standort statt an der Muttergesellschaft.
Dieser Unterschied ist kommerziell entscheidend. Die meisten Beschaffungsentscheidungen fallen lokal, und zu wissen, welches Krankenhaus was bestellt, trennt gezielten Vertrieb von Raterei. Vorher konnte ein Bericht nur den Konzern nennen, dem das Gesundheitssystem gehörte, egal wie viele Standorte darin steckten.
Unterwegs fiel noch ein Engpass. Historische Verkaufsdaten über eine AX-Listenansicht nach Salesforce zu holen funktionierte, dauerte aber „ewig“. Rapidi-Berater arbeiteten mit dem Team an der Indizierung der Tabellen und fanden einen besseren Weg, die Daten zu übertragen; danach war die historische Ladung schnell.
Rückblick
Mathew sagt klar, was er jemandem am Anfang eines solchen Projekts mitgeben würde.
Anfangs waren wir auf die billigste Integrationslösung fixiert, irgendetwas, das AX mit Salesforce verbindet. Aber manchmal ist das Billigste nicht das Beste. Man braucht einen Integrationspartner, der die Eigenheiten des ERP versteht, etwa die AX-Zeitstempel. Mit Rapidi tauschen wir endlich korrekte Daten aus.
Er schätzt auch das Unspektakuläre: ein Problem melden und es gelöst sehen. „Wir konnten nachmittags ein Problem einreichen, und oft hatten wir am nächsten Morgen bei Arbeitsbeginn eine Lösung.“
Auf die Frage, was er ohne Rapidi täte, lacht er. „Das kann ich mir nicht vorstellen. Vor Rapidi konnten wir Fehler nicht sehen und deshalb Probleme nicht selbst beheben. Wir haben jetzt so viel Einblick. Wir sehen die laufenden Jobs, können sie steuern, und wir haben alle Details zu Aktivitäten inklusive Fehlern in den Logs. Zurück können wir nicht mehr, wir können nur noch nach vorn.“
Doppelte Kundendatensätze, die Sie nicht bereinigt bekommen?
Sagen Sie uns, was Ihr ERP enthält und wie die Dubletten entstanden sind, und wir sagen Ihnen, ob eine Standardvorlage von Rapidi das abdeckt.