Ressourcen / Integration
Schnittstellen, die im Betrieb halten.
Zwei Systeme zu verbinden ist in wenigen Tagen gemacht. Die Verbindung fünf Jahre lang laufen zu lassen ist die eigentliche Arbeit. Dieser Beitrag sagt, welchen Weg Sie wann wählen, was der Betrieb kostet und woran Sie eine schlecht gebaute Schnittstelle erkennen.
Die kurze Antwort.
Nehmen Sie den einfachsten Weg, der die fachliche Anforderung erfüllt, und die Anforderung ist fast nie Echtzeit. Fragen Sie zuerst, wie alt eine Information sein darf, bevor jemand eine falsche Entscheidung trifft. Lautet die Antwort „bis zum nächsten Morgen“, dann ist ein nächtlicher Dateilauf die richtige Bauart, auch wenn der Hersteller eine schöne Programmierschnittstelle hat. Lautet sie „sofort“, brauchen Sie eine Echtzeitverbindung und damit auch alles, was danebenstehen muss: Warteschlange, Wiederholung, Überwachung.
Der zweite Satz ist genauso wichtig: Eine Schnittstelle ist kein Bauteil, sondern ein Dauerschuldverhältnis. Sie wird überwacht, sie fällt aus, sie muss angefasst werden, wenn die Gegenseite ihre Version wechselt. Wer nur den Bau beauftragt und den Betrieb nicht mitdenkt, hat in zwei Jahren eine Verbindung, die niemand mehr anfassen will.
Vier Wege, Daten zu bewegen.
Fast jede Integration im Mittelstand läuft über einen dieser vier Wege oder über eine Kombination aus zweien. Die Reihenfolge ist keine Rangfolge, sondern eine Unterscheidung nach Arbeitsweise.
REST-Schnittstelle
Wie es arbeitet
Ihr System schickt eine Anfrage über HTTP und bekommt eine Antwort in JSON zurück. Der Hersteller stellt die Befehle bereit und dokumentiert sie. Sie brauchen einen Zugang, einen Schlüssel und eine Dokumentation, die zur ausgelieferten Version passt.
Wofür es taugt
Für alles, was sofort stimmen muss: Verfügbarkeitsabfrage im Shop, Statusrückmeldung an den Kunden, ein Auftrag, der in der Maschinensteuerung ankommt, während der Disponent noch am Telefon ist.
Wo es bricht
Wenn die Gegenseite nicht erreichbar ist. Jede Echtzeitverbindung braucht eine Antwort auf die Frage, was passiert, während das andere System steht. Ohne Warteschlange und Wiederholung verlieren Sie in genau diesem Moment Daten.
Dateiaustausch
Wie es arbeitet
Ein System schreibt CSV, XML oder ein Branchenformat auf einen SFTP-Server oder in ein Verzeichnis, das andere liest es und quittiert. Der Takt ist frei wählbar: einmal je Nacht, einmal je Stunde, einmal je Schicht.
Wofür es taugt
Für Stammdaten, Buchungsstapel, Bestandsabgleiche, Lohn- und Zeitdaten. Überall dort, wo eine Verzögerung von Stunden fachlich niemanden stört.
Wo es bricht
Bei Formatänderungen ohne Ankündigung und bei halb geschriebenen Dateien, die der Empfänger zu früh einliest. Beides ist mit zwei Vorkehrungen erledigt: erst unter temporärem Namen schreiben, dann umbenennen, und jede Datei mit Satzanzahl und Prüfsumme abschließen.
Direkter Datenbankzugriff
Wie es arbeitet
Sie bekommen einen Benutzer mit Leserecht, am besten auf eigens dafür angelegte Sichten und nicht auf die Tabellen selbst. Alternativ spiegelt der Hersteller die Daten nachts in eine zweite Datenbank, die Sie abfragen dürfen.
Wofür es taugt
Für Auswertungen, Kennzahlen und Berichte. Also überall dort, wo Sie viel lesen, nichts schreiben und eine Stunde Verzögerung folgenlos ist.
Wo es bricht
Beim nächsten Update des Herstellers. Ein Tabellenname ist keine zugesagte Schnittstelle, er darf sich jederzeit ändern. Schreibend auf eine fremde Datenbank zuzugreifen ist keine Schnittstelle, sondern ein Eingriff: Sie umgehen jede Prüfung, die die Anwendung sonst vornimmt.
Middleware und Warteschlange
Wie es arbeitet
Statt jedes System mit jedem zu verbinden, geben alle ihre Nachrichten an eine Zwischenstelle. Die nimmt an, hält fest, wiederholt bei Fehlern und liefert aus, sobald der Empfänger wieder da ist.
Wofür es taugt
Sobald mehr als drei Systeme beteiligt sind oder dieselbe Information an mehrere Empfänger geht. Dann sinkt die Zahl der Verbindungen spürbar, und Sie haben eine Stelle, an der Sie nachsehen können, was wann durchgelaufen ist.
Wo es bricht
Wenn die Mitte selbst zum System wird, das niemand mehr versteht. Middleware ist ein weiteres Stück Software mit Updates, Lizenzen und Wissen, das an Personen hängt. Für zwei Systeme und einen Datenstrom ist sie zu groß.
Lesen aus einer fremden Datenbank ist ein vertretbarer Notbehelf. Schreiben ist es nicht. Die Anwendung darüber prüft Werte, füllt Folgefelder und schreibt Protokolle. All das entfällt, wenn Sie direkt in die Tabellen schreiben. Der Schaden zeigt sich meist erst Monate später im Jahresabschluss, und der Hersteller wird jede Gewährleistung dafür ablehnen. Zu Recht.
Wenn der Hersteller keine Schnittstelle anbietet.
Das ist der Normalfall bei älterer Branchensoftware, und es ist selten ein technisches Problem. Arbeiten Sie diese Reihenfolge ab und hören Sie bei der ersten Stufe auf, die trägt.
- Stufe 1
Fragen Sie schriftlich nach
Oft existiert eine Schnittstelle, sie ist nur nicht im Prospekt. Manchmal kostet sie als Modul extra. Fragen Sie nach Dokumentation, Testzugang und danach, ob die Schnittstelle Bestandteil der Wartung ist. Die Antwort brauchen Sie schriftlich, weil sie später die Grundlage für Gewährleistung ist.
- Stufe 2
Nutzen Sie den vorhandenen Export
Fast jede Software kann Listen ausgeben, oft nach Excel oder CSV, häufig auch zeitgesteuert. Ein geplanter Export in ein Verzeichnis ist eine vollwertige Schnittstelle, wenn er verlässlich läuft und das Format stabil bleibt.
- Stufe 3
Bitten Sie um einen Lesezugang auf Sichten
Der Hersteller legt Datenbanksichten an, die genau die Felder zeigen, die Sie brauchen, und sagt zu, diese Sichten stabil zu halten. Das ist der entscheidende Unterschied zum Zugriff auf Tabellen: Sie bekommen eine Zusage statt eines Zufalls.
- Stufe 4
Lassen Sie die Daten vom Berichtswesen liefern
Viele Systeme haben einen Berichtsgenerator, der Berichte planen und als Datei ablegen kann. Das ist umständlich, aber es ist dokumentiert, es ist vom Hersteller vorgesehen und es überlebt Updates.
- Stufe 5
Oberflächenautomatisierung nur als letztes Mittel
Ein Programm, das die Software bedient wie ein Mensch, bricht beim nächsten Maskenwechsel. Es kann als Überbrückung für einige Monate richtig sein, etwa während einer Ablösung. Als Dauerzustand ist es eine Verbindung, die niemand verantworten kann.
Wenn keine dieser Stufen trägt, ist das eine Aussage über die Software und gehört in Ihre Entscheidung darüber, ob Sie sie behalten. Was daraus folgt, steht in ERP ablösen oder ergänzen.
Warum der Nachtlauf per CSV oft die richtige Wahl ist.
Der Dateiaustausch gilt als altmodisch, und genau darin liegt sein Wert: Er ist seit Jahrzehnten dieselbe Sache, jeder Entwickler versteht ihn ohne Einarbeitung, und Sie brauchen keinen Spezialisten, um ihn zu reparieren. Fünf Eigenschaften machen ihn im Mittelstand so brauchbar.
- Die Übertragung ist nachvollziehbar
Die Datei von vorletzter Woche liegt noch da. Bei einem Streit darüber, was übertragen wurde, öffnen Sie sie und sehen nach. Bei einer Echtzeitverbindung brauchen Sie dafür ein Protokoll, das jemand bewusst gebaut haben muss.
- Ein Ausfall ist kein Datenverlust
Fällt der Lauf aus, liegt die Datei am nächsten Morgen immer noch da und wird nachgeholt. Fällt eine Echtzeitverbindung aus, ist der Vorgang weg, sofern niemand eine Warteschlange dazugebaut hat.
- Die Last ist planbar
Der Lauf liegt in der Nacht, wenn die Systeme frei sind. Ein Abgleich, der tagsüber im Minutentakt Anfragen stellt, belastet ein ERP, das ohnehin knapp dimensioniert ist.
- Prüfen ist einfach
Satzanzahl in der Datei, Satzanzahl im Zielsystem, Prüfsumme über die Beträge. Drei Zahlen, die stimmen müssen. Das kann eine Fachkraft ohne Entwicklerkenntnisse kontrollieren.
- Die Gegenseite kann es immer
Auch das Altsystem, das niemand mehr anfasst, auch der Lohnabrechner, auch der Spediteur. Dateiformate sind der kleinste gemeinsame Nenner, und den brauchen Sie, wenn Sie nicht bestimmen können, womit Ihre Partner arbeiten.
Das Gegenargument gilt trotzdem: Sobald ein Mensch auf die Antwort wartet, während er mit einem Kunden spricht, ist der Nachtlauf falsch. Prüfen Sie das je Datenstrom und nicht je System. In den meisten Häusern, die ich gesehen habe, braucht genau ein Strom Echtzeit und der Rest nicht.
Was eine Schnittstelle im Betrieb kostet.
Der Bau ist der kleinere Posten. Was danach kommt, taucht in keinem Angebot auf, fällt aber jedes Jahr wieder an. Rechnen Sie diese Posten in Ihre Entscheidung ein, bevor Sie die Verbindung beauftragen.
Jemand muss merken, wenn nichts mehr läuft. Das ist keine Person, die morgens nachsieht, sondern eine Prüfung, die Alarm gibt, wenn der letzte erfolgreiche Lauf zu lange her ist. Diese Prüfung will selbst gepflegt werden.
Jeder abgewiesene Satz braucht eine Person, die entscheidet, was damit geschieht. Diese Person muss sehen können, warum er abgewiesen wurde, und ihn nach der Korrektur erneut einspielen dürfen, ohne einen Entwickler zu rufen.
Ihr Spediteur stellt sein Portal um, der Lohnabrechner ändert das Satzformat, der Shop-Anbieter schaltet eine alte Fassung ab. Sie erfahren das mit Vorlauf oder ohne, aber Sie müssen reagieren, und zwar zu einem Termin, den ein anderer gesetzt hat.
Zertifikate laufen ab, Kennwörter werden gewechselt, Mitarbeiter mit Zugängen gehen. Jeder dieser Vorgänge legt eine Schnittstelle still, wenn niemand vorher weiß, dass sie daran hängt.
Wenn nur einer weiß, wo der Lauf konfiguriert ist, ist seine Urlaubsvertretung ein Betriebsrisiko. Eine Seite Dokumentation je Schnittstelle, abgelegt dort, wo Ihre IT sucht, ist billiger als jede Rekonstruktion.
Jedes Update auf einer der beiden Seiten ist ein Anlass, die Schnittstelle zu prüfen. Dafür brauchen Sie Testfälle, die jemand ohne Vorwissen durchgehen kann, und einen Testzugang auf beiden Seiten.
Beispielrechnung, keine Messung
Setzen Sie für eine einfache, gut gebaute Schnittstelle einmal im Monat zwei Stunden an: Protokolle durchsehen, liegengebliebene Sätze klären, nach einem Update prüfen. Dazu einmal im Jahr zwei bis fünf Tage für einen Versionswechsel auf einer der beiden Seiten. Beides sind angenommene Werte zur Veranschaulichung, keine erhobenen. Rechnen Sie sie mit Ihren eigenen Erfahrungswerten nach und multiplizieren Sie mit der Zahl Ihrer Schnittstellen. Das Ergebnis ist meist das stärkste Argument dafür, eine Verbindung wegzulassen.
Woran Sie eine schlecht gebaute Schnittstelle erkennen.
Gehen Sie diese Punkte für jede Verbindung durch, die Sie heute betreiben. Sie brauchen dafür keine Entwicklerkenntnisse, sondern nur jemanden, der die Fragen beantworten muss. Trifft mehr als die Hälfte zu, ist die Schnittstelle ein Kandidat für den Neubau, nicht für die nächste Reparatur.
- 01Sie erfahren von Fehlern durch den Fachbereich
Der Vertrieb meldet, dass seit Dienstag keine Aufträge mehr ankommen. Eine ordentlich gebaute Schnittstelle meldet sich selbst, bevor jemand sie vermisst.
- 02Ein zweiter Lauf erzeugt Dubletten
Wiederholen muss folgenlos sein. Jeder Satz braucht einen fachlichen Schlüssel, und der Empfänger muss entscheiden können, ob er diesen Satz schon kennt. Fehlt das, ist jeder Fehlerfall Handarbeit.
- 03Es gibt keine Stelle, an der man nachsieht
Kein Protokoll, keine Ablage der übertragenen Dateien, keine Angabe, wann der letzte Lauf erfolgreich war. Dann ist jede Klärung eine Rekonstruktion aus Erinnerung.
- 04Zugangsdaten stehen im Quelltext
Benutzer, Kennwort und Serveradresse gehören in die Konfiguration, nicht in den Code und nicht in ein Skript auf dem Rechner eines Mitarbeiters. Sonst ist der Wechsel eines Kennworts ein Entwicklungsvorgang.
- 05Niemand weiß, welche Felder übertragen werden
Es gibt keine Feldliste, keine Angabe zu Pflichtfeldern, Formaten und Wertebereichen. Die einzige Dokumentation ist der Code. Damit ist jede Änderung ein Risiko, das niemand abschätzen kann.
- 06Die Fehlerbehandlung besteht aus Ignorieren
Was nicht verarbeitet werden kann, wird übersprungen, und niemand erfährt davon. Solche Schnittstellen laufen jahrelang scheinbar störungsfrei, während die Bestände auseinanderlaufen.
- 07Sie läuft nur auf einem bestimmten Rechner
Ein Skript in einer Aufgabenplanung auf dem Arbeitsplatz eines Kollegen, ein Ordner auf einem Laufwerk, das nur er verbunden hat. Das ist Schatten-IT mit Schnittstellenfunktion.
- 08Es gibt keine Testumgebung
Änderungen werden produktiv ausprobiert, weil es keinen zweiten Zugang gibt. Fragen Sie danach, bevor Sie beauftragen: eine Schnittstelle ohne Testzugang ist eine Schnittstelle, die Sie nicht pflegen können.
Die Punkte sieben und acht führen fast immer auf denselben Befund: Die Verbindung ist nie als Teil der IT gebaut worden, sondern im Fachbereich entstanden, weil etwas fehlte. Wie Sie solche Stellen systematisch finden, steht in der Inventur der Schatten-IT.
Was vor dem Bau schriftlich feststehen muss.
Eine Schnittstelle ist eine Vereinbarung zwischen zwei Parteien, und wie jede Vereinbarung hält sie nur, wenn sie aufgeschrieben ist. Diese sechs Punkte gehören in das Dokument, bevor jemand anfängt zu bauen. Sie sind zugleich die Liste, die Sie einem Anbieter vorlegen, wenn Sie beurteilen wollen, ob er weiß, was er tut.
Feldliste mit Formaten
Jedes Feld mit Name, Typ, Länge, Pflichtangabe und Wertebereich. Dazu je Feld ein Beispielwert. Diese Liste ist der eigentliche Vertragsgegenstand.
Fachlicher Schlüssel
Woran erkennen beide Seiten denselben Vorgang wieder? Auftragsnummer, Belegnummer, Artikelnummer. Ohne diese Festlegung gibt es keinen sauberen zweiten Lauf.
Richtung und Takt
Wer schickt, wer holt, wie oft, in welchem Zeitfenster. Und ob voll oder nur die Änderungen seit dem letzten Lauf übertragen werden.
Verhalten im Fehlerfall
Wird der ganze Lauf verworfen oder nur der fehlerhafte Satz? Wie oft wird wiederholt, in welchem Abstand, und wer wird nach welcher Zeit benachrichtigt?
Versionswechsel und Vorlauf
Wie lange vorher kündigt die Gegenseite eine Formatänderung an, wie lange laufen alte und neue Fassung parallel? Wenn hier nichts steht, erfahren Sie es am Tag der Umstellung.
Zugänge und Ansprechpartner
Testzugang, Produktivzugang, Laufzeit der Zertifikate, benannte Personen auf beiden Seiten und eine Erreichbarkeit, die nicht nur aus einem Ticketformular besteht.
Diese Festlegungen entstehen nicht am Schreibtisch, sondern indem man den Ablauf dahinter aufnimmt. Das ist Phase 01 im Vorgehen, und wie Sie sich darauf vorbereiten, steht in Prozessanalyse vorbereiten. Wenn die Schnittstelle Daten aus einem Altsystem in ein neues bringt, lesen Sie zusätzlich Datenmigration: ein einmaliger Umzug hat andere Regeln als ein dauerhafter Abgleich.
Wann Sie keine Schnittstelle bauen sollten.
Eine Verbindung, die Sie nicht bauen, kostet nichts, fällt nie aus und muss nie angefasst werden. Das ist kein Scherz, sondern der Maßstab. Verzichten Sie in diesen Fällen:
- Die Datenmenge ist klein und die Erfassung dauert weniger lange als die Klärung eines Fehlerfalls kosten würde. Wer wöchentlich fünf Sätze überträgt, tippt sie schneller, als er die Überwachung pflegt.
- Eines der beiden Systeme steht auf der Abschussliste. Dann bauen Sie eine Verbindung, die Sie in einem Jahr wieder abreißen, und binden sich zugleich fester an das System, das gehen soll.
- Der fachliche Ablauf dahinter ist strittig. Eine Schnittstelle zementiert, was heute gemacht wird. Ist das Verfahren umstritten, klären Sie erst das Verfahren.
- Niemand ist für die Datenqualität zuständig. Ein Abgleich verteilt schlechte Daten schneller und in mehr Systeme. Ohne benannte Verantwortung für die Stammdaten wird die Verbindung zum Vervielfältiger.
- Der einzige Grund ist, dass die Daten doppelt stehen. Doppelte Erfassung ist ärgerlich, aber sie ist erst dann ein Geschäftsproblem, wenn daraus falsche Entscheidungen oder falsche Belege entstehen.
Unsicher, wo Sie stehen?
Wenn Sie nicht sagen können, wie viele Verbindungen zwischen Ihren Systemen heute laufen, ist das die wichtigere Frage. Der Selbsttest geht den Zustand Ihrer Systemlandschaft in kurzen Aussagen durch, in wenigen Minuten beantwortet, ohne dass jemand Sie anruft.
Häufige Fragen.
Eine Frage offen geblieben? Schildern Sie den Fall, und Sie bekommen eine Einschätzung, auch wenn sie lautet, dass Sie die Schnittstelle nicht brauchen. Zum Kontakt. Wem der Code und die Zugänge einer Schnittstelle gehören müssen, steht in Eigentum an Software; ob Sie eine Verbindung selbst bauen oder zukaufen, behandelt Make or Buy.