Panie Michale, dziękuję za bardzo ciekawe pytanie. 

Przede wszystkim, dokument BCP (Business Continuity Plan, Plan Ciągłości Biznesu) to rozwiązanie praktyczne. Dlatego lista błędów, grzeszków i niedoskonałości jest dynamiczna. Podobnie jak polityka bezpieczeństwa organizacji, powinien być regularnie aktualizowany, przeglądany i konfrontowany z rzeczywistością. To nie jest jednorazowy wysiłek - aby działał, plan musi uwzględniać incydenty, nowe zagrożenia, ryzyka, musi się rozwijać. Mimo to, faktycznie istnieją błędy najczęstsze, występujące regularnie, które możemy tu przybliżyć. 

1. ITCP nie działa w próżni

ITCP to skrót od angielskiego IT Continuity Plan (Plan Ciągłości Informatycznej) i trzeba pamiętać, że funkcjonuje on w ścisłej relacji do innych planów ciągłości w organizacji. Wewnętrzne IT powinno silnie powiązać swoje rozwiązania z tym, w jaki sposób kontrolowana jest ciągłość procesów biznesowych klienta wewnętrznego. Z kolei zewnętrzny dostawca koniecznie musi mieć na uwadze to samo u swojego odbiorcy. W tym celu przeprowadza się tzw. BIA, czyli Business Impact Analysis (Analiza Wpływu na Biznes). W IT często panuje mylne przekonanie, że analiza ryzyka i zagrożeń dla ciągłości powinna mieć charakter wewnętrzny, powinna odpowiadać na pytanie "Jakie ryzyko grozi mojej infrastrukturze, zasobom, konfiguracji i usługom?", gdy tymczasem jest inaczej. Poprawne pytanie BIA brzmi: "Jak ryzyka grożące mojej infrastrukturze, zasobom, konfiguracji i usługom wpływają na procesy biznesowe klienta?". 

Tak, to niuans, ale niuans o krytycznym znaczeniu. Na koniec dnia, jako dostawcy usług informatycznych, jesteśmy odpowiedzialni za wartość tych usług, za rezultat, jaki dostarczają odbiorcy biznesowemu. Nadając ten kontekst BIA osiągamy precyzyjniejszą ocenę ryzyk, większą korelację z celami biznesowymi i przede wszystkim efektywniejsze zapewnienie ciągłości. 

2. Papier kontra rzeczywistość

Nie ma nic złego w korzystaniu w doświadczeń czy predefiniowanych zestawów ryzyk w projektowaniu BCP. Tym bardziej, że konfiguracja usługi informatycznej składa się z całkiem dobrze poznanych i opisanych komponentów - element ludzki generuje ograniczoną liczbę ryzyk, podobnie konkretny sprzęt informatyczny czy inne rozwiązania. Często rozwiązania sprzętowe i software'owe mają listy ryzyk dostarczone przez producenta, więc możemy spokojnie używać ich w planowaniu dostępności i ciągłości. 

Problem pojawia się wtedy, kiedy te predefiniowane ryzyka nie są konfrontowane ze specyficzną architekturą, z kontekstem konkretnej usługi. Prawdopodobieństwo wystąpienia oraz lista zagrożeń każdego konkretnego ryzyka MUSI być osadzona w specyficznej sytuacji. Jeśli nie zadajemy sobie pytań, nierzadko niewygodnych pytań, o rzeczywiste konsekwencje ryzyk, BCP staje się wydmuszką - dokumentem wyglądającym profesjonalnie, ale jego praktyczna aplikacja jest ograniczona. Należy to powiedzieć otwarcie i dosadnie - najlepsze praktyki rekomendują BCP, jako dokument praktyczny, realistyczny, wbrew temu, że często używany jest, jako rozwiązanie fasadowe, wizytówka dojrzałości i nic więcej. To, jak można się domyślić, nie jest najlepsza praktyka. 

3. Ryzyko to nie wszystko

Praktyczna efektywność BCP zależy nie tylko od listy ryzyk, ale - być może przede wszystkim - od listy zagrożeń. Ryzyka można złożyć w macierz, w której jedną oś wyznacza Wpływ na Biznes, a drugą Prawdopodobieństwo wystąpienia. W ten sposób możemy zaliczyć część z nich do ryzyk akceptowalnych, oraz oznaczyć grupę tych absolutnie wymagających zaplanowania konkretnych rozwiązań ciągłościowych i odtworzeniowych. 

Ale to dopiero pierwszy krok. Każde ryzyko należy opatrzyć listą zagrożeń. Zagrożenia są kluczem do praktyczności BCP. To lista potencjalnych agentów ryzyka, przyczyn materializacji ryzyka. 





Powyższe zestawienie jest przykładem z publikacji Service Design. Powinno być inspiracją do pracy nad konkretnym BCP. 

4. Plan jest po to, by go wykonać

Odpowiedzialnością twórców BCP jest również odpowiednia implementacja rozwiązań i - przede wszystkim - skuteczna komunikacja. Plan jest tylko tak dobry, jak ludzie, którzy go wykonują. Można mieć znakomitą analizę ryzyka, świetne zestawy zagrożeń, precyzyjnie przewidziane prawdopodobieństwa i skrupulatnie wykonane BIA, ale jeśli faktyczni operatorzy infrastruktury nie stosują się do BCP, mamy znów do czynienia z wydmuszką, dokumentem fasadowym. Należy się upewnić, że konkretne działania w ramach planu ciągłości znajdują swoje odzwierciedlenie w instrukcjach roboczych, opisach stanowisk, zadaniach, check-listach i wszystkich innych dokumentach wykonawczych, a ponad to upewnić się, że te dokumenty są faktycznie egzekwowane w organizacji. 

5. Gdzie BCP tam DRP

Warto wzbogacić swoje plany i działania ciągłościowe o tak zwany DRP, Disaster Recovery Plan (Plan Odtworzenia Pokryzysowego). BCP w swej podstawowej formie to odpowiedź na pytanie "Co zrobić, kiedy zmaterializuje się przewidziane ryzyko?", podczas gdy DRP odpowiada na pytanie "Jak wrócić do nominalnego stanu usługi?". Zatem, o ile BCP dostarcza nam predefiniowane działania do zapewnienia ciągłości, DRP poinformuje nas jak wrócić do stanu oryginalnego, co naprawiać, w jakiej kolejności, z jakich dostawców skorzystać oraz jak się komunikować w sytuacji kryzysowej. Dobrze napisany DRP pozwoli efektywnie i sprawnie przywrócić status usługi, uniknąć paniki i decyzji podejmowanych w pośpiechu. 

...

Powyższa lista absolutnie nie wyczerpuje błędów, jakie zdarzają się podczas pisania Business Continuity Plan, ale ma stanowić swoistą inspirację, czy przestrogę. To wszystko sprowadza się i tak do jednego zalecenia, jednej rekomendacji - Plan Ciągłości Biznesu jest dokumentem praktycznym. Jego siła tkwi w realnych rozwiązaniach, adekwatnych do sytuacji. Należy unikać ogólników, postawić na precyzję i wykonalność. I pamiętać, że każdy plan jest tylko tak dobry jak ludzie, którzy go wykonują - BCP musi znaleźć swoje odzwierciedlenie w instrukcjach roboczych, procedurach i opisach stanowisk. I przestrzeganie tych dokumentów musi być egzekwowane. Inaczej kończymy z fasadowym dokumentem - ładnym, profesjonalnym, ale zupełnie niepraktycznym.