Przykład oceny ryzyka wg. ISO 12100

Najgorszy typ oceny ryzyka nie jest chaotyczny. Najgorszy typ oceny ryzyka wygląda profesjonalnie. Ma tabelę, punktację, normy, komentarze i końcowy PDF, który daje zespołowi przyjemne poczucie, że temat został zamknięty. Problem w tym, że ISO 12100 nie ocenia estetyki dokumentu. Ocenia to, czy ktoś rzeczywiście poprowadził proces oceny bezpieczeństwa.

I właśnie tu zaczynają się schody. Bo arkusz nie pilnuje logiki. Nie wymusza przejścia od ograniczeń maszyny do rzeczywistych scenariuszy zadań. Nie przypomina, że po zastosowaniu środka ochronnego może pojawić się ryzyko wtórne. Nie trzyma śladu decyzji. Nie pokazuje, kto zaakceptował ryzyko początkowe, kto zmienił ocenę końcową i na jakiej podstawie ktoś wpisał, że dana funkcja bezpieczeństwa ma mieć właśnie PL d, a nie inną wartość. A kiedy dochodzi do redukcji ryzyka, pozwala zrobić to, co branża lubi najbardziej: pominąć kolejność wymaganą przez ISO 12100 i przeskoczyć od zagrożenia prosto do osłony, procedury albo instrukcji, jakby trzyetapowa logika normy była tylko ozdobą, a nie fundamentem całego procesu.

Dlatego pytanie nie brzmi dziś: czy da się zrobić ocenę ryzyka w Excelu? Oczywiście, że się da. Tak samo jak da się w Excelu stworzyć dokument, który przez chwilę wygląda wiarygodnie. Prawdziwe pytanie brzmi inaczej: czy arkusz potrafi dopilnować procesu, który potem da się obronić technicznie, logicznie i audytowo? I właśnie tu zaczyna się różnica między tabelą a inżynierią.

Excel to nie dokumentacja oceny ryzyka

Skoro da się wszystko wpisać do arkusza, to w czym właściwie problem?

W tym, że ISO 12100 nie wymaga Excela. ISO 12100 wymaga sporządzenia dokumentacji oceny ryzyka. A to nie jest to samo.

Przecież arkusz może zawierać zagrożenia, punktację, normy i środki ochronne. To nadal za mało?

Tak. Bo arkusz może być:

• notatnikiem,
• szkicem,
• roboczą pomocą dla zespołu.

Może zbierać wpisy. Może nawet wyglądać porządnie. Ale jeśli nie potrafi zamienić ciągu decyzji w obronną dokumentację procesu, to nadal pozostaje tylko arkuszem.

Co więc musi pokazywać dokumentacja oceny ryzyka?

Nie tylko to, co wpisano, ale również:

• z jakich założeń to wynikało,
• jakie były ograniczenia maszyny,
• jakie zadania i sytuacje przeanalizowano,
• jakie zdarzenia niebezpieczne uwzględniono,
• jak oszacowano ryzyko,
• jakie środki ochronne dobrano,
• w jakiej kolejności je zastosowano,
• czy pojawiło się ryzyko wtórne,
• jak oceniono ryzyko resztkowe,
• i kto podjął konkretne decyzje.

Czyli problem z Excelem nie polega na tym, że jest „za prosty”?

Nie. Problem polega na czymś gorszym. Excel zbyt łatwo pozwala udawać, że dokumentacja już powstała, chociaż w rzeczywistości powstał tylko porządnie wyglądający arkusz.

I właśnie tutaj zaczyna się różnica między administracją a inżynierią.
Bo dokumentacja oceny ryzyka nie jest zbiorem rubryk. Jest zapisem procesu, który trzeba dać radę po czasie:

• odtworzyć,
• prześledzić,
• zweryfikować,
• i obronić.

A jeśli arkusz tego nie zapewnia?

To nie masz jeszcze dokumentacji oceny ryzyka.
Masz dane robocze. Czasem uporządkowane. Czasem efektowne. Czasem nawet przekonujące na pierwszy rzut oka. Ale nadal tylko dane robocze.

A ISO 12100 nie pyta, czy plik wygląda profesjonalnie.
Pyta, czy proces oceny ryzyka został rzeczywiście przeprowadzony i udokumentowany.

Ryzyko wtórne to moment, w którym większość ocen zaczyna udawać, że problemu nie ma

Czy środek ochronny może sam stworzyć nowe zagrożenie?

Oczywiście, że może.
I właśnie dlatego porządna ocena ryzyka nie kończy się w chwili, gdy ktoś dopisze osłonę, blokadę, reset albo procedurę.

Środek ochronny nie zamyka procesu.
Środek ochronny zmienia układ ryzyka.

Brzmi teoretycznie. Jak to wygląda w praktyce?

Bardzo konkretnie.

Przykład mechaniczny: osłona poprawiła bezpieczeństwo ruchu, ale pogorszyła serwis

Na stanowisku pojawia się ryzyko kontaktu z ruchem niebezpiecznym przy usuwaniu zacięć. Zespół dodaje osłonę ruchomą z blokadą. Na pierwszy rzut oka wszystko wygląda dobrze: dostęp do strefy zagrożenia podczas pracy automatycznej został ograniczony.

Tylko że po zmianie okazuje się, że przy czyszczeniu i usuwaniu zacięć operator musi teraz:

• sięgać głębiej do środka,
• pracować z ręką w ograniczonej przestrzeni,
• wykonywać ruchy w nienaturalnej pozycji,
• operować przez węższy otwór serwisowy.

Czyli główne ryzyko mechaniczne rzeczywiście spadło, ale pojawiło się pytanie:
czy środek ochronny nie stworzył nowego problemu z dostępem, widocznością i ergonomią pracy?

Jeżeli tego nie sprawdzisz, dokumentacja pokaże tylko połowę prawdy.

Przykład elektryczny: poprawa ochrony przed porażeniem może zwiększyć ryzyko błędu organizacyjnego

W szafie sterowniczej pojawia się ryzyko porażenia podczas diagnostyki błędów. Zespół porządkuje temat:

• lepsza obudowa,
• wyraźniejsze rozdzielenie obwodów,
• procedura izolacji,
• weryfikacja braku napięcia,
• dostęp tylko dla osób uprawnionych.

Brzmi dobrze. I zwykle jest dobrze.
Ale po tej zmianie diagnozowanie może stać się:

• dłuższe,
• bardziej wieloetapowe,
• bardziej zależne od właściwej kolejności czynności,
• bardziej wrażliwe na skróty organizacyjne.

I wtedy trzeba zadać kolejne pytanie:
czy nie zwiększyliśmy ryzyka błędu proceduralnego, pominięcia kroku albo niejednoznacznej odpowiedzialności za stan układu?

Ryzyko porażenia mogło spaść, ale jeśli proces diagnostyczny stał się bardziej złożony i mniej czytelny, pojawia się nowe ryzyko wtórne po stronie organizacji pracy i zachowania człowieka.

Czyli ryzyko wtórne nie musi być drobnym efektem ubocznym?

Właśnie nie.

Czasem będzie niewielkie.
Czasem skończy się na lekkim pogorszeniu ergonomii albo dostępu.
Ale czasem — szczególnie przy zmianach logiki sterowania albo sposobu interwencji — może doprowadzić do sytuacji, w której nowy układ pracy jest bardziej podatny na błąd niż ten sprzed wdrożenia środka ochronnego.

I to jest moment, którego nie wolno ignorować.

Dlaczego właśnie tutaj zwykły arkusz najczęściej przestaje wystarczać?

Bo arkusz bardzo dobrze przechowuje stan końcowy:

• zagrożenie,
• środek ochronny,
• wynik po redukcji.

Ale bardzo słabo pilnuje pytania:
co ten środek zmienił dalej?

Nie przypomina, że po dodaniu osłony trzeba jeszcze sprawdzić serwis.
Nie wymusza sprawdzenia, czy nowa logika restartu nie tworzy pokusy obejścia systemu.
Nie prowadzi użytkownika do ponownej oceny po zmianie organizacji pracy przy interwencji elektrycznej.

A właśnie tam zaczyna się prawdziwa różnica między wpisem do tabeli a rzeczywistą oceną ryzyka.

Co z tego wynika?

Jeżeli dokumentacja nie potrafi uchwycić ryzyk wtórnych, to bardzo łatwo zaczyna opisywać świat, który wygląda bezpieczniej niż rzeczywistość.

I wtedy problem nie polega na tym, że środek ochronny był zły.
Problem polega na tym, że nikt nie sprawdził, co ten środek zrobił z resztą układu człowiek–maszyna–proces.

A to już nie jest drobne przeoczenie.
To jest po prostu przerwanie logiki oceny ryzyka.

Ryzyko wtórne to moment, w którym środek ochronny przestaje być oczywistym „plusem”

Czy środek ochronny może stworzyć zagrożenie większe niż to, które miał ograniczyć?

Tak. I właśnie dlatego ocena ryzyka nie może kończyć się na dopisaniu środka ochronnego do tabeli.

Bo środek ochronny nie działa w próżni.
Zmienia sposób obsługi, serwisu, dostępu, interwencji, a czasem również układ energii i wzajemne relacje między elementami maszyny.

Przykład mechaniczny: osłona przed otarciami, która wprowadza ryzyko ścięcia dłoni

Załóżmy, że na maszynie występuje częsty kontakt z krawędzią ruchomego elementu. Skutek pierwotny jest względnie lekki: otarcia, drobne urazy powierzchniowe, może niewielkie stłuczenia. Zespół dodaje więc osłonę. Na papierze wszystko wygląda dobrze — ryzyko kontaktu zostało ograniczone.

Tyle że nowa osłona:

• jest duża,
• ciężka,
• zamocowana na zawiasie,
• i może zostać przypadkowo strącona albo puszczona bez kontroli.

W efekcie zamiast częstych, ale lekkich otarć, pojawia się nowe ryzyko:

• uderzenia osłoną,
• przytrzaśnięcia,
• a nawet ścięcia dłoni lub palców między opadającą osłoną a stałym elementem konstrukcji.

Czyli środek ochronny formalnie rozwiązał jeden problem, ale praktycznie mógł wytworzyć zagrożenie o większej ciężkości skutków niż to pierwotne.

I właśnie to jest ryzyko wtórne, którego nie wolno pominąć.

Przykład z automatyki: poprawiona logika, która prowokuje obchodzenie zabezpieczeń

Na stanowisku dodaje się interlock, reset ręczny i blokadę automatycznego restartu po otwarciu osłony. Sama funkcja bezpieczeństwa jest poprawna. Problem zaczyna się wtedy, gdy nowa sekwencja:

• wydłuża każdą interwencję,
• wybija operatora z rytmu,
• zwiększa liczbę wymaganych kroków przy wznowieniu pracy.

Jeżeli logika została wdrożona bez uwzględnienia realnego sposobu pracy, może pojawić się wtórne ryzyko organizacyjno-behawioralne:

• reset wykonywany odruchowo,
• brak rzeczywistej kontroli strefy przed restartem,
• próby mostkowania urządzeń ochronnych,
• presja na „przyspieszenie” procesu poza założeniami bezpieczeństwa.

Czyli nie sama funkcja jest błędem. Błędem jest wdrożenie jej bez sprawdzenia, jak wpłynie na człowieka i na rzeczywisty przebieg interwencji.

Przykład elektryczny: połączenie wyrównawcze, które zwiększa ryzyko różnicy potencjałów

Załóżmy, że ktoś zauważył problem z jedną częścią maszyny i postanowił „poprawić bezpieczeństwo”, wykonując połączenie wyrównawcze tylko dla tego jednego elementu. Intencja była dobra: ograniczyć ryzyko porażenia przez poprawę ciągłości połączeń.

Tyle że jeśli połączenie wyrównawcze zostaje wykonane wybiórczo, tylko dla fragmentu układu, to można doprowadzić do sytuacji, w której:

• jedna część maszyny ma inny potencjał odniesienia niż reszta,
• przy uszkodzeniu albo stanie przejściowym pojawia się większe ryzyko różnicy potencjałów,
• człowiek dotykający dwóch części układu jednocześnie trafia w bardziej niebezpieczny scenariusz niż przed „poprawką”.

Czyli środek wprowadzony jako poprawa bezpieczeństwa elektrycznego może w rzeczywistości pogorszyć sytuację, jeśli został zastosowany fragmentarycznie i bez spojrzenia na całość układu.

Co łączy te trzy przykłady?

We wszystkich przypadkach ktoś zrobił coś, co na pierwszy rzut oka wygląda rozsądnie:

• dodał osłonę,
• poprawił logikę sterowania,
• dołożył połączenie wyrównawcze.

Problem nie polegał na tym, że środek ochronny istniał.
Problem polegał na tym, że nikt nie sprawdził, co ten środek zrobił z resztą układu człowiek–maszyna–energia–proces.

I właśnie dlatego ryzyko wtórne nie jest dodatkiem do oceny ryzyka

To nie jest ciekawostka.
To nie jest margines dla pedantów.
To jest jeden z najważniejszych testów, czy zespół naprawdę prowadzi ocenę ryzyka, czy tylko dopisuje rozwiązania do problemów.

Bo dobra ocena ryzyka nie pyta wyłącznie:
czy dodaliśmy środek ochronny?

Dobra ocena ryzyka pyta:
czy po dodaniu środka ochronnego układ stał się rzeczywiście bezpieczniejszy — i dla kogo dokładnie?

Audit trail nie jest dodatkiem. To dowód, że ktoś naprawdę myślał

Czy ślad decyzyjny w ocenie ryzyka to naprawdę coś aż tak ważnego?

Tak. I dużo ważniejszego, niż wielu osobom się wydaje.

Bo w praktyce problem rzadko polega na tym, że w dokumentacji nie ma żadnego wyniku. Wynik zwykle jest. Tabela jest. Punktacja jest. Środek ochronny też. Problem zaczyna się wtedy, gdy po tygodniu, miesiącu albo po odbiorze nikt nie potrafi już odpowiedzieć na dużo prostsze pytania:

• kto to wpisał,
• kiedy to zmienił,
• dlaczego uznał ryzyko za akceptowalne,
• dlaczego w jednym miejscu wystarczył opis w instrukcji, a w innym potrzebna była funkcja bezpieczeństwa,
• i na jakiej podstawie ktoś wpisał właśnie taki, a nie inny poziom niezawodności.

Przecież jeśli końcowy dokument jest poprawny, to czy to naprawdę ma znaczenie?

Ma. Bo dokument końcowy pokazuje wynik.
A audit trail pokazuje drogę dojścia do wyniku.

A w ocenie ryzyka ta droga ma znaczenie fundamentalne.
To właśnie ona pokazuje:

• czy decyzje były spójne,
• czy ktoś wracał do wcześniejszych założeń,
• czy po dodaniu środka ochronnego wykonano ponowną ocenę,
• czy ryzyko wtórne zostało zauważone,
• czy ktoś nie zaakceptował zbyt szybko czegoś, co powinno trafić do redukcji,
• czy wpis o PL d wynikał z logiki funkcji bezpieczeństwa, czy z przyzwyczajenia.

Jak to wygląda w praktyce?

Bardzo konkretnie.

Przykład 1: ktoś zmienia ocenę sytuacji zagrożenia ze średniego poziomu na niski, ale po miesiącu nie wiadomo dlaczego

W arkuszu widać tylko stan końcowy:

• wcześniej było średnie,
• teraz jest niskie,
• ryzyko zaakceptowane.

I co dalej?

Dalej bardzo często nie wiadomo:

• kto zmienił ocenę,
• czy zmiana wynikała z dodania środka ochronnego,
• czy z korekty parametrów,
• czy z ponownej analizy scenariusza,
• czy może po prostu z potrzeby „domknięcia” dokumentu.

Bez śladu decyzyjnego taki dokument wygląda uporządkowanie, ale z punktu widzenia obrony procesu jest bardzo słaby. Bo w praktyce nie da się odróżnić świadomej decyzji inżynierskiej od późniejszego kosmetycznego poprawiania wyniku.

Przykład 2: ktoś zaakceptował poziom niski, ale nikt nie wie na jakiej podstawie

To też jest bardzo częsty przypadek.

W arkuszu zostaje wpis:

• niskie,
• akceptowalne,
• temat zamknięty.

Tylko że po czasie pojawia się pytanie:
dlaczego to ryzyko zostało zaakceptowane bez dodatkowych środków?

Czy dlatego, że:

• ekspozycja była sporadyczna,
• ciężkość skutków była niska,
• zadanie wykonywały tylko osoby przeszkolone,
• warunki pracy były kontrolowane?

Czy może po prostu dlatego, że wynik liczbowy był niski i nikt nie chciał już do tego wracać?

Bez śladu decyzji nie ma różnicy między jednym a drugim.
A to oznacza, że dokumentacja przestaje być obronna.

Przykład 3: ktoś wpisuje PL d, ale nie zostawia po sobie logiki

To jest jeden z najbardziej niebezpiecznych przypadków.

W dokumencie pojawia się:

• funkcja bezpieczeństwa,
• ISO 13849,
• PL d,
• wszystko wygląda profesjonalnie.

Tylko że po czasie nikt nie umie powiedzieć:

• jaka dokładnie funkcja bezpieczeństwa miała ten poziom realizować,
• czego dotyczyła,
• co monitorowała,
• co odcinała,
• dlaczego wymaganie zostało ustawione właśnie tak,
• i czy ta decyzja wynikała z rzeczywistej oceny ryzyka, czy z branżowego automatyzmu.

I właśnie tu audit trail staje się czymś więcej niż historią zmian.
Staje się dowodem, że decyzja miała techniczną treść.

Czyli audit trail nie służy tylko do tego, żeby „mieć historię”?

Nie.
To nie jest ozdobnik do systemu.
To nie jest funkcja „na wypadek audytu”.
To jest pamięć inżynierska projektu.

Bez niej bardzo szybko wszystko zaczyna się spłaszczać do końcowego PDF-a, który wygląda dobrze, ale nie pokazuje:

• kto co zrobił,
• kiedy to zrobił,
• z czego ta decyzja wynikała,
• i jak zmieniał się obraz ryzyka po drodze.

A dlaczego zwykły arkusz tak źle sobie z tym radzi?

Bo arkusz dobrze przechowuje wynik końcowy, ale fatalnie przechowuje logikę zmian.

Można w nim nadpisać komórkę.
Można poprawić wartość.
Można dopisać komentarz.
Można zmienić opis.

Ale po chwili bardzo trudno odróżnić:

• rozwój analizy,
• od ręcznego porządkowania dokumentu,
• od późniejszego dopasowywania wyniku do oczekiwanego wniosku.

I właśnie dlatego ocena ryzyka bez śladu decyzji bardzo szybko zaczyna przypominać dokument, który „zawsze wyglądał tak samo”, nawet jeśli w rzeczywistości po drodze wydarzyło się pięć ważnych zmian.

Co z tego wynika?

Jeżeli nie potrafisz odtworzyć procesu podejmowania decyzji, to nie bronisz już oceny ryzyka.
Bronisz tylko jej ostatniej wersji.

A to za mało.

Bo dobra dokumentacja nie ma tylko pokazywać, że na końcu wpisano „ryzyko akcepotwalne”.
Ma jeszcze pokazywać, jak ktoś do tego doszedł i czy po drodze nie zgubił rzeczy, które w bezpieczeństwie maszyn gubią się najłatwiej:

• logiki redukcji,
• ryzyk wtórnych,
• uzasadnienia decyzji,
• i spójności między zagrożeniem, środkiem ochronnym oraz ryzykiem resztkowym.

Przykład oceny ryzyka ISO 12100: jedna maszyna, kilkanaście sytuacji zagrożenia

Żeby nie zatrzymać się na teorii, weźmy przykład rzeczywistej oceny ryzyka wykonanej dla zautomatyzowanego stanowiska pakującego. Nie dla abstrakcyjnej „maszyny”, tylko dla układu, w którym występują ruchy niebezpieczne, interwencje operatora, usuwanie zacięć, czynności utrzymaniowe, dostęp do energii elektrycznej i pneumatycznej oraz funkcje bezpieczeństwa zależne od logiki sterowania. I właśnie tu widać najlepiej, dlaczego ocena ryzyka według ISO 12100 nie mieści się w prostym arkuszu z listą zagrożeń.

W przykładowej analizie nie skończyliśmy na dwóch czy trzech ogólnych wpisach. Powstało szesnaście odrębnych sytuacji zagrożenia: trzynaście scenariuszy zadaniowych i trzy zdarzenia niebezpieczne według logiki ISO 12100. Osobno oceniono drobne interwencje podczas pracy, usuwanie zacięć, regulację urządzeń ochronnych, testy funkcjonalne, odłączanie energii, wymianę części zużywających się, diagnostyka awarii oraz zdarzenia takie jak niezamierzony rozruch, wyrzut obiektów czy uwolnienie energii pneumatycznej.

Dopiero taki poziom rozbicia pokazuje rzeczywisty obraz ryzyka. Bo w dobrze prowadzonej analizie nie ocenia się „maszyny ogólnie”. Ocenia się relację człowieka z maszyną w konkretnych zadaniach, konkretnych strefach i konkretnych warunkach pracy. I to właśnie odróżnia przykład oceny ryzyka od tabeli, która tylko sprawia wrażenie kompletnej.

Co pokazał ten przykład w praktyce?

Po pierwsze, główne ryzyko nie wynikało z samej obecności ruchu niebezpiecznego, tylko z dostępu do niego podczas interwencji, usuwania zacięć i diagnostyki błędów.
Po drugie, część scenariuszy można było zaakceptować jako niskie ryzyko, ale tylko dlatego, że wcześniej zostały jasno ograniczone co do częstotliwości, warunków wykonania i roli użytkownika.
Po trzecie, przypadki medium nie dawały się obronić samym wpisem „osłona + instrukcja”. Trzeba było opisać logikę funkcji bezpieczeństwa, sposób blokady restartu, reset ręczny, warunki dostępu i ryzyko resztkowe.
Po czwarte, dopiero pełny ślad decyzji pokazał, kto i dlaczego uznał jedne scenariusze za akceptowalne, a inne skierował do redukcji ryzyka.

Jak wygląda dobra ocena ryzyka ISO 12100 na przykładzie?

Dobra ocena ryzyka ISO 12100 — nawet w wersji przykładowej — nie zaczyna się od wpisania zagrożeń do tabeli. Zaczyna się od ustalenia:

• do czego maszyna jest przeznaczona,
• kto będzie jej używał,
• jakie są jej ograniczenia,
• jakie zadania naprawdę będą wykonywane,
• jakie zdarzenia niebezpieczne trzeba uwzględnić,
• które sytuacje wymagają redukcji ryzyka,
• jakie środki ochronne dobrano i w jakiej kolejności,
• czy pojawiło się ryzyko wtórne,
• jak oceniono ryzyko resztkowe.

Jeżeli w dokumencie nie da się tego odczytać, to nie masz przykładu dobrej oceny ryzyka. Masz tylko arkusz z wpisami.

Co pokazał ten przykład w praktyce?

Po pierwsze, szybko wyszło na jaw coś, co w ocenach ryzyka powtarza się bardzo często: główny problem nie leży w samej obecności ruchu niebezpiecznego, tylko w momencie dostępu człowieka do tej strefy. W naszym przykładzie najistotniejsze scenariusze nie dotyczyły „maszyny jako całości”, ale bardzo konkretnych sytuacji: drobnych interwencji podczas pracy, usuwania zacięć, diagnostyki błędów oraz dostępu do energii elektrycznej i pneumatycznej.

Po drugie, przykład dobrze pokazał, że nie wszystkie sytuacje trzeba traktować tak samo. Część scenariuszy rzeczywiście mogła zostać oceniona jako niskie ryzyko i zaakceptowana bez wdrażania dodatkowych środków poza tymi, które już wynikały z przyjętego sposobu użytkowania. Dotyczyło to na przykład mniej obciążających przypadków związanych z testami funkcjonalnymi, regulacją, wymianą części zużywających się czy wybranymi sytuacjami ergonomicznymi. Ale taka akceptacja nie wynikała z automatu ani z samego faktu, że wynik liczbowy był niski. Wynikała z tego, że dało się obronić:

• małą częstotliwość ekspozycji,
• ograniczony zakres zadania,
• niski przewidywany skutek,
• kontrolowane warunki wykonania,
• i jasno określoną rolę użytkownika.

Po trzecie, kilka scenariuszy od razu pokazało, że bez realnej redukcji ryzyka dokument byłby zwyczajnie niewiarygodny. Dotyczyło to przede wszystkim:

• drobnych interwencji podczas pracy w strefie osłoniętej,
• usuwania zacięć,
• niezamierzonego lub niespodziewanego rozruchu,
• dostępu do części czynnych przy odłączaniu energii,
• diagnostyka błędów na wyposażeniu elektrycznym.

I właśnie tutaj różnica między „arkuszem” a rzeczywistą oceną ryzyka stała się najbardziej widoczna. W tych przypadkach nie wystarcza już wpis typu „osłona + instrukcja”. Trzeba było opisać:

• jaka funkcja bezpieczeństwa rzeczywiście ogranicza ryzyko,
• co dokładnie robi,
• kiedy blokuje ruch niebezpieczny,
• jak wygląda logika restartu,
• kiedy potrzebny jest reset ręczny,
• i dlaczego akurat tutaj wymagany jest określony poziom niezawodności.

Po czwarte, przykład pokazał też bardzo wyraźnie, że dobra ocena ryzyka nie kończy się na pierwszym oszacowaniu. W praktyce trzeba przejść przez cały ciąg decyzji:

• ocena początkowa,
• decyzja, czy ryzyko można zaakceptować,
• dobór środków ochronnych,
• sprawdzenie, czy nie pojawiło się ryzyko wtórne,
• ponowna ocena,
• i dopiero wtedy ocena ryzyka resztkowego.

To właśnie ten etap najczęściej znika w uproszczonych dokumentach. Widać wtedy wynik końcowy, ale nie widać już, jak do niego doszło.

Po piąte, ten przykład dobrze obnażył jeszcze jedną rzecz: nie da się uczciwie ocenić maszyny „ogólnie”. Da się oceniać tylko konkretne relacje człowiek–maszyna:

• przy konkretnej czynności,
• w konkretnej strefie,
• przy konkretnym źródle zagrożenia,
• i przy konkretnych warunkach dostępu.

Właśnie dlatego w porządnej analizie nie wystarcza jeden ogólny wpis o „ruchu niebezpiecznym” czy „ryzyku mechanicznym”. Trzeba rozdzielić sytuacje, bo dopiero wtedy widać, które z nich są naprawdę krytyczne, a które tylko wyglądają groźnie na poziomie ogólnego opisu.

Po szóste, ten przykład pokazał też coś ważnego z punktu widzenia późniejszej obrony dokumentacji: sama obecność norm i wyników liczbowych nie wystarcza. Dopiero połączenie:

• scenariusza,
• strefy zagrożenia,
• źródła,
• decyzji o redukcji,
• środka ochronnego,
• i uzasadnienia ryzyka resztkowego

tworzy dokument, który da się potraktować jako realną dokumentację oceny ryzyka, a nie tylko porządnie wyglądający załącznik.

I właśnie dlatego przykład oceny ryzyka według ISO 12100 jest tak cenny tylko wtedy, gdy pokazuje cały proces. Nie po to, żeby imponować liczbą tabel. Po to, żeby było widać, jak zespół doszedł do decyzji, które ryzyka można zaakceptować, a które wymagają prawdziwej ingerencji technicznej.

Jeśli chcesz zobaczyć przykład dokumentacji oceny ryzyka stworzonej w aplikacji Safety Software kliknij w "Pobierz PDF" pod spisem treści. Jeśli chcesz sam stworzyć taką ocenę ryzyka przetestuj nasze oprogramowanie bez karty i za darmo przez 14 dni rejestrując konto w naszym serwisie.