En agent der skriver til ERP: grænsen mellem at læse og skrive

Et indkøbsteam kører et pilotprojekt. En agent læser åbne behov, lagerbeholdninger og leverandørernes leveringstider, og i tre uger gør den præcis det, alle havde håbet på: den foreslår ordrer, indkøberne tjekker dem, indkøberne taster dem ind i ERP-systemet. Så stiller nogen det oplagte spørgsmål. Hvorfor taster vi det ind igen, som agenten allerede har forberedt? Giv den skriveadgang.

En mandag morgen viser ERP-systemet to indkøbsordrer til samme leverandør, samme linjer, to minutter fra hinanden. Den ene har leverandørens bekræftelse vedhæftet. Den anden er tom under hovedet. Connectoren havde fået timeout ved første forsøg og prøvet igen; ERP-systemet tog imod begge halvdele af historien. Leverandøren er allerede begyndt at plukke til den ene af dem, og ingen i lokalet kan sige hvilken.

Der var intet galt med agentens ræsonnement. Det, der fejlede, var skrivningen, og det er ved skrivningen, enhver integration har fejlet i tyve år. At læse fra et registreringssystem er et løst og næsten risikofrit problem: en læsning kan gentages, caches, sammenlignes og smides væk. En skrivning ændrer den post, som resten af virksomheden betragter som sandheden, og posten har ingen mulighed for at vide, om ændringen var ment én gang eller to.

Hvorfor det er et andet problem at skrive tilbage

En læsning kan gentages, det kan en skrivning ikke. Fejler en læsning halvvejs, læser man igen. Fejler en skrivning halvvejs, har man et dokument, der delvist findes, og næste forsøg enten dublerer den del, der kom igennem, eller springer den over, der ikke gjorde. Enhver afstemning, der kører ved månedens udgang, findes på grund af denne asymmetri.

En halv skrivning er værre end ingen. En indkøbsordre med hoved og uden linjer består ERP-systemets egen validering. Den blokerer også nummeret hos leverandøren, dukker op i de åbne forpligtelser og bliver fanget af næste rapport. Fejlen er usynlig præcis der, hvor det betyder noget.

Der findes ingen fortryd-knap i et registreringssystem. Økonomisystemer er bygget, så intet slettes. En forkert postering rettes med en tilbageførsel, en forkert faktura med en kreditnota. Hver rettelse er et nyt dokument med eget nummer og eget revisionsspor, så en fejl begået i maskinhastighed efterlader affald i maskinhastighed, som et menneske skal rydde op i hånden.

En timeout gør én hensigt til to handlinger. Connectoren ved ikke, om systemet modtog forespørgslen og var langsom til at svare, eller aldrig modtog den. Uden en måde at sige “det her er den samme forespørgsel som før” peger det sikre valg og det rigtige valg i hver sin retning.

Skrivningen går uden om betydningen. ERP-systemet tjekker, at felter er udfyldt, og at koder findes. Det ved ikke, at denne kunde er under et kreditstop aftalt på et møde, eller at denne leverandør kun må bruges til én fabrik. De regler lever i mennesker, og en direkte skrivning går lige forbi dem.

Ingen kan sige, hvem der skrev den. Integrationsbrugeren, der oprettede ordren, er en teknisk konto, som deles af hvert job, der kører igennem den. Spørgsmålet “hvem besluttede det her” har intet svar i posten, og det er emnet for én identitet for mennesker og agenter.

Hvad der skal findes, før en agent skriver

Idempotente forslag. Hver tilsigtet ændring bærer én identifikator, oprettet før det første forsøg. Sendes den to gange, skal det give ét resultat, og modtagersiden skal kunne sige “allerede gjort” i stedet for at gøre det igen. Kan målsystemet ikke honorere det, må laget foran det gøre det, ved at tjekke før det sender og registrere, hvad det sendte.

Et godkendelsestrin, som et menneske ejer. Ikke en notifikation, en beslutning: forslaget, grundlaget bag det og den risiko, det bærer, godkendt, ændret eller afvist af en person, hvis navn går ind i posten. Hvilke skrivninger der kræver det, er ikke en smagssag; det er skrevet ned pr. handling, og penge, der forlader virksomheden, eller en indgået forpligtelse står altid på listen.

En log, der kan afspilles igen. Hvad agenten så, hvad den konkluderede, hvad der blev foreslået, hvem der godkendte det, hvad der blev sendt, hvad der kom tilbage. Skrevet, så et menneske måneder senere kan følge kæden, og struktureret, så kæden kan afspilles mod en kopi af systemet, når noget skal rekonstrueres.

En grænse, som ontologien gør eksplicit. De handlinger, der findes på hvert forretningsobjekt, de tilstande, hvert objekt må være i, de regler, en ændring skal opfylde, og hvilke handlinger der regnes som kritiske. En agent, der kun handler i de termer, kan ikke skrive noget, modellen ikke tillader, og et menneske, der læser modellen, kan se præcis, hvad agenten har lov til.

Afstemning efter skrivningen. Læs tilbage, hvad der landede, og sammenlign det med det, der blev sendt. De fleste dobbeltposteringer findes af leverandøren eller revisoren; de burde findes af det system, der lavede dem, inden for få minutter.

En test du kan lave i dag

Tag den nyeste integration, der skriver ind i jeres ERP- eller økonomisystem. Den behøver ikke involvere en agent; en webshop-connector eller en upload fra et regneark er nok. Stil de folk, der byggede den, tre spørgsmål, og skriv svarene ned.

Hvad sker der, hvis den samme besked ankommer to gange? Hvad sker der, hvis overførslen fejler efter den tredje linje af syv? Hvor er det registreret, hvem der godkendte det dokument, der blev skrevet, og på hvilket grundlag?

Hvis I har et testmiljø, så prøv derefter de to første og tæl de rettelser, der skal til for at få posten tilbage til sandheden.

Hvis et af svarene er “det ville vi høre fra leverandøren” eller “det ville vi se ved månedens udgang”, er integrationen ikke klar til en agent, uanset hvad agenten kan læse. Hullet er ikke i modellen; det er i skrivevejen, og det er det samme hul for et menneske og for software.

Hurukan trækker sin egen grænse her. Agenter forbereder, udarbejder og foreslår inden for nedskrevne grænser, og de handler kun i de termer, ontologien definerer. Det, der går videre til økonomisystemet, eller til et eksisterende system, der holdes kørende ved siden af, går, efter at et menneske har godkendt det, gennem en connector, med forslaget, beslutningen og resultatet i én log. Kritiske operationer venter på et menneske i enhver konfiguration. Hvorfor et registreringssystem ikke kan betros at handle på egen hånd, argumenteres i et registreringssystem kan ikke handle; skrivevejen er der, hvor Hurukan begynder.