W jednym z poprzednich wpisów, skupiłem się na materializacji ryzyka określonego jako błędne wykorzystanie aplikacji. W oczach danego użytkownika, jest to problem, dla którego oczekuje rozwiązania. W procesie wskazałem rozwiązanie „docelowe”, nie podając co ma nastąpić w danym momencie, jaka informacja zwrotna powinna trafić do użytkownika. I to całościowe spojrzenie jest charakterystyczne dla metody 8D (ang. methodology 8D).

Diagram (w BPMN)  przedstawia kroki tej metody z nałożonymi krokami wcześniej określonymi. Widać, że proces rozwiązania problemu nie jest kompletny. Nastąpiło przekazanie do właściciela biznesowego, ale niestety nie wiadomo, czy sugestia zmian zostanie wykonana. Istotne jest wspólne rozwiązania jaka powinna być informacja zwrotna w danym momencie. Powinien również zostać ustalony sposób weryfikacji zaproponowanego rozwiązania. Ostatni krok – „Docenianie pracy zespołu” – ma istotne znaczenie dla dalszej współpracy i dla świadomości, że wspólna praca była potrzebna i została zauważona.

Wykonując te czynności nawet się nie zastanawiamy, że one mają charakter mniej lub bardziej skomplikowanego procesu, w który zaangażowani są ludzie oraz maszyny (które jak najbardziej mogą być uczestnikami procesu). Idąc dalej można powiedzieć, że pewne czynności mają charakter sekwencyjny a pewne synchroniczny.

Diagram w BPMN przedstawia ten prosty proces przygotowania ciasta.

Zastanówmy się nad cechami tego procesu:

1. zorientowany na wykonanie zadania, czyli upieczenie ciasta
2. wykonywany zgodnie z procedurą, czyli przepisem zawierającym informację o kolejnych czynnościach, wyborach,
3. wykonanie kolejnych czynności oznacza postęp procesu, przybliżenie do efektu końcowego,
4. może zostać wykonany przez dwie osoby, jedna osoba przygotowuje ciasto, a druga równocześnie przygotowuje nadzienie
5. wiadomo, który uczestnik jest za co odpowiedzialny.
6. czynności do wykonania są znane, czas oczekiwania na wyrośnięcie oraz pieczenie również, co pozwala na ustalenie kolejności oraz momentu rozpoczęcia poszczególnych czynności,
7. po upieczeniu ciasta, przechodzi się do innych zadań związanych ze świętami, proces nie jest powtarzany,
8. czynności są ze sobą powiązane czasowo,

Wymienione cechy pozwalają na określenie rodzaju procesu, jego perspektywy. Można rózróżnić proces sekwencyjny (określane także jako diachronic) oraz synchroniczny (synchronic). Cechy (1), (2). (3), (5), (6), (7) są właściwe dla procesów sekwencyjnych. Pozostałe dwie – (4) oraz (8) – dla procesów synchronicznych. O dokładnym rozróżnieniu można poczytać w standardzie konsorcjum SCIPIO.

Ciekawą cechą jest (6). Jest ona istotna dla procesów workflow (strumieni pracy), gdzie lista zadań jest wykonywana w określonej kolejności przez określonych uczestników.

• luka między stanem pożądanym a rzeczywistym, patrząc całościowo na organizację;
• luka między stanem możliwości a stanem potrzeb przykładowo w zakresie zasobów o określonym doświadczeniu, zaangażowaniu, umiejętnościach;
• luka między posiadanymi lub pozyskanymi w przeszłości możliwościami a rzeczywistymi/realizowanymi osiągnięciami, efektami działalności, która najlepiej pokazuje, czy przedsiębiorstwo idzie w oczekiwanym kierunku, czy jego osiągnięcia sprzedażowe, inwestycyjne, w zakresie polityki społecznej itp. odpowiadają posiadanym zasobom oraz zrealizowanym przedsięwzięciom.

Spojrzenie to jest właściwe dla poziomu całej organizacji, jednakże czy nie można tego przełożyć na niższy poziom? Pojedynczego procesu? Odpowiedź jest prosta – tak, w szczególności stosując zasady benchmarkingu lub reinżynierii procesów biznesowych.

Załóżmy, że mamy fragment procesu, gdzie po zakończeniu zadania przez jednego z uczestników procesu, efekt jest „konsumowany” przez innego uczestnika w kolejnym kroku. Diagram (w BPMN) prezentuje „oficjalny” i rzeczywisty przebieg procesu z zaznaczeniem luki.

W procesie konieczna byłaby modyfikacja luki między wyjściem „X” a wejściem „Y”. Różnica wynika z założenia, że każdy z uczestników chce wykonać jak najlepiej swoją pracę, jednakże oczekiwania uczestnika o Roli Y co wejścia do swojego zadania, są różne od rzeczywistego wejścia, produkowanego na wyjściu przez uczestnika o Roli X. W procesie konieczne jest wtedy przeznaczenie czasu na wyjaśnienia lub poprawki. W ramach benchmarkingu możliwe byłoby poprawienie tego procesu – na przykład poprzez zderzenie oczekiwań obydwu stron – Roli X i Roli Y. Może efekt pracy Roli X jest spowodowany przez jakość materiału, który otrzymuje z wcześniejszych etapów procesu. Całościowa analiza pozwoli na zidentyfikowanie większości luk i określenie ich przyczyn.

Poszczególne role zostały przydzielone odpowiedniej liczbie pracowników. Każde z zadań trwa określoną ilość czasu, co wskazuje powyższy diagram w BPMN. Rolę „1” ma dwóch pracowników, Rolę „2” ma 3 pracowników, a Rolę „3” ma 1 pracownik. Proces jest sprawny i efektywny. W określonym czasie jest obsługiwanych N spraw. Każda sprawa musi przejść przez wszystkie kroki, trwające 9 dni.

Co się stanie, gdy jeden z pracowników odejdzie do innej jednostki? Spadnie sprawność procesu, dla pewnej grupy spraw czas realizacji się wydłuży i będą się nawarstwiać. Pojawi się wąskie gardło – będzie zbyt mała liczba osób do realizacji spraw. Jest to wyzwanie dla przedsiębiorstwa – musi przeorganizować pracę, zatrudnić ludzi, poszerzyć/zmodyfikować kwalifikacje. Jeżeli nie wykona tych akcji z odpowiednim wyprzedzeniem naraża się na straty, wzrost kosztów lub inne konsekwencje.

Strzałki wskazują, że:

• proces jest inicjowany na pewnym poziomie struktury organizacyjnej.
• działanie związane z planem jest realizowane na innym jej poziomie.

Równocześnie strzałki pokazują połączenie między dwoma perspektywami procesu – stroną dynamiczną, w ramach której wykonywane są kolejne etapy, przynoszące określone efekty oraz stroną statyczną, czyli strukturą organizacyjną i z nią związanym podziałem zadań. Zadania są podzielone, procesy są inicjowane przez jednych pracowników, a wykonywane przez innych.

Istotnym elementem jest to, że między poszczególnymi etapami procesu następują powiązania i sprzężenia zwrotne. Postęp działania oraz kontrola może powodować nawrót do planowania, zmiany definicji celów, a to powoduje, że zmieniają się kryteria oceny działań. I tym momencie można wskazać, że proces jest inicjowany przez kogoś innego niż początkowo, a to już jest uzależnione od wcześniej wspominanego podziału zadań, a dokładnie tego, kto jest odpowiedzialny za kontrole, kto za zakomunikowanie zmian, a kto za ponowną definicję celów i aktualizację planów. Ta strona statyczna, przejawiająca się podziałem zadań, w pewien sposób powoduje, że proces jest dynamiczny i musi nieustannie reagować na zmiany.

Fakt, za drugim razem, proces zakończył się oczekiwanym efektem – usługa została opłacona i jej czas obowiązywania został przedłużony na następny okres. Jednakże sama realizacja nie odbyła się jak dla mnie w najlepszy możliwy sposób – zarówno ze względu na poświęcony czas, kilkakrotne potwierdzanie czy też wątpliwość czy przypadkiem jakaś płatność nie została jednak wykonana, a jedynie potwierdzenie nie zadziałało, czy też powrót do panelu.

Sformułowanie „oczekiwany efekt” wskazuje na tzw. efektywność procesu, natomiast „najlepszy możliwy sposób” wskazuje na tzw. sprawność procesu. W internecie można znaleźć różróżnienie, dla ułatwienia posłużę się angielskimi definicjami:

• Effective: Adequate to accomplish a purpose; producing the intended or expected result ( =oczekiwany efekt).
• Efficient: Performing or functioning in the best possible manner (=najlepszy możliwy sposób) with the least waste of time and effort.

Definicje idealnie pokazują, że proces efektywny to taki, który generuje właściwe efekty, a proces sprawny, który doprowadza do tych efektów w najlepszy możliwy sposób, biorąc pod uwagę czas, koszt realizacji. W przypadku powyższego procesu należałoby poprawić sposób działania i obsługi wyjątków, aby był realizowany szybciej. Można by, jak w przypadku niektórych sklepów internetowych, zapisywać etapy zrealizowane i umożliwić podjęcie procesu od pewnego kroku, ostatniego zaakceptowanego. Jeżeli chodzi o efektywność procesu to efekt jest prawidłowy. Myślę, że warto najpierw zadbać, aby z punktu widzenia użytkownika, proces przynosił oczekiwany efekt, a następnie poprawiać sprawność procesu, tak, aby efekt końcowy przewyższał oczekiwania użytkownika.

• pierwszym ryzykiem pojawiającym się w trakcie realizacji procesu jest Ryzyko niespełnienia oczekiwań klienta, które istnieje na do zakończenia procesu. Można sobie z nim poradzić przez dyskusję z klientem i poznanie jego potrzeb, ankiety, badania itp.
• po przyjęciu zamówienia, proces jest wspierany przez narzędzia informatyczne, które mogą być niedostępne, nie działać poprawnie lub zbyt wolno. Jest to tzw. Ryzyko operacyjne. Materializacja tego ryzyka może wymagać zainicjowania osobnego procesu, oznaczonego jako „RO” na diagramie.
• na pewnym etapie procesu, pracownik firmy może napotkać wątpliwości w wykorzystaniu systemu wspierającego lub w zakresie działań do wykonania, może źle zinterpretować zapisy procesu bądź podręcznika użytkownika. Podobnie może źle rozpoznać informację pozyskaną od klienta – Ryzyko błędnej interpretacji na diagramie. Istotny jest tu element odpowiedniej komunikacji wewnętrznej.
• jeżeli czas realizacji procesu się wydłuża i może się pojawić zapytanie klienta, co się dzieje z zamówieniem, może być konieczne zainicjowanie dedykowanego procesu – oznaczonego przez „RT”. Takim procesem może być np. proces powiadomienia klienta, a może być wynikiem materializacji Ryzyka terminu.

Załóżmy, że mamy ścieżkę raportowania Pracownik Lokalny->Manager Lokalny->Władze Lokalne->Łącznik -> Władze Globalne. Każdy z nich oznaczony jest innym kolorem na diagramie. Statusy informacji, zgodnie z ich „autorem” są również oznaczone kolorami. Statusy „Do uzupełnienia” oraz „Uzupełnione” są opcjonalne – wystąpią, gdy pojawi się pytanie przy przekazywaniu dalej, które należy wyjaśnić z inicjatorem procesu. Podobnie może wystąpić to na wyższym poziomie raportowania. Ramką na diagramie została zaznaczona komunikacja / przejścia informacji, zachodząca między Managarem Lokalnym a Władzami Lokalnymi, między Władzami Lokalnymi a Łącznikiem i między Łącznikiem a Władzami Globalnymi. Na wyższych poziomach mogą też nie wystąpić niektóre statusy. Każdy z uczestników może zadać nowe pytania i skierować uwagę na kwestie, które wcześniej nie zostały poruszone. Można powiedzieć, że po wykonaniu każdego z przejść entropia informacyjna rośnie? Chyba tak.

Po przeczytaniu artykułu „Business Process Utility – The emerging plug-and-play model in Finance and Accounting Outsourcing”, zacząłem się zastanawiać, czy podobnego spojrzenia na proces nie można wykorzystać przy wprowadzaniu outsourcingu procesu. Dokładniej przy identyfikacji procesu do outsourcingu. Podczas wykorzystania outsourcingu w procesie kluczową rolę odgrywa tzw. Business Process Unit (BPU), jednostka, której zadaniem jest standaryzacja procesu i jego efektywna realizacja. Włączenie takiej jednostki wymaga odpowiedniego przygotowania umowy z jednostką obsługującą proces, w ramach której zostaną zdefiniowane odpowiedzialności, parametry jakości oraz koszt.

Poniższy diagram prezentuje przykładowe przejście na wykorzystanie takiej jednostki:

Korzyści z takiego przejścia w realizacji procesu można określić następująco:

• zastąpienie kosztów własnych, stałym kosztem za realizację procesu;
• jednorodna obsługa spraw przez dedykowaną jednostkę;
• w wielu sytuacjach większa automatyzacja procesu;
• spadek kosztów na utrzymanie infrastruktury potrzebnej do realizacji procesów;
• brak potrzeby inwestowania w rozwój technologii wcześniej wykorzystywanej w procesie;
• łatwiejsza komunikacja o przebiegu procesu;

Wadami wydają się:

• brak pełnej kontroli nad przebiegiem procesu;
• uzależnienie od jednostki zewnętrznej;
• wzrost ryzyka związanego z realizacją procesu;
• utrata stopnia indywidualizacji obsługi klientów/spraw na rzecz standaryzacji;
• możliwość wystąpienia negatywnego odbioru ze strony pracowników, dotychczas uczestniczących w procesie;

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.