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

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 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, a każda zmiana jest zapisywana jako dokonana przez człowieka, agenta albo system, jak opisuje warstwa Bezpieczeństwo i suwerenność. System jest w budowie. Skąd bierze się pierwsza wersja takiego modelu, opisuje tekst Twoja firma ma już ontologię.

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 jest projektowany tak, żeby ta lista była krótka.