Salutare tuturor, numele meu este Igor Tyukachev și sunt consultant în continuitatea afacerii. În postarea de astăzi vom avea o discuție lungă și plictisitoare despre adevăruri comune.Vreau să împărtășesc experiența mea și să vorbesc despre principalele greșeli pe care companiile le fac atunci când elaborează un plan de continuitate a afacerii.
1. RTO și RPO la întâmplare
Cea mai importantă greșeală pe care am văzut-o este că timpul de recuperare (RTO) este scos din aer. Ei bine, din aer - de exemplu, există niște numere de acum doi ani din SLA pe care cineva le-a adus de la locul de muncă anterior. De ce fac asta? La urma urmei, conform tuturor metodelor, trebuie mai întâi să analizați consecințele asupra proceselor de afaceri și, pe baza acestei analize, să calculați timpul țintă de recuperare și pierderea acceptabilă de date. Dar a face o astfel de analiză uneori durează mult, uneori este costisitor, uneori nu este foarte clar cum - subliniați ceea ce trebuie făcut. Și primul lucru care vine în minte pentru mulți este: „Toți suntem adulți și înțelegem cum funcționează afacerile. Să nu pierdem timp și bani! Să luăm plus sau minus așa cum ar trebui. Din cap, folosind ingeniozitatea proletarului! Lăsați RTO să dureze două ore.”
La ce duce asta? Când veniți la management pentru bani pentru activități pentru a asigura RTO/RPO necesar cu anumite numere, este întotdeauna nevoie de justificare. Dacă nu există nicio justificare, atunci se pune întrebarea: de unde ai luat-o? Și nu e nimic de răspuns. Ca urmare, încrederea în munca ta este pierdută.
În plus, uneori, acele două ore de recuperare costă un milion de dolari. Iar justificarea duratei RTO este o chestiune de bani, și chiar foarte mari.
Și, în sfârșit, când veți aduce planul dvs. BCP și/sau DR artiștilor (care de fapt vor alerga și vor flutura brațele în momentul accidentului), aceștia vor pune o întrebare similară: de unde au venit aceste două ore? Și dacă nu puteți explica acest lucru clar, atunci ei nu vor avea încredere nici în dumneavoastră, nici în documentul dumneavoastră.
Se dovedește a fi o bucată de hârtie de dragul unei bucăți de hârtie, o dezabonare. Apropo, unii fac acest lucru în mod deliberat, pur și simplu pentru a satisface cerințele autorității de reglementare.
Păi ai înțeles
2. Leacul pentru toate
Unii oameni cred că un plan BCP este dezvoltat pentru a proteja toate procesele de afaceri de orice amenințări. Recent, întrebarea „De ce vrem să ne protejăm?” Am auzit răspunsul: „Totul și mai mult”.
Dar adevărul este că planul este destinat doar să protejeze specific procesele cheie de afaceri ale companiei din specific amenințări. Prin urmare, înainte de a elabora un plan, este necesar să se evalueze apariția riscurilor și să se analizeze consecințele acestora pentru afacere. Evaluarea riscurilor este necesară pentru a înțelege de ce amenințări se teme compania. În cazul distrugerii clădirii va exista un plan de continuitate, în caz de presiune de sancțiune - altul, în caz de inundație - un al treilea. Chiar și două site-uri identice din orașe diferite pot avea planuri semnificativ diferite.
Este imposibil să protejezi o întreagă companie cu un singur BCP, mai ales cu unul mare. De exemplu, imensul X5 Retail Group a început să asigure continuitatea cu două procese cheie de afaceri (am scris despre acest lucru
Standardul ISO 22301 conține conceptul de politică, cu care, de fapt, începe procesul de continuitate în companie. Descrie ce vom proteja și de ce. Dacă oamenii vin alergând și cer să adauge asta și asta, de exemplu:
— Să adăugăm la BCP riscul să fim piratați?
sau
— Recent, în timpul ploii, ultimul nostru etaj a fost inundat - să adăugăm un scenariu despre ce să facem în caz de inundație?
Apoi trimiteți-i imediat la această politică și spuneți că protejăm activele specifice ale companiei și numai de amenințări specifice, convenite în prealabil, pentru că acestea sunt prioritatea acum.
Și chiar dacă propunerile de modificări sunt într-adevăr adecvate, atunci oferiți-vă să le luați în considerare în următoarea versiune a politicii. Pentru că protejarea unei companii costă mulți bani. Deci, toate modificările aduse planului BCP trebuie să treacă prin comitetul bugetar și prin planificare. Vă recomandăm să revizuiți politica de continuitate a afacerii a companiei o dată pe an sau imediat după schimbări semnificative în structura companiei sau în condițiile externe (fie ca cititorii să mă ierte că spun asta).
3. Fantezii și realitate
Se întâmplă adesea ca, atunci când elaborează un plan BCP, autorii descriu o imagine ideală a lumii. De exemplu, „nu avem un al doilea centru de date, dar vom scrie un plan ca și cum am avea.” Sau afacerea nu are încă o parte din infrastructură, dar angajații o vor adăuga în continuare la plan în speranța că va apărea în viitor. Și apoi compania va întinde realitatea pe plan: construiește un al doilea centru de date, descrie alte schimbări.
În stânga este infrastructura corespunzătoare BCP, în dreapta este infrastructura reală
Totul este o greșeală. A scrie un plan BCP înseamnă a cheltui bani. Dacă scrieți un plan care nu funcționează acum, veți plăti pentru hârtie foarte scumpă. Este imposibil să-ți revii din ea, este imposibil să-l testezi. Se dovedește a fi muncă de dragul muncii.
Puteți scrie un plan destul de repede, dar construirea unei infrastructuri de rezervă și cheltuirea banilor pentru toate soluțiile de protecție este lungă și costisitoare. Acest lucru poate dura mai mult de un an. Și se poate dovedi că aveți deja un plan, iar infrastructura pentru acesta va apărea în doi ani. De ce este nevoie de un astfel de plan? De ce te va proteja?
Este, de asemenea, o fantezie când echipa de dezvoltare a BCP începe să-și dea seama pentru experți ce ar trebui să facă și în ce timp. Provine din categoria: „Când vezi un urs în taiga, trebuie să te întorci în direcția opusă față de urs și să alergi cu o viteză care depășește viteza ursului. În timpul lunilor de iarnă, trebuie să-ți acoperi urmele.”
4. Vârfuri și rădăcini
A patra cea mai importantă greșeală este să faci planul fie prea superficial, fie prea detaliat. Avem nevoie de un mijloc de aur. Planul nu ar trebui să fie prea detaliat pentru idioți, dar nu trebuie să fie prea general pentru ca așa ceva să ajungă:
Pe ușor în general
5. Către Cezar - ce este al lui Cezar, mecanicului - ce este al mecanicului.
Următoarea greșeală provine din cea anterioară: un plan nu poate găzdui toate acțiunile pentru toate nivelurile de management. Planurile BCP sunt de obicei dezvoltate pentru companiile mari cu fluxuri financiare mari (apropo, conform noastre
- nivel strategic - pentru conducerea superioară;
- nivel tactic - pentru manageri de mijloc;
- iar nivelul operaţional – pentru cei implicaţi direct în domeniu.
De exemplu, dacă vorbim de refacerea unei infrastructuri eșuate, atunci la nivel strategic se ia decizia de a activa planul de recuperare, la nivel tactic se pot descrie procedurile de proces, iar la nivel operațional există instrucțiuni de punere în funcțiune specifice. piese de echipament.
BCP fără buget
Toată lumea își vede zona de responsabilitate și conexiunile cu alți angajați. În momentul unui accident, fiecare își deschide un plan, își găsește rapid rolul și îl urmează. În mod ideal, trebuie să vă amintiți pe de rost ce pagini să deschideți, pentru că uneori minutele contează.
6. Joc de rol
O altă greșeală la întocmirea unui plan BCP: nu este nevoie să includeți în plan nume specifice, adrese de e-mail și alte informații de contact. În textul documentului în sine, trebuie să fie indicate doar rolurile impersonale, iar acestor roluri ar trebui să li se atribuie numele responsabililor pentru sarcini specifice, iar contactele acestora ar trebui enumerate în anexa la plan.
De ce?
Astăzi, majoritatea oamenilor își schimbă locul de muncă la fiecare doi sau trei ani. Și dacă notați toți cei responsabili și contactele lor în textul planului, atunci acesta va trebui schimbat în mod constant. Și în companiile mari, și în special în cele guvernamentale, fiecare modificare a oricărui document necesită o mulțime de aprobări.
Ca să nu mai vorbim că dacă apare o urgență și trebuie să răsfoiți frenetic planul și să cauți contactul potrivit, vei pierde timp prețios.
Life Hack: atunci când schimbi o aplicație, adesea nici nu trebuie să o aprobi. Un alt sfat: puteți utiliza sisteme de automatizare pentru actualizarea planului.
7. Lipsa versiunilor
De obicei, ei creează un plan versiunea 1.0 și apoi fac toate modificările fără modul de editare și fără a schimba numele fișierului. În același timp, este adesea neclar ce s-a schimbat în comparație cu versiunea anterioară. În absența versiunii, planul își trăiește propria viață, care nu este urmărită în niciun fel. A doua pagină a oricărui plan BCP ar trebui să indice versiunea, autorul modificărilor și o listă a modificărilor în sine.
Nimeni nu-și mai poate da seama
8. Pe cine ar trebui să întreb?
Adesea, companiile nu au o persoană responsabilă pentru planul BCP și nu există un departament separat care să fie responsabil pentru continuitatea afacerii. Această responsabilitate onorabilă este atribuită CIO, adjunctul său sau conform principiului „tu te ocupi cu securitatea informațiilor, așa că iată în plus BCP”. Ca urmare, planul este elaborat, convenit și aprobat, de sus în jos.
Cine este responsabil pentru stocarea planului, actualizarea și revizuirea informațiilor din acesta? Este posibil să nu fie prescris. Angajarea unui angajat separat pentru aceasta este o risipă, dar încărcarea unuia dintre cele existente cu sarcini suplimentare este posibilă, desigur, pentru că toată lumea se străduiește acum pentru eficiență: „Să agățăm un felinar de el, ca să poată cosi noaptea”, dar este necesar?
Căutăm responsabili pentru BCP la doi ani de la crearea sa
Prin urmare, se întâmplă adesea așa: un plan a fost elaborat și pus într-o cutie lungă pentru a se acoperi cu praf. Nimeni nu-l testează sau nu-i menține relevanța. Cea mai frecventă expresie pe care o aud când vin la un client este: „Există un plan, dar a fost dezvoltat cu mult timp în urmă, nu se știe dacă a fost testat, există suspiciunea că nu funcționează”.
9. Prea multă apă
Există planuri în care introducerea are cinci pagini, inclusiv o descriere a condițiilor preliminare și mulțumiri tuturor participanților la proiect, cu informații despre ceea ce face compania. În momentul în care derulați în jos până la a zecea pagină, unde există informații utile, centrul dvs. de date a fost deja inundat.
Când încercați să citiți până la momentul actual, ce ar trebui să faceți dacă centrul dvs. de date este inundat?
Puneți toată „apa” corporativă într-un document separat. Planul în sine trebuie să fie extrem de specific: persoana responsabilă pentru această sarcină face acest lucru și așa mai departe.
10. Pe cheltuiala cui este banchetul?
Adesea, creatorii de planuri nu au sprijin din partea conducerii de top a companiei. Există însă sprijin din partea managementului mediu care nu gestionează sau nu dispune de bugetul și resursele necesare pentru a gestiona continuitatea afacerii. De exemplu, departamentul IT își creează planul BCP în limita bugetului său, dar CIO nu vede întreaga imagine a companiei. Exemplul meu preferat este videoconferința. Când videoconferința a CEO-ului nu funcționează, pe cine va eviscera? CIO care „nu a furnizat”. Prin urmare, din punctul de vedere al CIO, care este cel mai important lucru din companie? Ceea ce oamenii îl „iubesc” mereu: videoconferința, care se transformă imediat într-un sistem critic pentru afaceri. Și din punct de vedere al afacerilor - ei bine, fără VKS, gândiți-vă, vom vorbi la telefon, ca sub Brejnev...
În plus, departamentul IT crede de obicei că sarcina sa principală în caz de dezastru este de a restabili funcționarea sistemelor IT corporative. Dar uneori nu trebuie să faci asta! Dacă există un proces de afaceri sub formă de tipărire a bucăților de hârtie pe o imprimantă teribil de scumpă, atunci nu ar trebui să cumpărați oa doua astfel de imprimantă ca rezervă și să o puneți lângă ea în cazul unei defecțiuni. Poate fi suficient să colorați temporar bucățile de hârtie manual.
Dacă construim o protecție continuă în cadrul IT, trebuie să obținem sprijinul managementului superior și al reprezentanților afacerilor. În caz contrar, pupând în interiorul departamentului IT, puteți rezolva o anumită gamă de probleme, dar nu pe toate cele necesare.
Așa arată situația când doar departamentul IT are planuri DR
10. Fără testare
Dacă există un plan, acesta trebuie testat. Pentru cei care nu sunt familiarizați cu standardele, acest lucru nu este deloc evident. De exemplu, aveți semne de „ieșire de urgență” agățate peste tot. Dar spune-mi, unde îți sunt găleata de foc, cârligul și lopata? Unde este hidrantul de incendiu? Unde ar trebui să fie amplasat stingătorul de incendiu? Dar toată lumea ar trebui să știe asta. Nu ni se pare deloc logic să găsim un stingător la intrarea într-un birou.
Poate că necesitatea de a testa planul ar trebui menționată în planul în sine, dar aceasta este o decizie controversată. În orice caz, un plan poate fi considerat funcțional doar dacă a fost testat cel puțin o dată. După cum am menționat mai sus, aud foarte des: „Există un plan, toată infrastructura este pregătită, dar nu este un fapt că totul va funcționa așa cum este scris în plan. Pentru că nu l-au testat. Nu".
în concluzie
Unele companii își pot analiza istoria pentru a înțelege ce fel de probleme pot apărea și cât de probabil sunt acestea. Cercetările și experiența sugerează că nu ne putem proteja de orice. Rahatul, mai devreme sau mai târziu, se întâmplă oricărei companii. Un alt lucru este cât de pregătit vei fi pentru această situație sau pentru o situație similară și dacă îți vei putea restabili afacerea la timp.
Unii oameni cred că continuitatea este despre cum să eliminăm tot felul de riscuri, astfel încât acestea să nu se materializeze. Nu, ideea este că riscurile se vor materializa și vom fi pregătiți pentru asta. Soldații sunt instruiți să nu gândească în luptă, ci să acționeze. La fel este și cu un plan BCP: vă va permite să vă restabiliți afacerea cât mai repede posibil.
Singurul echipament care nu necesită BCP
Igor Tyukachev,
Consultant pentru continuitatea afacerii
Centrul de proiectare a sistemelor de calcul
„Jet Infosystems”
Sursa: www.habr.com