Produkcja • 5 Why • Root Cause Analysis • Continuous Improvement
5 Why w produkcji – jak znaleźć przyczynę źródłową problemu?
Maszyna znowu stanęła. Operator popełnił błąd. Materiał nie dotarł na czas. Pierwsza odpowiedź często brzmi przekonująco, ale nie zawsze wyjaśnia, dlaczego problem w ogóle mógł się wydarzyć.
Metoda 5 Why pomaga przejść od widocznego objawu do głębszej przyczyny poprzez kolejne pytania „dlaczego?”. Jest prosta, ale tylko wtedy daje wartość, gdy odpowiedzi opierają się na faktach, obserwacji procesu i danych – a nie na przypuszczeniach.
5 Why to metoda analizy przyczyn źródłowych polegająca na wielokrotnym zadawaniu pytania „dlaczego?”, aby przejść od objawu problemu do mechanizmu, który go powoduje. Liczba pięć jest umowna – czasami wystarczą trzy pytania, a czasami potrzeba sześciu lub siedmiu. Najważniejsze jest dotarcie do przyczyny, na którą organizacja może rzeczywiście wpłynąć.
5 Why nie polega na wymyślaniu pięciu odpowiedzi. Każde kolejne „dlaczego?” powinno wynikać z poprzedniego faktu i – jeśli to możliwe – być potwierdzone obserwacją, danymi albo dowodem z procesu.
Co to jest metoda 5 Why?
5 Why, czyli „5 razy dlaczego”, to prosta metoda analizy przyczyn problemu. Zaczynamy od obserwowanego zdarzenia lub niepożądanego wyniku, a następnie pytamy, dlaczego do niego doszło. Odpowiedź staje się podstawą kolejnego pytania.
Celem nie jest samo stworzenie łańcucha pytań. Chodzi o przesunięcie uwagi z objawu na warunki, procesy lub mechanizmy, które pozwoliły problemowi powstać.
Logika 5 Why
Metoda jest popularna w produkcji, Lean, Kaizen, utrzymaniu ruchu, jakości oraz projektach Six Sigma i DMAIC, ponieważ pozwala stosunkowo szybko uporządkować analizę prostszych problemów.
„Maszyna się zatrzymała”
Opisuje to, co zobaczyliśmy, ale nie mówi jeszcze, dlaczego zdarzenie wystąpiło.
„Dlaczego maszyna się zatrzymała?”
Pytanie rozpoczyna analizę mechanizmu prowadzącego do problemu.
Po to, aby nie kończyć analizy na pierwszym logicznym wyjaśnieniu. Pierwsza odpowiedź bardzo często opisuje bezpośrednią przyczynę zdarzenia, ale niekoniecznie wyjaśnia, dlaczego system lub proces dopuścił do jej wystąpienia.
Co oznacza przyczyna źródłowa problemu?
Przyczyna źródłowa to taki czynnik lub mechanizm, którego usunięcie albo ograniczenie zmniejsza prawdopodobieństwo ponownego wystąpienia problemu.
Nie zawsze jest to jedna pojedyncza rzecz. W realnym procesie produkcyjnym problem może wynikać z kombinacji kilku warunków: sposobu pracy, stanu maszyny, informacji, materiału, odpowiedzialności lub parametrów procesu.
Co wydarzyło się tuż przed problemem?
Przykład: czujnik nie zadziałał, materiał był niewłaściwy, operator wybrał zły parametr.
Dlaczego proces dopuścił do takiego zdarzenia?
Przykład: brak kontroli stanu czujnika, niejednoznaczny standard ustawienia parametru albo brak mechanizmu wykrycia niewłaściwego materiału.
Jeżeli człowiek wykonał niewłaściwą czynność, warto zapytać dalej: dlaczego była możliwa? Czy standard był jednoznaczny? Czy informacja była dostępna? Czy system umożliwiał pomyłkę? Czy pracownik miał odpowiednie przygotowanie?
To przesuwa analizę z szukania winnego w stronę poprawy procesu – co jest znacznie bardziej użyteczne w optymalizacji procesów produkcyjnych.
Jak działa analiza 5 Why?
Analizę rozpoczynamy od możliwie precyzyjnego opisu problemu. Następnie pytamy, dlaczego doszło do tego konkretnego zdarzenia.
Każda kolejna odpowiedź powinna być logicznym następstwem poprzedniej.
Nie należy na siłę dopasowywać analizy do dokładnie pięciu pytań. Jeżeli po trzech pytaniach przyczyna jest potwierdzona i można podjąć skuteczne działanie, kolejne pytania mogą niczego nie wnosić. Jeśli po pięciu nadal opisujemy tylko objawy, trzeba analizować dalej.
Jak przeprowadzić analizę 5 Why krok po kroku?
Sama technika zadawania kolejnych pytań jest prosta. Jakość wyniku zależy jednak od tego, jak przygotujemy problem i jak weryfikujemy odpowiedzi.
Co dokładnie wydarzyło się w procesie? Unikaj ocen i interpretacji.
Gdzie, kiedy i dla jakiego produktu, maszyny lub zmiany wystąpił problem?
W analizie powinny uczestniczyć osoby znające rzeczywisty przebieg procesu.
Krok 1. Zdefiniuj problem bez wpisywania przyczyny do jego opisu
Zdanie:
nie jest dobrym punktem startowym, ponieważ zawiera już założenie dotyczące przyczyny.
Lepszy opis brzmi:
Dopiero teraz pytamy, dlaczego zatrzymanie wystąpiło.
Krok 2. Odpowiadaj na podstawie tego, co wiadomo
Jeżeli zespół nie zna odpowiedzi, nie powinien jej wymyślać. To sygnał, że trzeba sprawdzić historię zdarzeń, parametr maszyny, instrukcję, zapis systemowy lub porozmawiać z osobą uczestniczącą w procesie.
Krok 3. Każde kolejne pytanie kieruj do poprzedniej odpowiedzi
Łańcuch musi mieć logiczną ciągłość. Jeśli odpowiedzi zaczynają dotyczyć niezależnych problemów, analiza rozgałęzia się i warto potraktować je jako osobne hipotezy.
Krok 4. Zatrzymaj się przy przyczynie, na którą można sensownie zareagować
Dobra analiza prowadzi do przyczyny, która daje możliwość zaprojektowania konkretnego działania – zmiany standardu, kontroli, procesu, ustawienia, informacji, odpowiedzialności lub zabezpieczenia.
Krok 5. Sprawdź zależność wstecz
Po zakończeniu łańcucha warto przeczytać go od końca:
Test logiczny
Jeśli taki łańcuch nie jest logiczny, prawdopodobnie jedna z odpowiedzi została przyjęta zbyt szybko.
5 Why – przykład zastosowania w produkcji
Załóżmy, że linia produkcyjna regularnie nie realizuje planu. Jednego dnia wynik jest szczególnie niski.
Sam KPI pokazuje odchylenie, ale nie jego przyczynę. Dlatego zespół analizuje konkretną stratę.
Ponieważ zatrzymanie trwało długo.
Ponieważ diagnoza rozpoczęła się dopiero kilka minut po wystąpieniu problemu.
Ponieważ zgłoszenie nie trafiło od razu do właściwej osoby.
Operator nie miał jednoznacznej informacji, kto powinien przejąć ten rodzaj problemu.
Proces zgłaszania nie określał routingu i zasad eskalacji dla tej kategorii zdarzenia.
„UR musi szybciej naprawiać”
Takie działanie może nie zmienić wyniku, jeśli duża część straty powstaje jeszcze przed rozpoczęciem pracy technika.
Uporządkować routing i eskalację
Działanie odpowiada na konkretny mechanizm ujawniony podczas analizy.
Wzrost MTTR, spadek OEE lub niższy throughput pokazują, że coś się zmieniło. Dopiero analiza procesu pomaga ustalić, dlaczego. Więcej o tej relacji znajdziesz w poradniku KPI w produkcji.
Czy w metodzie 5 Why zawsze trzeba zapytać dokładnie pięć razy?
Nie. Liczba pięć jest nazwą i praktyczną wskazówką, a nie matematyczną regułą.
W jednym problemie przyczyna może być oczywista po trzech logicznych krokach. W innym po pięciu pytaniach nadal będziemy opisywać tylko kolejne objawy.
| Sytuacja | Co zrobić? |
|---|---|
| Po 3 pytaniach mamy potwierdzoną przyczynę | Nie trzeba sztucznie tworzyć dwóch kolejnych odpowiedzi. |
| Po 5 pytaniach nadal opisujemy objawy | Kontynuować analizę. |
| Pojawiają się dwie niezależne przyczyny | Rozdzielić analizę na dwa łańcuchy. |
| Nie znamy odpowiedzi | Zebrać dane zamiast zgadywać. |
| Odpowiedź brzmi „człowiek popełnił błąd” | Zapytać, co w procesie umożliwiło lub ułatwiło pomyłkę. |
Zakończ łańcuch wtedy, gdy dotarłeś do wiarygodnej, możliwej do zweryfikowania przyczyny, na którą można zaprojektować działanie zapobiegające ponownemu wystąpieniu problemu.
Jaką rolę w 5 Why odgrywają dane?
Największą słabością metody 5 Why jest łatwość, z jaką można zbudować całkowicie logicznie brzmiący, ale nieprawdziwy łańcuch przyczyn.
Dlatego każdą istotną odpowiedź warto traktować jak hipotezę wymagającą sprawdzenia.
Zespół wskazuje możliwy powód zdarzenia.
Sprawdzamy zapis, dane, obserwację albo dokumentację procesu.
Dopiero potwierdzony krok staje się podstawą następnego pytania.
W zależności od problemu źródłem potwierdzenia mogą być:
- historia alarmów i zatrzymań maszyny,
- czas wystąpienia, zgłoszenia, przejęcia i zakończenia zdarzenia,
- dane jakościowe oraz parametry procesu,
- historia prac utrzymania ruchu,
- obserwacja rzeczywistego przebiegu pracy,
- instrukcje i obowiązujące standardy,
- rozmowy z operatorami i osobami uczestniczącymi w procesie.
To ważne rozróżnienie. Celem 5 Why nie jest stworzenie najbardziej przekonującej historii o problemie, tylko dojście do przyczyny, którą można potwierdzić i skutecznie zmienić.
5 Why a diagram Ishikawy – kiedy używać którego narzędzia?
5 Why sprawdza się najlepiej wtedy, gdy istnieje stosunkowo czytelny ciąg przyczynowo-skutkowy.
Jeżeli jednak problem może mieć wiele niezależnych źródeł, rozpoczęcie analizy od jednego łańcucha „dlaczego?” może zbyt szybko skierować zespół na jedną ścieżkę.
W takim przypadku lepszym pierwszym krokiem może być diagram Ishikawy.
Pogłębia jedną ścieżkę
Pomaga przechodzić od jednego zdarzenia do coraz głębszych przyczyn.
Poszerza pole analizy
Pomaga zebrać różne możliwe kategorie i hipotezy dotyczące źródła problemu.
Narzędzia można łączyć
Nie są to narzędzia konkurencyjne. Ishikawa pomaga rozszerzyć listę możliwych przyczyn, a 5 Why może następnie pomóc pogłębić najbardziej prawdopodobne lub potwierdzone ścieżki.
Przykład 5 Why dla powtarzającej się awarii maszyny
Drugi przykład pokaże różnicę pomiędzy naprawą skutku a usunięciem mechanizmu prowadzącego do awarii.
Ponieważ temperatura pracy przekroczyła dopuszczalny poziom.
Ponieważ chłodzenie było ograniczone.
Ponieważ filtr wentylacyjny był silnie zanieczyszczony.
Ponieważ czynność nie została wykonana w wymaganym terminie.
Harmonogram przeglądów nie obejmował tego elementu jako osobnego zadania z określoną częstotliwością i odpowiedzialnością.
Dodanie odpowiedniej czynności do standardu utrzymania ruchu może natomiast zmniejszyć prawdopodobieństwo powrotu tego samego mechanizmu.
W tym rodzaju problemów 5 Why może być częścią szerszego procesu analizy niezawodności i doskonalenia utrzymania ruchu. Jeżeli problem jest bardziej złożony, warto połączyć tę metodę z analizą danych i innymi narzędziami root cause analysis.
Kolejny krok to sprawdzenie przyczyny, zaprojektowanie działania, pomiar efektu i upewnienie się, że problem nie wraca. Właśnie tę szerszą logikę pokazujemy w artykule Six Sigma w produkcji i DMAIC.
Najczęstsze błędy w analizie 5 Why
Prostota metody jest jednocześnie jej największą zaletą i największym zagrożeniem. Łatwo przeprowadzić analizę 5 Why w kilkanaście minut. Równie łatwo stworzyć łańcuch, który brzmi logicznie, ale prowadzi do niewłaściwej przyczyny.
Najczęstsze problemy nie wynikają więc z samej techniki zadawania pytań, ale ze sposobu prowadzenia analizy.
| Błąd | Co się wtedy dzieje? | Lepsze podejście |
|---|---|---|
| Problem zawiera już założoną przyczynę | Cała analiza od początku jest kierowana w stronę jednej odpowiedzi. | Rozpocząć od obserwowalnego faktu bez interpretacji. |
| Pytamy dokładnie pięć razy | Zespół kończy analizę dlatego, że skończyły się pola w formularzu. | Pytać tak długo, jak długo uzyskujemy użyteczne i możliwe do potwierdzenia odpowiedzi. |
| Odpowiedzi powstają przy biurku | Łańcuch odzwierciedla przekonania zespołu zamiast rzeczywistego przebiegu procesu. | Weryfikować odpowiedzi na miejscu, w danych i z osobami wykonującymi proces. |
| „Błąd operatora” kończy analizę | Działanie koncentruje się na człowieku, ale proces nadal umożliwia tę samą pomyłkę. | Zapytać, dlaczego pomyłka była możliwa i dlaczego nie została wykryta wcześniej. |
| Jedna ścieżka dla złożonego problemu | Pomijane są inne czynniki mające istotny wpływ na wynik. | Rozgałęzić analizę lub wcześniej użyć diagramu Ishikawy. |
| Hipoteza traktowana jest jak fakt | Zespół projektuje działanie na podstawie niesprawdzonego założenia. | Wskazać dowód potwierdzający każdy kluczowy krok. |
| Analiza kończy się zbyt ogólnie | Przyczyna brzmi np. „brak komunikacji” albo „brak dyscypliny”. | Określić konkretny mechanizm procesu, który można zmienić. |
| Brak pomiaru po działaniu | Nie wiadomo, czy znaleziono rzeczywistą przyczynę. | Po zmianie ponownie zmierzyć problem i sprawdzić, czy przestał występować. |
Jeżeli ktoś może zapytać „skąd to wiemy?”, a zespół potrafi wskazać obserwację, zapis lub dane, analiza staje się znacznie bardziej wartościowa niż sam logicznie brzmiący ciąg zdań.
Dlaczego „błąd operatora” nie powinien kończyć 5 Why?
W produkcji bardzo łatwo zakończyć analizę na stwierdzeniu, że pracownik wykonał niewłaściwą czynność. Czasami rzeczywiście tak było. To jednak nadal nie odpowiada na pytanie, dlaczego proces dopuścił do tej pomyłki i dlaczego nie wykrył jej wcześniej.
Operator ustawił niewłaściwą wartość.
Korzystał z poprzedniej wersji instrukcji stanowiskowej.
Stary wydruk pozostał przy stanowisku po zmianie standardu.
Proces aktualizacji nie obejmował potwierdzenia usunięcia poprzednich wersji ze stanowisk.
Standard zarządzania zmianą dokumentacji określał publikację nowej wersji, ale nie definiował odpowiedzialności za wycofanie starej.
Ponowne przeszkolenie operatora
Może pomóc konkretnej osobie, ale nie usuwa możliwości, że inny pracownik skorzysta z nieaktualnego dokumentu.
Kontrola wersji i wycofywania instrukcji
Zmiana dotyczy mechanizmu, który umożliwił powstanie pomyłki.
Zamiast pytać wyłącznie „dlaczego operator zrobił to źle?”, warto również zapytać: „co w procesie sprawiło, że niewłaściwe działanie było możliwe i nie zostało wykryte?”
Czy 5 Why może mieć więcej niż jedną ścieżkę?
Tak. Rzeczywiste problemy produkcyjne nie zawsze tworzą jeden prosty łańcuch przyczynowo-skutkowy.
Jeżeli na jednym etapie pojawiają się dwie lub trzy wiarygodne odpowiedzi, nie należy arbitralnie wybierać tylko jednej. Analizę można rozgałęzić i każdą hipotezę sprawdzić osobno.
Komponenty potrzebne do kolejnej partii nie zawsze są gotowe przed rozpoczęciem przezbrojenia.
Operator szuka części i narzędzi dopiero po zatrzymaniu maszyny.
Kolejność czynności różni się pomiędzy zmianami i operatorami.
Każda z tych ścieżek może następnie otrzymać własne kolejne pytania „dlaczego?”.
Jeżeli już na początku istnieje wiele potencjalnych kategorii przyczyn, pomocny może być diagram Ishikawy. Pozwala najpierw poszerzyć analizę, a dopiero później wykorzystać 5 Why do pogłębienia wybranych ścieżek.
Czasami problem jest wynikiem kilku warunków występujących jednocześnie. Wtedy skuteczne rozwiązanie również może wymagać kilku zmian.
Jak 5 Why wykorzystuje się w Six Sigma i DMAIC?
5 Why może być jednym z narzędzi używanych podczas fazy Analyze w cyklu DMAIC.
W takim projekcie metoda nie działa w izolacji. Wcześniej problem powinien zostać zdefiniowany, a jego skala zmierzona. Dopiero później zespół przechodzi do szukania przyczyn.
5 Why w logice DMAIC
Przykładowa logika może wyglądać tak:
| Etap | Co robimy? | Przykład |
|---|---|---|
| Define | Precyzujemy problem. | Powtarzalne zatrzymania obniżają throughput linii. |
| Measure | Określamy skalę i baseline. | Mierzymy liczbę zdarzeń, ich czas oraz wpływ na wynik. |
| Analyze | Szukamy i weryfikujemy przyczyny. | 5 Why pomaga pogłębić konkretny typ zatrzymania. |
| Improve | Usuwamy lub ograniczamy potwierdzoną przyczynę. | Zmiana standardu, parametru, zabezpieczenia albo procesu. |
| Control | Sprawdzamy, czy problem nie wraca. | KPI, monitoring, standard i reakcja na ponowne odchylenie. |
5 Why pomaga odpowiedzieć na pytanie „dlaczego?”, ale nie zastępuje pozostałych etapów projektu. Nadal trzeba zmierzyć problem, potwierdzić przyczynę, wdrożyć zmianę i sprawdzić, czy efekt utrzymuje się w czasie.
Szerszy proces pracy nad problemem opisujemy w poradniku Six Sigma w produkcji – jak wykorzystać DMAIC do optymalizacji procesów.
Kiedy 5 Why nie wystarcza?
5 Why jest bardzo użytecznym narzędziem, ale nie powinno być automatyczną metodą dla każdego rodzaju problemu.
Im bardziej złożony, wieloczynnikowy i statystycznie zmienny jest proces, tym większe ryzyko, że prosty liniowy łańcuch okaże się zbyt dużym uproszczeniem.
| Sytuacja | Czy samo 5 Why wystarczy? | Co może być potrzebne? |
|---|---|---|
| Proste, pojedyncze zdarzenie | Często tak | 5 Why + weryfikacja odpowiedzi. |
| Wiele potencjalnych przyczyn | Niekoniecznie | Diagram Ishikawy i rozgałęzione 5 Why. |
| Duża zmienność procesu | Zwykle nie | Analiza danych, rozkładów, trendów i zależności. |
| Problem związany z ryzykiem potencjalnym | Nie zawsze | Analiza ryzyka, np. FMEA. |
| Problem jakościowy zależny od wielu parametrów | Zwykle nie | Analiza procesu i danych dotyczących parametrów. |
| Nieznany przebieg procesu | Najpierw nie | Obserwacja procesu, mapowanie lub SIPOC. |
| Brak wiarygodnych danych | Ryzykowne | Najpierw sposób zebrania i zweryfikowania informacji. |
5 Why jest pomocne wtedy, gdy pasuje do struktury problemu. Jeśli sytuacja wymaga szerszej analizy, lepiej wykorzystać inne metody niż za wszelką cenę zamykać wszystko w pięciu pytaniach.
5 Why, Ishikawa czy analiza danych – co wybrać?
Narzędzia analizy przyczyn odpowiadają na nieco inne potrzeby. Dlatego ich wybór powinien wynikać z tego, czego jeszcze nie wiemy o problemie.
| Narzędzie | Najlepiej odpowiada na pytanie | Kiedy wykorzystać? |
|---|---|---|
| 5 Why | Dlaczego doszło do konkretnego zdarzenia? | Gdy można prześledzić relatywnie czytelny łańcuch przyczynowo-skutkowy. |
| Diagram Ishikawy | Jakie kategorie czynników mogą powodować problem? | Gdy istnieje wiele możliwych przyczyn. |
| Pareto | Które rodzaje problemów odpowiadają za największą część straty? | Gdy mamy wiele kategorii zdarzeń i chcemy ustalić priorytet. |
| Analiza KPI | Gdzie i kiedy wynik odchyla się od oczekiwanego poziomu? | Gdy trzeba zlokalizować obszar wymagający dalszej diagnozy. |
| Analiza statystyczna | Które czynniki są związane ze zmiennością wyniku? | Gdy problem jest wieloczynnikowy i wymaga bardziej zaawansowanej weryfikacji. |
W praktyce narzędzia często tworzą sekwencję:
Przykładowa ścieżka analizy
Jeśli punktem startowym jest odchylenie wyniku, zobacz także KPI w produkcji – jakie wskaźniki mierzyć i jak wykorzystać je do optymalizacji.
Jak przeprowadzić warsztat 5 Why z zespołem?
Dobra analiza nie musi być długim spotkaniem. Powinna natomiast angażować osoby, które znają rzeczywisty przebieg zdarzenia, a nie wyłącznie osoby zarządzające procesem z poziomu raportu.
- Zacznij od jednego konkretnego problemu, a nie ogólnego tematu typu „niska wydajność”.
- Ustal czas, miejsce, maszynę, produkt lub zmianę, której dotyczy zdarzenie.
- Zaproś osoby, które rzeczywiście uczestniczyły w procesie.
- Oddziel fakty od opinii.
- Zapisuj każde kolejne „dlaczego?” wraz z odpowiedzią.
- Przy ważnych krokach dopisz źródło potwierdzenia.
- Jeśli pojawia się kilka odpowiedzi, rozgałęź analizę zamiast wymuszać jedną wersję.
- Nie zatrzymuj się na „błędzie operatora”, „braku komunikacji” lub „braku uwagi”.
- Po znalezieniu przyczyny określ działanie i sposób sprawdzenia jego efektu.
Skład zależy od problemu. W analizie zatrzymania maszyny mogą uczestniczyć operator, lider zmiany i utrzymanie ruchu. Przy problemie jakościowym warto włączyć jakość i technologię procesu. Najważniejsze jest połączenie wiedzy operacyjnej z osobami, które mogą zweryfikować fakty i później zmienić proces.
Co zrobić po znalezieniu przyczyny źródłowej?
Samo znalezienie dobrego wyjaśnienia problemu nie poprawia procesu. 5 Why staje się wartościowe dopiero wtedy, gdy wynik analizy prowadzi do odpowiedniego działania, a organizacja sprawdza jego efekt.
Jeśli zdarzenie nadal wpływa na produkcję, najpierw trzeba ograniczyć jego bieżące konsekwencje.
Zaprojektuj zmianę odpowiadającą na mechanizm potwierdzony podczas analizy.
Monitoruj, czy problem rzeczywiście przestał występować i czy nie powstała nowa strata.
Może to oznaczać, że przyczyna została zidentyfikowana nieprawidłowo, działanie jej nie usuwa albo problem ma jeszcze inne istotne źródła.
Jak mierzyć skuteczność działania po analizie 5 Why?
Najprostszy test brzmi: czy problem, który analizowaliśmy, występuje rzadziej, trwa krócej albo przestał generować wcześniej obserwowaną stratę?
Odpowiedni sposób pomiaru zależy od rodzaju problemu.
| Problem | Przykładowy pomiar efektu |
|---|---|
| Powtarzalna awaria | Częstotliwość zdarzenia, MTBF, liczba ponownych awarii. |
| Długi czas reakcji | Czas od wystąpienia problemu do rozpoczęcia działania. |
| Problem jakościowy | Scrap rate, liczba defektów, First Pass Yield. |
| Niestabilne przezbrojenie | Średni czas oraz rozrzut czasu przezbrojenia. |
| Brak materiału | Liczba zatrzymań z tego powodu oraz czas oczekiwania. |
| Nieaktualna instrukcja | Liczba przypadków użycia niewłaściwej wersji i zgodność ze standardem aktualizacji. |
Przy problemach utrzymania ruchu historia zdarzeń, prac i powtarzających się przyczyn może być również elementem procesu obsługiwanego przez system CMMS. Sam system nie wykonuje jednak analizy 5 Why – dostarcza dane i pomaga później uporządkować działania wynikające z diagnozy.
Checklista: dobra analiza 5 Why
- Czy problem opisano jako obserwowalny fakt, bez zakładania przyczyny?
- Czy wiadomo gdzie i kiedy problem wystąpił?
- Czy pierwsze „dlaczego?” odnosi się bezpośrednio do problemu?
- Czy każde kolejne pytanie wynika z poprzedniej odpowiedzi?
- Czy odpowiedzi można potwierdzić danymi, obserwacją lub dokumentacją?
- Czy w analizie uczestniczyły osoby znające rzeczywisty przebieg procesu?
- Czy nie zakończyliśmy analizy na stwierdzeniu „błąd człowieka”?
- Czy nie wymuszamy dokładnie pięciu pytań?
- Czy problem nie wymaga kilku równoległych ścieżek?
- Czy końcowa przyczyna jest wystarczająco konkretna, aby można było zaprojektować działanie?
- Czy wskazaliśmy właściciela działania?
- Czy wiemy, jak zmierzymy skuteczność zmiany?
- Czy po wdrożeniu sprawdzimy, czy problem nie zaczyna wracać?
Po przeczytaniu analizy od końca powinien powstać wiarygodny łańcuch: ta przyczyna prowadzi do tego zdarzenia, ono prowadzi do kolejnego, a ostatecznie powstaje obserwowany problem. Jeśli związek w którymś miejscu się rozpada, warto wrócić do analizy.
Najczęstsze pytania o metodę 5 Why
Co to jest metoda 5 Why?
5 Why to metoda analizy przyczyn polegająca na wielokrotnym zadawaniu pytania „dlaczego?”, aby przejść od widocznego problemu do głębszej przyczyny lub mechanizmu, który go powoduje.
Co oznacza 5 Why po polsku?
Nazwę można przetłumaczyć jako „5 razy dlaczego”. W praktyce często używa się jednak angielskiej nazwy 5 Why.
Czy zawsze trzeba zadać dokładnie pięć pytań?
Nie. Liczba pięć jest orientacyjna. Analiza może zakończyć się wcześniej albo wymagać większej liczby pytań, zależnie od złożoności problemu.
Co jest celem 5 Why?
Celem jest przejście od objawu do przyczyny, której usunięcie lub ograniczenie zmniejszy prawdopodobieństwo ponownego wystąpienia problemu.
Czy 5 Why jest metodą analizy przyczyn źródłowych?
Tak. 5 Why jest jednym z prostych narzędzi wykorzystywanych w root cause analysis. Nie w każdym problemie jest jednak wystarczające jako jedyna metoda.
Jak przeprowadzić 5 Why?
Najpierw należy precyzyjnie opisać problem. Następnie pytamy, dlaczego doszło do zdarzenia, weryfikujemy odpowiedź i kierujemy kolejne pytanie do wskazanej przyczyny.
Jak powinien wyglądać dobry przykład 5 Why?
Każda odpowiedź powinna wynikać logicznie z poprzedniej, mieć oparcie w faktach i prowadzić do przyczyny, na którą można zaprojektować konkretne działanie.
Czy „błąd operatora” może być przyczyną źródłową?
Może opisywać bezpośrednią przyczynę zdarzenia, ale zazwyczaj warto analizować dalej i sprawdzić, dlaczego pomyłka była możliwa, dlaczego nie została wykryta oraz czy standard i warunki pracy ograniczały ryzyko błędu.
Co zrobić, jeśli pojawia się kilka odpowiedzi na jedno „dlaczego?”?
Analizę można rozgałęzić. Każdą wiarygodną ścieżkę należy potraktować jako hipotezę i sprawdzić osobno.
Jaka jest różnica między 5 Why a diagramem Ishikawy?
Diagram Ishikawy pomaga zebrać i uporządkować wiele możliwych kategorii przyczyn, natomiast 5 Why pogłębia konkretną ścieżkę przyczynowo-skutkową. Narzędzia można stosować razem.
Czy 5 Why można stosować w Six Sigma?
Tak. 5 Why może być wykorzystane szczególnie w fazie Analyze cyklu DMAIC jako jedno z narzędzi służących do identyfikowania i pogłębiania potencjalnych przyczyn.
Czy 5 Why stosuje się tylko w produkcji?
Nie. Metodę można wykorzystywać wszędzie tam, gdzie analizuje się ciąg przyczynowo-skutkowy, między innymi w jakości, utrzymaniu ruchu, logistyce, procesach administracyjnych i usługowych.
Kiedy 5 Why nie wystarcza?
Metoda może być niewystarczająca przy złożonych problemach wieloczynnikowych, dużej zmienności procesu, wielu niezależnych hipotezach lub sytuacjach wymagających analizy statystycznej albo analizy ryzyka.
Czy odpowiedzi w 5 Why trzeba potwierdzać?
Tak. Szczególnie ważne kroki powinny być oparte na danych, obserwacji, dokumentacji lub innych dostępnych dowodach. Bez tego odpowiedź pozostaje hipotezą.
Co zrobić po znalezieniu przyczyny?
Należy zaprojektować działanie odpowiadające na przyczynę, określić osobę odpowiedzialną za jego wykonanie oraz ustalić sposób pomiaru, który pokaże, czy problem rzeczywiście został ograniczony.
Czy 5 Why wystarczy do optymalizacji procesu?
Nie zawsze. 5 Why pomaga znaleźć przyczynę konkretnego problemu. Szersza optymalizacja może wymagać analizy KPI, danych procesowych, strat, przepływu, zmienności oraz późniejszego testowania i utrzymania rozwiązania.
Dobre „dlaczego?” prowadzi do przyczyny. Dobra optymalizacja sprawdza, czy jej usunięcie zmieniło wynik.
5 Why może szybko pomóc przejść od objawu do głębszego problemu. W rzeczywistym zakładzie często potrzebny jest jednak jeszcze kolejny krok: sprawdzenie danych, określenie skali straty, wybór działania i pomiar efektu po zmianie.
W Signalo zaczynamy właśnie od diagnozy procesu i danych. Dopiero kiedy wiadomo, gdzie powstaje strata i jaki mechanizm za nią odpowiada, dobieramy sposób poprawy oraz – jeśli jest potrzebne – odpowiednie narzędzie cyfrowe.
Zobacz, jak optymalizujemy produkcjęMetoda 5 Why pomaga przejść od widocznego problemu do jego głębszej przyczyny poprzez kolejne pytania „dlaczego?”. Nie trzeba zatrzymywać się dokładnie po pięciu krokach. Kluczowe jest to, aby odpowiedzi wynikały z faktów, były możliwe do zweryfikowania i prowadziły do mechanizmu, na który można wpływać. Przy bardziej złożonych problemach 5 Why warto łączyć z diagramem Ishikawy, analizą KPI i szerszą metodologią DMAIC. Sama analiza nie kończy pracy – po znalezieniu przyczyny trzeba jeszcze wdrożyć działanie, zmierzyć efekt i sprawdzić, czy problem nie wraca.
