Metoda 5xwhy a metoda 8D

Kiedyś opiekowałem się jednym z serwisów internetowych ze strony firmy ją obsługującej po wdrożeniu. Serwis był umieszczony na serwerach jednej z firm hostingowych. W godzinach szczytu wykorzystania serwisu występowały sytuacje, gdy serwer był niedostępny. W takim momencie wykonywałem telefon do administratorów z prośbą o pomoc. Po chwili, dłuższej lub krótszej wszystko wracało do normy. Trudno było określić przyczyny, więc po jakimś czasie firma hostingowa została zmieniona.

Administrator serwera znajdował rozwiązanie krótkoterminowe, które wykorzystywał wielokrotnie. Chcąc uniknąć takiej sytuacji w przyszłości, mógłby przeprowadzić analizę, zmierzającą do znalezienia rzeczywistej przyczny. O powyższej sytuacji przypomniał mi artykuł na stronie Startup Lessons Learned dotyczący metody 5-ciu dlaczego (Five Whys).

Znalezienie przyczyny problemów mogłoby przebiegać jak w poniższym przykładzie zaczerpniętym ze wskazanej powyżej strony (po przetłumaczeniu):

1. Dlaczego serwis internetowy padł?
   Odp.: Użycie wszystkich procesorów obsługujących serwis doszło do 100%.
2. Dlaczego użycie procesora podskoczyło?
   Odp.: Nowy kawałek kodu posiadał pętlę nieskończoną.
3. Dlaczego nowy kod został źle napisany?
   Pracownik X popełnił błąd.
4. Dlaczego jego pomyłka została dołączona do kodów?
   Nie napisał testu jednostkowego dla nowej funkcjonalności.
5. Dlaczego nie napisał testu jednostkowego?
   Jest nowym pracownikiem I nie został właściwie przeszkolony w wykorzystaniu TDD (ang. Test Driven Development).

Dochodzenia za pomocą tej metody do sedna sprawy, do rzeczywistej przyczyny, może odbywać się w kroku Analizy problemu przed przygotowaniem Korekty długoterminowej  – kroków wskazanych przy omawianiu metody rozwiązywania problemów 8D. Pozwala to uniknięcie powtórzenia takiej sytuacji w przyszłości.

Reklama

Proces współpracy – obsługa reklamacji

Kolejny raz odwołam się do własnych doświadczeń. Otrzymałem sms o treści: „Przypominamy, że do DD.MM.RRRRr. należy opłacić składkę za ubezpieczenie. Nr Polisy, Kwota i Numer rachunku”. Nadawcą jeden z ubezpieczycieli. Czytam sms i jestem coraz bardziej zaskoczony – nie mam ubezpieczenia u tego ubezpieczyciela. Numer rachunku ani polisy nic mi nie mówi. Oznacza to jedno, ktoś nie otrzymał powiadomienia o składce, a trafiło do niewłaściwej osoby.

Postanowiłem, że temat wyjaśnię – zgłoszę jakby reklamację. Zacząłem od formularza Kontaktowego na stronie – inne opinie/reklamacje. Wypełniam formularz – dane sprawy, numer polisy, o co chodzi – na razie wszystko z sms, potem imię i nazwisko (myślę ok), a potem PESEL, e-mail i zacząłem przeglądać formularz do końca. Zatrzymałem się na oświadczeniach i zdałem sobie sprawę, że nie chcę podawać tych danych. Pomyślałem, że może jest inny sposób.

(szczegóły po powiększeniu)

Przeszukałem stronę i znalazłem inny sposób na wyjaśnienie sprawy. Spytałem profilaktycznie czy to dobre miejsce i zapytałem w jaki sposób mogę rozwiązać kwestię. „Druga” strona poprosiła o minimum danych: numer polisy, numer telefonu i imię oraz nazwisko. Takie minimum danych mogłem podać. Po chwili przypuszczenia się potwierdziły – osoba ubezpieczona podała błędny numer lub przepisując do systemu zrobiony został błąd. Zgłosiła do poprawy i wskazała, że w ciągu 2 dni roboczych powinni usunąć numer. Od „drugiej” strony mogło to być tylko jednorazowe działanie a może też przyczynić się do zmian, zmierzających do uniknięcia takich sytuacji w przyszłości (zgodnie z metodologią 8D).

Obsługa tego procesu wyglądała jak na powyższym diagramie – szybko, prosto i bez podawania nadmiarowych danych. Jest to przykład tzw. procesu współpracy (ang. collaboration process), który wielokrotnie wykorzystywałem do prezentacji procesów. Doceniam takie proste rozwiązania. Powinna być szybka ścieżka obsługi takich zgłoszeń we wcześniej wspomnianym formularzu. Liczę, że planowane wykreślenie rzeczywiście nastąpi. Ciekawe czy otrzymam powiadomienie o zakończeniu sprawy.

Właściciel procesu – kto to taki?

Wyobraźmy sobie sytuację, że jesteśmy uczestnikiem procesu biznesowego, odbieramy wkład z wcześniejszych kroków, przetwarzamy go, rejestrujemy, weryfikujemy, a następnie przekazujemy dalej. Wiemy jaka jest wizja procesu, jaką wartość i komu proces przynosi. Pewnego dnia zdajemy sobie sprawę, że pewne kroki można zmienić i usprawnić przebieg procesu. Zgłaszając się z tym pomysłem do przełożonego lub innej okazji, może się okazać, że trzeba skontaktować się z właścicielem procesu. Bez jego zgody i zaangażowania proces nie ulegnie zmianie.

Kto to jest ten właściciel procesu?
Według słownika biznesowego, właściciel procesu (ang. process owner) to “osoba, która jest odpowiedzialna za wydajność procesu (ang. performance) podczas realizacji jego celów (ang. objectives), mierzonych przez wskaźniki oceny procesu (tzw. KPI). Osoba ta jest uprawniona do wykonania niezbędnych zmian”. Można powiedzieć, że zarządza procesem. W szczególności (streszczając wskazania z „Process Roles ‚Who are the Process Owners?'”):

• definiuje jak ma przebiegać proces,
• określa jaki ma przynieść efekt,
• monitoruje i raportuje efektywność procesu,
• ustala zmiany w procesie w porozumieniu z właścicielami innych powiązanych procesów,
• odpowiada za zgodność procesu z oczekiwaniami biznesowymi,
• sposnoruje rozwój procesu, przy przechodzi między kolejnymi pozomami dojrzałości procesu,

W ramach jednego z artykułów na ModernAnalyst.com, autorzy zastanawiali się nad tym, jak ważne jest właścicielstwo procesu biznesowego („The Importance of Business Process Ownership”). Artykuł wskazuje jakie są obowiązki właściciela procesu, za co odpowiada I z czym wiąże się ta rola. Porusza także ciekawy temat, że nie każdy chce być właścicielem danego procesu.

Procesy najbardziej atrakcyjne szybko znajdują właścicieli. Procesy trudne, ryzykowne wymagają poszukiwań właściciela procesu. Artykuł wskazuje, że jest to wynikiem różnych elementów – od charakteru procesu po umiejętności danego potencjalnego właściciela kończąc. Biorąc pod uwagę zakres obowiązków, nie jest to łatwe zadanie. Na podstawie artykułu i własnych przemyśleń spróbowałem spojrzeć na te “chęci” w sposób przedstawiony na powyższym diagramie.

Powyższą macierz można byłoby rozwinąć, wskazując na zmianę od słabego procesu do atrakcyjnego, czyli poprzez wzrost wartości dla właściciela. Podobnie przesunięcia w górę i w lewo macierzy można byłoby dodać, ale następuje to jakby przez odwrotność zaznaczonych działań/obserwacji. Zaprezentowane podejście wynika z tego, że atrakcyjny proces zyska potencjalnego właściciela, a spadek jego “cech” powoduje, że trudniej jest go znaleźć (patrząc od strony organizacji).