Tema broja, uvodni članak: Neprekinutost poslovanja

Prvenstveno poslovni problem

Kada poslovno rukovodstvo nije voljno sudjelovati u promišljanju informatičke strategije tvrtke, uključujući i business continuity, informatika sama preuzima odgovornost za business continuity planiranje. Tada može doći do neželjenih posljedica.
Ako ništa drugo, zbog takvog pristupa svjedočimo situacijama u kojima poslovna rukovodstva imaju pogrešnu sliku o tome što je business continuity i pogrešnu sliku o vlastitom business continuity rješenju, kada vrlo često pogrešno drže:
- kako se sve to tiče samo informatike te kako su business continuity rješenja tek preskupa igračka za informatičare
- kako tvrtka ima pravo business continuity rješenje (iako možda ima samo diskovni poslužitelj preslikan na pričuvnu lokaciju)

Potrebno je naglasiti kako je business continuity prije svega poslovni problem i zadatak, a tek nakon toga informatički.

Business continuity opisuje procedure i postupke koje organizacija/tvrtka definira u cilju očuvanja najvažnijih poslovnih funkcija tvrtke za vrijeme i nakon katastrofe. Business continuity planiranje ima zadaću osigurati neprekinutu dostupnost upravo onih najvažnijih, odabranih servisa te osigurati ponovnu uspostavu pune funkcionalnosti tvrtke što je prije moguće.  
Business continuity plan uzima u obzir procese, ljude, zgrade, sustave i sve vanjske elemente koji mogu utjecati na sposobnost funkcioniranja tvrtke u slučaju raznih scenarija katastrofe.
Disaster Recovery plan možemo promatrati kao logičan IT-centričan podskup Business Continuity procesa. No, niti Disaster Recovery plan nije moguće kvalitetno napraviti bez suradnje s poslovnim rukovodstvom.

Ciljevi Business Continuity plana
Idealni put ka Business Continuityu (kroz Disaster Recovery plan) počinje kroz proces identificiranja ciljeva Business Continuity plana u 3 koraka:

1. analiza rizika (risk analysis):
- identifikacija i prioritiziranje poslovnih funkcija i sredstava od ključnog značaja za operativnost tvrtke
- definicija vjerojatnosti nastajanja opasnosti po ključne funkcije i sredstva
- definicija ciljeva i strategije za izbjegavanje/minimiziranje posljedica

2. analiza utjecaja na poslovanje (business impact analysis – BIA):
BIA mora identificirati i definirati operativni, financijski i administrativni utjecaj nedostupnosti pojedine funkcionalnosti ili sredstva (npr. ako knjigovodstvo ne funkcionira zbog nedostupnosti informacija tvrtka može ostati bez prijeko potrebne gotovine; izgubljeni klijenti se neće vratiti; poslovni ugled može biti narušen itd.…). Koraci ka BIA-i su:
a) Identifikacija ključnih IT resursa:
Napraviti procjenu poslovnih procesa i odgovarajućih IT sustava (ključne funkcije koriste odgovarajuće poslovne procese koji koriste odgovarajuće IT resurse: HW, SW, podatke, mrežu…)
b) Identifikacija utjecaja mogućih problema na poslovanje i  određivanje prihvatljivog vremena bez servisa:
definirati utjecaj nedostupnosti nekog servisa u odnosu na odabrane poslovne procese
c) Definicija prioriteta oporavka:
Definirati prihvatljivo vrijeme bez pojedinog servisa. Ovaj proces mora uključiti komunikaciju/konsenzus više dijelova tvrtke. Konsenzus se mora postići oko «strategija oporavka» koje treba prioritizirati, razviti i implementirati tijekom aktivacije Business Continuity plana. Na primjer, ako je procjena kako određeni poslovni proces mora biti obnovljen u roku od 5 sati, Business Continuity plan mora predvidjeti mjere za ispunjenje tog zahtjeva.

3. analiza spremnosti za Business Continuity:
Ocjena stanja sadašnjeg Business Continuity rješenja (početno stanje) od kojeg se gradi novo, savršenije rješenje na osnovu analize rizika i analize utjecaja na poslovanje:
- prikupljanje Ključnih pokazatelja performansi – Key Performance Indicators/KPI (primjeri):
a) proceduralni:
- Trajanje sadašnjeg backup-a (trajanje raste? opada?)
- Vrijeme oporavka, vrijeme potrebno za prebacivanje rada s jedne lokacije na drugu
- Prosječno vrijeme odziva
- Prosječno vrijeme rješavanja problema
b) financijski:
- cijena komunikacije između dvije lokacije; kakva je komunikacija potrebna
- koliko podataka treba kopirati s lokacije na lokaciju
- postotak rasta potreba za diskovnim prostorom


Na kraju, za svaki od odabranih poslovnih funkcija (pa tako i poslovnih procesa, tj. IT servisa i pripadajućih IT resursa) dobijemo RPO/RTO/NRO zahtjeve:
- Recovery Time Objective (RTO): Koliko dugo možemo/smijemo izdržati bez naše funkcionalnosti/procesa? Koliko vremena sebi dajemo za obnovu pune aktivnosti?
- Recovery Point Objective (RPO): Koliku količinu podataka (ili, bolje rečeno, koliko sekundi/minuta/sati unosa podataka) smijemo «izgubiti» te iznova izraditi u trenutku kad je sustav ponovo dostupan?
- Network Recovery Objective (NRO): Koliko vremena imamo za oporavak naših komunikacijskih servisa? (uzalud će nam biti dostupnost serverskih servisa ako ne radi mreža preko koje im pristupamo)


Disaster Recovery plan (DRP)
Tek kad smo utvrdili ciljeve Business Continuity plana, moguće je krenuti ka Disaster Recovery planu (DRP):

Disaster Recovery lan je IT-centričan plan namijenjen obnovi funkcionalnosti IT sustava (HW, SW aplikacija) na pričuvnoj lokaciji nakon katastrofe.
Disaster Recovery plan uključuje definiranje strategije zamjene sustava, mrežnih resursa, klijentskih resursa u slučaju neplaniranog prekida (katastrofe). Plan je zasnovan na klasifikaciji sustava (funkcionalnosti, procesa, uključujući i IT resurse).

Sustavi (HW, SW, mrežni i klijentski resursi, aplikacije, podaci) su klasificirani:
a) prema relativnoj važnosti za tvrtku (BIA)
b) prema vremenu potrebnom za oporavak (RTO, NRO)
c) prema količini podataka koje smijemo «izgubiti» (RPO)

Disaster Recovery plan tiče se (ali nije ograničen na):
- Izvršnog rukovodstva
- Upravljanja operacijama
- Upravljanja s IT sigurnošću
- Sistem arhitekata i inženjera
- Sistem administratora
- Klijenata (unutrašnjih i vanjskih) koji koriste IT servise
- Administratora aplikacija i baza podataka

Kako se radi o širokom spektru zainteresiranih, DRP bi trebao biti pisan jezikom razumljivim i za ne-tehničku publiku. DRP opisuje uloge, odgovornost i specifične postupke za obnovu/oporavak IT okoliša nakon neplaniranog prestanka funkcionalnosti. DRP može pokrivati prestanak rada pojedinog sustava, pojedine IT lokacije ili cjelokupnog IT servisa.

Uobičajeni sadržaj Disaster recovery plana je sljedeći:
1. Koncept DRP-a: definira svrhu i sadržaj DRP-a
2. Faza Obavještavanja/Aktiviranja DRP-a: opisuje način komunikacije i donošenja odluka tijekom ili odmah nakon katastrofe. Uključene komponente su:
- alarmiranje/komunikacija
- procjena kvara/štete
- aktiviranje DRP-a
3. Faza oporavka: opisuje plan reaktiviranja sustava na pričuvnoj lokaciji (odabrani HW/SW/Network sustavi moraju biti uspostavljeni, odabrane aplikacije pokrenute, odabrani podaci ponovno dostupni)
4. Faza povratka u standardni način rada: definira procedure potrebne za povratak na stanje prije katastrofe (izvorna lokacija, svi servisi aktivni, svi podaci dostupni, svi klijenti imaju punu funkcionalnost)

Kvaliteta DRP dokumentacije je od izuzetnog značaja za upotrebljivost Disaster Recovery plana. Isto tako, kvaliteta uvoda u DRP – poslovnog dijela analize (analiza rizika, analiza utjecaja na poslovanje, analiza spremnosti za BC) jako utječe i na kvalitetu DRP-a i na cijenu budućeg konkretnog Disaster Recovery rješenja.
Završna poruka je vrlo jednostavna: pametno Business Continuity planiranje najbolja je investicija u kvalitetno i optimalno Business Continuity rješenje. Također, ukoliko imate kvalitetan DRP, lakše ćete i bolje pregovarati s potencijalnim izvođačima Disaster Recovery rješenja.