Ontologia Palantira w Enterprise OS: od danych do działania

Ontologia Palantira może pełnić rolę rdzenia Enterprise OS, gdy firma chce połączyć dane z decyzjami i bezpiecznym wykonaniem działań. Nie wystarczy jednak narysować klienta, zamówienia i relacji między nimi. Trzeba jeszcze określić, skąd pochodzi stan tych obiektów, kto może go zmienić, jak działa reguła i gdzie zostaje zapisany wynik. To właśnie odróżnia system operacyjny od ładnie opisanego raportu.

Ten tekst dotyczy roli ontologii w całym obiegu decyzji. Podstawowe elementy produktu — obiekty, powiązania i Action Types — objaśnia osobny przewodnik po Palantir Ontology System. Niezależny od dostawcy model firmy opisuje filar ontologii firmy. Nazwa „Enterprise OS” oznacza tu sposób pracy organizacji na wspólnym modelu danych, decyzji i działań; samo wdrożenie platformy nie tworzy automatycznie takiego systemu.

Co musi połączyć ontologia w Enterprise OS?

Palantir opisuje Ontology System przez cztery składniki: dane, logikę, działania i bezpieczeństwo. Dane z ERP, CRM czy systemu produkcji stają się obiektami z właściwościami i powiązaniami. Logika oblicza lub sprawdza wariant decyzji. Akcja może zmienić stan. Bezpieczeństwo ogranicza odczyt i wykonanie do uprawnionych osób oraz agentów.

Praktyczny test brzmi: czy po podjęciu decyzji wiadomo, co się zmieniło, gdzie, z czyjej inicjatywy i dlaczego? Jeżeli użytkownik widzi ryzyko opóźnienia, ale musi ręcznie przekleić wynik do trzech innych systemów, obieg nadal jest przerwany. Jeżeli agent potrafi zapisać zmianę bez kontroli uprawnień i śladu, obieg jest z kolei zbyt otwarty.

Krok w sprawie	Pytanie biznesowe	Element modelu
Odczyt	Jaki jest aktualny termin i z którego systemu pochodzi?	Obiekt, właściwość, źródło
Ocena	Czy opóźnienie naruszy zobowiązanie wobec klienta?	Reguła, model, wersja danych
Decyzja	Kto wybiera wariant i przy jakim limicie kosztu?	Rola, polityka, zatwierdzenie
Wykonanie	Który system zapisuje nowy termin?	Akcja i integracja zapisu
Kontrola	Czy można odtworzyć decyzję po miesiącu?	Historia, wynik, audyt

To jest moja mapa kontrolna procesu, a nie nazwa pięciu modułów produktu. Oficjalna dokumentacja rozróżnia język ontologii, silnik i narzędzia oraz pokazuje, jak łączą one dane, logikę, akcje i polityki dostępu.

Semantyczna, kinetyczna i dynamiczna: jak rozumieć warstwy?

W opisie systemu operacyjnego firmy stosuję trzy perspektywy. Semantyczna odpowiada za znaczenie: czym jest „zamówienie potwierdzone”, czy „klient” w CRM i ERP oznacza ten sam podmiot oraz kto odpowiada za definicję. Kinetyczna obejmuje dozwolone zmiany i ich skutki: zatwierdzenie nowego terminu, zmianę priorytetu zlecenia, zapis w systemie źródłowym. Dynamiczna obejmuje zmienny stan i logikę pomagającą podjąć decyzję: reguły, prognozy, symulacje oraz informację zwrotną.

To przydatny sposób objaśnienia projektu, zainspirowany także trójwarstwowym opisem ontologii. Nie jest to oficjalna specyfikacja trzech produktów Palantira. W dokumentacji producenta „kinetyka” oznacza przede wszystkim działania, podczas gdy mapowanie danych do obiektów należy do strony semantycznej. Taką granicę opisuje oficjalny przegląd ontologii.

Nie należy również utożsamiać prognozy z uprawnieniem. Model może przewidzieć spóźnienie, lecz z tego nie wynika prawo do zmiany terminu obiecanego klientowi. Warstwa decyzji musi odróżniać propozycję, akceptację i wykonanie.

Przykład dla polskiej firmy: opóźniona dostawa części

Wyobraźmy sobie hipotetyczną firmę produkującą urządzenia na zamówienie. ERP ma zlecenia, magazyn stan części, CRM ustalony z klientem termin, a arkusz planisty wyjątki. Celem pilota nie jest „objęcie ontologią całej firmy”. Jest nim odpowiedź na jedno pytanie: które zamówienia wymagają dziś decyzji o zmianie planu i kto ją zatwierdza?

Zespół najpierw uzgadnia identyfikator zamówienia, część i dostawę oraz różnicę między terminem planowanym a obiecanym. Następnie wiąże zamówienie z brakującą częścią i zleceniem produkcyjnym. Reguła oznacza ryzyko, gdy przewidywana dostawa części wypada po dacie uruchomienia produkcji. Planista widzi warianty: przesunąć inne zlecenie, zamówić część ekspresowo albo negocjować termin z klientem.

Akcja „zaproponuj nowy plan” może być dostępna planiście. Akcja „potwierdź nowy termin klientowi” powinna mieć innego właściciela i sprawdzać limit kosztu. Action Types w Palantir pozwalają modelować takie operacje; projekt musi jednak określić, które systemy są źródłem prawdy i co zrobić po częściowej awarii integracji. Fakt, że ekran pokazał komunikat „zapisano”, nie dowodzi, że CRM i ERP przyjęły identyczną zmianę.

W teście użyj także błędnego identyfikatora, nieaktualnego stanu magazynu, cofniętego uprawnienia i ponowionej akcji. Agent AI może przygotować uzasadnienie wariantu, ale przed wysłaniem wiadomości do klienta trzeba sprawdzić dane źródłowe i osobę odpowiedzialną. To przykład dydaktyczny, nie opis wdrożenia klienta KMC.

Gdzie kończy się ontologia, a zaczynają pozostałe systemy?

ERP i CRM nadal utrzymują własne rekordy oraz procesy. Foundry dostarcza środowisko danych i aplikacji, a AIP może używać modeli AI w procesie. Ontologia spina pojęcia i działania, lecz nie zwalnia z integracji, jakości identyfikatorów, zarządzania zmianą i odpowiedzialności biznesowej. Palantir rozdziela role platform.

W mniejszej firmie ten sam problem bywa możliwy do rozwiązania prostszym zestawem: uzgodniony słownik pojęć, widoki SQL, kolejka wyjątków i kontrolowana automatyzacja. Palantir warto oceniać, gdy wiele źródeł i zespołów pracuje na tych samych obiektach, a decyzje i ich skutki muszą być spójne. Porównanie powinno obejmować identyczny proces, poziom bezpieczeństwa, utrzymanie i koszt zmiany dostawcy; sama liczba funkcji na prezentacji nie wystarczy.

Jak odebrać pilota bez kupowania hasła „OS”?

1. Wybierz jedną decyzję, trzy do pięciu obiektów i właściciela każdej definicji.
2. Zapisz źródło i aktualność właściwości, z których korzysta reguła.
3. Oddziel odczyt, propozycję, zatwierdzenie i zapis; sprawdź prawa każdej roli.
4. Przetestuj zwykłą sprawę oraz błędne dane, odmowę i ponowienie działania.
5. Zmierz czas od sygnału do decyzji, liczbę ręcznych uzgodnień i odsetek spraw z odtwarzalnym uzasadnieniem.
6. Sprawdź eksport modelu, danych i logiki oraz pracę potrzebną do zastąpienia platformy.

Jeśli największym problemem jest już samo ustalenie, który termin jest obowiązujący, zacznij od mapy danych i pojęć firmy. Gdy model jest uzgodniony, można oceniać platformę. Zakres takiej neutralnej oceny opisuje współpraca; artykuł nie deklaruje partnerstwa ani gotowego wdrożenia Palantir.