Gdy problem wraca mimo kolejnych poprawek, zwykle nie brakuje pomysłów, tylko porządnej diagnozy. Diagram ishikawy pomaga zebrać możliwe źródła trudności, pogrupować je i sprawdzić, które z nich naprawdę wpływają na wynik. Pokazuję, jak działa to narzędzie, kiedy użyć układu 5M lub 6M, jak przeprowadzić analizę krok po kroku oraz jak przełożyć wnioski na usprawnienie procesu.
Rybia ość pomaga przejść od domysłów do sprawdzonych przyczyn
- Cel: znalezienie potencjalnych przyczyn problemu, a nie szybkie wskazanie winnego.
- Układ 5M lub 6M: porządkuje analizę według ludzi, metod, maszyn, materiałów, pomiarów i środowiska.
- Praktyka: najpierw definiuje się skutek, potem zbiera przyczyny i ich podprzyczyny.
- Weryfikacja: sama burza mózgów nie wystarcza, potrzebne są dane, obserwacje lub testy.
- Efekt: analiza powinna zakończyć się konkretnym działaniem, właścicielem zadania i terminem sprawdzenia.
Rybia ość porządkuje przyczyny zamiast zgadywania
Diagram przyczynowo-skutkowy, nazywany też rybią ością, przedstawia problem jako głowę ryby, a możliwe źródła problemu jako odchodzące od niej ości. Jego największa zaleta polega na tym, że zmusza zespół do spojrzenia na proces szerzej, zamiast automatycznie obwiniać jedną osobę, narzędzie albo dostawcę.
Metoda została spopularyzowana przez Kaoru Ishikawę w zarządzaniu jakością. Dziś korzysta się z niej nie tylko w produkcji, lecz także w IT, obsłudze klienta, logistyce, administracji i pracy projektowej. Sam stosuję ją przede wszystkim wtedy, gdy problem jest powtarzalny, dotyczy kilku etapów procesu i nie daje się wyjaśnić jednym oczywistym błędem.
Trzeba jednak jasno rozdzielić dwie rzeczy. Rybią ość pokazuje hipotezy dotyczące przyczyn, ale nie udowadnia jeszcze, że każda z nich rzeczywiście wywołuje problem. Dowód pojawia się dopiero po sprawdzeniu danych, obserwacji procesu albo przeprowadzeniu kontrolowanego testu.
5M czy 6M, czyli jak dobrać kategorie analizy
Najczęściej spotkasz układ 5M albo rozszerzoną wersję 6M. Nie traktuję tych oznaczeń jak sztywnego standardu. Ich sens polega na tym, by nie pominąć ważnego obszaru procesu, a nie na mechanicznym odhaczaniu wszystkich liter.
| Kategoria | Co obejmuje | Przykładowe pytanie |
|---|---|---|
| Ludzie | Kompetencje, obsada, komunikacja, zmęczenie, odpowiedzialność | Czy zespół wie, kto i jak ma wykonać zadanie? |
| Metoda | Instrukcje, kolejność działań, standardy, procedury | Czy proces jest opisany i wykonywany w ten sam sposób? |
| Maszyny | Sprzęt, oprogramowanie, infrastruktura, awarie, wydajność | Czy narzędzie ogranicza pracę albo generuje błędy? |
| Materiał | Dane wejściowe, surowce, dokumenty, informacje od klienta | Czy wejście ma odpowiednią jakość i kompletność? |
| Pomiar | Metody mierzenia, raporty, wskaźniki, jakość danych | Czy mierzymy właściwy parametr i robimy to poprawnie? |
| Środowisko | Warunki pracy, presja czasu, hałas, regulacje, sezonowość | Czy otoczenie wpływa na tempo lub jakość procesu? |
W klasycznym wariancie 5M pomiar lub środowisko mogą nie występować jako osobne gałęzie. W usługach i projektach cyfrowych często dodaję je świadomie, bo brak dobrych danych albo zła organizacja pracy bywa ważniejsza niż sam system czy kompetencje pracowników.
Jak zrobić analizę krok po kroku
1. Zdefiniuj konkretny skutek
Nie zaczynaj od ogólnego hasła „proces działa źle”. Taki opis jest zbyt szeroki, by dało się go sensownie analizować. Lepiej zapisać problem jako fakt, na przykład „co czwarty raport trafia do klienta po terminie” albo „liczba błędów w danych wzrosła z 2 do 7 procent”. Precyzyjny skutek wyznacza granice całej analizy.
2. Ustal zakres i zaproś właściwe osoby
Do rozmowy zaproś osoby, które wykonują pracę, nadzorują ją albo odbierają jej wynik. Sama perspektywa menedżera często nie wystarcza, ponieważ nie pokazuje drobnych przeszkód występujących w codziennej pracy. Zwykle dobrze działa grupa licząca 3-7 osób, która potrafi rozmawiać o procesie bez szukania winnych.
3. Narysuj główne kategorie
Umieść skutek po prawej stronie, a od głównej osi poprowadź gałęzie 5M lub 6M. Przy prostym problemie wystarczy kartka, tablica albo wspólny dokument online. Narzędzie ma pomagać w myśleniu, więc ładny diagram nie jest celem samym w sobie.
4. Zbierz możliwe przyczyny
Najpierw zapisuj obserwacje bez oceniania ich prawdopodobieństwa. W kategorii „Metoda” mogą pojawić się nieaktualna instrukcja i brak kontroli przed wysyłką, w „Ludziach” niejasny podział odpowiedzialności, a w „Narzędziach” wolny system lub brak automatycznej walidacji.
Dobrze sformułowana przyczyna opisuje mechanizm, a nie etykietę. „Nieuważny pracownik” niewiele wyjaśnia. „Brak kontroli drugiej osoby przy danych wysokiego ryzyka” wskazuje już na element procesu, który można sprawdzić i zmienić.
5. Rozwiń najważniejsze gałęzie pytaniem „dlaczego?”
W tym miejscu przydaje się metoda 5 Why, czyli kilkukrotne pytanie o przyczynę wskazanego zjawiska. Nie trzeba zadawać pytania dokładnie pięć razy. Chodzi o zejście z poziomu objawu do przyczyny, na którą organizacja może realnie wpłynąć.
Przeczytaj również: SMART w praktyce - jak ustawiać cele, które da się dowieźć
6. Wybierz 3-5 hipotez do sprawdzenia
Nie próbuj od razu naprawiać wszystkiego. Oceń przyczyny według częstotliwości występowania, siły wpływu i łatwości potwierdzenia. Następnie sprawdź je w danych, logach systemowych, raportach, rozmowach z klientami albo bezpośredniej obserwacji pracy.
Przykład zastosowania w procesie pracy
Załóżmy, że zespół publikuje materiały dla klientów, ale część z nich pojawia się z dwudniowym opóźnieniem. Samo stwierdzenie „zespół pracuje za wolno” prowadzi do pochopnych wniosków. Rybią ość pozwala rozłożyć problem na kilka niezależnych tropów.
| Obszar | Możliwa przyczyna | Jak ją sprawdzić |
|---|---|---|
| Ludzie | Nie wiadomo, kto zatwierdza finalną wersję | Przejrzeć historię zadań i zapytać osoby uczestniczące w procesie |
| Metoda | Recenzja odbywa się dopiero po zakończeniu całej pracy | Porównać czas oczekiwania na poprawki z czasem tworzenia materiału |
| Narzędzia | Informacje o zmianach są rozproszone w kilku kanałach | Sprawdzić, ile razy zespół szukał aktualnych ustaleń |
| Pomiar | Mierzony jest termin publikacji, ale nie czas oczekiwania | Rozbić cykl na etapy i zmierzyć każdy z nich osobno |
| Środowisko | Najwięcej zadań wpada pod koniec tygodnia | Porównać obciążenie i opóźnienia w poszczególnych dniach |
Po analizie może się okazać, że tworzenie materiału zajmuje tylko jeden dzień, a reszta opóźnienia wynika z oczekiwania na akceptację. Wtedy zakup nowego programu albo zwiększenie zespołu byłoby kosztowną pomyłką. Lepszym rozwiązaniem może być ustalenie właściciela akceptacji i czasu reakcji.
Ten przykład pokazuje też, dlaczego nie warto kończyć pracy na samej burzy mózgów. Każda zapisana przyczyna powinna mieć właściciela weryfikacji, źródło danych i decyzję dotyczącą dalszego działania.
Co zrobić po narysowaniu rybiej ości
Najczęstszy błąd polega na tym, że zespół tworzy rozbudowany diagram, robi zdjęcie tablicy i uznaje pracę za zakończoną. Tymczasem analiza jest dopiero punktem wyjścia. Po wybraniu najbardziej prawdopodobnych przyczyn trzeba przejść do testów i działań korygujących.
Przydatny plan powinien zawierać cztery elementy:
- hipotezę, którą chcemy sprawdzić,
- dowód, którego będziemy szukać,
- działanie, jakie podejmiemy po potwierdzeniu przyczyny,
- miarę efektu, która pokaże, czy problem rzeczywiście się zmniejszył.
Jeśli problem dotyczy częstotliwości błędów, porównaj wynik przed i po zmianie. Jeśli chodzi o czas realizacji, zmierz osobno czas pracy i czas oczekiwania. W procesach jakościowych pomocne bywają też analiza Pareto, karty kontrolne oraz test pilotażowy na małej części procesu.
Nie każda przyczyna wymaga natychmiastowej eliminacji. Czasem wystarczy ograniczyć jej wpływ, dodać kontrolę albo zmienić kolejność działań. Najlepiej działają rozwiązania, które zmieniają proces systemowo, a nie opierają się wyłącznie na większej uwadze pracowników.
Granice metody i błędy, które osłabiają wynik
Rybia ość nie zastępuje danych ani wiedzy procesowej. Jeżeli problem jest bardzo złożony, ma wiele zależności albo zmienia się w czasie, pojedyncza sesja może wygenerować więcej pytań niż odpowiedzi. To nie wada narzędzia, tylko sygnał, że potrzebna jest dokładniejsza analiza.
W praktyce szczególnie często widzę cztery błędy:
- zbyt ogólny problem, przez który diagram staje się listą wszystkich możliwych trudności,
- szukanie winnego zamiast przyczyny osadzonej w procesie,
- mieszanie faktów z opiniami bez oznaczania, co jest potwierdzone, a co tylko przypuszczalne,
- brak właściciela działania, przez co ustalenia nie wychodzą poza spotkanie.
Trzeba też uważać na pozorną zgodę zespołu. Jeśli wszyscy uznają, że problem wynika z „braku komunikacji”, warto dopytać, co dokładnie to oznacza. Czy nie ma konkretnego kanału, terminu odpowiedzi, formatu informacji, czy może odpowiedzialność jest rozproszona? Im bardziej przyczyna jest operacyjna, tym łatwiej ją zweryfikować.
Rybia ość ma sens wtedy, gdy prowadzi do zmiany
Dobrze przygotowany diagram nie daje magicznej odpowiedzi po jednym spotkaniu. Daje za to wspólny obraz problemu, ogranicza pochopne decyzje i pomaga wybrać kilka hipotez, które naprawdę warto sprawdzić.
Moje praktyczne kryterium jest proste: po zakończeniu analizy powinno być wiadomo, co sprawdzamy, kto to robi, do kiedy i po czym poznamy poprawę. Jeżeli tych czterech odpowiedzi brakuje, rybia ość pozostała tylko ciekawym rysunkiem, a nie narzędziem optymalizacji procesu.
