Kernaussage gleich vorweg
Integration ohne Brüche ist kein Technikprojekt, sondern ein Beziehungsaufbau zwischen Systemen, Daten und Menschen. Kennen Sie das Gefühl, wenn eine neue Schnittstelle zwar technisch läuft, aber das Team trotzdem weiter umständlich kopiert und einfügt? In meiner Erfahrung liegt das Problem selten an der API, sondern daran, wie Prozesse, Verantwortlichkeiten und Datenpflege zusammenspielen.
Warum «ohne Brüche» mehr bedeutet als «läuft»
Was verstehen Sie unter einem Bruch in der Integration? Für manche ist es ein Fehler in der Datenübertragung. Für mich ist es jede Stelle, an der ein Mitarbeiter aufwacht und sagen muss: «Jetzt muss ich es anders machen.» Solche Brüche entstehen, wenn Systeme zwar verknüpft, die Prozesse aber nicht angepasst wurden. Oder wenn Stammdaten in mehreren Systemen divergieren und niemand klar verantwortlich ist. In Kundenprojekten sehe ich oft, dass die technische Umsetzung vor den operativen Abläufen geplant wird. Das führt zu Lösungen, die formal korrekt sind, aber im Alltag Arbeitsschritte erzeugen, statt sie zu reduzieren.
Drei typische Fehler aus der Praxis
Ein häufiger Fehler ist, Integration als Einmalprojekt zu denken und nicht als fortlaufenden Prozess. Nach dem Go‑Live bleibt die Verantwortung diffus; niemand pflegt Mappings oder prüft Geschäftsregeln. Ein zweiter Fehler ist fehlende Transparenz über Datenherkunft: Wenn niemand weiss, welches System die Quelle der Wahrheit ist, entstehen widersprüchliche Kundenstämme und doppelte Arbeit. Ein dritter Fehler ist unklare Rollen beim Ausnahmenmanagement: Wenn Fehler auftreten, wissen die Mitarbeitenden nicht, wen sie informieren oder wie sie temporär weiterarbeiten sollen. Solche Fehler sind konkret, sichtbar und kosten im Tagesgeschäft Zeit und Vertrauen.
Menschen und Prozess vor Technologie
Haben Sie schon mal erlebt, dass eine neue Integration zwar Daten liefert, aber Entscheidungsgrundlagen verschlechtert? In solchen Fällen hilft es, zuerst die Prozesse zu skizzieren: Wer braucht welche Daten, wann und in welcher Qualität? In meinen Beratungen beginne ich deshalb mit Workshops, in denen Mitarbeitende ihre aktuellen Arbeitsschritte beschreiben. So werden versteckte Übergabepunkte sichtbar. Danach passen wir die technischen Mappings an die Realität an, nicht umgekehrt. Das reduziert Brüche, weil Technik die bestehende Arbeit unterstützt und schrittweise automatisiert statt sie radikal zu ersetzen.
Kleine Eingriffe mit grossem Effekt
Welche Massnahmen haben bei meinen Kunden am meisten gebracht? Eine klare Festlegung, welches System für welche Stammdaten verantwortlich ist, brachte oft sofort sichtbare Verbesserungen. Ebenso half ein einfaches Eskalationsprotokoll für Integrationsfehler, damit Mitarbeitende wissen, wen sie kontaktieren. Und schliesslich erwies sich eine kurze, wiederkehrende Qualitätssicht auf Daten als sehr wirkungsvoll: Fünfzehn Minuten pro Woche mit den Verantwortlichen reichen häufig, um Abweichungen früh zu entdecken. Das sind keine grossen Investitionen, aber sie richten Prozesse auf Kontinuität aus.
Was Sie diese Woche anders machen können
Kennen Sie den Unterschied zwischen einem Projektabschluss und betrieblicher Kontinuität? In den nächsten 14 bis 30 Tagen empfehle ich, gemeinsam mit Ihrem Kernteam zu prüfen, welches System die Quelle der Wahrheit für drei kritische Datentypen ist, diese Entscheidung schriftlich festzuhalten und eine kurze Verantwortungsmatrix zu erstellen, damit bei Integrationsfehlern schnell entschieden werden kann, wer handelt. Parallel dazu laden Sie eine kurze, zwanzigminütige wöchentliche Data‑Review‑Sitzung ein, in der echte Datenbeispiele geprüft und Abweichungen notiert werden; das schafft Feedbackloops und verhindert, dass kleine Brüche zu grossen Problemen werden. Wenn Sie möchten, kann ich Ihnen zeigen, wie solche Workshops in ein bis zwei Terminen praktisch durchgeführt werden.
