Tämä ISO 12100 riskinarvioinnin esimerkki paljastaa epämukavan totuuden: pahin riskinarviointi ei ole sekava vaan vakuuttavan näköinen. Siinä on taulukko, pisteytys, standardiviittauksia, kommentteja ja lopuksi PDF, jonka jälkeen tiimi huokaisee helpotuksesta. Asia muka valmis. Mutta ISO 12100 ei anna pisteitä dokumentin siisteydestä. Se kysyy jotain paljon ikävämpää: onko turvallisuuden arviointiprosessi oikeasti tehty, johdonmukaisesti, loppuun asti ja niin, että sen voi myöhemmin todentaa? Tässä kohtaa moni hyvältä näyttävä arviointi alkaa hajota. Taulukko ei vartioi logiikkaa. Se ei pakota siirtymään koneen rajoista todellisiin tehtäviin, vaaratilanteisiin ja vaaratapahtumiin. Se ei muistuta, että suojaustoimenpide voi synnyttää toissijaisen riskin. Se ei säilytä audit trailia. Ja juuri siksi siisti tiedosto ei vielä tarkoita turvallista konetta.
ISO 12100 riskinarvioinnin esimerkki: miltä huono arviointi näyttää
Kysymys ei ole siitä, voiko riskinarvioinnin tehdä Excelissä. Tietenkin voi. Samalla tavalla voi tehdä tiedoston, joka näyttää hetken uskottavalta. Oikea kysymys on toinen: pystyykö taulukko varmistamaan prosessin, jonka voi puolustaa teknisesti, loogisesti ja audit trailin näkökulmasta? Tässä kulkee raja hallinnollisen näpertelyn ja insinöörityön välillä.
Excel ei ole sama asia kuin riskinarviointidokumentaatio. Se voi olla muistikirja, luonnos tai tiimin työväline. Se voi kerätä havaintoja. Se voi näyttää asialliselta. Mutta jos se ei muuta päätösten ketjua puolustettavaksi riskinarviointidokumentaatioksi, se on edelleen vain taulukko.
Mitä riskinarviointidokumentaation on silloin oikeasti näytettävä? Ei vain lopputulosta vaan myös se, mistä lopputulos syntyi:
- mitkä olivat koneen rajoitukset
- mitä tehtäviä ja käyttötilanteita analysoitiin
- mitkä vaaratilanteet ja vaaratapahtumat otettiin mukaan
- miten riski arvioitiin
- mitkä suojaustoimenpiteet valittiin
- missä järjestyksessä riskin pienentäminen tehtiin
- syntyikö toissijainen riski
- miten jäännösriski arvioitiin
- kuka teki päätöksen ja millä perusteella
Tässä kohtaa kompastellaan jatkuvasti. Alalla rakastetaan oikoteitä. Vaara havaitaan, ja seuraavaksi hypätään suoraan suojukseen, menettelyyn tai käyttöohjeeseen, aivan kuin ISO 12100:n kolmiportainen logiikka olisi koriste eikä koko prosessin perusta. Näin ei toimita, jos arviointi halutaan kestämään tarkastelun.
Huono puoli Excelissä ei siis ole, että se olisi liian yksinkertainen. Ongelma on pahempi: sillä on liian helppo teeskennellä, että dokumentaatio on valmis, vaikka todellisuudessa kasassa on vasta hyvin muotoiltua raakadataa. Jos dokumentista ei pysty jälkikäteen rekonstruoimaan päätöksiä, tarkistamaan oletuksia ja näkemään miksi juuri tietty ratkaisu valittiin, sinulla ei ole riskinarviointidokumentaatiota. Sinulla on siisti liite.
Toissijainen riski on se hetki, jolloin arviointi paljastuu
Voiko suojaustoimenpide itse synnyttää uuden vaaran? Totta kai voi. Siksi riskinarviointi ei pääty siihen, että joku kirjoittaa riville suojuksen, lukituksen tai menettelyn. Suojaustoimenpide ei sulje prosessia. Se muuttaa koko riskikenttää.
Mekaaninen esimerkki: suojus voi parantaa käyttöä ja pilata huollon
Ajatellaan tilannetta, jossa vaarallinen liike on saavutettavissa käytön aikana. Tiimi lisää lukituksella varustetun liikkuvan suojuksen. Ensi silmäyksellä ratkaisu näyttää hyvältä: pääsy vaaravyöhykkeelle automaattiajossa rajoittuu. Mutta muutoksen jälkeen puhdistus ja tukosten poisto tapahtuvatkin ahtaammin. Käyttäjän pitää kurkottaa syvemmälle, työskennellä käsi huonossa asennossa ja operoida kapeamman huoltoaukon kautta.
Mitä tapahtui? Ensisijainen mekaaninen riski pieneni, mutta samalla syntyi uusi kysymys näkyvyydestä, pääsystä ja ergonomiasta. Jos tätä ei arvioida uudelleen, dokumentaatio näyttää vain puolet totuudesta.
Automaation esimerkki: oikea turvatoiminto voi houkutella väärään käyttäytymiseen
Toinen klassinen ansa liittyy ohjaukseen. Koneeseen lisätään turvatoiminto, manuaalinen kuittaus ja esto automaattiselle uudelleenkäynnistykselle suojuksen avaamisen jälkeen. Itse turvatoiminto voi olla täysin oikein suunniteltu. Ongelma alkaa vasta käytössä.
Jos uusi sekvenssi pidentää jokaista puuttumista prosessiin, rikkoo työn rytmin ja lisää työvaiheita, syntyy käyttäytymiseen liittyvä toissijainen riski. Kuittaus tehdään refleksinä. Vyöhykettä ei enää tarkasteta oikeasti ennen käynnistystä. Suojausta aletaan kiertää, koska tuotantopaine on todellinen eikä PowerPoint-kalvojen kuvitelma.
Tässä kohtaa vika ei ole turvatoiminnossa vaan siinä, että kukaan ei tarkistanut, mitä se tekee oikealle työlle.
Sähköesimerkki: hyvä aikomus ei riitä, jos kokonaisuus hajoaa
Sähköpuolella sama ilmiö näkyy kahdella tavalla. Ensimmäinen on organisatorinen. Vikadiagnostiikan sähköiskuriskiä pienennetään paremmalla koteloinnilla, selkeämmällä piirien erottelulla, eristysmenettelyllä, jännitteen puuttumisen varmistuksella ja käyttöoikeuksien rajaamisella. Kuulostaa hyvältä, ja usein onkin sitä. Mutta samalla diagnostiikasta voi tulla pidempi, monivaiheisempi ja herkempi järjestyksen rikkomiselle. Silloin sähköiskuriski on ehkä pienempi, mutta menettelyvirheen riski kasvaa.
Toinen esimerkki on teknisempi ja vaarallisempi. Joku huomaa ongelman yhdessä koneen osassa ja tekee potentiaalintasausliitoksen vain siihen kohtaan. Tarkoitus on hyvä: parantaa sähköistä turvallisuutta. Jos ratkaisu tehdään valikoivasti vain osaan kokonaisuutta, seurauksena voi olla tilanne, jossa yksi koneen osa käyttäytyy eri viitepotentiaalissa kuin muu rakenne. Häiriössä tai vikatilanteessa tämä voi kasvattaa potentiaalieron riskiä juuri siinä kosketustilanteessa, jonka piti parantua.
Näitä esimerkkejä yhdistää yksi asia. Joku teki paperilla järkevän ratkaisun. Mutta kukaan ei tarkistanut, mitä suojaustoimenpide teki koko suhteelle ihminen, kone, energia ja prosessi. Siinä kohtaa arvioinnin logiikka katkeaa.
Toissijainen riski ei ole sivuhuomautus. Se on yksi kovimmista testeistä sille, arvioiko tiimi oikeasti turvallisuutta vai kirjaako se vain ratkaisuja ongelmien perään.
Audit trail ei ole lisäominaisuus vaan todiste ajattelusta
Moni vähättelee audit trailia, kunnes tulee ensimmäinen tilanne, jossa joku kysyy yksinkertaisen kysymyksen: kuka muutti tätä arviota, milloin ja miksi? Silloin paljastuu nopeasti, onko dokumentaatio elävä päätösten ketju vai lopputulos, joka vain näyttää valmiilta.
Lopullinen dokumentti näyttää tuloksen. Audit trail näyttää reitin tulokseen. Riskinarvioinnissa juuri se reitti ratkaisee.
Hyvä audit trail näyttää esimerkiksi:
- olivatko päätökset johdonmukaisia
- palattiinko aiempiin oletuksiin ja miksi
- tehtiinkö suojaustoimenpiteen jälkeen uusi arviointi
- huomattiinko toissijainen riski
- hyväksyttiinkö jotain liian nopeasti
- perustuiko PL d todelliseen logiikkaan vai vanhaan tottumukseen
Ajatellaan kolmea hyvin tavallista tilannetta.
Ensimmäinen: vaaratilanne on ollut aiemmin keskitasoinen ja myöhemmin matala. Taulukossa näkyy vain lopputila. Mutta kuka muutti arvion? Perustuiko muutos uuteen suojaustoimenpiteeseen, korjattuun lähtötietoon vai siihen, että dokumentti piti saada päätökseen? Ilman audit trailia et tiedä.
Toinen: riski on merkitty hyväksyttäväksi. Peruste puuttuu. Hyväksyttiinkö se siksi, että altistuminen oli harvinaista, seuraus vähäinen, tehtävä rajattu ja käyttäjä koulutettu? Vai siksi, että pisteytys näytti numerona pieneltä eikä kukaan halunnut avata asiaa uudelleen? Nämä eivät ole sama asia, vaikka lopputulos rivillä näyttää samalta.
Kolmas: dokumentissa lukee turvatoiminto, ISO 13849 ja PL d. Ammattimaisen näköistä. Mutta mitä turvatoimintoa tämä täsmälleen koski? Mitä se valvoi? Mitä se katkaisi? Miksi juuri tämä vaatimustaso oli tarpeen? Jos perustelu puuttuu, merkintä ei todista suunnittelun laatua. Se todistaa lähinnä sen, että joku osasi kirjoittaa PL d oikeaan sarakkeeseen.
Tässä tavallinen taulukko on heikoimmillaan. Solun voi ylikirjoittaa. Arvon voi vaihtaa. Kommentin voi lisätä jälkeenpäin. Lopputulos näyttää siistiltä, mutta muutosten logiikka katoaa. Silloin et enää puolusta riskinarviointia. Puolustat vain sen viimeistä versiota.
ISO 12100 riskinarvioinnin esimerkki: yksi kone, 16 vaaratilannetta
Jotta asia ei jäisi teoriaksi, otetaan käytännön tapaus: automatisoitu pakkausasema. Ei geneerinen kone paperilla vaan kokonaisuus, jossa on vaarallista liikettä, käyttäjän puuttumisia prosessiin, tukosten poistoa, kunnossapitotehtäviä, pääsy sähkö- ja paineilmaenergiaan sekä ohjauslogiikkaan sidottuja turvatoimintoja.
Tässä analyysissä ei tehty kahta yleistä riviä tyyliin mekaaninen riski ja sähköinen riski. Arviointi pilkottiin 16 erilliseen tilanteeseen: 13 tehtäväkohtaiseen vaaratilanteeseen ja 3 vaaratapahtumaan ISO 12100:n logiikan mukaisesti. Mukana olivat esimerkiksi:
- pienet puuttumiset prosessiin käytön aikana
- tukosten poistaminen
- suojausten säätö
- toimintatestit
- energian irtikytkentä
- kuluvien osien vaihto
- vikadiagnostiikka
- tahaton tai odottamaton käynnistyminen
- kappaleiden sinkoutuminen
- paineilmaenergian vapautuminen
Tämä tarkkuus on ratkaiseva. Hyvässä arvioinnissa ei arvioida konetta yleisesti. Arvioidaan ihmisen suhdetta koneeseen tietyssä tehtävässä, tietyllä vyöhykkeellä, tietyssä käyttötilassa ja tietyillä pääsyehdoilla. Vasta silloin nähdään, mikä on oikeasti kriittistä ja mikä vain kuulostaa yleiskuvauksessa pahalta.
Mitä esimerkki näytti käytännössä?
- Pääongelma ei ollut pelkkä vaarallisen liikkeen olemassaolo, vaan pääsy siihen puuttumisten, tukosten poiston ja vikadiagnostiikan aikana.
- Osa tilanteista voitiin hyväksyä matalana riskinä, mutta vain siksi, että altistumistiheys, tehtävän laajuus, käyttöolosuhteet ja käyttäjän rooli oli rajattu tarkasti.
- Useat tilanteet eivät olleet uskottavasti hallittavissa merkinnällä suojus plus ohje. Niissä piti kuvata turvatoiminto, käynnistyksen eston logiikka, manuaalisen kuittauksen tarve, pääsyehdot ja jäännösriski.
- Vasta audit trail näytti, kuka hyväksyi minkäkin riskin ja miksi jotkin tilanteet vietiin riskin pienentämiseen eikä suoraan hyväksyntään.
Tässä juuri näkyy ero oikean arvioinnin ja näennäisen arvioinnin välillä. Kun analyysi tehdään tehtäväkohtaisesti, osa tilanteista osoittautuu aidosti vähäisiksi. Osa taas pakottaa teknisiin ratkaisuihin. Kumpikaan päätös ei saa syntyä automaattisesti.
Miltä puolustettava riskinarviointidokumentaatio näyttää
Hyvä riskinarviointi ei ala vaaralistasta. Se alkaa käyttöön tarkoitetusta tarkoituksesta, käyttäjistä ja koneen rajoista. Sen jälkeen kuvataan todelliset tehtävät, tunnistetaan vaara, määritetään vaaratilanne ja vaaratapahtuma, arvioidaan riski, valitaan suojaustoimenpide oikeassa järjestyksessä, tarkistetaan toissijainen riski, tehdään uusi arviointi ja kirjataan jäännösriski.
Jos dokumentista ei voi lukea tätä ketjua, kyse ei ole siitä, että formaatti olisi väärä. Kyse on siitä, että prosessi on jäänyt kesken.
Siksi käytännön neuvo on hyvin yksinkertainen. Älä aloita taulukosta. Aloita työstä, jota koneella oikeasti tehdään. Kysy, kuka menee minne, milloin, miksi ja mitä energiaa tai liikettä siellä on läsnä. Sen jälkeen vasta päätä, mikä suojaustoimenpide pienentää riskiä ja mitä se samalla muuttaa. Ja pidä audit trail kunnossa, koska muistikuva ei ole dokumentaatio.
Lopputulos on karu mutta rehellinen: ISO 12100 ei kysy, näyttääkö tiedosto ammattimaiselta. Se kysyy, tehtiinkö riskinarviointi oikeasti. Jos vastaus jää epäselväksi, silloin ongelma ei ole paperissa. Ongelma on koneen turvallisuudessa.