Warum scheitern Integrationsmodernisierungen?

Eine Bestellung aus einem Webshop kann innerhalb von Sekunden in das ERP-System, dann in das Lagerverwaltungssystem und schließlich zum Kurierdienst übermittelt werden. Auf dem Papier erscheint dieser Prozess einfach. In der Praxis zeigt sich jedoch, warum Integrationsmodernisierungen scheitern: Nicht die technische Umsetzung der Datenübertragung verursacht die meisten Probleme, sondern unklare Geschäftsregeln, unsichere Datenverantwortung und eine ohne Betrieb geplante Architektur.

Viele Organisationen betrachten die Modernisierung als Austausch einer alten Verbindung. Tatsächlich ist die Integration Teil des Betriebsmodells. Sie legt fest, welches System das letzte Wort in Bezug auf Lagerbestand, Preis, Bestellstatus oder Rechnungsdaten hat und auch, wer im Fehlerfall eingreift und auf welcher Informationsbasis. Wenn diese Fragen während der Entwicklung offen bleiben, kann das Projekt leicht zu einem kostspieligen Fehlerbehebungszyklus werden.

Warum scheitern Integrationsmodernisierungen bereits am Anfang?

Der häufigste Fehler ist, dass das Projekt mit einer technologischen Entscheidung beginnt: eine neue API, iPaaS-Plattform, Nachrichtenwarteschlange oder Zwischendatenbank. Diese können gerechtfertigte Werkzeuge sein, ersetzen jedoch nicht die Prozesskartierung. Dass zwei Systeme technisch in der Lage sind, Daten auszutauschen, bedeutet nicht, dass sie dasselbe unter erfüllter Bestellung, verfügbarem Lagerbestand oder gutgeschriebener Rechnung verstehen.

In Großhandels- oder Fertigungsumgebungen ist es besonders häufig, dass dieselbe Artikelnummer mit unterschiedlichen Lebenszyklen, Maßeinheiten oder Lagerlogiken in verschiedenen Systemen verknüpft ist. Das ERP kann die Quelle für Finanz- und Stammdatenmanagement sein, das Lagerverwaltungssystem verfolgt die physische Bewegung, und der Webshop kann eigene Verkaufsregeln anwenden. Wenn das Projekt nur Felder abgleicht, aber diese geschäftlichen Bedeutungen nicht abstimmt, treten die Fehler später in Form von Stammdatenabweichungen, Überverkäufen oder manuellen Korrekturen auf.

Daher wird das Ziel der Modernisierung nicht dadurch bestimmt, welches Interface das alte ersetzt. Eine bessere Frage ist, welche Betriebsentscheidung zuverlässige Daten erfordert, mit welcher Verzögerung, welcher Ausnahmebehandlung und wer für das Ergebnis verantwortlich ist.

Der bestehende Prozess ist nicht identisch mit der Dokumentation

Viele Organisationen verfügen über Prozesskarten, aber diese enthalten oft nicht die realen Ausnahmen. Sie zeigen nicht, was bei Teillieferungen, Ersatzprodukten, manuellen Bestelländerungen, Rücksendungen oder der vorübergehenden Nichterreichbarkeit eines externen Partnersystems passiert.

Erfahrene Betreiber handhaben diese Situationen mit Tabellen, E-Mails und Systemkenntnissen. Eine neue Integration kann jedoch nicht auf stillschweigenden Regeln basieren. Die Ausnahmen müssen im Voraus modelliert werden: Welches Ereignis löst einen Prozess aus, welches System ist die Quelle, was gilt als gültiger Zustand und wann ist eine menschliche Genehmigung erforderlich.

Ein fehlerhaftes Datenmodell untergräbt stillschweigend den Betrieb

In Integrationsprojekten sind Probleme mit Daten selten am ersten Tag sichtbar. Die Synchronisation kann laufen, das Dashboard kann einen grünen Status anzeigen, dennoch können falsche Geschäftsergebnisse auftreten. Der Grund dafür ist, dass die übertragenen Daten strukturell korrekt, aber in ihrer Bedeutung ungenau oder unvollständig sind.

Ein typisches Beispiel ist der Lagerbestand. Ein System gibt die physisch verfügbare Menge an, ein anderes zieht die Reservierungen ab, ein drittes enthält auch die Verfügbarkeit des Lieferanten. Wenn der Wert nicht mit einer klaren Definition an den Webshop veröffentlicht wird, arbeiten der Verkauf und das Lager aus unterschiedlichen Realitäten. Gleiches gilt für Partnerdaten, Preislisten, Steuersätze, Bestellstatus und Lieferadressen.

Jedes kritische Datenobjekt benötigt einen zugewiesenen Datenverantwortlichen. Dies bedeutet nicht unbedingt eine einzelne Person, sondern eine klare Verantwortung: Welche Anwendung ist die maßgebliche Quelle, wer genehmigt die Änderungsregeln und unter welchen Bedingungen kann ein System einen Wert aus einem anderen überschreiben.

Ohne Datenverwaltungsentscheidungen werden Integrationen letztendlich zu Prozessen, die sich ständig gegenseitig korrigieren. Eine manuelle Änderung wird überschrieben, ein fehlerhafter Datensatz erscheint erneut oder ein zuvor gelöschter Partner wird wieder aktiv. Dies sind keine einfachen Entwicklungsfehler, sondern ungeklärte Datenverwaltungsfragen.

Punkt-zu-Punkt-Verbindungen werden schnell unüberschaubar

Die Verbindung eines einzigen Webshops und eines ERP-Systems kann oft durch direkte Integration gelöst werden. Die Situation ändert sich, wenn Lagerverwaltung, Rechnungsstellung, CRM, Produktionsplanung, Lieferantendatenkanal, Lieferantenplattform oder Kundenportal hinzugefügt werden. In solchen Fällen schafft das schnell erstellte Netzwerk von Punkt-zu-Punkt-Verbindungen komplexe Abhängigkeiten, die schwer zu handhaben sind.

Eine neue Feld-, Status- oder Geschäftsregeländerung kann mehrere Schnittstellen betreffen. Ohne zentrale Verträge für Datenformate, Versionskontrolle und Fehlerbehandlung steigt das Risiko von Änderungen allmählich an. Teams zögern oft, die notwendigen Entwicklungen vorzunehmen, weil sie die Nebenwirkungen nicht sicher einschätzen können.

Die Einführung einer großen Integrationsplattform ist nicht immer gerechtfertigt. Bei kleineren, gut definierten Systemverbindungen kann übermäßige Abstraktion eine unnötige Betriebsbelastung darstellen. Bei mehreren geschäftskritischen Systemen ist es jedoch ratsam, die interne Logik der Anwendungen bewusst von der Integrationsschicht zu trennen. Dies kann eine API-zentrierte Architektur, ereignisgesteuerte Datenübertragung oder eine kontrollierte Zwischenschicht sein. Die richtige Wahl hängt vom Transaktionsvolumen, den Latenzanforderungen, der Reife der Systeme und der Häufigkeit von Änderungen ab.

Der Betrieb ist keine nachträgliche Entwicklungsaufgabe

Viele Modernisierungen werden unsicher, weil die Erfolgsdefinition auf die Einführung beschränkt ist. Eine Geschäftsintegration beweist sich wirklich, wenn sie bei Teilfehlern, Ausfällen externer Dienste, Netzwerkproblemen oder unerwarteten Datenvolumen kontrolliert funktioniert.

Die Frage ist, was passiert, wenn eine Nachricht zweimal ankommt oder wenn die Antwort einer entfernten API aufgrund eines unsicheren Zeitüberschreitens erfolgt. Kann der Betrieb sicher erneut versuchen? Ist klar, welche Bestellungen überprüft werden müssen? Gibt es eine Alarmierung, die nicht nur technische Fehlercodes anzeigt, sondern auch geschäftliche Auswirkungen?

Für die richtige Beobachtbarkeit sind strukturierte Protokollierung, Korrelationskennungen, Metriken und interpretierbare Alarmierungsregeln erforderlich. Das Protokoll ist dann nützlich, wenn es eine Kundenservice- oder Betriebsfrage beantworten kann: Wo blieb die Bestellung hängen, welche Daten wurden empfangen, welche Regel entschied und wurde eine erneute Verarbeitung durchgeführt.

Die Infrastrukturseite kann davon nicht getrennt werden. Die Authentifizierung der Verbindungen, die sichere Handhabung, die Berechtigungen, die Backups, die Kapazitätsplanung und die Aktualisierungspläne beeinflussen alle die Zuverlässigkeit der Integration. Eine gut geschriebene Schnittstelle funktioniert nicht verantwortungsvoll in einer Umgebung ohne kontrolliertes Änderungsmanagement oder Wiederherstellungsverfahren.

Die Tests müssen Geschäftsszenarien abdecken

Erfolgreich übertragene Beispieldaten in der Testumgebung bedeuten nicht, dass das System für den realen Betrieb bereit ist. Die Tests müssen Ausnahmen, wiederholte Einreichungen, fehlerhafte oder fehlende Stammdaten, die Reihenfolge von Statusänderungen und das Verhalten unter Last abdecken.

Besonders wichtig ist die geschäftsorientierte Definition der Akzeptanzkriterien. Die richtige Frage ist nicht, ob die API geantwortet hat, sondern ob ein bestimmtes Geschäftsergebnis zu einem korrekten, überprüfbaren Zustand in allen beteiligten Systemen geführt hat. Die gemeinsame Validierung durch Finanzen, Logistik, Kundenservice und IT ist kein administrativer Schritt, sondern ein Mittel zur Reduzierung des Betriebsrisikos.

Ein schrittweiser Rollout ist oft die bessere Entscheidung als eine einmalige vollständige Umstellung. Ein engerer Bestelltyp, Standort oder eine Partnergruppe kann zunächst kontrollierte Erfahrungen bieten. Dies ist nicht immer umsetzbar, zum Beispiel bei stark verknüpften Basisprozessen, aber wo möglich, reduziert es die geschäftlichen Auswirkungen von Fehlern und klärt die nächsten Schritte.

Auf welchen Grundlagen sollte die Modernisierung aufgebaut werden?

Am Anfang eines tragfähigen Integrationsprogramms sollten mindestens vier greifbare Ergebnisse erreicht werden:

• eine genehmigte Prozesskarte, die normale und außergewöhnliche Geschäftsfälle enthält;
• Datenverwaltungs- und Datenqualitätsregeln für kritische Objekte;
• dokumentierte Schnittstellenverträge mit Versionskontrolle, Fehlerbehandlung und Sicherheitsprinzipien;
• ein Betriebsplan mit Überwachung, Alarmierungen, Verantwortlichkeiten und Änderungsmanagement.

Diese verlangsamen die Entwicklung nicht. Im Gegenteil, sie reduzieren späte Neugestaltungen, die in der teuersten Phase auftreten, wenn intensiver Geschäftsdruck herrscht. Im CGAT-Ansatz ist die Integration keine separate Entwicklungsaufgabe, sondern ein gemeinsames Planungsgebiet der Prozesse, der Anwendungsarchitektur und der Infrastruktur. Eine erfolgreiche Modernisierung bewegt nicht nur mehr Daten zwischen den Systemen. Die Organisation weiß genauer, woher die Daten stammen, was im Fehlerfall passiert und wie die nächste geschäftliche Veränderung auf vorhersehbare Weise eingeführt werden kann. Dies ist die Kontrolle, auf die man beim Wachstum wirklich bauen kann.

Keine