Najčešće zablude o BCM-u

Što je firma veća i IT infrastruktura složenija, to su zablude o kontinuitetu poslovanja opasnije — jer zvuče ubedljivije. "Imamo cloud backup" ili "sertifikovani smo" deluju kao dovoljan odgovor, dok se pravo stanje ne vidi dok se nešto stvarno ne pokvari. U ovom tekstu prolazimo kroz zablude koje najčešće viđamo kod većih kompanija, kroz primer firme sa ozbiljnijom, mešovitom infrastrukturom.

Zamišljena firma za ovaj tekst

Koristimo "Elektrotehnu" — proizvođača i distributera elektro opreme sa 520 zaposlenih, sedištem u Beogradu i dva regionalna skladišta. Imaju sopstveni data centar sa ERP sistemom i proizvodnim/skladišnim sistemima on-premise, a deo poslovanja je već prebačen u cloud: e-mail i kancelarijski alati (Microsoft 365), CRM aplikacija, i deo rezervnih kopija koji se čuva u cloud storage-u. Ova kombinacija — solidan on-premise sistem plus rastući deo u cloudu — je danas realnost za veliki broj srednjih i većih firmi u Srbiji, i tu se najviše zabluda i rađa.

Zabluda 1: "Imamo cloud backup, znači imamo kontinuitet"

Backup rešava jedan problem — da podaci nisu trajno izgubljeni. Ne rešava pitanje koliko brzo se vraćate u pogon, a to je ono što BCM zapravo meri.

Primer: Elektrotehna ima nightly backup ERP baze u cloud storage. Kad je server sa ERP-om otkazao zbog kvara diska, IT tim je krenuo da vraća bazu iz backupa — i otkrio da restore, zbog veličine baze i brzine njihove internet konekcije ka cloud provajderu, traje oko 30 sati. Niko to nikad ranije nije testirao, jer se backup samo pravio, nikad nije stvarno vraćan pod pritiskom. Trideset sati bez ERP-a za firmu ove veličine znači zaustavljenu fakturisanje, otpremu robe na oko i ozbiljan zastoj u proizvodnji.

Šta zapravo treba: definisati RTO (koliko brzo mora da se vrati sistem) i RPO (koliko podataka smete da izgubite) za svaki kritičan sistem, i onda testirati restore proces bar jednom godišnje da vidite da li backup strategija zaista zadovoljava taj cilj — ne samo da li backup fajl postoji.

Zabluda 2: "Cloud provajder se brine o kontinuitetu, mi ne moramo"

Ovo je verovatno najskuplja zabluda kod firmi koje sele deo poslovanja u cloud. Cloud provajder garantuje dostupnost svoje platforme (recimo, da Microsoft 365 servisi rade), ali ne garantuje da će vaši podaci unutar te platforme biti bezbedni od vaših sopstvenih grešaka.

Primer: zaposleni u prodaji u Elektrotehni je greškom obrisao veliki deo CRM baze klijenata dok je "čistio" duple zapise. Cloud CRM platforma je bila savršeno dostupna celo vreme — problem nije bio u provajderu, nego u tome što niko u firmi nije proverio da li CRM ima sopstveni, odvojen backup ili se oslanja samo na "recycle bin" provajdera koji čuva obrisane zapise samo 30 dana.

Šta zapravo treba: za svaki cloud servis koji koristite, proverite tzv. model podeljene odgovornosti (shared responsibility) — provajder je odgovoran za infrastrukturu, vi ste odgovorni za svoje podatke, konfiguraciju i greške korisnika. To znači da vam i za cloud servise treba plan, ne samo za on-premise sisteme.

Zabluda 3: "IT disaster recovery plan pokriva sve"

IT DR plan odgovara na pitanje "kako vraćamo servere". Ne odgovara na pitanje "šta rade ljudi u skladištu dok servera nema".

Primer: kad je ERP sistem bio nedostupan 30 sati (isti slučaj kao gore), magacin u Novom Sadu nije imao nikakvu papirnu proceduru za ručno beleženje otpreme robe. Vozači kamiona su čekali, jer niko nije znao da li sme da se izda roba bez sistema koji to evidentira. IT tim je bio potpuno fokusiran na vraćanje servera, dok je operativni deo firme jednostavno stao, bez ijedne alternative.

Šta zapravo treba: za svaki kritičan proces koji zavisi od IT sistema, treba postojati i ručna, papirna ili offline alternativa — makar privremena — koju osoblje zna da koristi. To nije IT-jev posao da napiše; to piše operativni menadžer skladišta, uz podršku BCM koordinatora.

Zabluda 4: "Imamo redundantne servere, znači smo pokriveni"

Redundantni hardver (dupli izvori napajanja, RAID diskovi, klaster serveri) štiti od kvara jednog komada opreme. Ne štiti od događaja koji pogađa ceo data centar odjednom.

Primer: Elektrotehnin data centar ima potpuno redundantan hardver — ali sve u istoj serverskoj sobi. Kad su tokom simulacije (o vežbama pišemo detaljnije kasnije u seriji) postavili pitanje "šta ako izbije požar u toj sobi", odgovor je bio — ništa od te redundancije ne pomaže, jer propada sve odjednom. Slično važi i za ransomware: ako su backup serveri stalno povezani na istu mrežu kao produkcioni sistemi, napad koji šifruje jedne može da šifruje i druge.

Šta zapravo treba: redundancija unutar jedne lokacije rešava kvarove opreme; za scenarije koji pogađaju celu lokaciju (požar, poplava, ransomware) potrebna je fizički ili logički odvojena kopija — druga lokacija ili izolovan (air-gapped) backup koji napadač ili požar ne mogu istovremeno da dohvate.

Zabluda 5: "BCM je posao IT sektora"

U firmama sa ozbiljnijim IT-jem, lako se desi da direktor prebaci ceo BCM projekat na CIO-a ili IT menadžera "jer se radi o sistemima". Rezultat je plan koji dobro pokriva servere, a potpuno zanemaruje ljude, dobavljače i komunikaciju.

Primer: u Elektrotehni je prvobitni BCM projekat vodio isključivo IT sektor. Plan je detaljno opisivao kako se ERP vraća iz backupa, ali nigde nije pisalo ko obaveštava ključne kupce o kašnjenju isporuke, niti ko donosi odluku da li se prelazi na ručne procedure u skladištu. Kad se incident desio, IT tim je uporno radio na tehničkom delu, dok je komercijala improvizovala komunikaciju sa klijentima bez ikakvog unapred dogovorenog teksta ili liste prioritetnih kupaca.

Šta zapravo treba: BCM projekat treba da vodi neko ko ima pregled cele firme (operacije, kvalitet, bezbednost), uz IT kao jednog od učesnika, ne kao vlasnika celog projekta. Svaki plan treba da ima i "ljudski" deo — ko odlučuje, ko komunicira, ko aktivira plan — ne samo tehnički.

Zabluda 6: "Plan koji smo napisali pre dve godine i dalje važi"

Infrastruktura se menja brže nego što se planovi ažuriraju — pogotovo u firmama koje postepeno sele delove poslovanja u cloud.

Primer: Elektrotehnin plan kontinuiteta za ERP je napisan kad je sistem bio isključivo on-premise. U međuvremenu je firma prebacila deo funkcionalnosti (izveštavanje i analitiku) na cloud nadogradnju istog ERP-a, ali plan i dalje navodi stari postupak i stare kontakt osobe od kojih je jedna u međuvremenu napustila firmu. Prilikom stvarnog incidenta, prva tri poziva po planu bila su ili pogrešnom broju ili osobi koja više ne radi taj posao.

Šta zapravo treba: plan treba pregledati posle svake značajnije promene infrastrukture (ne samo jednom godišnje po automatizmu), i uvek posle promene ključnih kontakt osoba. Dobra praksa je da se pregled plana formalno veže za IT change management proces — kad IT sektor menja sistem, automatski se postavlja pitanje "da li ovo utiče na plan kontinuiteta".

Zaključak

Zajednička nit svih ovih zabluda: svaka od njih zvuči kao razuman odgovor dok se ne testira pod pritiskom. Cloud backup, redundantni serveri i sertifikat su svi korisni — ali nijedan sam za sebe ne odgovara na pitanje "šta tačno radimo u prvih sat vremena kad nešto stvarno stane". Sledeći tekst u seriji prelazi na prvu klauzulu standarda — kontekst organizacije — i pokazuje kako se ove lekcije pretvaraju u konkretan, dokumentovan pristup.