Pytania o … SIPOC

W książce Lean Banking” (F. Majorana, A. Morelli) można znaleźć poniższy diagram, który wskazuje „przykład kolejnych czynności , jakie muszą zostać wykonane, aby sporządzić poprawnie SIPOC”. Diagram na potrzeby wpisu został przetłumaczony oraz lekko zmodyfikowany (co widać na diagramie).

Spróbujmy odpowiedzieć na postawione pytania na bazie procesu realizacji zamówienia przy użyciu sklepu internetowego, którego przykład wykorzystuję często na blogu. Jest to proces „łatwo” dostępny dla większości użytkowników sieci Internet. Taki użytkownik ma możliwość poznania całego przebiegu procesu od jego zainicjowania aż do samego końca (otrzymania zamówionego produktu). W sytuacjach problemowych (np. brak zamówionego produktu lub inny problem), to właśnie do niego jest kierowana odpowiednia informacja z prośbą o podjęcie decyzji co dalej z procesem. Użytkownik wybierając konkretny produkt orientuje się przeważnie kto jest jego dostawcą, jaka jest jego cena na rynku oraz parametry.

sipoc_pytania_full

Odpowiedzi na pytania mogą być następujące (punkty odpowiadają numerom pytań na diagramie a odpowiedzi są poglądowe):

  1. Jest to proces realizacji zamówienia ze sklepu internetowego z dostarczeniem produktu w sposób wskazany przez Klienta. Klient płaci z zamówiony produkt w wybrany sposób (wybierając z opcji dopuszczonych przez sklep, po spełnieniu określonych warunków).
  2. Pytania odnoszą się do granic procesu. Określenie tego, gdzie zaczyna i kończy dany proces jest istotne z różnych względów. W przypadku procesu zamówienia można przyjąć, że złożenie zamówienia jest początkiem procesu a dostarczenie produktu jest jego końcem. W zależności od tego, czy Klient jest nowy lub istniejący, w trakcie tego procesu następuje rejestracja lub nie nowego użytkownika sklepu internetowego. Jednakże to, że Klient się zarejestruje nie oznacza, że złoży zamówienie – może je np. zapisać na przyszłość. Zarejestrowani użytkownicy mogą przeważnie skorzystać z większej liczby opcji oraz udogodnień jakie daje dany sklep.
  3. Output’em procesu jest:
    a. produkt dostarczony do Klienta za pomocą ustalonego sposobu dostawy oraz
    b. zaksięgowana płatność za produkt na koncie sklepu
  4. Beneficjentem output’ów są:
    3a. Klient;
    3b. Działa finansowy sklepu internetowego oraz dostawcy produktów;
  5. Od output’u:
    3a. Klient oczekuje, że produkt jest zgodny w parametrach z zamówionym produktem, że nie jest uszkodzony; jest kompletny;
    3b. Firma oczekuje, że dokonana płatność przez Klienta dotarła we właściwej wysokości na konto sklepu;
  6. Aby proces miał szansę zaistnieć to:
    a. Produkt musi być w magazynie sklepu;
    b. Dostawca produktu dysponuje możliwościami uzupełnienia produktu na zamówienie;
    c. Sklep internetowy musi być dostępny dla użytkowników (strona musi działać a serwery były w stanie obsłużyć ruch);
    d. Sklep musi obsługiwać różne formy płatności;
    e. Sklep musi mieć ustalone mechanizmy dostawy produktów;
    f. Pośrednicy uczestniczący w procesie są gotowi na przewóz produktów;
    g. Powinien istnieć określony regulamin sklepu określający prawa i obowiązki poszczególnych stron transakcji (Klienta oraz sklepu jako całości);
    h. Ceny produktów są adekwatne do produktów;
    i. Klient musi wybrać produkt, określić parametry zamówienia oraz je potwierdzić.
    Warunki zaistnienia procesu są wynikową możliwości technicznych, posiadanych zasobów oraz planowanych do osiągnięcia efektów. Input’y w ramach procesu są łączone i pozwalają na osiągnięcie output’ów – na poszczególnych krokach procesu są jego wejściami przekształcanymi w wyjścia.
  7. Dostawcą input’ów są: dział zamówień sklepu (6a), producent produktów (6b), dział techniczny wraz z wsparciem firmy hostingowej (6c-6d), dział dystrybucji (6e-6f), sklep jako całość (6g-6h) oraz Klient (6i);
  8. Input’y wskazane powyżej powinny się charakteryzować tym, że:
    a. Są dostępne w momencie czasu, w którym Klient decyduje się na złożenie zamówienia;
    b. Produkty dostępne w sklepie w zakresie parametrów są zgodne z rzeczywistością;
    c. Formy płatności oferowane przez sklep funkcjonują poprawnie i bez zakłóceń;
    d. Firmy pośredniczące działają w ramach zgodnych z regulaminem sklepu;
    Sposób ich wykorzystania oraz efekty są zgodne z regulaminem sklepu;

Powyższe odpowiedzi składają się na uogólniony przykład. Przykładając je do konkretnego procesu uległyby większym lub mniejszym zmianom. Wskazując konkretne produkty (ich rodzaj, charakter) można byłoby dodać dodatkowe wymagania/charakterystyki lub wymagania przy których proces może zaistnieć.

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.

Proces obsługi zgłoszeń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).

Nieudany proces

Miesiąc temu pisałem we wpisie o procesie zamówienia, w którym firma dostarczająca produkt informowała mnie o każdym zrealizowanym i planowanym kroku z bardzo dużą dokładnością. Proces zakończył się sukcesem, w szacowanym terminie – produkt został dostarczony. Mogę powiedzieć, że każdy z przekazanych statusów odzwierciedlał sytuację rzeczywistą. Do każdego z elementów SIPOC (o którym pisałem już wielekrotnie) można przyporządkować określone obiekty z podanego procesu.

Dzisiaj wrócę również do tematu procesu zamówienia. Jednakże niestety muszę przytoczyć przykład rzeczywistego procesu, w którym to fakt, byłem informowany o każdym etapie realizacji, ale niestety komunikaty nie odzwierciedlały rzeczywistości, patrząc z mojej perspektywy. Na początku wszystko wyglądało identycznie: złożyłem zamówienie, czyli wybrałem produkt, podałem parametry zamówienia, zapłaciłem, a produkt został wysłany, o czym poinformował mnie pierwszy komunikat. I tu się podobieństwa kończą. Następny komunikat stwierdzał: uzgodniono termin przesunięcia dostawy. Nie było ani kontaktu mailowego ani telefonicznego od firmy kurierskiej. Ok, machnąłem ręką, nowy termin był w ostateczności akceptowalny, jak nie dojdzie produkt będę się martwił.

nieudanyprocess450px

Kolejny komunikat poinformował: brak kontaktu z odbiorcą, produkt zwrócony. I w tym momencie już nie było ciekawie. Ani nie wiedzieliśmy, że kurier jednak nie przyjedzie, ani nie podał wcześniej szacowanej godziny dostawy, a na koniec pomimo aktywnego telefonu i przebywania w strefie objętej zasięgiem – kontaktu nie było. Skończyło się reklamacją skierowaną do firmy kurierskiej. Wielokrotnie zamawialiśmy produkty u tego dostawcy i z wykorzystaniem kuriera – nigdy nie było problemów.

Potem okazało się, że produkt wrócił do firmy, u której zamawiałem produkt, a po kilku dniach nastąpił zwrot środków na konto.  Choć niestety nie mam zamówionego produktu, czy element oczekiwanego “wyjścia” (ang. output) w ramach modelu SIPOC nie został zrealizowany zgodnie z oczekiwaniami. Zostałem z “wejściem” (ang. input) – swoją potrzebą oraz środkami na koncie. Dostawca produktu (ang. Supplier) oraz Odbiorca produktu/Klient (ang. Client) uczestniczyli w tym procesie, ale nie można powiedziec, że są zadowoleni – z jednego strony produkt nie został sprzedany, a z drugiej dostarczony. Sam proces  (ang. process)“podobno” – podkreślam to słowo – został zrealizowany, choć mam wątpliwości, czy z tak funkcjonującym kurierem wszystkie kroki rzeczywiście zostały zrealizowane.

Powyższy diagram obrazuje taką zmianę sytuacji, z oznaczeniem, że nastąpiła kolejna zmiana strony obsługującej oraz w procesie nie ma statusu „produkt dostarczony”.

Czas realizacji a “szybkość” procesu

Składając różne elementy procesu, o których pisałem na blogu, można utworzyć uogólniony proces, który:

  • zmienia wejścia procesu w wyjście procesu, na co zwracana jest uwaga w modelu SIPOC.
  • ma wejścia i wyjścia procesu, uzależnione od rodzaju procesu.
  • posiada kroki dodające wartość dla odbiorcy procesu (kroki oznaczone na diagramie jako VAP) lub tylko dla innych interesariuszy zainteresowanych (kroki na diagramie oznaczone jako VAI) procesem.
  • obsługuje wyjątki lub alternatywne ścieżki przebiegu procesu.

Każdy realizowany proces można opisać za pomocą jego czasu realizacji, czyli Delivery Cycle Time. Wartość ta informuje jak długo trwa proces od jego zainicjowania przez Klienta, na przykład poprzez złożenie zamówienia, dostarczenie dokumentu, złożenie zapytania, po zakończenie procesu, rozumiane jako dostarczenie produktu, na przykład przedmiotu zamówienia, akceptacji dokumentu, odpowiedzi na zapytanie.

szybkosc450px

Wartość ta interesuje nie tylko odbiorcę procesu, ale także księgowość, inwestorów oraz inne grupy interesariuszy. Biorąc pod uwagę powtarzalność procesu, najlepszą sytuacją, gdy w danym czasie, na przykład miesiąca, można zrealizować kilka, kilkanaście lub więcej przebiegów procesu.

Na bazie tych informacji można byłoby spróbować obliczyć “szybkość” procesu. Dostarczając 1 produkt w czasie T, możemy potencjalnie policzyć liczbę dostarczanych produktów, obsługiwanych zamówień w czasie jednostki czasu, np. miesiąca, czyli [Miesiąc/T] sztuk/per miesiąc.

Sformułowanie “szybkość” używam w cudzysłowach, aby zaznaczyć potoczne rozumienie tego słowa, przez porównanie na przykład do szybkości drukowania (10 kartek/minut). Obok tego pojęcia funkcjonuje także pojęcie “prędkości” (wartości z wektorem). W przypadku procesów pojęcia te też podlegają próbie rozróżnienia, wychodząc od pojęć z terminologii angielskiej.

Dlaczego taki proces?

Często wykonuję zakupy w interneciem, mam okazję korzystać z różnych sklepów. Ich systemy do sprzedaży elektronicznej są mniej lub bardziej rozbudowany. Czas dostawy jest podany z większą lub mniejszą dokładnością. Poza jednym przypadkiem, opisanym na blogu, przy okazji wpisu “Diagram Venna w akcji” nie miałem problemów z otrzymaniem zamówionego produktu w akceptowalnym czasie. Dlatego diagram ze wskazanego wpisu posłuży mi do dzisiejszego wpisu.

zakupy2x

Na powyższym diagramie znajduje się zmodyfikowana reprezentacja, tego nieudanego procesu, tak, aby pasowała do różnych przypadków procesów. Elementy z mojej perspektywy, czyli Klienta, zostały przedstawione w postaci procesu. Elementy od strony sklepu internetowego, czyli Dostawcy, zostały przedstawione jako wsad (baza Produkty), wynik (baza Finanse) i zasoby (element Pośrednika) niezbędne do przeprowadzenia tego procesu. Linia przerywana obrazuje, że realizacja części procesu jest rozłożona w czasie. Pośrednikiem może być kurier, podmiot usług pocztowych, punkt odbioru itp.

Będąc projektantem, wykonawcą czy odbiorcą takiego procesu można zadać pytanie “Dlaczego taki proces?”. Pytanie tak postawione jest dość ogólne, dlatego łatwiej na nie odpowiedzieć wykorzystując następujące pytania (nie jest to zestaw zamknięty):

  • Czego oczekuje i ceni Klient?
    Na to pytanie częściowo odpowiedziałem we wstępie. Oczekuje, że znajdzie poszukiwany produkt, będzie on dostępny i w łatwy i bezproblemowy sposób uda się go zamówić. Natomiast realizacja procesu przebiegnie w akceptowalnym i zgodnym z deklaracjami czasie.
    Więcej o stronie Klient w modelu SIPOC.
  • Czego oczekuje i ceni Dostawca?
    Po pierwsze, chce, aby jego produkty znalazły nabywców, że proces zamówień pozwoli je wybrać oraz zamówić. Na diagramie świadczy o tym strzałka z kierunkiem od Bazy Produkty do Procesu.
    Po drugie, że otrzyma przychód z produktu, o czym świadczy strzałka z kierunkiem od Procesu do Bazy Finanse.
    Po trzecie, że wybrani Pośrednicy zrealizują proces zgodnie z oczekiwaniami.
    Więcej o stronie Klient w modelu SIPOC.
  • Jakie są słabe i mocne strony procesu?
    Wielokrotnie na blogu pisałem o ocenie procesu, jego opomiarowaniu.
  • W czym proces jest lepszy od analogicznego procesu?
    To pytanie odnosi się do benchmarkingu oraz postawionych celów dla jakości usługi.

Proces dla sprawozdań finansowych

Przeglądając poprzednie wpisy, trafiłem ponownie na sformułowanie “elektronizacja procesu„, a po wpisaniu go do wyszukiwarki z czystej ciekawości, trafiłem na artykuł o przygotowywaniu spawozdań finansowych. Dokładnie chodziło o artykuł dot. zmiany procesu przygotowywania sprawozdań finansowach z papierowego/ręcznego na bardziej zautomatyzowany, oparty o dane przechowywane w formie elektronicznej.

Z jednej strony procesu, na tzw. wejściu mamy spływające dane finansowe od różnych podmiotów (tzw. dostawców) oraz obowiązując reglacje (m.in. Ustawa o rachunkowości, MSSF itd.). Z drugiej strony, odbiorców/klientów, np. podmioty regulujące działanie rynku finansowego, do których są przekazywane sprawozdania w określonym formacie, tworzące tzw. wyjście. Zebranie danych, przygotowanie sprawozdań i przekazanie w ustalonym formacie stanowią proces. Wskazane obiekty oraz kroki to elementy SIPOC. Na poniższym diagramie przedstawione jest to wizualnie.

sprawozd450

Taki proces może odbywać się ręcznie, w oparciu o dostępne narzędzia. Jeżeli jednak chcemy go usprawnić, zautomatyzować czy ustandaryzować, z pomocą przychodzi język XBRL. XBRL (ang. Extensible Business Reporting Language) jest standardem opracowanym do realizacji takich działań jak: usprawnienie wymiany, interpretacja, analiza i prezentacji sprawozdań gospodarczych (nie tylko finansowych). Można powiedzieć, że XBRL to język do modelowania sprawozdaw czości finansowej. Jego zastosowanie pozwala na realizację zasygnalizowanych powyżej celów. Istotne jest to, że stosowanie takiej ustandaryzowanej formy to także oszczędność czasu i kosztów w podmiocie, co obecnie ma bardzo duże znaczenie dla budowy przewagi konkurencyjnej. W kolejnym newsie postaram się przybliżyć bardziej ten język.

Wróćmy jednak do powyższego diagramu, na którym dodany został krok Transformacji raportów. W ramach tego kroku otrzymane dane wejściowe są przetwarzane na raporty w tym języku, zrozumiałe przez stosowane w procesie narzędzia. Zastosowanie analogicznego rozwiązania przez dostawców raportów, spowodowałoby, że poprawiłaby się znacznie sprawność procesu. Możliwość przekazania ich dalej w tym formacie, zmniejsza liczbę transformacji raportów z jednej postaci do drugiej.

Dwa kroki procesu – różnorodność rozwiązań

Wyobraź sobie, że chcesz kupić książkę. Jakie wersje książki potencjalnie mogą Cię zainteresować? Wydanie w miękkiej okładce, w sztywnej, wersja pocket, wersja na czytnik elektroniczny, audiobook, druk na żądanie. Możliwości jest jak widać kilka. Możesz otrzymać książkę w ciągu kilku sekund lub kilku dni. Gdy lubisz trzymać książkę w ręku, słyszeć szelest, postawić książkę na półce – pomimo długiego oczekiwania, zamówisz książkę np. w sztywnej oprawie. Gdy chcesz jedynie mieć lekturę w podróży, jedną z wielu na czytniku, wybierzesz wersję elektroniczną.

W poprzednim wpisie o modelu długiego ogona wyróżniłem dwie powiązane czynności procesu „Wybór rodzaju procesu” (lewa strona poniższego diagramu) oraz „Realizacja zamówienia” (prawa strona poniższego diagramu). Na diagramie umieściłem pogrupowane w zależności od realizacji powyższe wersje książki.

Diagram2

Wskazane czynności są sposobem dostarczenia zamówienia dla klienta. W zależności od dokonanego wyboru, biorąc pod uwagę dwa „skrajne” rozwiązania:

  • wersja na czytnik elektroniczny – proces jest krótki, może zostać zakończony w przeciągu kilku-kilkunastu minut, w całości zrealizowany w ramach platformy sprzedażowej, bez angażowania dodatkowych jednostek,
  • wydruk na żądanie – proces jest dłuższy, trwa kilka – kilkanaście dni, realizowany jest w dużym stopniu poza platformą, angażuje zarówno jednostki powiązane (drukarnia), jak i zewnętrzne (poczta, firma kurierska, pracownik punktu odbioru zamówienia),

Oceniając realizację takiego procesu, konieczne jest właściwe zdefiniowanie mierników uwzględniających różne realizacje procesu i jego cechy charakterystyczne (SIPOC).

Pytania o realizację procesu

Ostatnio wysyłając przesyłke, postanowiłem sprawdzić, za pomocą dostępnych narzędzi, jaki jest status przesyłki – czy dotarła, czy została odebrana. Udało mi się sprawdzić I przy okazji pomyślałem, że tak naprawdę jest to pewien proces rozciągnięty w czasie, gdzie inicjatorem jest nadawca przesyłki, a na końcu procesu jest odbiorca przesyłki. Istotnym elementem procesu są komunikaty przekazywane od obsługującego proces do odbiorcy – takim komunikatem jest przekazanie informacji do odbiorcy o oczekującej przesyłce w miejscu odbioru.

Proces od strony podmiotu obsługującego można zobrazować następująco:

Diagram1

W przypadku tego procesu, patrząc z perspektywy metody SIPOC można powiedzieć, że mamy: Dostawcę (nadawca przesyłki), Wejście (rodzaj przesyłki, dane odbiorcy, waga, inne parametry), Proces (realizacja przesyłki), Wyjście (przesyłka dostępna w miejscu docelowym, komunikat do odbiorcy), Klient (odbiorca przesyłki).

Jako nadawca – Klient – chciałem wiedzieć jak jest realizowany proces przesyłki.
Pytania, które mógłbym zadać, przykładowo:

  • Jaki poziom szczegółowości postępu procesu (statusy) jest potrzebny? Np. Nadany, przesłany, odebrany. Więcej o statusach.
  • Jakie informacje o przesyłce (wejście, wyjście) powinny być dostępne? np. Numer przesyłki, miejsce nadania itp.
  • Jakie informacje z realizacji procesu są mi potrzebne? np. Daty realizacji.
  • Do kiedy mogę sprawdzić, czy przesyłka dotarła? np. 2 tygodnie od zakończenia procesu, gdybym nie mógł sprawdzić przesyłki na bieżąco.

 

Informacja dodatkowa z procesu, to ile czasu może trwać dostarczenie określonej przesyłki do danego miejsca, gdyby korzystał częściej z tego mechanizmu. Jest to cenne, aby wiedzieć z jakim wyprzedzeniem lub po jakim czasie może druga strona zareagować na przesłaną informację.

PoDajCie dAlej, czyli trochę o PDCA

Wielokrotnie w organizacji można się spotkać z sytuacją, gdy dana informacja, dokument jest przekazywana zgodnie ze strukturą organizacyjną lub w poprzek struktury. Różne działania w jednym Pionie funkcjonalnym mogą odbić się w innym Pionie. Można usłyszeć, że „oni tak robią, może też spróbujemy? Osiągają dobre efekty”. Takie sformułowanie może się zarówno odnosić do komunikacji, zarządzania projektami, realizacji procesów, wprowadzaniu zmian czy po prostu w ramach określonego procesu. Np. Zmiana wyceny pracy, wprowadzenie rozliczeń wewnętrznych między współpracującymi jednostkami, nie zawsze musi oznaczać, że taki sposób postępowania przyjęty został przez wszystkich. A co jeśli się sprawdza? Albo zaobserwowano, że można go było zmienić i zaadaptować? Dobre rozwiązania warto podawać dalej, weryfikować i aktualizować, w szczególności, gdy dane jednostki są uczestnikami jednego z głównych procesów organizacji.

Na powyższym diagramie wskazano różnej długości procesy, w które zaangażowane są jednostki z różnych pionów. W ramach każdego z tych procesów konieczne jest zadbanie o spójność działania, tak, aby proces był efektywny i sprawny. Dodatkowo zaznaczono – poprzez znaczek dokumentu – miejsca styku jednostek, potencjalne miejsca, gdzie występują różnice w działaniu i które należy zbadać. Kierunki dalszego dostosowania – podaj dalej – zostały zaznaczone linią przerywaną. W ich likwidacji może być pomocne podejście PDCA.

Podejście PDCA (tzw. Cykl Deminga) zakłada, że po Zaplanowaniu działań (ang. Plan), następuje ich realizacja (ang. Do), po czym efekt zaplanowanych i zrealizowanych działań jest sprawdzany (ang. Check). Po sprawdzeniu i określeniu różnic, możliwości, koniecznych modyfikacji następuje ich wdrożenie (ang. Act). Wdrożenie nie następuje samo w sobie, zostaje zaplanowane, działania są włączone do dotychczasowych planów. Sam proces zaczyna się od początku. W pewnym momencie na kolejnych punktach styczności proces ulegnie poprawie. Doświadczenia (ang. lessons learned) można podać dalej do kolejnego punktu i rozpocząć proces doskonalenia procesu od początku (a raczej go dalej kontynuować).

Materializacja ryzyka jako „inicjator” procesu

Załóżmy, że został wdrożony system informatyczny wspierający główne procesy biznesowe. W trakcie realizacji projektu, w ramach Rejestru Ryzyk, który jest jednym z elementów zarządzania ryzykiem, umieszczono ryzyko „błędne wykorzystanie aplikacji”. Ryzyko to zostało wskazano jak możliwe do wystąpienia po wdrożeniu systemu. Odpowiedzialność za to ryzyko ponosi właściciel systemu/danego procesu biznesowego.

W trakcie realizacji procesu biznesowego, użytkownik napotkał na problem i zgłosił go – nastąpiło wejście (w rozumieniu diagramu SIPOC) do procesu obsługi błędów. Problemem zajął się użytkownik i okazało się, że problem nie wynika z błędu systemu a z błędnego wykorzystania systemu przez użytkownika. Błędne wykorzystanie systemu – materializacja ryzyka – mogła nastąpić z niewiedzy, niekompletnych lub niezrozumiałych materiałów, braku wykorzystania dostępnych procedur itp.

Można powiedzieć, że materializacja ryzyka zainicjowała nowy proces – zaprezentowany na poniższym przykładowym diagramie BPMN.

Wejściem do procesu jest zgłoszenie błędnego wykorzystanie systemu, które powinno zostać wyjaśnione przez właściciela biznesowego procesu głównego, na przykład poprzez rozszerzenie materiałów pomocniczych, procedur lub dedykowaną komunikację.

We wskazanej sytuacji przygotowanie odpowiednich materiałów jest działaniem zmniejszającym wpływ tego ryzyka. Jednakże rzeczywistość biznesowa jest zawsze bardziej zróżnicowana niż przypadku opisane w materiałach czy procedurach. Często konieczna jest ich modyfikacja po jakimś czasie w wyniku zgłoszeń użytkowników końcowych czy obserwacji pierwszych linii wsparcia. Czasami następuje to również w wyniku materializacji ryzyka.