En agent som skriver til ERP: grensen mellom å lese og å skrive

Et innkjøpsteam kjører en pilot. En agent leser åpne behov, lagerbeholdning og leverandørenes ledetider, og i tre uker gjør den akkurat det alle håpet på: den foreslår bestillinger, innkjøperne sjekker dem, innkjøperne taster dem inn i ERP-systemet. Så stiller noen det opplagte spørsmålet. Hvorfor taster vi inn på nytt det agenten allerede har forberedt? Gi den skrivetilgang.

En mandag morgen viser ERP-systemet to innkjøpsordrer til samme leverandør, samme linjer, to minutter fra hverandre. Den ene har leverandørens bekreftelse vedlagt. Den andre er tom under hodet. Koblingen hadde fått tidsavbrudd ved første forsøk og prøvd igjen; ERP-systemet tok imot begge halvdelene av historien. Leverandøren har allerede begynt å plukke mot en av dem, og ingen i rommet kan si hvilken.

Det var ingenting galt med agentens resonnement. Det som sviktet, var skrivingen, og det er ved skrivingen hver eneste integrasjon har sviktet i tjue år. Å lese fra et registersystem er et løst og nesten risikofritt problem: en lesing kan gjentas, mellomlagres, sammenlignes og kastes. En skriving endrer posten som resten av virksomheten behandler som sannheten, og posten har ingen måte å vite om endringen var ment én gang eller to.

Hvorfor det er et annet problem å skrive tilbake

En lesing kan gjentas, en skriving kan ikke. Svikter en lesing halvveis, leser man igjen. Svikter en skriving halvveis, har man et dokument som finnes delvis, og neste forsøk enten dupliserer delen som kom frem, eller hopper over delen som ikke gjorde det. Hver avstemmingsjobb som kjører ved månedsslutt, finnes på grunn av denne asymmetrien.

En halv skriving er verre enn ingen. En innkjøpsordre med hode og uten linjer består ERP-systemets egen validering. Den låser også nummeret hos leverandøren, dukker opp blant åpne forpliktelser og blir fanget opp av neste rapport. Feilen er usynlig akkurat der det betyr noe.

Det finnes ingen angreknapp i et registersystem. Regnskapssystemer er laget slik at ingenting slettes. En feil postering rettes med en tilbakeføring, en feil faktura med en kreditnota. Hver rettelse er et nytt dokument med eget nummer og eget revisjonsspor, så en feil gjort i maskinhastighet etterlater rot i maskinhastighet som et menneske må rydde for hånd.

Et tidsavbrudd gjør én hensikt til to handlinger. Koblingen vet ikke om systemet mottok forespørselen og var treg med å svare, eller aldri mottok den. Uten en måte å si “dette er samme forespørsel som sist” peker det trygge valget og det riktige valget i motsatt retning.

Skrivingen går utenom meningen. ERP-systemet sjekker at felt er fylt ut og at koder finnes. Det vet ikke at denne kunden har en kredittsperre avtalt i et møte, eller at denne leverandøren bare kan brukes for ett anlegg. De reglene lever i mennesker, og en direkte skriving går rett forbi dem.

Ingen kan si hvem som skrev den. Integrasjonsbrukeren som opprettet ordren, er en teknisk konto som deles av hver jobb som går gjennom den. Spørsmålet “hvem bestemte dette” har ikke noe svar i posten, og det er temaet for én identitet for mennesker og agenter.

Hva som må finnes før en agent skriver

Idempotente forslag. Hver tilsiktet endring bærer én identifikator, opprettet før første forsøk. Å sende den to ganger må gi ett resultat, og mottakersiden må kunne si “allerede gjort” i stedet for å gjøre det på nytt. Kan ikke målsystemet innfri det, må laget foran gjøre det, ved å sjekke før det sender og registrere hva det sendte.

Et godkjenningssteg som et menneske eier. Ikke et varsel, en beslutning: forslaget, grunnlaget bak det og risikoen det bærer, godkjent, endret eller avvist av noen hvis navn går inn i posten. Hvilke skrivinger som trenger dette, er ikke en smakssak; det er skrevet ned per handling, og penger som forlater huset eller en inngått forpliktelse står alltid på listen.

En logg som kan spilles av på nytt. Hva agenten så, hva den konkluderte, hva som ble foreslått, hvem som godkjente det, hva som ble sendt, hva som kom tilbake. Skrevet slik at et menneske måneder senere kan følge kjeden, og strukturert slik at kjeden kan spilles av mot en kopi av systemet når noe må rekonstrueres.

En grense som ontologien gjør eksplisitt. Handlingene som finnes på hvert forretningsobjekt, tilstandene hvert objekt kan være i, reglene en endring må oppfylle og hvilke handlinger som regnes som kritiske. En agent som bare handler i de termene, kan ikke skrive noe modellen ikke tillater, og et menneske som leser modellen, ser nøyaktig hva agenten har lov til.

Avstemming etter skrivingen. Les tilbake det som landet, og sammenlign det med det som ble sendt. De fleste dobbeltposteringer blir funnet av leverandøren eller revisor; de burde bli funnet av systemet som laget dem, innen få minutter.

En test du kan gjøre i dag

Ta den nyeste integrasjonen som skriver inn i ERP- eller regnskapssystemet deres. Den trenger ikke å involvere en agent; en nettbutikk-kobling eller en opplasting fra et regneark holder. Still tre spørsmål til dem som bygde den, og skriv ned svarene.

Hva skjer hvis samme melding kommer to ganger? Hva skjer hvis overføringen svikter etter linje tre av sju? Hvor er det registrert hvem som godkjente dokumentet som ble skrevet, og på hvilket grunnlag?

Hvis dere har et testmiljø, prøv deretter de to første og tell rettelsene som trengs for å få posten tilbake til sannheten.

Hvis noe av svaret er “det ville vi fått vite fra leverandøren” eller “det ville vi sett ved månedsslutt”, er integrasjonen ikke klar for en agent, uansett hva agenten kan lese. Hullet er ikke i modellen; det er i skriveveien, og det er samme hull for et menneske som for programvare.

Hurukan trekker sin egen grense her. Agenter forbereder, utformer og foreslår innenfor nedskrevne grenser, og de handler bare i termene ontologien definerer. Det som går til regnskapssystemet, eller til et eksisterende system som holdes i drift ved siden av, går etter at et menneske har godkjent det, gjennom en kobling, med forslaget, beslutningen og utfallet i én logg. Kritiske operasjoner venter på et menneske i enhver konfigurasjon. Hvorfor et registersystem ikke kan betros å handle på egen hånd, argumenteres i et registersystem kan ikke handle; skriveveien er der Hurukan begynner.