5 Why jest kluczowym elementem problem solving. Właśnie dzięki niej mamy możliwość zdefiniowania rzeczywistej przyczyny źródłowej, a nie symptomu. Jest to o tyle istotne, ponieważ dla symptomu definiowane są działania blokujące w kroku D3 w raporcie 8D.
Jak w takim razie przeprowadzić taką analizę?
Krokiem zerowym jest prawidłowe przeprowadzenie działania dot. diagramu Ishikawy. Jeśli wiemy już czy mamy do czynienia z niewłaściwie przeprowadzoną kontrolą, brakiem jej wykonania lub źle zdefiniowanym parametrami procesu, to przechodzimy do metody 5xWhy.
5 Why – struktura
Rys. 1. Przykład struktury Metody 5 Why
Sama struktura metody jest bardzo prosta, ponieważ polega ona na zadawaniu pięć razy pytań, które z dużym prawdopodobieństwem pozwolą na dojście do przyczyny źródłowej.
W teorii wydaje się to łatwe, natomiast w praktyce już niekoniecznie, ponieważ możemy wpaść na kilka pułapek, które znaczącą utrudnią ich kontynuowanie:
5 Why vs. 5 winnych
Przeprowadzając jakiekolwiek spotkania w zespole, musimy mieć świadomość jak ważne są relacje w nim panujące. Wielokrotnie miałem okazję obserwować (nawet jako przedstawiciel klienta), gdy podczas spotkania z poziomu treści rozmowa przenosiła się na poziom emocji. Jest to określenie, podczas którego rozmówcy nie skupiają się na fizycznym rozwiązaniu problemu, tylko na wypominaniu kto czego nie zrobił i do czego to doprowadziło.
Praca zespołowa, a nie „one man hero”
W trakcie definiowania 5 Why bardzo ważna jest praca grupowa. Tylko efekt synergii i modyfikowania idei przedstawianych przez innych uczestników daje szersze spojrzenie na problem. Możemy wtedy spojrzeć na niego z innej perspektywy poprzez działania operacyjne przeprowadzane we własnym obszarze. Jedna osoba nie jest w stanie tego uzyskać.
Jakość zespołu, czyli kogo dotyczy problem?
Kontynuując temat pracy zespołowej należy pamiętać, że w odróżnieniu do definiowania Ishikawy (przy której mogą uczestniczyć także osoby spoza obszaru produkcyjnego), 5 Why wymaga osoby znającej proces produkcyjny oraz zagadnienia techniczne. Ta wiedza pojawia się najczęściej od Why numer 3, w którym najczęściej następuje przejście ze sformułowań ogólnych do obszaru technicznego.
Dodatkowo w zespole powinny znajdować się wszystkie osoby, których problem dotyczy, a nie tylko osoba, która go zgłasza. Najczęściej jest to osoba z jakości zgłaszająca reklamacje od klienta albo problemy wewnętrzne, która następnie organizuje zespół.
Obiektywizm, czyli „u nas to nie wystąpiło”
Zachowanie obiektywności i wyjście poza strefę komfortu to bardzo dobra cecha uczestnika biorącego udział. Pozwala nam spojrzeć na nasz proces krytycznie, bez zrzucania odpowiedzialności na inne działy. Sam miałem okazję się o tym przekonać, gdy za wygięty wspornik metalowy winę zrzuciłem na podkomponent.
Jak się później okazało taki problem mógł wystąpić podczas nieprawidłowego bazowania wspornika przez operatora. Oczywiście nie była to jego wina, ponieważ takie możliwości dawał za[projektowany proces produkcyjny.
5 Why – przykład
Poniżej znajduje się przykład metody 5xWhy, która pomoże zrozumieć dokładnie mechanizmy pomiędzy poszczególnymi pytaniami.
Problem: brak możliwości montażu osłony zegarów do deski rozdzielczej
Why (1):
Ponieważ osłona zegarów deski rozdzielczej posiada niezgodne wymiary (jest za krótka).
Why (2) jest za krótka?:
Ponieważ zostały zmienione parametry chłodzenia komponentu podczas procesu wtrysku.
Why (3) parametry chłodzenia komponentu zostały zmienione?
Ponieważ parametry procesu produkcyjnego nie zostały zabezpieczone hasłem.
Why (4) parametry nie zostały zabezpieczone hasłem?
Ponieważ po przeprowadzonych testach dla produkcji innego wyrobu w fazie uruchomieniowej, inżynier procesu zapomniał o aktywowaniu hasła.
Why (5) Dlaczego inżynier procesu zapomniał o aktywowaniu hasła?
Ponieważ oprogramowanie produkcyjne nie wymusza takiej czynności podczas zmiany parametrów z cyklu testowego na cykl produkcyjny.
W powyższym wypadku widzimy, że działaniem, które można wprowadzić jest modyfikacja oprogramowania, w taki sposób, aby przechodząc między parametrami testowymi i produkcyjnymi od razu były one niedostępne do modyfikacji przez pracowników produkcji.
Innym działaniem jakie można w taki wypadku wdrożyć w sposób systemowy jest modyfikacja formularza do przeprowadzania testów produkcyjnych dodając pytania:
– Czy po zakończeniu testów parametry zostały zmienione z testowych na procesowe?
– Czy zostało aktywowane hasło dostępne tylko dla inżyniera procesu dla parametrów procesowych?
Na stronie „Bezpłatne narzędzia” można bezpłatnie pobrać automatyczny formularz Excel z możliwością edycji.
Nazwa dokumentu: 5xWhy – formularz Excel
Dariusz Kowalczyk
