Analiza przyczyn źródłowych na produkcji: 5 Whys i diagram Ishikawy w praktyce

By Mirko Peters · 2026-11-11

Analiza przyczyn źródłowych na produkcji krok po kroku: kiedy użyć metody 5 Whys lub diagramu Ishikawy, jak zweryfikować przyczynę oraz przykład przestoju z liczbami.

Automatically translated with AI from the original post. Read the English original

Analiza przyczyn źródłowych (RCA) pozwala znaleźć główną przyczynę problemu, tak aby jej usunięcie zapobiegło powrotowi usterki. Na produkcji najczęściej stosuje się metodę 5 Whys oraz diagram Ishikawy. Ten artykuł jest przeznaczony dla kierowników produkcji, którzy muszą dziś rozwiązywać problemy na linii i chcą, aby pozostały rozwiązane. Otrzymasz jasną procedurę, wskazówki, którą z dwóch metod wybrać, przykład przestoju z liczbami oraz listę typowych błędów.

Najważniejsze wnioski

• Analiza przyczyn źródłowych pozwala znaleźć główną przyczynę problemu, dzięki czemu działanie naprawcze zapobiega powtórzeniu się awarii, zamiast leczyć jedynie objaw.
• Stosuj metodę 5 Whys przy jasnym łańcuchu przyczyn i skutków, a diagram Ishikawy najpierw wtedy, gdy kilka przyczyn może na siebie wzajemnie oddziaływać.
• Na każde „dlaczego” trzeba odpowiedzieć zaobserwowanym faktem lub zmierzonymi danymi, a nie hipotezą, i przed podjęciem działania należy zweryfikować przyczynę.
• Zacznij od największych strat, korzystając z widoku Pareto, i nadaj priorytet wąskiemu gardłu, w którym utracony czas kosztuje całą linię.
• Poprawka jest potwierdzona dopiero wtedy, gdy kontrola pokaże, że problem nie wrócił, dlatego prowadź ją jako małą próbę w cyklu PDCA.

Czym jest analiza przyczyn źródłowych na produkcji?

iSixSigma opisuje analizę przyczyn źródłowych jako sposób identyfikowania głównego źródła awarii procesu lub produktu. Zaleca rozpoczęcie od rzeczowego opisu problemu: wadliwego produktu lub procesu, obserwacji, liczby wadliwych sztuk oraz opisu klienta. Zobacz jej artykuł o diagramach Ishikawy i metodzie 5 Whys.

Trzy pojęcia łatwo pomylić:

• Zabezpieczenie (containment) chroni klienta lub linię już dziś, na przykład przez wyselekcjonowanie podejrzanych części. Nie usuwa przyczyny.
• Działanie korygujące to zmiana, która usuwa przyczynę.
• Przyczyna źródłowa to przyczyna, której usunięcie zapobiega powtórzeniu się problemu w podobnych warunkach.

Jeśli tylko zabezpieczasz, ta sama wada lub przestój wróci. Jeśli przechodzisz od razu do działania korygującego bez zweryfikowanej przyczyny, możesz naprawić niewłaściwą rzecz. RCA znajduje się pomiędzy tymi dwoma podejściami.

Kiedy używać metody 5 Whys?

Słownik ASQ opisuje Five Whys jako technikę polegającą na wielokrotnym zadawaniu pytania „dlaczego?”. Zwykle stosuje się ją około pięciu razy, ale mniej lub więcej też jest dopuszczalne, a jej autorstwo przypisuje Sakichi Toyodzie. Jej zasady są praktyczne:

1. Sformułuj precyzyjny opis problemu poparty danymi.
2. Zapytaj, dlaczego problem wystąpił, i zapisz najbliższą obserwowalną przyczynę.
3. Pytaj dalej, dlaczego, o każdą odpowiedź, pozostając przy faktach.
4. Zatrzymaj się na przyczynie, na której możesz podjąć działanie, aby zapobiec powrotowi problemu.
5. Zweryfikuj przyczynę źródłową: czy prowadzi do problemu i czy jej usunięcie zapobiegnie problemowi?
6. Wdróż działanie zaradcze i potwierdź pomiarem kontrolnym, że problem się nie powtarza.

Ta sama strona zaznacza, że każda odpowiedź powinna być „zaobserwowanym faktem lub zmierzoną daną, a nie hipotezą”. Podkreśla też, że metoda działa najlepiej w liniowych łańcuchach przyczynowych z jedną przyczyną źródłową, a w przypadku złożonych problemów zaleca diagram Ishikawy.

Kiedy diagram Ishikawy jest lepszy?

Diagram Ishikawa (rybią ość) to obrazowe przedstawienie hipotez. Efekt, na przykład „krótkie strzały na prasie 3”, znajduje się na czole diagramu, a gałęzie pokazują możliwe przyczyny. Zespoły często grupują gałęzie według kategorii: maszyna, metoda, materiał, ludzie, pomiar i środowisko. Diagram pomaga zespołowi zobaczyć od razu wiele możliwych przyczyn i uzgodnić, które z nich warto sprawdzić.

iSixSigma zaleca przejrzysty sposób łączenia tych narzędzi: najpierw sformułuj opis problemu i zbierz dane, następnie zbuduj diagram z hipotez opisujących obserwowalne skutki, zastosuj metodę 5 whys do najbardziej prawdopodobnych gałęzi i śledź każdą hipotezę, przypisując jej właściciela i termin. Ostrzega również, że diagramy tworzone podczas burzy mózgów często zawierają przyczyny, które nie mają wpływu, oraz że niejasne kategorie, takie jak „oświetlenie”, rzadko wskazują drogę do awarii.

Zasada kciuka: jeśli istnieje jeden wyraźny ciąg przyczynowy, wystarczy metoda 5 whys. Jeśli występuje kilka możliwych czynników przyczyniających się do problemu albo zespół nie ma zgody, najpierw wykonaj diagram Ishikawa.

Wiele problemów produkcyjnych ma więcej niż jedną przyczynę źródłową. Krótki postój może być spowodowany jednocześnie zużytą częścią, brakiem kontroli i lukami w szkoleniu. Gdy zidentyfikujesz przyczynę źródłową, zapytaj, czy znalazłeś jedną z przyczyn źródłowych, czy wszystkie. Dobre zdefiniowanie problemu to połowa odpowiedzi: wąski opis, na przykład „postoje na stanowisku 3 na zmianie nocnej”, prowadzi do mniejszej liczby potencjalnych przyczyn niż opis szeroki. Aby ustalić przyczynę źródłową powtarzającej się wady, porównaj dobre i złe serie produkcyjne i wypisz, czym się różnią. Następnie wdrażaj działania korygujące dla każdej zweryfikowanej przyczyny, pojedynczo, abyś mógł zobaczyć, które z nich działa. To zwykłe rozwiązywanie problemów: najpierw fakty, potem hipotezy, na końcu działania.

Jak przeprowadzić analizę przyczyn źródłowych (RCA) na linii produkcyjnej?

1. Zabezpiecz. Najpierw chroń klienta i linię. Odizoluj podejrzany produkt i przywróć bezpieczny stan.
2. Wybierz problem. Nie analizuj wszystkiego. Skorzystaj z widoku Pareto, czyli zestawienia strat od największej do najmniejszej, i wybierz największą. Przede wszystkim przyjrzyj się wąskiemu gardłu, czyli etapowi ograniczającemu wydajność. Minuta stracona w tym miejscu jest stracona dla całej linii, natomiast minuta stracona na etapie z zapasem zdolności produkcyjnych może nie kosztować nic.
3. Zdefiniuj problem na podstawie danych. Co, gdzie, kiedy, ile i w porównaniu z czym? Podaj liczbę.
4. Idź i zobacz. Obserwuj rzeczywisty proces w gemba, czyli w miejscu, gdzie wszystko się dzieje, na hali produkcyjnej. Porozmawiaj z operatorami, którzy tam byli.
5. Znajdź potencjalne przyczyny. Użyj metody 5 whys lub diagramu Ishikawa z zespołem międzyfunkcyjnym: operatorem, utrzymaniem ruchu, jakością i brygadzistą.
6. Zweryfikuj. Sprawdź najbardziej prawdopodobną przyczynę. Jeśli jest prawdziwa, jej usunięcie powinno zmienić wynik, a jej ponowne wprowadzenie powinno przywrócić problem.
7. Działaj i sprawdzaj. Wdroż środek zaradczy jako mały test i zmierz rezultat. Cykl PDCA nadaje temu etapowi strukturę, a raport A3 może zapisać całą historię na jednej stronie.

Przykład: przestoje na jednej linii

Ten przykład wykorzystuje założone liczby.

Linia 4 pracuje w dwóch zmianach po 8 godzin przez 5 dni, czyli 80 zaplanowanych godzin. W zeszłym tygodniu straciła 14 godzin na postoje, co daje 14 ÷ 80 = 17,5%.

Pareto postojów:

• Błędne odczyty czujnika: 6,3 h (45%)
• Przekroczenie czasu przezbrojenia: 4,2 h (30%)
• Oczekiwanie na materiał: 2,1 h (15%)
• Inne: 1,4 h (10%)

Dwie największe przyczyny stanowią 75% strat. Zespół zaczyna od błędnych odczytów czujnika.

Pięć dlaczego (5 whys).

1. Dlaczego linia się zatrzymała? Czujnik błędnie odczytał położenie detalu.
2. Dlaczego? Na soczewce czujnika był kurz.
3. Dlaczego był kurz? Nikt nie czyści soczewki w trakcie zmiany.
4. Dlaczego nie? Czyszczenie nie jest częścią standardowej pracy operatora.
5. Dlaczego nie? Standard pracy został napisany, zanim zainstalowano czujnik.

Przyczyną źródłową jest luka w standardzie pracy, a nie wadliwy czujnik. Środkiem zaradczym jest dodanie kontroli soczewki do rutyny na początku zmiany oraz zamontowanie małej osłony.

Oczekiwany efekt. Jeśli działania wyeliminują 80% postojów spowodowanych czujnikiem: 6,3 × 0,8 = 5,04 godziny. Nowy czas przestojów to 14 − 5,04 = 8,96 godziny, czyli 8,96 ÷ 80 = 11,2%. Kontrola po dwóch tygodniach pokaże, czy rzeczywisty wynik odpowiada prognozie. Jeśli nie, zespół wraca do diagramu.

Jak upewnić się, że przyczyna jest właściwa?

Przetestuj ustalenie, zanim zainwestujesz w naprawę. Pomogą dwa proste pytania:

• Gdyby zidentyfikowana przyczyna była inna, czy wynik również byłby inny?
• Jeśli ją usuniesz, czy w podobnych warunkach ta sama awaria jest mało prawdopodobna?

Zbieraj dane przed i po wdrożeniu zmiany. Dobra analiza RCA kończy się zmierzonym wynikiem i zmienionym standardem; dzięki temu wspiera ciągłe doskonalenie, a nie gaszenie pożarów. Zapisz też czynniki przyczyniające się, których nie naprawiałeś, na przykład szkolenia czy narzędzia, aby się nie zagubiły.

Uważaj na określenie „błąd ludzki”. Rzadko jest ono przyczyną źródłową. Jeśli operator popełnił błąd, zapytaj, dlaczego proces na to pozwolił: czy instrukcja była jasna, czy narzędzie było odpowiednie, czy był na to czas? Odpowiedź niemal zawsze tkwi w systemie.

Częste błędy

• Zatrzymanie się na pierwszym dlaczego. Pierwsza odpowiedź to zazwyczaj objaw.
• Odpowiadanie opiniami. Każde dlaczego wymaga zaobserwowanego faktu lub pomiaru.
• Szukanie winnych. Obwinianie kończy rozmowę i ukrywa prawdziwą przyczynę.
• Analizowanie najpierw drobnych problemów. Użyj wykresu Pareto i zacznij od największej straty.
• Pomijanie weryfikacji. Niezweryfikowana przyczyna prowadzi do rozwiązania, które nie działa.
• Brak zmiany standardu. Jeśli standardowa praca pozostaje bez zmian, problem wróci.

Jak oprogramowanie może pomóc

Dobra analiza wymaga dobrych danych. Oprogramowanie może rejestrować przyczynę każdego zatrzymania w chwili jego wystąpienia, automatycznie tworzyć wykresy Pareto i pokazywać, czy problem wraca po wdrożeniu rozwiązania. Oszczędza to czas w pierwszych krokach RCA i daje zespołowi fakty zamiast wspomnień. Narzędzie nie myśli za nas. Ludzie nadal muszą pójść na gemba i zapytać dlaczego.

Następny krok

Weź największą stratę z ubiegłego tygodnia na swojej linii, sformułuj opis problemu z liczbą i przeprowadź 5 whys z operatorami, którzy byli wtedy na miejscu. Następnie zweryfikuj przyczynę w małym teście. To praktyczny sposób zastosowania analizy przyczyn źródłowych w Twojej produkcji.