Wenn die Schnittstelle zwischen zwei Systemen hakt: was vor der Reparatur geklärt sein sollte

„Die Schnittstelle funktioniert nicht richtig.“

Diesen Satz hört man, wenn Daten zwischen zwei Systemen nicht so ankommen, wie sie sollen. Aufträge fehlen, Mengen stimmen nicht, ein Status passt nicht zum anderen. Am Ende prüft jemand von Hand nach, obwohl genau das die Schnittstelle überflüssig machen sollte.

Der naheliegende Verdacht ist die Technik. Manchmal stimmt er. Manchmal liegt die Ursache woanders. Bevor man repariert, lohnt es sich, beides auseinanderzuhalten.

Was technisch schiefgehen kann

Technische Fehlerquellen gibt es reichlich. Ein Datumsformat wird auf beiden Seiten unterschiedlich gelesen. Ein Feld ist im einen System Pflicht und im anderen optional. Ein Sonderzeichen bricht die Übertragung ab. Ein System ist kurz nicht erreichbar, und niemand merkt, dass in dieser Zeit Daten verloren gegangen sind. Ein Hersteller ändert mit einem Update seine Schnittstelle.

Solche Fehler sind ärgerlich, aber greifbar. Man kann ihnen technisch nachgehen und sie meist gezielt beheben. Eine gut gebaute Schnittstelle meldet sie außerdem, statt still Daten zu verlieren, und weiß, was zu tun ist, wenn die Gegenseite nicht antwortet.

Was die Daten bedeuten

Schwieriger wird es, wenn technisch alles korrekt übertragen wird und das Ergebnis trotzdem nicht stimmt.

Ein typisches Bild: Der Vertrieb arbeitet mit einem Programm für Angebote, die Produktion plant mit einem anderen System. Ist ein Auftrag „bestätigt“, geht er an die Produktion. Der Vertrieb meint damit, dass der Kunde zugesagt hat. Die Produktion liest „bestätigt“ als „kann eingeplant werden“ und plant Aufträge ein, bei denen Material und Termin noch gar nicht geklärt sind. Die Schnittstelle überträgt das Feld fehlerfrei. Das Problem steckt in einer Annahme, die jede Seite für selbstverständlich hält.

Ähnlich ist es bei der Frage, welches System im Zweifel recht hat, wenn eine Adresse oder ein Preis in beiden gepflegt wird. Oder ab wann ein Angebot eigentlich ein Auftrag ist.

Solche Fragen sammeln sich oft genau an der Stelle, an der aus einem Angebot ein Fertigungsauftrag wird. Dort ist häufig niemand richtig zuständig, weil diese Stelle in keinem Organigramm auftaucht. Gerade im Mittelstand funktioniert das lange erstaunlich gut, über kurze Wege und Zuruf. Erst wenn eine Schnittstelle den Zuruf ersetzen soll, fällt auf, dass die Regel nie aufgeschrieben wurde.

Was vor dem Bau geklärt sein sollte

Ob eine Schnittstelle neu gebaut oder repariert wird, vorher sollten ein paar Fragen beantwortet sein:

  • Welche Daten müssen wann von wo nach wo?
  • Was bedeuten die wichtigsten Felder und Zustände auf beiden Seiten?
  • Welches System hat im Zweifel recht?
  • Wer verlässt sich auf die übertragenen Daten, und was passiert, wenn etwas nicht ankommt?
  • Wer ist zuständig, wenn ein Fehler gemeldet wird?

Die Antworten bestimmen auch, wie viel Schnittstelle nötig ist. Nicht jede Verbindung muss in Echtzeit laufen. Manchmal reicht ein nächtlicher Abgleich. Auch muss nicht jeder Sonderfall automatisch verarbeitet werden. Für seltene Ausnahmen kann es reichen, dass die Schnittstelle sie meldet und jemand sie von Hand erledigt. Und wenn nur ein paar Datensätze im Monat übertragen werden, kann ein sauberer Export die vernünftigere Lösung sein als eine Schnittstelle, die gebaut, überwacht und gepflegt werden muss. Entscheidend ist, was der Prozess tatsächlich braucht.

Wer für den ganzen Weg zuständig ist

Bei einer gestörten Schnittstelle hat oft jeder seinen Teil richtig gemacht. Der Vertrieb hat seine Daten gepflegt, die Produktion ihre. Die IT hat umgesetzt, was im Ticket stand. Und trotzdem hakt es genau dort, wo alles zusammenkommen müsste.

Verantwortung für einzelne Teile lässt sich gut verteilen. Für das Ergebnis braucht es jemanden im Unternehmen, der den ganzen Weg im Blick hat, vom Angebot bis zum Fertigungsauftrag, über alle Systeme hinweg. Das muss keine neue Stelle sein. Es sollte aber klar sein, wer entscheidet, wenn zwei Bereiche „bestätigt“ unterschiedlich verstehen.

Hakt bei Ihnen eine Verbindung zwischen zwei Systemen, schaue ich mir beides an: die Technik und die Annahmen dahinter. Ich verfolge den Weg der Daten über alle beteiligten Systeme, kläre mit den Bereichen, was die Daten bedeuten, und baue danach, was der Prozess wirklich braucht. Mehr dazu unter Systeme verbinden.