Ein Datenvertrag für jeden ERP-Export

An einem Montagmorgen sank die Abgleichsquote eines Finanz-Workflows deutlich, obwohl nichts ausgefallen war. Keine Fehlermeldung, kein Alarm, kein abgebrochener Job. Am Wochenende hatte der ERP-Partner ein Update eingespielt, das in einem Export das Datumsformat von Tag-Monat auf Monat-Tag umstellte. Jedes Datum bis zum Zwölften ließ sich weiterhin einlesen. Nur eben falsch. Rechnungen wurden mit den Wareneingängen der falschen Woche abgeglichen, unauffällig und mit voller Geschwindigkeit.

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.

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. Ob eine Menge in Kartons oder in Paletten angegeben ist. 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. Wir lassen uns von der Quelle Kontrollsummen liefern, Satzanzahl und Betragssumme, unabhängig vom Export erzeugt, und gleichen sie bei jedem Batch ab. Ein Batch mit einwandfreier Struktur, dem hundert Zeilen fehlen, ist der gefährlichste. 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.

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.

Bedeutung lässt sich nicht immer maschinell prüfen. Deshalb arbeiten wir mit Kontrollsätzen: einer 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. An jenem Montag hätte ein Kontrollsatz die Datumsumstellung innerhalb von Minuten aufgedeckt.

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.

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.

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.