Datenverträge für ERP-Exporte

An einem Montagmorgen sank die Abgleichsquote eines Finanz-Workflows deutlich, obwohl nichts ausgefallen war. Keine Fehlermeldung, kein Alarm, kein abgebrochener Job. Ein Update des ERP am Wochenende hatte in einem Export das Datumsformat von Tag-Monat auf Monat-Tag umgestellt. Der Batch umfasste die ersten neun Märztage, also ließ sich jedes Datum darin weiterhin einlesen. Nur eben falsch. Rechnungen wurden mit den Wareneingängen des falschen Monats abgeglichen, unauffällig und mit voller Geschwindigkeit.

Hätte der Batch über den Zwölften hinausgereicht, wäre jede spätere Zeile beim Einlesen gescheitert, und jemand hätte innerhalb von Minuten nachgesehen. Die stille Variante brauchte einen Zufall im Kalender. Bei genügend Exporten und genügend Upgrades sind solche Zufälle nicht mehr selten.

Die Korrektur dauerte eine Stunde. Die Ursachensuche fast einen Tag, denn das Design hatte nicht damit gerechnet, dass ein Export seine Bedeutung ändern kann, ohne sein Format zu ändern.

Jeder KI-Workflow im operativen Geschäft hängt an Daten, für deren Stabilität niemand garantiert: Exporte, die vor Jahren eingerichtet wurden, Felder, die für neue Zwecke zweckentfremdet werden, Codes, die sich von Land zu Land unterscheiden. Das ERP kann keinen Vertrag unterschreiben. Wir schreiben trotzdem einen und prüfen ihn bei jedem Batch.

Bei Consumer-Driven Contracts, wie Ian Robinson sie 2006 auf der Website von Martin Fowler beschrieben hat, legt der Nutzer eines Dienstes fest, worauf er sich verlässt, und der Anbieter testet dagegen. Ein Alt-ERP wird nie fremde Tests ausführen. Also schreibt der Nutzer den Vertrag und setzt ihn selbst durch. Die Designfrage lautet dann, welche Komponente dafür streng genug ist.

Modelle sind zu nachsichtig, um den Vertrag durchzusetzen

Sprachmodelle kommen mit unsauberen Eingaben gut zurecht. Eine umbenannte Spalte, ein neues Datumsformat, ein zusätzliches Feld: Das Modell verarbeitet es trotzdem. Viele Teams sehen darin einen Vorteil und lassen das Modell Formatänderungen abfangen.

An einer Datengrenze ist genau das ein Risiko. Ein klassischer Parser bricht bei einem geänderten Export mit einer Fehlermeldung ab, und jemand sieht nach. Ein Modell liefert bei derselben Änderung eine plausible Antwort und arbeitet weiter. Der Fehler zeigt sich Wochen später in einer Abstimmung, weit entfernt von seiner Ursache. Die Datengrenze sollte die strengste Komponente im System sein. Das Modell bekommt nur Daten, die diese Prüfung bereits bestanden haben.

Ein Modell darf den Inhalt eines Belegs lesen. Es darf nicht entscheiden, was die Spalten eines Systemexports bedeuten.

Entwickler kennen das Prinzip, das hier verletzt wird. Die Regel von Jon Postel, 1980 in die TCP-Spezifikation geschrieben, besagt: Sei großzügig in dem, was du annimmst. Sie hat frühe Netzwerke zum Laufen gebracht, und für das Lesen von Freitext ist sie bis heute ein guter Rat. An einer Grenze zwischen Systemen hat sie bekannte Kosten, die Martin Thomson und David Schinazi in RFC 9413 (2023) beschreiben: Ein nachsichtiger Empfänger verdeckt die Fehler des Senders, die Fehler werden zum faktischen Format, und niemand kann sie später beheben. Ein Sprachmodell ist der nachsichtigste Empfänger, der je in Produktion gegangen ist. Steht es an der Grenze, wird jede Änderung des ERP zu einem neuen Format, das nur das Modell versteht, bis zu dem Tag, an dem es eines missversteht.

Was der Vertrag abdeckt

Die meisten Teams halten den ersten dieser fünf Punkte fest und vergessen die übrigen.

Struktur. Felder, Typen, Formate, Pflichtwerte. Datumsangaben in einem festgelegten Format. Beträge mit festgelegtem Dezimaltrennzeichen und festgelegter Vorzeichenlogik.

Bedeutung. Was ein Feld je Quelle aussagt. Ob das „Buchungsdatum“ in diesem Markt das Belegdatum oder das Erfassungsdatum ist. Ob Gutschriften als negative Beträge kommen oder als positive Beträge mit eigener Belegart. Zwei Exporte können dieselbe Struktur haben und trotzdem Unterschiedliches bedeuten. Genau daran scheitern Daten aus mehreren Märkten.

Vollständigkeit. Wie viele Datensätze ankommen sollten und welche Summe sie ergeben müssen. Die Summen müssen aus einer anderen Quelle stammen als der Export selbst: Anzahl und Summe aus der Offene-Posten-Liste des ERP oder die Kontrollsummen, die die Bank in ihren Auszug schreibt. Ein Export, der sich selbst prüft, wird sich selbst recht geben. Ein Batch mit einwandfreier Struktur, dem hundert Zeilen fehlen, ist der gefährlichste, und wir behalten die Prüfung auch bei Quellen bei, die angeblich „nie Zeilen verlieren“. Jede Quelle verliert irgendwann Zeilen, und zwar an einem Tag, an dem niemand hinsieht.

Zeitpunkt. Wann der Batch eintrifft, welchen Zeitraum er abdeckt und was mit Datensätzen geschieht, die nach dem Stichtag gebucht werden. Ein Workflow, der einen Export liest, bevor das Lager seine Wareneingänge gebucht hat, erzeugt Ausnahmen, die in Wahrheit nur Verspätungen sind.

Zuständigkeit. Wer auf Kundenseite eine Änderung am Export freigibt und wie wir davon erfahren. Fehlt das, ist der Vertrag ein Dokument, das erst nach dem Vorfall jemand liest.

In der Praxis ist der Vertrag für einen Export eine Seite: die Felder mit Typ und Bedeutung, die Quellen der Kontrollsummen, das Lieferfenster, die Kontrollsätze, die zuständige Person und eine Versionsnummer.

Harte Prüfungen stoppen den Batch, weiche Prüfungen melden sich

Struktur- und Vollständigkeitsprüfungen sind hart: Ein Batch, der sie nicht besteht, läuft nicht weiter. Bedeutung lässt sich schwerer maschinell prüfen, deshalb ergänzen wir zwei Arten weicherer Hinweise.

Die erste ist die Gestalt der Daten statt der Datei. Jeder Batch wird mit den letzten Wochen derselben Quelle verglichen: Anteil der Gutschriften, Streuung der Beträge, Anzahl unterschiedlicher Lieferanten, Verteilung der Daten über den Monat. Eine Umstellung von Tag-Monat auf Monat-Tag hinterlässt einen Fingerabdruck. Mit Tag zuerst gelesen, fiel jedes Märzdatum in jenem Batch auf den Dritten irgendeines Monats, weil im Tagesfeld nun die Monatszahl stand. Eine Prüfung der Verteilung der Tage hätte den ersten Batch markiert, bevor ein einziger Abgleich lief. Diese Prüfungen stoppen einen Batch nicht allein, denn echte geschäftliche Veränderungen verschieben Verteilungen ebenfalls. Sie legen ihn einer namentlich benannten Person vor, bevor er verarbeitet wird.

Die zweite sind Kontrollsätze: eine Handvoll bekannter Datensätze, deren richtige Lesart feststeht und die bei jedem Lauf geprüft werden. Wird eine bekannte Rechnung eines bekannten Lieferanten plötzlich mit anderem Datum oder Betrag gelesen, hat sich die Bedeutung geändert, auch wenn die Struktur gleich geblieben ist. Kontrollsätze kommen den anbieterseitigen Tests, die Robinson beschrieben hat, auf Nutzerseite am nächsten.

Fehlerhafte Batches gehen vollständig in Quarantäne

Der Vertrag ist Code. Jeder eingehende Batch wird dagegen geprüft, bevor irgendeine Geschäftslogik läuft. Ein Batch, der die Prüfung nicht besteht, wird weder teilweise verarbeitet noch nach eigenem Ermessen repariert, auch wenn die Korrektur auf der Hand zu liegen scheint. Vermeintlich offensichtliche Korrekturen, stillschweigend angewendet, machen aus einer falschen Annahme einen Monat voller Fehlbuchungen. Der Batch geht mit Begründung in Quarantäne, und eine namentlich benannte Person wird benachrichtigt.

Wem es um Durchsatz geht, dem erscheint Quarantäne langsam. Ein abgewiesener Batch kostet eine Stunde Aufmerksamkeit. Ein falsch gelesener Batch kostet Tage an Ursachensuche und im Finanzbereich eine Spur von Korrekturbuchungen, nach der die Wirtschaftsprüfer fragen werden.

Quarantäne verlagert die Kosten einer Änderung außerdem zu denen, die sie verhindern können. Fängt der Nutzer jede Änderung stillschweigend ab, erfährt auf der Seite der Quelle niemand, dass ein Upgrade einen nachgelagerten Workflow getroffen hat, und das nächste Upgrade kann dasselbe tun. Stoppt ein Batch, landet die Frage dort, wo die Änderung entstanden ist. Wir berichten die Quarantänefälle je Quelle monatlich an die für den Export zuständige Person. In den ersten Monaten ist die Zahl unangenehm. Dann sinkt sie, weil Änderungen mit Vorankündigung kommen.

Die Quarantäne ganzer Batches hat einen echten Preis: Eine einzige fehlerhafte Zeile hält Hunderte korrekte auf. Für alles, was ins Hauptbuch bucht, nehmen wir das in Kauf. Für rein lesende Nutzungen, etwa ein Dashboard oder eine Triage-Warteschlange, kann ein Vertrag das Abweisen einzelner Zeilen erlauben, solange die abgewiesenen Zeilen gezählt werden und die Anzahl wie jede andere gegen die Kontrollsummen geprüft wird.

Jede Quelle bekommt ihren eigenen Vertrag

Als wir für Bredent Medical vier europäische Märkte angebunden haben, jeder auf Dynamics 365 oder einem Altsystem, zeigte sich: Den einen ERP-Vertrag gibt es nicht. Jeder Markt hatte sein System anders konfiguriert, nutzte eigene Codes und exportierte nach eigenem Zeitplan. Vor allen vier Systemen lag eine Integrationsschicht, mit einem Vertrag je Quelle und einem Mapping je Markt in ein gemeinsames Datenmodell. Die Verträge hielten diese Schicht stabil, während jeder Markt seine Konfiguration weiter veränderte. Das zählt vor allem, wenn ein Unternehmen neue Märkte erschließt: Jeder neue Markt ist eine neue Quelle, und er sollte gleich mit seinem Vertrag kommen.

Bankdaten brauchen dieselbe Disziplin. MT940-Auszüge und ISO-20022-Nachrichten vom Typ camt.053 enthalten Referenzen, Valuta- und Buchungsdaten, die über die Qualität des Abgleichs entscheiden, lange bevor ein Modell ins Spiel kommt. Und Banken ändern die Feldbelegung, wenn sie von einem Format aufs andere umstellen. Ein Vertrag je Bank und Kontoart, mit Kontrollsätzen, fängt das ab, bevor es in der Abstimmung auffällt.

Änderungen laufen parallel, nicht über Nacht

Exporte werden sich ändern, und manchmal ist die Änderung richtig. Der Vertrag ist versioniert, und eine geplante Änderung folgt dem Parallel-Change-Muster, das Danilo Sato 2014 auf der Website von Martin Fowler beschrieben hat: Die Quelle veröffentlicht die neue Version neben der alten, der Workflow liest beide und vergleicht sie über einen Zeitraum, der einen Monatsabschluss einschließt, und erst dann wird die alte Version abgeschaltet. Eine Änderung, die nicht parallel laufen kann, geht live, während die Quarantäne für die ersten Batches auf ihrer strengsten Stufe steht.

Verträge werden mit fehlerhaften Dateien getestet

Zu jedem Vertrag gehören Beispieldateien: korrekte und absichtlich fehlerhafte, mit umbenanntem Feld, geändertem Datumsformat, fehlenden Zeilen oder falscher Summe. Die Datengrenze muss die korrekten annehmen und jede fehlerhafte abweisen, und das läuft bei jeder Änderung in der Testsuite mit. Plant der ERP-Partner ein Upgrade, kann das Team des Kunden einen Beispielexport aus dem Testsystem durch die Prüfung schicken und weiß nach wenigen Minuten, ob etwas bricht.

Außerdem vereinbaren wir mit der IT des Kunden und dem ERP-Partner einen einzigen Satz: Eine Änderung an einem Export, aus dem ein Workflow seine Daten bezieht, durchläuft denselben Change-Prozess wie eine Änderung am Workflow selbst. Dieser Satz hat mehr Vorfälle verhindert als jeder Validierungscode, den wir geschrieben haben.

Der Vertrag überdauert das ERP

Diese Arbeit bringt einen Ertrag, den niemand budgetiert. Die meisten Unternehmen, mit denen wir arbeiten, werden ihr ERP innerhalb weniger Jahre ersetzen oder upgraden. Dann ist der schwierigste Teil des Projekts herauszufinden, worauf sich jeder nachgelagerte Prozess tatsächlich verlässt: welche Felder, in welcher Bedeutung, nach welchem Zeitplan. Ein Unternehmen mit Datenverträgen hat diese Liste bereits, aufgeschrieben, getestet und versioniert. Der Vertrag, der geschrieben wurde, um einen KI-Workflow zu schützen, wird zur Spezifikation für die Migration, und die Tests mit fehlerhaften Dateien werden zu den Abnahmetests für die Exporte des neuen Systems.

Fehler sollen auffallen

Das meiste, was einen KI-Workflow im Produktivbetrieb zuverlässig macht, geschieht, bevor das Modell irgendetwas zu sehen bekommt. Ein Vertrag verhindert nicht, dass sich Exporte ändern. Er sorgt dafür, dass die Änderung auffällt, und ein Fehler, der auffällt, ist in einer Stunde behoben. Einen stillen Fehler findet der Wirtschaftsprüfer.