Root Cause Analysis (RCA) to systematyczne podejście do identyfikacji pierwotnych przyczyn problemów występujących w systemach IT i procesach biznesowych. Zamiast usuwać jedynie widoczne objawy awarii, RCA prowadzi zespół w głąb łańcucha przyczynowo-skutkowego, aż do momentu, w którym można wskazać i wyeliminować faktyczne źródło problemu. To rozróżnienie ma znaczenie praktyczne, bo naprawa objawu daje ulgę tylko na chwilę, natomiast usunięcie przyczyny źródłowej pozwala trwale przerwać cykl powtarzających się incydentów.

Warto od razu zaznaczyć, że RCA nie jest pojedynczą procedurą. To pojęcie zbiorcze obejmujące szeroki wachlarz metod, narzędzi i technik analitycznych. Dobór konkretnej techniki zależy od złożoności problemu, ilości dostępnych danych oraz tego, czy mamy do czynienia z prostym łańcuchem przyczyn, czy z siecią wzajemnie powiązanych czynników. Więcej o praktycznej stronie stosowania tej metody piszemy w tekście Pięć zasad RCA? Najpierw zapytaj, czy ktoś je pamięta.

RCA – rozwinięcie skrótu i znaczenie w kontekście IT oraz biznesu

RCA to skrót od Root Cause Analysis, czyli analiza przyczyn źródłowych. W kontekście IT opisuje ustrukturyzowany proces ustalania fundamentalnej przyczyny incydentu, defektu lub awarii po to, by zdarzenie nie wróciło, a nie tylko po to, by przywrócić działanie usługi. W kontekście biznesowym ten sam skrót odnosi się do analizy niezgodności w procesach, reklamacji czy odchyleń jakościowych.

RCA bywa też nazywana metodologią, i to rozróżnienie jest tu praktyczne. Metodologia obejmuje cały przebieg: definicję problemu, zbieranie dowodów, analizę przyczynową, wdrożenie działań korygujących i weryfikację skuteczności. Techniki takie jak 5 Why, diagram Ishikawy czy drzewo błędów są narzędziami stosowanymi wewnątrz tego procesu, a nie jego zamiennikiem. Mylenie jednej techniki z całą metodologią prowadzi do sytuacji, w której zespół kończy analizę na jednej iteracji “Dlaczego?” i uznaje problem za rozwiązany.

Techniki stosowane w Root Cause Analysis

Pod parasolem RCA mieści się kilka uzupełniających się metod. Znajomość ich mocnych stron pozwala dobrać właściwe narzędzie do konkretnej sytuacji, zamiast na siłę stosować jedną technikę do każdego problemu.

• Metoda 5 Why polega na iteracyjnym zadawaniu pytania “Dlaczego?”, zazwyczaj pięć razy, aby przejść od widocznego objawu do przyczyny źródłowej. Sprawdza się przy prostych, liniowych łańcuchach przyczynowo-skutkowych, gdzie liczy się szybkość analizy. Szczegółowy opis znajdziesz w materiale Five Whys and Five Hows – ASQ.
• Diagram Ishikawy (nazywany też diagramem rybiej ości lub Fishbone) wizualnie kategoryzuje potencjalne przyczyny problemu w grupy, na przykład Ludzie, Proces, Technologia i Środowisko. Takie uporządkowanie ułatwia pracę zespołową i zmniejsza ryzyko pominięcia istotnego obszaru. Zasady tworzenia diagramu opisuje What is a Fishbone Diagram? Ishikawa Cause & Effect Diagram – ASQ.
• Analiza drzewa błędów (Fault Tree Analysis) oraz FMEA to podejścia bardziej zaawansowane, przydatne przy złożonych systemach o wielu punktach awarii.
• Analiza Pareto pomaga wskazać te przyczyny, które odpowiadają za największą część problemów, i skoncentrować działania tam, gdzie przyniosą największy efekt.

Pełne omówienie definicji i różnic między metodami dostępne jest w opracowaniach What is Root Cause Analysis (RCA)? – ASQ oraz Root Cause Analysis Explained – Tableau.

Diagram w RCA – kiedy wizualizacja zastępuje tabelę

Diagram wybierasz wtedy, gdy problem ma wiele potencjalnych przyczyn z różnych kategorii albo gdy chcesz pokazać złożone zależności między czynnikami. Fishbone, drzewo błędów i mapa przyczynowa sprawdzają się przy pracy zespołowej, bo każdy widzi, które gałęzie zostały już zbadane. Przy prostym, liniowym łańcuchu przyczyn wystarczy tabela 5 Why z trzema kolumnami: pytanie, odpowiedź, dowód. Taka tabela jest szybsza do wypełnienia i łatwiejsza do powiązania z rekordem w KEDB niż rysunek wymagający osobnego narzędzia graficznego.

Szkolenie z analizy przyczyn źródłowych – czego się nauczysz i kiedy warto

Szkolenie z RCA koncentruje się na praktyce prowadzenia analizy, a nie tylko na definicjach. Typowy zakres obejmuje:

• odróżnianie objawu od przyczyny źródłowej na realnych przykładach incydentów;
• dobór techniki (5 Why, Ishikawa, FTA) do złożoności problemu;
• budowę osi czasu zdarzenia i oddzielanie faktów od hipotez;
• moderowanie sesji zespołowej bez nastawienia na szukanie winnych;
• formułowanie działań korygujących z właścicielem i terminem oraz weryfikację ich skuteczności.

Szkolenie przydaje się zespołom, które prowadzą analizy ad hoc i chcą przejść do powtarzalnego procesu, a także osobom obejmującym rolę koordynatora Problem Management. Jeśli organizacja dopiero zaczyna, sensownie jest przeszkolić najpierw jedną grupę pilotażową i przeprowadzić z nią pierwszą analizę na dobrze udokumentowanym, ograniczonym problemie, zanim metoda trafi do wszystkich zespołów.

RCA w zarządzaniu usługami IT

W zarządzaniu infrastrukturą IT metoda RCA jest kluczowym elementem procesu Problem Management. Pozwala zespołom technicznym zrozumieć, dlaczego wystąpił dany Incident, oraz zapobiec jego powtórzeniu w przyszłości. Ma to szczególne znaczenie w środowiskach o wysokiej dostępności, gdzie każda awaria potrafi generować wymierne straty biznesowe.

W metodyce ITIL 4 wynik analizy przyczyny źródłowej dokumentuje się jako Known Error, czyli znany błąd, i zapisuje w bazie KEDB (Known Error Database). Dzięki temu przy kolejnym wystąpieniu podobnego incydentu zespół dysponuje gotowym obejściem, co skraca czas obsługi zgłoszenia aż do momentu wdrożenia trwałego rozwiązania.

Miejsce RCA w Six Sigma

Root Cause Analysis jest również integralną częścią metodyki Six Sigma. W fazie Analyze cyklu DMAIC stosuje się narzędzia takie jak diagram Ishikawy, metoda 5 Why czy analiza Pareto, aby statystycznie zweryfikować przyczyny źródłowe przed wdrożeniem usprawnień. To podejście łączy jakościową analizę z twardymi danymi, co zwiększa pewność, że działania korygujące trafiają w rzeczywisty problem.

RCA a normy ISO – wymagania dotyczące analizy przyczyn źródłowych

Normy ISO wymagają analizy przyczyn i działań korygujących, lecz nie narzucają konkretnej techniki RCA. ISO 9001:2015 w klauzuli 10.2 “Niezgodność i działanie korygujące” nakazuje ustalić przyczynę niezgodności i wdrożyć działania zapobiegające nawrotom. Trzeba przy tym udokumentować samą niezgodność, analizę przyczyny, podjęte działanie korygujące oraz weryfikację jego skuteczności. Szczegóły normy opisuje ISO 9001:2015 Quality management systems – ISO.org.

ISO/IEC 20000–1:2018, dotycząca zarządzania usługami IT, wymaga identyfikacji przyczyn źródłowych awarii usług i wdrożenia działań ograniczających ich nawroty. Norma wymienia 5 Why, diagramy fishbone i analizę drzewa błędów jako przykładowe techniki strukturalne, ale żadnej z nich nie czyni obowiązkową. W praktyce oznacza to, że audytor sprawdzi, czy przyczyna została udokumentowana i czy działanie zostało zweryfikowane, a nie to, którą techniką się posłużyłeś.

Przebieg analizy krok po kroku

• Dokładne zdefiniowanie problemu i jego wpływu na organizację
• Zebranie danych z logów systemowych, monitoringu i zgłoszeń użytkowników
• Wybór i zastosowanie odpowiedniej techniki analitycznej dopasowanej do złożoności problemu
• Identyfikacja przyczyny źródłowej poprzez konsekwentne eliminowanie objawów
• Opracowanie planu działań naprawczych
• Wdrożenie rozwiązania oraz monitorowanie jego skuteczności w czasie

Najczęściej zadawane pytania

Jak prowadzić analizę RCA krok po kroku?

Zacznij od precyzyjnej definicji problemu z opisem wpływu biznesowego, ustal zakres i zespół, a potem zabezpiecz dowody: logi, rekordy zmian, alerty, historię wdrożeń. Zbuduj oś czasu oddzielającą fakty od założeń, wskaż możliwe przyczyny w kategoriach (ludzie, proces, technologia) i zastosuj wybraną technikę. Każdą przyczynę źródłową potwierdź dowodem, zapisz działanie korygujące z właścicielem i terminem, a analizę zamknij dopiero po monitoringu, który potwierdzi skuteczność zmiany.

Czy RCA jest wymagane przez normy ISO?

Tak, w zakresie działań korygujących. ISO 9001 (klauzula 10.2) wymaga ustalenia przyczyny niezgodności i wdrożenia działań zapobiegających nawrotom, a ISO/IEC 20000–1 wymaga identyfikacji przyczyn źródłowych awarii usług. Żadna z norm nie narzuca jednak konkretnej techniki RCA, sprawdzana jest dokumentacja analizy i weryfikacja skuteczności.

Ile trwa przeprowadzenie analizy RCA?

Prosty incydent IT z izolowaną przyczyną i dostępnymi logami analizujesz w ciągu kilku godzin, a wstępne ustalenia najlepiej spisać w 24–48 godzin od rozwiązania zgłoszenia. Złożone problemy systemowe angażujące wiele zespołów i wymagające korelacji dużych zbiorów danych trwają od kilku tygodni do kilku miesięcy. Czas wydłużają niekompletne dane, rozproszona odpowiedzialność i brak neutralnego moderatora sesji.

Od czego zależy wybór metody RCA?

Decydują cztery czynniki: złożoność problemu i liczba możliwych przyczyn, dostępność oraz jakość danych, liczba zaangażowanych zespołów i systemów, a także czas na analizę. Proste, liniowe awarie obsługuje 5 Why, wiele kategorii przyczyn wymaga diagramu fishbone, a złożone ścieżki techniczne do awarii – drzewa błędów (FTA).

Co to jest KEDB i jak RCA się z nim łączy?

KEDB (Known Error Database) to repozytorium znanych błędów z potwierdzoną przyczyną źródłową i dostępnym obejściem. RCA zasila tę bazę: po zakończeniu analizy wynik trafia do KEDB, a Service Desk stosuje udokumentowane obejście przy kolejnych incydentach bez ponownej analizy. Skraca to czas rozwiązania zgłoszenia do chwili wdrożenia trwałej poprawki. Więcej o bazie znajdziesz w materiale KEDB Explained: Key Insights and Benefits for IT Service Management – InvGate.

Czy RCA stosuje się tylko po awarii?

Nie. Zastosowanie reaktywne odpowiada na pytanie “dlaczego to zdarzenie nastąpiło?” i przeprowadza się je po incydencie. Zastosowanie proaktywne, na przykład FMEA, odpowiada na pytanie “co może pójść nie tak?” i identyfikuje potencjalne tryby awarii przed ich wystąpieniem. Obie metody są komplementarne i razem tworzą kompletny system zarządzania ryzykiem.

Kultura bez szukania winnych

Skuteczność RCA zależy nie tylko od wybranej techniki, ale też od atmosfery, w jakiej prowadzi się analizę. Badania wskazują, że RCA stosowana obiektywnie i bez nastawienia na szukanie winnych prowadzi do trwalszych usprawnień. Organizacje, które traktują analizę jako narzędzie doskonalenia, a nie sposób oceny pracowników, osiągają wyższy wskaźnik skuteczności wdrożonych działań korygujących. Gdy zespół nie obawia się konsekwencji, chętniej dzieli się rzetelnymi informacjami o przebiegu awarii, a to bezpośrednio przekłada się na jakość wniosków.

Praktyczną rolę odgrywa tu moderacja sesji. Neutralny prowadzący pilnuje, by zespół oddzielał fakty od hipotez i nie przyjmował pierwszego wiarygodnego wyjaśnienia za przyczynę źródłową bez potwierdzenia dowodem. Dokumentuj wyniki od razu: oś czasu, zweryfikowaną przyczynę, uzgodnione działania z właścicielem i terminem. Analizę zamykasz dopiero wtedy, gdy monitoring potwierdzi, że wdrożona zmiana zadziałała, a nie w chwili sporządzenia raportu. Te same zasady porządkują przejście od analiz ad hoc do stałego procesu wbudowanego w Problem Management, opartego na standardowych wyzwalaczach, wspólnym szablonie i zdefiniowanych rolach. Przykłady takiego procesu opisuje Problem Management in ITIL – Atlassian.

Korzyści biznesowe

Konsekwentne stosowanie RCA prowadzi do redukcji liczby powtarzających się incydentów, obniżenia kosztów utrzymania systemów oraz poprawy poziomu usług zgodnie z Service Level Agreement (SLA). Organizacje, które włączają RCA w ramy Continual Improvement, osiągają wyższą stabilność operacyjną oraz większe zadowolenie użytkowników, ponieważ raz rozwiązany problem naprawdę przestaje wracać.