Når virksomheten endres, må ontologien følge med

En virksomhet som alltid har solgt produkter, begynner å selge serviceavtaler ved siden av. En serviceavtale passer ikke inn i begrepet ordre: det er ingenting å levere, den faktureres månedlig, og den kommer med responstider virksomheten må overholde. Den raskeste løsningen er en ordre med en spesiell typekode og noen fritekstfelt for avtalevilkårene.

Et år senere teller rapportene serviceavtaler som ordrer og blåser opp ordreboken. Lageret ser ordrer uten varelinjer og spør hva de skal plukke. En agent som blir bedt om å lage ukens følgesedler, lager en for en vedlikeholdsavtale. Hvert problem får sin egen lille lapp, og hver lapp gjør neste endring vanskeligere.

Årsaken er at modellen av virksomheten ble behandlet som fast infrastruktur, utformet én gang og deretter forsvart. Men en ontologi er en beskrivelse av hvordan virksomheten fungerer, og virksomheten endrer seg hele tiden: omorganiseringer, nye produkter, oppkjøp, nye reguleringer, nye måter å selge på. Hvis modellen ikke kan endres trygt, vil folk endre den utrygt, én typekode om gangen.

Slik blir en modell av virksomheten utdatert

Overlasting. Et eksisterende objekt gjenbrukes til noe nytt, skilt ut med et flagg. Det går fort, og det betyr at hver rapport, regel og agent som leser objektet, nå må kjenne til flagget.

Fritekst som nødutgang. Strukturen flytter inn i notatfelt. «Avtale nr. … gyldig til …» tastes inn for hånd etter et fast mønster fordi modellen ikke har noe sted å legge det.

Stille omdefineringer. En region deles i to, og det gamle navnet dekker nå et mindre område enn før. Sammenligninger år mot år sammenligner i stillhet ulike ting.

Ombygging i ett jafs. Endringer spares opp til et stort prosjekt «neste år». I mellomtiden hoper midlertidige løsninger seg opp, og prosjektet må nøste opp i alle sammen.

Ingen oversikt over hvorfor. Ingen husker hvorfor kundetype 7 finnes eller om noe fortsatt bruker den, så ingen tør å fjerne den.

Agenter som lærer omveien. En agent som arbeider ut fra dagens modell, gjengir omveiene trofast og i stor skala. Et menneske lærte til slutt å overse spøkelsesordrene. En agent gjør ikke det, med mindre modellen sier det.

Endre modellen slik du endrer kode

Hver endring versjoneres. Hver endring i objekter, relasjoner eller regler har en forfatter, en begrunnelse, en gjennomgang og et versjonsnummer, med den samme disiplinen som for kildekode. Historikken kan leses senere av noen som ikke var der.

Legg til først, migrer deretter, fas ut til slutt. Innfør det nye objektet, serviceavtalen, med egne relasjoner og regler. Flytt de eksisterende postene over. Merk den gamle veien som utfaset, og fjern den først når ingenting er avhengig av den. Omdefiner aldri en eksisterende betydning på stedet.

Bruk gyldighetsdatoer. En regiondeling trer i kraft på en dato. Historikken beholder den gamle strukturen, rapportene vet hvilken som gjaldt når, og sammenligninger over grensen gjøres med vilje.

Vis konsekvensene før godkjenning. Før en endring godkjennes, list opp alt som er avhengig av det som endres: rapporter, regler, agenter, integrasjoner, dokumenter. Den som godkjenner, ser skadeomfanget, ikke bare differansen.

La agentene foreslå; la menneskene godkjenne. En agent kan legge merke til en omvei, for eksempel at ordrer av én type aldri har varelinjer, og foreslå et nytt objekt som erstatning, med dokumentasjonen. En person som eier den delen av virksomheten, bestemmer.

Slik er Ontologi-laget i Hurukan utformet: objekter, relasjoner og regler beskrevet og versjonert, og utvidet etter hvert som agentene utvider systemet. Forslag går gjennom godkjenningsreglene i Agentisk logikk-laget, og hver endring revideres som gjort av et menneske, en agent eller systemet, slik det er beskrevet under Sikkerhet og suverenitet. Det er under utvikling. Hvor den første versjonen av en slik modell kommer fra, tar vi for oss i virksomheten din har allerede en ontologi.

En test du kan gjøre i dag

Finn de tre mest brukte feltene for «type», «kategori» eller «status» i hovedsystemet ditt. For hvert av dem:

1. List opp alle verdiene feltet kan ha.
2. Finn ut for hver verdi når den ble lagt til, av hvem og hvorfor.
3. Merk verdiene som brukes til noe annet enn det navnet sier.

Søk deretter i postene etter fritekstfelt som folk fyller ut etter et fast mønster, som «PO: …», «avtale nr. …» eller «gyldig til …». Hvert mønster du finner, er et objekt eller en relasjon modellen din ennå ikke har.

De to listene er til sammen en kø av endringer virksomheten allerede har gjort i virkeligheten, men ennå ikke i modellen. Å jobbe seg gjennom dem, én versjonert endring om gangen, er billigere enn det store ombyggingsprosjektet de ellers ville blitt. Hurukan er utformet for å holde den køen kort.