Ontologia potrzebuje decydenta bardziej niż modelarza

Projekt ontologiczny ma dwie części. Pierwszą da się zlecić: rozmowy z działami, modelowanie, wdrożenie, mapowanie istniejących systemów. Drugiej nie da się oddać nikomu z zewnątrz: rozstrzygnięcia, co w tej firmie znaczy „klient”, „zamówienie” albo „aktywna umowa”, gdy dwa działy mają różne odpowiedzi i obie są uzasadnione.

Gdy taki projekt się przeciąga, rzadko chodzi o trudność techniczną. Częściej spór trafił do kogoś, kto nie ma prawa go rozstrzygnąć, i od tygodni krąży między spotkaniami.

Dlaczego modelarz tego nie zrobi

Za każdą definicją stoi czyjś interes. Sprzedaż liczy klienta od podpisania umowy, finanse od pierwszej faktury, obsługa od pierwszego zgłoszenia. Każda wersja jest poprawna w swoim kontekście i każdy dział ma wyniki, które od niej zależą.

Średnia nikomu nie służy. Kompromisowa definicja, której nie używa żaden dział, to najgorszy możliwy wynik: model zgodny ze wszystkimi i nieprzydatny dla nikogo.

Zespół techniczny nie ma mandatu. Może przygotować warianty i opisać ich skutki. Jeśli jednak sam wybierze, jeden z działów uzna model za wymysł informatyków i będzie dalej liczył po swojemu — a model stanie się kolejną konwencją obok pozostałych.

Jak wygląda rozstrzygnięcie

Często nie polega na wyborze jednej definicji. Uprawnionym i częstym wynikiem jest zapisanie obu, nazwanie ich odrębnie i zmapowanie między nimi. Potrzebna decyzja jest węższa: którą wersję znaczy każdy system i każdy raport.

Infografika

Jak rozstrzyga się sporną definicję

1. 01Wydobyć spórRozmowy z działami osobno, potem definicje położone obok siebie.
2. 02Nazwać obie wersjeDwie definicje dostają odrębne nazwy zamiast jednej uśrednionej.
3. 03Przypisać do systemówDecydent rozstrzyga, którą wersję znaczy każdy system i raport.
4. 04Wskazać właścicielaKtoś odpowiada za definicję i przyjmuje wnioski o zmianę.
5. 05Sprawdzić na danychPrawdziwe rekordy przepuszczone przez model pokazują, czy rozstrzygnięcie się trzyma.

Co się dzieje, gdy nikt nie rozstrzyga

Projekt rzadko staje całkowicie. Zwykle idzie dalej, tylko gorzej, i nikt nie zauważa momentu, w którym przestał rozwiązywać problem, dla którego go zaczęto.

Model przejmuje definicję jednego działu. Tego, który był najbardziej dostępny dla zespołu technicznego albo najgłośniej argumentował. Pozostałe działy dowiadują się o tym przy pierwszym raporcie, który im się nie zgadza.

Arkusze wracają. Dział, którego definicja przegrała bez decyzji, prowadzi własne zestawienia obok systemu. Po roku są dwa źródła prawdy, tylko jedno z nich kosztowało budżet projektu.

Systemy AI dziedziczą spór. Wyszukiwanie i agenci działają na modelu, który po cichu zakłada jedną definicję. Odpowiedzi są spójne i przekonujące — i błędne dla połowy pytających.

Ile Waszego czasu to zajmuje

Mniej, niż się obawiacie, i więcej, niż zwykle planujecie.

Rozmowy. Godzina albo dwie z każdym działem, osobno. Wspólny warsztat produkuje zgodę, której nikt nie zamierza przestrzegać; spory wychodzą w rozmowach w cztery oczy.

Decyzje. Uzgodnione części modelu zajmują popołudnie. Sporów, które naprawdę mają znaczenie, jest zwykle kilka, a nie kilkadziesiąt. Każdy wymaga krótkiego spotkania, na którym warianty i ich skutki leżą już na stole.

Nadzór po projekcie. Każda definicja dostaje właściciela, który przyjmuje wnioski o zmianę. Bez tego model jest trafny przez jeden kwartał, a potem znów rozjeżdża się z rzeczywistością.

Kto powinien rozstrzygać

Niekoniecznie najwyższa osoba w firmie. Ktoś, kto ma władzę nad oboma spierającymi się działami albo pisemny mandat, żeby rozstrzygać w ich imieniu — i kto rozumie, że decyzja „to zależy” jest decyzją o odłożeniu projektu.

Dobry decydent nie musi znać się na modelowaniu. Musi rozumieć skutki: co zmieni się w raportach sprzedaży, jeśli klient będzie liczony od pierwszej faktury, i kto na tym straci. Te skutki przygotowuje zespół projektowy; decyzja należy do decydenta.

Sygnały, że wybraliście złą osobę: rozstrzygnięcia są otwierane ponownie na następnym spotkaniu, każdy spór kończy się prośbą o „jeszcze jedną rundę konsultacji”, a działy przestają przychodzić, bo i tak nic nie zapada.

Jeśli nikt w firmie nie ma takiej władzy, warto powiedzieć to na początku. Model da się wtedy opisać, ale nie uzgodnić, i lepiej o tym wiedzieć przed podpisaniem umowy niż po.

Jedna rozmowa przed startem

Zanim podpiszecie projekt ontologiczny, wskażcie osobę, która będzie rozstrzygać spory, i zapytajcie ją, czy się na to zgadza i ile czasu może na to poświęcić. Ta rozmowa przewiduje wynik lepiej niż jakakolwiek ocena techniczna.

W projektowaniu i inżynierii ontologii to pytanie pada przed pierwszą rozmową z działami — bo konflikty są tą pracą, a bez kogoś, kto je rozstrzyga, zostaje tylko ich staranny opis.