Wiesz już jak podejść do tematyki Problem Solving. Wiesz już do czego służy diagram Ishikawy oraz jak wykorzystać diagram rybiej ości do zidentyfikowania obszarów występowania potencjalnych przyczyn powstawania problemów. Dzisiaj natomiast przyglądniemy się jak dobrze zrozumieć sam problem. Aby tego dokonać będziesz potrzebował jednego bardzo prostego narzędzia jakim jest 5W2H.

Czym 5W2H jest? Co kryje się za tym akronimem? Jak korzystać ze wspomnianego narzędzia?

Odpowiedzi na te pytania znajdziesz w poniższym wpisie.

5W2H – co to jest?

5W2H to narzędzie do definiowania problemu podczas prowadzenia analizy zgodnie z metodologią Problem Solving. Narzędzie to wykorzystywane będzie więc na samym początku jakiejkolwiek analizy problemu lub też po prostu w celu zrozumienia, czy to co może wydawać się problemem na pierwszy rzut oka, tym problemem faktycznie jest.

Jeśli nie miałeś okazji zaglądnąć wcześniej na jeden z moich wcześniejszych wpisów poświęconych metodologii Problem Solving, przedstawiam poniżej grafikę przypominając tym samym na jakim etapie 5W2H jest stosowane.

Ale czym tak właściwie narzędzie to jest i jak je stosować?

5W2H to nic innego jak 7 podstawowych i prostych pytań stanowiących klucz i wyznaczających drogę do istoty problemu. 5W2H, które często mylone jest z narzędziem jakim jest 5Why, odgrywa jednak inną rolę.

Co więc wchodzi w skład 5W2H?

• What is a problem? – co jest problemem? Odpowiedzią na to pytanie będzie klarowna informacja, która jednocześnie będzie dawała pierwszą informację na temat tego z czym przychodzi nam się mierzyć. W tym przypadku istotne jest to by “nazwać” problem w sposób, krótki ale jednocześnie bardzo dokładny.
  
  Ważnym więc będzie by odpowiadając na to pytanie dać jasno do zrozumienia co tak na prawdę jest problemem. Tak jak wspominałem przy okazji wpisu poświęconemu diagramowi Ishikawa, odpowiadając na pytanie co jest problemem, przekazać odpowiedź w postaci “Pęknięte komponenty X na linii Y” zamiast określać ogólnikowo “Uszkodzone komponenty”.
  
  Im dokładniej odpowiemy sobie na to pytanie, tym łatwiej będzie nam odpowiedzieć na kolejne pytania oraz tym łatwiej będzie zrozumieć jego istotę podczas dalszej analizy.
  
  
• Why? – dlaczego jest to problem? Dzięki odpowiedziom na to pytanie, w łatwy sposób łatwo będzie zrozumieć czy jest to faktycznie problem.
  
  Wyobraźmy sobie sytuację, w której problemem jest uszkodzenie – zarysowanie – powierzchni elementu estetycznego. Z punktu widzenia klienta, użytkownika wyrobu, uszkodzenie takie nie będzie miało większego wpływu na funkcjonalność danego komponentu, ale z punktu widzenia estetyki będzie to b100ez wątpienia drażniące dla klienta, w szczególności, gdy uszkodzony element będzie w zasięgu wzroku użytkownika końcowego.
  
  Ale czy tego samego typu uszkodzenie będzie miało większe znaczenie w przypadku gdy, zarysowana powierzchnia będzie ukryta? Gdy będzie zasłonięta przez inny komponent? Jeśli nie będzie znajdowała się w bezpośrednim zasięgu wzroku? Czy wówczas klient będzie miał zastrzeżenia dla takiego wyrobu? Z odpowiedzią na te pytania z pewnością przyjdą zarówno oczekiwania klienta, definiowane na podstawie oceny satysfakcji jak również na podstawie specyfikacji zdefiniowanej przez klienta (CTQ’s) jak również ocena ryzyka dla naszego wyrobu czy procesu, które pozwolą określić jak duże znaczenie dany problem ma.
  
  Bazując na tych kwestiach warto się zastanowić, czy dany problem jest faktycznie problemem i czy jest potrzeba inwestować czas w dalszą analizę.
  
  
• Where? – gdzie został spowodowany? Odpowiedź na to pytanie, pomoże jednocześnie zdefiniować nam wszystkie obszary, które kroki procesu, są potencjalnym miejscem powstawania problemu. Od tego momentu rozpoczyna się tak na dobre praca z wykorzystaniem diagramu Ishikawy.
  
  W ten sposób zminimalizujesz czas potrzebny na znalezienie miejsca, w którym problem jest kreowany, a ostatecznie, będziesz w stanie we właściwy sposób zdefiniować działania korygujące i zapobiegawcze na przyszłość.
  
  
• When? – kiedy został spowodowany? / kiedy został wykryty? – jest to o tyle istotne by na podstawie danych procesowych określić jak duża część produktów czy komponentów może być narażona na obecność tego samego problemu. Dzięki odpowiedziom na te pytania, będziesz w stanie skupić się na kontroli określonej grupy produktów bez potrzeby kontrolowania 100% posiadanego stanu magazynowego.
  
  Informacja ta będzie również istotna z punktu widzenia potencjalnego ryzyka dla innych wyrobów, produkowanych w określonych ramach czasowych oraz skali potencjalnie niezgodnych produktów, które mogły zostać zainfekowane tym samym błędem.
  
  
• Who? – kto spowodował? / kto wykrył? Tak samo jak w przypadku gdzie, tak i kto spowodował powstanie problemu będzie dla nas istotną informacją. Nie po to by kogokolwiek obwiniać czy nawet karać, ale po to by lepiej zrozumieć co poszło nie tak, że operator / maszyna / narzędzie spowodowało powstanie problemu.
  
  Dzięki rozmowie z danym pracownikiem, łatwiej będzie można sprawdzić, czy potencjalną przyczyną generującą problem jest niewłaściwe przeszkolenie pracownika, niewłaściwie dobrane narzędzia pracy, niejasne standardy pracy czy wreszcie niewłaściwie skonstruowane / przygotowane miejsce pracy. W ten sposób będziesz w stanie zdefiniować również potencjalne rozwiązanie problemu w późniejszym etapie analizy problemu, a co najważniejsze dopasujesz właściwe rozwiązania.
  
  Kto wykrył / znalazł problem? Odpowiedź na to pytanie, da nam jasną odpowiedź na to, czy problem został wykryty na kolejnych etapach procesu, wliczając w to również kontrolę końcową. To pozwoli nam ustalić czy nasz problem jest zabezpieczony w sposób odpowiedni by wyroby niezgodne nie trafiły do naszych klientów.
  
  Jeśli jednak okaże się, że problem został wykryty przez klienta, co skutkuje reklamacją bądź zgłoszeniem problemu przez klienta, wówczas otrzymasz jasną informację, że jednym z następnych kroków jakie będziesz musiał wykonać, to odpowiednie zabezpieczenie klienta przed dostarczaniem kolejnych wyrobów niezgodnych. Dzięki temu będziesz wiedział czy i jakie działania natychmiastowe są wymagane do wdrożenia, zanim dalsza analiza problemu będzie kontynuowana.
  
  
• How? – jak został wykryty? To nic innego jak uzupełnienie poprzedniego pytania “kto wykrył?”. W tym przypadku uzyskamy odpowiedź czy wdrożone narzędzia kontroli w procesie są wystarczająco odpowiednie do tego by wadliwe wyroby nie “uciekły” do klienta. Czy sposób kontroli i nadzoru procesu wymaga jeszcze dodatkowego wzmocnienia poprzez wdrożenie odpowiednich działań natychmiastowych, a w konsekwencji działań korygujących i zapobiegawczy.
  
  
• How many? – Ile? czyli dokładna liczba wadliwych wyrobów. Dane te dają nam odpowiedź z jaką skalą problemu mamy do czynienia. Czy było to jednostkowe zdarzenie czy jednak większa część produkcji została zainfekowana.
  
  W przypadku jednostkowego zdarzenia, musimy przeanalizować jakie jest ryzyko, że problem pojawi się ponownie oraz wpływ na funkcjonowanie procesu w przyszłości.

5W2H – konkluzja

Warto pamiętać jak ważne jest właściwe rozpoznanie problemu już w początkowej fazie jego rozwiązywania. Czy jest to mniej ważne niż analiza przyczyn? Czy warto skupiać się na problemie? Osobiście uważam, że tak. Każdy z etapów metodologii Problem Solving jest tak samo istotny, a im lepiej poznamy “wroga”, z którym mamy do czynienia, tym łatwiej będzie nam w kolejnych krokach rozpoznać przyczyny samego problemu jak i określić działania korygujące i zapobiegawcze.

5W2H to proste narzędzie nie wymagające szczególnych umiejętności czy wiedzy. Jest to narzędzie pozwalające przy użyciu bardzo prostych pytań, zgromadzić bardzo pomocne dane do dalszej analizy.

Warto więc poświęcić trochę czasu, wejść do Gemby i za pomocą prostego narzędzia 5W2H tylko po to by nie marnować czasu i zasobów na dalsze kroki analizy.