Posts Tagged ‘rozwiązywanie problemów’

h1

(Nie)oczekiwany efekt procesu

Maj 17, 2014

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

Reklamy
h1

Proces reklamacji

Grudzień 8, 2012

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.

h1

Rozwiązywanie problemów metodą 8D

Styczeń 19, 2012

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.