Od golfu k certifikaci BCMS – L.Široký (článok)

Výber z článku publikovaného v časopise DSM (3/2010):

“I certifikace může mít zajímavou historii. V případě BCMS nebylo úplně snadné se jí dopátrat a poskládat celou mozaiku událostí dohromady.

dsmŘízení kontinuity činností organizace (BCM), jak je chápáno dnes, vyplynulo z požadavků na zajištění obnovy informačních systémů po haváriích sálových počítačů. Tradičně se havarijní plánování (disaster recovery planning, DRP) soustřeďovalo na obnovu technického vybavení po větším incidentu. Než se původní koncept DRP přerodil v dnešní „certifikovatelný“ systém řízení kontinuity činností (BCMS), uběhlo téměř 40 let.

Havarijní plán č. 1

Myšlenka na vytvoření formalizovaných pravidel a postupů řízené eskalace incidentů se zrodila jednoho nedělního odpoledne během hry golfu, psala se druhá polovina 70. let. Tím vášnivým hráčem golfu byl Norman Harris, viceprezident odpovědný za zpracování dat v Bank of Ohio. V dobách hromadného zpracování dat prostřednictvím děrných štítků znamenala jakákoli drobná či větší závada sálového počítače obvykle narušení práce v celé bance. Bez ohledu na denní nebo noční dobu, bez jakéhokoli pokusu o předběžné posouzení závažnosti a rozsahu incidentu byl svými podřízenými ihned, a zpravidla i zbytečně, kontaktován Norman Harris. V dobách bez mobilních telefonů obnášelo vyřízení hovoru cestu do klubovny a zpět na odpaliště jamky č. 13, a to ještě v tom lepším případě. Potřeba vytvořit a formalizovat postupy hlášení a zvládání ICT incidentů se tak zrodila z nutnosti eliminovat plané poplachy – byl vytvořen první plán obnovy po havárii (disaster recovery plan, DRP).

Potíže hned v prvním kole

Od počátku se první tvůrci DRP potýkali s tím, jak přesvědčit vedení svých společností, aby schválila nemalé investice do tvorby havarijních plánů a přípravy záložních lokalit. Zejména, když se jednalo o přípravu na závažné události a havárie, které s velkou pravděpodobností nikdy ani nenastanou. Investice do DRP bylo nutné zdůvodnit a před majiteli obhájit. To vedlo k vytvoření technik pro hodnocení potenciálních dopadů negativních událostí na celkové fungování společnosti. První metodiky analýz obchodních dopadů (business impact analysis, BIA) vznikaly ve Spojených státech v první polovině 80. let, a jsou tak o několik let starší než samotný koncept řízení kontinuity činností. Je důležité, že hned od začátku byla podchycena klíčová podstata implementace BCM. A to potřeba identifikovat důležité procesy, odhadnout následky jejich přerušení a na tomto základě navrhnout cenově efektivní strategie obnovy informačních technologií. Dnes je BIA neoddělitelnou, ale hlavně klíčovou součástí životního cyklu BCM.

Zrození BCM(S)

Počátky dnešního BCM(S) jsou datovány do poloviny 80. let. O rozšíření původního, čistě technicky zaměřeného konceptu se zasloužil jiný z pionýrů havarijního plánování. Vpravdě lidský rozměr dal původnímu DRP dnes již více než osmdesátiletý Ron Ginn (jeden z původních zakladatelů britského Business Continuity Institute). Jako první si totiž uvědomil, že obnova funkčnosti technologií ještě neznamená automatickou obnovou fungování celé společnosti. Podle vytvořených a otestovaných DRP nebyl problém obnovit funkčnost sálových počítačů, včetně obnovy dat ze záloh, v záložní lokalitě. Nikdo však již neuvažoval nad tím, že bude nutné do záložní lokality přemístit zaměstnance, vytvořit jim vhodné podmínky pro práci. Nastavit postupy pro informování zaměstnanců o nastalé události a jejich pracovní náplni v následujících hodinách a dnech po havárii. Určit způsob a vymezit rozsah informací podávaných zákazníkům a médiím. Předem promyslet a zahrnout do plánů další aspekty související se zajištěním kontinuity a obnovy podnikání. To vše původní koncept plánování po havárii zcela opomíjel. A tak přichází na scénu BCM, na který je o několik let později aplikován systémový přístup k řízení kontinuity založený na cyklu PDCA (Plánuj – Dělej – Kontroluj – Jednej, Plan – Do – Check – Act).

Od obnovy ke kontinuitě

Byl to také Ron Ginn, kdo v roce 1985 takto rozšířený koncept původního DRP pojmenoval jako řízení kontinuity činností (BCM). Dodnes s nadsázkou rád říká, že si měl tehdy nechat spojení „business continuity“ patentovat. V novém světle bylo ICT nutno chápat jako jeden ze zdrojů, které podporují fungování procesů a činností společnosti. Přičemž ale původní postupy a techniky DRP nebyly zatraceny, ale naopak nově aplikovány na mnohem širší okruh procesů a podpůrných činností. Dnes jsou DRP chápány jako podmnožina BCP (plány kontinuity činností) zaměřená na obnovu ICT zdrojů po incidentu nebo havárii. Přičemž BCP obsahují postupy a kroky pro zajištění kontinuity (přechodné období) a následné obnovy (návrt k normálu) procesů a činností. Dalším logickým krokem ve vývoji BCM byl posun od pouhé obnovy, kdy se pouze vyčkává, až se něco stane, a teprve pak se začíná jednat, ke kontinuitě, kdy jsou dopředu promýšleny kroky obnovy. Nadto jsou zde připraveny alternativní způsoby fungování v době výpadku. Kde to jde, řeší se prevence a je snaha se hrozbám vyhnout či alespoň pravděpodobnost jejich úspěchu minimalizovat (zejména proto je součástí programu BCM také řízení rizik). Namísto pasivního vyčkávání organizace aktivně řídí kontinuitu svého podnikání. Přesto trvalo ještě řadu let, než se tento rozšířený koncept ujal. Ještě dnes je BCM v řadě společností chápáno jako aktivita spadající čistě do působnosti IT oddělení.

Závěr

Přestože neexistuje žádná oficiální statistika, jako je tomu např. u certifikací ISMS, uvádějí různé neoficiální zdroje až 100 certifikací BCMS po celém světě. Česká republika ale na svoji první certifikaci ještě stále čeká. Prvotní impuls získat certifikát BCMS přichází zpravidla ze strany vlastníků, zejména pokud se jedná o společnosti se zahraniční majetkovou účastí. Stále častěji se také objevuje požadavek ze strany potenciálních zákazníků (opět zejména těch ze zahraničí), kteří vyžadují určité záruky, že společnost bude schopna dostát smluveným závazkům.”

ukážka:

01. novembra 2010 by Martin Kašša
Categories: Zo sveta | Tags: , , , , | Leave a comment

Leave a Reply

Required fields are marked *