Hola a tots, em dic Igor Tyukachev i sóc consultor de continuïtat del negoci. En el post d'avui farem un llarg i tediós debat de veritats comunes, vull compartir la meva experiència i parlar dels principals errors que cometen les empreses a l'hora d'elaborar un pla de continuïtat del negoci.
1. RTO i RPO a l'atzar
L'error més important que he vist és que el temps de recuperació (RTO) es treu de la nada. Bé, de la nada, per exemple, hi ha alguns números de fa dos anys del SLA que algú va portar del seu lloc de treball anterior. Per què fan això? Al cap i a la fi, segons tots els mètodes, primer heu d'analitzar les conseqüències dels processos empresarials i, a partir d'aquesta anàlisi, calcular el temps de recuperació objectiu i la pèrdua de dades acceptable. Però fer una anàlisi d'aquest tipus de vegades porta molt de temps, de vegades és car, de vegades no està molt clar com, posa l'accent en què s'ha de fer. I el primer que ve al cap a molts és: “Tots som adults i entenem com funciona el negoci. No perdem temps i diners! Prenem més o menys com ha de ser. Fora del teu cap, fent servir l'enginy proletari! Que el RTO sigui de dues hores".
A què comporta això? Quan s'arriba a la gestió per diners per a activitats per garantir el RTO/RPO requerit amb determinats números, sempre requereix una justificació. Si no hi ha justificació, sorgeix la pregunta: d'on l'heu tret? I no hi ha res a respondre. Com a resultat, es perd la confiança en la seva feina.
A més, de vegades aquestes dues hores de recuperació costen un milió de dòlars. I justificar la durada de l'RTO és una qüestió de diners, i molt grans.
I finalment, quan porteu el vostre pla BCP i/o DR als intèrprets (que en realitat estaran corrent i agitant els braços en el moment de l'accident), aquests faran una pregunta semblant: d'on han sortit aquestes dues hores? I si no pots explicar-ho amb claredat, no tindran confiança ni en tu ni en el teu document.
Resulta que és un paper pel fet d'un paper, una baixa. Per cert, alguns ho fan deliberadament, simplement per satisfer els requisits del regulador.
Bé, ho entens
2. La cura per a tot
Algunes persones creuen que es desenvolupa un pla BCP per protegir tots els processos empresarials de qualsevol amenaça. Recentment, la pregunta "De què ens volem protegir?" Vaig sentir la resposta: "Tot i més".
Però el fet és que el pla només pretén protegir específic processos de negoci clau de l'empresa a partir específic amenaces. Per tant, abans d'elaborar un pla, cal avaluar l'ocurrència de riscos i analitzar-ne les conseqüències per al negoci. L'avaluació de riscos és necessària per entendre de quines amenaces té por l'empresa. En cas de destrucció d'edificis hi haurà un pla de continuïtat, en cas de pressió sancionadora -un altre, en cas d'inundació- un tercer. Fins i tot dos llocs idèntics a diferents ciutats poden tenir plans significativament diferents.
És impossible protegir una empresa sencera amb un BCP, especialment un de gran. Per exemple, l'enorme X5 Retail Group va començar a garantir la continuïtat amb dos processos de negoci clau (vam escriure sobre això ). I és simplement poc realista tancar tota l'empresa amb un sol pla, això és de la categoria de "responsabilitat col·lectiva", quan tothom és responsable i ningú és responsable.
La norma ISO 22301 conté el concepte de política, amb la qual, de fet, s'inicia el procés de continuïtat a l'empresa. Descriu què protegirem i de què. Si la gent ve corrent i demana afegir això i allò, per exemple:
— Afegim a BCP el risc de ser piratejats?
O
— Recentment, durant la pluja, el nostre pis superior es va inundar; afegim un escenari de què fer en cas d'inundació?
Aleshores, immediatament els referiu a aquesta política i digueu que protegim els actius específics de l'empresa i només d'amenaces específiques acordades prèviament, perquè ara són la prioritat.
I fins i tot si les propostes de canvis són realment adequades, oferiu-les a tenir-les en compte a la següent versió de la política. Perquè protegir una empresa costa molts diners. Per tant, tots els canvis al pla BCP han de passar per la comissió de pressupostos i la planificació. Recomanem revisar la política de continuïtat del negoci de l'empresa una vegada a l'any o immediatament després de canvis significatius en l'estructura de l'empresa o en les condicions externes (que els lectors em perdonin per dir-ho).
3. Fantasies i realitat
Sovint passa que quan elaboren un pla BCP, els autors descriuen una imatge ideal del món. Per exemple, "no tenim un segon centre de dades, però escriurem un pla com si ho tinguéssim". O el negoci encara no disposa d'alguna part de la infraestructura, però els empleats encara l'afegiran al pla amb l'esperança que aparegui en el futur. I llavors l'empresa estirarà la realitat al pla: construir un segon centre de dades, descriure altres canvis.
A l'esquerra hi ha la infraestructura corresponent a BCP, a la dreta la infraestructura real
Tot això és un error. Escriure un pla BCP significa gastar diners. Si escriviu un pla que no funciona ara mateix, pagareu un paper molt car. És impossible recuperar-se'n, és impossible provar-ho. Resulta que és feina pel bé de la feina.
Podeu escriure un pla amb força rapidesa, però construir una infraestructura de còpia de seguretat i gastar diners en totes les solucions de protecció és llarg i costós. Això pot trigar més d'un any. I pot resultar que ja teniu un pla, i la infraestructura per aquest apareixerà d'aquí a dos anys. Per què és necessari un pla així? De què et protegirà?
També és una fantasia quan l'equip de desenvolupament de BCP comença a esbrinar per als experts què han de fer i en quin moment. Prové de la categoria: “Quan veus un ós a la taigà, has de girar en sentit contrari a l'ós i córrer a una velocitat superior a la de l'ós. Durant els mesos d'hivern, heu de cobrir les vostres pistes".
4. Cims i arrels
El quart error més important és fer que el pla sigui massa superficial o massa detallat. Necessitem un mitjà d'or. El pla no hauria de ser massa detallat per als idiotes, però no hauria de ser massa general perquè acabi una cosa així:
A fàcil en general
5. Al Cèsar - el que és del Cèsar, al mecànic - el que és del mecànic.
El següent error prové de l'anterior: un pla no pot acollir totes les accions per a tots els nivells de gestió. Els plans BCP es desenvolupen normalment per a grans empreses amb grans fluxos financers (per cert, segons el nostre , de mitjana, el 48% de les grans empreses russes es van trobar amb situacions d'emergència que van comportar importants pèrdues financeres) i un sistema de gestió multinivell. Per a aquestes empreses, no val la pena intentar encaixar-ho tot en un sol document. Si l'empresa és gran i estructurada, el pla hauria de tenir tres nivells separats:
- nivell estratègic - per a la direcció superior;
- nivell tàctic - per a directius intermedis;
- i el nivell operatiu, per als que estan directament implicats en el camp.
Per exemple, si estem parlant de restaurar una infraestructura fallida, a nivell estratègic es pren la decisió d'activar el pla de recuperació, a nivell tàctic es poden descriure els procediments del procés i a nivell operatiu hi ha instruccions per posar en marxa peces d'equip.
BCP sense pressupost
Tothom veu la seva àrea de responsabilitat i les connexions amb altres empleats. En el moment d'un accident, tothom obre un pla, troba ràpidament la seva part i la segueix. L'ideal és recordar de memòria quines pàgines obrir, perquè de vegades els minuts compten.
6. Joc de rol
Un altre error a l'hora d'elaborar un pla BCP: no cal incloure noms concrets, adreces de correu i altres dades de contacte al pla. En el propi text del document només s'han d'indicar els rols impersonals, i aquests rols s'han d'assignar els noms dels responsables de tasques concretes i els seus contactes s'han d'enumerar a l'annex del pla.
Per què?
Avui dia, la majoria de la gent canvia de feina cada dos o tres anys. I si anoteu tots els responsables i els seus contactes al text del pla, s'haurà de canviar constantment. I a les grans empreses, i especialment a les governamentals, cada canvi a qualsevol document requereix un munt d'aprovacions.
Sense oblidar que si es produeix una emergència i has de fullejar frenèticament el pla i buscar el contacte adequat, perdràs un temps preciós.
Life hack: quan canvies una aplicació, sovint ni tan sols cal que l'aprovis. Un altre consell: podeu utilitzar sistemes d'automatització d'actualització del pla.
7. Manca de versions
Normalment creen un pla versió 1.0, i després fan tots els canvis sense el mode d'edició i sense canviar el nom del fitxer. Al mateix temps, sovint no està clar què ha canviat en comparació amb la versió anterior. En absència de versions, el pla viu la seva pròpia vida, que no es fa un seguiment de cap manera. La segona pàgina de qualsevol pla de BCP ha d'indicar la versió, l'autor dels canvis i una llista dels mateixos canvis.
Ja ningú ho pot esbrinar
8. A qui he de preguntar?
Sovint, les empreses no tenen una persona responsable del pla BCP i no hi ha cap departament independent que sigui responsable de la continuïtat del negoci. Aquesta honorable responsabilitat s'assigna al CIO, el seu adjunt, o segons el principi "tu tractes amb la seguretat de la informació, així que aquí hi ha BCP a més". Com a resultat, el pla s'elabora, s'acorda i s'aprova, de dalt a baix.
Qui és responsable d'emmagatzemar el pla, actualitzar i revisar la informació que hi ha? Això pot no estar prescrit. Contractar un empleat independent per a això és un malbaratament, però carregar un dels existents amb tasques addicionals és possible, és clar, perquè ara tothom s'esforce per l'eficiència: "Pengem-li una llanterna perquè pugui segar a la nit", però és necessari?
Busquem responsables de BCP dos anys després de la seva creació
Per tant, sovint passa així: es va elaborar un pla i es va posar en una caixa llarga per cobrir-se de pols. Ningú el prova ni manté la seva rellevància. La frase més habitual que escolto quan arribo a un client és: "Hi ha un pla, però es va desenvolupar fa molt de temps, no se sap si es va provar, hi ha la sospita que no funciona".
9. Massa aigua
Hi ha plànols en què la introducció és de cinc pàgines, amb una descripció dels requisits previs i agraïment a tots els participants del projecte, amb informació sobre què fa l'empresa. Quan us desplaceu cap avall fins a la desena pàgina, on hi ha informació útil, el vostre centre de dades ja s'ha inundat.
Quan intenteu llegir fins al moment, què heu de fer si el vostre centre de dades està inundat?
Col·loqueu tota l'"aigua" corporativa en un document separat. El pla en si ha de ser extremadament específic: el responsable d'aquesta tasca ho fa, etc.
10. A qui costa el banquet?
Sovint, els creadors de plans no compten amb el suport de la direcció superior de l'empresa. Però hi ha suport de la direcció mitjana que no gestiona o no disposa del pressupost i dels recursos necessaris per gestionar la continuïtat del negoci. Per exemple, el departament de TI crea el seu pla BCP dins del seu pressupost, però el CIO no veu tota la imatge de l'empresa. El meu exemple preferit és la videoconferència. Quan la videoconferència del CEO no funcioni, a qui eviscerarà? El CIO que "no va proporcionar". Per tant, des del punt de vista del CIO, què és el més important de l'empresa? El que la gent sempre l'estima: la videoconferència, que de seguida es converteix en un sistema crític per a l'empresa. I des del punt de vista empresarial: bé, no VKS, només penseu, parlarem per telèfon, com sota Brezhnev...
A més, el departament informàtic acostuma a pensar que la seva tasca principal en cas de desastre és restablir el funcionament dels sistemes informàtics corporatius. Però de vegades no cal fer això! Si hi ha un procés empresarial en forma d'impressió de trossos de paper en una impressora molt cara, no hauríeu de comprar una segona impressora com a recanvi i col·locar-la al costat en cas d'avaria. Pot ser suficient per pintar temporalment els trossos de paper a mà.
Si estem construint una protecció contínua dins de les TI, hem de comptar amb el suport de l'alta direcció i representants empresarials. En cas contrari, després d'haver pupat dins del departament d'informàtica, podeu resoldre una sèrie de problemes, però no tots els necessaris.
Així es veu la situació quan només el departament informàtic té plans de DR
10. Sense proves
Si hi ha un pla, s'ha de provar. Per a aquells que no estan familiaritzats amb els estàndards, això no és gens obvi. Per exemple, teniu rètols de "sortida d'emergència" penjats per tot arreu. Però digueu-me, on és el vostre cub de foc, el vostre ganxo i la vostra pala? On és la boca d'incendis? On s'ha d'ubicar l'extintor? Però això ho hauria de saber tothom. No ens sembla gens lògic trobar un extintor en entrar a una oficina.
Potser s'hauria d'esmentar la necessitat de provar el pla al mateix pla, però aquesta és una decisió controvertida. En qualsevol cas, només es pot considerar que un pla funciona si s'ha provat almenys una vegada. Com s'ha dit anteriorment, escolto molt sovint: “Hi ha un pla, tota la infraestructura està preparada, però no és un fet que tot surti com està escrit al pla. Perquè no ho van provar. Mai".
en conclusió
Algunes empreses poden analitzar la seva història per entendre quin tipus de problemes poden passar i quina probabilitat són. La investigació i l'experiència suggereixen que no podem protegir-nos de tot. Una merda, tard o d'hora, li passa a qualsevol empresa. Una altra cosa és com estaràs preparat per a aquesta o una situació semblant i si podràs restaurar el teu negoci a temps.
Hi ha qui pensa que la continuïtat és com eliminar tot tipus de riscos perquè no es materialitzin. No, la qüestió és que els riscos es materialitzaran, i estarem preparats per a això. Els soldats estan entrenats no per pensar en la batalla, sinó per actuar. Passa el mateix amb un pla BCP: et permetrà restaurar el teu negoci el més aviat possible.
L'únic equip que no requereix BCP
Igor Tyukachev,
Consultor de Continuïtat de Negoci
Centre de Disseny de Sistemes Informàtics
"Jet Infosystems"
Font: www.habr.com