Kiedy potrzebujecie ontologii, a kiedy to tylko narzut

Słowo „ontologia” potrafi zakończyć rozmowę z zarządem, zanim ta się zacznie. Brzmi jak wieloletni program modelowania wiedzy, prowadzony przez specjalistów mówiących językiem, którego nikt inny nie rozumie. I taka wersja rzeczywiście zwykle zawodzi.

Dla osoby, która decyduje o budżecie, pytanie nie brzmi jednak „czy potrzebujemy ontologii”. Brzmi: ile kosztuje nas dziś to, że nie zgadzamy się, czym są rzeczy, na których stoi firma — klient, zamówienie, lokalizacja, umowa. Czasem odpowiedź brzmi „niewiele” i wtedy ontologia jest narzutem. Czasem płacicie za ten brak co miesiąc, tylko w pozycjach, które tak się nie nazywają.

Sygnały, że już płacicie za brak modelu

Dwa systemy, dwie liczby. Sprzedaż i finanse raportują liczbę klientów i wychodzą im różne wyniki. Każde spotkanie zaczyna się od ustalania, czyja liczba jest „prawdziwa”, a uzgodnienie istnieje tylko w głowie jednego analityka.

Duplikaty jako koszt stały. Ten sam klient trzy razy w systemie sprzedażowym i dwa razy w fakturowaniu, a ktoś co miesiąc czyści to ręcznie. To nie jest jednorazowy bałagan, tylko powtarzalny koszt operacyjny.

Raporty z przypisami. Każde zestawienie wymaga zdania wyjaśniającego, której definicji użyto. Przypis to objaw: definicja istnieje, ale nigdzie, gdzie mogłaby ją przeczytać maszyna.

Konsolidacja albo przejęcie. Łączenie systemów po fuzji albo wymiana głównego systemu wymusza mapowanie, niezależnie od tego, czy ktoś nazwie je ontologią. Pytanie tylko, czy zostanie zrobione raz i porządnie, czy przy każdym raporcie od nowa.

AI, które ma wnioskować w poprzek systemów. Wyszukiwanie albo agent, który musi wiedzieć, że rekord w jednym systemie i dokument w drugim dotyczą tej samej rzeczy. Bez reguł tożsamości zgaduje — i robi to przekonująco.

Infografika

Od narzutu do konieczności

Jeden systemRaporty z przypisamiDuplikaty klientówKonsolidacja systemówAI w poprzek systemów

NarzutKonieczność

Kiedy to narzut

Jeden system, jedna definicja. Jeśli całą firmę obsługuje jeden system i nikt nie spiera się o znaczenie słów, ontologia dokłada pracę bez zysku. Wystarczy dobrze utrzymany słownik.

Nikt nie ma władzy, żeby rozstrzygnąć spór. Bez osoby wystarczająco wysoko model da się tylko opisać, a nie uzgodnić. Wtedy lepiej najpierw załatwić tę kwestię, niż wydać budżet na staranny opis sporu.

Zakres „całe przedsiębiorstwo, z góry”. Projekt, który chce zamodelować wszystko, zanim cokolwiek z niego skorzysta, ma dobrze udokumentowany tryb porażki. To nie jest za mało potrzeby, tylko za dużo zakresu.

Ile to kosztuje Was, a nie dostawcę

Honorarium dostawcy to tylko część rachunku. Po Waszej stronie potrzebne są dwie rzeczy.

Pierwsza to czas ludzi z działów, które się nie zgadzają: rozmowa z każdym osobno, rzędu godziny czy dwóch, i dostęp do kogoś, kto zna dane od strony praktycznej. Uzgodnione części modelu zajmują popołudnie; praca jest w sporach.

Druga jest droższa i rzadziej planowana: ktoś wystarczająco wysoko, kto rozstrzygnie, którą definicję znaczy dany system. Zwykle chodzi o kilka decyzji, a nie kilkadziesiąt — ale bez nich projekt stoi.

Sama praca nad rdzeniem modelu dla jednego albo dwóch realnych przypadków użycia to zwykle cztery do ośmiu tygodni razem z wdrożeniem. Jeśli ktoś proponuje lata, proponuje inny projekt.

Jak wygląda zwrot

Uzasadnienie nie musi opierać się na obietnicy „lepszej jakości danych”, której nikt nie umie zmierzyć. Da się je oprzeć na rzeczach, które już dziś kosztują i które po projekcie powinny kosztować mniej.

Mniej uzgadniania. Liczby zgadzają się między systemami, bo wynikają z jednego modelu, a nie z pięciu konwencji. Spotkania przestają zaczynać się od ustalania, czyja liczba jest prawdziwa, a raporty tracą przypisy.

Mniej ręcznego czyszczenia. Reguły tożsamości rozpoznają tego samego klienta w różnych systemach, więc duplikaty przestają być comiesięcznym zadaniem czyjegoś zespołu.

Lepsze wyszukiwanie i lepsi agenci. Oba zawodzą głównie na niejednoznaczności, a nie na możliwościach. Z rozstrzygniętą encją i jej relacjami system może odfiltrować to, co naprawdę istotne, zamiast przekonująco zgadywać.

Test na jedno popołudnie

Weźcie jedną liczbę, o którą firma regularnie się spiera — liczbę klientów, aktywnych umów, czynnych lokalizacji — i zapytajcie dwa działy osobno, jak ją liczą.

Jeśli odpowiedzi się różnią i nikt nie umie powiedzieć, która jest właściwa do czego, macie problem ontologiczny, niezależnie od tego, jak go nazwiecie. Jeśli się zgadzają, zaoszczędziliście budżet, a to też jest dobry wynik.

Od tej rozmowy zaczyna się projektowanie i inżynieria ontologii: wąsko, przy jednym albo dwóch realnych przypadkach użycia i z czymś, co zacznie korzystać z modelu w ciągu tygodni.