Hei kaikki, nimeni on Igor Tyukachev ja olen liiketoiminnan jatkuvuuden konsultti. Tämän päivän postauksessa käydään pitkä ja ikävä keskustelu yhteisistä totuuksista.Haluan jakaa kokemukseni ja kertoa tärkeimmistä virheistä, joita yritykset tekevät liiketoiminnan jatkuvuussuunnitelmaa laatiessaan.
1. RTO ja RPO satunnaisesti
Tärkein näkemäni virhe on, että toipumisaika (RTO) otetaan tyhjästä. No, tyhjästä - esimerkiksi SLA:sta on joitain kahden vuoden takaisia numeroita, jotka joku toi edelliseltä työpaikaltaan. Miksi he tekevät tämän? Loppujen lopuksi kaikkien menetelmien mukaan sinun on ensin analysoitava seuraukset liiketoimintaprosesseille ja laskettava tämän analyysin perusteella tavoitepalautusaika ja hyväksyttävä tietojen menetys. Mutta tällaisen analyysin tekeminen kestää joskus kauan, joskus se on kallista, joskus ei ole kovin selvää miten – korosta, mitä on tehtävä. Ja ensimmäinen asia, joka tulee monille mieleen, on: ”Olemme kaikki aikuisia ja ymmärrämme, miten bisnes toimii. Älä tuhlaa aikaa ja rahaa! Otetaan plussa tai miinus niin kuin pitääkin. Pois päästäsi, käytä proletaarista kekseliäisyyttä! Olkoon RTO kaksi tuntia."
Mihin tämä johtaa? Kun tulet johdolle rahaa toimintaan, jolla varmistetaan vaadittu RTO/RPO tietyillä numeroilla, se vaatii aina perustelun. Jos perusteluja ei ole, herää kysymys: mistä olet sen saanut? Eikä ole mitään vastattavaa. Seurauksena on, että luottamus työhösi on menetetty.
Lisäksi joskus ne kaksi tuntia toipumista maksavat miljoona dollaria. Ja RTO:n keston perusteleminen on rahakysymys, ja se on erittäin suuri.
Ja lopuksi, kun tuot BCP- ja/tai DR-suunnitelmasi esiintyjille (jotka todella juoksevat ja heiluttavat käsiään onnettomuuden hetkellä), he kysyvät samanlaisen kysymyksen: mistä nämä kaksi tuntia tulivat? Ja jos et pysty selittämään tätä selkeästi, he eivät luota sinuun tai asiakirjaasi.
Se osoittautuu paperinpalaksi paperinpalan vuoksi, tilauksen peruuttamiseksi. Muuten, jotkut tekevät tämän tarkoituksella, yksinkertaisesti täyttääkseen sääntelijän vaatimukset.
No, sait sen
2. Lääke kaikkeen
Jotkut ihmiset uskovat, että BCP-suunnitelma on kehitetty suojaamaan kaikkia liiketoimintaprosesseja kaikilta uhilta. Viime aikoina kysymys "Miltä haluamme suojautua?" Kuulin vastauksen: "Kaikki ja enemmän."
Mutta tosiasia on, että suunnitelman tarkoituksena on vain suojella erityinen Yrityksen keskeiset liiketoimintaprosessit alkaen erityinen uhkauksia. Siksi ennen suunnitelman laatimista on tarpeen arvioida riskien esiintyminen ja analysoida niiden seuraukset liiketoiminnalle. Riskien arviointia tarvitaan, jotta voidaan ymmärtää, mitä uhkia yritys pelkää. Rakennuksen tuhoutuessa on yksi jatkuvuussuunnitelma, pakotepaineen tapauksessa toinen, tulvan tapauksessa kolmas. Jopa kahdella identtisellä kohteella eri kaupungeissa voi olla huomattavasti erilaiset suunnitelmat.
Koko yritystä on mahdotonta suojella yhdellä BCP:llä, etenkään suurella. Esimerkiksi valtava X5 Retail Group alkoi varmistaa jatkuvuuden kahdella keskeisellä liiketoimintaprosessilla (kirjoitimme tästä ). Ja on yksinkertaisesti epärealistista sulkea koko yritys yhteen suunnitelmaan, tämä on "kollektiivisen vastuun" kategoriasta, kun kaikki ovat vastuussa ja kukaan ei ole vastuussa.
ISO 22301 -standardi sisältää politiikan käsitteen, josta itse asiassa jatkuvuusprosessi yrityksessä alkaa. Se kuvaa mitä suojelemme ja miltä. Jos ihmiset tulevat juoksemaan ja pyytävät lisäämään tämän ja tuon, esimerkiksi:
— Lisätäänkö BCP:hen riski, että meidät hakkeroidaan?
tai
— Äskettäin sateen aikana ylin kerros tulvi - lisätään skenaario, mitä tehdä tulvan sattuessa?
Ohjaa sitten välittömästi tähän käytäntöön ja sano, että suojelemme tiettyä yrityksen omaisuutta ja vain tietyiltä, ennalta sovituilta uhilta, koska ne ovat nyt etusijalla.
Ja vaikka muutosehdotukset ovatkin aiheellisia, tarjoudu ottamaan ne huomioon politiikan seuraavassa versiossa. Koska yrityksen suojaaminen maksaa paljon rahaa. Kaikki BCP-suunnitelmaan tehtävät muutokset on siis käytävä budjettivaliokunnan ja suunnittelun läpi. Suosittelemme tutustumaan yhtiön liiketoiminnan jatkuvuuspolitiikkaan kerran vuodessa tai välittömästi yhtiön rakenteessa tai ulkoisissa olosuhteissa tapahtuneiden merkittävien muutosten jälkeen (antakoon lukijat anteeksi, että sanon niin).
3. Fantasioita ja todellisuutta
Usein käy niin, että BCP-suunnitelmaa laatiessaan kirjoittajat kuvaavat ideaalikuvaa maailmasta. Esimerkiksi "meillä ei ole toista palvelinkeskusta, mutta kirjoitamme suunnitelman ikään kuin meillä olisi." Tai yrityksellä ei ole vielä osaa infrastruktuurista, mutta työntekijät lisäävät sen silti suunnitelmaan siinä toivossa, että se ilmestyy tulevaisuudessa. Ja sitten yritys venyttää todellisuuden suunnitelmaan: rakentaa toinen datakeskus, kuvaile muita muutoksia.
Vasemmalla on BCP:tä vastaava infrastruktuuri, oikealla todellinen infrastruktuuri
Tämä kaikki on virhe. BCP-suunnitelman kirjoittaminen tarkoittaa rahankäyttöä. Jos kirjoitat suunnitelman, joka ei toimi juuri nyt, maksat erittäin kalliista paperista. Siitä on mahdotonta toipua, sitä on mahdotonta testata. Se osoittautuu työksi työn tähden.
Suunnitelman voi kirjoittaa melko nopeasti, mutta varainfrastruktuurin rakentaminen ja rahan käyttäminen kaikkiin suojaratkaisuihin on pitkää ja kallista. Tämä voi kestää yli vuoden. Ja voi käydä niin, että sinulla on jo suunnitelma, ja sen infrastruktuuri ilmestyy kahden vuoden kuluttua. Miksi tällaista suunnitelmaa tarvitaan? Miltä se suojaa sinua?
On myös fantasiaa, kun BCP-kehitystiimi alkaa selvittää asiantuntijoiden puolesta, mitä heidän pitäisi tehdä ja mihin aikaan. Se tulee kategoriasta: ”Kun näet karhun taigassa, sinun on käännyttävä karhusta vastakkaiseen suuntaan ja juostava karhun nopeuden ylittävällä nopeudella. Talvikuukausina sinun on peitettävä jälkesi."
4. Topit ja juuret
Neljäs tärkein virhe on tehdä suunnitelmasta joko liian pinnallinen tai liian yksityiskohtainen. Tarvitsemme kultaisen keskitien. Suunnitelma ei saa olla liian yksityiskohtainen idiooteille, mutta se ei saa olla liian yleinen, jotta jotain tällaista päätyy:
Yleisesti helpolla
5. Caesarille - mikä on Caesarin, mekaanikolle - mikä on mekaanikon.
Seuraava virhe johtuu edellisestä: yhteen suunnitelmaan ei voi mahtua kaikkia toimia kaikille johtamistasoille. BCP-suunnitelmat kehitetään yleensä suurille yrityksille, joilla on suuret rahavirrat (muuten, meidän Keskimäärin 48 % venäläisistä suurista yrityksistä kohtasi hätätilanteita, jotka aiheuttivat merkittäviä taloudellisia menetyksiä) ja monitasoisen johtamisjärjestelmän. Tällaisten yritysten ei kannata yrittää sovittaa kaikkea yhteen asiakirjaan. Jos yritys on suuri ja jäsennelty, suunnitelmassa tulisi olla kolme erillistä tasoa:
- strateginen taso - ylimmälle johdolle;
- taktinen taso - keskijohdolle;
- ja toiminnallinen taso - alan suoraan toimiville.
Esimerkiksi, jos puhutaan epäonnistuneen infrastruktuurin palauttamisesta, niin strategisella tasolla päätetään elvytyssuunnitelman aktivoimisesta, taktisella tasolla voidaan kuvata prosessimenettelyjä ja operatiivisella tasolla on ohjeet tiettyjen käyttöönottoon. varusteet.
BCP ilman budjettia
Jokainen näkee oman vastuualueensa ja yhteydet muihin työntekijöihin. Onnettomuuden hetkellä jokainen avaa suunnitelman, löytää nopeasti oman osansa ja seuraa sitä. Ihannetapauksessa sinun on muistettava ulkoa, mitkä sivut avataan, koska joskus minuutit ovat tärkeitä.
6. Roolileikki
Toinen virhe BCP-suunnitelmaa laadittaessa: suunnitelmaan ei tarvitse sisällyttää tiettyjä nimiä, sähköpostiosoitteita ja muita yhteystietoja. Itse asiakirjan tekstissä tulee ilmoittaa vain persoonattomat roolit, ja näille rooleille tulee antaa tietyistä tehtävistä vastaavien nimet ja heidän yhteyshenkilönsä mainita suunnitelman liitteessä.
Miksi?
Nykyään useimmat ihmiset vaihtavat työpaikkaa kahden tai kolmen vuoden välein. Ja jos kirjoitat kaikki vastuulliset ja heidän yhteystietonsa suunnitelman tekstiin, sitä on jatkuvasti muutettava. Ja suurissa yrityksissä, ja erityisesti valtion yrityksissä, jokainen asiakirjan muutos vaatii paljon hyväksyntää.
Puhumattakaan siitä, että jos tulee hätätilanne ja joudut kiihkeästi selaamaan suunnitelmaa ja etsimään oikeaa kontaktia, menetät arvokasta aikaa.
Life hack: kun muutat sovellusta, sinun ei usein tarvitse edes hyväksyä sitä. Toinen vinkki: voit käyttää suunnitelmapäivitysautomaatiojärjestelmiä.
7. Versioinnin puute
Yleensä he luovat suunnitelman version 1.0 ja tekevät sitten kaikki muutokset ilman muokkaustilaa ja muuttamatta tiedoston nimeä. Samaan aikaan on usein epäselvää, mikä on muuttunut edelliseen versioon verrattuna. Versioinnin puuttuessa suunnitelma elää omaa elämäänsä, jota ei seurata millään tavalla. Jokaisen BCP-suunnitelman toisella sivulla tulee olla versio, muutosten tekijä ja luettelo itse muutoksista.
Kukaan ei voi enää selvittää sitä
8. Keneltä minun pitäisi kysyä?
Usein yrityksillä ei ole BCP-suunnitelmasta vastaavaa henkilöä, eikä erillistä osastoa ole vastuussa liiketoiminnan jatkuvuudesta. Tämä kunniakas vastuu on osoitettu tietohallintojohtajalle, hänen sijaiselleen tai periaatteen mukaan "käsittelet tietoturvaa, joten tässä on lisäksi BCP". Tämän seurauksena suunnitelmaa kehitetään, sovitaan ja hyväksytään ylhäältä alas.
Kuka vastaa suunnitelman tallentamisesta, päivittämisestä ja sen sisältämien tietojen tarkistamisesta? Tätä ei välttämättä määrätä. Erillisen työntekijän palkkaaminen tähän on turhaa, mutta olemassa olevien kuormittaminen lisätehtävillä on tietysti mahdollista, sillä nyt kaikki pyrkivät tehokkuuteen: "Riputetaan lyhty, jotta hän voi leikkaa yöllä", mutta onko se tarpeellista?
Etsimme BCP:stä vastaavia kaksi vuotta sen perustamisen jälkeen
Siksi se tapahtuu usein näin: suunnitelma kehitettiin ja laitettiin pitkään laatikkoon pölyn peittämiseksi. Kukaan ei testaa sitä tai säilytä sen merkitystä. Yleisin lause, jonka kuulen tullessani asiakkaan luo, on: "Suunnitelma on olemassa, mutta se on kehitetty kauan sitten, ei tiedetä, onko sitä testattu, on epäilys, että se ei toimi."
9. Liikaa vettä
Suunnitelmissa on viisi sivua pitkä johdanto, jossa on kuvaus edellytyksistä ja kiitos kaikille hankkeeseen osallistuneille sekä tietoa yrityksen toiminnasta. Kun vierität alas kymmenennelle sivulle, jolla on hyödyllistä tietoa, palvelinkeskuksesi on jo tulvinut.
Kun yrität lukea nykyhetkeä, mitä sinun tulee tehdä, jos palvelinkeskuksesi on tulvinut?
Aseta kaikki yrityksen "vesi" erilliseen asiakirjaan. Itse suunnitelman on oltava erittäin tarkka: tästä tehtävästä vastaava henkilö tekee tämän ja niin edelleen.
10. Kenen kustannuksella juhlat järjestetään?
Usein suunnitelmien laatijat eivät saa tukea yrityksen ylimmältä johdolta. Mutta tukea saa keskijohto, joka ei johda tai jolla ei ole tarvittavaa budjettia ja resursseja liiketoiminnan jatkuvuuden hallintaan. Esimerkiksi IT-osasto laatii BCP-suunnitelmansa budjettinsa puitteissa, mutta tietohallintojohtaja ei näe koko yrityskuvaa. Suosikkiesimerkkini on videoneuvottelu. Kun toimitusjohtajan videoneuvottelu ei toimi, kenen hän poistaa sisälmykset? Tietohallintojohtaja, joka "ei tarjonnut". Mikä siis CIO:n näkökulmasta on tärkeintä yrityksessä? Mistä ihmiset aina "rakastavat" häntä: videoneuvottelut, jotka muuttuvat välittömästi liiketoimintakriittisiksi järjestelmiksi. Ja liiketoiminnan näkökulmasta - no, ei VKS, ajattele vain, puhumme puhelimessa, kuten Brežnevin aikana...
Lisäksi IT-osasto on yleensä sitä mieltä, että sen päätehtävänä katastrofin sattuessa on yrityksen IT-järjestelmien toiminnan palauttaminen. Mutta joskus sinun ei tarvitse tehdä tätä! Jos on olemassa liiketoimintaprosessi, jossa tulostetaan paperipaloja hirvittävän kalliilla tulostimella, sinun ei pitäisi ostaa toista tällaista tulostinta varaosiksi ja sijoittaa se sen viereen, jos se rikkoutuu. Voi riittää, että paperinpalat värjätään väliaikaisesti käsin.
Jos rakennamme jatkuvaa suojausta IT:n sisällä, meidän on hankittava ylimmän johdon ja yritysten edustajien tuki. Muuten IT-osaston sisällä nukkeutumalla voit ratkaista tietyn joukon ongelmia, mutta ei kaikkia välttämättömiä.
Tältä tilanne näyttää, kun vain IT-osastolla on DR-suunnitelmat
10. Ei testausta
Jos suunnitelma on olemassa, se on testattava. Niille, jotka eivät tunne standardeja, tämä ei ole ollenkaan ilmeistä. Esimerkiksi "hätäuloskäynti" -kyltit roikkuvat kaikkialla. Mutta kerro minulle, missä on palokauhasi, koukkusi ja lapiosi? Missä paloposti on? Missä palosammutin tulisi sijoittaa? Mutta tämä pitäisi jokaisen tietää. Meistä ei tunnu ollenkaan loogiselta löytää sammutin toimistoon astuessa.
Ehkä suunnitelman testaamisen tarve pitäisi mainita itse suunnitelmassa, mutta tämä on kiistanalainen päätös. Joka tapauksessa suunnitelmaa voidaan pitää toimivana vain, jos se on testattu vähintään kerran. Kuten edellä mainittiin, kuulen hyvin usein: "Suunnitelma on olemassa, kaikki infrastruktuuri on valmis, mutta se ei ole tosiasia, että kaikki menee niin kuin suunnitelmassa on kirjoitettu. Koska he eivät testanneet sitä. Ei koskaan".
lopuksi
Jotkut yritykset voivat analysoida historiaansa ymmärtääkseen, millaisia ongelmia todennäköisesti tapahtuu ja kuinka todennäköisiä ne ovat. Tutkimus ja kokemus osoittavat, että emme voi suojautua kaikelta. Paskaa, ennemmin tai myöhemmin, tapahtuu mille tahansa yritykselle. Toinen asia on se, kuinka valmistautunut olet tähän tai vastaavaan tilanteeseen ja pystytkö palauttamaan yrityksesi ajoissa.
Jotkut ajattelevat, että jatkuvuus on sitä, miten kaikenlaiset riskit poistetaan, jotta ne eivät toteudu. Ei, kysymys on siitä, että riskit toteutuvat, ja olemme valmiita siihen. Sotilaat on koulutettu olemaan ajattelematta taistelussa, vaan toimimaan. Sama koskee BCP-suunnitelmaa: sen avulla voit palauttaa yrityksesi mahdollisimman nopeasti.
Ainoa laite, joka ei vaadi BCP:tä
Igor Tyukachev,
Liiketoiminnan jatkuvuuden konsultti
Tietojenkäsittelyjärjestelmien suunnittelukeskus
"Jet Infosystems"
Lähde: will.com