ERP-Migration: Kostenfalle Schnittstellen

Bei ERP-Migrationen liegt der größte Aufwand selten in der Migration selbst, sondern in den Schnittstellen zu den umliegenden Systemen. Warum Integrationen das teuerste Element solcher Projekte sind und wie sich der Aufwand früh abschätzen lässt.

Wer ein ERP- oder CRM-System ablöst, plant in der Regel rund um die neue Plattform: Lizenzen, Datenmigration, Prozessdesign und Schulungen. Die Schnittstellen zu den umliegenden Systemen tauchen im Projektplan dagegen oft nur als eine einzige Zeile auf. Dahinter steht meist die Annahme, bestehende Verbindungen ließen sich einfach auf das neue System umlenken. Wie so oft bei großen Transformationsprogrammen erweist sich genau diese Zeile später als einer der größten Kostentreiber des gesamten Vorhabens.

Ein Beispiel aus der Praxis

Wie schnell sich das Bild verschiebt, zeigt ein mehrjähriges Transformationsprogramm bei einem großen Finanzdienstleister. Dort wurden die zentrale Kundenplattform, die Vertriebs- und Serviceprozesse sowie der gesamte Marketing-Stack gleichzeitig erneuert. Mehr als 20 Umsysteme mussten neu angebunden werden, von fachlichen Bestandssystemen über Dokumentenablage und Data Warehouse bis hin zu externen Dienstleistern.

Die Integrationen entwickelten sich dabei zu einem der wesentlichen Aufwandstreiber. Das lag nicht daran, dass einzelne Schnittstellen besonders komplex gewesen wären. Entscheidend war, dass ihre Summe und ihre gegenseitigen Abhängigkeiten zu Projektbeginn schlicht niemand vollständig überblickte.

Phase 1: Der unterschätzte Projektaufwand

Bevor eine Schnittstelle neu gebaut werden kann, muss sie verstanden werden. Das klingt banal, ist in der Praxis aber der eigentliche Aufwand. Drei Fragen stehen dabei im Mittelpunkt.

Erstens der Mechanismus: Handelt es sich um einen nativen Konnektor, einen ETL-Prozess, einen nächtlichen Dateiaustausch oder eine API? Nicht selten stellt sich heraus, dass eine vermeintliche Schnittstelle in Wahrheit ein manueller Export ist, den eine Fachabteilung seit Jahren pflegt.

Zweitens das Datenmodell: Die neue Plattform bildet Kunden, Verträge oder Aktivitäten anders ab als das Altsystem. Jede angebundene Anwendung, die sich auf die alte Struktur verlässt, muss neu gemappt werden, einschließlich aller über Jahre gewachsenen Sonderfälle.

Drittens, und am häufigsten unterschätzt, die Frage der Datenhoheit: Welches System ist für welche Daten führend, und welche Systeme konsumieren sie nur? Solange die alte Landschaft stabil lief, musste diese Frage nie ausdrücklich beantwortet werden. Mit einer neuen Plattform in der Mitte wird sie für jedes Datenobjekt relevant. Ihre Klärung erfordert Abstimmungen über Abteilungsgrenzen hinweg, die in keinem technischen Zeitplan vorgesehen sind.

Die Folge: Viele dieser Punkte werden erst im Integrationstest sichtbar, also zu einem Zeitpunkt, an dem Budget und Zeitplan bereits weitgehend verplant sind.

Phase 2: Die laufenden Kosten nach dem Go-live

Mit dem Go-live endet das Projekt, nicht aber der Aufwand. Jede Schnittstelle bleibt eine lebendige Abhängigkeit zwischen zwei Systemen, die sich unabhängig voneinander weiterentwickeln. Sie muss überwacht werden, braucht eine Fehlerbehandlung und muss bei jeder Änderung auf einer der beiden Seiten erneut getestet werden.

Bei Cloud-Plattformen mit mehreren Releases pro Jahr ist das der Normalfall, hinzu kommen auslaufende API-Versionen. Zudem verschieben sich mit neuen Schnittstellen oft die Zuständigkeiten für Aufbau und Wartung, denn sie hängen vom Mechanismus ab: Eine Anbindung über ETL und Data Warehouse verantwortet selten dasselbe Team wie eine API. Wird das nicht früh mit den Stakeholdern geklärt, entstehen Schnittstellen ohne fachliche oder technische Verantwortliche.

In der Wirtschaftlichkeitsbetrachtung tauchen diese Kosten selten auf. Der Aufbau der Schnittstellen wird als einmalige Investition (Capex) geplant, der Betrieb verteilt sich anschließend als laufender Aufwand (Opex) auf verschiedene Teams und Kostenstellen. Somit wird aus einer Einmalinvestition schleichend ein dauerhafter Kostenblock, den niemand als Ganzes verantwortet und der über die Lebensdauer einer Plattform die ursprünglichen Baukosten durchaus erreichen oder übersteigen kann.

Wie sich der Aufwand früh sichtbar machen lässt

Der Integrationsaufwand lässt sich nicht vermeiden, wohl aber rechtzeitig einplanen. Fünf Maßnahmen haben sich in der Praxis bewährt:

1. Schnittstelleninventar vor dem Business Case: Jeder ein- und ausgehende Datenfluss wird erfasst, einschließlich Dateiexporten und manueller Übergaben. Gespräche mit den Fachbereichen fördern dabei oft mehr zutage als die technische Dokumentation.
2. Jede Schnittstelle klassifizieren: nach Mechanismus, Datenvolumen, Geschäftskritikalität und Änderungshäufigkeit. Schon eine einfache Einteilung in drei Komplexitätsstufen macht Aufwände vergleichbar.
3. Datenhoheit und Verantwortung früh klären: Für jedes zentrale Datenobjekt wird festgelegt, welches System führend ist, und für jede Schnittstelle, wer sie fachlich und technisch verantwortet. Diese Entscheidungen gehören in die Architektur- und Fachgremien, nicht in den Integrationstest.
4. Lebenszykluskosten statt Baukosten: Neben dem Aufbau werden auch Betrieb, Monitoring und Anpassungen über mehrere Jahre geschätzt und in den Business Case aufgenommen.
5. Konsolidieren statt eins zu eins nachbauen: Eine Migration ist eine gute Gelegenheit zu prüfen, welche Schnittstellen noch gebraucht werden, welche sich zusammenlegen lassen und welche abgeschaltet werden können.

Fazit

Die Kosten einer ERP-Migration entscheiden sich selten in der neuen Plattform selbst, sondern an ihren Rändern. Wer die Schnittstellen von Anfang an als eigenen Arbeitsstrang mit eigenem Budget behandelt und ihre Kosten über den gesamten Lebenszyklus betrachtet, trifft fundiertere Entscheidungen. Und erlebt im Integrationstest deutlich weniger Überraschungen.