Analiza przyczyn źródłowych
Analiza przyczyn źródłowych (root cause analysis) to praktyka
pytania, dlaczego coś poszło źle, dopóki odpowiedź nie przestanie się przesuwać. Usunięcie źródła usuwa też objawy, które z niego wyrastają;
usunięcie objawu sprawia tylko, że on wraca. Zarządzanie jakością, obsługa incydentów IT, bezpieczeństwo pacjentów i lotnictwo wymagają jej po każdej
awarii. Metody różnią się głównie tym, kto prowadzi rozumowanie.
Metody
Pięć „dlaczego”Zadaje się pytanie „dlaczego” o awarię, potem o
odpowiedź, i tak pięć razy. Jedna osoba albo mały zespół. Szybko i tanio, a metoda znajduje jeden łańcuch przyczyn — ten, który pytający
i tak podejrzewa. Dobra przy pojedynczym incydencie z jednym mechanizmem; słaba tam, gdzie przyczyny na siebie oddziałują.
Diagram rybiej ości (Ishikawy)Przyczyny podzielone na
kategorie — ludzie, proces, sprzęt, materiały, otoczenie — narysowane jako ości odchodzące od kręgosłupa. Osoba prowadząca wypełnia go
na podstawie sugestii grupy. Raczej szeroki niż głęboki: wymienia kandydatów, ale nic nie mówi o tym, które przyczyny wpływają na które.
Analiza drzewa błędówLogiczne drzewo od góry do dołu, od
awarii przez bramki AND/OR do zdarzeń podstawowych. Rygorystyczna w systemach technicznych, w których znane są elementy i sposoby
ich awarii. Buduje ją analityk; potrzebuje danych, których w sprawach społecznych rzadko się ma.
Analiza ParetoLiczy się incydenty według kategorii i
naprawia te kategorie, które odpowiadają za większość z nich. Mówi, gdzie boli, a nie, co jest przyczyną — to narzędzie do segregacji, a nie do
szukania przyczyn.
Ustrukturyzowany Dialog DemokratycznyLudzie, którzy
żyją z problemem, piszą kandydujące przyczyny, wyjaśniają je, a potem oceniają — po jednej parze naraz, przy progu 75% — czy
każda przyczyna znacząco wpływa na każdą inną. Algorytm składa odpowiedzi w mapę wpływów
(interpretacyjne modelowanie strukturalne, interpretive structural modelling), a przyczyny na dole mapy są źródłami. Pięćdziesiąt lat praktyki,
kilkaset udokumentowanych dialogów. To właśnie prowadzi ta strona.
Kiedy grupa wygrywa z analitykiem
Decyduje jedno pytanie. Czy ktoś w pokoju zna
przyczynę? Jeśli zepsuła się maszyna, inżynier z logami szybciej znajdzie powód niż piętnaście głosujących osób. Jeśli dostawy
się spóźniają, pacjenci czekają, szkoła traci nauczycieli albo miasto traci zaufanie, przyczyny są rozproszone między zaangażowanych
ludzi — nocna zmiana zna jedną, dyspozytor drugą, klient trzecią — i żaden analityk nie zna ich wszystkich. Wtedy
metoda musi zebrać przyczyny od wszystkich i pozwolić wszystkim oceniać powiązania, bo inaczej znajdzie tylko to, w co analityk
już wierzył.
Dwa wyniki badań wyjaśniają, dlaczego zwykła dyskusja w grupie
też tego nie załatwia. Ludzie poproszeni o uszeregowanie przyczyn według ważności, zanim zbada się powiązania między nimi,
szeregują je źle — to efekt błędnych priorytetów (erroneous priorities effect) — a grupa poproszona o opinie rozprasza je tak
szeroko, że nic nie ma większości — to rozproszenie myślenia (spreadthink). Ustrukturyzowany dialog jest zbudowany wokół obu: żadnego szeregowania, dopóki
powiązania nie zostaną ocenione, a powiązania ocenia się po jednym, kwalifikowaną większością.
Co daje dobra analiza przyczyn źródłowych
- Mapę, a nie listę: które przyczyny wpływają na które, ze źródłami na dole.
- Każde powiązanie razem ze zgodą, która za nim stoi, tak by czytelnik widział, co zostało rozstrzygnięte, a co nie.
- Spory zapisane, a nie uśrednione.
- Działania oceniane względem źródeł, a nie względem najgłośniejszego objawu.
Szablon w siedmiu etapach ·
Przykład krok po kroku z prawdziwymi liczbami ·
Jak ta strona prowadzi ją dla dowolnej liczby grup