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

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.

Reklama

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.

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.

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.