ISO 22301 – Klauzula 8.5: Program vežbi

U jednoj rečenici: plan koji nikad nije testiran je samo pretpostavka na papiru — ova klauzula traži da firma redovno, kroz smišljen program različitih vežbi, proverava da li planovi zaista rade, i to dokumentuje dovoljno ozbiljno da se iz svake vežbe nešto konkretno nauči i popravi.

Šta klauzula zapravo traži

Organizacija treba da sprovodi vežbe i testove koji su usklađeni sa obuhvatom i ciljevima BCMS-a, zasnovani na odgovarajućim, dobro planiranim scenarijima sa dogovorenim ciljevima, i koji, posmatrano kroz vreme, potvrđuju kompletnost svih dogovora o kontinuitetu poslovanja — ne samo jedan omiljeni scenario iznova i iznova. Vežbe treba da minimiziraju rizik od stvarnog prekida poslovanja tokom samog testiranja, da proizvedu formalizovan izveštaj sa nalazima, preporukama i radnjama za unapređenje, i da se sprovode u planiranim intervalima, kao i kad god dođe do značajnije promene u organizaciji ili njenom okruženju.

Zašto je ovo bitno

Kroz ovu seriju smo već videli nekoliko primera šta vežbe otkrivaju kad se rade ozbiljno: da je ovlašćenje za aktivaciju plana nejasno kad je BCM koordinator odsutan (klauzula 5.3), da magacin nema papirnu proceduru (klauzula 7.3), da zamenik tehničara zna teoriju ali ne i praksu (klauzula 7.2), da redundantni serveri ne pomažu kod požara (klauzula 8.1). Nijedan od ovih nalaza nije mogao da se otkrije čitanjem plana — samo njegovim testiranjem pod uslovima koji makar delimično oponašaju stvarnu krizu.

Tipovi vežbi — od najlakših do najzahtevnijih

Standard ne propisuje tačno koje vrste vežbi morate koristiti, ali u praksi se koristi spektar od lakših ka zahtevnijim:

• Diskusiona (tabletop) vežba: grupa ljudi sedi za stolom i prolazi kroz hipotetički scenario korak po korak, govoreći šta bi uradili — nema stvarnog prekidanja rada, samo razgovor i provera da li plan ima logičke rupe.
• Orijentaciona vežba: detaljniji obilazak plana, često uz upoznavanje novih članova tima sa procedurama, bez simulacije stvarnog događaja.
• Simulacija: realističniji scenario, može biti delimično ili potpuno nenajavljen, gde učesnici stvarno preduzimaju korake (na primer, stvarno pozivaju kontakte sa liste, stvarno prelaze na papirnu proceduru) — ovde se najviše otkrivaju stvarni nedostaci.
• Puna (live) vežba: stvarna aktivacija tehničkog rešenja — na primer, stvaran restore sistema iz backupa, sa merenjem stvarnog vremena, ne samo razgovorom o tome koliko bi trebalo da traje.

Detaljan primer: godišnji program vežbi Elektrotehne

Umesto da se svake godine ponavlja ista, jednostavna vežba, Elektrotehna je sastavila program koji tokom godine pokriva različite planove i različite tipove vežbi, tako da se kroz vreme testira ceo sistem, ne samo jedan njegov deo:

Kvartal	Tip vežbe	Scenario i cilj
Q1	Diskusiona (tabletop)	Ransomware napad na ERP — cilj: proveriti da li krizni tim zna redosled koraka i da li je komunikacioni plan (klauzula 7.4) logički potpun, bez stvarnog prekidanja sistema
Q2	Simulacija, nenajavljena, noćna smena	Kvar na proizvodnoj liniji 2 — cilj: proveriti stvarnu kompetentnost zamenskog tehničara i brzinu aktivacije prelaska na liniju 1 (ovo je vežba opisana u tekstu o klauzuli 7.2)
Q3	Puna (live) vežba	Stvaran restore ERP sistema iz lokalnog backupa, na test okruženju — cilj: izmeriti stvaran RTO i RPO i uporediti sa ciljevima od 8 i 4 sata (klauzula 6.2)
Q4	Simulacija sa spoljnim partnerom	Aktivacija dogovora o uzajamnoj pomoći sa partnerskim magacinom — cilj: proveriti da li dogovoreni postupak (klauzula 8.3) zaista funkcioniše u praksi, ne samo na papiru ugovora

Ovakav raspored obezbeđuje da se tokom jedne godine testiraju i tehnički sistemi (Q3), i ljudi pod pritiskom (Q2), i logika planova bez stvarnog rizika (Q1), i saradnja sa spoljnim stranama (Q4) — tačno ono što standard traži kad kaže da vežbe, posmatrane kroz vreme, treba da potvrde kompletnost celog sistema.

Kako se minimizira rizik tokom same vežbe

Test iz Q3 (stvaran restore ERP sistema) nosi realan rizik da sama vežba izazove problem koji pokušava da spreči. Elektrotehna to rešava tako što se restore radi na odvojenom test okruženju, ne na produkcionom sistemu, u terminu van radnog vremena, uz unapred dogovorenu "stop reč" koju bilo ko od učesnika može da izgovori ako primeti da vežba stvarno ugrožava produkcione podatke — nakon čega se vežba odmah prekida bez daljih pitanja.

Primer post-vežbovnog izveštaja (Q3 — test restore ERP sistema)

Posle sprovedene vežbe, sastavlja se kratak, formalan izveštaj. Evo kako je izgledao za test iz trećeg kvartala:

• Rezultat: stvaran RTO iznosio je 6 sati i 40 minuta — bolje od ciljanih 8 sati.
• Nalaz: RPO je u jednom trenutku iznosio skoro 5 sati izgubljenih podataka, umesto ciljanih 4, zbog toga što je poslednja sinhronizacija backupa bila izvršena neposredno pre simuliranog prekida, a ne odmah nakon njega — vremenski razmak između sinhronizacija nije bio dovoljno gust da uvek garantuje 4-časovni RPO.
• Preporuka: skratiti interval sinhronizacije lokalnog backupa sa 4 na 2 sata, čime se realno garantovani RPO smanjuje bez obzira na trenutak prekida.
• Radnja: IT menadžer zadužen da implementira izmenu u roku od mesec dana, uz ponovni test pri sledećem godišnjem ciklusu vežbi.

Ovaj nalaz nikad ne bi bio otkriven čitanjem plana ili teorijskom procenom — samo stvarnim merenjem tokom vežbe.

Vežbe van planiranog rasporeda

Pored redovnog godišnjeg programa, dodatna vežba se organizuje kad dođe do značajnije promene — na primer, posle migracije dela ERP-a u cloud opisane u klauzuli 6.3, planirana je posebna vežba specifično za novi, cloud-bazirani deo sistema, umesto da se čeka na sledeći redovni ciklus.

Smernice za dokumentaciju

Za svaku vežbu treba voditi: scenario i ciljeve definisane unapred, spisak učesnika, izmereni rezultat (gde je primenjivo, konkretan broj — vreme oporavka, ne utisak "prošlo je dobro"), nalaze i preporuke, i konkretne radnje sa odgovornom osobom i rokom. Ovi izveštaji se čuvaju u centralnom registru (klauzula 7.5) i direktno hrane kvartalno preispitivanje (klauzula 9.3) i proces unapređenja (klauzula 10).

Najčešća greška

Najčešća greška je oslanjanje isključivo na diskusione (tabletop) vežbe godinama unazad, jer su najjeftinije i najmanje ometaju redovan rad — ali upravo zato i najmanje otkrivaju stvarne probleme, poput razlike između teorijskog i stvarnog RPO-a koju je Elektrotehna otkrila tek kroz pravi tehnički test. Druga česta greška je sprovođenje vežbe bez formalnog izveštaja i bez konkretnih radnji posle nje — vežba se odradi, svi kažu da je bilo korisno, i sledeće godine se otkriju potpuno isti problemi jer ništa iz prethodne vežbe nikad nije zvanično zatvoreno.