Schnittstellen zwischen Systemen, die nicht miteinander reden

Der Ablauf ist in vielen Häusern derselbe. Jemand meldet sich morgens im ERP an, zieht eine CSV-Datei, öffnet sie in Excel, sortiert Spalten um, löscht die Kopfzeile und tippt die Werte in das zweite System. Bei Zahlen, die sich nicht eindeutig zuordnen lassen, entscheidet Erfahrung. Die technische Verbindung zwischen Ihren Systemen ist an dieser Stelle ein Mensch mit einer Tastatur.

Das fällt selten als Problem auf, weil es funktioniert. Auffällig wird es an den Rändern. Sie erkennen Ihren Betrieb vermutlich in mindestens einem dieser Punkte wieder.

• Ein Export läuft täglich oder wöchentlich, und niemand kann genau sagen, was passiert, wenn die zuständige Person drei Wochen im Urlaub ist.
• Zwei Systeme führen dieselbe Stammdatenliste, und bei Abweichungen ist unklar, welche gilt.
• Belege werden zweimal erfasst, einmal im Vorsystem und einmal in der Buchhaltung.
• Ein Fehler fällt beim Monatsabschluss auf, und die Suche nach dem Lauf, der ihn verursacht hat, dauert länger als die Korrektur.
• Ein Feld wurde vor Jahren zweckentfremdet, und die Regel dafür steht auf einem Zettel neben dem Bildschirm.
• Die Excel-Zwischendatei hat eine Makro-Zeile, die jemand geschrieben hat, der das Haus verlassen hat.

Abtippen war meistens eine vernünftige Entscheidung. Die Systeme kamen zu unterschiedlichen Zeiten ins Haus, für eine Kopplung fehlten Budget oder Anlass, und die Menge war überschaubar. Was sich seitdem geändert hat, ist die Menge. Ein Weg, der bei dreißig Datensätzen am Tag trägt, wird bei dreihundert zum Engpass, und er wird zum Risiko, sobald das Wissen darüber an einer einzigen Person hängt.

Bevor über Technik geredet wird, lohnt eine Rechnung mit zwei Posten: der Zeit, die das Übertragen kostet, und dem, was die Fehler kosten. Beide Zahlen liegen in Ihrem Haus vor, sie stehen nur nirgends zusammen.

Der zweite Posten ist der unangenehmere. Ein falsch getippter Zählerstand wird zur falschen Abrechnung, die Abrechnung zur Reklamation, die Reklamation zu Storno, Gutschrift und einem Anruf, den jemand führen muss. Der Aufwand pro Vorfall liegt regelmäßig über dem, was die ursprüngliche Erfassung gekostet hat. Dazu kommt ein Posten, den keine Tabelle abbildet: Ihre Fachabteilung fängt an, den Zahlen nur noch bedingt zu trauen, und baut sich eigene Nebenrechnungen.

Es gibt den umgekehrten Fall, und den sagen wir Ihnen auch. Zwanzig Datensätze im Quartal, die eine Person in zehn Minuten überträgt, brauchen keine gebaute Strecke. Wenn das Quellsystem ohnehin in absehbarer Zeit abgelöst wird, gehört die Schnittstelle an das Nachfolgesystem, und die verbleibende Zeit lebt man mit dem Export. Und wenn Ihr Hersteller ein fertiges Modul für genau diese Kopplung anbietet, prüfen Sie zuerst das Modul.

Für die Frage, wie man eine Schnittstelle programmieren lässt, sind im Kern drei Wege gebräuchlich. Welcher passt, entscheidet weniger der Geschmack als das, was die beteiligten Systeme zulassen.

Dateien in einem festen Verzeichnis

CSV, XML oder JSON werden abgelegt und per SFTP abgeholt. Das kann praktisch jedes System, auch eines, das seit einem Jahrzehnt keine neue Version gesehen hat. Für Nachtläufe mit großen Mengen ist dieser Weg oft der stabilste. Seine Schwächen sind bekannt und beherrschbar: Es gibt keinen Rückkanal, Zeichensatz und Trennzeichen müssen verbindlich festgelegt sein, und eine Datei darf nie gelesen werden, während sie noch geschrieben wird. Dafür schreibt man zuerst unter einem temporären Namen und benennt am Ende um. Wer diesen Punkt übersieht, verarbeitet irgendwann eine halbe Datei.

Eine API zwischen den Systemen

REST, OData oder SOAP, je nachdem, was das Gegenüber anbietet. Der Vorteil ist die sofortige Rückmeldung: Der aufrufende Prozess erfährt im selben Moment, ob der Satz angekommen und akzeptiert wurde. Das brauchen Sie überall dort, wo ein Mensch auf ein Ergebnis wartet, etwa bei einer Verfügbarkeitsanzeige, einem Bestellstatus oder einer Anmeldung im Kundenportal. Bedingung ist, dass beide Seiten eine Schnittstelle anbieten oder sich erweitern lassen. Zu klären sind außerdem Authentifizierung, Mengenbegrenzungen pro Minute und die Frage, was passiert, wenn der Hersteller seine Version wechselt.

Middleware und Integrationsplattformen

Eine zentrale Schicht nimmt alle Datenströme auf, übersetzt Formate an einer Stelle und überwacht sie gemeinsam. Ab einer gewissen Zahl von Systemen und Strecken ist das die richtige Antwort, weil sonst jede Verbindung ihr eigenes Monitoring und ihre eigene Fehlerlogik mitbringt. Ehrlich dazugehört: Eine Integrationsplattform kostet Lizenz, Einführung und laufenden Betrieb, und sie braucht jemanden, der sie pflegt. Bei drei Systemen und zwei Verbindungen ist sie in der Regel teurer als das Problem, das sie löst.

Einen vierten Weg gibt es noch, und er ist verlockend: direkt in die Datenbank des Fremdsystems schreiben. Das ist schnell gebaut und geht regelmäßig schief, weil die Fachlogik des Systems umgangen wird und das nächste Herstellerupdate die Tabellenstruktur ändert. Diesen Weg gehen wir nur, wenn der Hersteller ihn dokumentiert freigibt.

Der Teil, der Daten von A nach B schiebt, ist in wenigen Tagen geschrieben. Der Aufwand steckt im Verhalten bei Störungen, und genau dieser Teil fehlt in günstigen Angeboten. Diese Punkte gehören in jedes Lastenheft.

• Protokoll: Jeder Lauf schreibt mit, wann er startete, wie viele Sätze gelesen, geschrieben und übersprungen wurden und aus welchem Grund. Lesbar für die Fachabteilung, nicht nur für Entwickler.
• Wiederanlauf: Bricht die Übertragung bei Satz 4.000 von 10.000 ab, darf der nächste Versuch weder von vorn beginnen noch die Lücke stehen lassen. Der Lauf merkt sich seinen Stand oder wird sauber zurückgerollt.
• Doppelerkennung: Jeder Datensatz trägt einen eindeutigen Schlüssel. Wird er zweimal übertragen, wird er einmal verbucht. Das verhindert die klassische Doppelrechnung nach einem Netzausfall.
• Alarm bei Fehlern: Eine Störung erreicht einen benannten Menschen per Mail oder Ticket, im Klartext und mit dem betroffenen Datensatz. Ebenso wichtig ist der Alarm, wenn ein Lauf gar nicht erst startet.
• Trennung technischer und fachlicher Fehler: Eine abgerissene Leitung wird automatisch wiederholt. Eine unbekannte Kundennummer gehört zu einem Menschen. Wer beides gleich behandelt, erzeugt entweder tausend identische Mails oder verliert Daten still.
• Abgleichszahlen: Vor und nach jedem Lauf wird gezählt, und die beiden Zahlen stehen im Protokoll nebeneinander. Eine Differenz, die niemand erklären kann, ist ein Befund und kein Rundungsfehler.
• Eine Testumgebung mit echten Strukturen und anonymisierten Daten. Produktivsysteme sind kein Übungsgelände.
• Feldlängen, Zeichensatz, Zeitzonen und Dezimaltrennzeichen sind schriftlich festgelegt. Umlaute und die Umstellung auf Sommerzeit stehen weit oben auf der Liste der Ursachen für nächtliche Abbrüche.

Fragen Sie jeden Anbieter, was seine Schnittstelle tut, wenn die Übertragung mitten im Lauf abbricht. Die Antwort auf diese eine Frage trennt die Angebote zuverlässiger als jeder Preisvergleich.

Wie eine Kopplung aussieht, hängt an der Fachlichkeit dahinter. Vier Beispiele aus Projekten, die laufen.

Für mexxenergie, einen Energiedienstleister in Baden-Württemberg, ist eine mandantenfähige Plattform mit vier Fachmodulen entstanden: Zählerstände und Lieferstellen, Verträge, Objekt- und Dokumentenverwaltung sowie Verbrauchs- und Kostenauswertung. Die Altbestände wurden im laufenden Betrieb migriert, mit Abgleichszahlen vor und nach jedem Lauf. Jede Differenz musste erklärt sein, bevor der nächste Lauf startete. Das ist die unspektakulärste und zugleich wichtigste Disziplin bei Datenübernahmen.

Bei Yido Performance hängen ein 3D-Konfigurator mit 152 Felgen, eine Warenwirtschaft und ein Onlineshop an denselben Daten. Dazu kommt eine automatisierte Datenpipeline für Gutachten, weil die Zuordnung von Rad zu Fahrzeug sonst von Hand aus Dokumenten gelesen werden müsste. Der Konfigurator ist die sichtbare Seite; die Arbeit lag in der Kette dahinter.

Bei Glanz K liegen vier Systeme auf einem gemeinsamen Backend. Stammdaten existieren einmal, statt in vier Ständen gepflegt zu werden, die auseinanderlaufen. Der Shop ist barrierefrei nach WCAG 2.1 AA gebaut.

Für Omid laufen Bewerbungsfunnel und CRM zusammen. Über 200.000 Leads sind dort verarbeitet worden. Bei solchen Mengen entscheidet die Doppelerkennung darüber, ob ein Vertriebsteam mit sauberen Daten arbeitet oder dieselbe Person dreimal anruft.

NOVU ist weder SAP- noch DATEV-Partner. Wir verkaufen keine Lizenzen, zertifizieren keine Add-ons und beraten Sie nicht zu Lizenzmodellen. Wenn Sie das suchen, sind Ihr Systemhaus oder Ihr Steuerbüro die richtige Adresse. Gebaut wird bei uns die Strecke davor und danach: das Vorsystem, das die Daten erzeugt, die Aufbereitung dazwischen und die Übergabe in dem Format und über den Weg, den das Zielsystem vorschreibt.

Für SAP heißt das praktisch: Daten kommen über die Wege heraus und hinein, die Ihr System dafür vorsieht, etwa OData-Services, RFC- und BAPI-Aufrufe oder IDoc-Dateien. Welcher dieser Wege bei Ihnen offen ist und wer ihn freischaltet, entscheidet Ihr SAP-Team oder dessen Dienstleister. Wir sagen, welche Felder wir brauchen, halten uns an die freigegebenen Wege und schreiben nichts an der Basis vorbei. Das ist auch in Ihrem Interesse, weil ein direkter Eingriff Ihren Wartungsvertrag berühren kann.

In der Buchhaltung läuft die Übergabe meist über Buchungsstapel im DATEV-Format, die Ihr Steuerbüro einliest. Das Dateiformat ist dabei der einfache Teil. Die Arbeit steckt in der Zuordnung: Welcher Beleg trifft welches Konto, welchen Steuerschlüssel, welche Kostenstelle. Diese Regeln legen Sie mit Ihrem Steuerberater fest, wir setzen sie um und sorgen dafür, dass der Stapel ohne Nacharbeit importiert wird. Ein Stapel, den jemand vor dem Einlesen nochmal von Hand anfasst, hat sein Ziel verfehlt. Wenn im selben Zug die Rechnungsausgabe auf ein strukturiertes elektronisches Format umgestellt wird, gehört das in dieselbe Planung.

Bei anderen ERP-Systemen gilt dasselbe Muster. Bevor die technische Machbarkeit zählt, zählt die Freigabe des Herstellers und das, was Ihr Wartungsvertrag zulässt. Diese Frage klären wir vor dem Angebot, weil sie über Weg und Aufwand entscheidet. Kommt dabei heraus, dass der Hersteller die Kopplung selbst anbietet, empfehlen wir Ihnen seine Variante.

1. Feldabgleich. Beide Seiten kommen auf den Tisch: Welches Feld heißt wo wie, welche Werte sind zulässig, was gilt bei Widersprüchen. Dieser Schritt dauert länger als das Programmieren und entscheidet über das Ergebnis.
2. Testumgebung. Aufgebaut wird mit echten Strukturen und anonymisierten Daten, während Ihr Betrieb unangetastet weiterläuft.
3. Probelauf mit Abgleichszahlen. Vor und nach jedem Lauf wird gezählt, und jede Differenz wird erklärt, bevor der nächste Schritt kommt. Bei mexxenergie sind so die Altbestände im laufenden Betrieb migriert worden.
4. Parallelbetrieb. Eine Zeit lang laufen der alte Weg und die neue Strecke nebeneinander, und die Ergebnisse werden täglich verglichen. Erst danach wird der manuelle Weg abgeschaltet.
5. Übergabe. Sie bekommen Dokumentation, eine Betriebsanleitung für den Fehlerfall und alle Zugänge. Der Code und das Repository gehören Ihnen ab Tag eins, betrieben wird in Deutschland oder der EU.
6. Betrieb. Ein benannter Ansprechpartner bleibt zuständig, auch dann, wenn ein Hersteller ein halbes Jahr später sein Format ändert.

Gebaut wird von festangestellten Entwicklern in St. Leon-Rot. Das ist bei Schnittstellen kein Nebenaspekt: Wer den Feldabgleich gemacht hat, sitzt zwei Jahre später noch am selben Ort und weiß, warum ein Feld damals so belegt wurde. Eine Freelancer-Kette oder ein Offshore-Team hinterlässt an dieser Stelle Dokumentation, aber kein Gedächtnis.

Eine einzelne Strecke zwischen zwei Systemen liegt in der Regel unter dem Band unten. In dieses Band fallen Vorhaben, bei denen mehrere Strecken zusammenkommen, die Fachabteilung eine eigene Oberfläche für Prüfung und Korrektur braucht und der überwachte Betrieb dazugehört.

Was, wenn der Hersteller unseres Systems keine Schnittstelle anbietet?

Dann bleibt in vielen Fällen der dateibasierte Weg. Fast jedes System kann Daten exportieren und importieren, auch wenn das im Handbuch unter einem anderen Namen steht. Wir prüfen zuerst, was Ihre Lizenz und Ihr Wartungsvertrag hergeben. Wenn wirklich kein freigegebener Weg existiert, sagen wir das, statt eine Lösung an der Datenbank vorbei zu bauen, die beim nächsten Update bricht.

Muss die Übertragung in Echtzeit laufen?

Selten. Echtzeit brauchen Sie dort, wo jemand unmittelbar auf ein Ergebnis wartet, etwa bei einer Bestandsanzeige im Shop. Stammdaten, Belege und Verbrauchswerte vertragen einen Nachtlauf, und der ist stabiler und günstiger im Betrieb. Legen Sie fest, wie alt ein Wert im schlechtesten Fall sein darf. Aus dieser Zahl folgt der Takt.

Wie lange dauert der Bau?

Die Bauzeit hängt weniger am Code als an Zugängen, Testdaten und Terminen mit den Herstellern der beteiligten Systeme. Ein sauberer Feldabgleich und ein freigeschalteter Testzugang verkürzen das Projekt spürbarer als jede Entwicklerstunde. Einen Termin nennen wir, sobald geklärt ist, welche Wege die beteiligten Systeme freigeben.

Wer arbeitet an unserer Schnittstelle?

Festangestellte Entwickler von uns, kein Offshoring und keine weitergereichte Auftragskette. Sie haben einen benannten Ansprechpartner, der das Projekt kennt und auch nach dem Go-live zuständig bleibt. Bei Schnittstellen zahlt sich das aus, weil Fragen typischerweise dann kommen, wenn ein Fremdsystem etwas ändert, und das ist selten in der Projektphase.

Was passiert, wenn der Hersteller seine Schnittstelle ändert?

Das kommt vor, meist mit Vorlauf. Deshalb gehört zu jeder Strecke ein Betriebsvertrag oder zumindest ein benannter Ansprechpartner bei uns. Änderungen an einer API-Version fangen wir in der Regel in der Übersetzungsschicht ab, ohne dass Ihre eigenen Systeme angefasst werden müssen.

Läuft die Schnittstelle bei uns im Haus oder in der Cloud?

Beides ist möglich, und die Entscheidung fällt oft entlang der Netzwerkregeln. Muss die Strecke auf ein System hinter Ihrer Firewall zugreifen, läuft sie meist bei Ihnen. In allen anderen Fällen betreiben wir sie auf Servern in Deutschland oder der EU. Zugangsdaten liegen verschlüsselt, und Protokolle enthalten keine personenbezogenen Inhalte, die dort nicht hingehören.

Sind Sie SAP- oder DATEV-Partner?

Nein. Wir verkaufen keine Lizenzen und übernehmen keine Zertifizierung. Wir bauen die Systeme davor und danach und übergeben die Daten in dem Format und über den Weg, den SAP oder DATEV vorsehen. Für alles innerhalb dieser Produkte bleibt Ihr Systemhaus oder Ihr Steuerbüro zuständig.

Wem gehört der Code am Ende?

Ihnen, ab dem ersten Tag. Sie bekommen das Repository, die Dokumentation und alle Zugänge. Es gibt keine Bindung an uns, die technisch erzwungen wäre. Wenn Sie später ein anderes Haus beauftragen, kann es weiterarbeiten.

Was geschieht mit Datensätzen, die fachlich falsch sind?

Sie werden weder stillschweigend verworfen noch stur wiederholt. Fehlerhafte Sätze landen in einer Liste, die Ihre Fachabteilung einsehen kann, mit Grund und Ursprungsdatensatz. Nach der Korrektur wird gezielt nachgezogen. Wer diesen Rückweg weglässt, hat nach einem halben Jahr eine unbekannte Zahl verlorener Vorgänge.

Für eine erste Einschätzung reichen wenige Angaben: die beteiligten Systeme mit Version, ein Beispielexport oder ein Screenshot der betroffenen Maske, die Menge pro Tag oder Monat, wie aktuell die Daten sein müssen und ob im Wartungsvertrag steht, welche Zugriffe erlaubt sind. Liegen diese Punkte vor, sagen wir Ihnen, welche Bauform passt und was sie kostet. Wenn ein Standardmodul Ihres Herstellers dieselbe Aufgabe erledigt, sagen wir Ihnen auch das.

Der Beispielexport ist der wertvollste dieser Punkte. An einer echten Datei sieht man in zehn Minuten, wo die Fallstricke liegen — an einer Beschreibung nicht.

• Altsysteme ablösen
• Prozesse digitalisieren
• Projekt mexxenergie
• Projekt Yido Performance
• E-Rechnung: was jetzt gilt
• Ablauf und Kosten
• Vertrauen und Sicherheit