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.

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.