ISO 22301 – Klauzula 10.2: Neusaglašenost i korektivne radnje

ISO 22301 – Klauzula 10.2: Neusaglašenost i korektivne radnje

U jednoj rečenici: kad se nešto pokaže neusaglašenim sa pravilima koja ste sami sebi postavili, ne rešava se samo taj jedan konkretan slučaj — traži se pravi uzrok, proverava se da li se isti problem krije i negde drugde, i tek posle nekog vremena proverava da li je rešenje zaista upalilo.

Šta klauzula zapravo traži

Kad se pojavi neusaglašenost, organizacija treba da:

• reaguje — ispravi konkretan slučaj i, ako je potrebno, reši eventualne posledice koje je taj propust već izazvao,
• proceni da li je potrebna dublja radnja — pregleda šta se tačno desilo, odredi pravi uzrok, i proveri da li isti problem postoji ili bi mogao da se pojavi i na drugim mestima,
• sprovede tu radnju, ako je procenjeno da je potrebna,
• proveri, posle nekog vremena, da li je radnja zaista bila efikasna,
• ažurira dokumentaciju BCMS-a, ako je to potrebno kao rezultat svega ovoga.

Zašto je ovo bitno

Razlika između firme koja samo "gasi požare" i firme koja stvarno uči je upravo u ovom procesu. Ispraviti jedan pogrešan obrazac je lako i brzo. Pitati se zašto se to desilo, da li se to dešava i drugde, i da li je rešenje zaista promenilo nešto — to je sporije, ali je jedini način da se broj sličnih propusta stvarno smanjuje kroz vreme, umesto da se firma iznova i iznova bavi varijacijama istog problema.

Detaljan primer: kompletan životni ciklus jedne neusaglašenosti

U tekstu o klauzuli 9.2 pomenuli smo nalaz sa interne provere — obrazac o proverenoj kompetentnosti zamenskog tehničara za liniju 2 je postojao, ali nikad nije unet u centralni registar dokumenata. Tamo smo samo dotakli razliku između korekcije i korektivne radnje. Ovde prolazimo kroz ceo proces, korak po korak, onako kako ga klauzula 10.2 zaista traži.

Korak 1 — reagovanje

Neposredna korekcija je bila jednostavna: obrazac je pronađen kod šefa proizvodnje, skeniran i unet u registar istog dana. Zatim je BCM koordinator proverio posledice — da li je, dok obrazac nije bio u registru (oko tri meseca), taj propust stvarno nekome naškodio. Ispostavilo se da nije — nijedan incident se u tom periodu nije desio, pa formalno nedostajući dokaz kompetentnosti nije prouzrokovao stvarnu štetu, samo je predstavljao rizik da bi mogao da je prouzrokuje.

Korak 2 — pregled, uzrok i provera "da li se isto dešava negde drugde"

Pregledom slučaja, BCM koordinator i proverivač su zajedno tražili pravi uzrok — ne "šef proizvodnje je zaboravio", što je samo simptom, nego zašto je uopšte bilo moguće da se zaboravi. Pravi uzrok: procedura za proveru kompetentnosti (klauzula 7.2) nikad nije eksplicitno rekla ko je odgovoran da popunjen obrazac prosledi dalje, u centralni registar. Odgovornost je bila prećutno pretpostavljena, ne pisana — što znači da je propust bio pitanje procesa, ne nemarnosti jedne osobe.

Ova razlika je bitna i zbog kulture u firmi: tražiti krivca za "zaboravljanje" vodi u to da ljudi kriju sitne propuste iz straha, dok traženje uzroka u procesu vodi u sistemsko rešenje koje pomaže svima, ne samo trenutnom slučaju. Isti princip nepokažnjavanja grešaka, samo primenjen na prijavljivanje problema, radi i ovde.

Proverom da li se isti obrazac krije i na drugim mestima, otkriven je još jedan identičan slučaj: evidencija o tome da je IT administrator uspešno prošao test obnove ERP sistema (test opisan u klauzuli 8.5) takođe nikad nije formalno unet u registar, iz potpuno istog razloga — nedostatka jasno određenog koraka u proceduri.

Korak 3 — sprovođenje radnje

U proceduru za kompetentnost (7.2) dodat je eksplicitan korak: svaki popunjen i potpisan obrazac o proverenoj kompetentnosti mora biti prosleđen BCM koordinatoru i unet u centralni registar u roku od tri radna dana. Ovo rešenje nije primenjeno samo na slučaj sa tehničarem, nego i na već pronađen sličan slučaj sa IT administratorom — jer rešavanje samo jednog primera, dok uzrok ostaje isti za oba, ne bi zaista rešilo problem.

Korak 4 — provera efikasnosti

Radnja se ne smatra završenom čim se sprovede — mora se i proveriti da li stvarno radi. Tri meseca kasnije, prilikom redovnog mesečnog pregleda registra (pokazatelj iz klauzule 9.1), BCM koordinator je proverio da li su svi novi obrasci kompetentnosti od uvođenja pravila stigli u registar u roku od tri dana. Svi jesu — radnja je potvrđena kao efikasna, i tek tada je slučaj zvanično zatvoren.

Korak 5 — ažuriranje dokumentacije

Izmenjena procedura za kompetentnost dobila je novu verziju u centralnom registru (klauzula 7.5), sa jasnom napomenom šta je promenjeno i zašto — tako da je trag od originalnog nalaza do konačne izmene procedure moguće pratiti unazad, ako se ikad postavi pitanje zašto procedura sada izgleda ovako kako izgleda.

Odakle neusaglašenosti obično dolaze

Kroz celu ovu seriju, neusaglašenosti su se pojavljivale iz više izvora: interne provere (klauzula 9.2), vežbi (klauzula 8.5), stvarnih incidenata, pa čak i preispitivanja rukovodstva (klauzula 9.3), kad neko od direktora primeti nešto što ne deluje u redu. Svi ovi izvori hrane isti proces opisan u ovoj klauzuli — nije bitno odakle je neusaglašenost stigla, obrada je uvek ista.

Smernice za dokumentaciju

Registar neusaglašenosti treba da sadrži: opis šta se desilo i kako je otkriveno, neposrednu korekciju, utvrđen uzrok, rezultat provere da li se isto dešava negde drugde, sprovedenu radnju sa odgovornom osobom i rokom, datum i rezultat provere efikasnosti, i referencu na dokument koji je eventualno izmenjen kao rezultat. Ovaj registar se čuva u centralnom registru dokumenata (klauzula 7.5) i redovno se pregleda na preispitivanju rukovodstva (klauzula 9.3).

Najčešća greška

Najčešća greška je zaustavljanje na koraku korekcije — problem se ispravi, svi su zadovoljni, a pitanje "zašto se ovo uopšte desilo" nikad se ozbiljno ne postavi. Druga česta greška je preskakanje provere "da li se isto dešava negde drugde" — rešava se tačno onaj slučaj koji je otkriven, dok identičan problem, kao u primeru sa IT administratorom, ostaje neotkriven sve dok ga ne otkrije neka sledeća provera, meseci ili godinu kasnije. Treća česta greška je da se radnja sprovede i nikad više ne proveri da li zaista radi — pravilo se uvede, svi pretpostave da je problem rešen, i niko se više ne vrati da to potvrdi.

Kraj klauzula-po-klauzula serije

Ovim tekstom smo prošli kroz sve klauzule ISO 22301, od konteksta organizacije do korektivnih radnji, kroz Elektrotehnu kao stalan primer. Sledeći korak na blogu je prelazak na ISO 27031 — standard koji se fokusira uže na IT/ICT spremnost za kontinuitet poslovanja, najavljen još u prvom tekstu ove serije.