Klient 360: ontologia dla MŚP krok po kroku

Klient 360 to model, który łączy tożsamość klienta, sprzedaż, realizację, płatności i obsługę przez nazwane relacje. Dla MŚP jego wartość polega na odpowiedzi na konkretne pytanie: „co wiemy o tej sprawie, z jakiego źródła i czy wolno nam na tej podstawie działać?”. Poniżej pokazuję autorską ontologię przykładowej firmy sprzedającej urządzenia i świadczącej serwis. Zawiera 24 encje i 35 relacji. Nie jest gotowym modelem danych do wgrania bez uzgodnienia definicji z firmą.

To końcowy odcinek cyklu Katalog ontologii dla MŚP w filarze ontologii firmy. Jeśli potrzebujesz najpierw rozróżnić pojęcie, taksonomię i graf, zacznij od prostego słownika ontologii. Wcześniejszy model ruchu na stronie i konwersji pokazuje, kiedy anonimowe zdarzenie może prowadzić do rzeczywistego zapytania. Tutaj przechodzimy do pełniejszego modelu relacji z klientem.

Zobacz model jako graf

Otwórz pełny graf: 24 encje, 35 relacje ↗

Klient 360 dla MŚP24 encje · 35 relacje

−Całość+Zamknij ×

Kliknij lub wybierz węzeł albo relację, aby przeczytać opis. Przeciągnij tło, aby przesunąć graf.

Graf pokazuje wszystkie pojęcia i relacje opisane dalej. Miniatura otwiera duży, interaktywny widok; tekstowe tabele poniżej pozwalają prześledzić model bez korzystania z grafu.

Jaką decyzję wspiera ten model?

Wyobraź sobie firmę, której klient zgłasza awarię urządzenia i pyta, czy może dostać sprzęt zastępczy. Pracownik musi ustalić, która spółka kupiła konkretny egzemplarz, jakie warunki obowiązują, czy dostawa została zrealizowana, kto prowadzi zgłoszenie i jaka jest podstawa działania. Dane leżą w systemie sprzedażowym, finansowym, logistycznym i obsługowym. Sam ekran z „wszystkimi danymi klienta” nie rozstrzyga, czy podobnie nazwane rekordy dotyczą tej samej strony umowy.

Model ma pomóc pracownikowi przejść po potwierdzonych powiązaniach i dostrzec brak danych. Nie zastępuje prawnej interpretacji umowy, decyzji o reklamacji ani kontroli uprawnień. To rozwinięcie problemu jednego widoku klienta: zamiast jednej płaskiej karty pokazujemy, skąd wynika każda odpowiedź.

Co jest encją, a co tylko rolą lub oceną?

W tym modelu Podmiot to osoba prawna albo fizyczna występująca w procesie. Klient jest rolą takiego podmiotu w relacji handlowej z naszą firmą. Ten sam podmiot może być nabywcą na fakturze, a inny odbiorcą urządzenia. Osoba kontaktowa reprezentuje podmiot w określonym zakresie i czasie; jej wiadomość nie jest automatycznie zmianą umowy. Ten podział chroni przed częstym błędem: sklejeniem nabywcy, płatnika i rozmówcy w jeden rekord „klient”.

Poniższy katalog podaje wszystkie typy obiektów. Pełne definicje, identyfikatory i przykładowe źródła zapisano także w wersjonowanym pliku, z którego powstaje widok grafowy na tej stronie.

Obszar	Encje	Rola w modelu
Tożsamość i odpowiedzialność	Podmiot, Klient, Osoba kontaktowa, Identyfikator źródłowy, Pracownik	Kto jest kim, w jakim systemie ma rekord i kto odpowiada za sprawę.
Historia relacji	Relacja handlowa, Interakcja, Zgoda	Kiedy trwała współpraca, kto rozmawiał i jaki kontakt był dopuszczalny.
Sprzedaż	Szansa sprzedaży, Oferta, Umowa, Zamówienie, Pozycja zamówienia	Od możliwości zakupu do uzgodnionych warunków i konkretnych pozycji.
Produkt i realizacja	Produkt, Urządzenie, Dostawa	Typ wyrobu, jego fizyczny egzemplarz i przekazanie odbiorcy.
Finanse	Faktura, Płatność, Rozliczenie	Dokument należności, przepływ środków i przypisanie kwoty do faktury.
Obsługa i utrzymanie	Zgłoszenie, Reklamacja, Sygnał ryzyka, Ocena ryzyka odejścia, Działanie utrzymaniowe	Od zaobserwowanego problemu do oceny i odpowiedzialnego działania.

Rozliczenie jest osobną encją, bo jedna płatność może pokrywać kilka faktur, a jedna faktura może być spłacona w częściach. Ocena ryzyka odejścia też jest osobnym obiektem: musi mieć datę, metodę i zakres. Nie wolno traktować jej jak stałej cechy klienta. Sygnał ryzyka to fakt lub obserwacja, na przykład kilka zgłoszeń w krótkim okresie; ocena jest wnioskiem opartym na takich sygnałach.

Jak encje łączą się w graf biznesowy?

Każda strzałka ma kierunek i czasownik. „Faktura wystawiona dla Podmiotu” znaczy coś innego niż „Osoba kontaktowa reprezentuje Podmiot”. Poniżej znajduje się komplet relacji modelu, pogrupowany według ścieżki pracy:

Ścieżka	Relacje
Ustalenie tożsamości	Klient jest rolą Podmiotu; Podmiot ma Identyfikator źródłowy; Osoba kontaktowa reprezentuje Podmiot.
Historia współpracy	Klient ma Relację handlową; Pracownik prowadzi Relację handlową; Interakcja dotyczy Relacji handlowej; Osoba kontaktowa uczestniczy w Interakcji; Osoba kontaktowa udziela Zgody.
Sprzedaż	Klient ma Szansę sprzedaży; Oferta dotyczy Szansy sprzedaży; Umowa jest zawarta z Podmiotem; Zamówienie jest złożone przez Klienta; Zamówienie wynika z Umowy; Zamówienie ma Pozycję zamówienia; Pozycja zamówienia dotyczy Produktu.
Dostawa	Urządzenie jest egzemplarzem Produktu; Dostawa realizuje Zamówienie; Dostawa jest skierowana do Podmiotu; Dostawa obejmuje Urządzenie.
Rozliczenie	Faktura rozlicza Zamówienie; Faktura jest wystawiona dla Podmiotu; Płatność jest wykonana przez Podmiot; Rozliczenie dotyczy Płatności; Rozliczenie pokrywa Fakturę.
Obsługa	Zgłoszenie dotyczy Klienta; Zgłoszenie dotyczy Urządzenia; Reklamacja wynika ze Zgłoszenia; Pracownik prowadzi Zgłoszenie.
Ryzyko i reakcja	Sygnał ryzyka wynika ze Zgłoszenia; Sygnał ryzyka wynika z Faktury; Ocena ryzyka odejścia dotyczy Klienta; Ocena ryzyka odejścia korzysta z Sygnału ryzyka; Działanie utrzymaniowe odpowiada na Ocenę ryzyka odejścia; Pracownik odpowiada za Działanie utrzymaniowe; Działanie utrzymaniowe dotyczy Klienta.

To graf relacji biznesowych, a nie drzewo typów. Czytelnik może przejść od Zgłoszenia do Urządzenia, Dostawy, Zamówienia, Umowy i Podmiotu. Przy każdym kroku powinien umieć zapytać o źródło powiązania. Jeśli numer seryjny nie został zapisany, graf ma pokazać brak krawędzi zamiast dopasować urządzenie po podobnej nazwie produktu.

Jak wygląda jedno przejście po modelu?

Przykład jest hipotetyczny. Klient K17 dzwoni o urządzenie U8. Zgłoszenie S4 dotyczy U8. Dostawa D3 obejmuje U8 i realizuje Zamówienie Z52. Z52 wynika z Umowy M6 zawartej z Podmiotem P2. Faktura F9 rozlicza Z52, ale rozliczenie pokrywa tylko część kwoty. Pracownik widzi więc powiązany zakup i warunki umowy, lecz nie powinien automatycznie stwierdzić, że całe zamówienie jest opłacone.

Teraz pytanie: „czy możemy wysłać urządzenie zastępcze?”. Model wskazuje dokument umowy, zgłoszenie, egzemplarz i osobę prowadzącą. Nie zawiera jeszcze reguły uprawnienia do wydania sprzętu zastępczego ani potwierdzenia, że zgłoszenie uznano za reklamację. To świadoma granica. Pracownik sprawdza właściwy zapis umowy i podejmuje decyzję zgodnie z procesem. Agent AI może zebrać dowody i wskazać lukę, ale nie powinien dopisać brakującej reguły.

Jak połączyć cztery systemy bez fałszywego scalenia?

Pierwszy krok to mapa identyfikatorów. Dla każdego Podmiotu przechowuj parę „system i lokalny klucz”, a decyzję o połączeniu rekordów opieraj na potwierdzonych danych. Podobna nazwa firmy jest kandydatem do sprawdzenia, nie dowodem. Przykład trzech nazw klienta w systemach pokazuje, dlaczego zbyt szybkie scalenie psuje historię umów i uprawnienia.

Drugi krok to właściciel znaczenia. Sprzedaż zatwierdza definicję szansy, finanse — zasady rozliczenia, obsługa — stan zgłoszenia, a odpowiedzialna osoba biznesowa uzgadnia, co oznacza „aktywny klient”. Właściciel danych o kliencie nie musi poprawiać każdego wiersza, ale musi rozstrzygać sporne definicje. Każdy odczyt powinien pokazywać czas aktualizacji i źródło; status z poprzedniego tygodnia nie jest automatycznie statusem dzisiejszym.

Trzeci krok to dostęp. Handlowiec może potrzebować informacji, że istnieje zaległość, ale nie całego wyciągu bankowego. Osoba z serwisu może znać historię urządzenia, ale nie wszystkie warunki innych spółek tej samej grupy. Zgoda na kontakt ma określony cel i osobę. Połączenie grafowe rekordów nie rozszerza samo przez się prawa ich odczytu.

Gdzie kończy się sens takiego modelu?

Nie każda firma potrzebuje od razu 24 encji w produkcji. Dla pierwszego wdrożenia wystarczy często Podmiot, Klient, Zamówienie, Urządzenie, Zgłoszenie i Umowa, jeśli to one odpowiadają na wybrane pytanie. Pozostałe pojęcia są mapą rozszerzenia, a nie listą tabel do natychmiastowego utworzenia. Gdy relacji jest niewiele i są stabilne, istniejąca baza oraz widok mogą wystarczyć. Grafowa wizualizacja pomaga zrozumieć model, ale sama nie poprawia jakości danych.

Szczególnie ostrożnie trzeba traktować ocenę odejścia. W niewielkim MŚP może brakować danych do sensownej prognozy; wtedy lepiej rejestrować sprawdzalne sygnały i przeglądać je z opiekunem klienta. Ocena nie może zastępować rozmowy ani stawać się ukrytą podstawą gorszej obsługi. Zanim dodamy automatyczne działania, ustalmy, kto je zatwierdza, jakie dane są dozwolone i jak sprawdzić skutek.

Jak sprawdzić pierwszy wycinek w swojej firmie?

Wybierz pięć rzeczywistych spraw: prosty zakup, zakup z dwiema dostawami, częściową płatność, reklamację urządzenia oraz klienta z dwoma podobnie nazwanymi podmiotami. Dla każdej zapisz oczekiwaną ścieżkę od zgłoszenia albo zamówienia do strony umowy. Sprawdź, czy pracownik może odtworzyć źródło każdej relacji i wskazać brakujące dane. Jeśli dwie osoby wyciągają inne wnioski z tej samej ścieżki, wróć do definicji relacji przed budową interfejsu.

Pełny sposób przejścia od decyzji do mapowania źródeł opisuje poradnik budowy ontologii firmy. Zacznij od jednego pytania i niewielkiej próbki danych. Dopiero po sprawdzeniu tożsamości, czasu i uprawnień warto rozbudować model o kolejne procesy.