Uw bedrijf heeft al een ontologie. Ze zit in de hoofden van mensen

Een nieuwe salescoördinator begint bij het bedrijf. In haar eerste week leert ze dat „actieve klant” drie dingen betekent. Bij sales is het iedereen die recent heeft besteld. Bij finance is het iedereen met een openstaande kredietlimiet. Bij logistiek is het iedereen met een geverifieerd afleveradres. Niemand heeft ongelijk; elk team heeft zijn eigen betekenis nodig voor zijn eigen werk.

Ze leert ook dat een spoedorder alleen voor mag gaan in de productiewachtrij als de accountmanager akkoord gaat, dat een bepaalde groep klanten nooit een deellevering mag krijgen, en dat het moederbedrijf in het systeem niet het bedrijf is dat betaalt. Niets daarvan staat in de software. Het zit in de hoofden van drie ervaren collega’s en in een spreadsheettabblad met de naam „niet verwijderen”.

Dat is een ontologie: een beschrijving van wat er in het bedrijf bestaat, hoe die dingen zich tot elkaar verhouden en welke regels ervoor gelden. Het woord klinkt academisch. Het ding zelf is alledaags, en elk bedrijf heeft er een. Het probleem is dat ze impliciet is: gedragen door mensen, doorgegeven door meekijken en maar voor een deel vastgelegd in veldnamen en spreadsheetformules. Software slaat velden op. Mensen bewaren de betekenis.

Jarenlang was dat te overzien, omdat de mensen die het werk deden de betekenis in een paar maanden opnamen. Een agent kan dat niet. Hij kan alleen volgen wat is opgeschreven. Vraag een agent de leveringen van deze week voor te bereiden, en hij stuurt vrolijk een deellevering naar precies de klant waarvan iedereen weet dat die er nooit een mag krijgen.

Waar de verborgen ontologie zichtbaar wordt

Woorden die meerdere dingen betekenen. Actief, klant, geleverd, gesloten, klaar. Elk team gebruikt hetzelfde woord voor een andere toestand, en elke rapportage over teams heen haalt ze ongemerkt door elkaar.

Regels als reflex. „We offreren voor een nieuwe klant nooit onder de kostprijs, behalve als…” De uitzondering is echt en belangrijk, en bestaat alleen als gewoonte van degene die meestal de offertes maakt.

Relaties die niemand modelleerde. Het concern dat eigenaar is van de klant, de vestiging die de order plaatst, het adres waar de goederen naartoe gaan en de entiteit die betaalt, zijn vier verschillende dingen. Het systeem heeft één klantrecord met een notitieveld.

Uitzonderingen als overlevering. De lijst met bijzondere gevallen zit bij de medewerkers die het langst in dienst zijn en wordt mondeling doorgegeven. Zijn zij op vakantie, dan gaan de uitzonderingen mis.

Spreadsheets als schaduwschema. Er verschijnen extra kolommen overal waar het systeem geen plek had voor een gegeven dat het bedrijf nodig had. Elke kolom is een stukje van het model dat buiten het model is gegroeid.

Opschrijven zonder project van twee jaar

Begin niet met een workshop over taxonomie. Begin bij besluiten, want daar wordt de betekenis gebruikt.

Kies één proces en verzamel de besluiten erin. Vraag bij elk besluit aan degene die het neemt drie dingen: waar keek u naar, welke regel paste u toe, en wat had u anders laten beslissen?

Benoem de objecten en relaties die de besluiten gebruiken. Klant, vestiging, order, levering, kredietlimiet. Schrijf daarna de relaties gewoon uit: een levering hoort bij een order, gaat naar een vestiging en wordt gefactureerd aan een entiteit.

Schrijf de regels naast de objecten waar ze over gaan, elk met een eigenaar en een reden, zodat de regel later ter discussie kan worden gesteld door iemand die er niet bij was.

Maak onenigheid expliciet in plaats van haar met geweld te beslechten. Als finance en sales iets anders bedoelen met „actief”, houd dan beide aan, onder verschillende namen. Het doel is één betekenis per woord, niet één woord voor het hele bedrijf. Dezelfde discipline toegepast op kpi’s staat beschreven in één definitie van omzet.

Laat het groeien uit gebruik. Vraag u telkens als er een uitzondering wordt afgehandeld af of het eigenlijk een nieuwe regel is. Zo ja, dan gaat die met zijn eigenaar het model in.

Dat is de taak van de laag Ontologie in Hurukan: een beschreven model van objecten, relaties en regels onder versiebeheer, dat elke module en elke agent leest. Het is ontworpen om zichzelf te ontwikkelen naarmate het systeem wordt uitgebreid: een agent stelt een nieuw object of een nieuwe regel voor, een mens keurt het goed, en de wijziging wordt vastgelegd. Omdat het bedrijf blijft veranderen, moet het model veilig kunnen veranderen. Daarover gaat verandert het bedrijf, dan moet de ontologie mee veranderen.

Een test die u vandaag kunt doen

Kies drie woorden die uw bedrijf elke dag gebruikt. „Klant”, „order” en „klaar” zijn goede kandidaten. Vraag iemand van sales, iemand van finance en iemand van operations om elk woord in één zin te definiëren, afzonderlijk en op papier, zonder te overleggen.

Leg de negen zinnen naast elkaar. Elk verschil is een stukje van uw ontologie dat in iemands hoofd zit.

Ga daarna een halfuur zitten met de meest ervaren persoon in één team en stel één vraag: wat weet u dat het systeem niet weet? Schrijf alles op wat die persoon zegt. Die lijst is de eerste versie van het model van uw bedrijf, en hij is nauwkeuriger dan de meeste specificaties die voor een nieuw systeem worden geschreven. Staat hij eenmaal op papier, dan kan hij iets worden wat software en agents kunnen lezen, en daar begint Hurukan.