Üdvözlök mindenkit, a nevem Igor Tyukachev, és üzletmenet-folytonossági tanácsadó vagyok. A mai bejegyzésben a közös igazságokról fogunk hosszasan és fárasztóan vitatkozni. Szeretném megosztani tapasztalataimat, és beszélni a főbb hibákról, amelyeket a vállalatok elkövetnek az üzletmenet-folytonossági terv kidolgozása során.
1. RTO és RPO véletlenszerűen
A legfontosabb hiba, amit láttam, hogy a helyreállítási időt (RTO) a semmiből vették. Nos, légből kapott - van például néhány két évvel ezelőtti szám az SLA-ból, amit valaki az előző munkahelyéről hozott. Miért teszik ezt? Végtére is, minden módszer szerint először elemezni kell az üzleti folyamatokra gyakorolt következményeket, és ezen elemzés alapján ki kell számítani a cél helyreállítási időt és az elfogadható adatvesztést. De egy ilyen elemzés elkészítése néha sokáig tart, néha drága, néha nem nagyon világos, hogyan – hangsúlyozd, hogy mit kell tenni. És az első dolog, ami sokaknak eszébe jut: „Mindannyian felnőttek vagyunk, és értjük az üzlet működését. Ne vesztegessük az időt és a pénzt! Vegyük a pluszt vagy mínuszt, ahogy kell. Fejből, proletár találékonysággal! Legyen az RTO két óra.”
Mihez vezet ez? Ha a vezetőséghez olyan tevékenységekért érkezel pénzért, amelyek bizonyos számokkal biztosítják a szükséges RTO/RPO-t, az mindig indoklást igényel. Ha nincs indoklás, akkor felmerül a kérdés: honnan vetted? És nincs mit válaszolni. Ennek eredményeként elveszik a munkájába vetett bizalom.
Emellett néha egymillió dollárba került az a két óra gyógyulás. Az RTO időtartamának igazolása pedig pénzkérdés, mégpedig nagyon nagyok.
És végül, amikor elhozod a BCP- és/vagy DR-tervedet az előadóknak (akik a baleset pillanatában valóban futni fognak és hadonászni a karjukkal), hasonló kérdést tesznek fel: honnan jött ez a két óra? És ha ezt nem tudja egyértelműen elmagyarázni, akkor sem Önben, sem a dokumentumában nem fognak bízni.
Kiderül, hogy egy darab papír a papír kedvéért, egy leiratkozás. Egyébként vannak, akik ezt szándékosan teszik, egyszerűen azért, hogy megfeleljenek a szabályozó követelményeinek.
Nos, megkaptad
2. A gyógymód mindenre
Vannak, akik úgy vélik, hogy a BCP-tervet úgy dolgozták ki, hogy megvédje az összes üzleti folyamatot bármilyen fenyegetéstől. Nemrég felvetődött a kérdés: „Mitől akarjuk megvédeni magunkat?” Hallottam a választ: "Mindent és még többet."
De tény, hogy a terv célja csak a védelem különleges a cég kulcsfontosságú üzleti folyamataitól különleges fenyegetések. Ezért a terv kidolgozása előtt fel kell mérni a kockázatok előfordulását, és elemezni kell azok vállalkozásra gyakorolt következményeit. Kockázatértékelésre van szükség ahhoz, hogy megértsük, milyen fenyegetésektől tart a vállalat. Épületrombolás esetén egy folytonossági terv lesz, szankciók nyomása esetén másik, árvíz esetén pedig harmadik. Akár két egyforma telephely különböző városokban is jelentősen eltérhet a tervektől.
Lehetetlen egy teljes vállalatot megvédeni egyetlen BCP-vel, különösen egy nagyot. A hatalmas X5 Retail Group például megkezdte a folytonosságot két kulcsfontosságú üzleti folyamattal (erről írtunk ). És egyszerűen irreális az egész céget egy tervvel körbezárni, ez a „kollektív felelősség” kategóriájából való, amikor mindenki felelős és senki sem.
Az ISO 22301 szabvány tartalmazza a politika fogalmát, amivel tulajdonképpen a folyamatosság folyamata kezdődik a vállalatban. Leírja, hogy mit és mitől védünk meg. Ha futnak az emberek és kérik, hogy adjanak hozzá ezt-azt, például:
— Adjuk hozzá a BCP-hez a kockázatot, hogy feltörnek minket?
Vagy
— Nemrég, esőben, elöntötte a legfelső emeletünket – adjunk hozzá egy forgatókönyvet, hogy mit tegyünk árvíz esetén?
Ezután azonnal hivatkozzon rájuk erre a szabályzatra, és mondja ki, hogy a vállalat meghatározott eszközeit védjük, és csak a konkrét, előre egyeztetett fenyegetésektől, mert most ezek a prioritások.
És még ha a változtatási javaslatok valóban megfelelőek is, akkor ajánlja fel, hogy ezeket figyelembe veszi a szabályzat következő változatában. Mert egy cég védelme sok pénzbe kerül. Tehát a BCP-terv minden változtatásának át kell mennie a költségvetési bizottságon és a tervezésen. Javasoljuk a társaság üzletmenet-folytonossági politikájának áttekintését évente egyszer, vagy közvetlenül a vállalati struktúra vagy a külső feltételek jelentős változása után (elnézést kérek az olvasóktól).
3. Fantáziák és valóság
Gyakran előfordul, hogy a BCP-terv elkészítésekor a szerzők valamilyen ideális világképet írnak le. Például: „Nincs második adatközpontunk, de úgy írunk egy tervet, mintha lenne”. Illetve a vállalkozás még nem rendelkezik az infrastruktúra egy részével, de az alkalmazottak még hozzáteszik a tervhez, abban a reményben, hogy a jövőben megjelenik. És akkor a cég rátereli a valóságot a tervre: épít egy második adatközpontot, és ír le más változásokat.
Bal oldalon a BCP-nek megfelelő infrastruktúra, jobb oldalon a valós infrastruktúra látható
Ez mind hiba. A BCP-terv megírása pénzköltést jelent. Ha olyan tervet ír, amely most nem működik, akkor nagyon drága papírt fog fizetni. Kigyógyulni belőle lehetetlen, kipróbálni lehetetlen. Kiderül, hogy munka a munka kedvéért.
Elég gyorsan lehet tervet írni, de a tartalék infrastruktúra kiépítése és az összes védelmi megoldásra való pénzköltés hosszú és költséges. Ez több mint egy évig is eltarthat. És kiderülhet, hogy már van egy terve, és két év múlva megjelenik az infrastruktúra hozzá. Miért van szükség ilyen tervre? Mitől fog megvédeni?
Az is egy fantázia, amikor a BCP fejlesztőcsapata elkezdi kitalálni a szakértők számára, mit és mennyi idő alatt kell tenniük. A kategóriából származik: „Amikor medvét látsz a tajgában, a medvével ellentétes irányba kell fordulnod, és a medve sebességét meghaladó sebességgel kell futnod. A téli hónapokban el kell fedezni a nyomokat.”
4. Csúcsok és gyökerek
A negyedik legfontosabb hiba, hogy a tervet túl felületessé vagy túl részletessé tesszük. Arany középútra van szükségünk. A terv ne legyen túl részletes az idióták számára, de ne legyen túl általános, hogy valami ilyesmi legyen a vége:
Egyszerűen általában
5. Caesarnak - ami Caesaré, a szerelőnek - ami a szerelőé.
A következő hiba az előzőből fakad: egy tervben nem lehet minden irányítási szint összes intézkedését befogadni. A BCP-terveket általában nagy pénzügyi áramlásokkal rendelkező nagyvállalatok számára készítik (mellesleg a mi , átlagosan az orosz nagyvállalatok 48%-a találkozott jelentős pénzügyi veszteséggel járó vészhelyzetekkel) és többszintű irányítási rendszerrel. Az ilyen cégeknél nem érdemes megpróbálni mindent egy dokumentumba illeszteni. Ha a vállalat nagy és strukturált, akkor a tervnek három különálló szinttel kell rendelkeznie:
- stratégiai szint - felső vezetés számára;
- taktikai szint - középvezetőknek;
- és az operatív szint – a szakterületen közvetlenül érintettek számára.
Például, ha egy meghibásodott infrastruktúra helyreállításáról beszélünk, akkor stratégiai szinten megszületik a döntés a helyreállítási terv aktiválásáról, taktikai szinten le lehet írni a folyamatokat, operatív szinten pedig utasítások vannak a konkrét üzembe helyezéshez. berendezések darabjai.
BCP költségvetés nélkül
Mindenki látja a saját felelősségi körét és kapcsolatait más alkalmazottakkal. A baleset pillanatában mindenki megnyit egy tervet, gyorsan megtalálja a részét és követi azt. Ideális esetben fejből kell megjegyezni, hogy melyik oldalt kell megnyitni, mert néha a percek számítanak.
6. Szerepjáték
Egy másik hiba a BCP-terv elkészítésekor: nincs szükség konkrét nevek, e-mail címek és egyéb elérhetőségek feltüntetésére a tervben. Magában a dokumentum szövegében csak a személytelen szerepköröket kell feltüntetni, ezekhez a szerepkörökhöz kell hozzárendelni a konkrét feladatokért felelős személyek nevét és elérhetőségeit a terv mellékletében.
Miért?
Ma a legtöbb ember két-három évente vált munkahelyet. És ha a terv szövegébe beírja az összes felelőst és elérhetőségeit, akkor azt folyamatosan módosítani kell. A nagy cégeknél, és különösen a kormányoknál, minden dokumentum módosításához rengeteg jóváhagyás szükséges.
Arról nem is beszélve, hogy ha vészhelyzet történik, és eszeveszetten kell lapoznia a tervet, és meg kell keresnie a megfelelő kapcsolatot, akkor értékes időt veszít.
Life hack: amikor módosít egy alkalmazást, gyakran még jóváhagynia sem kell. Egy másik tipp: használhat tervfrissítési automatizálási rendszereket.
7. Verziószámítás hiánya
Általában létrehoznak egy 1.0-s tervverziót, majd minden változtatást szerkesztési mód és a fájlnév megváltoztatása nélkül hajtanak végre. Ugyanakkor gyakran nem világos, hogy mi változott az előző verzióhoz képest. Verziószámítás hiányában a terv éli a saját életét, amit semmilyen módon nem követnek nyomon. Bármely BCP-terv második oldalán fel kell tüntetni a verziót, a módosítások szerzőjét és maguknak a változtatásoknak a listáját.
Ezt már senki sem tudja kitalálni
8. Kit kérdezzek meg?
A vállalatoknak gyakran nincs felelőse a BCP-tervért, és nincs külön részleg, amely az üzletmenet folytonosságáért felelne. Ezt a megtisztelő felelősséget a CIO-ra, a helyettesére ruházzák, vagy az „információbiztonsággal foglalkozik, ezért itt van még a BCP” elv szerint. Ennek eredményeként a tervet felülről lefelé kidolgozzák, egyeztetik és jóváhagyják.
Ki a felelős a terv tárolásáért, frissítéséért és a benne található információk átdolgozásáért? Ezt nem írják elő. Erre külön alkalmazottat felvenni pazarlás, de a meglévők valamelyikét plusz feladatokkal terhelni persze lehetséges, mert ma már mindenki a hatékonyságra törekszik: „Akassunk rá lámpást, hogy éjszaka nyírhasson” de szükséges?
A BCP-ért felelősöket keresünk a létrehozása után két évvel
Ezért gyakran így történik: kidolgoztak egy tervet, amelyet egy hosszú dobozba tettek, hogy porral borítsa be. Senki nem teszteli és nem tartja fenn a relevanciáját. A leggyakrabban hallható mondat, amikor egy ügyfélhez fordulok: "Van egy terv, de régen kidolgozták, nem tudni, hogy tesztelték-e, van a gyanú, hogy nem működik."
9. Túl sok víz
Vannak olyan tervek, amelyekben a bevezető öt oldalas, tartalmazza az előfeltételek leírását és a projekt minden résztvevőjének köszönetét, a cég tevékenységével kapcsolatos információkkal. Mire lefelé görgetsz a tizedik oldalra, ahol hasznos információk találhatók, már elárasztották az adatközpontodat.
Mi a teendő, ha az aktuális pillanatig próbál olvasni, ha az adatközpontot elárasztotta a víz?
Helyezze el az összes vállalati „vizet” egy külön dokumentumba. Magának a tervnek rendkívül konkrétnak kell lennie: ezt a feladatot végző személy végzi el stb.
10. Kinek a költségére történik a bankett?
A tervek készítői gyakran nem kapnak támogatást a vállalat felső vezetésétől. De támogatást kap a középvezetés, aki nem irányítja, vagy nem rendelkezik a szükséges költségvetéssel és erőforrásokkal az üzletmenet folytonosságának kezelésére. Például az informatikai részleg a költségvetésén belül elkészíti a BCP-tervét, de a CIO nem látja a teljes vállalatképet. Kedvenc példám a videokonferencia. Ha a vezérigazgató videokonferenciája nem működik, kit zsigerel ki? A CIO, aki „nem biztosított”. Ezért az informatikai igazgató szemszögéből mi a legfontosabb a cégben? Amiért az emberek mindig „szeretik”: a videokonferenciát, amiből azonnal üzletkritikus rendszer lesz. És üzleti szempontból - nos, nem VKS, gondolja csak, beszélünk telefonon, mint Brezsnyev alatt...
Emellett az informatikai osztály általában azt gondolja, hogy katasztrófa esetén a fő feladata a vállalati informatikai rendszerek működésének helyreállítása. De néha nem kell ezt csinálni! Ha van olyan üzleti folyamat, hogy papírdarabokat nyomtatunk egy borzasztóan drága nyomtatón, akkor ne vegyünk egy második ilyen nyomtatót tartaléknak, és tegyük mellé, ha meghibásodik. Elég lehet ideiglenesen kézzel színezni a papírdarabokat.
Ha folyamatos védelmet építünk ki az IT-n belül, akkor a felső vezetés és az üzleti élet képviselőinek támogatását kell igénybe venni. Ellenkező esetben az informatikai osztályon belül bebábozva bizonyos problémákat meg tud oldani, de nem minden szükségeset.
Így néz ki a helyzet, amikor csak az informatikai osztálynak vannak DR-tervei
10. Nincs tesztelés
Ha van terv, azt ki kell próbálni. Azok számára, akik nem ismerik a szabványokat, ez egyáltalán nem nyilvánvaló. Például mindenhol „vészkijárat” táblák lógnak. De mondd, hol van a tűzoltóvödröd, a horgod és a lapátod? Hol van a tűzcsap? Hol kell elhelyezni a tűzoltó készüléket? De ezt mindenkinek tudnia kell. Egyáltalán nem tűnik logikusnak számunkra, hogy az irodába belépve tűzoltó készüléket találjunk.
Talán magában a tervben is meg kell említeni a terv tesztelésének szükségességét, de ez egy vitatott döntés. Mindenesetre egy terv csak akkor tekinthető működőképesnek, ha legalább egyszer tesztelték. Ahogy fentebb említettük, nagyon gyakran hallom: „Van egy terv, minden infrastruktúra előkészítve, de nem tény, hogy minden úgy fog sikerülni, ahogy a tervben meg van írva. Mert nem tesztelték. Soha".
Összefoglalva
Egyes vállalatok elemezhetik történetüket annak érdekében, hogy megértsék, milyen bajok várhatók és mekkora valószínűséggel. A kutatások és a tapasztalatok azt mutatják, hogy nem tudjuk megvédeni magunkat mindentől. A szar előbb-utóbb minden céggel megtörténik. Más kérdés, hogy mennyire leszel felkészülve erre vagy egy hasonló helyzetre, és hogy sikerül-e időben helyreállítani a vállalkozásodat.
Vannak, akik úgy gondolják, hogy a folytonosság arról szól, hogyan lehet mindenféle kockázatot kiküszöbölni, hogy azok ne valósuljanak meg. Nem, a lényeg az, hogy a kockázatok megvalósulnak, és készek leszünk erre. A katonákat arra képezik ki, hogy ne harcban gondolkodjanak, hanem cselekedjenek. Ugyanez vonatkozik a BCP-tervre is: lehetővé teszi, hogy a lehető leggyorsabban helyreállítsa vállalkozását.
Az egyetlen berendezés, amely nem igényel BCP-t
Igor Tyukachev,
Üzletmenet-folytonossági tanácsadó
Számítástechnikai Rendszertervezési Központ
"Jet Inforendszerek"
Forrás: will.com