Schnittstellen sind wie Beziehungen – sie brauchen Verständnis, Pflege und offene Kommunikation
Kennen Sie das? Ein IT-Projekt ist erfolgreich live gegangen, die Systeme laufen, alle sind zufrieden. Und dann, einige Zeit später, kommen Daten plötzlich nicht mehr dort an, wo sie hingehören. Spenden landen ohne Zuordnung im Klärungskonto, Kundendaten sind doppelt oder unvollständig, Berichte zeigen unterschiedliche Zahlen. Die Ursache liegt erstaunlich oft an derselben Stelle: an einer Schnittstelle.
Meine Beobachtung ist, dass Schnittstellen in Projekten zwar sorgfältig technisch geplant werden, ihre eigentliche Natur aber häufig unterschätzt wird. Denn eine Schnittstelle ist im Kern nichts anderes als eine Beziehung zwischen zwei Systemen. Und wie bei Beziehungen zwischen Menschen gilt auch hier: Am Anfang ist vieles leicht – auf Dauer wird es anspruchsvoll.
Ich bin überzeugt, dass die Parallelen zwischen Beziehungskonflikten und Schnittstellen-Problemen größer sind, als man zunächst denkt. Zwei davon möchte ich Ihnen vorstellen.
Parallele 1: Man spricht nicht dieselbe Sprache
In Beziehungen beginnen viele Konflikte nicht mit bösem Willen, sondern mit Missverständnissen. Der eine sagt "später" und meint heute Abend, die andere versteht "irgendwann diese Woche". Beide verwenden dasselbe Wort, meinen aber etwas völlig anderes – und reden aneinander vorbei.
Genau so ist es bei Schnittstellen. Zwei Systeme tauschen Daten aus, aber jedes hat seine eigene "Sprache": eigene Feldnamen, Formate, Pflichtfelder und Bedeutungen.
Ein paar typische Beispiele aus der Praxis:
• Das Quellsystem liefert "Status = aktiv", das Zielsystem kennt nur "1" und "0".
• Ein Datum kommt als 03.04.2026 an und wird als 4. März interpretiert.
• Ein Feld "Kunde" bezeichnet im CRM die Person, im ERP aber das Debitorenkonto.
Warum ist das so? Weil das Mapping von Quell- und Zielfeldern selten nur eine technische Übersetzung ist. Es ist eine fachliche Vereinbarung darüber, was ein Begriff im jeweiligen Prozess bedeutet. Fehlt diese gemeinsame Definition, "verstehen" sich die Systeme formal – inhaltlich aber nicht.
Parallele 2: Man hat sich auseinanderentwickelt
Die zweite Parallele ist subtiler. Zwei Menschen verstehen sich prima, die Beziehung funktioniert. Jahre später kommt es – gefühlt plötzlich – zu Spannungen. Niemand hat etwas "falsch" gemacht. Beide haben sich schlicht weiterentwickelt, nur eben nicht in dieselbe Richtung. Dann gilt es, wieder neu zueinanderzufinden.
Bei Schnittstellen erlebe ich genau dieses Muster regelmäßig: Die Anbindung wurde sauber aufgesetzt, ausführlich getestet, alles läuft einwandfrei. Doch ein oder zwei Jahre später häufen sich die Fehler. Was ist passiert?
Ein Hersteller hat seine API auf eine neue Version gehoben und die alte abgekündigt.
Im Quellsystem wurde ein neues Pflichtfeld oder ein neuer Wert in einer Auswahlliste eingeführt.
Ein Fachbereich hat seinen Prozess geändert, die Schnittstelle aber nicht mitgedacht.
Das eine System hat sich weiterentwickelt – das andere ist "stehen geblieben". Gerade bei SaaS-Lösungen mit regelmäßigen, teils automatischen Updates ist das keine Ausnahme, sondern der Normalfall.
Meine Erklärung: Eine Schnittstelle ist kein einmaliges Projektergebnis, sondern eine Beziehung mit Laufzeit. Wer sie nach dem Go-Live sich selbst überlässt, darf sich über eine spätere "Beziehungskrise" nicht wundern.
Was gute Beziehungen – und gute Schnittstellen – ausmacht
Aus meiner Erfahrung kommt es auf drei Dinge an, damit Schnittstellen nicht nur initial, sondern auch auf Dauer funktionieren:
Eine saubere technische Anbindung & gründliches Testing. Das gemeinsame "Vokabular" muss stimmen: Jedes Quellfeld ist eindeutig einem Zielfeld zugeordnet, Formate, Pflichtfelder und Sonderfälle sind geklärt. Getestet wird nicht nur der Idealfall, sondern auch fehlerhafte, unvollständige und ungewöhnliche Datensätze. Und es gibt ein Monitoring, das Fehler meldet, bevor es die Fachabteilung tut.
Eine vollständige und korrekte Dokumentation. Welche Daten fließen wann, in welche Richtung, nach welchen Regeln? Wer ist auf beiden Seiten verantwortlich? In Beziehungen nennt man das "klare Absprachen". Ohne Dokumentation hängt das Wissen an einzelnen Personen – und ist spätestens dann weg, wenn der Dienstleister wechselt oder ein Kollege das Unternehmen verlässt.
Kommunikation mit ausreichend Vorlauf vor Änderungen. Die wichtigste Zutat jeder langfristigen Beziehung: Man spricht miteinander, bevor man Fakten schafft. Änderungen an einem System – ein Update, ein neues Feld, ein angepasster Prozess – müssen rechtzeitig angekündigt werden, damit die Gegenseite Anpassungen vornehmen und testen kann. Dazu gehören feste Verantwortliche, ein Änderungsprozess und ein Blick in die Release-Pläne der Hersteller.
Punkt 1 ist dabei die Pflicht, Punkt 2 und 3 sind die Kür – und genau an der Kür scheitert es in der Praxis am häufigsten. Denn Dokumentation und Kommunikation passieren nicht "nebenbei". Geschrieben und gelebt werden sie von IT-Teams und Dienstleistern – aber nur, wenn die Rahmenbedingungen stimmen: klare Zuständigkeiten auf beiden Seiten der Schnittstelle, verbindliche Vereinbarungen mit Dienstleistern (z.B. Ankündigungsfristen für Änderungen) sowie Zeit und Budget, auch nach dem Projektende. Diese Rahmenbedingungen zu schaffen, ist Aufgabe der Führung.
Zusammengefasst heißt das:
Schnittstellen scheitern selten an der Technik allein. Sie scheitern daran, dass zwei Systeme bzw. die Systemverantwortlichen beider Seiten nicht dieselbe Sprache sprechen – oder daran, dass sie sich über die Zeit auseinanderentwickeln, ohne miteinander zu reden.
So einfach ist das! Schnittstellen müssen daher als das behandelt werden, was sie sind: langfristige Beziehungen mit klaren Absprachen.
P.S.: Integrierte Systemplattformen wie z.B. Dynamics 365 oder Salesforce, die zahlreiche Prozesse abdecken und damit die Zahl angebundener Drittsysteme verringern, machen das Beziehungs-Leben deutlich leichter. 😉 Denn jede Schnittstelle weniger bedeutet weniger Abstimmungsaufwand, weniger Wartung und ein Fehlerrisiko weniger.
