---
title: "Gdy firma się zmienia, ontologia musi zmienić się razem z nią"
url: "https://hurukan.com/pl/blog/gdy-firma-sie-zmienia-ontologia-tez"
description: "Firma dodaje usługi, dzieli region albo kupuje konkurenta, a jej model biznesu traci aktualność. Jak zmieniać ontologię, nie psując tego, co od niej zależy."
---

# Gdy firma się zmienia, ontologia musi zmienić się razem z nią

21 lipca 2026·3 min czytania·Redakcja

Dwie osoby widziane z boku przestawiają białe karty na dużej tablicy ściennej z połączonymi prostokątami w jasnej przestrzeni roboczej, jedna nowa karta oznaczona paskiem niebieskiej taśmy

Firma, która zawsze sprzedawała produkty, zaczyna sprzedawać obok nich umowy serwisowe. Umowa serwisowa nie pasuje do pojęcia zamówienia: nie ma czego dostarczyć, rozlicza się ją co miesiąc, a do tego firma musi dotrzymać czasów reakcji. Najszybsze rozwiązanie to zamówienie ze specjalnym kodem typu i kilkoma polami tekstowymi na warunki umowy.

Rok później raporty liczą umowy serwisowe jako zamówienia i zawyżają portfel. Magazyn widzi zamówienia bez pozycji i pyta, co ma kompletować. Agent poproszony o przygotowanie dokumentów dostawy na ten tydzień tworzy jeden dla umowy serwisowej. Każdy problem dostaje własną małą łatkę, a każda łatka utrudnia następną zmianę.

Przyczyna jest taka, że model biznesu potraktowano jak stałą infrastrukturę, zaprojektowaną raz, a potem bronioną. Tymczasem ontologia to opis tego, jak firma działa, a firma zmienia się cały czas: reorganizacje, nowe produkty, przejęcia, nowe przepisy, nowe sposoby sprzedaży. Jeśli modelu nie da się zmieniać bezpiecznie, ludzie będą go zmieniać niebezpiecznie, po jednym kodzie typu naraz.

## Jak model biznesu traci aktualność

**Przeciążanie.** Istniejący obiekt używany jest do czegoś nowego i odróżniany flagą. To szybkie, ale odtąd każdy raport, reguła i agent, które czytają ten obiekt, muszą wiedzieć o fladze.

**Furtki w polach tekstowych.** Struktura przenosi się do pól „uwagi”. „Umowa nr … ważna do …” wpisuje się ręcznie według stałego wzoru, bo model nie ma na to miejsca.

**Ciche zmiany znaczenia.** Region dzieli się na dwa, a stara nazwa obejmuje mniejszy obszar niż wcześniej. Porównania rok do roku po cichu zestawiają różne rzeczy.

**Wielka przebudowa.** Zmiany odkłada się na duży projekt „w przyszłym roku”. Tymczasem obejścia się mnożą, a projekt musi potem rozplątać je wszystkie.

**Brak zapisu, dlaczego.** Nikt nie pamięta, po co istnieje typ klienta 7 ani czy coś go jeszcze używa, więc nikt nie odważy się go usunąć.

**Agenci uczący się obejść.** Agent pracujący na obecnym modelu wiernie i na dużą skalę powtarza jego obejścia. Człowiek w końcu nauczył się ignorować widmowe zamówienia. Agent tego nie zrobi, dopóki model mu tego nie powie.

## Zmieniaj model tak, jak zmienia się kod

**Każda zmiana jest wersjonowana.** Każda zmiana obiektów, relacji czy reguł ma autora, powód, przegląd i numer wersji, z tą samą dyscypliną, którą stosuje się do kodu źródłowego. Historię może później przeczytać ktoś, kogo przy niej nie było.

**Najpierw dodaj, potem przenieś, na końcu wycofaj.** Wprowadź nowy obiekt, umowę serwisową, z własnymi relacjami i regułami. Przenieś istniejące rekordy. Oznacz starą ścieżkę jako wycofywaną i usuń ją dopiero wtedy, gdy nic od niej nie zależy. Nigdy nie zmieniaj istniejącego znaczenia w miejscu.

**Używaj dat obowiązywania.** Podział regionu wchodzi w życie określonego dnia. Historia zachowuje starą strukturę, raporty wiedzą, która obowiązywała kiedy, a porównania przez tę granicę robi się świadomie.

**Pokaż skutki przed akceptacją.** Zanim zmiana zostanie zatwierdzona, wypisz wszystko, co zależy od tego, co się zmienia: raporty, reguły, agentów, integracje, dokumenty. Zatwierdzający widzi zasięg zmiany, a nie tylko samą różnicę.

**Agenci proponują, ludzie zatwierdzają.** Agent może zauważyć obejście, na przykład to, że zamówienia jednego typu nigdy nie mają pozycji, i zaproponować nowy obiekt w jego miejsce, razem z dowodami. Decyduje osoba, która odpowiada za tę część firmy.

Tak jest projektowana warstwa [Ontologia](https://hurukan.com/pl/system/ontologia) w Hurukan: obiekty, relacje i reguły opisane i wersjonowane oraz rozbudowywane wraz z tym, jak agenci rozbudowują system. Propozycje przechodzą przez reguły akceptacji warstwy [Logika agentowa](https://hurukan.com/pl/system/logika-agentowa), a każda zmiana jest zapisywana jako dokonana przez człowieka, agenta albo system, jak opisuje warstwa [Bezpieczeństwo i suwerenność](https://hurukan.com/pl/system/bezpieczenstwo-i-suwerennosc). System jest w budowie. Skąd bierze się pierwsza wersja takiego modelu, opisuje tekst [Twoja firma ma już ontologię](https://hurukan.com/pl/blog/twoja-firma-ma-juz-ontologie).

## Test na dziś

Znajdź w swoim głównym systemie trzy najczęściej używane pola typu „rodzaj”, „kategoria” albo „status”. Przy każdym:

1.  Wypisz wszystkie wartości, jakie może przyjąć.
2.  Przy każdej wartości ustal, kiedy ją dodano, kto i po co.
3.  Zaznacz wartości używane do czegoś innego, niż mówi ich nazwa.

Potem przeszukaj rekordy w poszukiwaniu pól tekstowych, które ludzie wypełniają według stałego wzoru, na przykład „PO: …”, „umowa nr …” albo „ważne do …”. Każdy znaleziony wzór to obiekt albo relacja, której Twój model jeszcze nie ma.

Obie listy razem to zaległe zmiany, które firma już wprowadziła w rzeczywistości, a jeszcze nie w swoim modelu. Przerobienie ich po jednej, wersjonowanej zmianie naraz, jest tańsze niż wielki projekt przebudowy, którym inaczej by się stały. [Hurukan](https://hurukan.com/pl) jest projektowany tak, żeby ta lista była krótka.

-   ontologia
-   wersjonowanie
-   zarządzanie zmianą
-   model danych

## Czytaj dalej

-   [Jedna tożsamość dla ludzi i agentów: kto co może](https://hurukan.com/pl/blog/jedna-tozsamosc-dla-ludzi-i-agentow)
-   [Stan bieżący i zapis: dwie pamięci systemu operacyjnego firmy](https://hurukan.com/pl/blog/stan-biezacy-i-zapis-dwie-pamieci-systemu-operacyjnego-firmy)