Sveiki visi, mano vardas Igoris Tyukačiovas ir aš esu verslo tęstinumo konsultantas. Šiandienos įraše turėsime ilgą ir varginantį bendrų tiesų aptarimą.Noriu pasidalinti savo patirtimi ir pakalbėti apie pagrindines klaidas, kurias daro įmonės, rengdamos veiklos tęstinumo planą.
1. RTO ir RPO atsitiktinai
Svarbiausia klaida, kurią mačiau, yra ta, kad atkūrimo laikas (RTO) yra paimtas iš oro. Na, iš oro – pavyzdžiui, yra keletas prieš dvejų metų skaičiuojamų SLA, kuriuos kažkas atsinešė iš ankstesnės darbovietės. Kodėl jie tai daro? Juk pagal visus metodus pirmiausia reikia išanalizuoti pasekmes verslo procesams ir pagal šią analizę apskaičiuoti tikslinį atkūrimo laiką bei priimtiną duomenų praradimą. Bet tokios analizės atlikimas kartais užtrunka ilgai, kartais brangiai kainuoja, kartais nelabai aišku kaip – pabrėžti, ką reikia padaryti. Ir pirmas dalykas, kuris daugeliui ateina į galvą, yra: „Mes visi esame suaugę ir suprantame, kaip veikia verslas. Negaiškime laiko ir pinigų! Paimkime pliusą ar minusą taip, kaip turėtų būti. Iš galvos, pasitelkite proletarišką išradingumą! Tegul RTO trunka dvi valandas.
Prie ko tai veda? Kai ateini į vadovybę dėl pinigų veiklai užtikrinti reikiamą RTO/RPO su tam tikrais skaičiais, tai visada reikalauja pagrįstumo. Jei pateisinimo nėra, tada kyla klausimas: iš kur tai gavai? Ir nėra ką atsakyti. Dėl to prarandamas pasitikėjimas savo darbu.
Be to, kartais tos dvi sveikimo valandos kainuoja milijoną dolerių. O pateisinti RTO trukmę yra pinigų reikalas, ir labai didelių.
Ir galiausiai, kai atnešite savo BCP ir/ar DR planą atlikėjams (kurie avarijos momentu iš tikrųjų bėgs ir mojuos rankomis), jie užduos panašų klausimą: iš kur atsirado šios dvi valandos? Ir jei negalite to aiškiai paaiškinti, jie nepasitikės nei jumis, nei jūsų dokumentu.
Pasirodo, tai popierius dėl popieriaus lapo, atsisakymas. Beje, kai kurie tai daro sąmoningai, tiesiog norėdami patenkinti reguliuotojo reikalavimus.
Na supranti
2. Vaistas nuo visko
Kai kurie žmonės mano, kad BCP planas yra sukurtas siekiant apsaugoti visus verslo procesus nuo bet kokių grėsmių. Pastaruoju metu iškilo klausimas „Nuo ko norime apsisaugoti? Išgirdau atsakymą: „Viskas ir dar daugiau“.
Tačiau faktas yra tas, kad planas skirtas tik apsaugoti konkretus pagrindiniai įmonės verslo procesai nuo konkretus grasinimai. Todėl prieš kuriant planą būtina įvertinti rizikų atsiradimą ir išanalizuoti jų pasekmes verslui. Rizikos įvertinimas reikalingas norint suprasti, kokių grėsmių įmonė bijo. Pastato sunaikinimo atveju bus vienas tęstinumo planas, sankcijų spaudimo atveju - kitas, potvynio atveju - trečias. Net dvi identiškos vietos skirtinguose miestuose gali turėti labai skirtingus planus.
Neįmanoma apsaugoti visos įmonės vienu BCP, ypač dideliu. Pavyzdžiui, didžiulė X5 Retail Group pradėjo užtikrinti dviejų pagrindinių verslo procesų tęstinumą (apie tai rašėme ). O apglėbti visą įmonę su vienu planu tiesiog nerealu, tai iš „kolektyvinės atsakomybės“ kategorijos, kai atsakingi visi, o niekas neatsako.
ISO 22301 standarte yra politikos samprata, nuo kurios iš tikrųjų prasideda tęstinumo procesas įmonėje. Jame aprašoma, ką ir nuo ko saugosime. Jei žmonės atbėga ir paprašys pridėti šį bei tą, pavyzdžiui:
— Pridėkime prie BCP rizikos, kad būsime nulaužti?
Or
– Neseniai per lietų mūsų viršutinis aukštas buvo užlietas – pridėkime scenarijų, ką daryti užliejus?
Tada iš karto nukreipkite juos į šią politiką ir pasakykite, kad mes saugome konkretų įmonės turtą ir tik nuo konkrečių, iš anksto sutartų grėsmių, nes jiems dabar yra prioritetas.
Ir net jei pasiūlymai dėl pakeitimų tikrai tinkami, pasiūlykite į juos atsižvelgti kitoje politikos versijoje. Nes apsaugoti įmonę kainuoja nemažus pinigus. Taigi visi BCP plano pakeitimai turi vykti per biudžeto komitetą ir planuojant. Įmonės veiklos tęstinumo politiką rekomenduojame peržiūrėti kartą per metus arba iš karto po esminių įmonės struktūros ar išorės sąlygų pasikeitimų (ar atleis skaitytojai, kad taip sakau).
3. Fantazijos ir realybė
Dažnai atsitinka taip, kad rengdami PKP planą autoriai aprašo kokį nors idealų pasaulio vaizdą. Pavyzdžiui, „neturime antrojo duomenų centro, bet parašysime planą taip, lyg turėtume“. Arba verslas dar neturi dalies infrastruktūros, tačiau darbuotojai ją vis tiek įtrauks į planą, tikėdamiesi, kad ji atsiras ateityje. Ir tada įmonė realybę perkels į planą: pastatys antrą duomenų centrą, aprašys kitus pakeitimus.
Kairėje yra BCP atitinkanti infrastruktūra, dešinėje - tikroji infrastruktūra
Visa tai yra klaida. BCP plano rašymas reiškia pinigų išleidimą. Jei parašysite planą, kuris šiuo metu neveikia, mokėsite už labai brangų popierių. Nuo jos neįmanoma atsigauti, neįmanoma to išbandyti. Pasirodo, darbas vardan darbo.
Planą galite parašyti gana greitai, tačiau atsarginės infrastruktūros kūrimas ir pinigų leidimas visiems apsaugos sprendimams yra ilgas ir brangus. Tai gali užtrukti daugiau nei vienerius metus. Ir gali pasirodyti, kad jau turite planą, o infrastruktūra jam atsiras po dvejų metų. Kam reikalingas toks planas? Nuo ko jis tave apsaugos?
Taip pat fantazija, kai BCP kūrimo komanda pradeda aiškintis ekspertams, ką jie turėtų daryti ir per kiek laiko. Jis kilęs iš kategorijos: „Pamačius mešką taigoje reikia sukti į priešingą pusę nei lokys ir bėgti greičiu, viršijančiu meškos greitį. Žiemos mėnesiais reikia uždengti pėdsakus.
4. Viršūnės ir šaknys
Ketvirta pagal svarbą klaida – planas per daug paviršutiniškas arba per daug detalus. Mums reikia aukso vidurio. Planas neturėtų būti per daug išsamus idiotams, tačiau jis neturėtų būti pernelyg bendras, kad baigtųsi kažkas panašaus:
Apskritai lengva
5. Cezariui - kas Cezario, mechanikui - kas mechaniko.
Kita klaida kyla iš ankstesnės: vienas planas negali sutalpinti visų veiksmų visiems valdymo lygiams. BCP planai dažniausiai kuriami didelėms įmonėms, turinčioms didelius finansinius srautus (beje, pagal mūsų , vidutiniškai 48 % didelių Rusijos įmonių susidūrė su ekstremaliomis situacijomis, dėl kurių patyrė didelių finansinių nuostolių) ir daugiapakopę valdymo sistemą. Tokioms įmonėms neverta stengtis visko sutalpinti į vieną dokumentą. Jei įmonė yra didelė ir struktūrizuota, planas turi turėti tris atskirus lygius:
- strateginis lygis – vyresniajai vadovybei;
- taktinis lygis – vidurinės grandies vadovams;
- o operatyvinis lygis – tiems, kurie tiesiogiai dalyvauja šioje srityje.
Pavyzdžiui, jei kalbame apie sugedusios infrastruktūros atkūrimą, tai strateginiu lygmeniu priimamas sprendimas aktyvuoti atkūrimo planą, taktiniame lygmenyje gali būti aprašytos proceso procedūros, o eksploataciniu lygmeniu pateikiamos instrukcijos, kaip paleisti konkrečias. įrangos dalių.
BCP be biudžeto
Kiekvienas mato savo atsakomybės sritį ir ryšius su kitais darbuotojais. Avarijos metu kiekvienas atsidaro planą, greitai suranda savo dalį ir jo laikosi. Idealiu atveju reikia mintinai atsiminti, kuriuos puslapius atversti, nes kartais minutės skaičiuojamos.
6. Vaidmenų žaidimas
Dar viena klaida rengiant PKP planą: į planą nereikia įtraukti konkrečių vardų, el. pašto adresų ir kitos kontaktinės informacijos. Pačiame dokumento tekste turi būti nurodyti tik beasmeniai vaidmenys, o šiems vaidmenims priskirti atsakingų už konkrečias užduotis vardai ir jų kontaktai nurodyti plano priede.
Kodėl?
Šiandien dauguma žmonių keičia darbą kas dvejus trejus metus. O jeigu plano tekste surašysite visus atsakingus asmenis ir jų kontaktus, tuomet jį teks nuolat keisti. O didelėse įmonėse, o ypač valdiškose, kiekvienas bet kokio dokumento pakeitimas reikalauja galybės patvirtinimų.
Jau nekalbant apie tai, kad jei atsitiks nelaimė ir turėsite įnirtingai naršyti planą ir ieškoti tinkamo kontakto, prarasite brangų laiką.
Gyvenimo įsilaužimas: kai pakeičiate programą, dažnai net nereikia jos patvirtinti. Kitas patarimas: galite naudoti planų atnaujinimo automatizavimo sistemas.
7. Versijų nebuvimas
Paprastai jie sukuria plano versiją 1.0, o tada atlieka visus pakeitimus be redagavimo režimo ir nekeisdami failo pavadinimo. Tuo pačiu metu dažnai neaišku, kas pasikeitė, palyginti su ankstesne versija. Jei nėra versijų, planas gyvena savo gyvenimą, kuris jokiu būdu nėra sekamas. Antrame bet kurio BCP plano puslapyje turi būti nurodyta versija, pakeitimų autorius ir pačių pakeitimų sąrašas.
Niekas nebegali to išsiaiškinti
8. Ko turėčiau paklausti?
Dažnai įmonės neturi atsakingo už BCP planą asmens ir nėra atskiro skyriaus, atsakingo už veiklos tęstinumą. Ši garbinga pareiga priskiriama CIO, jo pavaduotojui arba pagal principą „jūs užsiimate informacijos saugumu, taigi čia papildomai BCP“. Dėl to planas rengiamas, suderinamas ir patvirtinamas iš viršaus į apačią.
Kas atsakingas už plano saugojimą, atnaujinimą ir jame esančios informacijos patikslinimą? Tai gali būti nenurodyta. Tam samdyti atskirą darbuotoją yra nenaudinga, tačiau apkrauti vieną iš esamų papildomų pareigų, žinoma, galima, nes visi dabar siekia efektyvumo: „Pakabinkime jam žibintą, kad galėtų pjauti naktį“, bet ar tai būtina?
Atsakingų už PKP ieškome praėjus dvejiems metams nuo jo sukūrimo
Todėl dažnai atsitinka taip: buvo sukurtas planas ir įdėtas į ilgą dėžutę, kad jis būtų padengtas dulkėmis. Niekas jo netikrina ir nepalaiko jos aktualumo. Dažniausia frazė, kurią išgirstu atėjus pas klientą: „Planas yra, bet jau seniai sukurtas, ar buvo išbandytas nežinia, kyla įtarimas, kad neveikia“.
9. Per daug vandens
Yra planų, kurių įvadas yra penkių puslapių, įskaitant būtinųjų sąlygų aprašymą ir padėką visiems projekto dalyviams, su informacija apie tai, ką įmonė veikia. Kol slenkate žemyn iki dešimto puslapio, kuriame yra naudingos informacijos, jūsų duomenų centras jau buvo užtvindytas.
Kai bandote skaityti iki šiol, ką daryti, jei jūsų duomenų centras yra užtvindytas?
Įdėkite visą įmonės „vandenį“ į atskirą dokumentą. Pats planas turi būti itin konkretus: tai atlieka už šią užduotį atsakingas asmuo ir pan.
10. Kieno sąskaita banketas?
Dažnai planų kūrėjai neturi aukščiausios įmonės vadovybės palaikymo. Tačiau yra paramos iš vidurinės grandies vadovų, kurie nevaldo arba neturi reikiamo biudžeto ir išteklių veiklos tęstinumui valdyti. Pavyzdžiui, IT skyrius sukuria BCP planą neviršydamas savo biudžeto, tačiau CIO nemato viso įmonės vaizdo. Mano mėgstamiausias pavyzdys yra vaizdo konferencijos. Kai generalinio direktoriaus vaizdo konferencija neveiks, ką jis išdarinės? CIO, kuris „nepateikė“. Todėl CIO požiūriu, kas įmonėje yra svarbiausia? Už ką žmonės jį visada „myli“: vaizdo konferencijos, kurios iškart virsta verslui svarbia sistema. Ir iš verslo pusės - na, jokios VKS, tik pagalvok, kalbėsime telefonu, kaip Brežnevo laikais...
Be to, IT skyrius dažniausiai mano, kad pagrindinė jo užduotis įvykus nelaimei yra atkurti įmonių IT sistemų veikimą. Bet kartais to daryti nereikia! Jei vyksta verslo procesas, susijęs su popieriaus gabalėlių spausdinimu ant siaubingai brangaus spausdintuvo, tuomet nereikėtų pirkti antrojo tokio spausdintuvo kaip atsarginės ir padėti jį šalia jo, jei sugestų. Gali pakakti laikinai nuspalvinti popieriaus gabalus rankomis.
Jei kuriame nuolatinę IT apsaugą, turime pasitelkti vyresniosios vadovybės ir verslo atstovų pagalbą. Priešingu atveju, apsigyvenę IT skyriuje, galite išspręsti tam tikrą problemų spektrą, bet ne visas būtinas.
Taip atrodo situacija, kai DR planus turi tik IT skyrius
10. Jokių bandymų
Jei yra planas, jį reikia išbandyti. Tiems, kurie nėra susipažinę su standartais, tai nėra akivaizdu. Pavyzdžiui, visur kabo „avarinio išėjimo“ ženklai. Bet pasakyk, kur tavo ugnies kibiras, kabliukas ir kastuvas? Kur yra gaisrinis hidrantas? Kur turėtų būti gesintuvas? Bet visi turėtų tai žinoti. Mums visai nelogiška įėjus į biurą rasti gesintuvą.
Galbūt plano testavimo būtinybę reikėtų paminėti pačiame plane, tačiau tai prieštaringas sprendimas. Bet kuriuo atveju planas gali būti laikomas veikiančiu tik tuo atveju, jei jis buvo bent kartą išbandytas. Kaip jau minėta, labai dažnai girdžiu: „Planas yra, visa infrastruktūra parengta, bet ne faktas, kad viskas pavyks taip, kaip parašyta plane. Nes jie to neišbandė. Niekada".
užbaigiant
Kai kurios įmonės gali analizuoti savo istoriją, kad suprastų, kokių problemų gali kilti ir kokia jų tikimybė. Tyrimai ir patirtis rodo, kad negalime apsisaugoti nuo visko. Šūdas, anksčiau ar vėliau, nutinka bet kuriai įmonei. Kitas dalykas – kaip būsite pasiruošę tokiai ar panašiai situacijai ir ar pavyks laiku atkurti savo verslą.
Kai kurie žmonės mano, kad tęstinumas yra tai, kaip pašalinti visokias rizikas, kad jos nepasitvirtintų. Ne, esmė ta, kad rizika išsipildys, ir mes būsime tam pasirengę. Kariai mokomi mūšyje ne mąstyti, o veikti. Tas pats ir su BCP planu: jis leis kuo greičiau atkurti verslą.
Vienintelė įranga, kuriai nereikia BCP
Igoris Tyukačiovas,
Veiklos tęstinumo konsultantas
Kompiuterinių sistemų projektavimo centras
„Jet Infosystems“
Šaltinis: www.habr.com