Metodologia 8D – perspektywa zgłaszającego i obsługującego

Ponad rok temu pisałem na swoim blogu: “Otrzymuję 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….”. Jak pisałem na koniec otrzymałem informację, że sprawa została rozwiązana – numer został wykreślony.

Niestety w tym roku, sytuacja się powtórzyła, otrzymałem analogicznego smsa. Oznacza on jedno, że sprawa jednak nie została załatwiona tak jak napisali. Postanowiłem jednak, że skorzystam tym razem z formularza, powołując się na poprzednią sprawę i poproszę o jej rozwiązanie. Formularz wypełniłem 1,5 tygodnia i do dziś nie otrzymałem żadnej odpowiedzi. Z mojej perspektywy, czyli Zgłaszającego, proces rozpoczął się w dniu wysłania formularza i czas leci. Jestem ciekaw kiedy otrzymam informację zwrotną (o ile otrzymam).

smsx2_450px

Patrząc na różne procesy, czas obsługi rozumiany przez Obsługującego nie jest tożsamy z tym jak go ocenia Zgłaszający. Okres od przesłania zgłoszenia do zajęcia się sprawą po stronie Obsługującego może być różny i najlepiej, gdyby był jak najkrótszy. Zostało to zaprezentowane na powyższym diagramie.

Rozbieżności między czasem liczonym z perspektywy Zgłaszającego oraz Obsługującego są silnie uzależnione od wykorzystanego kanału do obsługi sprawy. W momencie kontaktu osobistego skraca się czas od zgłoszenia do zajęcia się sprawą. W momencie kontaktu za pośrednictwem kanałów elektronicznych – zgłoszenie może trafić na jakąś listę, z automatycznie nadawanymi priorytetami, co powoduje, że moment reakcji przesuwa się w czasie.

Patrząc na metodologię 8D, przy wskazanej interakcji, zabrakło zastosowania punktów D5 (“Korekta długoterminowa”) oraz D6 (“Wdrożenie i weryfikacja”). Gdyby zostały w pełni zastosowane, wykreślenie numeru byłoby skuteczne i ta weryfikacja nie została “przeniesiona” na Zgłaszającego.

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.

5why450

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.

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.

Gdy pojawia się problem z produktem

Houston, mamy problem” (ang. Houston we have a problem) to chyba jedno ze sformułowań, które zna każdy. Słyszał je, używał, oglądał film, gdzie ono padło czy nawet zna historię tego sformułowania (choć w rzeczywistości brzmiało trochę inaczej). A może ktoś czytał książkę o takim tytule? Ale nie, spokojnie dzisiaj nie będzie o filmie, książce czy podboju kosmosu, będzie o problemach. Słowo to pada w różnych określeniach… „mam problem”, „chyba mamy problem”, „problem do rozwiązania”, „problematyczne”, „zarządzanie problemami”, „rozwiązywanie problemów” itd.

Czasami mówi się, że lepiej powiedzieć zamiast problemu, że istnieje wyzwanie (podobno lepiej brzmi). Fakt jest taki, że zadziało się coś, czego się nie spodziewaliśmy, co powoduje nieprawidłowe działanie, niedostępność usługi/procesu/produktu, powołanie komitetu sterującego czy konieczność podejmowania szybkich decyzji. Mamy tutaj więc dwie strony „medalu” – identyfikację problemu oraz reakcję na problem.

Z nazwaniem czy identyfikacją problemu, stwierdzeniem faktu jego istnienia przez osobę, która ma z nim do czynienia, nie ma jakiejś wielkiej trudności. Wyzwanie (świadomie używam tego słowa) pojawia się z drugiej strony – w reakcji na znaleziony problem. W zależności od przyczyny problemu czy zależności od tego, co wcześniej wykonała dana osoba, z komunikowaniem problemu szerszemu gronu może być trudniej, a czasami może to powodować strach/przerażenie czy też inną reakcję, może ucieczkę.

Mając w pamięci różne sytuacje, zarówno te, w których byłem odbiorcą komunikatu, czy biernym obserwatorem czy też osobą identyfikującą problem, mogę pokusić się o identyfikację (czyt. nazwanie) kilku podejść do takiej sytuacji (podane nazwy to pierwsze skojarzenia z zachowaniem, moje bardzo subiektywne określenia):

  • śpioch – nie robi nic, niech problem sam się rozwiąże, może ktoś inny go też znajdzie i podejmie kroki; nie musi się martwić i tłumaczyć, sprawdzać itd. W tej sytuacji nie czuje się odpowiedzialny za problem a także jego/jej działania nie przyczyniły się do niego;
  • konspirator – również nie robi nic, a wręcz ukrywa problem. Może ktoś przy okazji znajdzie go w innej sytuacji i powie o nim. Wtedy może udać zdziwienie lub podejść do tego inaczej. Reakcja wynika często z tego, że po pierwsze nie chce podjąć działań, boi się reakcji, oceny ale z drugiej nie chce wziąć odpowiedzialności za swoje działania lub brak działań, które przyczyniły się do pojawienia problemu;
  • ofiara – mówi, że jest problem. Żali się jak do niego mogło dojść, że to przeoczył/a. Niech każdy pomoże, on/a sobie nie poradzi. On/a nic nie potrafi, jak robi takie błędy. Plus jest taki, że problem wychodzi na jaw, ale równocześnie trzeba sobie poradzić z osobą zgłaszającą, która tworzy niezbyt przyjemną atmosferę;
  • współpracownik – mówi, że jest problem, ale stara się do niego podejść racjonalnie. Znaleźć przyczynę, porozmawiać o skutkach, przyznać się do błędu, ale nie robić wokół siebie zamieszania jak w przypadku „ofiary„. Wtedy skupiamy się na faktach i działamy. Nie szuka winnego. Współpracujące zachowanie może się pojawić także wtedy, gdy ktoś nie ma wpływu (jak w przypadku „znalazcy” poniżej), ale chce pomóc bardziej (na przykład sprawdzić po rozwiązaniu, uczestniczyć w testach, dostarczyć szczegółowe dane dotyczące problemu lub nawet zaangażować się w zespół wraz z propozycją rozwiązań). Postawa ta może być także w przypadku powiązania z problemem;
  • bohater – stwierdza, że jest problem i już znalazł jego rozwiązanie. Wskazuje wokół co trzeba zrobić, kogo poinformować, jak działać. Bierze na siebie odpowiedzialność równocześnie stając się liderem tematu od „a” do „z”, nawet przygotowując lessons learned, aby taka sytuacja nie powtórzyła się w przyszłości. Nie szuka winnego;
  • sędzia – wskazuje, że jest problem, równocześnie wskazując co jest przyczyną, najlepiej ze wskazaniem osoby/procesu/tematu, który się do tego przyczynił. Jeżeli problem jest spowodowany przez kogoś innego, to bez skrupułów następuje ocena sytuacji. Jeżeli problem jest spowodowany przez działania danej osoby, wskazywana jest słabość systemu lub procesu, który nie zabezpieczył przed problemem;
  • znalazca – mówi, że jest problem, ale nie ma możliwości zajęcia się nim, nie ma wpływu na system, proces, jednostkę itd. W szczególności ma to miejsce, gdy jest Klientem, użytkownikiem, odbiorcą.

Wyobraźmy sobie, że przez kilka sprintów zespół deweloperski pracował nad produktem, zgodnie z kierunkiem wskazanym przez product ownera. Wszystkie ceremonie przeszły bez problemów. Na planowaniu była pełna gotowość do realizacji zmian, na review prezentowany był pięknie działający produkt z kolejnym przyrostem. Na daily czy retrospektywnie nikt nie zgłaszał problemów czy trudności. Zadecydowano o wdrożeniu, mijają dwa dni i następuje wielkie bum… w jednym z kluczowych procesów produktu, następuje błąd. Trafia zgłoszenie do zespołu w kolejnym sprint, wszystkie prace są wstrzymane w celu jego rozwiązania. Jest problem z produktem. Wiadomo gdzie, w którym miejscu i… Ktoś zgłosił problem, więc zachował się jako „znalazca” a nie „śpioch”. W zespole (oznaczonym jako osoby na kole przerywanym na diagramie powyżej). zaczyna się szukanie przyczyny problemu i w zależności od przyczyny problemu mogą pojawić się różne z wymienionych zachowań – na przykład:

  • sędzia” może powiedzieć, że to przez brak odpowiednich testów, które powinny być wykonane przez osobę X, zespół XYZ (przykład oznaczony na diagramie powyżej na szaro jako osoba poza zespołem);
  • ofiara” może powiedzieć, że to moja część pracy, zacząć płakać na spotkaniu, że przez nią Klienci mogą nas oczernić na forach. Że ja sobie nie poradzę z tą sytuacją (przykład na czerwono oznaczony na diagramie powyżej).
  • bohater” może powiedzieć, że wie jak obejść problem. Na przykład może wskazać, że problem znika, gdy na danym ekranie, użytkownik zapisze dany stan, zrestartuje aplikację i ponownie wejdzie (przykład na zielono oznaczony na diagramie powyżej).
  • konspirator” może powiedzieć, że to nie nasz problem, u nas wszystko działało, mamy potwierdzenia z testów i kto inny powinien się zająć problemem (przykład oznaczony na fioletowo na diagramie powyżej).

Spotkałem się z różnymi reakcjami w takich sytuacjach i moim zdaniem najłatwiej jest, gdy wszyscy są albo „współpracownikami” (przykład na pomarańczowo zaznaczony na diagramie powyżej) albo „bohaterami” bo wtedy najszybciej można rozwiązać problem, nie ma szukania winnych. Jeżeli osoba, która zawiniła przyzna się do błędu i pomoże w identyfikacji miejsca, ułatwi to wszystkim pracę. Gdy ze względu na duch współpracy, zaangażuje się, też to ułatwi wszystkim zadanie.   

Powyższe określenia są moją subiektywną próbą zobrazowania zachowań, które obserwowałem w różnych sytuacjach biznesowych i prywatnych. Pewnie nie pokrywają pełni możliwości, ale moim zdaniem wskazują te, które dość często można zaobserwować. Te, które są bardzo wyraziste.

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.

Analityk_450px
(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.

(Nie)oczekiwany efekt procesu

Po ostatnim tygodniu, mam taką refleksję. Gdy dwie grupy są zaangażowane wspólnie w przygotowanie jakiegoś produktu, a wynik pracy jednej grupy staje się podstawą pracy drugiej, to końcowy efekt jest obarczony ryzykiem, że nie będzie oczekiwany z tym na początku. Dlaczego tak może być?

Wyobraźmy sobie, że dwie jednostki dowolnej firmy przygotowują raport. Pierwsza jednostka przygotowuje wsad, a druga uzupełnia go o resztę informacji – taki proces jest zaprezentowany na poniższym diagramie. Na końcu procesu raport może przyjąć dwa stany: „Oczekiwana prezentacja raportu”, „Niepoprawna prezentacja raportu”. Stany te są skutkiem różnych działań. Oczekiwanym działaniem jest zachowanie formatu danych. Łatwo powiedzieć, ale często trudniej wykonać. Przykładów nie trzeba szukać daleko – zapis dat może być różny – jedni oczekują formatu dd-mm-rrrr, inni rrrr-mm-dd, a często mamy daty jako dd-mm-rr lub rr-mm-dd. Jak dorzucimy do tego jeszcze znaki oddzielające i stosowanie tzw. timestampa, czyli formatu data+godzina to już się robi zamieszanie.

Diagram5p450
Odpowiadając na pytanie „Dlaczego?” można powiedzieć, że:

  • informacja przy przekazaniu raportu była niewystarczająca,
  • nie doprecyzowano założeń i formatu raportu,
  • obydwie jednostki korzystały z różnych narzędzi/konfiguracji,
  • prawdopodobnie zastosowano różne formaty dla tego samego charakteru danych w poszczególnych częściach raportu,
  • druga jednostka niepoprawnie zinterpretowała zawartość przekazanego wsadu,

 

Wystąpienie takich problemów powoduje, że proces się wydłuża, ze względu na konieczność poprawy raportu. Wymają także działań zapobiegających na przyszłość, jeżeli raport ma być przygotowywany cyklicznie. Jest to związane z rodzajami ryzyka w procesie biznesowym i zarządzania nimi, a także z rozwiązywaniem problemów (krótko i długoterminowym).

Równoczesne ścieżki procesu

Uruchamiam w pewien weekend swój komputer i po kilku sekundach widzę komunikat o braku możliwości odczytu dysku. Dobra restartuję go i zastanawiam się co się mogło stać. Próbuję ustalić przyczynę problemu i znaleźć możliwe rozwiązania, zgodnie z metodologią 8D, o której pisałem ponad rok temu. Próbuję komend na poziomie linii poleceń, sprawdzania dysku, uruchomienia trybu awaryjnego, załadowania poprzedniej wersji. Wszystkie działania wykonywałem sekwencyjnie. Ostatecznie skończyło się na instalacji systemu od początku. Mówi się trudno.process_rownoczesny_450

Wrzuciłem płytkę, zmieniłem tymczasowo kolejność źródeł uruchomienia systemu. Wreszcie pojawił się ekran – uruchom system z dysku lub zainstaluj system. Wybrałem to drugie i po kilku ekranach zaczyna się kopiowanie plików. A tu nagle zaskoczenie, mogłem równocześnie konfigurować przyszły system. Ooo…, coś nowego. Zwykle działo się to sekwencyjnie – najpierw kopiowanie potem parametry lub na odwrót. A tu taka oszczędność czasu.

Powyższy przykład można zobrazować diagramem w BPMN przy wykorzystaniu elementów pozwalających na rozdzielenie procesu na dwie równoczesne ścieżki (tzw. parallel gateway). Element początkowy rozdziela ścieżkę a element końcowy łączy. Przejście do dalszej części procesu możliwe jest dopiero po zakończeniu obydwu ścieżek. Gdyby czynności były sekwencyjnie ułożone nie byłoby tego elementu. Przed rozdzieleniem były pewne zadania istotne dla obydwu ścieżek, a potem były zadania będące efektem wszystkich wcześniej zakończonych kroków – uruchomienie systemu po raz pierwszy w wybranej wersji językowej i dla danego użytkownika.

Proces reklamacji

Dzisiaj ponownie skupię się na procesie obsługi zgłoszeń od klienta. Po raz pierwszy z tematem mierzyłem się przy okazji materializacji ryzyka, potem podczas próby przybliżenia metodologii rozwiązywania problemów. W pierwszym wypadku skupiłem się na kliencie wewnętrznym zgłaszającym problem w aplikacji, z której korzysta. Natomiast w drugim, skupiłem się na samym sposobie rozwiązywania problemu. Nie patrzyłem jednak na całość procesu obsługi reklamacji i co najważniejsze nie wspominałem o komunikacji ze zgłaszającym.

Klient zgłaszając problem dotyczący zakupionego sprzętu, wykonanej operacji czy braku możliwości jej wykonania, oczekuje, że:

  1. problem zostanie rozwiązany i w przyszłości już nie wystąpi,
  2. rozwiązanie problemu nastąpi w akceptowalnym czasie i otrzyma informację zwrotną o postępach,

Na przykład w branży finansowej, KNF określa – tzw. zasady reklamacji – jak powinny wyglądać ramy czasowe, obowiązki strony obsługuącej problem, dokładnie instytucji finansowej. Ma to na celu zastosowanie jednorodnego sposobu obsługi klientów przez instytucje rynku finansowego, utrzymanie zaufania do tych instytucji i zachowania przejrzystości funkcjonowania. W szczególności po określonej liczbie dni, klient powinien otrzymać informację o postępach, efekcie działań, a także o dalszych krokach.

reklamacja450a

Na powyższym diagramie w BPMN zaprezentowane są ramowe kroki takiego procesu (przygotowane na podstawie metody 8D), począwszy od przyjęcia zgłoszenia, przez analizę, rozpatrzenie po zapewnienie, że w przyszłości problem już nie wystąpi – poprzez Ustalenie działań na przyszłość i Wdrożenie odpowiednich zmian. Równocześnie zaznaczone zostały ramy czasowe związane z odpowiedzią dla Klienta – Dzień 1 odpowiedzi oraz Dzień 2 odpowiedzi. Czynność Poinformowanie Klienta o postępie może nastapić na różnym etapie analizy problemu. Może już być po zakończeniu analizy i rozpatrzeniu reklamacji. Może nastąpić również w Dniu 1, między Dniem 1 a Dniem 2 lub dopiero w Dniu 2, z zastrzeżeniem, że rzeczywisty otrzymanie pisma przez Klienta powinno nastąpić najpóźniej w danym dniu.