Et registersystem kan ikke handle

I førti år har forretningssystemer vært bygget rundt én idé: å holde en korrekt oversikt over hva virksomheten har gjort. Ordrer lagt inn, varer flyttet, fakturaer sendt, lønn utbetalt. Registreringene er autoritative, kan revideres og avstemmes, og det er lagt ned enorme mengder ingeniørarbeid i å gjøre dem pålitelige.
Samtidig er de, rent strukturelt, ute av stand til å gjøre noe som helst. Hver handling i dem begynner utenfor systemet, hos en person som bestemte noe og fortalte systemet om det i etterkant. Det er ikke et hull i produktene. Det er designet.
Hva som følger av designet
Forsinkelsen er menneskelig. Registreringene er bare oppdaterte så ofte som noen oppdaterer dem. Mellom oppdateringene er de et historisk dokument som leses som om det beskrev nået, og hver beslutning som tas ut fra dem, tas på utdatert grunnlag.
Kapasiteten er menneskelig. Organisasjonen kan behandle nøyaktig så mange transaksjoner som folkene den har, klarer å registrere. Mer kapasitet betyr flere ansatte, og derfor følger antallet administrativt ansatte omsetningen nesten overalt.
Skjønnet blir ikke fanget. Begrunnelsen for en beslutning lever i en e-post, en samtale eller noens hukommelse. Systemet lagrer utfallet og mister resonnementet, og derfor blir det samme spørsmålet diskutert på nytt hvert år.
Unntakene slipper unna. Den dokumenterte veien dekker standardtilfellet. Alt annet håndteres av erfarne folk gjennom kanaler registreringene aldri ser, så de beskriver en ryddigere virksomhet enn den som faktisk finnes.
Hva det betyr å handle i stedet
Et handlingssystem starter med de samme dataene og går motsatt vei. Jobben er ferdig, så fakturaen settes opp som utkast. Lagerbeholdningen passerer en grense, så påfyllingen forberedes. En maskin stopper, så planen bygges opp på nytt og de berørte kundene identifiseres. Systemet lager neste steg og spør om det skal gå videre.
Forskjellen er ikke automatisering i gammel forstand. Regelbasert automatisering har eksistert i tiår, og den knekker på unntakene – derfor ble den værende i utkanten. Det som har endret seg, er evnen under: Med superintelligente modeller i bunnen kan et system nå lese en ustrukturert e-post, forstå en uvanlig situasjon og lage et fornuftig utkast for et tilfelle ingen har skrevet en regel for.
Hvorfor dette krever ett register, ikke integrasjon
Et system som handler, trenger hele bildet. For å sette opp et fakturautkast trenger det ordren, leveransen, prisavtalen, kundens betalingshistorikk og om det finnes en åpen reklamasjon. Dette ligger i fire produkter, og å få det samlet på ett sted i beslutningsøyeblikket er det arbeidet integrasjon aldri helt blir ferdig med.
Derfor er svaret ett register, ikke bedre koblinger. Ikke fordi integrasjon er teknisk vanskelig, men fordi en handling krever et konsistent bilde i ett og samme øyeblikk – og synkroniserte systemer er bare konsistente i pausene mellom endringene.
Det som må følge med
Et system som handler, tar noen ganger feil, og prisen for å ta feil betales nå i maskintempo, ikke i menneskelig tempo. Den nyttige versjonen kommer derfor med tre ting på plass, og ingen av dem er valgfrie.
Grenser – hva hver agent har lov til å røre, og opp til hvilken verdi. En beslutningslogg – hva agenten så, konkluderte med og gjorde, lesbar for et menneske flere måneder senere. Og godkjenning av alt som ikke kan reverseres, fordi et feil utkast koster ett minutt, mens en feil betaling koster atskillig mer.
Får du disse tre riktig, kan autonomien forsvares. Hopper du over dem, har du bygget noe imponerende som ingen virksomhet kan stå ansvarlig for – og det er det samme som å ikke ha bygget noe som helst.
- handlingssystem
- ERP
- automatisering
- programvaredesign