Zwykle zamodelowany proces w narzędziu klasy BPA jest bardzo skomplikowany.
Ma bardzo dużo decyzji (więcej niż 5),
Ma bardzo dużo elementów w linii (więcej niż 5),
Ma bardzo dużo linii (więcej niź 5),
I ma bardzo mało basen (zwykle 1).
Do tego dochodzi zamęt Informatyczny w biznesowej notacji, który przybiera formę stawiania na równi z działem biznesowym nazwy systemu.
No i jeszcze kwestia notacji dla interfejsów, co wdrożenie to inaczej się to zapisuje.
Skąd to się bierze?
Według mnie jest to próba odwzorowania biznesu i jego wszystkich ścieżek alternatywnych.
Wystarczy spojrzeć na proces logowania, klasyka przypadku, w którym każdy polski programista, może udowodnić, że w BPMN nie można opisać każdego procesu.
Ale czy rzeczywiście biznes jest tak bardzo skomplikowany?
Gdyby tak było, to nawet przy darze kombinowania, w jaki obdażony jest prawie każdy Polak, ten biznes po prostu by nie działał.
Znacznie bardziej ciekawa przyczyna powyższego stanu wynika z psychologii.
Otóż istnieją dwa dobrze zbadane prawa, które tłumaczą powody, przez które komplikujemy opis codziennych praktycznych metod postępowania.
Pierwsze to prawo koleracji, według którego nieświadomie naciągamy rzeczywistość (symptomy i fakty) do jednostkowego przypadku, który nie jest dojrzały statystycznie, ale który przeżyliśmy z dużą dawką emocji. W efekcie modelujemy alternatywne ścieżki (które same w sobie są często bardziej złożone, niż ścieżka główna) dla funkcjonalności, które najprościej by było zablokować lub obsłużyć mechanizmem wyjątków biznesowych.
Drugie prawo to prawo perspektywy według, którego każdy inaczej interpretuje te same liczby, dla mnie 5 to bardzo dużo, a dla innej osoby to śmiech na sali. Ta interpretacja wynika z doświadczeń, ale nie tylko tych bezpośrednich i biznesowych, ale szeroko kontekstowych (dla osoby, która w szkole dostawała zwykle 3 i była z tej oceny zadowolona to i 4 będzie bardzo dużo).
Wracając do modelowania...
Niestety nie da się modelować symultanicznie (mam tu na myśli automatyczne odtwarzania rzeczywistości), zatem do modelowania wybierane są kluczowe osoby i to ich magię koleracji według ich indywidualnej perspektywy odtwarzamy w modelu. Naturalnie każdy taki proces będzie oderwany od biznesowej rzeczywistości.
Taki ułomny model (mimo poniesienia znaczych środków w jego wytworzenie), staje się wsadem do procesu BPM, który bezdusznie obnaża koleracje i perspektywę. Niestety robi to w pierwszym okresie po wdrożeniu. Ocena jest oczywista: jakość procesu jest fatalna....
Dostrzegam tylko jedno sesnsowne rozwiązanie:
W ramach BPM wdrażamy tylko ścieżkę główna, cała reszta jest generycznym biznesowym wyjątkiem. Takie rozwiązanie wdrażamy na produkcję, tak by biznesowa społeczność mogła je poddać systemowej ocenie. Po krótkim okresie użytkowania zmierzymy skalę najczęstrzych wyjątków.
W ten sposób zamienimy indywidualną kolerację i perspektywę na obiektywną statystykę. To ona będzie definiować priorytety i kolejne przyrosty lub sprinty dalszych prac.
Biznesowy sprzeciw
Naturalny jest opór i sprzeciw użytkowników biznesowych. Wynika on z odkrycia biznesowych patologii i powiedzeniu "nie" dla ich implementacji (gdybyśmy zrobili ścieżki alternatywne, to reaktywnie byśmy się na to zgodzili).
Do wyboru mamy jednak dwie opcje:
1. Konflikt na początku projektu, który grozi nam wykluczeniem.
2. Zgodę na patologię i kiepski PR na końcu projektu, który grozi nam wyłączeniem naszego rozwiązania.
Ja wybieram opcję 1. Zdrowy sens zawszę prędzej czy później wypłynie na wierzch.
A i jeszcze jedno, wygrać tą batalię może tylko ta osoba, która wierzy w to o co walczy ...
Brak komentarzy:
Prześlij komentarz