Datacontracten voor ERP-exports

Het matchpercentage van een financiële workflow zakte op een maandagochtend fors, en er was niets uitgevallen. Een update in het weekend had in het ERP, het centrale bedrijfssysteem, het datumformaat van één exportbestand omgezet van dag-eerst naar maand-eerst. Het bestand besloeg de eerste negen dagen van maart, dus elke datum las nog als geldig. Alleen fout. Facturen werden gematcht met goederenontvangsten uit de verkeerde maand, op volle snelheid.

Na de twaalfde waren regels mislukt en had iemand binnen minuten gekeken. De stille variant had een toevallige kalender nodig, en over genoeg bestanden en upgrades is zo'n toeval niet zeldzaam. De oplossing kostte een uur. Het zoeken bijna een dag, omdat niets in het ontwerp ervan uitging dat een bestand van betekenis kon veranderen zonder van vorm te veranderen.

Elke AI-workflow hangt af van data waarvan niemand stabiliteit heeft beloofd. Het ERP kan geen afspraak tekenen, dus schrijven wij er een en dwingen die bij elke levering af. Ian Robinson beschreef consumer-driven contracts in 2006 op de site van Martin Fowler: de kant die de data gebruikt, legt vast waarop ze vertrouwt, en de afzender test daartegen. Een oud ERP draait niemands tests, dus de ontvangende kant handhaaft alleen en moet daarvoor een onderdeel kiezen dat streng genoeg is.

AI-modellen zijn te vergevingsgezind om de controle te zijn

AI-modellen kunnen overweg met een hernoemde kolom of een nieuw datumformaat. Op een systeemgrens is dat een zwakte. Gewone code die een gewijzigd bestand tegenkomt, stopt, en iemand kijkt. Een model geeft een plausibel antwoord en gaat door, en de fout duikt weken later op bij de controle van de boeken, ver van de oorzaak. Daarom is de ingang het minst vergevingsgezinde deel van het systeem. Een model mag de inhoud van een document lezen; wat de kolommen van een export betekenen, bepaalt het niet.

Jon Postels regel uit 1980, wees ruimhartig in wat je accepteert, past bij vrije tekst. Tussen systemen, lieten Martin Thomson en David Schinazi zien in RFC 9413 (2023), verbergt een tolerante ontvanger de fouten van de afzender tot ze het formaat worden. Een AI-model is de meest tolerante ontvanger ooit: elke ERP-wijziging wordt een formaat dat alleen het model begrijpt, tot het er een verkeerd begrijpt.

Wat de afspraak dekt

De meeste teams schrijven het eerste van deze vijf punten op en vergeten de rest.

Vorm. Velden, typen, verplichte waarden, één datumformaat, een vastgelegd decimaalteken en tekenconventie.

Betekenis. Wat elk veld per bron voorstelt: of de "boekingsdatum" in deze markt de documentdatum of de invoerdatum is; of creditnota's negatief binnenkomen of positief met een documentsoort. Zelfde vorm, andere betekenis: daar breekt data uit meerdere markten.

Volledigheid. Hoeveel records er moeten komen en wat ze optellen tot, met totalen van buiten de export, zoals de openstaande-postenlijst van het ERP of de totalen op het bankafschrift. Een levering met een perfecte vorm waarin honderd regels ontbreken, is de gevaarlijkste, dus houden we deze controle ook voor bronnen die "nooit regels verliezen". Ze doen het allemaal, op een dag dat niemand kijkt.

Timing. Wanneer ze binnenkomt, welke periode ze dekt, wat er gebeurt met records na de cut-off. Wie leest voordat het magazijn zijn ontvangsten vastlegt, maakt uitzonderingen die eigenlijk vertraging zijn.

Eigenaar. Wie een wijziging in de export goedkeurt, en hoe wij dat horen. Zonder dit wordt de afspraak pas na het incident gelezen.

In de praktijk is het één pagina per export, met versienummer.

Harde controles stoppen, zachte steken een hand op

Vorm en volledigheid zijn harde controles: een afwijkende levering gaat niet verder. Voor betekenis voegen we twee zachtere toe.

De eerste vergelijkt elke levering met de afgelopen weken: aandeel creditnota's, spreiding van bedragen, aantal verschillende leveranciers, verdeling van datums over de maand. De datumwissel liet een vingerafdruk achter: dag-eerst gelezen viel elke datum in maart op de derde van een maand, omdat in het dagveld nu het maandnummer stond. Een controle op de spreiding van dagen had het eerste bestand gemarkeerd vóór één match. Omdat echte zakelijke veranderingen deze cijfers ook verschuiven, stoppen ze geen levering; ze leggen haar voor aan een benoemde persoon.

De tweede is een handvol bekende records, bij elke run gecontroleerd. Leest de bekende factuur van een bekende leverancier ineens een andere datum of een ander bedrag, dan is de betekenis veranderd terwijl de vorm gelijk bleef.

Een afwijkende levering wordt in zijn geheel tegengehouden

De afspraak is code. Een afwijkende levering wordt niet deels verwerkt en niet op de gok gerepareerd, hoe voor de hand liggend de oplossing ook lijkt: stille reparaties maken van één verkeerde aanname een maand verkeerde boekingen. Ze wordt met een reden tegengehouden, en een benoemde persoon krijgt bericht. Een tegengehouden levering kost een uur, een verkeerd gelezen levering dagen en in finance een correctiespoor waar de accountant naar vraagt.

Tegenhouden legt de kosten van een wijziging ook bij wie haar kan voorkomen. Slikt de ontvangende kant wijzigingen stil, dan hoort niemand stroomopwaarts dat een upgrade iets brak, en de volgende doet hetzelfde. We melden tegengehouden leveringen maandelijks aan de eigenaar van elke export. Het aantal daalt zodra wijzigingen met aankondiging komen.

De prijs: één foute regel houdt honderden goede op. Voor alles wat naar de boekhouding schrijft, accepteren we dat. Toepassingen die alleen lezen, zoals een dashboard of een werkwachtrij, mogen losse regels afwijzen, zolang die tegen de controletotalen worden geteld.

Elke bron krijgt een eigen afspraak

Toen we vier Europese markten van Bredent Medical verbonden, elk op Dynamics 365 of een ouder systeem, bestond er niet één ERP-afspraak. Eén verbindende laag stond voor alle vier, met een afspraak per bron en een vertaling per markt naar één gedeeld model dat betrouwbaar bleef terwijl elke markt bleef veranderen. Elke nieuwe markt is een nieuwe bron en hoort met haar afspraak te komen.

Bankafschriftbestanden (MT940, ISO 20022 camt.053) hebben ook een afspraak per bank en rekeningsoort nodig: hun referenties en datums bepalen de matchkwaliteit, en banken veranderen het veldgebruik als ze van formaat wisselen.

Wijzigingen draaien parallel en worden getest met kapotte bestanden

Een geplande wijziging volgt het parallel change-patroon dat Danilo Sato in 2014 op de site van Martin Fowler beschreef: nieuw en oud draaien naast elkaar over een maandafsluiting, daarna verdwijnt de oude. Een wijziging die niet parallel kan, start met de strengste instelling voor tegenhouden.

Elke afspraak komt met goede voorbeeldbestanden en bewust kapotte: een hernoemd veld, een ander datumformaat, ontbrekende regels, een fout totaal. De controle moet de eerste accepteren en alle tweede afwijzen, bij elke wijziging. Voor een ERP-upgrade stuurt het team van de klant een testexport erdoor en weet binnen minuten wat breekt.

Met de IT van de klant en de ERP-partner spreken we ook één regel af: een wijziging in een export die een workflow voedt, gaat door hetzelfde wijzigingsproces als de workflow.

De afspraak overleeft het ERP

De meeste van onze klanten vervangen of vernieuwen hun ERP binnen een paar jaar. Het lastigste is uitzoeken op welke velden, betekenissen en schema's elk proces verderop leunt. Met deze afspraken bestaat die lijst al, getest en met versies. De afspraak die één AI-workflow moest beschermen, wordt de specificatie voor de migratie, en de tests met kapotte bestanden worden de acceptatietests voor de exports van het nieuwe systeem.

Het meeste van wat een AI-workflow betrouwbaar maakt, gebeurt voordat het model iets ziet. Een afspraak voorkomt niet dat exports veranderen. Ze maakt de verandering luid, en luide fouten zijn in een uur opgelost. Stille vindt de accountant.