Een agent die naar het ERP schrijft: lezen versus schrijven

Een inkoopteam draait een pilot. Een agent leest openstaande behoefte, voorraad en levertijden van leveranciers, en drie weken lang doet hij wat iedereen hoopte: hij stelt bestellingen voor, de inkopers controleren ze, de inkopers voeren ze in het ERP in. Dan stelt iemand de voor de hand liggende vraag. Waarom typen we over wat de agent al heeft voorbereid? Geef hem schrijfrechten.

Op een maandagochtend toont het ERP twee inkooporders voor dezelfde leverancier, dezelfde regels, twee minuten na elkaar. Aan de ene hangt een bevestiging van de leverancier. De andere is leeg onder de kop. De connector was bij de eerste poging in een time-out gelopen en had het opnieuw geprobeerd; het ERP accepteerde beide helften van het verhaal. De leverancier is al begonnen met picken op een van de twee, en niemand in de kamer kan zeggen op welke.

Aan de redenering van de agent mankeerde niets. Wat faalde, was het schrijven, en op het schrijven loopt elke integratie al twintig jaar stuk. Lezen uit een registratiesysteem is een opgelost en vrijwel risicoloos probleem: een leesactie kun je herhalen, cachen, vergelijken en weggooien. Een schrijfactie verandert het record dat de rest van het bedrijf als de waarheid beschouwt, en het record kan onmogelijk weten of de wijziging een keer of twee keer bedoeld was.

Waarom terugschrijven een ander probleem is

Lezen is herhaalbaar, schrijven niet. Mislukt een leesactie halverwege, dan lees je opnieuw. Mislukt een schrijfactie halverwege, dan heb je een document dat er gedeeltelijk is, en de volgende poging dupliceert ofwel het deel dat is aangekomen, ofwel slaat het deel over dat ontbreekt. Elke afstemming die aan het einde van de maand draait, bestaat door deze asymmetrie.

Een gedeeltelijke schrijfactie is erger dan geen. Een inkooporder met een kop en zonder regels komt door de eigen validatie van het ERP. Hij blokkeert ook het nummer bij de leverancier, verschijnt in de openstaande verplichtingen en wordt opgepikt door het volgende rapport. De fout is onzichtbaar precies waar het ertoe doet.

In een registratiesysteem bestaat geen ongedaan maken. Boekhoudsoftware is zo ontworpen dat er niets wordt verwijderd. Een foute boeking wordt gecorrigeerd met een tegenboeking, een foute factuur met een creditnota. Elke correctie is een nieuw document met een eigen nummer en een eigen auditspoor, zodat een fout op machinesnelheid puin op machinesnelheid achterlaat dat een mens met de hand moet opruimen.

Een time-out maakt van een bedoeling twee acties. De connector weet niet of het systeem het verzoek heeft ontvangen en traag antwoordde, of het nooit heeft ontvangen. Zonder een manier om te zeggen “dit is hetzelfde verzoek als daarnet” wijzen de veilige keuze en de juiste keuze in tegengestelde richtingen.

De schrijfactie gaat om de betekenis heen. Het ERP controleert of velden gevuld zijn en codes bestaan. Het weet niet dat deze klant een kredietblokkade heeft die in een vergadering is afgesproken, of dat deze leverancier alleen voor een vestiging gebruikt mag worden. Die regels leven in mensen, en een directe schrijfactie loopt er recht langs.

Niemand kan zeggen wie het heeft geschreven. De integratiegebruiker die de order aanmaakte, is een technisch account dat wordt gedeeld door elke job die erdoorheen loopt. De vraag “wie heeft dit besloten” heeft geen antwoord in het record, en dat is het onderwerp van een identiteit voor mensen en agents.

Wat er moet bestaan voordat een agent schrijft

Idempotente voorstellen. Elke beoogde wijziging draagt een identificatie, aangemaakt voor de eerste poging. Twee keer versturen moet een resultaat opleveren, en de ontvangende kant moet “al gedaan” kunnen zeggen in plaats van het nog eens te doen. Kan het doelsysteem dat niet, dan moet de laag ervoor het doen, door te controleren voordat ze verstuurt en vast te leggen wat ze heeft verstuurd.

Een goedkeuringsstap waar een mens eigenaar van is. Geen melding, een beslissing: het voorstel, het bewijs erachter en het risico dat het draagt, goedgekeurd, aangepast of afgewezen door iemand wiens naam in het record komt. Welke schrijfacties dit nodig hebben is geen kwestie van smaak; het staat per actie opgeschreven, en geld dat vertrekt of een aangegane verplichting staat altijd op de lijst.

Een herspeelbaar logboek. Wat de agent zag, wat hij concludeerde, wat werd voorgesteld, wie het goedkeurde, wat werd verstuurd, wat terugkwam. Zo geschreven dat een mens maanden later de keten kan volgen, en zo gestructureerd dat de keten opnieuw kan worden afgespeeld tegen een kopie van het systeem wanneer iets gereconstrueerd moet worden.

Een grens die de ontologie expliciet maakt. De acties die op elk bedrijfsobject bestaan, de toestanden waarin elk object mag verkeren, de regels waaraan een wijziging moet voldoen en welke acties als kritiek gelden. Een agent die alleen in die termen handelt, kan niets schrijven wat het model niet toestaat, en een mens die het model leest, ziet precies wat de agent mag doen.

Afstemming na het schrijven. Teruglezen wat is aangekomen en het vergelijken met wat is verstuurd. De meeste dubbele boekingen worden gevonden door de leverancier of de accountant; ze zouden gevonden moeten worden door het systeem dat ze maakte, binnen minuten.

Een test die u vandaag kunt doen

Neem de nieuwste integratie die naar uw ERP of boekhoudprogramma schrijft. Er hoeft geen agent bij betrokken te zijn; een webshopconnector of een spreadsheetupload volstaat. Stel de mensen die hem bouwden drie vragen en schrijf de antwoorden op.

Wat gebeurt er als hetzelfde bericht twee keer aankomt? Wat gebeurt er als de overdracht mislukt na de derde van zeven regels? Waar staat vastgelegd wie het geschreven document heeft goedgekeurd, en op welk bewijs?

Probeer daarna, als u een testomgeving hebt, de eerste twee en tel de correcties die nodig zijn om het record weer bij de waarheid te brengen.

Luidt een van de antwoorden “dat zouden we van de leverancier horen” of “dat zouden we aan het einde van de maand zien”, dan is de integratie niet klaar voor een agent, wat de agent ook kan lezen. Het gat zit niet in het model; het zit in het schrijfpad, en het is hetzelfde gat voor een mens als voor software.

Hurukan trekt hier zijn eigen grens. Agents bereiden voor, stellen op en stellen voor binnen opgeschreven grenzen, en ze handelen alleen in de termen die de ontologie definieert. Wat vertrekt naar het boekhoudprogramma, of naar een bestaand systeem dat ernaast blijft draaien, gaat nadat een mens het heeft goedgekeurd, via een connector, met het voorstel, de beslissing en de uitkomst in een logboek. Kritieke bewerkingen wachten in elke configuratie op een mens. Waarom een registratiesysteem niet te vertrouwen is om uit zichzelf te handelen, wordt beargumenteerd in een registratiesysteem kan niet handelen; het schrijfpad is waar Hurukan begint.