Co jakiś czas pojawiają się w zapytaniach ofertowych lub dla odmiany w publikacjach różne metody modelowania lub opisu procesów, w tym dość popularne RACI i SIPOC. Kilka słów o tych “metodach”, wyjaśnijmy na początek owe skróty.

RACI

Akronim od angielskich słów: Responsible, Accountable, Consult, Inform. Oznaczają kolejno:

• R?Responsible, to osoba odpowiedzialna za realizację (wykonanie) zadania i jego produkt,
• A?Accountable to osoba mająca obowiązek zatwierdzenia powstałego produktu, możliwe jest to także wykonawca, np. dotyczy to często prac specjalistycznych, 
• C?Consult, to osoba posiadająca wiedzę merytoryczną o przedmiocie zadania, jest ekspertem dziedzinowym, jest to osoba dostępna na żądanie,
• I?Informed, to osoba, która jest informowana o wytworzeniu produktu zadania (ukończeniu zadania),

Powyższy schemat opisu zadania (aktywności) jest dość często spotykany w projektach powiązanych z procesowymi systemami zarządzania jakością. Czy to jakiś model? Nie, procesy (czynności) musimy wyspecyfikować jakąkolwiek metodą (model) by tę macierz RACI stworzyć. Wygląda np. tak:

Problemem macierzy RACI jest ich częste stosowanie bez modelu procesów. W efekcie są one nieweryfikowalne (pozostają jedynie deklaracją).  Macierz RACI jest bardzo przydatna jako wsparcie np. dla modelu procesów, gdyż pokazanie tych zależności w postaci macierzy jest znacznie wygodniejsze niż na diagramie w postaci przepływów.

SIPOC

SIPOC to akronim od angielskich słów: Supplier, Input, Process, Output, Customer, kolejno oznaczają one:

• Supplier (S), czyli Dostawca ? oznacza podmiot, który dostarcza informacje, zasoby do realizowanego procesu.
• Input (I), czyli zasoby wejściowe ? oznacza informacje, zasoby dostarczane przez Dostawcę.
• Process (P), czyli proces (definicja wyżej)
• Output (O), czyli efekt wyjściowy ? oznacza informacje, zasoby dostarczane przez proces.
• Customer (C), czyli klient ? oznacza podmiot, który otrzymuje efekt wyjściowy.

Diagram SIPOC jest prostym w użyciu narzędziem służącym do opisu procesu wraz z jego otoczeniem biznesowym. Diagram SIPOC opisuje dostawców, wejścia, w stopniu ogólnym przebieg procesu, wyjścia (produkty) oraz odbiorców. Odpowiada to akronimowi od Supplier, Inputs, Process, Outputs, Customer.

Diagram SIPOC często rozbudowywany jest o dwa kolejne obszary: zasoby niezbędne do zrealizowania procesu oraz reguły (regulacje prawne) rządzące procesem czyli Resources oraz Rules. Zasoby i reguły mogą być dzielone w zależności od potrzeb, np. reguły ? zewnętrzne i wewnętrzne regulacje prawne, zasoby ? np. pracownicy i systemy IT. (źr. http://www.e-sixsigma.pl/index.php?option=com_content&task=view&id=27&Itemid=1)

Przykład dokumentu:

Jak widać sam spis zawiera wiele pozycji w kolumnach (szczególnie wejście i wyjście), co nie nie ułatwia odtworzenia procesu i jego możliwych scenariuszy, model procesu i tak musi powstać. Tu analogicznie: sama lista SIPOC jest deklaracją, sama – deklaratywnie – stworzona lista procesów jest bardzo ryzykowna. Lista procesów end-2-end (po wstępnej analizie strategii) w postaci nap. tabeli lub modeli SIPOC ma już sens. (patrz także )

Proces

Po raz kolejny posłużmy się podstawową definicją procesu ICOM i jej graficznym modelem:

“Proces biznesowy to czynność lub łańcuch powiązanych czynności, przekształcających wejście (Inputs) w wyjście (Outputs). Proces wymaga określonego działania i zasobów (Mechanism/Resources) a swoboda jego realizacji może być sterowana i/lub ograniczona (Controll/Constraints)”. Powyższy diagram obrazuje definicję, nie jest elementem żadnej notacji (stanowi jednak pierwowzór notacji [[IDEF0]]).

Jeżeli uznać, że dane wejściowe ktoś dostarcza a wyjściowe ktoś odbiera okazuje się, że SIPOC to nic innego, jak opisowy (tabelaryczny) spis procesów, rodzaj inwentaryzacji. Lista taka nie daje żadnego narzędzia pozwalającego na stwierdzenie (weryfikator), że niczego nie pominięto. Deklaracja autorów takiej listy pozostaje nieweryfikowalna. Sam proces, dla weryfikacji, i tak wymaga opisania (modelowania). Tak więc SIPOC jako narzędzie opisu – tak, jako “sposób modelowania”, raczej nie.

Macierz RACI użyta jako metoda opisu wymuszająca cztery atrybuty dla każdego procesu ma pewną wadę: nie dla każdego procesu lub czynności da się (lub ma sens) definiowanie takiej “czwórki atrybutów” a robienie tego obligatoryjnie, prowadzi nie raz do powstania znacznego nadmiaru w dokumentacji. Bardzo często tworzone są sztuczne, nieistniejące zależności (one istnieją czasem warunkowo np. konsultacje można ale nie trzeba prowadzić). Twierdzenie, że powinny być zdefiniowane wszystkie dla każdego procesu jest trudne do obrony. Jednak RACI jako uzupełnienie wiedzy o procesie, bez obowiązku deklarowania wszystkich czterech ról dla każdego procesu, jak najbardziej ma sens.

Popatrzmy teraz na ten model:

Obrazuje on cztery role RACI. Warto zwrócić uwagę, na fakt, że mamy tu 12 możliwych scenariuszy przejścia (proponuję zabawę w sprawdzenie tego :)). Uznanie, że przypadków konsultacji może być więcej niż jeden prowadzi do znacznie większej ilości scenariuszy a diagram ten urósł by do jakichś monstrualnych rozmiarów. (patrz także )

Jak widać więc i tak nie opisuje wszystkiego co może się wydarzyć a powinien, jeśli ma być nazwany modelem jakiejś rzeczywistości.

To jest moment, który nazywam utratą panowania nad złożonością problemu i projektu “modelowanie procesów biznesowych”. Jest to cecha wielu modeli (dokumentów), które otrzymuję do audytu. Powyższy diagram to tylko jeden prosty proces, a wyobraźmy sobie próbę opisania w ten sposób nawet części np. Państwa organizacji. Będą to dziesiątki złożonych, ogromnych diagramów, praktycznie do niczego nie przydatnych, gdyż sprawne posługiwanie się nimi jest niemalże niemożliwe. Do tego każda, nawet drobna zmiana sposobu działania, pociągnie za sobą potrzebę zmodyfikowania znacznej części tej dokumentacji a to koszt porównywalny nie raz z jej wytworzeniem.

Przypomnę jeszcze raz definicję ICOM: wejście, ograniczenia, mechanizm i zasoby, wyjście. W środku jest to co i jak “robią” zasoby: proces. Otóż zasoby to ludzie i ich narzędzia, to co i jak robią to kompetencje. Są opisane np. w opisie zajmowanego stanowiska. Jeżeli coś musi się wydarzyć lub nie może się wydarzyć, to regulują to ograniczenia, są nimi procedury i reguły biznesowe. Są to osobne dokumenty, które mogą się często zmieniać.

Proces biznesowy w opisanej konwencji pojęciowej ICOM można przedstawić tak (notacja BPMN, symbol Reguły biznesowej to notatka, nie jest elementem notacji):

Tak więc mamy: wejście i wyjście, tu treść inicjująca sprawę i dokumenty kończące. Mamy ograniczenie czyli regułę biznesową. Dodatkowym ograniczeniem może być procedura, czyli narzucony wykonawcy sposób (recepta) postępowania. Mamy zasoby w postaci Wykonawcy: osoby odpowiedzialnej za wykonanie i za produkt procesu (Dokument kończący). Rola reprezentuje wszelkie wymagane umiejętności, w tym umiejętność użycia narzędzi (także oprogramowania), ewentualną znajomość prawa i wewnętrznych zarządzeń regulujących pracę, Czynność na diagramie może mieć przyporządkowane określone atrybuty RACI (nie zawsze wszystkie) . To opisuje zakres kompetencji Wykonawcy (nie pokazany na diagramie, to osobny dokument kadrowy).  Powyższy diagram pokazuje sens procesu, czynności może być oczywiście więcej na diagramie, jednak to będą czynności wnoszące wartość w procesie powiązane z ewentualnymi procedurami i regułami biznesowymi. Ich istnienie lub nie oraz treść, to decyzje zarządcze. Tak zdefiniowany proces opisuje w sposób kompletny specyfikę firmy. Modelowanie kompetencji i procedur na modelach (poprzedni diagram) traktuję jako poważny błąd modelowania procesów biznesowych.

Ten model (powyżej) jest odporny na zmiany procedur i reguł biznesowych, są to odrębne, powiązane z modelem dokumenty. Procedura i wyszkolony pracownik  obsłuży statusy sprawy, reaguje w ramach uprawnień i kompetencji na stan Sprawy zgodnie z procedurą. Konserwacja takiej dokumentacji nie stanowi już dużej pracochłonności. Jak widać model procesów to dokumentacja opisująca strategię osiągania celów firmy, tego w jaki sposób tworzy produkt rynkowy. Szczegóły to albo kompetentny pracownik i jego odpowiedzialność albo mniej kompetentny pracownik i procedury pokazujące mu jak ma pracować. Ten wybór to także decyzja zarządcza.

Na zakończenie

Modelując jakąkolwiek firmę jakąkolwiek notacją warto projekt modelowania uzupełnić o jego pragmatykę, to jest o specyfikację wszelkich warunków tworzenia modeli. Opracowanie takiej dokumentacji wymaga ustalenia tych zasad, a także zdefiniowania słownika, skończonej przestrzeni nazw i definicji, która pozwoli jednoznacznie zaklasyfikować każde pojęcie z życia firmy do właściwego, i tylko jednego, elementu modelu. Projekt modelowania procesów to nie jest proste rysowanie tego co się dzieje. Tak powstają najczęściej nieprzydatne i kosztowne zarazem dokumenty.

Projekt modelowania procesów biznesowych to wnikliwa analiza całej organizacji, sposobu zarządzania nią i udokumentowania tego jak faktycznie powstaje w niej wartość dla klienta. Nie raz niestety odnoszę wrażenie, że w wielu projektach tego rodzaju duża wartość analizy i modeli biznesowych zostaje zastąpiona skomplikowanymi i nic nie wartymi diagramami.

RACI

Poniżej matryca RACI jako uzupełnienie procedur stworzona na bazie powyższych diagramów:

Powyższa postać specyfikacji może być wygodna dla osób nieoswojonych z diagramami a użyteczna jako materiał do bieżącego użytku. Jeżeli jakaś procedura miała by zawierać tylko takie dane (wymagania)  to takie zestawienie z powodzeniem może ja zastąpić. Czynności i procesy można posortować alfabetycznie dla ułatwienia korzystania z dużej listy.

Analogiczną macierz można opracować dla dokumentów. Tę wersję bardziej polecam gdyż, co do czynności i procesów to odpowiedzialność może być wielopoziomowa (podległość służbowa), tak w przypadku dokumentów zależności te są jednoznaczne (a nie w każdej organizacji dokument jest identyfikowany jak produkt procesu).

SIPOC

W praktyce analityka często zaczynam projekty od wyspecyfikowania kluczowych procesów end-to-end. Są to procesy opisujące kluczowe działania organizacji. W takiej sytuacji SIPOC to nic innego jak abstrakcyjny opis (model) czarnej skrzynki jaką jest badany podmiot. Lista jest ograniczona wyłącznie do dostawców firmy i jej odbiorców (klientów).

Ograniczając do tego poziomu tę metodę, można opracować (firma samodzielnie lub z pomocą analityka) listę kluczowych procesów i nie raz sam zalecam taki początek projektu polegającego na mapowaniu procesów. Zagłębianie się jednak do wnętrza firmy z takim modelem jest bardzo ryzykowne, gdyż nie ma tu metody łączącej procesy w łańcuchy wyjście-wejście wiec weryfikacja modelu jest bardzo trudna a w przypadku większych organizacji praktycznie niemożliwa.

Podsumowanie

Nazywanie więc tych narzędzi (SIPOC i RACI) metodami jest moim zdaniem nadużyciem. Niewątpliwie SIPOC jest przydatną techniką prostego specyfikowania procesów. Jednak model procesów jest tu i tak przydatnym, bo weryfikowalnym, źródłem danych.

RACI jako narzędzie dokumentowania dodatkowych powiązań pomiędzy czynnościami a rolami może być przydatne jako uzupełnienie specyfikacji SIPOC i kompletnej mapy procesów biznesowych. Model w postaci diagramu BPMN to łańcuch wartości.

Warto posiadać tak opracowany model firmy. Dokumentacja taka jest trudna w wykonaniu ale szybko procentuje, gdyż:

1. porządkuje dane w działach kadr (opisy kompetencji, opisy stanowisk, eliminuje zbędne powtórzenia, wykrywa luki)
2. porządkuje zasoby procedur i zarządzeń wewnętrznych (wychwytywanie “martwych” czyli z niczym nie powiązanych zarządzeń i procedur, wskazuje brakujące),
3. pozwala na szybkie i pewne specyfikowanie wymagań na nowe lub rozbudowywane oprogramowanie wspomagające zarządzanie (wymaga jedynie określenia zakresu projektu i opracowania “wyciągu” z posiadanego modelu procesów)
4. pozwala na stałą obserwację i optymalizację procesów.

Poniżej przykładowe zestawienie zakresu obowiązków na podstawie modelu procesowego:

(zestawienie diagramów z tego artykułu w postaci uproszczonego raportu: Raport RACI SIPOC)

Źródła