PROCA, czyli proces zarządzania ryzykiem

Dzisiejszy wpis będzie trochę odbiegał od poprzednich. Jednakże pozwoli na wprowadzenie dodatkowego elementu w przedstawianiu przykładów oraz spojrzeń na procesy biznesowe oraz ich modele. Chciałbym dodać element ryzyka. Nie chciałbym tłumaczyć co oznacza ryzyko, niepewność (można o tym przeczytać w wielu publikacjach w internecie)

W publikacjach na temat zarządzania ryzykiem, pojawia się następujący proces (cykl) zarządzania ryzykiem:

1. Identyfikacja ryzyka
2. Ocena ryzyka
3. Wybór i planowanie reakcji na ryzyka
4. Monitorowanie i kontrola

Poniższy diagram (przy użyciu notacji BPMN, oddając bardziej ideę niż przepływ procesu) prezentuje moje podejście do procesu zarządzania ryzykiem – PROCA.

Podejście to, składające się poniższych kroków pochodzących z rozwinięcia liter nazwy – PROCA – można wyjaśnić następująco:

• Przygotowanie – w ramach którego nastąpi identyfikacja ryzyk, ich ocena oraz wybór właściwej metody postępowania w celu zapobieganiu zdarzeniom bądź umiejętności radzenia sobie w sytuacji, gdy określone zdarzenie wystąp
  
• Realizacja – krok procesu, którego celem jest postępowanie zgodnie z przygotowanym i co ważne zakomunikowanym planem działania. Na powyższym diagramie wejściem do procesu „Realizacji” są dwa elementy – zakończenie prac przygotowawczych lub/i wystąpienie zdarzenia ujętego podczas identyfikacji ryzyk.
• Obserwacja – bardzo ważny krok procesu, w którym uczestnicy działań projektowych lub prowadzonej działalności operacyjnej, obserwują otoczenie pod kątem zakomunikowanego planu, a także możliwych do pojawienia się nowych szans lub zagrożeń. Świadomość zmieniającego się otoczenia i tego, że decyzje są podejmowane w warunkach niepewności, pozwala na zmniejszenie ryzyka braku realizacji zaplanowanych celów. Przy wejściu do tego kroku, na diagramie pojawia się zdarzenie związane z czasem. Obserwacja może odbywać się także w sposób uporządkowany, na cyklicznych spotkaniach, podczas kŧórych następuje przegląd dotychczasowych działań oraz ewentualnie burza mózgów o obserwacjach, sugerowanych zmianach.
• (Ciągła) Aktualizacja – wyniki obserwacji, zebrane informacje zwrotne od uczestników procesu, powinny być przeglądane i analizowane pod kątem wpływu na wcześniej zakomunikowany plan działania. Jeżeli okaże się, że konieczne jest dostosowanie, powinno zostać wykonane i przekazane do realizacji. I w tym momencie pojawia się pętla, której zakończenie jest związane z końcem projektu (o ile pewne ryzyka nie zostały przeniesione na proces wykorzystujący produkty projektu) lub zmianą przebiegu, warunków realizacji procesu. Stąd właśnie przy określeniu tego kroku oraz w samej nazwie podejścia słowo „Ciągła”.

Tak określony sposób postępowania kładzie nacisk na 3 aspekty:

• zmienność otoczenia i konieczność jego obserwacji
• to, że plan postępowania nie jest stworzony na zawsze i powinien podlegać weryfikacji.
• to, że nieodłącznym procesem tego procesu jest komunikacja

Reklama

SIPOC na bazie diagramu BPMN

W wielu przedsiębiorstwach, które udostępniają swoim pracownikom – np. pracownikom obsługującym klientów – system informatyczny, funkcjonuje proces obsługi zgłoszeń błędów/problemów. Proces ten funkcjonuje obok zwykłych/głównych procesów (ang. core processes), wspieranych przez system informatyczny i w których biorą udział pracownicy. W kontekście systemu informatycznego pracownik staje się użytkownikiem (albo inaczej patrząc aktorem).

Ideę takiego procesu obrazuje poniższy diagram w BPMN.

W jednym z ostatnich wpisów wspomniałem o diagramie SIPOC. Jest on używany do zobrazowania przepływu pracy. Po rozwinięciu poszczególnych liter nazwy – umieszczonych także w odpowiednich miejscach na diagramie – mamy następujące elementy:

• Supplier (S), czyli Dostawca – oznacza podmiot, który dostarcza informacje, zasoby do realizowanego procesu. Na powyższym diagramie jest to użytkownik systemu, który zgłasza problem – oznaczony przez (S).
• Input (I), czyli zasoby wejściowe – oznacza informacje, zasoby dostarczane przez Dostawcę. Powyżej jest to zgłoszenie problemu/błędu z jego opisem, czasem wystąpienia, identyfikatorem transakcji/błędu, danymi identyfikacyjnymi użytkownika. Obiekty oznaczone przez (I).
• Process (P), czyli proces – działania w określonej kolejności, które wykorzystuję zasoby wejściowe w celu zwiększenia ich wartości lub wytworzenia efektu końcowego (wyjściowego). W tym wypadku jest proces ze wskazanymi czynności zmierzającymi do znalezienia rozwiązania. Uczestnicy procesu analizują dostarczone informacje przez użytkownika. Wykorzystują przekazane dane kontaktowe w celu uzyskania dodatkowych wyjaśnień. Proces (P) składa się z kroków „Analiza zgłoszenia”, „Poszukiwanie rozwiązania” oraz „Wybór/Wskazanie rozwiązania”.
• Output (O), czyli efekt wyjściowy – oznacza informacje, zasoby dostarczane przez proces. Na diagramie jest to rozwiązanie (jego opis), oznaczony przez (O).
• Customer (C), czyli klient – oznacza podmiot, który otrzymuje efekt wyjściowy. W tym wypadku jest to inicjatora zgłoszenia, oznaczony przez (C).

Więcej o diagramie SIPOC można przeczytać u źródła (Six Sigma).