Jakie są Twoje doświadczenia w pierwszym kontakcie z interesariuszami w projekcie? Albo z dokumentacją, jaką często czytasz na starcie prac? Na początku podejmowana jest próba odnalezienia się w gąszczu informacji i zrozumienia, czego ktoś ode mnie oczekuje, jaką ma wizję produktu, jak realizował dotychczas swoje zadania. A jak się już to jakoś ogarnie, spotykam się z kolejnym interesariuszem i… okazuje się, że owszem, wiemy mniej więcej jak co działa, ale KLIENTEM jest zupełnie ktoś inny niż mówiła dotychczasowa dokumentacja; zostaje się nim dopiero jak się taki jegomość pojawi w systemie, otrzyma odpowiednią flagę, trzy gwiazdki w rankingu fajności i kupi jakiś produkt… do tego czasu nie jest klientem, tylko… no właśnie, kimś bliżej nieokreślonym. Przynajmniej dla tego interesariusza. Dla poprzednich interesariuszy przecież wiadome było, że to Klient. Zabiegaliśmy o niego, dbaliśmy o strzępki informacji jakie nam udostępnił, pielęgnowaliśmy jego zaangażowanie w procesie stania w kolejce, podchodzenia do okienka i pierwszej rozmowy z doradcą… I jak sobie poradzić z taką rzeczywistością. Dla jednego Klient, dla innego „ktoś” kogo nawet dotychczas nie było sensu nazywać bo nie jest w systemie. A projekt trzeba przeprowadzić, ludzi skomunikować, stworzyć rozwiązanie i zjeść kawałek tortu o nazwie „sukces wdrożenia”…

Słownik pojęć

Najczęściej stosowanym rozwiązaniem do ustalenia wspólnego poziomu rozumienia zagadnień biznesowych są słowniki pojęć, tworzone lokalnie, najczęściej w sekcji „Definicje i skróty” w opasłym tomiku specyfikacji funkcjonalnej. Pozwalają one na czas przedsięwzięcia wprowadzić pewien wspólny mianownik przy rozmowach czy opiniowaniu i zatwierdzaniu zakresu do realizacji. Słownik pojęć to najprostsze, jednak nie najdoskonalsze narzędzie utrzymania definicji. Owszem, lepiej je mieć niż cierpieć na brak świadomości kim dla mnie jest Klient i o jakie saldo wreszcie chodzi: zapadłe, bieżące, z dnia poprzedniego, uzgodnione… Jednak tworzenie lokalnych słowników w dokumentach czy narzędziach dla inicjatywy posiada dość znaczną wadę. Brak trwałości. Raz zdefiniowane pojęcie definiowane jest za każdym razem od nowa, definiują je różne osoby i jego rozumienie w każdym przypadku może być inne. Można powiedzieć, że przecież zmienia się znaczenie słów, które wypowiadamy i w zależności od kontekstu inaczej je rozumiemy. Czy na pewno? Czy kontekst nie tworzy specjalizacji dla danego pojęcia? Czy Klient równa się klient indywidualny (zawsze pracowaliśmy tylko z klientami indywidualnymi, używamy więc pewnego skrótu)? Czy może klient jest zawsze klientem, a klient indywidualny jest jego podzbiorem. Oprócz nietrwałości i niespójności pomiędzy takimi słownikami wynikającej z wielokrotnego definiowania tych samych pojęć, napotykamy na problem przy przeniesieniu projektu do innego zespołu bądź zaangażowania w niego nowej grupy osób. Druga grupa może mieć inne przyzwyczajenia i używać innych definicji, dla nich klient jest dopiero w systemie, a to utrudnia pracę całej grupy. Dodatkowo słownika zwykle się nie czyta, przecież pojęcia w nim zdefiniowane są oczywiste i w naszej grupie zwykle je tak rozumieliśmy…

Słownik na poziomie organizacji

Pewnym lekarstwem na powyższą bolączkę jest stworzenie słownika na poziomie całej organizacji. Ale tylko pewnym. Zaraz wyjaśnię dlaczego. Owszem, w wielu projektach używamy tych samych definicji, dbamy zatem o jego trwałość, przyrostową aktualizację i wielokrotne użycie w wielu miejscach. Czy pozbywamy się wszystkich problemów? Moim zdaniem mamy generalnie problem ze słownikami nie tyle lokalnymi, co w ogóle ze słownikami. Popatrzmy jak definiowane są pojęcia w takich słownikach. Przykład ze słownika NBP (https://www.nbportal.pl/slownik/pozycje-slownika/rachunek-biezacy):

Rachunek bieżący: rodzaj rachunku bankowego przeznaczonego do gromadzenia środków pieniężnych oraz przeprowadzania rozliczeń pieniężnych przez osoby prawne, jednostki organizacyjne nie posiadające osobowości prawnej, o ile posiadają zdolność prawną, oraz osoby fizyczne prowadzące działalność zarobkową na własny rachunek, w tym działalność gospodarczą.

A teraz ta sama definicja z oznaczonymi innymi pojęciami:

Rachunek bieżący: rodzaj rachunku bankowego przeznaczonego do gromadzenia środków pieniężnych oraz przeprowadzania rozliczeń pieniężnych przez osoby prawne, jednostki organizacyjne nie posiadające osobowości prawnej, o ile posiadają zdolność prawną, oraz osoby fizyczne prowadzące działalność zarobkową na własny rachunek, w tym działalność gospodarczą.

Taka definicja słownikowa, aby była zrozumiała musi zawierać referencje do innych pojęć w swojej treści oraz określać związki z nimi. Najczęściej inne pojęcia znajdują się w postaci synonimów, specjalizacji czy zestawu atrybutów je opisujących. Definicja taka z reguły nie jest precyzyjna. Jak zrozumieć podkreślone pojęcia? Musimy sięgnąć do ich definicji, a tam znajdziemy odniesienia do kolejnych pojęć i kolejnych, musimy nasepnie zrozumieć ich powiązania… a może i liczności, a tu już natrafiamy na reguły biznesowe… ups.

Definicja słownikowa łączy w sobie przynajmniej trzy rzeczy. Wyjaśnienie (niepełne) co do definiowanego pojęcia (bo oparte na innych pojęciach stanowiących dziedzinę biznesową), relację z innym pojęciem (która może się przecież zmienić, nie naruszając konstrukcji samego pojęcia) oraz zestaw atrybutów … dużo tego. Jak utrzymać aktualność takiej definicji na poziomie całej organizacji, przy zmienności biznesu i zasad nim rządzących, relacji pomiędzy definiowanymi obiektami biznesowymi… może wróćmy do słowników lokalnych, bo są prostsze?

Model pojęć

Jest coś, co możesz zastosować w pracy swojej, pracy swojego zespołu, w funkcjonowaniu swojej organizacji, co owszem nie jest trywialne i wymagać będzie pewnego porządku (tutaj na myśl przychodzi mi jakaś metodyka, którą stosujecie albo powinniście stosować w swojej pracy). Jest to model pojęć. Model to uproszczona, abstrakcyjna reprezentacja skomplikowanej rzeczywistości, spójna i rozumiana w jednoznaczny sposób przez wszystkich uczestników zabawy korporacyjnej.

O modelu dla doświadczonych analityków niewiele muszę mówić. O UML, czy diagramie klas też nie. Diagram klas i zobrazowanie modelu pojęć pozwala na oddzielenie aspektu definiowanych pojęć od ich relacji. Definicje takie wyglądają inaczej, zawierają mniej tekstu, ale docierają do sedna. Bo jeśli definiujemy pojęcie na około, to jak ktoś powiedział, jeśli nie potrafimy tego zdefiniować wprost, być może tego nie rozumiemy…

Nie chcę powtarzać po mistrzach, dlatego do informacji jak zbudować model pojęć, jak diagram klas może zastąpić Wam słownik – kieruję Was do tego oto bloga. Niedługo natomiast postaram się umieścić kilka koncepcji jak taki model zbudować w swoim repozytorium, jak go utrzymać i jak korzystać z niego w trakcie modelowania. A moc modelu jest wielka. Wyzwań też jest wiele, bo np. zwykle model taki buduje się w sposób przyrostowy (nie stać nas na zatrzymanie wszystkich inicjatyw i zdefiniowanie całego świata, a po roku prac odmrożenie projektów w zdefiniowanym już świecie). Zmieniamy ciągle i uszczegóławiamy obszary pojęciowe w trakcie odkrywania świata biznesowego w kolejnych projektach. Jak więc wersjonować, odnosić się do kolejnych wersji pojęć? Czy i dlaczego się to opłaca (a może nie)?

…a może model w wersji „global”?

A dlaczego nie stworzyć modelu dla całego świata biznesu? Jednego? Dlaczego każda organizacja powinna posiadać osobny? Wróćmy do naszego Klienta.

Kim jest Klient? Centrum handlowe powie, że Klientem jest ktoś, kto właśnie znajduje się na terenie centrum. Taki Klient wraca bądź nie, zachowuje pewną postawę względem miejsca, lubi spędzać tam czas, ma ulubione restauracje, sklepy, ulubione ruchome schody i parkuje auto przy tym samym wejściu.

Właściciel sklepu z ubraniami znajdującego się w takim centrum powie, że Klientem jest ktoś, kto jest w jego sklepie i jest zainteresowany kupnem produktu. Po prostu ogląda ubrania. Ktoś z banku mającego w takim centrum swój oddział powie, że Klientem jest ktoś, kto został zarejestrowany w ich systemie, a do tego musiał wcześniej nabyć jakiś produkt bankowy; należy więc najpierw zidentyfikować osobę będącą w oddziale, aby powiedzieć, czy jest Klientem czy nie. Od definicji i rozumienia Klienta zależy strategia i aktywność przedsiębiorstwa względem niego, oferta jaką do niego kierujemy, sposób traktowania czy zainteresowanie nim. Czy sklep odzieżowy interesuje się osobami, które do centrum handlowego przychodzą jedynie zjeść burgera? Czy zaproponują im tą samą ofertę, co dla stałego odwiedzającego posiadającego złotą kartę lojalnościową? Pewnie nie. Ale samo centrum będzie chciało takiego Klienta zatrzymać, aby ten spędzał w nim jak najwięcej czasu i może zaczął odwiedzać jakieś sklepy…

Hmm…

Być może klient nie jest Klientem, a interesantem. Kimś jeszcze niezidentyfikowanym, osobą we wspólnej przestrzeni, która ma jakiś interes i póki co nie wiadomo, czym ten kontakt się zakończy. Klientem w świadomości pracownika firmy stanie się po zweryfikowaniu kim jest, czy jest z nami związany i czy jest dla nas interesujący. A być może Klientem jest osoba mieszkająca w obrębie 2 km od sklepu, która robi bądź może robić w sklepie zakupy… Jak różne będą wymagania w projektach realizowane dla każdej z tych grup. Jak inne funkcje w systemach będą udostępniane tak różnym grupom, jak bardzo różnić się będzie ich obsługa? Nie wystarczy już powiedzieć „Chcę, aby Klient wybrał opcję…”. Jaki Klient?

Kim jest więc dla Ciebie Klient? Zdefiniuj, a najlepiej umieść go w modelu pojęć, aby nadać mu kontekst i aby stał się częścią pewnej architektury informacji dostępnej dla wszystkich i rozumianej przez każdego w Twojej firmie tak samo.