Zarządzanie kryzysowe dla niewtajemniczonych? Jak bezpiecznie wylądować, gdy pali nam się silnik?

Każda organizacja i każdy klient mają własne wyobrażenie na temat tego, co jest krytyczne, a co nie. Dlatego tak ważne jest poznanie specyfiki danego klienta. Czy jest to lokalny dostawca usług pocztowych, czy światowy gracz na arenie przemysłu wydobywczego? Czy będzie to branża medyczna, szkoleniowa, spożywcza, a może filmowa? Dla każdego indywidualnego przypadku krytyczność i pilność będą znaczyły coś innego. Dopiero zrozumienie konkretnego przypadku biznesu pozwoli nam zrozumieć, co czai się w cieniu pojęcia „kryzys” dla każdego z nich.

Lepiej dmuchać na zimne – przygotuj proces zarządzania kryzysowego, nawet gdyby kryzys miał się nigdy nie wydarzyć

Warto przygotować ten proces i definicję kryzysu trochę na wzór listy kontrolnej w samolocie. Nie ufałabym wiedzy z głowy – zawsze możemy akurat być na urlopie, a kryzys przytrafi się pracownikom pod naszą nieobecność. Nie pozostawiajmy ich w tak stresującej sytuacji bez pomocy i oparcia. Nie wyjeżdżajmy też ze służbowym telefonem i laptopem „na wszelki wypadek” pod palmy. Naszym klientom też nie wyda się to zbyt profesjonalne. Panika nie jest wskazana, natomiast ostrożność, udokumentowana wiedza, zasady i mobilizacja – już tak.

 „A po co mi to?” – zapyta czytelnik. Na wszelki wypadek. Znów nawiążemy do listy kontrolnej w samolocie. Jest procedura na wypadek awaryjnego lądowania? Jest. Czy awaryjne lądowanie zdarza się często? Nie. Co więcej, przemysł lotniczy jest akurat przykładem antykruchości w biznesie. Transparentność, zgłaszanie awarii, dokumentacja, eliminowanie wad – wszystko to dąży do zwiększenia bezpieczeństwa. Uczymy się w ten sposób na błędach i wzmacniamy naszą organizację. Ale procedura awaryjna istnieje cały czas, właśnie na wszelki wypadek. Bo jak już kryzys się wydarzy, to wiemy konkretnie jak postępować.

Od czego więc zacząć? Od priorytetyzacji (czy też triażowania). Jak w szpitalu. Kolory i kody. Jeżeli klient nie ma swojego procesu zarządzania incydentami, a co za tym idzie zarządzania kryzysowego, to konieczne jest stworzenie go razem z nim. Istnieją pewne uniwersalne wskazówki do takiej priorytetyzacji. Zazwyczaj pod uwagę bierze się trzy kryteria, według których zdefiniujemy nasz kryzys, i to kombinacja tych trzech zbuduje nam matrycę priorytetów, czyli tabelę z kolorami, zgodnie z którą wiadomo, ile trzeba będzie posiedzieć na izbie przyjęć w szpitalu zanim obejrzą naszą złamaną nogę.

Pilność (z ang. urgency). Jak szybko potrzebujemy usługi z powrotem? Czy musimy brać pod uwagę jakieś zbliżające się terminy dostaw, naglące umowy biznesowe? Kiedy zaczynają się godziny szczytu dla naszego klienta? Co się stanie, jeśli nie wróci na czas?

Wpływ (z ang. impact). Na co mamy wpływ? W jaki sposób ta przerwa w dostawie danej usługi, cechy czy funkcjonalności odbije się na naszej reputacji czy wiarygodności?

Waga/rozległość (z ang. severity). Kogo konkretnie dotyka ten incydent i w jakim stopniu, których klientów, których pracowników? Jakich funkcji nie mogą przez to wykonywać? Co się stanie, jeśli przerwa będzie długotrwała? Co stracimy? Co przepadnie?

Awarie czy też incydenty – jakiekolwiek przerwy w prawidłowym funkcjonowaniu, czy to w aplikacji, infrastrukturze czy usługach – zdarzają się zawsze. Zanim stwierdzimy, że dana awaria jest krytyczna, że już należy zwołać sztab kryzysowy i obudzić całe kierownictwo wysokiego szczebla w środku nocy, potrzebujemy pewności. Klarownej miary czy też kryterium, według którego zaklasyfikujemy dane zdarzenie. Rozpoczynając prace związane z usunięciem samej awarii oraz potencjalnych jej skutków,musimy przypisać incydentowi czy zdarzeniu odpowiedni priorytet – wagę, pilność, rozległość. Znać długofalowe skutki przerwy w dostawie naszej usługi, a także wynikające z przerwy w jej dostawie kary umowne.

Bardzo wartościowym elementem tworzenia procesu zarządzania kryzysowego jest przejście z klientem i współpracownikami twórczej burzy mózgów – czy wszyscy w ten sam sposób rozumieją ważność i pilność? Czy wszyscy zgadzają się z definicją? Jakie scenariusze należy brać pod uwagę? Czy czegoś istotnego nie pominęliśmy? Im szersze spektrum wiedzy i więcej opinii, tym lepiej stworzona „mapa” działania na przyszłość.

Co da nam wskazówkę, że mowa o poważnej awarii, a co za tym idzie – o czyhającym za rogiem potencjalnym kryzysie? Nie każda awaria najwyższego priorytetu (wysoka zarówno waga, jak i pilność) będzie automatycznie kryzysem. Natomiast jeżeli usługa lub grupa usług, aplikacji czy komponentów infrastruktury jest niedostępna, ale nie mamy pojęcia dlaczego, w związku z czym szacowany czas na jej naprawę jest zupełnie nieznany lub bardzo długi – można mówić o kryzysie. Jeżeli konkretny i dla naszego klienta krytyczny proces lub grupa krytycznych procesów biznesowych jest dotknięta taką awarią, a czas potrzebny na przywrócenie ich pełnej sprawności jest nieznany lub bardzo długi – również.

Co zatem charakteryzuje kryzys?

1. Utrata zdolności do korzystania z kluczowych usług czy systemów już nastąpiła lub jest nieuchronna.
2. Koszty pośrednie i bezpośrednie awarii będą znamienne – zarówno utracone zyski, inne przyszłe korzyści, jak i kary umowne.
3. Reputacja naszego klienta znacznie ucierpi.
4. Wiadomo już, że czas potrzebny do usunięcia awarii jest bardzo długi i już teraz możemy z pewnością stwierdzić, że nie dotrzymamy naszej umowy.

Dlaczego kolory to nie wszystko?

Znajomość specyfiki naszego klienta jest tutaj nieodzowna.

Mieć świadomość, które procesy biznesowe są dla niego najważniejsze. Bez względu na nowe technologie i stosowane rozwiązania pewne rzeczy naprawdę wolno się starzeją. Tutaj bardzo mocno opieramy się na relacjach, ważne jest poznanie klienta – ustalenie na czym dokładnie polega jego biznes, która funkcjonalność jest dla niego niezbędna, a której, mimo że ciekawa i pomocna, jednak używa sporadycznie? Kto i gdzie używa jego aplikacji, gdzie generuje największe przychody? Z pomocą którego procesu, w której lokalizacji, oddziale czy linii biznesowej występują słabe punkty, wrażliwe i kosztowne w naprawie?

Bardzo istotnym elementem jest tutaj również kalendarz – daty, kiedy następują ważne zamknięcia, wyniki roczne czy kwartalne, kampanie i to, w jakiej aplikacji są tworzone i jak przebiegają? Jak rozkłada się ruch sieciowy bądź aplikacyjny przy okazji dni wolnych, świąt, weekendów i akcji typu Black Friday? W zależności od specyfiki i branży mogą one nie być takie same – branża turystyczna czy logistyczna będą miały inne okresy wzmożonej aktywności niż – dajmy na to – branża szkoleniowa czy branża usług kateringowych. Wyobraźcie sobie jak najwięcej przykładów, w których „sezonowość” definiuje dostępność usług i to, jak my możemy w tym pomóc. Będziecie na dobrej drodze.

Niestety, bardzo często zdarzają się sytuacje, w których awarii ulega komponent czy usługa, a rozwścieczony klient zarzuca nam rażącą niekompetencję, straszy karami umownymi i rzuca słuchawką lub wybiega, trzaskając drzwiami. Wtedy po naszej stronie zapada cisza i następuje nieśmiałe pytanie z tyłu sali: „a co to jest i czy my to w ogóle wspieramy”.

Dlatego też dokumenty typu scope of work i service catalog, czyli nasz zakres odpowiedzialności i katalog usług, jakie świadczymy dla klienta, są jednymi z podstawowych dokumentów, o które opierać będziemy skuteczne zarządzanie kryzysowe. Musimy wiedzieć, czego klient używa i w jakim celu, jak ważne jest to w użyciu i jak kosztowne w stracie.

W przypadku wsparcia technicznego infrastruktury informatycznej czy aplikacji musimy wiedzieć, co dla klienta świadczymy i co konkretnie mamy pod opieką – w jakiej wersji, do kiedy wspierane, jakie są ograniczenia. Dobry proces zarządzania incydentami pozwoli osiągnąć następujące korzyści: przywróci usługę najszybciej jak to możliwe, zidentyfikuje osoby niezbędne do naprawienia problemu, zakomunikuje ważne informacje zespołom i kierownictwu, skategoryzuje kroki, by uporządkować plan działania ku naprawie, i rzetelnie udokumentuje awarię.

Tak samo będzie w przypadku programowania czy projektowania. Czasem przejmujemy projekt od kogoś innego (czy będzie to poprzedni dostawca, czy klient przekazujący nam administrację) – aplikację, którą mamy zmodernizować, ulepszyć, poprawić, przemigrować. Prawidłowe i staranne udokumentowanie zakresu usług i odpowiedzialności, inwentarza, priorytetów i kalendarza znacznie usprawnia przygotowanie się do zarządzania kryzysowego w przyszłości.

Sztab kryzysowy

Mogę z pewnością stwierdzić, że udana współpraca z zespołami projektowymi, inżynierami, konsultantami czy kierownictwem, a także życzliwość, transparentność, uważność i komunikacja były kluczowe przy rozwiązywaniu ogromnej liczby kryzysów w moim doświadczeniu zawodowym w obszarze usług IT.

Osoby, z którymi pracujemy na co dzień, to osoby, z którymi przyjdzie nam rozwiązywać kryzysy. Dobre relacje, komunikacja, uznanie pracy, wdzięczność, dodawanie sobie otuchy, poleganie na sobie, dbanie o wzajemny wypoczynek, zastępowanie się w czasie urlopowym i pomoc przy rozwiązywaniu codziennych drobnych problemów mają znaczenie. Brainstorming, klarowne oddzielenie obowiązków, docenienie tego, kogo mamy w grupie, zależności między członkami Scrum Teamu czy Swarming Teamu, skupionego na wymianie doświadczeń jako zespół ekspercki w rozwiązywaniu podobnych pogrupowanych typów incydentów – to wszystko opiera się o relacje.

Musimy być świadomi i mieć poczucie, że siedzimy w tym razem, że nie przerzucamy się odpowiedzialnością, tylko wspólnie działamy jako swego rodzaju Think Tank, jako sztab kryzysowy, w celu jak najszybszego rozwiązania palącego problemu.

Bardzo często zdarza się, że zespoły zaniedbują dokumentację, nie uzupełniają raportów, ponieważ nie widzą wartości dodanej w tej papierologii. Uważam, że zmiana postrzegania procesu i katalogowania tych dokumentów jest kluczowa. Odniesienie do przemysłu lotniczego znów zdaje się być trafne. Wyobraźmy sobie, że zdarza nam się cyklicznie powtarzająca się awaria. Wiemy, co jest przyczyną, ale nie możemy jej trwale usunąć. Albo może wystąpić gdzie indziej, w podobnych, ale nie takich samych okolicznościach. Możemy lepiej się przygotować na jej następne wystąpienie. Dzięki temu, że dobrze ją udokumentujemy i opiszemy objawy, triażowanie i działania diagnostyczne następnym razem znacznie skróci to czas naszej reakcji (albo reakcji naszych kolegów, gdy nas nie będzie akurat w pobliżu). Być może inni pomogą zasugerować klientowi trwałą poprawę, posłużą do uargumentowania powodów, przemawiając za modernizacją? A może skłonią klienta do inwestycji w lepszą i stabilniejszą infrastrukturę czy wybór całkiem innego rozwiązania technologicznego, lepiej trafiającego w jego potrzeby? Same pozytywy!

A jak to wygląda w praktyce?

Spokój i opanowanie są tutaj kluczowe. Pośpiech jest bardzo złym doradcą, łatwo o błąd czy zaniedbanie. Wstępna diagnoza techniczna jest niezbędna, by wspólnie opracować plan dalszych działań. Pracujemy też z naszym klientem ramię w ramię. To zdecydowanie nie jest czas na szukanie winnych, wytykanie palcami, wypominanie sobie błędów czy wyliczanie wcześniejszych niepowodzeń, żalu, pretensji. Na analizę „po” będzie czas później – wtedy określimy kruche newralgiczne punkty, udokumentujemy wyciągnięte wnioski i uodpornimy się na przyszłość. A teraz czas rozwiązać to, co się wydarzyło. Każdego klienta będzie kusiło, żeby próbować wymusić na nas wykonanie czegoś na już, na wczoraj. Ale w tej sytuacji nie uginamy się i nie obiecujemy klientowi niemożliwego tylko po to, by się od nas odczepił. Bardzo często zdarzało mi się rozdzielać sztab kryzysowy na podgrupy: podgrupę techniczną i podgrupę menedżerską. Wynika to z faktu, iż nie każdy człowiek, czy to charakterologicznie czy osobowościowo, jest odporny na stres i nie każdy dobrze znosi konfrontację w warunkach trudnych, pod presją czasu. Łatwo wtedy o błąd, przejęzyczenie, wyłączenie nie tego, co trzeba.

Moją rolą – jako crisis managera – zawsze było zbieranie niezbędnych informacji od inżynierów wsparcia i przekazywanie tych informacji w lżejszej i bardziej przystępnej formie klientowi. Było to również zapewnienie ekipie technicznej (inżynierom, deweloperom, technikom wsparcia) dobrych i komfortowych warunków do pracy, by mogli robić swoje, podczas gdy ja będę udzielać dalszych informacji – trochę na zasadzie „konferencji prasowej” dla naszych zainteresowanych „interesariuszy”. Wspomniane wcześniej zaufanie, życzliwość i serdeczność, które zbudowały nam dobrą trwałą relację w pracy, dobra dokumentacja techniczna, zakres odpowiedzialności i solidna baza wiedzy mają zbawienny wpływ na sprawne usunięcie awarii i zażegnanie kryzysu. Jeśli wiemy dokładnie, który komponent nie działa – technicy się tym zajmą, trzeba im tylko dać czas i narzędzia, a przede wszystkim: zostawić ich w spokoju. Nie wymagać od nich, by z nami, klientem i wszystkimi interesariuszami ślęczeli w sali konferencyjnej, udzielając po raz kolejny odpowiedzi na zagmatwane pytania. Spotkania sztabu kryzysowego powinny być krótkie, rzeczowe, z klarownym planem działania. Bezsensowne jest siedzenie godzinami na otwartej linii telefonicznej. Plan rozpoczynamy od najważniejszych i najpilniejszych zadań, z szacowanym czasem na ich wykonanie, opierając się na tym, co mówią na ten temat inżynierowie. Oni wiedzą dokładnie, ile czasu zabierze przeinstalowanie czegoś, przepięcie, zrestartowanie, odbudowanie, odtworzenie. Oni zdają sobie sprawę z tego, na co pozwala technologia i w jakim czasie. Następnie ustalamy, kiedy spotkamy się ponownie, co powinno już być wtedy wiadomo, i kto jest za to odpowiedzialny. Określamy, które zadania można wykonywać równolegle, a które są od siebie zależne i muszą być potraktowane kaskadowo. Jeżeli sytuacja jest wyjątkowo nerwowa – spotykamy się najpierw w podgrupie technicznej, wspólnie ustalając „update” dla interesariuszy, a następnie crisis manager przedstawia uzgodnione podsumowanie na osobnym, menedżerskim spotkaniu. Warto zostawiać przestrzeń i czas na wykonanie zadań, odpoczynek i podsumowanie zanim popędzimy z najnowszymi wieściami do zniecierpliwionego klienta.

Rola crisis managera, czyli takiego szefa sztabu kryzysowego, to rola bardzo ciekawa. Pełna wyzwań. Potrzebna i bardzo gratyfikująca. Dająca bardzo duże poczucie sensu w pracy, ale też bardzo stresująca. Gdy nic się nie dzieje – wręcz niezauważalna. Zakopana w dokumentach, procedurach, listach kontaktowych, kalendarzach. Widoczna natychmiast, gdy coś się zepsuje. Wymaga nieszablonowego myślenia, opanowania, stanowczości, obiektywności, skutecznej komunikacji, umiejętności negocjacyjnych i zachowania zimnej krwi, czasem wystąpień publicznych. Nie wymaga zaplecza technicznego, a organizacyjnego, logistycznego i sporych umiejętności budowania relacji w biznesie. Dużym atutem jest postawa pokazująca, że dokładnie wiemy, co się dzieje, pracujemy nad tym, panujemy nad sytuacją, a naprawa zajmie tyle a tyle czasu.

Po usunięciu skutków awarii czeka nas zwykle lista kontrolna, tzw. health checks – sprawdzanie, czy aby na pewno wszystko działa tak, jak przed awarią, oraz analiza problemowa źródła naszej awarii. Jeszcze raz warto podkreślić, jak ważna jest prawidłowa dokumentacja, na przyszły, wszelki wypadek. Obyśmy byli organizacją antykruchą i uczyli się na błędach, by w przyszłości, z każdą awarią, było ich kolejnych coraz mniej.