När företaget förändras måste ontologin förändras med det

Ett företag som alltid har sålt produkter börjar sälja serviceavtal vid sidan av dem. Ett serviceavtal passar inte in i idén om en order: det finns inget att leverera, det faktureras månadsvis och det kommer med inställelsetider som företaget måste hålla. Den snabbaste lösningen är en order med en särskild typkod och några fritextfält för avtalsvillkoren.

Ett år senare räknar rapporterna serviceavtal som ordrar och blåser upp orderstocken. Lagret ser ordrar utan artiklar och frågar vad som ska plockas. En agent som ombeds förbereda veckans följesedlar tar fram en för ett underhållsavtal. Varje problem får sin egen lilla lapp, och varje lapp gör nästa ändring svårare.

Orsaken är att modellen av verksamheten behandlades som fast infrastruktur, utformad en gång och sedan försvarad. Men en ontologi är en beskrivning av hur företaget fungerar, och företaget förändras hela tiden: omorganisationer, nya produkter, förvärv, nya regelverk, nya sätt att sälja. Om modellen inte kan ändras på ett säkert sätt kommer människor att ändra den på ett osäkert sätt, en typkod i taget.

Hur en modell av verksamheten blir inaktuell

Överlastning. Ett befintligt objekt återanvänds för något nytt och skiljs ut med en flagga. Det går fort, och det innebär att varje rapport, regel och agent som läser objektet nu måste känna till flaggan.

Nödutgångar i fritext. Strukturen flyttar in i anteckningsfält. ”Avtal nr … giltigt till …” skrivs för hand enligt ett fast mönster eftersom modellen inte har någonstans att lägga det.

Tysta omdefinitioner. En region delas i två, och det gamla namnet täcker nu ett mindre område än förut. Jämförelser år för år jämför i tysthet olika saker.

Ombyggnad i ett enda stort steg. Ändringar sparas till ett stort projekt ”nästa år”. Under tiden hopar sig nödlösningarna, och projektet måste reda ut alla.

Ingen uppgift om varför. Ingen minns varför kundtyp 7 finns eller om något fortfarande använder den, så ingen vågar ta bort den.

Agenter som lär sig nödlösningen. En agent som arbetar utifrån den nuvarande modellen återskapar dess nödlösningar troget och i stor skala. En människa lärde sig till slut att bortse från spökordrarna. En agent gör det inte, om inte modellen säger det.

Ändra modellen som du ändrar kod

Varje ändring versionshanteras. Varje ändring av objekt, relationer eller regler har en upphovsperson, ett skäl, en granskning och ett versionsnummer, med samma disciplin som för källkod. Historiken kan läsas i efterhand av någon som inte var med.

Lägg till först, migrera sedan, avveckla till sist. Inför det nya objektet, serviceavtalet, med egna relationer och regler. Flytta över de befintliga posterna. Markera den gamla vägen som utfasad och ta bort den först när ingenting beror på den. Omdefiniera aldrig en befintlig betydelse på plats.

Använd giltighetsdatum. En regiondelning träder i kraft ett visst datum. Historiken behåller den gamla strukturen, rapporterna vet vilken som gällde när, och jämförelser över gränsen görs medvetet.

Visa konsekvenserna före godkännandet. Innan en ändring godkänns, lista allt som beror på det som ändras: rapporter, regler, agenter, integrationer, dokument. Den som godkänner ser hela verkningsradien, inte bara skillnaden.

Låt agenterna föreslå; låt människor godkänna. En agent kan upptäcka en nödlösning, till exempel att ordrar av en viss typ aldrig har artiklar, och föreslå ett nytt objekt som ersätter den, med underlaget. En människa som äger den delen av verksamheten beslutar.

Det är så Hurukans lager Ontologi är utformat: objekt, relationer och regler beskrivna och versionshanterade, och utbyggda i takt med att agenterna bygger ut systemet. Förslagen går genom godkännandereglerna i lagret Agentisk logik, och varje ändring granskas som gjord av en människa, en agent eller systemet, som beskrivs under Säkerhet och suveränitet. Det är under uppbyggnad. Var den första versionen av en sådan modell kommer ifrån behandlas i ditt företag har redan en ontologi.

Ett test du kan göra i dag

Hitta de tre mest använda fälten för ”typ”, ”kategori” eller ”status” i ditt huvudsystem. För vart och ett:

1. Lista varje värde det kan ha.
2. Ta reda på för varje värde när det lades till, av vem och varför.
3. Markera de värden som används till något annat än vad namnet säger.

Sök sedan i dina poster efter fritextfält som människor fyller i enligt ett fast mönster, som ”IO: …”, ”avtal nr …” eller ”giltigt till …”. Varje mönster du hittar är ett objekt eller en relation som din modell ännu inte har.

De två listorna är tillsammans en kö av ändringar som företaget redan har gjort i verkligheten men ännu inte i sin modell. Att beta av dem, en versionshanterad ändring i taget, är billigare än det stora ombyggnadsprojekt de annars skulle bli. Hurukan är utformat för att hålla den kön kort.