Die versteckten Kosten von CRM-/ERP-Integrationen, die „nur einen Knopfdruck erfordern“

Es gibt einen Satz, der in etwa neun von zehn ersten Gesprächen über eine CRM-/ERP-Integration fällt. Er enthält das Wort „nur“ und lautet in etwa wie folgt:

„Wir brauchen lediglich eine Schaltfläche im CRM, über die der Auftrag an das ERP-System weitergeleitet wird. Das ist im Grunde alles, oder?“

Es ist im Grunde nie so einfach. Der Button macht nur die sichtbaren 5 % der Integration aus, und die Fragesteller sind keineswegs unvernünftig. Die sichtbare Arbeit ist der Button. Die anderen 95 % befinden sich an Stellen, die erst sichtbar werden, wenn man mit der Entwicklung beginnt, und genau dort kosten diese Projekte still und leise das Dreifache dessen, was ursprünglich veranschlagt wurde.

Dies ist ein praktischer Überblick darüber, woraus die restlichen 95 % bestehen.

Was sich hinter der Schaltfläche verbirgt

Wenn jemand nach einer Schaltfläche fragt, die „einen Auftrag in das ERP-System übermittelt“, beschreibt er damit den Auslöser, nicht die Integration. Die Integration umfasst alles, was zwischen dem Klick und dem Zeitpunkt geschieht, zu dem der Auftrag tatsächlich korrekt, dauerhaft und wiederherstellbar im Zielsystem vorliegt.

Die Arten versteckter Kosten sind vorhersehbar. Sie treten bei jedem Projekt dieser Art auf; die Frage ist lediglich, ob man bewusst darauf eingeht oder sie auf die harte Tour entdeckt.

Versteckte Kosten 1: Inkompatibilitäten bei Datenmodellen

Das CRM und das ERP sind sich nicht einig darüber, was ein Kunde ist. Oder ein Produkt. Oder eine Adresse. Oder eine Maßeinheit. Das CRM verfügt über Freitextfelder für Adressen; das ERP hat ein striktes Schema mit Ländercodes aus einer bestimmten Liste. Das CRM erfasst „Unternehmen“ mit einer ID; das ERP erfasst „juristische Person“, „Rechnungsempfänger“ und „Lieferempfänger“ als drei separate Einheiten.

Jedes Feld in der Quelldatenbank muss einem Feld in der Zieldatenbank zugeordnet werden. Die Felder, die sich problemlos zuordnen lassen, sind die „einfachen“; bei den Feldern, bei denen dies nicht der Fall ist, liegt der Schwerpunkt des Integrationsdesigns.

Diese Arbeit bleibt unsichtbar, bis man damit beginnt. Nach zwei Stunden Arbeit an der Schaltfläche stellt man fest, dass das CRM neun Adresszeilen und das ERP vier hat, und die Frage „Was kommt wohin?“ führt zu einem 30-minütigen Gespräch mit dem Betriebsleiter.

Versteckte Kosten 2: Synchronisationsrichtung und Zuständigkeit

Welches System gilt in welchem Fall als maßgebliche Quelle? Wenn ein Kundendatensatz in beiden Systemen vorhanden ist, welcher Datensatz hat im Konfliktfall Vorrang? Wenn ein Produkt im ERP-System aktualisiert wird, das CRM-System jedoch seit der letzten Synchronisierung geändert wurde, welche Änderung wird übernommen?

Dies sind keine technischen Fragen, sondern Fragen der Steuerung mit technischen Konsequenzen. Sie müssen beantwortet werden, bevor Sie die Integration programmieren, denn die falsche Antwort ist stillschweigend und unumkehrbar. Das System wird das falsche Feld stillschweigend und für immer mit dem falschen Wert überschreiben.

In der Praxis sind die meisten „Mit-einem-Klick“-Integrationen letztendlich Einweg-Push-Systeme, gerade weil eine bidirektionale Synchronisierung eine angemessene Beantwortung dieser Fragen erfordert. Das ist oft die richtige Entscheidung, aber es handelt sich dabei um eine Designentscheidung, nicht um eine Standardeinstellung.

Versteckte Kosten 3: Randfälle und Idempotenz

Die Schaltfläche funktioniert im Normalfall. Dann klickt jemand zweimal darauf, weil der erste Klick keine sichtbare Wirkung gezeigt hat. Nun befinden sich zwei Bestellungen im ERP-System.

Idempotenz ist die Eigenschaft, dass dieselbe Operation, wenn sie zweimal angewendet wird, dasselbe Ergebnis liefert wie bei einmaliger Anwendung. Das klingt akademisch, bis man dem Leiter der Betriebsabteilung erklären muss, warum es doppelte Rechnungen gibt. Es von Anfang an einzuplanen, ist unkompliziert. Es nachträglich einzubauen, ist es nicht.

Die Liste der Sonderfälle bei der Einführung eines CRM-/ERP-Systems ist länger als der Standardablauf:

Teilbestellungen (einige Einzelposten werden erfolgreich verarbeitet, andere nicht)
Bestellungen für Kunden, die im Zielsystem noch nicht vorhanden sind
Bestellungen für Produkte, deren Bezeichnung im Zielsystem seit der letzten Synchronisierung geändert wurde
Bestellungen, die während eines Wartungsfensters des Zielsystems übermittelt wurden
Bestellungen, die übermittelt wurden, während eine andere Synchronisierung für denselben Kunden läuft
Bestellungen, die gegen Geschäftsregeln des Zielsystems verstoßen, die für die Quelle nicht sichtbar sind

Jede dieser Optionen ist eine Entscheidung: überspringen, erneut versuchen, laut scheitern, still scheitern und in die Warteschlange stellen, erneut in die Warteschlange stellen mit Benachrichtigung. Jedes „Nur-ein-Knopf“-Projekt besteht zum Teil aus einer Reihe von unscheinbaren Entscheidungen über diese Punkte.

Versteckte Kosten 4: Fehlerbehandlung und Transparenz

Was passiert, wenn die Schaltfläche nicht funktioniert – und das wird sie –, was dann? Erhält der Nutzer eine Meldung wie „Es ist ein Fehler aufgetreten“? Wird eine E-Mail an eine bestimmte Adresse gesendet? Oder geschieht nichts Sichtbares, und die Bestellung geht verloren?

Für eine Produktionsintegration ist Folgendes erforderlich:

Eine Wiederholungsrichtlinie, die vorübergehende Ausfälle behandelt, ohne fehlerhafte Daten zu verstärken
Ein Dead-Letter-Muster für tatsächlich fehlgeschlagene Elemente, damit diese die Warteschlange nicht blockieren
Eine Überwachungsoberfläche, auf der der Betrieb sehen kann, was tatsächlich geschieht: nicht „das System ist in Betrieb“, sondern „47 Bestellungen wurden heute synchronisiert, 3 befinden sich im Dead-Letter-Stapel, hier ist der Grund“
Warnmeldungen, die ausgelöst werden, wenn die Ausfallraten sprunghaft ansteigen, und nicht erst, nachdem das Betriebsteam dies zufällig bemerkt hat

Dies ist der Teil, den die meisten Projekte, bei denen es heißt „Wir erstellen den Button einfach schnell“, überspringen. Es ist auch der Teil, der darüber entscheidet, ob die Integration nach dem ersten Zwischenfall in der Produktion als zuverlässig gilt oder ob sie zu dem System wird, aus dem jeder Bestellungen von Hand kopiert.

Versteckte Kosten 5: Historische Daten

Die Schaltfläche dient zur Bearbeitung neuer Aufträge. Was ist mit den bestehenden Aufträgen?

Bei fast jedem Integrationsprojekt stellt sich die Frage nach der Nachvervollständigung. Manchmal lautet die Antwort: „Wir müssen nichts migrieren, sondern lediglich ab jetzt synchronisieren.“ Häufiger lautet die Antwort jedoch: „Eigentlich benötigen wir die Bestellungen der letzten zwei Jahre im neuen System, und die sind ein einziges Durcheinander.“

Die Migration historischer Daten stellt zusätzlich zur Integration ein eigenständiges technisches Problem dar. Es lohnt sich, den Umfang hierfür separat und realistisch zu ermitteln. Wenn man „die Integration aufbauen“ und „die historischen Daten migrieren“ in einem Budget zusammenfasst, kommt es häufig vor, dass Projekte auf sechs Wochen Aufräumarbeit stoßen, die niemand einkalkuliert hat.

Versteckte Kosten 6: Langfristige Wartungskosten

Die Integration wird in Betrieb genommen. Sechs Monate später aktualisiert der CRM-Anbieter seine API. Ein Jahr später erhält das ERP-System neue Pflichtfelder. Zwei Jahre später benennt jemand das Feld „Kundenstatus“ um, und die Synchronisierung schlägt bei einer Teilmenge von Datensätzen stillschweigend fehl, was niemand bemerkt, bis die Quartalsberichterstattung ansteht.

Jede Integration ist eine langfristige Verpflichtung, kein einmaliges Projekt. Unabhängig davon, ob die Wartung beim ursprünglichen Entwickler, beim internen Team oder bei demjenigen liegt, der gerade verfügbar ist – sie muss bei jemandem liegen. Projekte, bei denen dies nicht ausdrücklich festgelegt wird, stellen in der Regel fest, dass niemand die Verantwortung dafür übernimmt.

Wenn es sich tatsächlich nur um eine Schaltfläche handelt

Das kommt zwar selten vor, aber es kommt vor. Die Voraussetzungen sind:

Bei beiden Systemen handelt es sich um gut dokumentierte APIs, die Sie selbst verwalten oder die stabil sind
Das Datenmodell ist klar strukturiert und weist keine Randfälle auf (wirklich keine Randfälle, nicht „darum kümmern wir uns später“)
Einweg-Push aus einer einzigen verlässlichen Quelle
Das Datenvolumen ist so gering, dass eine manuelle Wiederherstellung akzeptabel ist, wenn etwas schiefgeht
Der Ausfall der Integration hat nur begrenzte Auswirkungen

Wenn all diese Punkte zutreffen, können Sie es an einem Nachmittag zusammenbauen, und es wird niemandem schaden. Selten treffen jedoch alle Punkte zu.

Diese Projekte realistisch einschätzen

Eine Faustregel, die wir anwenden: Bei der Planung einer CRM-/ERP-Integration schätzen Sie den Aufwand für die Schaltfläche mit dem Faktor 1 und veranschlagen Sie für alles andere den Faktor 4–6. Dieses Verhältnis variiert je nach Komplexität, doch entscheidend ist die grundsätzliche Erkenntnis: Der sichtbare Aufwand macht nur einen Bruchteil des tatsächlichen Aufwands aus.

Das Gespräch, das wir bei der Projektplanung lieber führen sollten, lautet nicht „Wie lange wird die Entwicklung der Schaltfläche dauern?“, sondern „Welche der oben genannten sechs Kategorien versteckter Kosten treffen zu, und wie viel tatsächlichen Entwicklungsaufwand erfordern sie?“ Dieses Gespräch ist der eigentliche Projektplan.

Wenn Sie sich eines dieser Elemente ansehen und „nur ein Knopf“ der Ansatz ist, mit dem Sie arbeiten, ist das das Gespräch, das wir normalerweise zuerst führen würden.