Problemy jakościowe, awarie, reklamacje, przestoje czy spadek wydajności rzadko mają jedną oczywistą przyczynę. Często pierwsze wyjaśnienie, które pojawia się podczas analizy, opisuje jedynie skutek albo bezpośrednie zdarzenie prowadzące do problemu. Usunięcie takiej przyczyny może poprawić sytuację na krótko, ale nie daje pewności, że problem nie powróci. Diagram Ishikawy pomaga uporządkować możliwe źródła problemu i przeprowadzić zespół od obserwowanego skutku do przyczyn, które można zweryfikować.

Metoda jest stosowana w zarządzaniu jakością, produkcji, utrzymaniu ruchu, logistyce oraz doskonaleniu procesów. Jej zaletą jest prostota. Do rozpoczęcia analizy nie jest potrzebne specjalistyczne oprogramowanie. Znacznie ważniejsze są właściwie zdefiniowany problem, udział osób znających analizowany proces oraz konsekwentne oddzielenie faktów od przypuszczeń.

Czym jest diagram Ishikawy?

Diagram Ishikawy, nazywany również diagramem przyczynowo-skutkowym lub diagramem rybiej ości, służy do identyfikowania potencjalnych przyczyn określonego problemu. Nazwa pochodzi od Kaoru Ishikawy, japońskiego specjalisty zajmującego się zarządzaniem jakością.

Konstrukcja diagramu przypomina szkielet ryby. Po prawej stronie znajduje się analizowany skutek, natomiast główne „ości” przedstawiają grupy potencjalnych przyczyn. Od nich odchodzą bardziej szczegółowe przyczyny i kolejne zależności.

Diagram nie daje automatycznie odpowiedzi na pytanie, co spowodowało problem. Jego zadaniem jest uporządkowanie hipotez i wskazanie obszarów wymagających sprawdzenia. Dopiero pomiary, obserwacje, analiza danych lub testy pozwalają ustalić, które z zapisanych przyczyn rzeczywiście wpływają na występowanie niezgodności.

To ważne rozróżnienie. Jeśli zespół potraktuje wszystkie elementy wpisane na diagram jako potwierdzone przyczyny, analiza może prowadzić do błędnych działań korygujących.

Kiedy analiza Ishikawy jest dobrym wyborem?

Diagram przyczynowo-skutkowy sprawdza się szczególnie wtedy, gdy problem może mieć wiele źródeł. Przykładem jest rosnąca liczba wad produktu. Przyczyną może być niewłaściwy parametr maszyny, zużycie narzędzia, materiał o innych właściwościach, błędna instrukcja, niewystarczające szkolenie operatora albo warunki środowiskowe.

Podobnie wygląda analiza powtarzających się przestojów. Sam komunikat o awarii urządzenia nie wyjaśnia, dlaczego problem występuje. Źródłem może być niewłaściwe smarowanie, brak inspekcji, przeciążenie elementu, źle dobrana część zamienna albo zmiana warunków pracy maszyny.

Diagram Ishikawy jest użyteczny przy analizie reklamacji klientów, problemów z terminowością, odchyleń jakościowych, błędów procesowych, wypadków i zdarzeń potencjalnie wypadkowych. Może też wspierać analizę problemów organizacyjnych, jeśli kategorie przyczyn zostaną odpowiednio dostosowane.

Jak poprawnie zdefiniować problem przed rozpoczęciem analizy?

Jakość całej analizy zależy od tego, co zostanie zapisane jako skutek. Ogólne stwierdzenie „mamy problem z jakością” jest zbyt szerokie. Każda osoba może rozumieć je inaczej, przez co diagram szybko zapełni się przypadkowymi hipotezami.

Problem powinien być konkretny, obserwowalny i możliwy do zmierzenia. Zamiast „dużo braków” lepiej zapisać: „udział produktów odrzuconych z powodu nieszczelności wzrósł z 1,2% do 4,8% na linii nr 2 w ciągu ostatnich dwóch tygodni”.

Taka definicja od razu zawęża analizę. Wiadomo, jaki typ niezgodności występuje, gdzie się pojawia, jak duża jest skala i kiedy nastąpiła zmiana.

Przed rozpoczęciem pracy dobrze jest sprawdzić dostępne dane. Kiedy problem pojawił się po raz pierwszy? Czy dotyczy każdej zmiany? Czy występuje na wszystkich maszynach? Czy pojawia się przy konkretnym produkcie, surowcu albo dostawcy? Im dokładniej opisany skutek, tym mniejsze ryzyko analizowania przyczyn niezwiązanych z rzeczywistym problemem.

Kategorie 6M w diagramie Ishikawy

W środowisku produkcyjnym często stosuje się model 6M. Kategorie pomagają spojrzeć na problem z kilku stron i ograniczają ryzyko skupienia się wyłącznie na maszynie albo pracowniku.

  • Man – człowiek: kompetencje, szkolenia, doświadczenie, obciążenie pracą, przestrzeganie standardów.
  • Machine – maszyna: stan techniczny urządzeń, ustawienia, narzędzia, zużycie części, awarie i konserwacja.
  • Method – metoda: instrukcje pracy, kolejność operacji, parametry procesu, standardy oraz sposób organizacji zadań.
  • Material – materiał: jakość surowców, różnice między partiami, sposób przechowywania, specyfikacja i dostawcy.
  • Measurement – pomiar: metody kontroli, przyrządy pomiarowe, kalibracja, częstotliwość pomiarów i sposób interpretacji wyników.
  • Mother Nature – środowisko: temperatura, wilgotność, zapylenie, oświetlenie, hałas oraz inne warunki otoczenia wpływające na proces.

Model 6M jest punktem wyjścia, a nie obowiązkowym szablonem. W logistyce mogą pojawić się kategorie dotyczące transportu, informacji lub magazynowania. Przy analizie procesów administracyjnych bardziej użyteczne mogą być ludzie, procedury, systemy, dane i komunikacja. Kategorie powinny wspierać analizę konkretnego procesu, a nie zmuszać zespół do sztucznego dopisywania przyczyn.

Jak przeprowadzić analizę przyczyn metodą Ishikawy?

Pierwszym etapem jest zapisanie problemu po prawej stronie diagramu. Wszyscy uczestnicy powinni zaakceptować jedną definicję problemu. Jeśli podczas spotkania okazuje się, że członkowie zespołu mówią o różnych zjawiskach, analizę trzeba zatrzymać i doprecyzować zakres.

Następnie wyznacza się główne kategorie. W produkcji najczęściej będzie to wspomniane 6M, ale układ można zmodyfikować.

Kolejny etap polega na poszukiwaniu potencjalnych przyczyn. Zespół odpowiada na pytanie: co mogło doprowadzić do tego konkretnego skutku? Odpowiedzi przypisuje się do odpowiednich kategorii. Na tym etapie nie powinno się odrzucać hipotezy tylko dlatego, że wydaje się mało prawdopodobna. Jednocześnie każda hipoteza powinna mieć logiczny związek z analizowanym problemem.

Po zapisaniu głównych przyczyn należy zejść poziom niżej. Jeśli przyczyną jest „niewłaściwe ustawienie maszyny”, pojawia się pytanie, dlaczego parametr został ustawiony nieprawidłowo. Możliwe odpowiedzi to brak zabezpieczenia nastawy, nieaktualna instrukcja, błędne dane technologiczne albo niejasna odpowiedzialność za zmianę parametrów.

W ten sposób diagram zaczyna pokazywać łańcuch zależności prowadzących do problemu, a nie zbiór luźnych pomysłów.

Diagram Ishikawy i metoda 5 Why

Diagram Ishikawy dobrze łączy się z metodą 5 Why. Ishikawa pomaga znaleźć obszary, w których mogą znajdować się przyczyny problemu, natomiast 5 Why pozwala pogłębić wybrane gałęzie analizy.

Załóżmy, że firma analizuje częste zatrzymania maszyny spowodowane przegrzewaniem się podzespołu. Na diagramie w kategorii „maszyna” pojawia się hipoteza dotycząca niewystarczającego smarowania. Kolejne pytania „dlaczego?” mogą prowadzić do informacji, że punkt smarny nie został obsłużony, ponieważ nie znalazł się w harmonogramie konserwacji, a harmonogram nie został zaktualizowany po modernizacji urządzenia.

W takim przypadku wymiana przegrzanego elementu usuwa skutek. Dodanie punktu do standardu konserwacji oddziałuje na przyczynę systemową.

Liczba pięciu pytań nie jest wymogiem. Czasem wystarczą trzy, a czasem potrzeba więcej. Analizę należy prowadzić do momentu, w którym zostanie wskazana przyczyna możliwa do potwierdzenia i objęcia skutecznym działaniem.

Jak odróżnić przyczynę źródłową od objawu?

Jednym z trudniejszych elementów analizy problemów jest rozpoznanie, czy zespół dotarł już do przyczyny źródłowej. Dobrym testem jest pytanie: jeżeli usuniemy tę przyczynę, czy prawdopodobieństwo ponownego wystąpienia problemu wyraźnie spadnie?

Jeżeli odpowiedź brzmi „nie”, prawdopodobnie analiza zatrzymała się zbyt wcześnie.

Przykładowo stwierdzenie „operator ustawił niewłaściwy parametr” może być prawdziwe, ale nadal wymaga sprawdzenia. Dlaczego mógł wprowadzić błędną wartość? Czy instrukcja była aktualna? Czy system pozwalał na wprowadzenie wartości poza dopuszczalnym zakresem? Czy operator posiadał właściwe szkolenie? Czy parametr był jednoznacznie opisany?

Takie podejście chroni przed częstym błędem polegającym na przypisywaniu problemu do „błędu ludzkiego”. Błąd człowieka może być elementem łańcucha zdarzeń, ale analiza przyczyn powinna sprawdzić warunki, które umożliwiły popełnienie błędu lub sprawiły, że nie został on wykryty.

Jak zweryfikować przyczyny wskazane na diagramie?

Gotowy diagram jest początkiem dalszej pracy. Każda istotna hipoteza powinna zostać sprawdzona na podstawie danych.

Jeśli podejrzewana jest konkretna partia materiału, można porównać poziom wad dla różnych partii. Jeśli hipoteza dotyczy zmiany ustawień maszyny, trzeba przeanalizować historię parametrów. Jeśli problem może zależeć od operatora, należy porównać wyniki między zmianami, uwzględniając pozostałe warunki procesu.

Pomocne mogą być dane z systemów MES, SCADA, ERP, zapisów kontroli jakości, historii awarii, kart przeglądów i raportów zmianowych. W prostszych procesach wystarczy obserwacja stanowiska i wykonanie kontrolowanego testu.

Nie należy wybierać przyczyny źródłowej głosowaniem. Zespół może ustalić, które hipotezy sprawdzić w pierwszej kolejności, ale potwierdzenie związku przyczynowego powinno wynikać z faktów.

Jak przejść od analizy Ishikawy do działań korygujących?

Po potwierdzeniu przyczyny przychodzi moment wyboru działania. Samo „przeszkolenie pracownika” często nie wystarcza, szczególnie jeśli źródłem problemu jest konstrukcja procesu. Jeżeli system umożliwia wprowadzenie niewłaściwej wartości, skuteczniejsze może być ograniczenie zakresu nastaw. Jeśli problem wynika z pominięcia czynności podczas przezbrojenia, pomocne może być zmodyfikowanie standardu i wprowadzenie kontroli wykonania.

Działanie korygujące powinno odpowiadać na potwierdzoną przyczynę. Trzeba również ustalić właściciela, termin oraz sposób sprawdzenia efektu.

Weryfikacja skuteczności jest często pomijana. Po wdrożeniu działania należy obserwować ten sam wskaźnik, który wcześniej pokazywał problem. Jeśli udział braków spadł z 4,8% do wcześniejszego poziomu i utrzymuje się przez ustalony okres, istnieje podstawa do uznania działania za skuteczne. Jeśli wynik się nie poprawia, trzeba wrócić do analizy.

Najczęstsze błędy podczas tworzenia diagramu Ishikawy

Pierwszym błędem jest zbyt szeroka definicja problemu. Diagram dotyczący jednocześnie jakości, przestojów i terminowości będzie trudny do wykorzystania. Każdy z tych problemów może wymagać osobnej analizy.

Drugim błędem jest rozpoczynanie spotkania z gotową odpowiedzią. Jeśli manager od początku zakłada, że winna jest maszyna albo operator, zespół będzie szukał argumentów potwierdzających tę tezę. Diagram powinien rozszerzać pole analizy, zanim rozpocznie się selekcja przyczyn.

Kolejnym problemem jest brak osób znających analizowany proces. Analiza przeprowadzona wyłącznie przez managerów może pomijać szczegóły widoczne dla operatorów, techników, jakościowców czy logistyków.

Błędem jest też zatrzymanie pracy po stworzeniu efektownego diagramu. Jeśli nie następuje weryfikacja hipotez, diagram pozostaje zapisem opinii. Wartość metody pojawia się dopiero wtedy, gdy prowadzi od problemu przez potwierdzoną przyczynę do działania i sprawdzenia jego skuteczności.

Diagram Ishikawy jako część systemowego rozwiązywania problemów

Diagram Ishikawy najlepiej sprawdza się jako element szerszego procesu rozwiązywania problemów. Może być wykorzystywany w ramach PDCA, 8D, A3, DMAIC czy działań CAPA. W każdym z tych podejść jego funkcja jest podobna: uporządkować możliwe przyczyny i pomóc zespołowi zdecydować, co należy zweryfikować.

Dobrze przeprowadzona analiza nie musi być rozbudowana. Przy prostym problemie może zająć kilkadziesiąt minut. Przy złożonej niezgodności wymagającej danych z kilku procesów może wymagać kilku etapów i dodatkowych pomiarów. Kryterium jakości nie jest liczba gałęzi na diagramie, lecz zdolność do znalezienia i potwierdzenia przyczyny, której usunięcie ogranicza ryzyko ponownego wystąpienia problemu.

Diagram Ishikawy pomaga zespołowi przejść od reakcji typu „naprawmy to, co się zepsuło” do bardziej systemowego pytania: „dlaczego proces pozwolił, żeby ten problem wystąpił?”. To właśnie ta zmiana sposobu analizy decyduje o tym, czy działania korygujące gaszą pojedynczy incydent, czy rzeczywiście poprawiają proces.