Primer ocene tveganja po ISO 12100 ni uporaben zato, ker lepo izgleda v Excelu. Uporaben je takrat, ko iz dokumentacije jasno vidite, kako je ekipa prišla od omejitev stroja do konkretnih odločitev o zaščitnih ukrepih, varnostnih funkcijah in preostalem tveganju. Tu večina dokumentov odpove. Ne zato, ker bi bili kaotični. Nasprotno. Videti so profesionalno, imajo točkovanje, opombe, sklice na standarde in končni PDF, ki ekipi hitro da občutek, da je tema zaprta.
Problem je drugje. ISO 12100 ne ocenjuje urejenosti preglednice. Ocenjuje, ali je bila ocena tveganja zares izvedena. Ali so bile določene omejitve stroja. Ali so bile analizirane naloge uporabnika. Ali so bile prepoznane nevarna situacija, nevarni dogodek, zaščitni ukrep, sekundarno tveganje in preostalo tveganje. In ali se da po času razumeti, kdo je sprejel katero odločitev in zakaj.
Zato pravo vprašanje ni, ali se ocena tveganja lahko vodi v Excelu. Seveda se lahko. Pravo vprašanje je, ali tak zapis zagotovi proces, ki ga lahko tehnično, logično in pri presoji skladnosti za CE tudi zagovarjate. Tu se začne razlika med tabelo in inženirstvom.
Primer ocene tveganja po ISO 12100: zakaj Excel ni dovolj
Excel sam po sebi ni problem. Problem je, da prelahko ustvari videz, da je dokumentacija ocene tveganja že nastala, čeprav v resnici obstajajo le delovni podatki. Preglednica je lahko uporaben osnutek. Lahko zbira vnose ekipe. Lahko pomaga pri razdelitvi scenarijev. Ne more pa sama od sebe varovati logike postopka.
ISO 12100 ne zahteva preglednice. Zahteva dokumentacija ocene tveganja. To ni isto. Dobra dokumentacija ne pokaže samo tega, kaj je nekdo vpisal v celico, ampak tudi, iz česa je ta odločitev nastala in kako se je spreminjala po uvedbi zaščitnega ukrepa.
Če naj bo dokumentacija ocene tveganja uporabna in obranljiva, mora iz nje biti razvidno najmanj naslednje:
- kakšen je namen stroja in kakšne so njegove omejitve,
- kdo ga uporablja in katere naloge se v resnici izvajajo,
- katere nevarne situacije in kateri nevarni dogodki so bili analizirani,
- kako je bilo ocenjeno začetno tveganje,
- kateri zaščitni ukrep je bil izbran in v kakšnem zaporedju,
- ali je bil najprej obravnavan ukrep v zasnovi, nato tehnični ukrep, šele potem informacije za uporabo,
- ali se je po spremembi pojavilo sekundarno tveganje,
- kako je bilo ocenjeno preostalo tveganje,
- kdo je odločitev sprejel in na kateri podlagi.
Tu običajna preglednica najpogosteje popusti. Ne opozori, da mora ekipa po vgradnji varovala znova preveriti servis. Ne prisili uporabnika, da po spremembi logike ponovnega zagona še enkrat oceni nevarno situacijo. Ne ohrani zanesljive sledi odločitev. Končni rezultat je zato pogosto lep, vendar plitek.
In še nekaj. Tri-stopenjska logika po ISO 12100 ni okrasek. Najprej zmanjšanje tveganja z zasnovo, nato varovala in varnostne funkcije, šele nato informacije za uporabo. Če dokument skoči neposredno od nevarnosti do navodila ali opozorila na nalepki, je nekaj narobe. Ne z videzom. Z osnovno logiko postopka.
Sekundarno tveganje je trenutek, ko se vidi kakovost ocene tveganja
Ali lahko zaščitni ukrep ustvari novo nevarnost? Seveda lahko. In prav zato se dobra ocena tveganja ne konča v trenutku, ko nekdo dopiše varovalo, blokado, ročni reset ali postopek. Zaščitni ukrep ne zapre teme. Spremeni razmerje med človekom, strojem, energijo in načinom dela.
Mehanski primer: premično varovalo z blokado izboljša dostopno varnost, poslabša pa servis
Na avtomatizirani postaji je prisotno nevarno gibanje med normalnim ciklom. Ekipa doda premično varovalo z blokado, kar je na prvi pogled pravilna odločitev. Med avtomatskim delovanjem je dostop do nevarnega območja omejen. Toda pri čiščenju in odstranjevanju zastojev mora operater zdaj segati globlje v stroj, skozi ožji servisni odprtino in v manj naravni drži.
Glavno mehansko tveganje se sicer zmanjša, vendar se odpre drugo vprašanje: ali je zaščitni ukrep poslabšal dostop, preglednost in ergonomijo do te mere, da nastaja nova nevarna situacija pri vzdrževanju? Če tega ne preverite, dokument pokaže samo polovico slike.
Primer avtomatizacije: pravilna varnostna funkcija lahko sproži napačno vedenje
Na stroju se doda blokada odpiranja, ročni reset in preprečitev samodejnega ponovnega zagona po odprtju varovala. Sama varnostna funkcija je lahko povsem pravilno zasnovana. Težava se začne, če nova zaporedja podaljšajo vsako intervencijo, povečajo število korakov in operaterja nenehno prekinjajo pri delu.
Takrat se pojavi sekundarno tveganje na ravni organizacije in vedenja. Reset se začne izvajati rutinsko, brez dejanskega pregleda območja. Pojavi se skušnjava po obhodih. Nekdo začne iskati bližnjice. Napaka ni v tem, da obstaja varnostna funkcija. Napaka je, da ni bilo preverjeno, kako bo vplivala na resničen potek dela.
Električni primer: izenačitvena povezava, ki poslabša razlika potencialov
V krmilna omara ali na kovinskem delu stroja nekdo opazi dvomljivo kontinuiteto in se odloči za hitro izboljšavo. Doda izenačitvena povezava samo na enem delu sestava. Namen je dober: boljša zaščita pred električnim udarom. A če je ukrep izveden delno in brez pregleda celote, lahko nastane ravno nasprotni učinek.
Ena skupina delov dobi drugačen referenčni potencial kot preostanek stroja. Ob okvari ali prehodnem stanju se poveča razlika potencialov. Človek, ki se hkrati dotakne dveh delov sistema, je lahko v nevarnejšem scenariju kot pred izboljšavo. To ni akademska podrobnost. To je tipičen primer, kako dober namen brez sistemskega pogleda ustvari slab rezultat.
Skupna točka teh primerov je preprosta. Nekdo je storil nekaj, kar je na prvi pogled videti razumno: dodal je varovalo, popravil logiko krmiljenja ali izvedel izenačitvena povezava. Težava ni v obstoju ukrepa. Težava je v tem, da ni bilo preverjeno, kaj je ta ukrep naredil preostalemu sistemu človek–stroj–energija–proces.
Če dokumentacija ocene tveganja ne zajame sekundarnega tveganja, zelo hitro začne opisovati svet, ki je videti varnejši od resničnosti. To ni majhen administrativni spodrsljaj. To je prekinitev logike ocene tveganja.
Sled odločitev ni dodatek, ampak dokaz
V praksi redko manjka končni rezultat. Tabela je. Vrednost tveganja je. Zaščitni ukrep je. Težava nastane kasneje, ko po enem mesecu nihče več ne zna odgovoriti na preprosta vprašanja: kdo je spremenil oceno, zakaj je bila neka nevarna situacija označena kot sprejemljiva in na podlagi česa je bila zahtevana ravno raven PL d.
Končni dokument pokaže rezultat. Sled odločitev pokaže pot do rezultata. Pri oceni tveganja je ta pot ključna, ker šele ona razkrije, ali so bile odločitve dosledne in tehnično utemeljene.
Brez sledi odločitev ne morete zanesljivo ločiti med temi tremi zelo pogostimi primeri:
- nekdo je spremenil oceno iz srednje v nizko, vendar ni jasno, ali zaradi novega zaščitnega ukrepa ali zaradi kozmetičnega popravka dokumenta,
- nekdo je sprejel nizko tveganje, vendar ni razvidno, ali zaradi redke izpostavljenosti in nadzorovanih pogojev ali zgolj zato, ker je bilo treba zadevo zaključiti,
- nekdo je vpisal PL d, vendar ni pojasnil, katera varnostna funkcija točno to zahteva, kaj spremlja, kaj prekine in zakaj je ta zahteva sploh nastala.
Tu preglednica odpove hitreje, kot si večina prizna. Celico je mogoče prepisati. Opombo je mogoče spremeniti. Opis je mogoče olepšati. Zelo težko pa je po času razlikovati med razvojem analize, ročnim urejanjem dokumenta in prilagajanjem rezultata želenemu zaključku.
Zato sled odločitev ni birokracija. Je inženirski spomin projekta. Brez nje hitro ostane samo zadnja verzija PDF, ki izgleda urejeno, ne pokaže pa, kdo je kaj naredil, kdaj je to naredil, kaj se je po poti spremenilo in ali je bila po uvedbi zaščitnega ukrepa res izvedena ponovna ocena.
Dobra dokumentacija ocene tveganja mora zato povezati nevarno situacijo, začetno oceno, odločitev o zmanjšanju tveganja, izbran zaščitni ukrep, morebitno sekundarno tveganje in končno oceno preostalega tveganja. Če te povezave ni mogoče slediti, branite samo zadnji zapis. Ne branite procesa.
Primer ocene tveganja po ISO 12100: ena pakirna postaja, šestnajst nevarnih situacij
Da ne ostanemo pri teoriji, poglejmo praktičen primer za avtomatizirano pakirno postajo. Ne za abstrakten stroj, ampak za realen sistem z nevarnim gibanjem, posegi operaterja, odstranjevanjem zastojev, vzdrževalnimi opravili, dostopom do električne in pnevmatske energije ter varnostnimi funkcijami, ki so odvisne od logike krmiljenja.
V takem primeru nismo ostali pri dveh ali treh splošnih vnosih. Nastalo je šestnajst ločenih obravnav: trinajst scenarijev nalog in trije nevarni dogodki po logiki ISO 12100. Posebej so bili ocenjeni manjši posegi med delovanjem, odstranjevanje zastojev, nastavljanje zaščitnih naprav, funkcionalni preizkusi, odklop energije, menjava potrošnih delov, diagnostika napak ter dogodki, kot so nenameren zagon, izmet predmeta in sprostitev pnevmatske energije.
Prav takšna razčlenitev pokaže resnično sliko. Dobra ocena tveganja ne ocenjuje stroja na splošno. Ocenjuje odnos človeka do stroja pri konkretni nalogi, v konkretni coni, pri konkretnem viru nevarnosti in v konkretnih pogojih dostopa. Tu se loči resen primer od dokumenta, ki je samo videti popoln.
Ta primer je v praksi pokazal več pomembnih stvari.
- Glavno tveganje ni izhajalo iz same prisotnosti nevarnega gibanja, ampak iz dostopa človeka do tega gibanja med posegi, diagnostiko in odstranjevanjem zastojev.
- Nekateri scenariji so bili res lahko ocenjeni kot nizko tveganje, vendar samo zato, ker so bili jasno omejeni glede pogostosti, trajanja, pogojev izvedbe in vloge uporabnika.
- V več kritičnih primerih ni bilo mogoče verodostojno ostati pri zapisu varovalo plus navodilo. Treba je bilo opisati dejansko varnostna funkcija, logiko blokade, pogoje dostopa, ročni reset, ponovni zagon in razlog za zahtevano raven PL d.
- Šele popolna sled odločitev je pokazala, kdo in zakaj je nekatere scenarije sprejel, druge pa poslal v nadaljnje zmanjšanje tveganja.
Pomemben nauk je še en. Stroja ni mogoče pošteno oceniti na splošno. Ocenjevati je mogoče samo konkretne relacije človek–stroj. En vnos z opisom mehansko tveganje skoraj nikoli ne zadošča. Šele ko nevarne situacije razdelite po nalogah in okoliščinah, postane jasno, kaj je res kritično in kaj samo deluje strašljivo na ravni splošnega opisa.
Kaj mora pokazati Primer ocene tveganja po ISO 12100
Dober dokument ne začne z vnosom nevarnosti v tabelo. Začne se prej in gre dlje. Pokazati mora celoten lok odločanja:
- čemu je stroj namenjen in kakšne so njegove omejitve,
- kdo ga uporablja in kakšna je razumno predvidljiva napačna uporaba,
- katere naloge se dejansko izvajajo med obratovanjem, čiščenjem, nastavljanjem, vzdrževanjem in diagnostiko,
- katere nevarne situacije in kateri nevarni dogodki so bili zato analizirani,
- katera tveganja so bila že na začetku sprejemljiva in zakaj,
- katera tveganja zahtevajo zmanjšanje tveganja,
- kateri zaščitni ukrep je bil izbran in v kakšnem vrstnem redu,
- ali je ukrep ustvaril sekundarno tveganje,
- kako je bilo ocenjeno preostalo tveganje,
- kdo je sprejel odločitev in kakšna sled odločitev to potrjuje.
Če iz dokumenta tega ni mogoče razbrati, potem to ni dober primer. To je samo urejen seznam vnosov. Lep na pogled, šibak v vsebini.
Ko pride do notranje presoje, presoje kupca, vprašanj po nesreči ali priprave dokumentacije za CE po 2006/42/ES, nihče ne bo resno spraševal, ali je bila tabela estetska. Vprašanje bo vedno isto: ali je bila ocena tveganja izvedena sistematično, ali je bila dokumentirana in ali je mogoče razumeti tehnično logiko odločitev.
To je bistvo. Dober primer ocene tveganja ne navduši s številom vrstic. Vreden je zato, ker pokaže, kako je ekipa prišla do odločitve, katero tveganje je mogoče sprejeti in kje je nujen resničen tehnični poseg. Če tega ni, nimate dokumentacije ocene tveganja. Imate samo delovni list.
Če želite videti primer dokumentacije ocene tveganja v obliki PDF, ga lahko prenesete na tej strani. Če želite tak postopek voditi sistematično in z ohranjeno sledjo odločitev, lahko preizkusite Safety Software brez kartice in brezplačno za 14 dni.