True Causes
PL

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ów
Logiczne 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 Pareto
Liczy 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 Demokratyczny
Ludzie, 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

Szablon w siedmiu etapach · Przykład krok po kroku z prawdziwymi liczbami · Jak ta strona prowadzi ją dla dowolnej liczby grup