ISO 22301 – Klauzula 8.2 (deo 1): Analiza uticaja na poslovanje (BIA)
U jednoj rečenici: BIA je proces u kom za svaki poslovni proces pratite kako se šteta od prekida menja tokom vremena, pronalazite tačku posle koje ta šteta postaje neprihvatljiva, i na osnovu toga određujete koliko brzo proces mora da se vrati u funkciju.
Šta klauzula zapravo traži
Standard traži formalan, dokumentovan proces koji radi četiri stvari:
- postavlja kriterijume za procenu uticaja — ovo smo već uradili u klauzuli 8.1,
- procenjuje kako uticaj raste tokom vremena ako neki proces ne radi,
- određuje rok do kog proces mora ponovo da proradi, pre nego što šteta postane neprihvatljiva,
- popisuje šta je procesu potrebno da bi uopšte mogao da radi — ljude, prostor, tehnologiju, informacije, dobavljače.
Tri pojma koja se lako pomešaju: MTPD, RTO i RPO
Pre nego što odemo na primer, vredi razjasniti razliku između tri skraćenice koje ćete sretati kroz ostatak serije, jer se lako pomešaju.
Šta znači "neprihvatljivo"? Kad proces stane, šteta raste — prvo polako, pa sve brže. Neprihvatljivo je tačka posle koje ta šteta prestaje da bude "skupo, ali popravljivo" i postaje nešto što firma teško može da vrati nazad — raskinut ugovor, trajno izgubljen klijent, nepopravljivo pomešani podaci, ugrožena bezbednost ljudi. Ta granica nije osećaj — najbolje je kad se oslanja na konkretne, tvrde tačke: kad tačno ugovor dozvoljava klijentu da ga raskine, kad tačno zakon nalaže prijavu, kad tačno gubici počinju da ugrožavaju opstanak firme.
MTPD (Maximum Tolerable Period of Disruption) je upravo ta granica — trenutak posle kog je šteta neprihvatljiva. Zamislite je kao ivicu litice.
RTO (Recovery Time Objective) je cilj koji sami sebi postavljate — koliko brzo želite da se proces vrati u funkciju. RTO se uvek postavlja jasno ispred MTPD, sa sigurnosnom marginom, iz jednostavnog razloga: ne možete biti savršeno precizni. Plan koji je na vežbi trajao 6 sati može pod stvarnim stresom, noću, uz jednu otežavajuću okolnost više, potrajati i duže. Ako biste cilj postavili tačno na ivicu litice (na samu MTPD), svako odstupanje od plana bi vas gurnulo preko granice. RTO zato uvek ostavlja prostor za grešku.
RPO (Recovery Point Objective) je treći, malo drugačiji pojam — odnosi se samo na podatke, ne na vreme rada procesa. Govori koliko podataka sme da se izgubi, izraženo u vremenu od poslednje sačuvane kopije. Ako pravite bekap na svaka 4 sata, RPO vam je najviše 4 sata — u najgorem slučaju, izgubićete podatke unete u poslednja 4 sata pre prekida.
Zašto se RTO uopšte "podešava", a ne samo izračunava? Zato što na njega utiču dve odvojene stvari koje moraju da se poklope: s jedne strane, MTPD kaže "moraš biti gotov pre ove granice", a s druge strane, tehnička i organizaciona stvarnost kaže "ovo je najbrže što trenutno realno možemo da postignemo". RTO je kompromis između te dve granice — postavljen ispod MTPD, ali i realno dostižan sa resursima koje firma ima ili planira da nabavi.
Pažnja: ovo nije isto što i kriterijum iz klauzule 8.1
U prethodnom tekstu, Elektrotehna je odredila da se proces smatra "kritičnim" ako prekid duži od 8 sati izazove gubitak preko 500.000 dinara. Taj broj (8 sati) je opšti filter za ceo BCMS — pravilo koje kaže "ovaj proces zaslužuje detaljnu BIA analizu". To nije isto što i MTPD ili RTO za pojedinačni proces. Svaki proces dobija sopstveni MTPD i RTO tek kroz BIA opisanu u ovom tekstu, i ti brojevi mogu biti sasvim drugačiji od 8 sati — videćete da je kod nabavke sirovina MTPD meren nedeljama, ne satima.
Kako se RTO određuje — četiri koraka
- Napravite krivu uticaja tokom vremena. Za posmatrani proces, opišite šta se dešava na više vremenskih tačaka — 1 sat, 4 sata, 24 sata, nekoliko dana. Ovo je tabela koju gradite kroz razgovor sa ljudima koji taj proces stvarno rade.
- Pronađite MTPD. Na toj krivoj, tražite prvu tvrdu, konkretnu granicu — ugovorni rok, zakonski rok, tačku posle koje se šteta više ne može vratiti. To je vaš MTPD.
- Proverite šta je realno izvodljivo. Koliko brzo se proces trenutno može vratiti u funkciju sa postojećim resursima? Ovo je "pod" ispod kog RTO ne može ići bez dodatnog ulaganja.
- Postavite RTO između to dvoje, sa marginom. RTO treba da bude jasno ispod MTPD (ne na samoj granici) i realno dostižan. Ako je razlika prevelika — na primer, MTPD je 8 sati a trenutni realni oporavak traje 30 — to je signal da treba uložiti u brže rešenje (o tome pišemo u klauzuli 8.3).
Detaljan primer: određivanje RTO za ERP sistem, korak po korak
Korak 1 — kriva uticaja:
| Vreme prekida | Uticaj |
|---|---|
| 1 sat | Zanemarljiv — zaposleni čekaju, nema merljive štete |
| 4 sata | Kašnjenje fakturisanja, magacin počinje ručno beleženje otpreme |
| 8 sati | Prelazi prag od 500.000 dinara gubitka (kriterijum iz 8.1) — ozbiljno, ali još uvek popravljivo |
| 24 sata | Prva tvrda granica: aktiviraju se ugovorni penali kod dva ključna klijenta (0,5% dnevno, utvrđeno u klauzuli 4.2) |
| 3 dana | MTPD: ručno uneti podaci i sistemski podaci počinju da se razilaze na način koji se teško usklađuje — šteta postaje strukturna, ne samo finansijska |
Korak 2 — MTPD: Elektrotehna je odredila MTPD na oko 3 dana (72 sata) — ne zato što je to "osećaj", nego zato što je to tačka gde greške u podacima postaju teško popravljive, što je kvalitativno drugačija, trajnija šteta od pukog kašnjenja.
Korak 3 — izvodljivost: pre poboljšanja opisanih u klauzuli 8.3, stvaran oporavak je trajao 30 sati (potvrđeno stvarnim incidentom). To je bilo znatno iznad željenog cilja, što je i bio signal da treba uložiti u brže rešenje — lokalni backup server.
Korak 4 — postavljanje RTO: RTO je postavljen na 8 sati. Ovo nije proizvoljan broj — pogledajte gde on sedi na krivoj: daje čitavih 16 sati margine pre nego što uopšte počnu ugovorni penali (na 24. satu), i skoro tri puna dana margine pre MTPD (72. sat). Istovremeno, posle ulaganja u lokalni backup server, testiranje je pokazalo da je 8 sati realno dostižno — vežba je izmerila stvaran oporavak od 6 sati i 40 minuta, što dodatno potvrđuje da cilj ima smisla, ne samo na papiru nego i u praksi.
RPO za ovaj proces: Elektrotehna je odredila da sme da izgubi najviše 4 sata podataka. To je direktno odredilo koliko često backup mora da se pravi — na svaka 4 sata, ne jednom dnevno kao ranije.
Kako se određuje RPO
RPO odgovara na drugačije pitanje od RTO-a. RTO pita "koliko dugo proces sme da ne radi". RPO pita "koliko unazad u vremenu sme da se vrati kad se sistem ponovo digne, a da to bude prihvatljivo" — odnosno, koliko sati podataka sme trajno da nestane. Na njega utiču četiri stvari.
Koliko brzo se podaci menjaju. Ako sistem retko dobija nove unose, RPO od 24 sata je bezopasan — verovatno se u tih 24 sata ništa nije ni promenilo. Ako sistem non-stop prima transakcije (porudžbine, fakture, unosi sa proizvodne linije), svaki izgubljeni sat znači realan, opipljiv broj izgubljenih zapisa.
Da li se izgubljeno može rekonstruisati iz drugog izvora. Ovo je najvažnije pitanje, i često se preskoči. Ako je faktura poslata i mejlom, ili porudžbina stigla i na papiru, gubitak sistemskog zapisa je neprijatan, ali podatak nije stvarno izgubljen — može se ručno ponovo uneti. Ako je podatak nastao samo u tom sistemu (na primer, automatski zapis sa proizvodne linije), gubitak je trajan. Isti broj sati znači potpuno različitu težinu štete zavisno od ovog odgovora.
Cena gubitka, izražena konkretno. Koliko zapisa nastane po satu, i šta znači njihov gubitak — koliko ručnog rada da se rekonstruišu, kolika je verovatnoća greške ili duplikata (na primer, dve fakture za istu porudžbinu poslate klijentu).
Šta je tehnički izvodljivo i po kojoj ceni. RPO blizu nule (kontinualna replikacija) je skup i kompleksan. RPO od par sati (redovan inkrementalni backup) je jeftin i jednostavan. Svaki korak bliže nuli obično eksponencijalno poskupljuje — treba proveriti gde stvarna potreba prestaje da opravdava dodatnu cenu.
Za ERP sistem, obrazloženje je izgledalo ovako: tokom radnog vremena, sistem prima otprilike 40-60 novih ili izmenjenih zapisa po satu. Deo tih podataka (porudžbine, fakture) može se delimično rekonstruisati iz mejlova i papirnih naloga — sporo i sklono greškama, ali izvodljivo. Automatski generisani podaci o stanju proizvodnje ne mogu se ručno rekonstruisati. Izgubljen sat znači 40-60 zapisa koje neko mora ručno da pronađe, uz realan rizik duplikata. Prelazak sa dnevnog na backup na svaka 4 sata bio je tehnički jednostavan i jeftin — kontinualna replikacija bi bila neproporcionalno skupa za obim podataka koji firma ima. Na osnovu svega ovoga, RPO je postavljen na 4 sata.
Zašto se broj kasnije menja — validacija kroz testiranje. Backup na svaka 4 sata ne garantuje automatski RPO od tačno 4 sata. Ako se prekid desi tik pre nego što je poslednji backup završen, stvarni gubitak može biti blizu 8 sati (ceo prethodni interval plus deo novog). Upravo je to Elektrotehna otkrila kroz stvaran test obnove sistema, opisan detaljnije u tekstu o klauzuli 8.5 — izmereni RPO je u jednom trenutku bio skoro 5 sati, iznad cilja od 4, jer je poslednja sinhronizacija bila izvršena neposredno pre simuliranog prekida, ne odmah posle njega. Zato se RPO, kao i RTO, ne postavlja jednom i zaboravi — testira se stvarnim merenjem, ne pretpostavkom da "backup na X sati = RPO od X sati".
Isti princip, kraći primeri za ostala tri procesa
Proizvodna linija 2 (ekstruzija)
Prva tvrda granica je na 4. satu — tad se aktivira prelazak na liniju 1. Puni MTPD je oko 3 dana, kada čak i uz prebacivanje na liniju 1 ukupan kapacitet firme padne ispod potrebnog nivoa. RTO je zato postavljen stepenovano: 4 sata do aktivacije alternative, 24 sata do punog oporavka same linije 2 — svaki cilj ima svoju svrhu i svoju marginu.
Nabavka sirovina od ključnih dobavljača
Ovde je kriva potpuno drugačije razvučena u vremenu — postojeće zalihe pokrivaju 3 nedelje proizvodnje, alternativni dobavljač bi mogao da isporuči za 4-6 nedelja, a posle 8 nedelja bez rešenja proizvodnja koja zavisi od tih sirovina potpuno staje. MTPD je ovde 6-8 nedelja. RTO je postavljen na "aktivirati alternativu za 3 nedelje" — pre nego što zalihe počnu da presušuju, ne na samoj ivici.
Magacinsko poslovanje i otprema
Ovaj proces pokazuje da MTPD nije fiksan zauvek — zavisi od toga da li postoji radna alternativa. Sa papirnom procedurom (uvedenom posle ranijeg incidenta), magacin može da izdrži do 2 dana bez ERP-a. Bez te procedure, MTPD bi bio mnogo kraći — praktično vezan za MTPD samog ERP-a. Kad firma uvede novu alternativu, BIA za taj proces treba ponovo proveriti, jer se granica pomerila.
Zavisnosti i resursi — primer za proizvodnu liniju 2
Za svaki proces, BIA takođe mapira šta je potrebno da bi proces uopšte mogao da radi. Za liniju 2, to uključuje: ljude (kvalifikovan tehničar — sada dvoje, posle obuke iz klauzule 7.2), opremu (sam ekstruder i rezervni delovi na stanju), informacije (tehnička dokumentacija za podešavanje, dostupna i u papirnoj formi), lanac snabdevanja (sirovine, dobavljač rezervnih delova), i infrastrukturu (napajanje strujom — direktno povezano sa rezervnim agregatom odobrenim u klauzuli 5.1).
Smernice za dokumentaciju
Za svaki proces u obuhvatu BCMS-a, koristi se isti obrazac: naziv procesa, tabela uticaja tokom vremena, MTPD sa obrazloženjem odakle ta granica dolazi (koji ugovor, koji zakon, koja vrsta štete), izvedeni RTO sa objašnjenjem margine, RPO ako je relevantan, i lista zavisnosti/resursa. Bitno je zapisati ne samo brojeve nego i zašto su baš ti brojevi odabrani — to je ono što kasnije, kod procene rizika i strategija, omogućava da se odluke razumeju i preispituju, ne samo prepisuju.
Najčešća greška
Najčešća greška je mešanje kriterijuma za klasifikaciju "kritičnog procesa" iz klauzule 8.1 sa MTPD ili RTO pojedinačnog procesa — to su dve različite stvari na dva različita nivoa. Druga česta greška je postavljanje istog RTO-a za sve procese "radi jednostavnosti", bez uvažavanja da različiti procesi imaju potpuno različitu prirodu uticaja, kao što smo videli kod nabavke sirovina. Treća česta greška je da se RTO postavi bez provere izvodljivosti — cilj od 8 sati ima smisla samo ako je i stvarno dostižan sa resursima koje firma ima ili planira da nabavi, što se na kraju uvek proverava kroz vežbe (klauzula 8.5).
Коментари
Постави коментар