W większości małych i średnich firm „plan na sytuacje awaryjne" istnieje w głowie jednej osoby. To zwykle ten sam informatyk, który zna każdy serwer po nazwie, ma w komórce numer do dostawcy łącza i pamięta, gdzie leży klucz do szafy serwerowej. Dopóki ten człowiek odbiera telefon, wszystko działa. W chwili, w której nie odbiera — firma nagle ma bardzo poważny problem.
Nie chodzi o paranoję, tylko o czysty rachunek prawdopodobieństwa. W ciągu dwóch lat każda firma trafi na coś z listy: padnie serwer, zerwie się światłowód, zachoruje kluczowa osoba, ransomware wejdzie do sieci, zniknie prąd na sześć godzin. To nie są scenariusze z filmu. To są wtorki w MŚP.
Plan ciągłości działania (BCP) brzmi korporacyjnie. Tak nie musi wyglądać.
Plan ciągłości to nie 200-stronicowy raport
Niektóre firmy konsultingowe sprzedają „opracowanie BCP" jako wielomiesięczny projekt z wagonem dokumentów. Większość MŚP nie potrzebuje niczego takiego. Potrzebuje jednej kartki A4, na której są trzy rzeczy:
- co robimy, gdy padnie X,
- kto dzwoni do kogo i w jakiej kolejności,
- gdzie leżą hasła, klucze i kontakty potrzebne, żeby zacząć.
Ta kartka leży wydrukowana w kilku miejscach — recepcja, sejf, mieszkanie prezesa — bo jeśli padnie sieć, dostęp do pliku na SharePoincie też pada. Ten szczegół brzmi banalnie, dopóki nie próbujesz odzyskać hasła z menedżera haseł, którego nie da się otworzyć bez internetu.
Pięć scenariuszy, na które trzeba mieć odpowiedź
Nie musisz wymyślać wszystkich możliwych awarii. Wystarczy, że masz spisaną odpowiedź na pięć:
- Brak internetu w biurze. Czy mamy zapasowe łącze (LTE, druga linia od innego operatora)? Kto je podłącza? Jak długo wytrzymamy bez sieci, zanim klienci zaczną dzwonić ze złością?
- Padł kluczowy serwer. Gdzie jest dokumentacja sprzętu? Kto ma aktualny kontakt do dostawcy serwera i licencji? Jakie funkcje da się tymczasowo przepiąć na chmurę albo drugą maszynę?
- Ransomware lub poważny incydent bezpieczeństwa. Kogo zawiadamiamy w pierwszej godzinie (CSIRT, ubezpieczyciel, prawnik, klienci związani umowami)? Co odpinamy od sieci natychmiast? Skąd odtwarzamy?
- Kluczowa osoba IT niedostępna przez tydzień. Czy ktokolwiek inny w firmie wie, gdzie leżą hasła do ERP-a, hostingu i domeny? Czy informatyk ma realnego, przeszkolonego zastępcę?
- Awaria prądu albo fizyczna szkoda w biurze (pożar, zalanie, ewakuacja). Czy zespół może pracować zdalnie z marszu? Czy w ogóle ma laptopy i dostęp z domu? Czy ktoś niedawno przetestował, że VPN z zewnątrz naprawdę działa?
Każda z tych pięciu sytuacji wydarza się statystycznie częściej, niż się chce wierzyć. Plan dla każdej z nich powinien zmieścić się w kilku zdaniach.
U jednego z naszych klientów — 35-osobowej hurtowni części przemysłowych spod Poznania — w piątek po południu padł kontroler RAID w serwerze, na którym chodził Comarch Optima i system magazynowy. Główny informatyk był na weselu i nie odbierał telefonu. Nikt inny w firmie nie wiedział, gdzie leżą backupy, kto ma kontakt do dostawcy serwera ani czy w ogóle istnieje plan B. W poniedziałek rano firma wciąż była offline; odbudowa zajęła cztery dni robocze i kosztowała w przybliżeniu 80 000 zł w opóźnionych wysyłkach i karach umownych z dwoma większymi klientami. Jednostronicowy plan — kto dzwoni, do kogo, w jakiej kolejności, z jakimi numerami pod ręką — skróciłby ten przestój do kilku godzin.
Jednostronicowy plan — co zawiera
Konkretnie, na tej jednej kartce powinno się znaleźć:
- Krytyczne systemy — wymienione z nazwy: ERP (Comarch Optima, enova365, Subiekt), poczta, kasy fiskalne, system magazynowy, kontrolery dostępu. Bez listy nie wiadomo, co ratujemy najpierw.
- Kontakty awaryjne — nazwisko, telefon komórkowy, rola. Dostawca internetu, dostawca ERP, firma serwisująca serwery, informatyk i jego zastępca, biuro rachunkowe, prawnik, ubezpieczyciel. Bez numerów stacjonarnych jako jedynego kanału — w piątek o 17:00 nikt ich nie odbierze.
- Lokalizacje haseł i kluczy — nie same hasła (te są w menedżerze), ale „gdzie szukać": który menedżer, kto ma master password, gdzie jest klucz fizyczny od szafy serwerowej, kto zna PIN do alarmu po godzinach.
- Krótki runbook na trzy najczęstsze scenariusze — w formie „jeśli X, to zrób Y". Trzy do pięciu kroków, nie podręcznik. Cel: żeby księgowa z pięcioletnim stażem była w stanie wykonać pierwsze trzy ruchy bez dzwonienia do nikogo.
- Kto ma uprawnienia do podejmowania decyzji finansowych w kryzysie — np. zatwierdzenia wezwania pogotowia serwerowego w niedzielę za 8 000 zł albo zakupu zastępczego sprzętu na karcie firmowej.
To wszystko. Jedna strona A4, druk dwustronny — w MŚP zwykle wystarczy.
Symulacja „co jeśli zniknie..."
Plan, który nigdy nie został przetestowany, jest takim samym mitem jak backup, którego nikt nie odtworzył. Raz na pół roku warto zrobić w firmie krótkie ćwiczenie na sucho.
Wybierz scenariusz. Na przykład: „przez najbliższe dwie godziny udajemy, że nie działa nam internet i serwer ERP". Wyłącz fizycznie router (albo umownie ogłoś, że jest wyłączony — chodzi o symulację, nie o paraliżowanie firmy). Patrz, co dzieje się w zespole. Kto wie, co robić? Kto biegnie zapytać szefa? Czy ktoś sięga po wydrukowany plan, czy szuka go po dyskach?
Po dwóch godzinach zbierz zespół na piętnaście minut i spisz: co zadziałało, co nie, gdzie był chaos, czego brakowało w planie. Popraw kartkę. Powtórz za pół roku z innym scenariuszem.
To nie kosztuje nic poza dwiema godzinami dwa razy w roku. Większość firm, które robią to regularnie, w realnym kryzysie traci godziny zamiast dni.
Co dalej
Jeśli w Twojej firmie nie ma takiej kartki — nie panikuj, ale potraktuj to jako sygnał. Zacznij od dwudziestu minut z notesem: kto dzwoni do kogo, gdzie są hasła, co robimy, gdy padnie ERP. Resztę można dopisać później. Najważniejsze, żeby ktokolwiek poza jedną osobą wiedział, gdzie ten dokument w ogóle szukać.
Jeśli nie wiesz, od czego zacząć w realiach swojej firmy — pomagamy MŚP rozłożyć to na dwie–trzy rozmowy po pół godziny. Bez 200-stronicowego raportu na końcu. Pierwsza rozmowa jest bezpłatna.
Plan ciągłości działania to nie dokument na półkę. To kartka, którą da się przeczytać o trzeciej w nocy, gdy serwer właśnie padł.