Den sämsta riskbedömningen är inte rörig. Den ser professionell ut. Exempel på riskbedömning enligt ISO 12100 låter ofta som något man kan fånga i ett snyggt kalkylark med poäng, normhänvisningar, kommentarer och en slutlig PDF som får teamet att känna att frågan är stängd. Problemet är att ISO 12100 inte bedömer hur prydligt dokumentet ser ut. Den bedömer om någon faktiskt har genomfört en process för säkerhetsbedömning.
Och det är här det brukar spricka. Ett kalkylark bevakar inte logiken. Det tvingar dig inte att gå från maskinens begränsningar till verkliga uppgifter, verkliga zoner och verkliga scenarier. Det påminner dig inte om att en skyddsåtgärd kan skapa en sekundärrisk. Det håller inget beslutsspår. Det visar inte vem som accepterade den första nivån, vem som ändrade slutbedömningen eller varför en viss säkerhetsfunktion sattes till PL d och inte något annat.
Frågan är därför inte om det går att göra en riskbedömning i Excel. Självklart går det. Frågan är om kalkylarket kan bära en process som senare går att försvara tekniskt, logiskt och vid granskning. Där går skiljelinjen mellan tabell och ingenjörsarbete.
Exempel på riskbedömning enligt ISO 12100: varför Excel inte räcker
Att allt går att skriva in i ett kalkylark betyder inte att du har dokumentation för riskbedömning. ISO 12100 kräver inte Excel. ISO 12100 kräver dokumentation för riskbedömning. Det är inte samma sak.
Ett kalkylark kan vara användbart. Det kan vara anteckningsbok, skiss, arbetsstöd för gruppen eller en plats där man samlar in data. Det kan till och med se ordnat ut. Men om det inte kan omvandla en kedja av tekniska beslut till försvarbar dokumentation för riskbedömning är det fortfarande bara ett kalkylark.
Det här måste gå att läsa ut ur dokumentationen för riskbedömning:
- vilka antaganden analysen bygger på,
- vilka begränsningar maskinen har,
- vilka användare och uppgifter som faktiskt omfattas,
- vilka farliga händelser och situationer som analyserats,
- hur riskbedömning och uppskattning av risk genomförts,
- vilka skyddsåtgärder som valts,
- i vilken ordning riskreducering skett enligt ISO 12100,
- om en sekundärrisk uppstod efter ändringen,
- hur restrisk bedömts,
- och vem som fattade vilka beslut.
Det verkliga problemet med Excel är alltså inte att det är för enkelt. Problemet är värre än så: Excel gör det alldeles för lätt att låtsas att dokumentation för riskbedömning redan finns, fast det som egentligen finns är ett snyggt kalkylark.
Det är inte hårklyveri. Dokumentation för riskbedömning är inte en samling rutor att fylla i. Det är en registrering av en process som i efterhand måste gå att återskapa, följa, verifiera och försvara. Om kalkylarket inte klarar det har du inte färdig dokumentation för riskbedömning. Du har arbetsdata. Ibland välordnad. Ibland övertygande vid första anblick. Men fortfarande arbetsdata.
Och just här gör många fel när riskreducering ska väljas. De hoppar över ordningen i ISO 12100 och går direkt från risk till skydd, procedur eller instruktion, som om den trestegslogik standarden kräver bara vore pynt. Så fungerar det inte. Först ska risken angripas konstruktivt där det är möjligt. Därefter med tekniska skyddsåtgärder. Information för användning kommer sist, inte först. När den ordningen försvinner ser dokumentet ofta komplett ut, men processen är redan skadad.
Sekundärrisk är punkten där många analyser börjar låtsas att problemet är löst
Kan en skyddsåtgärd själv skapa en ny fara? Ja, självklart. Därför slutar en seriös riskbedömning inte när någon lägger till ett skydd, en förregling, manuell återställning eller en procedur. En skyddsåtgärd stänger inte processen. Den förändrar hela riskbilden.
Mekaniskt exempel: bättre skydd mot farlig rörelse men sämre servicearbete
Tänk dig en station där operatören ibland måste rensa stopp. Teamet lägger till en öppningsbar skyddsåtgärd med förregling för att begränsa åtkomst till en zon med farlig rörelse under automatisk drift. På papperet ser det bra ut. Åtkomsten under normal drift minskar.
Men efter ändringen visar det sig att operatören vid rengöring och stoppavhjälpning måste sträcka sig längre in, arbeta med handen i ett trängre utrymme, ta sämre grepp och jobba i en onaturlig ställning. Den ursprungliga mekaniska risken har minskat, men samtidigt har du öppnat för nya problem med åtkomst, sikt, ergonomi och okontrollerad kontakt med maskindelar under serviceingrepp. Om det inte fångas i dokumentationen visar den bara halva sanningen.
Det kan bli ännu värre. En tung, gångjärnsmonterad skyddsåtgärd kan formellt minska risken för ytliga skador men samtidigt skapa risk för slag, klämning eller till och med skärande skador om den faller eller släpps utan kontroll. Då har skyddsåtgärden i praktiken skapat en sekundärrisk med allvarligare konsekvenser än det ursprungliga problemet. Det är ingen detalj. Det är ett rakt avbrott i logiken om du missar det.
Automations exempel: korrekt säkerhetsfunktion som driver fram kringgående
På en station läggs förregling till, automatisk återstart spärras efter öppning av skyddet och manuell återställning krävs före återgång till drift. Själva säkerhetsfunktionen kan vara helt riktig. Felet uppstår när ingen kontrollerar vad den nya sekvensen gör med arbetssättet.
Om varje liten insats blir längre, mer stegstyrd och mer känslig för rätt ordningsföljd börjar människor anpassa sig. Återställning görs reflexmässigt. Zonen kontrolleras inte ordentligt före start. Någon försöker hålla processen igång genom att kringgå förreglingen. Plötsligt har du inte ett tekniskt fel i säkerhetsfunktionen, utan en sekundärrisk på organisations- och beteendenivå.
Det här är precis den typ av effekt som vanliga kalkylark missar. De är bra på att lagra slutläget: fara, skyddsåtgärd, nytt resultat. De är dåliga på att ställa den avgörande frågan: vad förändrade den här åtgärden i samspelet mellan människa, maskin och process?
Elektriskt exempel: potentialutjämning som ser klok ut men gör läget sämre
Föreställ dig att någon vill förbättra elsäkerheten genom att lägga till potentialutjämning på en enskild del av maskinen. Avsikten är god: bättre kontinuitet, mindre risk för elchock. Men om potentialutjämning görs fragmentariskt, bara för en del av systemet, kan resultatet bli att en del av maskinen får annan referens än resten.
Vid fel eller övergångstillstånd kan det ge större risk för potentialskillnad mellan två delar som användaren kan beröra samtidigt. I klartext: en åtgärd som skulle förbättra säkerheten kan faktiskt försämra den om den inte bedöms i systemperspektiv. Det är också en sekundärrisk. Och den syns sällan i en slutrad med låg poäng och grön färg.
Gemensamt för de här exemplen är att någon gjorde något som först såg rimligt ut: lade till en skyddsåtgärd, förbättrade styrlogiken eller kompletterade med potentialutjämning. Problemet var inte att åtgärden fanns. Problemet var att ingen kontrollerade vad åtgärden gjorde med resten av systemet människa–maskin–energi–process.
Audit trail (beslutsspår) är inte extra administration
Många ser beslutsspår som en fin bonus. Det är fel. Beslutsspår är beviset på att någon faktiskt tänkte. I praktiken är problemet sällan att dokumentationen saknar ett resultat. Resultat brukar finnas. Tabell finns. Poäng finns. Skyddsåtgärd finns. Frågan kommer senare: vem skrev det här, när ändrades det, varför bedömdes risken som acceptabel, och på vilken grund sattes en säkerhetsfunktion till just PL d?
Slutdokumentet visar utfallet. Beslutsspåret visar vägen fram till utfallet. Och i riskbedömning är vägen minst lika viktig som målet.
Ett bra beslutsspår visar bland annat:
- om besluten varit konsekventa,
- om tidigare antaganden behövt revideras,
- om ny riskbedömning gjordes efter en skyddsåtgärd,
- om sekundärrisk upptäcktes eller missades,
- om något accepterades för snabbt,
- och om kravet på en viss säkerhetsfunktion faktiskt kom ur analysen och inte av vana.
Tre typiska haverier återkommer hela tiden.
För det första: någon ändrar en bedömning från medelhög till låg, men en månad senare vet ingen varför. I kalkylarket syns bara slutläget. Utan beslutsspår går det inte att skilja mellan medvetet ingenjörsbeslut och kosmetisk justering för att få dokumentet att se klart ut.
För det andra: någon accepterar låg risk, men det finns ingen motivering. Berodde det på sällan exponering, låg sannolik konsekvens, kontrollerade förhållanden och utbildad personal? Eller bara på att talet i rutan var lågt och ingen ville öppna diskussionen igen? Utan beslutsspår ser de två situationerna likadana ut, fast de inte är det.
För det tredje: dokumentet anger ISO 13849 och PL d, men logiken bakom saknas. Vilken säkerhetsfunktion handlar det om? Vad övervakar den? Vilken farlig rörelse stoppar den? Varför just den nivån? Om det inte går att svara på det i efterhand är markeringen inte ett tekniskt ställningstagande. Den är dekor.
Det här är också varför vanliga kalkylark fungerar dåligt för ändringshistorik. En cell skrivs över. En kommentar justeras. En beskrivning putsas. Efter ett tag är det svårt att skilja mellan analysens utveckling, manuell städning och anpassning av resultat till önskad slutsats. Då försvarar du inte längre riskbedömningen. Du försvarar bara den senaste versionen av filen.
Exempel på riskbedömning enligt ISO 12100: en packstation i 16 situationer
För att inte fastna i teori tar vi ett konkret fall: en automatiserad packstation. Inte en abstrakt maskin på en whiteboard, utan ett verkligt system med farlig rörelse, operatörsingrepp, stoppavhjälpning, underhåll, åtkomst till elektrisk och pneumatisk energi samt säkerhetsfunktioner som beror på styrlogik.
I analysen stannade vi inte vid två eller tre allmänna rader. Vi landade i sexton separata situationer: tretton uppgiftsscenarier och tre farliga händelser enligt logiken i ISO 12100. Det är först på den nivån bilden blir sann.
Följande bedömdes var för sig:
- mindre ingrepp under drift,
- stoppavhjälpning,
- justering av skyddsåtgärder,
- funktionsprov,
- frånkoppling av energi,
- byte av slitdelar,
- felsökning i elutrustning,
- åtkomst till pneumatisk energi,
- oavsiktlig eller oväntad start,
- utkast av föremål,
- frigjord pneumatisk energi.
Det här är kärnan: man bedömer inte maskinen allmänt. Man bedömer relationen mellan människa och maskin i en viss uppgift, i en viss zon, under vissa villkor. Därför är en enda rad om mekanisk risk nästan alltid för grov för att vara trovärdig.
Vad visade analysen i praktiken?
- Huvudproblemet var inte att farlig rörelse fanns. Huvudproblemet uppstod när människor behövde åtkomst under ingrepp, stoppavhjälpning och felsökning.
- Vissa scenarier kunde accepteras som låg risk. Men bara därför att frekvens, villkor och användarroll var tydligt begränsade. Det gällde exempelvis vissa funktionsprov, vissa justeringar och utvalda ergonomiska situationer. Inte för att någon gillade ett lågt tal.
- Flera situationer krävde verklig riskreducering. Där räckte det inte med en rad av typen skyddsåtgärd plus instruktion. Det behövdes beskrivning av säkerhetsfunktion, blockering av återstart, manuell återställning, åtkomstvillkor och motivering av restrisk.
- Den avgörande delen kom efter första bedömningen. Först initial riskbedömning. Sedan beslut om risken kan accepteras eller inte. Därefter val av skyddsåtgärd i rätt ordning. Sedan kontroll av sekundärrisk. Först därefter ny bedömning och slutsats om restrisk.
- Det gick inte att vara ärlig med en generell maskinbedömning. Varje kritisk punkt var knuten till en konkret aktivitet: rensa stopp, kontrollera elutrustning, återställa efter öppning, byta en komponent eller säkra energi.
- Normhänvisningar och siffervärden räckte inte. Först när scenario, riskkälla, zon, vald riskreducering, säkerhetsfunktion och motivering av restrisk hängde ihop blev dokumentationen tekniskt försvarbar.
Det här är också skälet till att ett bra exempel inte imponerar genom mängden tabeller. Det visar hur teamet faktiskt kom fram till att vissa risker kunde accepteras medan andra krävde teknisk förändring. Det är en helt annan sak.
Så ser dokumentation för riskbedömning ut när den går att försvara
En bra dokumentation för riskbedömning ska gå att läsa baklänges. Du ska kunna börja i restrisk och följa besluten tillbaka till ursprunglig situation, antaganden, uppgift, riskkälla och vald riskreducering. Om den resan inte går att göra är dokumentet svagt, även om layouten är snygg.
Det som ska vara tydligt är inte bara vad som skrevs in, utan också varför:
- vad maskinen är avsedd för och vilka begränsningar som gäller,
- vilka uppgifter som verkligen utförs,
- vilka farliga händelser som måste beaktas,
- hur uppskattningen av risk gjordes,
- vilka skyddsåtgärder som valdes och i vilken ordning,
- om en sekundärrisk uppstod efter ändringen,
- hur restrisk bedömdes,
- vem som fattade besluten och när,
- och varför en viss säkerhetsfunktion krävdes, inklusive motiveringen till exempelvis PL d där det är relevant.
När det finns på plats får du inte bara ett dokument som ser professionellt ut. Du får en process som går att försvara vid intern granskning, vid revision, i CE-arbetet och när frågor dyker upp långt senare. Det är där dokumentation för riskbedömning visar sitt värde.
Omvänt gäller också detta: om filen bara visar slutresultat, saknar beslutsspår, hoppar över kontroll av sekundärrisk och inte visar logiken bakom riskreducering, då har du inte en färdig riskbedömning enligt ISO 12100. Du har ett kalkylark som ser ut som en riskbedömning.
Och det räcker inte. Inte tekniskt. Inte logiskt. Inte enligt 2006/42/EG. Och definitivt inte när någon på fullt allvar frågar: hur vet ni att den här maskinen verkligen blev säkrare?