Awaria się zdarzyła. Dostawca coś naprawił, ludzie wrócili do pracy, wszyscy odetchnęli. Za trzy tygodnie ten sam scenariusz — inna maska, ten sam błąd. Tego się da uniknąć, ale tylko wtedy, gdy między jednym pożarem a drugim znajdzie się godzina na coś, co w korpo nazywają post-mortem, a w MŚP zwykle nie nazywa się nijak.
W dużej firmie postmortem to sformalizowana procedura z szablonem, moderatorem i biletem w Jirze. W dziesięcio- czy trzydziestoosobowej firmie ten sam efekt można uzyskać przy jednym stole, na jednej kartce, w godzinę. Nie chodzi o dokumentację. Chodzi o to, żeby ten sam kabel nie wyleciał drugi raz w tym samym miesiącu.
Dlaczego w MŚP to nie działa domyślnie
W MŚP awaria zwykle kończy się tak: informatyk (albo dostawca) mówi „to był RAID/dysk/UPS/prąd", odhacza zgłoszenie i wraca do swoich rzeczy. Nikt nie pyta, dlaczego nikt nie zauważył wcześniej, że dysk sypie błędy od tygodnia. Nikt nie sprawdza, dlaczego backup, który miał uratować sytuację, okazał się sprzed 11 dni. Rozmowa jest krótka, bo długa rozmowa oznacza szukanie winnych — a tego wszyscy chcą uniknąć.
I to jest właśnie ta pułapka. Jeśli postmortem służy do przypisania winy, nikt nie powie prawdy, i za miesiąc dostaniesz tę samą awarię z innej strony. Jeśli postmortem służy do naprawy procesu, ludzie mówią, co widzieli — bo wiedzą, że nikt ich za to nie zwolni.
Konkretny przykład — 12-osobowe biuro projektowe
W jednym z projektów widzieliśmy taki scenariusz. 12-osobowe biuro projektowe (branża instalacji elektrycznych), serwer plików w szafce w recepcji, ERP Comarch Optima w chmurze partnera. W poniedziałek rano nikt nie może otworzyć rysunków — dysk NAS trzasnął w weekend, kontroler RAID poszedł razem z nim, część projektów z ostatnich trzech dni przepadła.
Dostawca IT przyjechał, wymienił NAS, przywrócił dane z backupu sprzed 4 dni. Straty: 22 godziny pracy dwóch projektantów odtwarzających schematy, jeden termin przesunięty o tydzień, klient rozmawiał z prezesem tonem, którego ten wolałby więcej nie słuchać. Koszt materialny — łatwo policzalny — około 6 500 zł. Koszt reputacyjny — nikt nie liczył.
Zamiast zamknąć temat, zrobiliśmy godzinny postmortem. Wyszło z niego pięć rzeczy:
- Alerty S.M.A.R.T. z dysku szły na skrzynkę informatyka, który był tydzień na urlopie. Nikt inny ich nie widział.
- Backup działał codziennie, ale kopiował się na drugą partycję tego samego NAS-a — kiedy padł kontroler, poszedł też backup.
- Kopia offsite robiła się raz w tygodniu, w piątek wieczorem. W piątek do 15:00 przybyło 4 dni pracy, których już nikt nigdy nie odzyska.
- Nikt nie wiedział, że NAS ma 6 lat. Nie było żadnego rejestru sprzętu z datami zakupu.
- „Plan awaryjny" istniał w głowie informatyka. Kiedy go zabrakło, nikt nie wiedział nawet, gdzie leży klucz do szafki serwerowej.
Żadna z tych rzeczy nie wymagała nowego budżetu. Wymagała pół dnia porządków. Rok później, przy podobnym „trzasku" (tym razem SSD w drugim serwerze), przywrócenie zajęło 90 minut z backupu offsite z poprzedniej nocy. Awaria się powtórzyła — ale konsekwencje już nie.
Godzinny szablon, który działa
Nie potrzebujesz narzędzia. Kartka A4, długopis, jedna godzina, wszyscy, którzy w awarii cokolwiek robili (dostawca IT też, nawet zdalnie). Cztery bloki:
Timeline — co się działo, po kolejce. Nie „co ktoś sądzi, że się działo", tylko co zobaczyliśmy: godzina pierwszego zgłoszenia od użytkownika, godzina pierwszej reakcji IT, godzina uruchomienia, godzina pełnego powrotu. Suche liczby. Zwykle sam ten blok pokazuje, że „awaria trwała 2 godziny" to fikcja — użytkownicy nie pracowali od 8:00, ale zgłoszenie poszło o 10:15, a IT dowiedziało się o 11:30.
Impact — co realnie zabrała. Ile godzin pracy? Ile transakcji nie doszło? Ile telefonów od klientów? Jaki termin się przesunął? Bez tego nikt nie będzie chciał wydać nawet 500 zł na profilaktykę, bo „przecież nic się nie stało".
Root cause — dlaczego, pięć razy pod rząd. Klasyczne „5 whys". Dlaczego padł NAS? — Bo kontroler się przegrzał. — Dlaczego się przegrzał? — Bo wentylator nie działał. — Dlaczego nie działał? — Bo od pół roku był zapchany kurzem. — Dlaczego nikt nie sprzątał? — Bo nikt nie ma tego w kalendarzu. — Dlaczego? — Bo nie mamy żadnego harmonogramu przeglądów sprzętu. I nagle wiadomo, co naprawdę naprawić — nie kontroler, tylko brak harmonogramu.
Action items — kto, co, do kiedy. Maks 5 rzeczy. Każda z nazwiskiem i datą. Bez tego postmortem jest terapią grupową, nie zmianą.
Co odróżnia postmortem od szukania winnych
Jedna zasada, którą warto powiedzieć głośno na początku spotkania: „Zakładamy, że każdy zrobił najlepiej, jak umiał, mając wiedzę, którą wtedy miał." Brzmi łopatologicznie, ale bez tego nikt nie powie, że rok temu wyłączył alerty z NAS-a, bo za dużo spamował. A to jest właśnie ta informacja, dla której robimy postmortem.
Winny nie naprawia procesu. Winny odchodzi z firmy albo zaczyna kłamać. Ani jedno, ani drugie ci nie pomoże. Postmortem szuka luki w systemie, nie luki w człowieku. Ludzie zwykle popełniają błędy w tych samych miejscach — jeśli w twoim procesie da się popełnić kosztowny błąd bez sieci bezpieczeństwa, to jest problem procesu.
Kiedy robić, a kiedy odpuścić
Nie każda awaria zasługuje na godzinę spotkania. Warto trzymać się prostej granicy: postmortem robimy, jeśli awaria trwała ponad godzinę, dotknęła więcej niż jednej osoby albo kosztowała pieniądze (utracone godziny pracy, przesunięty termin, telefon od klienta). Poniżej — wpis w prostym logu (data, co, jak długo, kto naprawił) wystarczy.
Log z ostatnich 12 miesięcy jest zaskakująco pouczający sam w sobie. Kiedy nagle widzisz, że przez rok mieliście siedem drobnych awarii związanych z tym samym przełącznikiem sieciowym, żaden dostawca nie musi ci już mówić, że pora go wymienić.
Co dalej
Postmortem nie kosztuje pieniędzy. Kosztuje godzinę dyscypliny raz na kwartał albo raz na dłuższą awarię. Zwraca się jednym uniknionym powtórzeniem — a w praktyce zwykle znacznie więcej.
Jeśli w twojej firmie po ostatniej awarii nikt nie usiadł do stołu i nie zapytał „dlaczego to w ogóle było możliwe?" — to jest dokładnie to miejsce, w którym warto zacząć. Możemy pomóc rozłożyć konkretny incydent na czynniki pierwsze i zbudować szablon, który zostanie u ciebie na stałe.
Awaria to nie porażka. Powtórzona awaria — już tak.