ISO 22301 – Klauzula 4.4: Sistem upravljanja kontinuitetom poslovanja (BCMS)

U jednoj rečenici: sve što ste do sada uradili — kontekst, zainteresovane strane, obuhvat — i sve što sledi treba da funkcioniše kao povezan sistem koji se stalno vrti i unapređuje, a ne kao gomila odvojenih dokumenata koji sede u fascikli.

Šta klauzula zapravo traži

Tekst standarda je kratak: organizacija treba da uspostavi, primeni, održava i kontinuirano unapređuje BCMS, uključujući procese koji su potrebni i njihovu međusobnu povezanost, u skladu sa zahtevima standarda. Iza ove naizgled uopštene rečenice krije se konkretna poenta — BCMS nisu izolovani dokumenti (BIA izveštaj, registar rizika, plan kontinuiteta) koji postoje nezavisno jedan od drugog. To je sistem u kom rezultat jednog procesa hrani sledeći: analiza uticaja na poslovanje određuje šta je kritično, procena rizika određuje šta preti tim kritičnim stvarima, strategija određuje kako da se odgovori, planovi to razrađuju, vežbe proveravaju da li planovi rade, a rezultati vežbi se vraćaju nazad u preispitivanje i unapređenje sistema.

Zašto je ovo bitno

Ovo je klauzula koja razdvaja firmu koja "ima papire" od firme koja zaista ima funkcionalan sistem. Vrlo je moguće proći kroz sve prethodne korake — popisati kontekst, zainteresovane strane, obuhvat, čak i napisati planove — a da rezultat i dalje bude gomila nepovezanih dokumenata koje niko ne ažurira kad se nešto promeni. Klauzula 4.4 postavlja standard da sistem mora da bude živ: kad se promeni kontekst (4.1), to se mora odraziti na procenu rizika; kad vežba pokaže da plan ne radi, to mora da vodi ka konkretnoj izmeni, ne samo ka zapisniku koji se arhivira.

Primer iz prakse: Elektrotehna

Elektrotehna je prvih šest meseci imala tačno onaj problem koji ova klauzula pokušava da spreči. BIA izveštaj je pokazao da je ERP sistem najkritičniji proces. Nezavisno od toga, registar rizika (urađen mesec dana kasnije, od strane drugog tima) je identifikovao zavisnost od jedinog tehničara koji zna da podesi glavnu proizvodnu liniju kao rizik visokog prioriteta. Ni jedan od ta dva nalaza nije stigao do budžetskog plana za narednu godinu — jednostavno zato što niko nije imao definisan proces koji povezuje "šta smo otkrili" sa "šta ćemo uraditi povodom toga".

Kad je BCM koordinator to primetio, rešenje nije bilo pisanje još dokumenata, nego uspostavljanje jednostavnog kvartalnog ciklusa: svaki kvartal, BCM koordinator sastavlja kratak pregled — šta je novo u kontekstu firme, da li je BIA i dalje tačna, da li je registar rizika ažuran, koji planovi su testirani a koji nisu — i taj pregled ide direktno na sledeći sastanak rukovodstva (klauzula 9.3) kao stalna tačka dnevnog reda. Tek tada je obuka novog tehničara za glavnu proizvodnu liniju, prepoznata kao rizik mesecima ranije, konačno ušla u godišnji plan obuka.

Smernice za dokumentaciju

Za ovu klauzulu ne pravite poseban, izdvojen dokument — umesto toga, pobrinite se da svi drugi dokumenti BCMS-a jasno upućuju jedan na drugi. Dobra praksa je jednostavna tabela ili dijagram procesa koji pokazuje redosled i veze: kontekst → BIA → procena rizika → strategija → planovi → vežbe → preispitivanje → (nazad na kontekst, ako se nešto promenilo). Ovaj pregled ne mora biti složen — jedna strana koja pokazuje ko šta ažurira i kada je dovoljna da dokaže da sistem zaista funkcioniše kao celina, a ne kao skup nezavisnih zadataka.

Najčešća greška

Najčešća greška je tretiranje BCMS-a kao liste dokumenata koje treba "otkačiti" — imamo BIA, imamo registar rizika, imamo plan, gotovo. Bez definisanog procesa koji povezuje nalaze jednog koraka sa akcijom u sledećem, svaki od tih dokumenata brzo zastari i sistem prestaje da bude sistem. Druga česta greška, posebno kod firmi koje već imaju drugi sertifikovan sistem upravljanja (na primer ISO 9001 ili ISO 27001), jeste građenje potpuno odvojenog BCMS-a od nule, umesto povezivanja sa postojećim procesima preispitivanja i unapređenja koji već postoje u firmi — što nepotrebno duplira posao i otežava održavanje.