Loading ...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 proces (problem, projekt) i jego rezultat (produkt).
- A–Accountable, to osoba odpowiedzialna za zatwierdzenie, będąca z reguły ostatnia czynnością procesu, wspiera bezpośrednio osobę odpowiedzialną.
- C–Consult, to osoba posiadająca wiedzę o przedmiocie procesu, która zwykle konsultuje i zatwierdza merytorycznie podejmowane przez powyższe osoby decyzje.
- I–Inform, to osoba, która jest informowana o podejmowanych działaniach lecz nie ma wpływu na nie.
Powyższy schemat opisu procesu (czynnoś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:
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 sam spis zawiera wiele pozycji w kolumnach (szczególnie wejscie i wyjście), co nie nie ułatwia odtworzenia procesu i jego możliwych scenariuszy, model procesu i tak musi powstać.
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).
RACI 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.
Jeżeli faktycznie, każdy proces ma osobę odpowiedzialną (Wykonawcę), to już obligatoryjne wskazanie, jako odrębnych ról, pozostałych trzech może być sztuczne. Nie zawsze produkt procesu jest odrębnie zatwierdzany, zaś co do konsultacji i informowania to jest to raczej decyzja wykonawcy, czasem wymóg procedury, która jest odrębnym dokumentem. Reagowanie na informacje (osoba informowana) nie musi być obligatoryjne.
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.
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ę. 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.
Po raz kolejny kłania się brzytwa Ockhama. Istnienie takich narzędzi jak SIPOC czy RACI to wtórne byty, możliwe do wytworzenia jako dane „wyciągnięte” z dobrze opracowanego modelu procesów biznesowych
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ą tekstowego „zapisu” procesów, jeśli forma graficzna nie jest preferowana. Jednak model procesów jest tu i tak przydatnym, bo weryfikowalnym, źródłem danych.
RACI jako narzędzie dokumentowania 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 zawiera te dane i nie wymusza określania każdego z czterech atrybutów dla każdej czynności/procesu co nie raz jest, jak wspomniałem, sztuczne. RACI, zastosowane ortodoksyjnie, to w moich oczach nie raz zbędna komplikacja stanu faktycznego. Zamiast tego w zupełności wystarczą procedury mówiące np. co i w jakiej sytuacji należy konsultować i z kim.
Warto posiadać tak opracowany model firmy. Dokumentacja taka jest trudna w wykonaniu ale szybko procentuje, gdyż:
- porządkuje dane w działach kadr (opisy kompetencji, opisy stanowisk, eliminuje zbędne powtórzenia, wykrywa luki)
- porządkuje zasoby procedur i zarządzeń wewnętrznych (wychwytywanie „martwych” czyli z niczym nie powiązanychzarządzeń i procedur, wskazuje brakujące),
- 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)
- 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)
Moim zdaniem RACI nie jest modelem, ale sposobem opisu implementacji (wdrożenia) modelu. Modele procesowe posługują się pojęciem roli, która jest niezależna od przyjętej struktury organizacyjnej. Z kolei przyporządkowanie RACI odwołuje się do konkretnych funkcji w strukturze organizacyjnej (co widać na załączonym obrazku). Czyli tak bym tego używał:
1) Zaprojektować proces (stworzyć model)
2) Wdrożyć proces w organizacji opisując go w ewentualnych procedurach z pomocą RACI.
przy czym pierwsze leży zdecydowanie w gestii projektanta / architekta /analityka. Druga czynność powinna być wykonana w ramach organizacji, a projektant powinien ograniczyć się do konsultacji.
Do powyższego, z czym się zgadzam, warto dodać, że kompletny model organizacji powinien zawierać powiązania obiektów na modelach z innymi, powiązanymi, dokumentami w firmie. Dlatego artykuł uzupełniłem o kolejny przykładowy diagram z komentarzem. To jest także powodem, dla którego warto stosować zaawansowane narzędzia do modelowania. Proste narzędzia, takie jak popularny Visio, nie daje nawet szans na objęcie w dokumentacji wszystkich relacji pomiędzy dokumentami powiązanymi w modelach, a ich ręczne weryfikowanie jest pracochłonne. Niestety tego rodzaju narzędzia są powszechnie stosowane nawet a dużych firmach doradczych, co powoduje, że albo opracowane dokumenty są niekompletne i niespójne (czyli praktycznie nie przydatne) albo są bardzo pracochłonne czyli kosztowne zarówno w wytworzeniu jak i w utrzymaniu.
Witam, przebrnęłam przez tekst o RACI….
To prawda, że nagminnie stosowane VISIO nie wszystko opisze,
ja bym jednak do RACI czy VISIO, czy cokolwiek innego dodała jako obowiązkowe w każdej organizacji system prowadzenia projektów,
gdzie dopasowując chociażby Prince 2 do specyfiki firmy, możemy bardzo przejrzyście stworzyć reguły gry dla starych i wszystkich nowych pracowników, od których tak naprawdę zależy powodzenie procesu biznesowego.
To prawda. Nie wspomniałem o tym ale faktycznie sformalizowane metody zarządzania projektami, dostosowane do treści i zakresu projektu, to bardzo silne narzędzie zarządcze dla kierownika projektu i dla sponsora projektu jako narzędzie nadzoru nad projektem.
[...] Skutecznie opracowany model procesów to wynik analizy, która pokazuje granice pomiędzy tymi obsza… [...]
[...] przypadku udziałowców projektu dobrą praktyką jest budowa prostej macierzy RACI (kliknij po opis tego narzędzia). Co do zasady przyjmuje się, że każdy obszar projektu [...]
[...] Swego czasu pisałem o modelowaniu organizacji wskazując na potrzebę użycia nie tylko notacji ale także zbudowanego dla konkretnego modelu słownika: 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. (za RACI, SIPOC i inne czyli modelowanie organizacji c.d.). [...]
[...] RACI, SIPOC i inne czyli modelowanie organizacji c… [...]