ISO 22301 – Klauzula 6.3: Planiranje promena u BCMS-u

U jednoj rečenici: kad menjate sam sistem kontinuiteta poslovanja — ne poslovanje firme, nego strukturu, obuhvat ili ciljeve samog BCMS-a — ta promena mora biti smišljena i kontrolisana, a ne slučajna posledica neke druge odluke o kojoj niko iz BCM tima nije ni znao.

Šta klauzula zapravo traži

Standard traži da se, kad organizacija odredi potrebu za promenom BCMS-a, ta promena sprovede na planiran način. To znači da se pre same promene razmotri: zašto se menja i šta bi mogle biti posledice, kako se čuva celovitost sistema tokom promene, da li ima dovoljno resursa da se promena sprovede kako treba, i kako se preraspoređuju odgovornosti i ovlašćenja ako promena to zahteva.

Zašto je ovo bitno

Ova klauzula postoji zato što se sistemi retko sruše zbog jedne velike, dramatične greške — mnogo češće se polako raspadaju kroz niz malih, nepovezanih promena o kojima niko sa BCM strane nije ni pitan. Firma promeni dobavljača, doda novu lokaciju, premesti deo sistema u cloud, restrukturira odeljenje — svaka od tih odluka ima smisla sama za sebe, ali ako se BCM tim ne uključi u trenutku odlučivanja, sistem kontinuiteta poslovanja tiho zaostaje za stvarnošću firme, tačno onako kako je opisano u primeru zastarelog plana iz teksta o najčešćim zabludama.

Primer iz prakse: Elektrotehna

Elektrotehna je planirala da premesti i finansijski/knjigovodstveni modul ERP sistema u cloud, kao nastavak migracije koja je već delimično započeta. Ranije, slična odluka (migracija dela izveštavanja u cloud, pomenuta u tekstu o klauzuli 4.4) doneta je bez ikakvog uključivanja BCM koordinatora, i posledica je bila plan koji je i dalje opisivao stare, tada već netačne procedure.

Ovog puta, promena je sprovedena drugačije. Pre nego što je IT sektor krenuo sa migracijom, BCM koordinator je uključen u inicijalno planiranje projekta i postavio je nekoliko konkretnih pitanja:

• Uticaj na RTO: da li novi cloud servis nudi isto ili brže vreme oporavka od trenutnog cilja od 8 sati, ili treba prilagoditi cilj i plan?
• Vlasništvo plana: da li IT menadžer, dosadašnji vlasnik plana za ERP, i dalje ima potrebno znanje za novi, cloud-bazirani deo sistema, ili treba uključiti dodatnu osobu upoznatu sa cloud platformom?
• Novi rizici: da li ovo uvodi novu zavisnost (cloud provajder finansijskog modula) koju treba dodati u registar rizika iz klauzule 8.2?
• Resursi za sprovođenje: da li postojeći budžet i vreme predviđeno za migraciju uključuje i vreme potrebno da se ažuriraju planovi i sprovede novo testiranje, ili to treba dodatno predvideti?

Rezultat je bio da je migracija odložena za tri nedelje u odnosu na prvobitni plan — dovoljno da se plan kontinuiteta za finansijski modul ažurira paralelno sa samom migracijom, umesto da se to radi naknadno, posle što se ispostavi da je nešto zaboravljeno. Tri nedelje kašnjenja u projektu bile su mnogo jeftinije od otkrivanja praznine u planu tokom stvarnog incidenta.

Smernice za dokumentaciju

Nije potreban poseban, obiman proces upravljanja promenama — dovoljno je da postoji jasna tačka u postojećim projektnim ili IT change management procesima gde se eksplicitno postavlja pitanje: "da li ova promena utiče na sistem kontinuiteta poslovanja, i ako da, ko sa BCM strane treba da bude uključen". Kad se promena zaista sprovede, korisno je kratko zabeležiti šta je promenjeno u BCMS-u kao rezultat (koji plan, koji rizik, koja odgovornost) i kada.

Najčešća greška

Najčešća greška je tretiranje BCM tima kao nekog ko se obaveštava posle odluke, ne pre nje — promene u infrastrukturi, organizaciji ili dobavljačima se dešavaju, a BCM dokumentacija se "sredi" tek kad neko primeti da je zastarela, često tokom pripreme za audit ili, gore, tokom stvarnog incidenta. Druga česta greška je da se promena BCMS-a (na primer, promena obuhvata ili ciljeva) sprovede bez razmišljanja o tome ko sada treba da bude odgovoran za novi deo sistema, pa novododata lokacija ili proces ostane bez jasnog vlasnika plana mesecima.