Rozwiązywanie problemów metodą 8D

Reklamacja w sieci kablowej, sklepie? Zakupiony sprzęt nie działa? Nie można wykorzystać funkcjonalności serwisu internetowego? Zablokowane konto? Aplikacja zachowuje się w niespodziewany sposób? W życiu prywatnym, czy w pracy, natrafiamy na różnego rodzaju problemy. Każda ze stron, zgłaszający, jak i obsługujący, radzą sobie z tym w odpowiedni sposób, mniej lub bardziej uporządkowany. Niektóre firmy mają proceduralnie ustalony sposób postępowania, a inne się dopiero uczą tego odpowiedniego, reagując na każde zgłoszenie indywidualnie. Jednym ze sposobów rozwiązywania problemów jest metoda 8D.

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.

„Świąteczne” procesy – inna perspektywa

Dziś będzie trochę nietypowo. Co dopiero minął świąteczny czas – przygotowania, świętowanie, odpoczynek itd. W czasie tego czasu, wielokrotnie były przygotowywane listy – zakupów, składników, potraw do wykonania, gości, prezentów, czy postanowień noworocznych. W szczególności przygotowywane były ciasta – sprawdzony przepis, lista składników, pieczenie. Prawie każdy wypiek można sprowadzić do takich czynności jak: przygotowanie składników, przygotowanie ciasta, przygotowanie nadzienia, dodanie nadzienia (czy to bakalii do keksa czy maku do makowca), pieczenie, chłodzenie, dekorowanie (np. lukrem) oraz jedzenie.

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.

Rózwój procesu jako likwidacja jego luk

W literaturze można się spotkać z przyczynowym podejściem do rozwoju przedsiębiorstwa, które skupia się na identyfikacji i rozwoju luk. Mogą to być takie luki jak na przykład:

• 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.

Ryzyko „wąskich gardeł” w procesie

W poprzednim wpisie, wskazywałem na powiązanie procesu i struktury organizacyjnej w danym przedsiębiorstwie. Chciałbym jeszcze nawiązać do tego tematu. Załóżmy, że mamy proces biznesowy odbywający się w danej jednostce. Proces wykonywany jest przez 3 role, z których każda ma przydzielone określone zadania i jest powiązana z odpowiednim stanowiskiem organizacyjnym. Dodatkowo są to zadania specjalistyczne.

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.

Dwa oblicza procesu zarządzania

W literaturze najczęściej spotykanym przedstawieniem procesu zarządzania jest podział na 4 etapy: „planowanie, organizowanie, kierowanie oraz kontrola” (podział z książki J.A.F. Stonera „Kierowanie”). Można powiedzieć, że dwa pierwsze etapy odpowiadają na pytania: „Co chcemy zrobić?” oraz „Jak chcemy zrobić?” Potem następuje działanie kierowane przez odpowiednich członków organizacji. Zaplanowane zadania są wykonywane przez ludzi na odpowiednich stanowiskach. Na koniec szukamy odpowiedzi na pytanie „Co i jak zrobiliśmy?”, czyli następuje kontrola, a dokładnie porównanie efektów działań z planem. Ideę tej zależności prezentuje poniższy diagram.

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.

Od sprawności do efektywności procesu

Ostatnio płaciłem za usługę za pomocą mechanizmu płatności elektronicznych, inicjowanych z poziomu panelu administracyjnego, jednego z dostawców usług (nazwijmy internetowych). Wybrałem usługę do opłacenia, wskazałem rodzaj pakietu, wybrałem sposób płatności, kilka razy potwierdziłem, a na koniec otrzymałem komunikat „Niestety nie udało się. Spróbuj jeszcze raz”. Pomyślałem, będą musiał powtórzyć ostatni krok. Niestety okazało się, że całość. Czy było to efektywne? Czy można powiedzieć, że proces jest sprawny? Proces w uproszczeniu został zaprezentowany na poniższym diagramie (w BPMN).

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.

Ryzyka w procesie biznesowym

Załóżmy, że otrzymaliśmy zamówienie klienta i jako firma/dostawca próbujemy je zrealizować. W czasie procesu, którego efektem będzie realizacja zamówienia klienta, można powiedzieć, że rośnie jego poziom ryzyka. Spróbuję rozłożyć ryzyko na osi czasu odpowiadającej czasowi realizacji procesu. Poniższy diagram prezentuje, że w trakcie realizacji można zidentyfikować kolejne ryzyka, dla których należy przygotować odpowiednią strategię postępowania – zgodnie z procesem zarządzania ryzykiem.
W szczególnych przypadkach pewne zdarzenia mogą spowodować, że konieczna jest realizacja dedykowanego procesu – o czym więcej we wcześniejszym wpisie o materializacji ryzyka.Diagram prezentuje tylko przykładowe ryzyka występujące w procesie biznesowym. Można zauważyć, że:

• 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.

Proces raportowania a entropia informacyjna

Po obejrzeniu filmu Lot 93, zacząłem się zastanawiać nad tym, że w przypadku zdarzeń wyjątkowych/obserwacji istotne znaczenie ma właściwa komunikacja i proces przekazywania informacji o tym. Każda kolejna osoba, która otrzymuje tę informacje, dopytuje, potwierdza, chce dowiedzieć się więcej. Czy to oznacza, że entropia informacyjna danej organizacji (np. Centrum Obsługi Lotów bądź innej jednostki) rośnie? Moim zdaniem tak. Zgodnie z interpretacjami dotyczącymi entropii, to mówimy przede wszystkim o komunikacji bieżącej, poszukiwaniu informacji (odpowiedzi) a nie samym korzystaniu z zapisanych źródeł informacji. Na fakt występowania entropii informacyjnej w organizacji zwrócił mi uwagę jeden z czytelników bloga pod wpisem „Komunikacja jako efekt procesu”. Taka informacja, przekazywana i analizowana, jest wejściem do procesu i z punktu widzenia poszczególnych jej „uczestników posiada pewien status„. Zastanówmy się jak mógłby wyglądać proces raportowania takiej informacji.

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.

Czy stała opłata w outsourcingu jest decydująca?

We wpisie „Trochę inna analiza procesu”  próbowałem pokazać różne mierniki pozwalające na ocenę procesu, zarówno pod względem czasu realizacji, jak i ilości obsłużonych spraw. Podczas analizy procesu nie należy zapominać o koszcie procesu. Wyniki takiej analizy można wykorzystać w trakcie projektowania zmian w procesie zmierzających do poprawy jego efektywności.

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;

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.