Verandert het bedrijf, dan moet de ontologie mee veranderen

Een bedrijf dat altijd producten heeft verkocht, gaat daarnaast servicecontracten verkopen. Een servicecontract past niet in het idee van een order: er valt niets te leveren, het wordt maandelijks gefactureerd en het brengt responstijden mee die het bedrijf moet halen. De snelste oplossing is een order met een speciale typecode en een paar vrije tekstvelden voor de contractvoorwaarden.

Een jaar later tellen de rapportages servicecontracten als orders mee en blazen ze de orderportefeuille op. Het magazijn ziet orders zonder artikelen en vraagt wat het moet picken. Een agent die de leverbonnen voor de week moet voorbereiden, maakt er een aan voor een onderhoudscontract. Elk probleem krijgt zijn eigen kleine reparatie, en elke reparatie maakt de volgende wijziging moeilijker.

De oorzaak: het model van het bedrijf werd behandeld als vaste infrastructuur, één keer ontworpen en daarna verdedigd. Maar een ontologie is een beschrijving van hoe het bedrijf werkt, en het bedrijf verandert voortdurend: reorganisaties, nieuwe producten, overnames, nieuwe regelgeving, nieuwe manieren van verkopen. Als het model niet veilig kan veranderen, veranderen mensen het onveilig, één typecode tegelijk.

Hoe een model van het bedrijf veroudert

Overbelasting. Een bestaand object wordt hergebruikt voor iets nieuws, onderscheiden door een vlag. Dat is snel, en het betekent dat elke rapportage, regel en agent die het object leest, nu van die vlag moet weten.

Vrije tekst als nooduitgang. Structuur verhuist naar notitievelden. „Contractnr. … geldig tot …” wordt met de hand in een vast patroon getypt, omdat het model er geen plek voor heeft.

Stille herdefinities. Een regio wordt in tweeën gesplitst, en de oude naam dekt nu minder gebied dan vroeger. Vergelijkingen met vorig jaar vergelijken ongemerkt verschillende dingen.

Alles in één keer herbouwen. Wijzigingen worden opgespaard voor een groot project „volgend jaar”. Intussen stapelen de noodoplossingen zich op, en dat project moet ze allemaal weer ontrafelen.

Geen vastlegging van het waarom. Niemand weet meer waarom klanttype 7 bestaat of of het nog ergens gebruikt wordt, dus niemand durft het weg te halen.

Agents die de noodoplossing leren. Een agent die met het huidige model werkt, reproduceert de noodoplossingen getrouw en op schaal. Een mens leerde de spookorders uiteindelijk te negeren. Een agent doet dat niet, tenzij het model het zegt.

Wijzig het model zoals u code wijzigt

Elke wijziging krijgt een versie. Elke wijziging in objecten, relaties of regels heeft een auteur, een reden, een review en een versienummer, met dezelfde discipline als bij broncode. De geschiedenis is later te lezen door iemand die er niet bij was.

Eerst toevoegen, dan migreren, dan uitfaseren. Introduceer het nieuwe object, het servicecontract, met eigen relaties en regels. Zet de bestaande records over. Markeer het oude pad als verouderd en verwijder het pas als niets er meer van afhangt. Herdefinieer een bestaande betekenis nooit ter plekke.

Werk met ingangsdata. Een regiosplitsing gaat in op een datum. De historie behoudt de oude structuur, rapportages weten welke wanneer gold, en vergelijkingen over die grens heen worden bewust gemaakt.

Toon de impact vóór de goedkeuring. Zet voordat een wijziging wordt goedgekeurd alles op een rij wat afhangt van wat er verandert: rapportages, regels, agents, integraties, documenten. Wie goedkeurt, ziet de reikwijdte van de wijziging, niet alleen het verschil.

Laat agents voorstellen; laat mensen goedkeuren. Een agent kan een noodoplossing opmerken, bijvoorbeeld dat orders van één type nooit artikelen hebben, en met onderbouwing een nieuw object voorstellen om die te vervangen. Een persoon die eigenaar is van dat deel van het bedrijf beslist.

Zo is de laag Ontologie van Hurukan ontworpen: objecten, relaties en regels, beschreven en onder versiebeheer, en uitgebreid naarmate agents het systeem uitbreiden. Voorstellen doorlopen de goedkeuringsregels van de laag Agentische logica, en elke wijziging wordt vastgelegd in de audittrail als gedaan door een persoon, een agent of het systeem, zoals beschreven onder Beveiliging en soevereiniteit. Het systeem is in ontwikkeling. Waar de eerste versie van zo’n model vandaan komt, leest u in uw bedrijf heeft al een ontologie.

Een test die u vandaag kunt doen

Zoek de drie meest gebruikte velden voor „type”, „categorie” of „status” in uw hoofdsysteem. Per veld:

1. Noteer alle waarden die het kan aannemen.
2. Zoek per waarde uit wanneer die is toegevoegd, door wie en waarom.
3. Markeer de waarden die worden gebruikt voor iets anders dan hun naam zegt.

Doorzoek daarna uw records op vrije tekstvelden die mensen volgens een vast patroon invullen, zoals „PO: …”, „contractnr. …” of „geldig tot …”. Elk patroon dat u vindt, is een object of een relatie die uw model nog niet heeft.

Samen vormen de twee lijsten een achterstand van wijzigingen die het bedrijf in werkelijkheid al heeft doorgevoerd en in zijn model nog niet. Die één voor één wegwerken, telkens als wijziging met een versie, is goedkoper dan het grote herbouwproject dat er anders van komt. Hurukan is ontworpen om die achterstand kort te houden.