Wprowadzenie

Kolejne przeprowadzone szkolenia za mną, kolejna seria trudnych pytań też. Na szkoleniach z analizy biznesowej podaję, poza opisem dobrych praktyk, także anty-przykłady. Jednym z typowych anty-przykładów są diagramy zbyt szczegółowe, w szczególności próby “narysowania” konsultacji, serii zapętlonych zgłaszanych uwag do dokumentów i ich akceptacji, dziesiątek przekazywanych komuś innemu informacji. Diagram procesu BPMN nafaszerowany dziesiątkami rombów z wieloma wyjściami w rodzaju kto i w jakich warunkach ma coś skontrolować, zaakceptować, odesłać do poprawy itp. To mega diagramy, niemożliwe do zrealizowania próby algorytmizacji pracy modelowanej firmy (żadna firma nie jest deterministyczna). Przypomnę, że na poziomie procesów biznesowych (wewnętrzny łańcuch wartości) “pętle wstecz” reprezentują cofnięcie się w czasie, a czy to faktycznie ma miejsce?

Szczytem tego zjawiska, jakie swego czasu widziałem, był diagram  na którym jego autor  usiłował pokazać proces, w którym Asystentka Zarządu pozyskiwała trzy wymagane do reprezentacji podpisy pod umowami, spośród pięciu możliwych (trzech członków zarządu i dwóch prokurentów wpisanych w KSR). Diagram zawierał pulę, sześć torów (powyższe osoby) i zawiły “proces” pozyskiwania trzech z pięciu możliwych podpisów w postaci przepływów “fruwających” po tych sześciu torach. Innym przykładem tego “makaronistycznego” (w literaturze zachodniej można spotkać ironiczną nazwę tego podejścia: spaghetti modeling) podejścia to diagramy pokazujące np. mocno zapętlone procesy zawierające wszelkiego typu konsultacje i korekty dokumentów.

Więc jak, skoro nie tak?

Kilka lat temu wspomniałem o macierzy RACI pisząc o “metodach” modelowania procesów. Tu kilka słów na temat tego jaką wartość wnosi ta macierz do modelu. W  artykule  tym napisałem, że sama macierz RACI nie jest modelem procesu. Tu pokaże,  że macierz ta jest (może być) jednak uzupełnieniem modelu procesu. Co oznaczają kolejne litery skróty RACI?

• R – Responsible, to osoba odpowiedzialna za daną aktywność (proces) i rezultat (produkt). Z reguły wykonawca procesu, jeżeli jest to atomowy proces biznesowy (aktywność).
• A – Accountable/Approver, to osoba odpowiedzialna za weryfikację i zatwierdzenie produktu, rozliczana z uzyskanego efektu, z reguły czynność ta jest ostatnią czynnością procedury danej aktywności.
• C – Consulted, to osoba (jedna lub więcej) posiadająca wiedzę wymaganą w toku realizacji danej aktywności, która na żądanie wykonawcy udziela mu konsultacji.
• I – Informed, to osoba (jedna lub więcej), która jest informowana o produkcie aktywności.

(źr. https://www.youtube.com/watch?v=rWpLe23pi0g)

Kolejna ważna rzecz: ludzie w firmach (ich stanowiska, role itp.) poza tym, że są (nie raz) wykonawcami procesów, są także zasobami firmy! A na diagramach procesów nie pokazujemy zasobów, tylko role i aktywności za jakie te role odpowiadają (wykonują). Tak więc sprzedawca, jako swój zasób, ma cennik, z którego korzysta podczas opracowywania ofert. Jednak w przypadku gdy nie ma cennika, konsultuje się z osobą, która zna ceny. Może to robić lub nie zależnie od sytuacji. Czy to znaczy, że mamy dwa różne procesy opracowania oferty? Nie! Sprzedawca korzysta z cennika drukowanego lub konsultuje się (wie z kim powinien) z określonym specjalistą w firmie. Ten specjalista, w tym przypadku, jest zasobem firmy, z którego można korzystać (z jego wiedzy).

Tak więc procesy, ich modele,  są (powinny być) relatywnie proste. Ewentualna ich złożoność tkwi między innymi w wykorzystaniu (obligatoryjnym lub opcjonalnym) zasobów, jakimi są między innymi inni pracownicy (Prezes firmy także jest, w wielu procesach,  “zasobem ludzkim” firmy, a nie wykonawcą).  

Macierz RACI to narzędzie pokazujące i dokumentujące zarazem, pozaprocesowe zależności między wykonawcami procesów biznesowych, bo na modelach procesów biznesowych pokazujemy wyłącznie łańcuch wartości dodanej (proces biznesowy tworzy wartość dodaną). Reszta to zasoby wymagane w danym procesie (konsultanci, akceptanci, informowani), których na modelu procesu nie ma, korzysta z nich “rola” jako ten (ta), kto odpowiada za wykonanie danej pracy.  Wtedy diagram procesu pozyskania właściwych podpisów pod umową jest bardzo prosty: jedna czynność “pozyskanie podpisów”, skojarzeni są z nią (macierz RACI jako uzupełnienie diagramu z modelem procesu) “akceptanci”, czyli Ci, którzy mogą się podpisać oraz reguła biznesowa, mówiąca, że mają być dwa podpisy. 

Na pewnej dość ciekawej stronie WWW można znaleźć taki ciekawy diagram:

Tak więc cztery role w macierzy RACI to: A – ktoś kto może wstrzymać proces, R – wykonawca (realizator) procesu, C – konsultant (pętla konsultacji) oraz I czyli ten kto czeka na informacje o zakończeniu (subskrybent).

Polowanie na wykonawcę

Drugim przykładem występowania zjawiska “spaghetti modeling” są sytuacje, w których np. fakturę może wystawić więcej niż jedna osoba w firmie. Np. może to być główna księgowa, specjalista ds. księgowych i asystent sprzedaży. Widywałem diagramy procesu sprzedaży, na których były tory wszystkich tych “osób” oraz złożony przepływ (masa bramek i niejasnych kryteriów wyboru) pokazujący sposób wyboru, która z tych wymienionych osób, wystawi w danym przypadku tę fakturę. Diagram taki wygląda trochę jak polowanie na “jelenia” :).

Rzecz w tym, że w bardzo wielu przypadkach określone role (tu fakturowanie) mogą być przyporządkowane do kilku różnych stanowisk w strukturze organizacyjnej. Jak to pokazać? Nie na modelu procesu. Informacje te są (powinny być) na modelu struktury organizacyjnej. Przyzwyczajeni jesteśmy do struktury organizacyjnej w postaci drzewa “komórka organizacyjna, przełożony, podwładny”.  Na potrzeby analizy potrzebny jest nam jednak sformalizowany model, w którym nie “kończymy” na stanowiskach a na kompetencjach (rolach – funkcjach biznesowych). Na takim diagramie, poza stanowiskami  “główna księgowa, specjalista ds. księgowych i asystent sprzedaży” pojawi się przy każdym z nich bloczek “fakturowanie” (jako Funkcja biznesowa).  Do tej pory formalizację struktury organizacyjnej robiłem “na własna rękę”, ale na szczęście opracowywany jest już przez organizację OMG model struktury organizacyjnej, który to (taki sposób modelowania struktur organizacyjnych) narzuca, w sposób praktycznie taki jak tu opisałem i sam stosuję.

Tak więc  na modelu procesu sprzedaży, będzie czynność wystawienia faktury, wykonawcą jest rola “Fakturzysta”, a na strukturze organizacyjnej, dodatkowy bloczek: Fakturzysta, będzie  skojarzony z główną księgową, specjalistą ds. księgowych i asystentem sprzedaży. Model będzie “prosty”.

Na zakończenie. Trudność tworzenia modeli procesów biznesowych polega  na wyłuskaniu istoty rzeczy a nie na umieszczeniu na diagramach wszystkiego tego, czego się dowiemy podczas wywiadów. To drugie nazywa się raczej “stenogram”.

Analityk ma uogólniać, analizować i dokumentować (modelować) sens i sposób działania, jego cele. Nie jest rolą analityka, podczas modelowania procesów biznesowych, zapisywanie w formie rysunku, wszystkiego tego  czego się dowiedział.

Model procesów biznesowych nie jest “samowystarczalny”, musi być skojarzony z wzorami dokumentów, zakresami obowiązków czy właśnie macierzami RACI. Próba umieszczenia całej tej wiedzy na diagramach, prowadzi do nieczytelnych, przeładowanych szczegółami, praktycznie nieprzydatnych, diagramów.

Jeżeli więc ktoś Państwu zafunduje model (mapy) procesów biznesowych na setkach diagramów, a na każdym dziesiątki bloczków, to należy się zastanowić  nad tym, czym te diagramy są i do czego mogą posłużyć (i czy w ogóle mogą się na coś przydać). Chyba, że sami Państwo o takie diagramy, tak szczegółowe i w takiej ilości, poprosili…  tylko, że ja zapytam: po co?

Przykład

Mam nadzieję, że powyższe “daje do myślenia” i skłoni do refleksji nad dostawcami usług “modelowania procesów biznesowych”. Tu prosty przykład ilustrujący powyższe dobre praktyki.

Struktura organizacyjna z naniesioną informacją o funkcjach biznesowych:

Model procesu biznesowego, Funkcje biznesowe mapują się 1:1 na role:

Lista dokumentów z kodami CRUD pokazująca dodatkowo, co dzieje się z dokumentami w procesach (docelowo mogą być mapowane na przypadki użycia):

oraz macierz RACI pokazująca pozostałe “zadania” poszczególnych Ról w tym procesie:

Proszę sobie wyobrazić złożoność powyższego diagramu procesu, gdyby starać się na niego nanieść wszystkie informacje z tych macierzy…

(modele wykonane z użyciem pakietu VP).

Bibliografia