Kierownik logistyki wchodzi na spotkanie i mówi: „Potrzebuję raportu, który codziennie rano pokaże opóźnione zamówienia". Można to wycenić, wrzucić do backlogu i za dwa sprinty dowieźć. Tylko że ten raport niczego nie naprawi. Opóźnienia zostaną, po prostu będą ładnie policzone.
Zanim zapiszesz takie wymaganie, zadaj jedno pytanie: dlaczego te zamówienia w ogóle się spóźniają? Właśnie od tego pytania zaczyna się analiza przyczyn źródłowych. A najprostszym narzędziem, żeby ją przeprowadzić, jest metoda 5 why.
Leczenie objawów kosztuje więcej niż diagnoza - po co BA analiza przyczyn źródłowych
Objaw to coś, co boli biznes tu i teraz: spóźnione zamówienia, reklamacje, ręczne poprawki w Excelu o 22:00. Przyczyna źródłowa to mechanizm, który te objawy produkuje. Jeśli usuwasz tylko objaw, mechanizm dalej działa i za chwilę wyprodukuje kolejny.
Policz koszt scenariusza z raportem. Zespół buduje raport (sprint pracy). Opóźnienia nie znikają, więc przychodzi prośba o alerty mailowe (kolejny sprint). Potem o eskalacje do przełożonych (jeszcze jeden). Po pół roku masz w systemie trzy funkcje monitorujące problem, którego nikt nie rozwiązał. Backlog spuchł, zaufanie do IT spadło, zamówienia dalej się spóźniają.
Analityk biznesowy jest w tym łańcuchu jedyną osobą, której rolą jest zatrzymać się i zapytać „dlaczego", zanim ktokolwiek zacznie budować. Interesariusze prawie zawsze przychodzą z rozwiązaniem, nie z problemem. Twoja praca to cofnąć się od rozwiązania do potrzeby. Analiza przyczyn źródłowych (root cause analysis, RCA) to sposób, żeby robić to systematycznie, a nie na wyczucie.
Metoda 5 why krok po kroku na realnym scenariuszu
Zasada jest prosta: bierzesz problem i pytasz „dlaczego tak się dzieje?". Do odpowiedzi znowu przykładasz „dlaczego?". I tak dalej, zwykle około pięciu razy, aż dojdziesz do przyczyny, na którą organizacja ma realny wpływ. Piątki w nazwie nie traktuj dosłownie - czasem wystarczą trzy pytania, czasem trzeba siedmiu.
Przejdźmy przez to na scenariuszu z początku artykułu.
Problem (sformułowany mierzalnie): znacząca część zamówień B2B wychodzi z magazynu po terminie deklarowanym klientowi.
- Dlaczego zamówienia wychodzą po terminie? Bo magazyn dostaje listy kompletacji z opóźnieniem, często dopiero po południu.
- Dlaczego listy kompletacji powstają tak późno? Bo system generuje je dopiero po zatwierdzeniu zamówienia przez dział sprzedaży, a zatwierdzenie jest ręczne.
- Dlaczego zatwierdzenie jest ręczne? Bo część zamówień ma niestandardowe rabaty i handlowiec musi je zweryfikować przed realizacją.
- Dlaczego na ręczną weryfikację czekają wszystkie zamówienia, skoro rabaty niestandardowe ma tylko część? Bo proces zatwierdzania jest jeden dla wszystkich - nikt nigdy nie rozdzielił ścieżki standardowej od wyjątkowej.
- Dlaczego nikt nie rozdzielił tych ścieżek? Bo przy wdrożeniu obecnego systemu proces przeniesiono jeden do jednego ze starego rozwiązania, bez analizy, czy nadal ma sens.
I jesteśmy przy sednie. Przyczyną źródłową nie jest „wolny magazyn" ani „opieszali handlowcy", tylko projekt procesu: jedna ścieżka zatwierdzania dla wszystkich zamówień, odziedziczona bez refleksji po starym systemie.
Dwie rzeczy odróżniają taką analizę od zgadywania:
- Każda odpowiedź musi być faktem, nie hipotezą. Odpowiedź na pytanie 1 sprawdzasz w timestampach systemu, odpowiedź na pytanie 3 potwierdzasz z handlowcami. Jeśli na którymś poziomie mówisz „chyba", zatrzymaj się i idź po dane.
- Test odwrotny. Przeczytaj łańcuch od dołu do góry, zamieniając „dlaczego" na „dlatego": proces przeniesiono bez analizy, dlatego jest jedna ścieżka dla wszystkich, dlatego każde zamówienie czeka na ręczne zatwierdzenie, dlatego listy kompletacji powstają późno, dlatego zamówienia się spóźniają. Jeśli któreś ogniwo nie wynika logicznie z poprzedniego, łańcuch jest dziurawy.
Pułapki 5 why: łańcuch obwiniania ludzi, trzymanie się jednej gałęzi, zatrzymanie za wcześnie
Metoda 5 why jest zwodniczo prosta i właśnie dlatego łatwo ją zepsuć. Trzy pułapki widuję najczęściej.
Łańcuch kończy się na człowieku
„Dlaczego zamówienia czekają? Bo Marek nie zatwierdza ich na czas." Koniec analizy, mamy winnego. Tyle że wymiana Marka na Kasię niczego nie zmieni, bo Kasia wpadnie w ten sam proces.
Reguła robocza: jeśli odpowiedź na „dlaczego" zawiera imię albo stanowisko, to nie jest przyczyna źródłowa, tylko kolejny objaw. Pytaj dalej, ale o proces: dlaczego praca jednej osoby blokuje cały strumień? Dlaczego nie ma zastępstwa, limitu czasu, automatu? Ludzie popełniają błędy w takim tempie, w jakim proces im na to pozwala.
To ma też wymiar praktyczny dla Ciebie jako facylitatora: jeśli warsztat RCA zamieni się w szukanie winnych, na następny nikt Ci nie przyjdzie z prawdziwymi informacjami.
Trzymanie się jednej gałęzi
5 why jest liniowe, a problemy zwykle nie są. Na pytanie „dlaczego zamówienia się spóźniają" prawdziwa odpowiedź może brzmieć: z trzech powodów naraz - późne listy kompletacji, braki magazynowe i błędne adresy w danych klientów. Jeśli pociągniesz tylko pierwszą nitkę, usuniesz jedną trzecią problemu i ogłosisz sukces, który się nie obroni w liczbach.
Rozwiązanie: na każdym poziomie zapisuj wszystkie odpowiedzi, które padły, a potem prowadź osobny łańcuch dla każdej istotnej. Albo od razu sięgnij po diagram Ishikawy, o którym za chwilę.
Zatrzymanie za wcześnie
„Dlaczego listy generują się późno? Bo system tak działa." Taka odpowiedź to kapitulacja przebrana za wniosek. Dwa testy, które mówią, czy możesz przestać pytać:
- Test nawrotu: czy usunięcie tej przyczyny sprawi, że problem przestanie wracać? Jeśli nie, kop dalej.
- Test wpływu: czy organizacja ma realną możliwość usunięcia tej przyczyny? „Bo klienci składają zamówienia po południu" to fakt, ale nie zmienisz zachowania rynku. Zmienisz za to proces, który tego faktu nie obsługuje.
Diagram Ishikawy (rybia ość) - kiedy 5 why nie wystarcza i jak połączyć obie techniki
Kiedy problem jest wielowymiarowy albo pracujesz z grupą, która sypie hipotezami z różnych stron, samo 5 why robi się chaotyczne. Wtedy wchodzi diagram Ishikawy, zwany rybią ością: głowa ryby to problem, a ości to kategorie potencjalnych przyczyn.
Klasyczne kategorie pochodzą z produkcji, więc na potrzeby pracy analityka w usługach i IT przerabiam je na taki zestaw:
- Ludzie - kompetencje, obciążenie, rotacja, motywacja
- Proces - kroki, przekazania, wąskie gardła, wyjątki
- Systemy - funkcje, integracje, wydajność, błędy
- Dane - jakość, kompletność, aktualność, dostępność
- Zasady - procedury, regulacje, uprawnienia, polityki firmy
- Otoczenie - dostawcy, klienci, sezonowość, rynek
Najlepsze efekty daje połączenie obu technik w jednej sesji. Ishikawa daje szerokość: grupa wrzuca hipotezy do kategorii i nikt nie okopuje się przy swojej ulubionej teorii, bo wszystkie wiszą obok siebie na tablicy. Potem głosowanie kropkami wybiera dwie, trzy najbardziej obiecujące ości. I dopiero na nich odpalasz 5 why, które daje głębokość: od hipotezy do zweryfikowanej przyczyny źródłowej.
Ta kolejność jest ważna. Ishikawa bez 5 why kończy się ścianą karteczek i brakiem wniosków. 5 why bez Ishikawy kończy się jedną gałęzią i przekonaniem, że problem jest prostszy, niż jest.
Root cause analysis wg BABOK i miejsce w codziennej pracy analityka
W BABOK Guide analiza przyczyn źródłowych jest opisana jako jedna z technik pracy analityka, a przewodnik wprost wymienia diagram rybiej ości i five whys jako podejścia do jej przeprowadzenia. RCA wraca wszędzie tam, gdzie BABOK każe najpierw zrozumieć stan obecny, zanim zaczniesz projektować przyszły: przy analizie strategicznej, przy definiowaniu potrzeby biznesowej i przy ocenie, dlaczego wdrożone rozwiązanie nie dostarcza obiecanej wartości.
W codziennej pracy oznacza to co najmniej cztery momenty, w których sięgam po nią najczęściej:
- Nowe zgłoszenie od interesariusza. Zanim „raport opóźnień" trafi do backlogu, jedno lub dwa „dlaczego" potrafią zamienić funkcję-plaster w zmianę, która faktycznie coś naprawia.
- Analiza przed projektem. Sponsor mówi „wdrażamy nowy CRM". RCA na problemach obecnego procesu sprzedaży często pokazuje, że połowa bólu nie zniknie po zmianie narzędzia.
- Incydent produkcyjny albo powtarzająca się reklamacja. Tu RCA to standard w zespołach operacyjnych, a analityk bywa jedyną osobą, która patrzy na incydent od strony procesu, nie tylko kodu.
- Ocena wdrożonego rozwiązania. Funkcja działa, a wskaźnik stoi w miejscu. Dlaczego? To też jest analiza przyczyn źródłowych.
Jeśli myślisz o formalnym potwierdzeniu warsztatu analitycznego, RCA należy do kanonu technik sprawdzanych na egzaminach certyfikacyjnych dla BA. Porównanie dostępnych certyfikacji i wymagań znajdziesz w zestawieniu certyfikacji BA. A jeśli dopiero wchodzisz do zawodu z innej branży, mam dobrą wiadomość: umiejętność drążenia „dlaczego" przenosi się z każdej wcześniejszej roli - jak to wykorzystać, opisuję w ścieżkach przebranżowienia na analityka.
Od przyczyny do wymagania: jak przekuć wynik analizy w pozycje backlogu
Analiza, która kończy się na diagnozie, jest warta tyle, co raport o opóźnieniach. Wynik RCA musi zamienić się w konkretną pozycję backlogu, inaczej cała sesja była kosztowną rozmową.
Ścieżka wygląda tak: przyczyna źródłowa → potrzeba biznesowa → wymaganie z kryteriami akceptacji → miara sukcesu.
Na naszym scenariuszu:
- Przyczyna źródłowa: jedna ręczna ścieżka zatwierdzania dla wszystkich zamówień, niezależnie od tego, czy wymagają weryfikacji.
- Potrzeba biznesowa: zamówienia standardowe mają trafiać do kompletacji bez czekania na człowieka, przy zachowaniu kontroli nad rabatami niestandardowymi.
- Wymaganie (user story): jako kierownik sprzedaży chcę, aby zamówienia spełniające zdefiniowane reguły (standardowy cennik, klient bez blokady płatności) były zatwierdzane automatycznie, a pozostałe trafiały do kolejki wyjątków, żeby magazyn dostawał listy kompletacji bez zbędnej zwłoki.
- Kryteria akceptacji: m.in. reguły automatu konfigurowalne przez biznes, pełny log decyzji automatu, zamówienie z rabatem niestandardowym nigdy nie przechodzi ścieżką automatyczną.
- Miara sukcesu: odsetek zamówień wysłanych w terminie, zmierzony przed zmianą i po niej.
Jeden szczegół, który polecam z własnej praktyki: wpisz przyczynę źródłową do opisu story. Za pół roku, kiedy ktoś zapyta „po co nam ta kolejka wyjątków", odpowiedź będzie w tickecie, a nie w niczyjej pamięci. To najtańsza forma śladowalności wymagań, jaką znam.
Szablon warsztatu RCA: agenda 60 minut + checklista facylitatora
Gotowiec do wzięcia na najbliższy warsztat. Zakłada 4-8 uczestników i jeden problem na sesję.
Agenda 60 minut:
| Czas | Krok |
|---|---|
| 0-5 min | Sformułowanie problemu: jedno zdanie, mierzalne, bez sugerowania przyczyny ani winnego |
| 5-15 min | Zbieranie faktów: co wiemy z danych, co tylko zakładamy (dwie osobne kolumny) |
| 15-30 min | Diagram Ishikawy: burza hipotez do kategorii, bez oceniania |
| 30-40 min | Głosowanie kropkami: wybór 2-3 najbardziej obiecujących ości |
| 40-55 min | 5 why na wybranych ościach, każdy łańcuch osobno, test odwrotny na koniec |
| 55-60 min | Zapis przyczyn źródłowych, przypisanie właścicieli następnych kroków |
Checklista facylitatora - przed warsztatem:
- [ ] Problem statement jest mierzalny i uzgodniony ze zgłaszającym
- [ ] Masz dane, nie tylko opinie (logi, raporty, przykładowe przypadki)
- [ ] Zaprosiłeś ludzi, którzy wykonują proces, nie tylko ich przełożonych
- [ ] Tablica (fizyczna lub wirtualna) z przygotowanym szkieletem rybiej ości
W trakcie:
- [ ] Każde „bo ktoś..." przekierowujesz na pytanie o proces
- [ ] Odpowiedzi-hipotezy oznaczasz do weryfikacji, nie przyjmujesz na wiarę
- [ ] Propozycje rozwiązań lądują na parkingu, nie w łańcuchu przyczyn
- [ ] Każdy łańcuch przechodzi test odwrotny („dlatego") na głos
Po warsztacie:
- [ ] Notatka z łańcuchami przyczyn rozesłana w ciągu 24 godzin
- [ ] Hipotezy z parkingu zweryfikowane na danych przed podjęciem decyzji
- [ ] Przyczyny źródłowe przekute w pozycje backlogu z miarą sukcesu
- [ ] Termin follow-upu ustalony: czy miara faktycznie drgnęła
Ta technika wchodzi w krew dopiero wtedy, gdy przećwiczysz ją na realnym scenariuszu i skonfrontujesz swój łańcuch przyczyn z czyimś feedbackiem. Dokładnie tak działa nauka na Analify: wyzwania na prawdziwych przypadkach, peer review i portfolio, które pokazuje, co potrafisz. Załóż darmowe konto i sprawdź to na własnym warsztacie.