Dlaczego szukanie winnego po awarii to błąd wart miliony

W kulturze organizacyjnej wielu firm IT instynkt obwiniania jednostek za błędy systemowe zastępuje realne rozwiązywanie problemów, co prowadzi do zjawiska „unikania winy” (blame-avoidance) zamiast wdrażania poprawek. Dla Senior IT Architecta i specjalisty ds. Security kluczowe jest zrozumienie, że zatrzymanie analizy na „winie człowieka” blokuje naukę i uniemożliwia identyfikację faktycznych luk w architekturze lub procesach automatyzacji.

Instynkt obwiniania jako blokada innowacji

Instynkt obwiniania to naturalna tendencja do szukania prostej przyczyny negatywnych zdarzeń w działaniu konkretnej osoby. W organizacjach przepływ winy z góry na dół jest sygnałem porażki strukturalnej; w tzw. „kulturze obwiniania” pracownicy boją się zgłaszać incydenty z obawy przed utratą pracy, co ukrywa długoterminowe wskaźniki zagrożeń dla bezpieczeństwa.

Przykładem skuteczności systemowej nad indywidualną jest przypadek firmy Rivopharm, która dzięki zaawansowanej automatyzacji i robotyce była w stanie produkować leki taniej niż koszt surowców u konkurencji. To nie „heroizm” menedżerów, ale projekt systemu i technologia (robotyka, szybkie maszyny) stały za tym sukcesem. W IT analogicznie — to nie „uważny administrator”, ale szczelna architektura i automatyzacja procesów decydują o odporności systemu.

Fikcja indywidualnej odpowiedzialności w złożonych systemach

Wiele instytucji promuje narrację o „dyscyplinie” i „odporności” jednostek, ignorując wady projektowe samych systemów. W strukturach biznesowych często występuje asymetria: na szczycie hierarchii porażki są traktowane jako systemowe, podczas gdy na dole jako personalne. Z perspektywy etyki, obwinianie kogoś bez posiadania uzasadnionych dowodów (reasonable belief) jest nie tylko niesprawiedliwe, ale świadczy o niewystarczającej dbałości o znalezienie faktycznego winowajcy.

Wysoko niezawodne organizacje (High Reliability Organizations) odchodzą od tego modelu, wiedząc, że obwinianie pilota za katastrofę nie zapobiegnie kolejnym wypadkom, jeśli nie zapytamy, dlaczego system dopuścił do powstania błędu. Zamiast „bić po twarzy” (punching faces) zarządy czy deweloperów, należy skupić się na wielu interakcyjnych przyczynach tworzących dany system.

Wnioski praktyczne: Architektura bez winy

Zamiast szukać kozła ofiarnego po incydencie security, profesjonalista IT powinien wdrożyć następujące zasady oparte na danych:

1. Analiza systemowa zamiast personalnej: Akceptuj, że złe rzeczy dzieją się bez złych intencji — szukaj luk w procesach, a nie „złych ludzi”.
2. Promowanie raportowania bez lęku: Buduj zaufanie, aby pracownicy zgłaszali błędy wcześnie; strach przed prokuraturą czy bezrobociem sprawia, że drobne problemy eskalują w niekontrolowane kryzysy.
3. Inwestycja w automatyzację ( heroes of system): Sukces w IT to wynik sprawnych instytucji i technologii, a nie pojedynczych liderów. Szukaj systemowych „bezpieczników”, takich jak czujniki w drzwiach wind, które działają niezależnie od błędu użytkownika.
4. Zasada 80/20 w budżecie security: Skup się na zrozumieniu największych pozycji w budżecie i logach, które odpowiadają za 80% ryzyka, zamiast rozpraszać energię na drobne, rzadkie incydenty.

Prawdziwa zmiana świata IT i bezpieczeństwa wymaga porzucenia „gry w obwinianie” na rzecz chłodnej analizy danych i struktury systemów.