Hei alle sammen, mitt navn er Igor Tyukachev og jeg er en forretningskontinuitetskonsulent. I dagens innlegg vil vi ha en lang og kjedelig diskusjon om vanlige sannheter. Jeg vil dele min erfaring og snakke om de viktigste feilene som bedrifter gjør når de utvikler en forretningskontinuitetsplan.
1. RTO og RPO tilfeldig
Den viktigste feilen jeg har sett er at restitusjonstid (RTO) er tatt ut av løse luften. Vel, ut av løse luften - for eksempel er det noen tall fra to år siden fra SLA som noen hentet fra sin forrige arbeidsplass. Hvorfor gjør de dette? Tross alt, i henhold til alle metoder, må du først analysere konsekvensene for forretningsprosesser, og basert på denne analysen, beregne målgjenopprettingstiden og akseptabelt tap av data. Men å gjøre en slik analyse tar noen ganger lang tid, noen ganger er det dyrt, noen ganger er det ikke veldig klart hvordan – legg vekt på hva som må gjøres. Og det første som kommer til å tenke på for mange er: «Vi er alle voksne og forstår hvordan virksomheten fungerer. La oss ikke kaste bort tid og penger! La oss ta pluss eller minus som det skal være. Ut av hodet, ved å bruke proletarisk oppfinnsomhet! La RTO være to timer.»
Hva fører dette til? Når du kommer til ledelsen for penger til aktiviteter for å sikre nødvendig RTO/RPO med visse tall, krever det alltid begrunnelse. Hvis det ikke er noen begrunnelse, oppstår spørsmålet: hvor har du det fra? Og det er ingenting å svare på. Som et resultat mister tilliten til arbeidet ditt.
Dessuten koster de to timene med restitusjon noen ganger en million dollar. Og å rettferdiggjøre varigheten av RTO er et spørsmål om penger, og veldig store.
Og til slutt, når du bringer BCP- og/eller DR-planen din til artistene (som faktisk vil løpe og vifte med armene i øyeblikket av ulykken), vil de stille et lignende spørsmål: hvor kom disse to timene fra? Og hvis du ikke kan forklare dette tydelig, vil de ikke ha tillit til verken deg eller dokumentet ditt.
Det viser seg å være et stykke papir for et stykke papirs skyld, en avmelding. Forresten, noen gjør dette bevisst, rett og slett for å tilfredsstille kravene til regulatoren.
Vel du forstår
2. Kuren mot alt
Noen mennesker tror at en BCP-plan er utviklet for å beskytte alle forretningsprosesser mot trusler. Nylig ble spørsmålet "Hva vil vi beskytte oss mot?" Jeg hørte svaret: "Alt og mer."
Men faktum er at planen kun er ment å beskytte spesifikk sentrale forretningsprosesser i selskapet fra spesifikk trusler. Derfor, før du utvikler en plan, er det nødvendig å vurdere forekomsten av risikoer og analysere deres konsekvenser for virksomheten. Risikovurdering er nødvendig for å forstå hvilke trusler selskapet er redd for. Ved bygningsskader vil det være én kontinuitetsplan, ved sanksjonspress – en annen, ved flom – en tredje. Selv to identiske steder i forskjellige byer kan ha vesentlig forskjellige planer.
Det er umulig å beskytte et helt selskap med én BCP, spesielt en stor. For eksempel begynte den enorme X5 Retail Group å sikre kontinuitet med to viktige forretningsprosesser (vi skrev om dette ). Og det er rett og slett urealistisk å omslutte hele selskapet med én plan; dette er fra kategorien "kollektivt ansvar", når alle er ansvarlige og ingen er ansvarlige.
ISO 22301-standarden inneholder konseptet med en policy, som faktisk kontinuitetsprosessen i selskapet starter med. Den beskriver hva vi skal beskytte og mot hva. Hvis folk kommer løpende og ber om å legge til dette og hint, for eksempel:
— La oss legge til BCP risikoen for at vi blir hacket?
eller
— Nylig, under regnet, ble toppetasjen vår oversvømmet - la oss legge til et scenario for hva vi skal gjøre i tilfelle flom?
Henvis dem deretter umiddelbart til denne policyen og si at vi beskytter spesifikke selskapsaktiva og bare mot spesifikke, forhåndsavtalte trusler, fordi de er prioritet nå.
Og selv om forslag til endringer faktisk er passende, så tilby å ta hensyn til dem i neste versjon av policyen. Fordi å beskytte et selskap koster mye penger. Så alle endringer i BCP-planen må gå gjennom budsjettkomiteen og planleggingen. Vi anbefaler å gjennomgå selskapets forretningskontinuitetspolicy en gang i året eller umiddelbart etter betydelige endringer i selskapets struktur eller eksterne forhold (kan leserne tilgi meg at jeg sier det).
3. Fantasier og virkelighet
Det hender ofte at når de utarbeider en BCP-plan, beskriver forfatterne et ideelt bilde av verden. For eksempel, "vi har ikke et ekstra datasenter, men vi vil skrive en plan som om vi gjør det." Eller virksomheten har ennå ikke en del av infrastrukturen, men ansatte vil likevel legge den til planen i håp om at den dukker opp i fremtiden. Og så vil selskapet strekke virkeligheten inn på planen: bygge et nytt datasenter, beskrive andre endringer.
Til venstre er infrastrukturen som tilsvarer BCP, til høyre er den virkelige infrastrukturen
Alt dette er en feil. Å skrive en BCP-plan betyr å bruke penger. Hvis du skriver en plan som ikke fungerer akkurat nå, vil du betale for veldig dyrt papir. Det er umulig å komme seg fra det, det er umulig å teste det. Det viser seg å være arbeid for arbeidets skyld.
Du kan skrive en plan ganske raskt, men å bygge en backup-infrastruktur og bruke penger på alle beskyttelsesløsninger er lang og dyrt. Dette kan ta mer enn ett år. Og det kan vise seg at du allerede har en plan, og infrastrukturen for den vil dukke opp om to år. Hvorfor trengs en slik plan? Hva vil det beskytte deg mot?
Det er også en fantasi når BCP-utviklingsteamet begynner å finne ut for ekspertene hva de skal gjøre og til hvilken tid. Den kommer fra kategorien: «Når du ser en bjørn i taigaen, må du svinge i motsatt retning fra bjørnen og løpe med en hastighet som overstiger bjørnens hastighet. I vintermånedene må du dekke til sporene dine.»
4. Topper og røtter
Den fjerde viktigste feilen er å gjøre planen enten for overfladisk eller for detaljert. Vi trenger en gylden middelvei. Planen skal ikke være for detaljert for idioter, men den bør ikke være for generell slik at noe slikt ender opp:
På lett generelt
5. Til Cæsar - hva er Cæsars, til mekanikeren - hva er mekaniker.
Den neste feilen stammer fra den forrige: én plan kan ikke imøtekomme alle handlinger for alle ledelsesnivåer. BCP-planer er vanligvis utviklet for store selskaper med store økonomiske strømmer (forresten, ifølge vår 48 % av store russiske selskaper møtte i gjennomsnitt nødsituasjoner som medførte betydelige økonomiske tap) og et styringssystem på flere nivåer. For slike selskaper er det ikke verdt å prøve å få alt inn i ett dokument. Hvis selskapet er stort og strukturert, bør planen ha tre separate nivåer:
- strategisk nivå - for toppledelsen;
- taktisk nivå - for mellomledere;
- og det operative nivået - for de som er direkte involvert i felten.
For eksempel, hvis vi snakker om å gjenopprette en mislykket infrastruktur, på det strategiske nivået tas beslutningen om å aktivere gjenopprettingsplanen, på det taktiske nivået kan prosessprosedyrene beskrives, og på det operasjonelle nivået er det instruksjoner for igangsettingsspesifikke utstyrsdeler.
BCP uten budsjett
Alle ser sitt ansvarsområde og forbindelser med andre ansatte. I øyeblikket av en ulykke åpner alle en plan, finner raskt sin del og følger den. Ideelt sett må du huske utenat hvilke sider du skal åpne, for noen ganger teller minuttene.
6. Rollespill
En annen feil når du utarbeider en BCP-plan: det er ikke nødvendig å inkludere spesifikke navn, e-postadresser og annen kontaktinformasjon i planen. I teksten til selve dokumentet skal kun upersonlige roller angis, og disse rollene skal tildeles navnene på de som er ansvarlige for spesifikke oppgaver, og deres kontakter skal være oppført i vedlegget til planen.
Hvorfor?
I dag bytter de fleste jobb hvert annet til tredje år. Og hvis du skriver ned alle de ansvarlige og deres kontakter i teksten til planen, må den hele tiden endres. Og i store selskaper, og spesielt offentlige, krever hver endring av ethvert dokument massevis av godkjenninger.
For ikke å nevne at hvis en nødssituasjon oppstår og du må febrilsk bla gjennom planen og lete etter den rette kontakten, vil du miste dyrebar tid.
Life hack: Når du endrer en applikasjon, trenger du ofte ikke engang å godkjenne den. Et annet tips: du kan bruke automatiseringssystemer for planoppdatering.
7. Mangel på versjonering
Vanligvis lager de en plan versjon 1.0, og gjør deretter alle endringer uten redigeringsmodus og uten å endre filnavnet. Samtidig er det ofte uklart hva som har endret seg i forhold til forrige versjon. I mangel av versjonering lever planen sitt eget liv, som ikke spores på noen måte. Den andre siden av enhver BCP-plan bør angi versjonen, forfatteren av endringene og en liste over selve endringene.
Ingen kan finne ut av det lenger
8. Hvem bør jeg spørre?
Ofte har ikke bedrifter en person som er ansvarlig for BCP-planen, og det er ingen egen avdeling som er ansvarlig for forretningskontinuitet. Dette ærefulle ansvaret er tildelt CIO, hans stedfortreder, eller i henhold til prinsippet "du har med informasjonssikkerhet å gjøre, så her er BCP i tillegg." Som et resultat er planen utviklet, avtalt og godkjent, fra topp til bunn.
Hvem er ansvarlig for å lagre planen, oppdatere og revidere informasjonen i den? Dette kan ikke foreskrives. Å ansette en egen medarbeider til dette er bortkastet, men å laste en av de eksisterende med tilleggsoppgaver er selvfølgelig mulig, fordi alle nå streber etter effektivitet: «La oss henge en lykt på ham slik at han kan klippe om natten», men er det nødvendig?
Vi ser etter ansvarlige for BCP to år etter opprettelsen
Derfor skjer det ofte slik: en plan ble utviklet og lagt i en lang boks for å bli dekket med støv. Ingen tester det eller opprettholder dets relevans. Den vanligste setningen jeg hører når jeg kommer til en kunde er: "Det er en plan, men den ble utviklet for lenge siden, om den ble testet er ukjent, det er en mistanke om at den ikke fungerer."
9. For mye vann
Det er planer hvor introduksjonen er på fem sider, inkludert beskrivelse av forutsetninger og takk til alle deltakere i prosjektet, med informasjon om hva bedriften driver med. Innen du ruller ned til den tiende siden, hvor det er nyttig informasjon, har datasenteret ditt allerede blitt oversvømmet.
Når du prøver å lese opp til øyeblikket, hva bør du gjøre hvis datasenteret ditt er oversvømmet?
Plasser alt bedriftens "vann" i et eget dokument. Selve planen må være ekstremt spesifikk: den ansvarlige for denne oppgaven gjør dette, og så videre.
10. På hvis bekostning er banketten?
Ofte har ikke planskapere støtte fra toppledelsen i selskapet. Men det er støtte fra mellomledelsen som ikke klarer eller ikke har det nødvendige budsjettet og ressursene til å styre forretningskontinuiteten. For eksempel oppretter IT-avdelingen sin BCP-plan innenfor sitt budsjett, men IT-sjefen ser ikke hele bedriftsbildet. Mitt favoritteksempel er videokonferanser. Når administrerende direktørs videokonferanser ikke fungerer, hvem skal han ta ut innvollene? CIOen som "ikke ga." Derfor, fra CIOs synspunkt, hva er det viktigste i selskapet? Det folk alltid "elsker" ham for: videokonferanser, som umiddelbart blir til et forretningskritisk system. Og fra et forretningsmessig synspunkt - vel, ingen VKS, bare tenk, vi snakker på telefon, som under Brezhnev ...
I tillegg tenker IT-avdelingen vanligvis at hovedoppgaven i tilfelle en katastrofe er å gjenopprette driften av bedriftens IT-systemer. Men noen ganger trenger du ikke å gjøre dette! Hvis det er en forretningsprosess i form av å skrive ut papirbiter på en fryktelig dyr skriver, bør du ikke kjøpe en annen slik skriver som reserve og plassere den ved siden av den i tilfelle et sammenbrudd. Det kan være nok å midlertidig fargelegge papirbitene for hånd.
Hvis vi bygger kontinuerlig beskyttelse innen IT, må vi få støtte fra toppledelsen og forretningsrepresentanter. Ellers, etter å ha forpuppet seg inne i IT-avdelingen, kan du løse en viss rekke problemer, men ikke alle de nødvendige.
Slik ser situasjonen ut når kun IT-avdelingen har DR-planer
10. Ingen testing
Hvis det er en plan, må den testes. For de som ikke er kjent med standardene, er dette slett ikke åpenbart. For eksempel har du "nødutgang"-skilt hengende overalt. Men fortell meg, hvor er brannbøtte, krok og spade? Hvor er brannhydranten? Hvor skal brannslukningsapparatet stå? Men alle burde vite dette. Det virker ikke logisk for oss i det hele tatt å finne et brannslukningsapparat når vi går inn på et kontor.
Kanskje behovet for å teste planen bør nevnes i selve planen, men dette er en kontroversiell avgjørelse. I alle fall kan en plan anses å fungere bare hvis den er testet minst én gang. Som nevnt ovenfor hører jeg veldig ofte: «Det er en plan, all infrastruktur er forberedt, men det er ikke et faktum at alt vil gå som det står i planen. Fordi de ikke testet det. Aldri".
i konklusjonen
Noen selskaper kan analysere historien deres for å forstå hva slags problemer som sannsynligvis vil skje og hvor sannsynlige de er. Forskning og erfaring tyder på at vi ikke kan beskytte oss mot alt. Shit, før eller siden, skjer med ethvert selskap. En annen ting er hvor forberedt du vil være på denne eller en lignende situasjon og om du vil være i stand til å gjenopprette virksomheten din i tide.
Noen tror at kontinuitet handler om hvordan man kan eliminere alle slags risikoer slik at de ikke materialiserer seg. Nei, poenget er at risiko vil materialisere seg, og vi skal være klare for dette. Soldater er opplært til å ikke tenke i kamp, men til å handle. Det er det samme med en BCP-plan: den vil tillate deg å gjenopprette virksomheten din så raskt som mulig.
Det eneste utstyret som ikke krever BCP
Igor Tyukachev,
Konsulent for forretningskontinuitet
Senter for design av datasystemer
"Jet infosystemer"
Kilde: www.habr.com