---
title: "Når virksomheden ændrer sig, skal ontologien ændre sig med"
url: "https://hurukan.com/da/blog/naar-virksomheden-aendrer-sig-skal-ontologien-med"
description: "Virksomheden får en ny forretning, deler en region eller køber en konkurrent, og modellen forældes. Sådan ændrer du en ontologi uden at bryde noget."
---

# Når virksomheden ændrer sig, skal ontologien ændre sig med

21\. juli 2026·3 min. læsning·Redaktionen

To personer set fra siden, der flytter rundt på hvide kort på en stor vægtavle med forbundne bokse i et lyst arbejdsrum; ét nyt kort er markeret med en stribe blå tape

En virksomhed, der altid har solgt produkter, begynder også at sælge serviceaftaler. En serviceaftale passer ikke ind i idéen om en ordre: Der er intet at levere, den faktureres månedligt, og den kommer med svartider, virksomheden skal overholde. Den hurtigste løsning er en ordre med en særlig typekode og et par fritekstfelter til aftalevilkårene.

Et år senere tæller rapporterne serviceaftaler som ordrer og puster ordrebeholdningen op. Lageret ser ordrer uden varer og spørger, hvad der skal plukkes. En agent, der bliver bedt om at forberede ugens følgesedler, laver én til en vedligeholdelsesaftale. Hvert problem får sin egen lille lap, og hver lap gør den næste ændring sværere.

Årsagen er, at modellen af forretningen blev behandlet som fast infrastruktur — designet én gang og derefter forsvaret. Men en ontologi er en beskrivelse af, hvordan virksomheden arbejder, og virksomheden ændrer sig hele tiden: omorganiseringer, nye produkter, opkøb, ny regulering, nye måder at sælge på. Hvis modellen ikke kan ændres sikkert, ændrer folk den usikkert, én typekode ad gangen.

## Sådan forældes en model af forretningen

**Overbelastning.** Et eksisterende objekt genbruges til noget nyt og skelnes med et flag. Det går hurtigt, og det betyder, at hver rapport, regel og agent, der læser objektet, nu skal kende flaget.

**Nødudgange i fritekst.** Struktur flytter ind i notefelter. »Aftale nr. … gyldig til …« tastes i hånden efter et fast mønster, fordi modellen ikke har noget sted at lægge det.

**Stille omdefineringer.** En region deles i to, og det gamle navn dækker nu et mindre område end før. Sammenligninger år for år sammenligner i stilhed forskellige ting.

**Ombygning i ét hug.** Ændringer spares op til et stort projekt »næste år«. I mellemtiden hober nødløsningerne sig op, og projektet skal pille dem alle fra hinanden.

**Ingen registrering af hvorfor.** Ingen husker, hvorfor kundetype 7 findes, eller om noget stadig bruger den, så ingen tør fjerne den.

**Agenter, der lærer nødløsningen.** En agent, der arbejder ud fra den nuværende model, gengiver dens nødløsninger trofast og i stor skala. Et menneske lærte efterhånden at ignorere spøgelsesordrerne. Det gør en agent ikke, medmindre modellen siger det.

## Ændr modellen, som du ændrer kode

**Hver ændring versioneres.** Hver ændring af objekter, relationer eller regler har en ophavsperson, en begrundelse, en gennemgang og et versionsnummer — med samme disciplin som for kildekode. Historikken kan senere læses af en, der ikke var med.

**Tilføj først, migrér så, udfas til sidst.** Indfør det nye objekt, serviceaftalen, med sine egne relationer og regler. Flyt de eksisterende poster over. Markér den gamle vej som udfaset, og fjern den først, når intet afhænger af den. Omdefinér aldrig en eksisterende betydning på stedet.

**Brug ikrafttrædelsesdatoer.** En regionsopdeling træder i kraft på en dato. Historikken bevarer den gamle struktur, rapporterne ved, hvilken der gjaldt hvornår, og sammenligninger hen over skillelinjen foretages bevidst.

**Vis konsekvenserne før godkendelse.** Før en ændring godkendes, listes alt, der afhænger af det, der ændres: rapporter, regler, agenter, integrationer, dokumenter. Godkenderen ser rækkevidden, ikke kun forskellen.

**Lad agenter foreslå; lad mennesker godkende.** En agent kan opdage en nødløsning — for eksempel at ordrer af én type aldrig har varer — og foreslå et nyt objekt, der erstatter den, med dokumentationen. En person, der ejer den del af forretningen, beslutter.

Sådan er Hurukans [lag Ontologi](https://hurukan.com/da/system/ontologi) designet: objekter, relationer og regler beskrevet og versioneret og udvidet, efterhånden som agenter udvider systemet. Forslag går gennem godkendelsesreglerne i [laget Agentisk logik](https://hurukan.com/da/system/agentisk-logik), og hver ændring revideres som foretaget af et menneske, en agent eller systemet, som beskrevet under [Sikkerhed og suverænitet](https://hurukan.com/da/system/sikkerhed-og-suveraenitet). Det er under opbygning. Hvor den første version af sådan en model kommer fra, behandles i [din virksomhed har allerede en ontologi](https://hurukan.com/da/blog/din-virksomhed-har-allerede-en-ontologi).

## En test, du kan køre i dag

Find de tre mest brugte felter af typen »type«, »kategori« eller »status« i dit primære system. For hvert af dem:

1.  List alle de værdier, feltet kan have.
2.  Find for hver værdi ud af, hvornår den blev tilføjet, af hvem og hvorfor.
3.  Markér de værdier, der bruges til noget andet, end navnet siger.

Søg derefter i dine poster efter fritekstfelter, som folk udfylder efter et fast mønster, for eksempel »IO: …«, »aftale nr. …« eller »gyldig til …«. Hvert mønster, du finder, er et objekt eller en relation, som din model endnu ikke har.

De to lister er tilsammen et efterslæb af ændringer, som virksomheden allerede har foretaget i virkeligheden, men endnu ikke i sin model. At arbejde sig igennem dem, én versioneret ændring ad gangen, er billigere end det store ombygningsprojekt, de ellers ville blive til. [Hurukan](https://hurukan.com/da) er designet til at holde det efterslæb kort.

-   ontologi
-   versionering
-   forandringsledelse
-   datamodel

## Læs videre

-   [Én identitet for mennesker og agenter: hvem må hvad](https://hurukan.com/da/blog/en-identitet-for-mennesker-og-agenter)
-   [Den levende tilstand og registret: to hukommelser i et operativsystem for virksomheden](https://hurukan.com/da/blog/den-levende-tilstand-og-registret-to-hukommelser)