RCA – analiza przyczyn źródłowych: usuń mechanizm problemu, nie jego objaw

RCA nie jest nazwą jednego diagramu. To sposób dochodzenia od obserwowanego skutku do przyczyn, które można potwierdzić i na które organizacja może oddziaływać. IPP dobiera poziom analizy do skali problemu: od prostego 5 Why po analizę interdyscyplinarną opartą na danych, historii zdarzeń i eksperymentach.

Porozmawiajmy o wdrożeniu

Kiedy ten obszar ma sens

awarie lub wady wracają po pozornie skutecznych naprawach
zespół kończy analizę stwierdzeniem „błąd operatora”
Ishikawa generuje wiele możliwych przyczyn, ale nie wiadomo które są prawdziwe
działania korygujące są zamykane bez sprawdzenia skuteczności

Co obejmuje wdrożenie

Problem statement

Co, gdzie, kiedy, ile i w jakich warunkach odbiega od standardu.

Evidence

Historia zdarzeń, parametry procesu, zdjęcia, części, logi, próbki i obserwacja Gemba.

Causal analysis

5 Why, Ishikawa, fault tree lub inne narzędzie dobieramy do problemu, a nie odwrotnie.

Verification

Przyczyna zostaje uznana dopiero, gdy wyjaśnia mechanizm i można sprawdzić wpływ działania.

Co zostaje po projekcie

standard klasyfikacji problemów do RCA
format analizy
zasady evidence i weryfikacji
rola facylitatora
biblioteka przyczyn i lessons learned
mechanizm effectiveness check

Jak mierzymy efekt

repeat failure/defect rateczas RCAodsetek RCA z effectiveness checkczas do trwałej korektyudział przyczyn typu system/process vs nieprecyzyjne human error

Najczęstsze błędy wdrożeniowe

Human error jako koniec analizy

Błąd człowieka opisuje zdarzenie, ale zwykle nie wyjaśnia warunków, które je umożliwiły.

Głosowanie na przyczynę

Najbardziej popularna hipoteza nie jest dowodem.

5 Why bez faktów

Łatwo dojść do odpowiedzi zgodnej z intuicją zespołu, ale niekoniecznie z rzeczywistością.

Działanie bez testu skuteczności

Brak ponownego zdarzenia przez kilka dni może nie być wystarczającym dowodem.

Powiązane strony

FAQ

Czym różni się RCA od 5 Why?

RCA to proces analizy przyczynowej. 5 Why jest jednym z narzędzi, odpowiednim dla części prostszych problemów.

Czy Ishikawa wskazuje przyczynę źródłową?

Nie sama w sobie. Diagram porządkuje potencjalne przyczyny, które później trzeba zweryfikować danymi lub testem.

Kiedy problem jest zbyt mały na pełne RCA?

Gdy przyczyna jest oczywista, ryzyko niskie i problem nie jest powtarzalny. Organizacja powinna mieć progi eskalacji.

Czy RCA działa dla awarii i jakości tak samo?

Logika dowodowa jest podobna, ale dane, eksperci i narzędzia techniczne będą różne.

Jak sprawdzić skuteczność RCA?

Monitorując wskaźnik powiązany z mechanizmem problemu w odpowiednim okresie i potwierdzając, że warunki przyczynowe zostały usunięte lub kontrolowane.

Porozmawiajmy o wdrożeniu