Dlaczego Twój system nie wie kim jest Twój klient?
Organizacje mogą mieć dziesiątki systemów, setki tabel w bazach danych i tysiące pól opisujących klientów, pracowników, dostawców, partnerów. I prawie zawsze ten sam problem: każdy system inaczej rozumie kim jest podmiot, z którym firma robi interesy.
W CRM klient to rekord z emailem i telefonem. W ERP to numer kontrahenta z NIP-em i warunkami płatności. W HR to pracownik z PESEL-em i datą zatrudnienia. W systemie prawnym to strona umowy z adresem korespondencyjnym. Cztery systemy, cztery różne odpowiedzi na to samo pytanie: kim jest ta osoba lub firma?
To nie jest problem techniczny do rozwiązania kolejną integracją. To jest problem analityczny wynikający z braku wspólnego modelu tego czym jest podmiot w organizacji.
Archetyp Party, jak jedno pytanie może uporządkować chaos
Archetypy biznesowe to sprawdzone wzorce modelowania, opisane przez Arlowa i Neustadta, rozwinięte przez Fowlera. Nie są teorią akademicką tylko narzędziem które od dwudziestu lat pomagają analitykom i architektom budować spójne modele domen biznesowych.
Jednym z ośmiu fundamentalnych archetypów w rozwiązaniu DOcForge jest Party opisujący podmiot. Odpowiada na pytanie: kto bierze udział w procesach biznesowych?
Zasada jest prosta. Party to byt który istnieje niezależnie od jakiegokolwiek procesu. Gdyby wszystkie zamówienia, umowy i sprawy się zakończyły to podmiot nadal figuruje w rejestrze. Jan Kowalski nie przestaje istnieć gdy zakończy się jego ostatnie zamówienie. Kancelaria prawna XYZ nie znika gdy zamknie ostatnią sprawę.
Party ma dokładnie dwa podtypy i jest to jedno z ważniejszych założeń, tylko dwa. Co ważne, nie ma możliwości aby podmiot był w dwóch podtypach jednocześnie. Jest albo osobą fizyczną, albo organizacją. To jest ograniczenie które ma konkretną przyczynę prawną.
Dlaczego podział Person/Organization jest wymuszony przez RODO
RODO (Rozporządzenie 2016/679) stosuje się do osób fizycznych. Dane osobowe to informacje dotyczące zidentyfikowanej lub możliwej do zidentyfikowania osoby fizycznej. NIP firmy nie jest daną osobową. PESEL osoby jest. Email firmowy info(at)firma.pl nie podlega RODO. Email jan.kowalski(at)firma.pl już tak ponieważ identyfikuje osobę.
Jeśli Twój model danych traktuje klienta jako jeden byt bez rozróżnienia czy to człowiek czy firma to pojawia się problem. Nie wiesz do których rekordów stosować prawo do usunięcia (art. 17), prawo dostępu (art. 15), prawo do przenoszenia (art. 20). Nie wiesz które pola szyfrować, które anonimizować, które retencjonować.
Archetyp Party rozwiązuje to na poziomie modelu. Reguła projektowa mówi: Party jest wyłącznie Person lub Organization, nigdy obydwoma. Analityk podejmuje tę decyzję raz, przy modelowaniu domeny. Inspektor ochrony danych wie które rekordy podlegają RODO: te z podtypem Person.
Przypadek specjalny: jednoosobowa działalność gospodarcza
Tu jest pułapka na którą wpada większość systemów. Jan Kowalski prowadzący jednoosobową działalność gospodarczą ma NIP i REGON tak jak firma. Ma wpis w CEIDG jak firma. Wystawia faktury VAT jak firma. Więc zazwyczaj modeluje się go jako organizację.
Tyle że podmiotem prawnym JDG jest człowiek, nie odrębna jednostka. Dane JDG w tym NIP i REGON to dane osobowe podlegające pełnej ochronie RODO. Archetyp Party ma na to osobną regułę: JDG to zawsze Person, nie Organization. Nazwa handlowa (Kancelaria Doradztwa Jan Kowalski) to atrybut osoby z typem użycia nazwa handlowa i datą wpisu CEIDG nie osobny podmiot.
Co to daje w praktyce
Gdy analityk modeluje domenę z archetypem Party, każdy podmiot przechodzi przez zestaw pytań diagnostycznych. Dwa z nich są krytyczne , odpowiedź nie natychmiast wyklucza byt z tego archetypu:
Pierwsze pytanie: czy ten byt istnieje niezależnie od jakiegokolwiek procesu?
Jeśli nie: to nie jest podmiot. To jest rola (np. klient to rola którą człowiek pełni w kontekście transakcji) albo zdarzenie (