Opis problemu w metodyce Global 8D

Opis problemu, w metodyce Global 8D zwykle realizowany w kroku 2, jest jednym z kluczowych etapów w procesie rozwiązywania problemów. Etap ten, przez wielu traktowany jako bardzo prosty i nie wymagający specjalnego zaangażowania („przecież wiemy, w czym jest problem”) często decyduje o sukcesie bądź niepowodzeniu dalszych etapów rozwiązywania problemów – niewłaściwie lub lakonicznie opisany problem jest wielokrotnie powodem niepowodzenia podczas właściwej identyfikacji przyczyny problemu i w efekcie prowadzi do porażki w całości procesu 8D.

Dlatego też dążąc do jak najlepszego opisania problemu należy kierować się poniższymi zasadami:

Potwierdzenie problemu

Zawsze w początkowej fazie opisywania problemu należy potwierdzić, że problem faktycznie występuje. Wielokrotnie stykałem się z sytuacjami, gdy grupa robocza z wielkim zaangażowaniem pracowała nad identyfikacją przyczyny problemu, który w ogóle nie istniał. Dlatego też potwierdzenie istnienia problemu powinno się opierać na zebranych „twardych” i obiektywnych dowodach.

Ograniczone zaufanie

Drugą regułą, którą należy stosować podczas definiowania problemu, jest zasada ograniczonego zaufania wobec otrzymywanych z zewnątrz informacji, gdyż mogą być błędne. Szczególnie ostrożnym należy być w sytuacjach, gdy bazujemy tylko na informacjach przekazanych przez osoby trzecie i nie popartych „twardymi” danymi. Niektóre osoby, pomijając ich często duże zaangażowanie w temat, mają problem z oddzieleniem faktów, (rzeczywistych obserwacji) od tego, co się im wydaje (własnych teorii na dany temat). W rezultacie przedstawiają one fakty wymieszane z przypuszczeniami i teoriami, będąc jednocześnie przekonanym, że prezentują wyłącznie obiektywne obserwacje. Warto więc weryfikować takie wypowiedzi. Najlepszą metodą weryfikacji jest pozyskiwanie obiektywnych danych, które można uzyskać gromadząc:

• Próbki wadliwych wyrobów, materiałów, surowców,
• Wyniki pomiarów i testów,
• Dane z systemów informatycznych (baz danych), itp.

Oczywiście nie wolno zapominać, że czasami i „twarde” dowody bywają błędne. Może się bowiem zdarzyć, że na przykład:

• Pobrane dane z baz danych są niekompletne (lub zdublowane) za pomocą wadliwie skonstruowanego zapytania SQL,
• Pomiary zostały wykonane błędnie,
• Uzyskano fałszywie pozytywne lub fałszywie negatywne wyniki testów , ponieważ stosowana metoda testu bądź pomiaru okazała się niedokładna.

Nie szukaj przyczyny

Na etapie opisu problemu nie należy myśleć o przyczynach problemu oraz o potencjalnych rozwiązaniach. Jeżeli na tym etapie pozwolimy sobie na wyciąganie wniosków, to często okazuje się, że podświadomie staramy się potwierdzać naszą diagnozę i pomijamy (nie dostrzegamy) innych sygnałów, które mogą jej przeczyć.

Właściwie opisz problem

Jednym ze sposobów kompleksowego opisywania problemu jest metoda 5W2H. Jest ona na pozór czasochłonna, lecz pozwala opisać problem z wielu perspektyw, co znakomicie ułatwi późniejsze działania i w rezultacie da korzystny bilans czasowy.

Metoda 5W2H polega na odpowiedzi na siedem pytań. Pięć z nich zaczyna się na literę W a dwa na literę H i stąd też nazwa metody. W praktyce pytań tych może być o wiele więcej, jednak wszystkie da się dopasować do opisanego schematu. Oto kilka wskazówek, jak zadawać szczegółowe pytania w ramach poszczególnych W i H:

WHO

Kto zgłosił problem? Czy to był klient, czy pracownik a może dostawca? Czy problem zgłosił jeden klient czy kilku?

WHAT

Co jest problemem? Opisz dokładnie samo zjawisko. Jeżeli to możliwe, wykonaj zdjęcia problemu lub użyj dokumentacji i rysunków technicznych. Jeżeli problem na zdjęciu nie jest oczywisty i prosty do zauważenia warto dorysować na zdjęciu strzałkę wskazującą problem. O ile to możliwe, bardzo pomocne jest też przedstawienie dwóch zdjęć, prezentujących sytuację prawidłową i nieprawidłową – dzięki temu wizualna identyfikacja problemu staje się znacznie łatwiejsza. W przypadku problemów z wyrobami należy także podać numery seryjne, daty produkcji itp.

WHEN

Kiedy problem się pojawił? Zbierz informacje o tym, kiedy problem został zgłoszony oraz kiedy faktycznie wystąpił (czasami do zgłoszenia dochodzi o wiele później niż problem wystąpił). Upewnij się, czy ten problem nie występował już wcześniej w mniejszej skali i z tego powodu mógł pozostawać niezauważony. Sprawdź, w jakim dniu produkt był wytwarzany, na której zmianie itp. Należy rozgraniczać informacje o tym, kiedy problem zgłoszono, kiedy wystąpił oraz kiedy dany produkt wyprodukowano.

WHERE

Gdzie problem wystąpił? Wskazanie miejsca powinno odnosić się do lokalizacji geograficznej lub miejsca w zakładzie. Może się okazać, że problem występuje tylko w określonej lokalizacji, co czasami ułatwia dalszą analizę.

WHY

Opisz znane wytłumaczenia/przyczyny problemu. Można tu posłużyć się doświadczeniami z wcześniejszych, podobnych problemów, które mogą mieć zastosowanie w naszym przypadku.

HOW

W jakiej sytuacji problem wystąpił? W jaki sposób? Warto tu posłużyć się mapą procesów, aby odwzorować kolejność zjawisk poprzedzających powstanie problemu i ewentualne skutki problemu.

HOW-MANY

Opisz skalę problemu (ilość wystąpień) w mierzalny sposób. Ilości możesz wyrazić w sztukach, % lub PPM (w zależności od branży i ilości danych).

Poniżej zaprezentowano kilka sytuacji, które udało się zidentyfikować dzięki prawidłowemu opisaniu problemu i zastosowaniu metodyki 5W2H:

• Wadliwy wyrób był produkowany 3 miesiące temu. Problem zgłoszono 2 dni temu. Dzięki informacji o dacie produkcji wiemy, że zmiany w procesie wprowadzone 2 miesiące temu nie są przyczyną powstawania wady.
• Wadliwe wyroby są reklamowane przez dwóch klientów. Reklamacje dotyczą dostaw do zakładów klientów w północnej Europie w okresie zimowym. Należy więc przypuszczać, że problem jest związany z niską temperaturą (np. w czasie transportu, składowania wyrobów lub samej konstrukcji wyrobów).

Podsumowując, należy jeszcze raz podkreślić, że dzięki dokładnemu opisaniu problemu możemy na wstępie wyeliminować część teorii nt. przyczyny wady i w kroku 4D skoncentrować się na mniejszej liczbie potencjalnych przyczyn. Dobrze opisany problem jest kluczowym etapem 8D i pozwala grupie roboczej skoncentrować się na mniejszej liczbie potencjalnych przyczyn. Ułatwia też zrozumienie problemu poszczególnym członkom grupy roboczej oraz  jest sygnałem dla klientów, że stosujemy profesjonalne i metodyczne narzędzia rozwiązywania problemów.