Plánování kontinuity činnosti (2)

12. 8. 2009

Sdílet

Existuje šest základních kroků na cestě k vytouženému cíli, kterým je BCP. První krok představuje základní vytyčení mantinelů, což je v daném případě rozsah projektu a projektový plán.

Pokračování včerejšího článku

Začít jde třeba sumarizací prováděných operací a jejich podpůrných ICT služeb. Jde o to definovat jejich přesný rozsah, organizační stránku, časování, vynakládanou práci aj. Výsledkem by kromě jiného měla být přesná informace o rozložení zdrojů a potřeb napříč organizací.

Na tuto úvodní fázi navazuje druhý krok, jehož cílem provedení vyhodnocení vlivu jednotlivých kritických oblastí na chod organizace. Především je zapotřebí kvantifikovat, jak zásadní (technicky, organizačně, provozně, ekonomicky...) dopad může mít jejich výpadek na kontinuitu činnosti (např. dostupnost či kvalita služby).

Třetí krok představuje vývoj strategie obnovy dostupnosti a činnosti. Informace z předchozích kroků se v něm použijí pro kvantifikaci zdrojů, které budou potřebné pro plnou obnovu, tedy jaké jsou požadavky na síť, technologie, zdroje. Podotýkáme, že tato fáze není rozhodovací, ale je pouze přípravná. V ideální situaci by mělo být navrženo několik řešení i s ekonomickým rozpočtem a všemi klady i zápory z toho plynoucími.

Krok číslo čtyři představuje vlastní vývoj plánu obnovy, k němuž dojde na základě předchozí kvantifikace zdrojů stejně jako návrhů řešení. V této fázi vzniká závazná dokumentace pro provedení efektivního záchranného procesu. Tedy kdo bude mít co na starost, jaký bude sled kroků, jaký inventář musí být pro takové situace k dispozici...

Pátý krok představuje implementaci, testování a udržování BCP. Ač to vypadá, že v tuto chvíli by celý proces mohl skončit, nesmí se zapomínat na krok šestý a jak praxe ukazuje, často nejkritičtější - je totiž dlouhodobý. Představuje trvalý dohled a vyhodnocování probíhajících procesů. Jeho obsahem by mělo být kromě měření vytvořeného systému též vyjadřování, jakou hodnotu přináší organizaci.

Pro provedení výše uvedených šesti kroků se používají různé techniky shromažďování informací – od technických prostředků po osobní pohovory. Je zároveň nutné kalkulovat nikoliv pouze s ICT systémy, ale se všemi komoditami, které organizace využívá. Zpravidla jde o osoby, budovy, technické platformy (nejen ve smyslu IT, ale i tradiční), software, datové sítě a vybavení, hlasové sítě a vybavení, důležité záznamy, data, dodavatele...


Kdy je správný čas?

Ač se jednotlivé organizace od sebe více či méně liší, existují určité startovací podmínky, za nichž je iniciována BIA. Typicky jde o tyto situace:

  • Zahájení procesu BCP tam, kde BIA dosud nikdy dříve nebyla provedena.

  • Obnovení procesu BCP tam, kde BIA již byla provedena, ale nyní potřebuje z nějakého důvodu aktualizovat.

  • Provedení BIA v návaznosti na aktuální výraznou změnu situace, která má zásadní dopad na celkové strategie obnovy.

  • Provedení BIA k ověření BCP aktivit, které dosud byly realizovány.

  • Provedení BIA jako „předehry“ k plnému BCP procesu nebo jako nástroj pro management vysvětlující potřebu BCP.


Dalo by se také říci, že celý proces BCP připomíná pohyb v kruhu: analýza – návrh řešení – implementace – testování – údržba – a znovu od začátku. Cykly mohou být dle potřeby delší nebo kratší, zásahy větší nebo menší, ale BCP samo o sobě je nekonečným procesem.


Podpora shora

Již jednou jsme zde zmínili důležitost podpory managementu organizace (v souvislosti s nutností stanovit hodnotu MTD). Tato podpora je přitom důležitá po celou dobu projektu (což není nic nového po sluncem) a měla by se projevit třeba tak, že výsledky BCP budou zaznamenány ve formě dokumentace a že budou odpovídajícím způsobem komunikovány.

Praxe totiž ukazuje, že nedostatečná komunikace může být pro BCP největším problémem. Má za následek špatný výběr metodik obnovy plynoucí z nedostatečných, neúplných nebo nepřesných informací. Na tom pohoří mnoho jinak výtečně zpracovaných BIA – nebo pak vzniká BCP jen proto, aby vznikla, tedy v jistém rozporu s realitou.

bitcoin školení listopad 24

 

Tento text vyšel v tištěném SecurityWorldu 1/2009.