Co to jest diagram Ishikawy i jak znaleźć przyczynę problemu?

Diagram Ishikawy to metoda pomagająca uporządkować możliwe przyczyny konkretnego problemu. Charakterystyczny schemat przypomina szkielet ryby, dlatego często nazywa się go również diagramem rybiej ości albo diagramem przyczyn i skutków. Po jednej stronie znajduje się analizowany problem, a od głównej osi odchodzą grupy potencjalnych przyczyn.

Najważniejszą wartością tej metody nie jest jednak sam rysunek. Diagram Ishikawy zmusza do spojrzenia na problem szerzej niż przez pierwsze, najbardziej oczywiste wyjaśnienie. Jeżeli sklep wysyła zamówienia z opóźnieniem, łatwo powiedzieć: „magazyn pracuje za wolno”. Analiza może jednak pokazać, że rzeczywista przyczyna znajduje się w błędnych stanach magazynowych, ręcznym przepisywaniu danych, źle ustawionej integracji albo sposobie organizacji zamówień.

Co to jest diagram Ishikawy?

Diagram Ishikawy jest narzędziem analizy przyczyn problemu. Pomaga zebrać możliwe czynniki wpływające na określony skutek i uporządkować je w logiczne grupy. Dzięki temu zespół nie koncentruje się wyłącznie na jednym podejrzeniu, ale buduje szerszy obraz sytuacji.

Metoda jest szczególnie przydatna przy problemach złożonych, w których ten sam skutek może mieć kilka przyczyn działających jednocześnie. Opóźnienie realizacji zamówienia może wynikać zarówno z braku produktu, jak i awarii systemu, niejasnej procedury czy przeciążenia konkretnego stanowiska.

Skąd pochodzi diagram Ishikawy?

Nazwa narzędzia pochodzi od Kaoru Ishikawy, japońskiego specjalisty zajmującego się zarządzaniem jakością. Metoda została spopularyzowana w kontekście kontroli jakości i analizy procesów produkcyjnych, ale z czasem zaczęto stosować ją w znacznie większej liczbie obszarów.

Dzisiaj diagramy Ishikawy można wykorzystywać podczas analizy problemów w produkcji, logistyce, sprzedaży, marketingu, IT, e-commerce, obsłudze klienta, zarządzaniu projektami i wielu innych procesach biznesowych.

Dlaczego diagram przypomina rybią ość?

Na końcu głównej osi umieszcza się analizowany problem, czyli skutek. Od osi odchodzą główne kategorie przyczyn, a od nich kolejne bardziej szczegółowe możliwości. Powstaje układ przypominający szkielet ryby.

Największe „ości” reprezentują kategorie, a mniejsze konkretne przyczyny. Jeżeli potrzeba, od konkretnej przyczyny można poprowadzić kolejny poziom i zapytać, co z kolei doprowadziło do jej wystąpienia.

Diagram przyczyn i skutków

Inna popularna nazwa tej metody to diagram przyczyn i skutków. Skutek znajduje się na końcu osi, natomiast pozostała część schematu przedstawia czynniki, które potencjalnie mogły do niego doprowadzić.

To rozróżnienie jest bardzo ważne, ponieważ w codziennej pracy firmy często reagują na skutek, nie analizując jego źródła. Jeśli pracownik codziennie poprawia błędne rekordy, organizacja może uznać, że rozwiązaniem jest „pracować uważniej”. Tymczasem błędy mogą wynikać z interfejsu, który pozwala wprowadzić nieprawidłową wartość.

Objaw a przyczyna

Jedną z najtrudniejszych części analizy problemu jest rozróżnienie objawu od przyczyny. Objaw to coś, co widzimy. Przyczyna wyjaśnia, dlaczego ten objaw występuje.

Przykładowo spadek sprzedaży jest skutkiem. „Mniej klientów kupuje” nadal opisuje właściwie ten sam problem, tylko innymi słowami. Przyczyną może być natomiast wzrost ceny, utrata ruchu organicznego, awaria płatności, brak popularnego produktu albo wydłużenie czasu dostawy.

Po co stosować diagram Ishikawy?

Metoda pomaga przede wszystkim uniknąć zbyt szybkiego wskazania jednej przyczyny. Człowiek naturalnie szuka prostego wyjaśnienia, szczególnie jeśli znajduje się pod presją czasu. W organizacji łatwo wtedy pojawia się diagnoza oparta na intuicji, wcześniejszych doświadczeniach albo pierwszej opinii osoby posiadającej największy autorytet.

Diagram tworzy strukturę rozmowy. Zamiast pytać wyłącznie „kto zawinił?”, można systematycznie analizować proces, narzędzia, dane, ludzi, środowisko i pozostałe elementy systemu.

Diagram Ishikawy nie służy do szukania winnego

To bardzo ważna zasada. Celem analizy jest znalezienie mechanizmu prowadzącego do problemu, a nie osoby, którą można obarczyć odpowiedzialnością. Jeśli pracownik regularnie popełnia ten sam rodzaj błędu, warto sprawdzić, dlaczego system na to pozwala.

Być może formularz jest niejasny, instrukcja nieaktualna, pracownik nie otrzymał potrzebnych danych albo wykonuje zadanie pod zbyt dużą presją. Stwierdzenie „pracownik się pomylił” bardzo często kończy analizę dokładnie tam, gdzie powinna się ona dopiero rozpocząć.

Jak wygląda podstawowy diagram Ishikawy?

Najpierw po prawej stronie zapisuje się problem. Następnie rysuje się główną linię prowadzącą do niego. Od tej osi odchodzą główne kategorie potencjalnych przyczyn, a do każdej kategorii przypisuje się bardziej szczegółowe czynniki.

Przykładowy problem może brzmieć: „Zamówienia są wysyłane po terminie”. Kategorie mogą obejmować ludzi, proces, systemy, dane, materiały i otoczenie. Pod kategorią „systemy” mogą znaleźć się awarie integracji, wolny panel administracyjny albo nieprawidłowa synchronizacja stanów.

Praktyczny wzór diagramu Ishikawy

Najprostszy diagram Ishikawy można przygotować nawet bez specjalnego programu. Wystarczy zapisać po prawej stronie konkretny problem, a następnie utworzyć kilka głównych kategorii możliwych przyczyn. Pod każdą kategorią dopisuje się kolejne hipotezy, które później trzeba zweryfikować danymi, obserwacją procesu albo testem.

Praktyczny wzór może wyglądać następująco:

• Problem: dokładnie opisany skutek, który chcemy wyjaśnić.
• Ludzie: kompetencje, obciążenie, komunikacja, odpowiedzialność, szkolenia.
• Proces: kolejność działań, procedury, zatwierdzenia, ręczne operacje, wąskie gardła.
• Narzędzia i systemy: oprogramowanie, sprzęt, integracje, API, konfiguracja, wydajność.
• Dane: kompletność, poprawność, aktualność, format, źródło informacji.
• Pomiar: sposób mierzenia problemu, jakość raportów, KPI, analityka.
• Otoczenie: sezonowość, dostawcy, zmiany rynkowe, czynniki zewnętrzne.

Do każdej potencjalnej przyczyny warto następnie dopisać pytanie „dlaczego?”. Jeżeli odpowiedź nadal opisuje tylko objaw, trzeba zejść o poziom głębiej. Diagram może więc rozwijać się od ogólnej kategorii do bardzo konkretnego miejsca, w którym problem faktycznie powstaje.

Przykład diagramu Ishikawy dla sklepu internetowego

Załóżmy, że analizowany problem brzmi: „20% zamówień jest wysyłanych po deklarowanym terminie”. Zamiast od razu zakładać, że magazyn pracuje zbyt wolno, można rozpisać problem w kilku obszarach.

• Ludzie: zbyt mała obsada w godzinach szczytu, niejasny podział obowiązków, brak informacji o priorytetowych zamówieniach.
• Proces: zamówienia trafiają do realizacji tylko kilka razy dziennie, część wymaga ręcznego zatwierdzenia, brak jednoznacznych priorytetów.
• Systemy: opóźniona synchronizacja sklepu z magazynem, błędy integracji, wolny panel do obsługi zamówień.
• Dane: nieprawidłowe stany magazynowe, brak części danych wysyłkowych, błędne oznaczenia produktów.
• Pomiar: czas realizacji liczony od niewłaściwego momentu, raport aktualizowany tylko raz dziennie.
• Otoczenie: opóźnienia dostawcy, sezonowy wzrost liczby zamówień, wcześniejsze odbiory paczek przez kuriera.

Po przygotowaniu takiego diagramu nie należy jeszcze wybierać przyczyny wyłącznie na podstawie intuicji. Każdą najważniejszą hipotezę trzeba sprawdzić. Można na przykład porównać godzinę złożenia zamówienia z godziną jego pojawienia się w systemie magazynowym, sprawdzić logi integracji i zestawić opóźnienia z godzinami odbiorów kurierskich.

Prosty szablon do własnej analizy

Przy analizie dowolnego problemu można skorzystać z poniższego schematu:

1. Problem: co dokładnie się dzieje i jaka jest skala?
2. Kategoria 1: jakie przyczyny związane z ludźmi mogą wpływać na problem?
3. Kategoria 2: jakie elementy procesu mogą go powodować?
4. Kategoria 3: czy problem może wynikać z systemu, narzędzia albo integracji?
5. Kategoria 4: czy dane wejściowe są kompletne i poprawne?
6. Kategoria 5: czy właściwie mierzymy analizowane zjawisko?
7. Kategoria 6: jakie czynniki zewnętrzne mogą wpływać na rezultat?
8. Weryfikacja: jakie dane pozwolą potwierdzić albo odrzucić każdą hipotezę?
9. Przyczyna źródłowa: który mechanizm został potwierdzony?
10. Działanie: co trzeba zmienić, aby problem nie pojawiał się ponownie?

Taki wzór można wykorzystać zarówno podczas spotkania zespołu, jak i samodzielnej analizy. Nie trzeba zaczynać od efektownego graficznego diagramu. Najważniejsze jest uporządkowanie myślenia, oddzielenie hipotez od faktów i doprowadzenie analizy do konkretnej przyczyny, którą można później usunąć.

Jak dobrze zdefiniować problem?

Jakość całej analizy zależy od sposobu opisania problemu. Hasło „sprzedaż jest zła” jest zbyt ogólne. Znacznie lepsza definicja brzmi: „Współczynnik konwersji w sklepie spadł z 2,6% do 1,8% w ciągu ostatnich sześciu tygodni”.

Dobry opis powinien być możliwie konkretny i oparty na obserwowalnym zjawisku. Warto określić, co dokładnie się wydarzyło, gdzie występuje problem, kiedy się rozpoczął i jaka jest jego skala.

Nie wpisuj rozwiązania w definicję problemu

Problem „pracownicy potrzebują lepszego szkolenia” już zawiera założenie dotyczące rozwiązania. Być może szkolenie wcale nie jest potrzebne. Być może system jest źle zaprojektowany albo procedura zawiera sprzeczne informacje.

Znacznie lepiej zapisać obserwowany skutek, na przykład: „W 14% zamówień pracownik wybiera nieprawidłowy typ wysyłki”. Dopiero później analizuje się możliwe przyczyny.

Model 5M

Jednym z klasycznych sposobów organizowania diagramu jest model 5M. Główne kategorie odnoszą się do pięciu obszarów, których angielskie nazwy rozpoczynają się od litery M.

• Man, czyli ludzie.
• Machine, czyli maszyny i narzędzia.
• Method, czyli metody i procesy.
• Material, czyli materiały.
• Measurement, czyli pomiary.

Model wywodzi się ze środowiska produkcyjnego, ale można go łatwo dostosować do procesów cyfrowych i usługowych.

Man, czyli ludzie

W tej kategorii analizuje się czynniki związane z osobami uczestniczącymi w procesie. Nie chodzi o wskazanie konkretnego pracownika, ale o sprawdzenie, czy problem może wynikać z organizacji pracy, kompetencji, komunikacji lub obciążenia.

Możliwe przyczyny to brak szkolenia, niejasny podział odpowiedzialności, niewystarczająca liczba osób, przeciążenie, brak dostępu do informacji albo różne sposoby wykonywania tego samego zadania.

Machine, czyli maszyny i narzędzia

W produkcji mogą być to maszyny fizyczne, ale w biznesie cyfrowym do tej kategorii można zaliczyć systemy informatyczne, komputery, aplikacje, integracje i infrastrukturę.

Przykładowe problemy obejmują wolne oprogramowanie, błędną konfigurację, awarie API, brak synchronizacji danych, niestabilny serwer albo narzędzie niedopasowane do procesu.

Method, czyli metoda

Ta kategoria dotyczy sposobu wykonywania pracy. Nawet kompetentni ludzie i dobre narzędzia nie pomogą, jeśli sam proces jest źle zaprojektowany.

Warto analizować liczbę etapów, kolejność działań, zatwierdzenia, procedury, wyjątki, przekazywanie informacji oraz różnice pomiędzy tym, jak proces powinien wyglądać, a jak faktycznie przebiega.

Material, czyli materiały

W produkcji chodzi przede wszystkim o materiały fizyczne. W usługach i systemach cyfrowych kategorię można rozumieć szerzej jako dane wejściowe potrzebne do wykonania procesu.

Problemem mogą być niekompletne dane klienta, nieprawidłowe pliki, błędne opisy produktów, zła jakość danych z zewnętrznego systemu albo brak informacji wymaganej na kolejnym etapie.

Measurement, czyli pomiary

Organizacja może podejmować błędne decyzje, jeśli źle mierzy proces. Być może raport zawiera niewłaściwe dane, KPI jest nieprawidłowo zdefiniowany albo informacje pojawiają się z dużym opóźnieniem.

Warto również sprawdzić, czy problem rzeczywiście występuje w skali, którą zakładamy. Kilka głośnych reklamacji może stworzyć wrażenie dużej awarii, mimo że statystycznie dotyczy ona bardzo niewielkiej części użytkowników.

Model 6M

Rozszerzona wersja modelu dodaje szóstą kategorię: Mother Nature lub Environment, czyli środowisko. Pozwala uwzględnić warunki zewnętrzne wpływające na proces.

W zależności od branży może chodzić o temperaturę, pogodę, lokalizację, warunki pracy, sezonowość, wydarzenia rynkowe albo inne czynniki niezależne od samego zespołu.

Czy trzeba używać 5M lub 6M?

Nie. Kategorie są pomocą, a nie obowiązkowym standardem każdego diagramu. Jeżeli analizowany problem dotyczy strony internetowej, bardziej naturalne mogą być kategorie takie jak technologia, treść, UX, ruch, urządzenia i analityka.

Najważniejsze jest stworzenie podziału, który pomaga zobaczyć problem z różnych perspektyw. Mechaniczne używanie kategorii produkcyjnych w sytuacji, do której zupełnie nie pasują, może tylko utrudnić analizę.

Diagram Ishikawy w e-commerce

Załóżmy, że problem brzmi: „Rośnie liczba porzuconych koszyków”. Możliwe kategorie mogą obejmować checkout, płatności, dostawę, urządzenia, ofertę i błędy techniczne.

W checkout można przeanalizować liczbę pól, błędy walidacji i konieczność zakładania konta. W płatnościach można sprawdzić dostępne metody, awarie operatora i zachowanie po nieudanej transakcji. W dostawie znaczenie mogą mieć koszty, terminy oraz dostępne formy odbioru.

Przykład: spada konwersja sklepu

Problem należy najpierw dobrze zdefiniować. Zamiast „sklep gorzej sprzedaje” można zapisać: „Konwersja użytkowników mobilnych spadła z 2,1% do 1,3% po ostatnim wdrożeniu”. Już sama definicja mocno zawęża obszar poszukiwań.

Pod potencjalnymi przyczynami mogą znaleźć się zmiany checkoutu, wydajność mobile, błędy JavaScript, zmiana źródeł ruchu, problemy z płatnością, dostępność produktów oraz zmiana sposobu mierzenia konwersji.

Nie zakładaj, że problem jest tam, gdzie widać objaw

Jeżeli sprzedaż spadła w checkout, źródło problemu nie musi znajdować się w checkout. Być może po kampanii trafia do sklepu zupełnie inna grupa użytkowników. Być może zmieniła się dostępność produktów albo wcześniej analityka błędnie zliczała część transakcji.

Diagram Ishikawy pomaga właśnie dlatego, że wymusza analizę kilku kategorii zamiast skupienia całej uwagi na najbardziej widocznym miejscu.

Diagram Ishikawy w obsłudze zamówień

Załóżmy, że firma regularnie wysyła część paczek z jednodniowym opóźnieniem. Pierwszą reakcją może być zatrudnienie dodatkowej osoby do magazynu. Diagram może jednak pokazać, że magazyn przez kilka godzin czeka na ręczny eksport zamówień z innego systemu.

W takim przypadku dodatkowy pracownik nie usuwa przyczyny. Prawdziwym problemem jest przepływ informacji pomiędzy systemami. Rozwiązaniem może być zmiana procesu albo odpowiednia automatyzacja.

Diagram Ishikawy w IT

Metoda bardzo dobrze sprawdza się również przy awariach technologicznych. Jeśli aplikacja regularnie działa wolno, potencjalne kategorie mogą obejmować kod, bazę danych, serwer, zewnętrzne API, ruch użytkowników i konfigurację cache.

Pod kategorią „baza danych” można później dodać brak indeksów, ciężkie zapytania albo zbyt dużą liczbę połączeń. Pod „zewnętrzne API” mogą pojawić się limity, timeouty albo duże opóźnienia dostawcy.

Diagram Ishikawy a analiza błędów strony

Jeżeli strona ładuje się wolno, łatwo stwierdzić: „hosting jest słaby”. Tymczasem problem może wynikać z bardzo dużych grafik, setek zapytań do bazy, ciężkich skryptów, źle ustawionego cache albo zewnętrznych widgetów.

Dobra analiza powinna więc najpierw zebrać możliwe przyczyny, a dopiero później sprawdzić je pomiarami. Wymiana hostingu bez diagnozy może być kosztowna i nie przynieść żadnej zauważalnej poprawy.

Diagram Ishikawy w marketingu

Metoda może pomóc przeanalizować na przykład spadek liczby leadów. Kategorie mogą obejmować ruch, ofertę, reklamę, landing page, formularz, pomiar i dział sprzedaży.

Spadek liczby formularzy nie musi oznaczać problemu reklamy. Kampania może dostarczać tę samą liczbę wartościowych użytkowników, ale formularz po ostatniej zmianie przestał działać na części urządzeń. Bez szerszej analizy firma może zwiększyć budżet reklamowy i tylko powiększyć koszt problemu.

Diagram Ishikawy w sprzedaży

Przy spadku liczby zamkniętych transakcji można analizować jakość leadów, ofertę, cenę, proces follow-up, czas reakcji, kompetencje handlowców oraz sposób mierzenia wyników.

Warto unikać prostego wniosku „handlowcy słabo sprzedają”. Być może zespół otrzymuje obecnie znacznie gorsze leady albo odpowiada na zapytania dopiero po dwóch dniach z powodu problemu organizacyjnego.

Diagram Ishikawy w logistyce

Problemy logistyczne zwykle posiadają wiele wzajemnie zależnych przyczyn. Opóźnienia mogą wynikać z braków magazynowych, organizacji kompletacji, działania kuriera, nieprawidłowych etykiet, błędów w zamówieniach albo niewłaściwego rozmieszczenia produktów.

Diagram pomaga rozdzielić te obszary i wskazać, które hipotezy wymagają późniejszego sprawdzenia.

Jak przygotować diagram Ishikawy krok po kroku?

Najpierw należy zdefiniować jeden konkretny problem. Następnie ustala się główne kategorie potencjalnych przyczyn. Dopiero wtedy zespół generuje możliwe czynniki w każdej kategorii i rozwija te, które wymagają bardziej szczegółowej analizy.

1. Zdefiniuj problem.
2. Określ jego skalę i kontekst.
3. Wybierz kategorie przyczyn.
4. Zbierz możliwe przyczyny.
5. Rozwijaj je o kolejne poziomy.
6. Wybierz hipotezy wymagające weryfikacji.
7. Sprawdź je danymi lub eksperymentem.
8. Znajdź i usuń przyczynę źródłową.
9. Sprawdź, czy problem rzeczywiście zniknął.

Krok 1: zdefiniuj skutek

Na końcu diagramu należy zapisać dokładnie to, co jest przedmiotem analizy. Problem powinien być obserwowalny i możliwie konkretny. „Klienci są niezadowoleni” można doprecyzować do „Liczba reklamacji związanych z czasem dostawy wzrosła o 40% w ostatnim kwartale”.

Im lepsza definicja, tym łatwiej później odrzucać przyczyny niemające związku z analizowanym zjawiskiem.

Krok 2: wybierz kategorie

Można wykorzystać 5M, 6M albo stworzyć własny podział. Kategorie powinny być wystarczająco szerokie, aby pobudzić różne sposoby myślenia, ale nie tak ogólne, żeby każda możliwa przyczyna pasowała wszędzie.

W procesie cyfrowym dobrym zestawem może być na przykład: użytkownicy, proces, system, dane, integracje i otoczenie biznesowe.

Krok 3: zbierz możliwe przyczyny

Na tym etapie warto oddzielić generowanie hipotez od ich oceniania. Jeżeli każda propozycja natychmiast spotyka się z odpowiedzią „to na pewno nie to”, część uczestników szybko przestanie zgłaszać pomysły.

Najpierw warto zebrać szeroki zestaw możliwości. Później można wykorzystać dane i wiedzę techniczną do ich weryfikacji.

Krok 4: pytaj dalej

Ogólna przyczyna bardzo często wymaga rozwinięcia. Jeśli ktoś zapisze „błędne dane”, warto zapytać, dlaczego dane są błędne. Być może zostały źle wpisane, pochodzą z nieaktualnego źródła albo integracja mapuje niewłaściwe pola.

W ten sposób od głównej przyczyny tworzy się kolejne mniejsze gałęzie diagramu.

Diagram Ishikawy i metoda 5 Why

Diagram Ishikawy bardzo dobrze łączy się z metodą 5 Why, czyli „pięć razy dlaczego”. Ishikawa pomaga najpierw znaleźć różne potencjalne obszary problemu, natomiast 5 Why pozwala zagłębiać się w konkretną gałąź.

Przykład: zamówienie zostało wysłane z opóźnieniem. Dlaczego? Magazyn dostał je za późno. Dlaczego? Eksport został wykonany dopiero następnego dnia. Dlaczego? Eksport jest uruchamiany ręcznie. Dlaczego? System sklepu nie jest zintegrowany z systemem magazynowym.

Czy zawsze trzeba pytać pięć razy?

Nie. Liczba pięć jest umowna. Czasami przyczyna źródłowa pojawi się po trzecim pytaniu, a w innym przypadku potrzeba siedmiu poziomów.

Najważniejsze jest to, aby nie zatrzymać analizy na pierwszej odpowiedzi tylko dlatego, że brzmi przekonująco.

Co to jest przyczyna źródłowa?

Przyczyna źródłowa to mechanizm znajdujący się wystarczająco głęboko w procesie, którego usunięcie ogranicza lub eliminuje występowanie problemu. Nie zawsze istnieje jedna pojedyncza przyczyna. W złożonym systemie kilka czynników może działać jednocześnie.

Jeżeli pracownik pomylił się, ponieważ system posiada niejasne pola i nie prowadzi walidacji, samo zwrócenie mu uwagi nie usuwa źródła problemu. Zmiana interfejsu może natomiast zapobiegać kolejnym identycznym błędom niezależnie od tego, kto wykonuje zadanie.

Root Cause Analysis

Root Cause Analysis, czyli analiza przyczyn źródłowych, jest szerszym pojęciem obejmującym metody służące do znalezienia rzeczywistego źródła problemu. Diagram Ishikawy jest jednym z narzędzi, które można wykorzystać w takim procesie.

Inne techniki to między innymi 5 Why, analiza Pareto, analiza danych, mapowanie procesu czy analiza drzewa błędów.

Hipoteza to nie dowód

Najważniejsza pułapka diagramu Ishikawy polega na tym, że bardzo łatwo pomylić wymyśloną przyczynę z potwierdzoną przyczyną. Fakt, że dana możliwość została wpisana na diagramie, nie oznacza, że rzeczywiście odpowiada za problem.

Każda ważna hipoteza powinna później zostać zweryfikowana. Mogą do tego służyć dane, logi, obserwacja procesu, test, rozmowy z użytkownikami albo kontrolowany eksperyment.

Diagram nie zastępuje danych

Jeżeli zespół zapisze „serwer jest przeciążony”, warto sprawdzić użycie CPU, pamięci, liczbę zapytań i czas odpowiedzi. Jeżeli podejrzenie brzmi „użytkownicy nie rozumieją formularza”, warto przeanalizować zachowanie użytkowników albo wykonać test użyteczności.

Diagram pomaga wiedzieć, czego szukać. Nie jest sam w sobie dowodem.

Jak wybierać przyczyny do sprawdzenia?

Przy rozbudowanym problemie diagram może zawierać kilkadziesiąt hipotez. Nie da się badać wszystkich jednocześnie. Warto więc ocenić prawdopodobieństwo, możliwy wpływ oraz koszt sprawdzenia konkretnej przyczyny.

Jeżeli logi można sprawdzić w pięć minut, a wykluczenie danego problemu znacząco zawęzi dalszą analizę, jest to dobry punkt startowy.

Diagram Ishikawy a zasada Pareto

Po zebraniu przyczyn można wykorzystać analizę Pareto do ustalenia, które z nich odpowiadają za największą część problemów. Przykładowo firma może posiadać dziesięć rodzajów błędów zamówień, ale dwa z nich odpowiadają za większość reklamacji.

Diagram pomaga znaleźć możliwe źródła, natomiast Pareto pomaga ustalić, gdzie koncentracja wysiłku może dać największy efekt.

Burza mózgów i diagram Ishikawy

Diagram często powstaje podczas pracy zespołowej i może wykorzystywać burzę mózgów. Warto zaprosić osoby posiadające różne perspektywy na proces. Manager może znać procedurę, programista system, a pracownik operacyjny codziennie widzieć sytuacje, które nigdy nie trafiają do raportów.

Najlepszy obraz problemu często powstaje właśnie przez połączenie kilku takich perspektyw.

Kto powinien uczestniczyć w analizie?

Nie ma jednej obowiązkowej listy. Powinny pojawić się osoby posiadające wiedzę o różnych częściach analizowanego procesu. Przy problemie sklepu internetowego mogą to być osoby odpowiedzialne za e-commerce, magazyn, marketing, development i obsługę klienta.

Nie warto jednak tworzyć ogromnego spotkania z osobami, które nie mają żadnej wiedzy o procesie. Większa liczba uczestników nie gwarantuje lepszej analizy.

Znaczenie osoby wykonującej proces

Bardzo częstym błędem jest analizowanie procesu wyłącznie na poziomie managementu. Procedura może wyglądać perfekcyjnie w dokumencie, ale rzeczywista praca odbywa się zupełnie inaczej.

Osoba wykonująca proces codziennie może wiedzieć, że konkretne pole zawsze trzeba poprawiać ręcznie, eksport regularnie się zawiesza albo jeden etap wymaga nieformalnego obejścia. Taka wiedza jest niezwykle wartościowa.

Gemba i obserwacja procesu

Znana z Lean idea Gemba zakłada obserwowanie pracy tam, gdzie rzeczywiście się odbywa. Zamiast wyłącznie pytać, jak działa proces, warto czasami zobaczyć jego realne wykonanie.

Może się okazać, że oficjalna instrukcja posiada pięć kroków, ale pracownik wykonuje dodatkowe cztery czynności, ponieważ bez nich system nie działa prawidłowo.

Diagram Ishikawy w analizie procesu cyfrowego

Przy projektach cyfrowych często analizuję przepływ danych pomiędzy systemami. Problem widoczny w jednym miejscu może powstawać kilka etapów wcześniej. Produkt ma złą cenę w sklepie, ale źródłem jest błędna wartość w systemie nadrzędnym albo nieprawidłowa reguła integracji.

Przy dedykowanych systemach operacyjnych takie podejście jest szczególnie ważne. Budowanie nowej funkcji bez zrozumienia źródła problemu może tylko cyfryzować istniejący chaos.

Przykład analizy integracji

Załóżmy, że stan magazynowy w sklepie regularnie jest nieprawidłowy. Możliwe kategorie to system źródłowy, integracja, WooCommerce, harmonogram synchronizacji, identyfikatory produktów i operacje wykonywane ręcznie.

Dopiero po rozpisaniu całego procesu można sprawdzić, czy problem wynika z niewłaściwego SKU, opóźnienia synchronizacji, błędu API czy ręcznej zmiany dokonanej bezpośrednio w sklepie.

Nie naprawiaj objawu w systemie końcowym

Jeżeli dane są błędne w systemie źródłowym, poprawianie ich ręcznie w WooCommerce może dać chwilowy efekt, ale następna synchronizacja ponownie nadpisze wartości. Trzeba znaleźć miejsce, w którym błąd rzeczywiście powstaje.

To dobry przykład różnicy pomiędzy leczeniem objawu i usuwaniem przyczyny.

Diagram Ishikawy przy problemach SEO

Jeżeli spada widoczność strony, przyczyn może być bardzo wiele. Kategorie mogą obejmować techniczne SEO, treść, indeksowanie, linkowanie, konkurencję, zmiany algorytmiczne i pomiar.

Pod technicznym SEO mogą znaleźć się błędy canonical, noindex, robots.txt, wydajność albo problemy z renderowaniem. Pod treścią można analizować jej aktualność, dopasowanie do intencji i strukturę serwisu.

Problem może mieć kilka przyczyn jednocześnie

Nie należy zakładać, że każde zjawisko posiada jedną ukrytą przyczynę, którą wystarczy odkryć. Spadek sprzedaży może być wynikiem jednoczesnego pogorszenia ruchu, niedostępności kilku bestsellerów i błędu mobilnej płatności.

Diagram pozwala zobaczyć system jako zestaw czynników zamiast szukać jednej magicznej odpowiedzi.

Przyczyny zależne od siebie

Niektóre czynniki wpływają również na siebie nawzajem. Przeciążenie pracownika może zwiększać liczbę błędów. Błędy powodują poprawki, a poprawki jeszcze bardziej zwiększają przeciążenie. Powstaje mechanizm sam wzmacniający problem.

W takim przypadku rozwiązanie jednego elementu może zmniejszyć kilka innych problemów jednocześnie.

Korelacja nie oznacza przyczyny

Jeżeli dwa zdarzenia występują w podobnym czasie, nie oznacza to automatycznie, że jedno spowodowało drugie. Sprzedaż mogła spaść po wdrożeniu nowego layoutu, ale w tym samym czasie mogła zakończyć się kampania reklamowa.

Diagram może uwzględnić oba czynniki, a późniejsza analiza powinna sprawdzić ich rzeczywisty wpływ.

Jak zweryfikować przyczynę?

Metoda zależy od charakteru problemu. Można analizować dane historyczne, porównać okresy, sprawdzić logi, przeprowadzić test A/B, odtworzyć błąd albo obserwować proces. W niektórych przypadkach można czasowo zmienić jeden czynnik i sprawdzić, czy rezultat również się zmienia.

Najważniejsze jest przejście z poziomu „wydaje nam się” do „mamy dowód”.

Przykład weryfikacji

Zespół podejrzewa, że wysoka liczba porzuceń checkout wynika z braku konkretnej metody płatności. Samo umieszczenie tej hipotezy na diagramie niczego nie potwierdza.

Można sprawdzić zapytania klientów, dane o nieudanych płatnościach, zachowanie na checkout oraz później wdrożyć brakującą metodę i porównać wynik. Dopiero wtedy można ocenić rzeczywisty wpływ.

Diagram Ishikawy a PDCA

Diagram można połączyć z cyklem PDCA: Plan, Do, Check, Act. Najpierw analizuje się problem i planuje zmianę, później wdraża rozwiązanie, mierzy rezultat i na podstawie wyniku podejmuje dalsze działanie.

To ważne, ponieważ znalezienie prawdopodobnej przyczyny nie kończy procesu. Trzeba jeszcze sprawdzić, czy zastosowana poprawka faktycznie rozwiązała problem.

Nie zamykaj problemu po wdrożeniu poprawki

Firma wprowadziła zmianę i problem „powinien być rozwiązany”. To za mało. Należy ponownie zmierzyć wskaźnik i sprawdzić, czy oczekiwany efekt rzeczywiście nastąpił.

Jeżeli reklamacje nie spadły, prawdopodobnie przyczyna była inna albo wdrożenie rozwiązało tylko część problemu.

Działanie korygujące a działanie zapobiegawcze

Działanie korygujące usuwa istniejący problem. Działanie zapobiegawcze ma ograniczyć ryzyko jego ponownego pojawienia się.

Jeżeli błędny rekord zostanie poprawiony ręcznie, usunięto skutek. Jeżeli system otrzyma walidację uniemożliwiającą zapisanie podobnego błędu w przyszłości, proces został dodatkowo zabezpieczony.

Diagram Ishikawy i automatyzacja

Analiza przyczyn jest bardzo przydatna przed automatyzacją. Jeżeli firma próbuje automatyzować źle zaprojektowany proces, może tylko przyspieszyć generowanie błędów.

Najpierw warto ustalić, które czynności są potrzebne, gdzie powstają problemy i które dane są źródłem prawdy. Dopiero później można projektować automat wykonujący poprawny proces.

Najczęstszy błąd: problem zbyt ogólny

Hasło „firma działa za wolno” prowadzi do diagramu obejmującego praktycznie całą organizację. Trudno wtedy przejść od analizy do konkretnego działania.

Lepiej wybrać jeden mierzalny proces, na przykład „średni czas przygotowania oferty wzrósł z jednego do trzech dni”.

Najczęstszy błąd: tylko pierwsza warstwa przyczyn

Zespół zapisuje „brak czasu”, „błędy pracowników” i „problemy systemu”, po czym uznaje diagram za gotowy. To zbyt ogólne kategorie, żeby można było na ich podstawie coś naprawić.

Każdą z nich trzeba rozwijać. Dlaczego brakuje czasu? Jaki dokładnie problem występuje w systemie? Jaki rodzaj błędu popełniają pracownicy i w którym miejscu procesu?

Najczęstszy błąd: rozwiązania zamiast przyczyn

Na diagramie pojawiają się hasła „potrzebujemy nowego systemu” albo „trzeba zatrudnić więcej ludzi”. To potencjalne rozwiązania, a nie przyczyny problemu.

Najpierw trzeba ustalić, dlaczego obecny system jest niewystarczający albo dlaczego aktualna liczba pracowników nie wystarcza.

Najczęstszy błąd: przyczyny oparte wyłącznie na opinii

Osoba najbardziej przekonująca podczas spotkania może zdominować analizę. Diagram zaczyna wtedy odzwierciedlać hierarchię firmy zamiast rzeczywistego procesu.

Dlatego po wygenerowaniu hipotez potrzebna jest ich weryfikacja danymi i obserwacją.

Najczęstszy błąd: za dużo kategorii

Diagram nie staje się lepszy tylko dlatego, że posiada piętnaście głównych gałęzi i sto podpunktów. Zbyt duża liczba elementów może utrudnić znalezienie najważniejszych zależności.

Jeżeli problem jest ogromny, warto podzielić go na kilka mniejszych analiz.

Najczęstszy błąd: za mało perspektyw

Analiza przygotowana przez jedną osobę może być dobra, ale zawsze jest ograniczona jej wiedzą. Specjalista od marketingu może nie wiedzieć o błędzie magazynowym, a programista może nie znać sposobu, w jaki użytkownicy rzeczywiście przechodzą przez proces.

Przy ważnych problemach warto zebrać wiedzę kilku osób.

Najczęstszy błąd: kończenie na diagramie

Ładny diagram na prezentacji nie rozwiązuje żadnego problemu. Po analizie powinny pojawić się działania: weryfikacja najważniejszych hipotez, ustalenie przyczyny, wdrożenie zmiany i sprawdzenie rezultatu.

Jeżeli diagram kończy życie jako załącznik do raportu, był tylko ćwiczeniem analitycznym.

Najczęstszy błąd: brak właściciela działania

Zespół poprawnie ustala przyczynę, ale nikt nie odpowiada za jej usunięcie. Po kilku miesiącach ten sam problem nadal występuje.

Każde działanie powinno posiadać odpowiedzialną osobę, termin i sposób oceny rezultatu.

Kiedy diagram Ishikawy nie jest najlepszym narzędziem?

Jeżeli problem jest bardzo prosty i jego przyczyna jest oczywista oraz potwierdzona, tworzenie rozbudowanego diagramu może być stratą czasu. Jeśli kabel został fizycznie odłączony i dlatego urządzenie nie działa, nie potrzeba wielogodzinnego warsztatu przyczynowego.

Metoda daje największą wartość przy problemach złożonych, powtarzalnych albo takich, których przyczyna nie jest oczywista.

Diagram Ishikawy a jednorazowa awaria

Nawet pojedyncza awaria może wymagać analizy, jeśli jej konsekwencje były poważne. W takim przypadku warto sprawdzić nie tylko bezpośrednią przyczynę, ale również dlaczego system nie posiadał zabezpieczenia pozwalającego wykryć lub ograniczyć problem wcześniej.

To szczególnie istotne przy bezpieczeństwie, finansach i procesach krytycznych.

Diagram Ishikawy a problemy powtarzalne

Jeżeli zespół regularnie gasi ten sam pożar, jest to bardzo dobry sygnał do przeprowadzenia analizy przyczynowej. Powtarzalność oznacza, że dotychczasowe działania prawdopodobnie usuwają skutek, ale nie źródło.

Przykładem może być cotygodniowe ręczne poprawianie stanów magazynowych. Zamiast planować kolejną poprawkę, warto sprawdzić, dlaczego rozbieżności stale powstają.

Jak prowadzić warsztat Ishikawy?

Na początku należy jasno przedstawić problem i upewnić się, że wszyscy analizują dokładnie to samo zjawisko. Następnie można przechodzić przez kolejne kategorie i zbierać możliwe przyczyny bez zbyt szybkiego oceniania.

Po zebraniu materiału warto pogrupować podobne elementy, połączyć zależności i wybrać kilka najbardziej prawdopodobnych przyczyn do dalszego sprawdzenia. Warsztat powinien zakończyć się konkretnym planem weryfikacji.

Diagram na tablicy czy w programie?

Narzędzie nie ma większego znaczenia. Diagram można narysować na kartce, tablicy, w programie do diagramów albo w aplikacji do wspólnej pracy online.

Ważniejsze jest to, czy metoda pomaga uczestnikom myśleć o przyczynach i czy później można wykorzystać wynik do dalszej analizy.

Nie zaczynaj od idealnego diagramu

Na początku nie trzeba martwić się perfekcyjnym rozmieszczeniem wszystkich elementów. Diagram jest narzędziem roboczym. Może być przebudowywany, gdy pojawiają się nowe informacje.

Najważniejsza jest jakość analizy, a nie estetyka rybiej ości.

Diagram Ishikawy a mapa procesu

Jeżeli problem dotyczy procesu wieloetapowego, warto wcześniej lub równolegle przygotować prostą mapę procesu. Pozwala zobaczyć, w którym miejscu powstaje opóźnienie, błąd albo przekazanie informacji.

Mapa odpowiada przede wszystkim na pytanie „jak przebiega praca?”, a diagram Ishikawy pomaga później odpowiedzieć „dlaczego pojawia się problem?”.

Diagram Ishikawy a SIPOC

SIPOC to metoda opisująca dostawców, wejścia, proces, wyjścia i klientów procesu. Może pomóc ustalić granice analizowanego problemu przed rozpoczęciem bardziej szczegółowej analizy przyczyn.

Przy bardzo złożonych procesach połączenie kilku prostych metod często daje znacznie lepszy obraz niż próba umieszczenia wszystkiego na jednym diagramie.

Diagram Ishikawy a FMEA

FMEA służy do analizowania potencjalnych sposobów wystąpienia błędów i oceniania związanego z nimi ryzyka. Ishikawa koncentruje się bardziej na możliwych przyczynach konkretnego problemu.

Obie metody mogą się uzupełniać. Jedna pomaga zrozumieć, dlaczego coś się wydarzyło, a druga może pomóc przewidzieć i ograniczyć podobne problemy jeszcze przed ich wystąpieniem.

Diagram Ishikawy a analiza SWOT

Oba narzędzia służą analizie, ale rozwiązują zupełnie inne problemy. SWOT służy do strategicznej oceny mocnych stron, słabości, szans i zagrożeń. Diagram Ishikawy koncentruje się na przyczynach konkretnego skutku.

Nie należy używać tych metod zamiennie tylko dlatego, że obie mają postać prostego schematu.

Diagram Ishikawy i ciągłe doskonalenie

Metoda dobrze wpisuje się w kulturę ciągłego doskonalenia. Zamiast akceptować powtarzalne błędy jako normalną część pracy, organizacja może systematycznie analizować ich źródła i przebudowywać proces.

Z czasem prowadzi to nie tylko do mniejszej liczby problemów, ale również do lepszego rozumienia działania całego systemu.

Co daje dobra analiza przyczyn?

Największą korzyścią jest możliwość usuwania problemów u źródła. Zamiast co tydzień wykonywać tę samą poprawkę, firma może raz zmienić proces, system albo zasady i ograniczyć występowanie błędu w przyszłości.

To często daje znacznie większą wartość niż dalsze optymalizowanie sposobu obsługi skutków.

Co warto zapamiętać o diagramie Ishikawy?

Diagram Ishikawy to narzędzie pomagające uporządkować możliwe przyczyny konkretnego problemu. Charakterystyczna forma rybiej ości pozwala podzielić je na główne kategorie, a następnie rozwijać o bardziej szczegółowe czynniki.

Popularne modele 5M i 6M obejmują ludzi, maszyny lub narzędzia, metody, materiały, pomiary oraz środowisko. Nie trzeba jednak stosować ich mechanicznie. Kategorie można dostosować do analizowanego procesu, szczególnie w usługach i biznesie cyfrowym.

Najważniejsze jest odróżnienie objawu od przyczyny. Stwierdzenie, że pracownik popełnił błąd albo system nie zadziałał, często jest dopiero początkiem analizy. Trzeba sprawdzić, dlaczego błąd był możliwy i co w procesie doprowadziło do jego wystąpienia.

Diagram Ishikawy bardzo dobrze współpracuje z metodą 5 Why, analizą Pareto, mapowaniem procesu i danymi. Sam schemat nie udowadnia jednak żadnej przyczyny. Wszystkie ważne hipotezy trzeba później zweryfikować obserwacją, pomiarami albo eksperymentem.

Największa wartość metody pojawia się wtedy, gdy analiza prowadzi do trwałej zmiany. Nie chodzi o stworzenie efektownego diagramu, ale o znalezienie miejsca, w którym można poprawić system tak, aby problem nie musiał być ciągle rozwiązywany od nowa.