Rozmowa po błędzie. Od tego, jakie pytanie padnie jako pierwsze, zależy, czy skończy się na „przeszkolić operatora”, czy na znalezieniu przyczyny. „Operator się pomylił.” Ile razy właśnie tak kończyła się analiza problemu na Twojej produkcji?...
Rozmowa po błędzie. Od tego, jakie pytanie padnie jako pierwsze, zależy, czy skończy się na „przeszkolić operatora”, czy na znalezieniu przyczyny.
„Operator się pomylił.” Ile razy właśnie tak kończyła się analiza problemu na Twojej produkcji?
Moje „ulubione” działanie: przeszkolić operatora!
Tadam!!! Problem zamknięty. Przybijamy sobie piąteczki i produkujemy dalej. A czasem, o zgrozo, na przypieczętowanie naszego trofeum wywieszamy jeszcze OPL nad stanowiskiem, niczym pranie powiewające na wietrze.
Tylko że po kilku tygodniach błąd pojawia się ponownie. I wtedy okazuje się, że „błąd operatora” nie był przyczyną źródłową. Był tylko tym, co wydarzyło się na końcu całego łańcucha. A to proste „rozwiązanie” w konsekwencji często okazuje się tym najdroższym, bo problem wraca.
I właśnie tutaj warto sięgnąć po HERCA, czyli Human Error Root Cause Analysis.
- Czym HERCA różni się od „przeszkolić operatora”
- Jak wygląda analiza HERCA w praktyce
- Krok 1. Rozmowa z operatorem – jak najszybciej po zdarzeniu
- Krok 2. Analiza jakościowa – czy proces i dokumentacja zabezpieczały przed błędem?
- Krok 3. Weryfikacja techniczna stanowiska
- Krok 4. Zebranie faktów i określenie przyczyny
- Krok 5. Plan działań
- Co HERCA daje organizacji
Czym HERCA różni się od „przeszkolić operatora”
Człowiek popełnił błąd.
Pierwsza reakcja? „Nie zastosował się do standardu.”
Ale teraz trzeba zadać kolejne pytanie: dlaczego?
Bo nagle okazuje się, że „operator się pomylił” to zdecydowanie za mało, żeby zakończyć analizę i wdrożyć skuteczne działanie.
HERCA służy do analizy błędów ludzkich. I właśnie to odróżnia ją od prostego podejścia:
człowiek → błąd → szkolenie
W HERCA nie zatrzymujemy się na pytaniu: „Kto popełnił błąd?”. Szukamy odpowiedzi na pytanie: „Co spowodowało, że ten błąd mógł powstać?”.
Problem może tkwić w:
- procesie,
- procedurze,
- wyposażeniu,
- narzędziach,
- organizacji stanowiska,
- warunkach pracy,
- sposobie przekazywania informacji,
- przygotowaniu pracownika,
- częstotliwości wykonywania zadania,
- wymaganym czasie,
- sposobie nadzorowania procesu.
Jak wygląda analiza HERCA w praktyce
Analiza przechodzi przez pięć kroków. Każdy z nich wnosi inną perspektywę: operatora, jakości i techniki. Dopiero razem dają pełny obraz.
Krok 1. Rozmowa z operatorem – jak najszybciej po zdarzeniu
Pierwszym źródłem informacji jest osoba, która faktycznie wykonywała operację.
Im później przeprowadzimy rozmowę, tym więcej szczegółów może zostać zapomnianych, zniekształconych albo odtworzonych z pamięci już po fakcie.
Dlatego lider powinien możliwie szybko porozmawiać z operatorem. Nie po to, żeby znaleźć winnego. Po to, żeby odtworzyć, co dokładnie wydarzyło się w momencie powstania błędu.
- Co operator robił bezpośrednio przed zdarzeniem?
- Jak wyglądała kolejność czynności?
- Co zobaczył?
- Jaką informację otrzymał?
- Z czego korzystał?
- Co było inne niż zwykle?
- Czy coś zakłóciło pracę?
- Czy wystąpiła presja czasu?
- Czy operator miał wątpliwości i czy je zgłaszał?
Operator jest często jedyną osobą, która może dokładnie opisać rzeczywiste warunki, w których powstał błąd.
Dlatego rozmowa nie powinna sprowadzać się do pytania: „Dlaczego tego nie zrobiłeś?”. To pytanie bardzo szybko zamyka rozmowę.
Znacznie więcej informacji daje odtworzenie przebiegu zdarzenia: „Przejdźmy krok po kroku przez to, co robiłeś”. Dopiero wtedy zaczynają pojawiać się fakty. I to jest dokładnie ten moment, w którym kompetencje miękkie lidera decydują o jakości całej analizy.
Krok 2. Analiza jakościowa – czy proces i dokumentacja zabezpieczały przed błędem?
Ten krok należy do działu jakości. Trzeba sprawdzić, czy dokumentacja rzeczywiście wspierała prawidłowe wykonanie operacji.
Do weryfikacji mogą trafić między innymi:
- instrukcja pracy,
- standard pracy,
- standardy jakościowe,
- kryteria akceptacji,
- karty kontroli,
- dokumentacja procesu,
- wymagania klienta,
- zapisy kontroli,
- wcześniejsze niezgodności,
- działania podjęte przy podobnych problemach.
I tutaj często pojawia się bardzo ważne pytanie: czy operator rzeczywiście miał możliwość wykonać operację prawidłowo na podstawie dostępnych informacji?
Bo dokument może istnieć, a mimo to nie zabezpieczać procesu. Instrukcja może być nieaktualna. Standard może nie odpowiadać rzeczywistemu procesowi. Kryterium jakości może być niejednoznaczne. Informacja może znajdować się w innym miejscu niż stanowisko pracy. A procedura może zakładać warunki, które na hali po prostu nie występują.
Krok 3. Weryfikacja techniczna stanowiska
Teraz na stanowisko powinien wejść inżynier. Sprawdzamy, co rzeczywiście dzieje się na stanowisku.
- Czy stanowisko jest prawidłowo przygotowane?
- Czy narzędzia są właściwe, dostępne i sprawne?
- Czy sposób ułożenia elementów nie sprzyja pomyłce?
- Czy można wykonać operację w niewłaściwy sposób?
- Czy proces posiada zabezpieczenia przed błędem?
- Czy parametry są prawidłowo ustawione?
- Czy operator ma możliwość pomylenia komponentów?
- Czy konstrukcja stanowiska wymusza właściwą kolejność czynności?
- Czy występują różnice pomiędzy tym, co przewiduje standard, a tym, co rzeczywiście dzieje się na stanowisku?
To właśnie tutaj bardzo często okazuje się, że problem, który na papierze wyglądał jak „błąd operatora”, w rzeczywistości jest problemem procesu. A ryzyko, które powinno zostać wyłapane dużo wcześniej, na etapie analizy PFMEA.
Krok 4. Zebranie faktów i określenie przyczyny
Mamy już trzy perspektywy:
operator → jakość → technika
Każda daje inny fragment obrazu. Dopiero ich połączenie pozwala określić, co rzeczywiście doprowadziło do błędu.
Trzeba ustalić, dlaczego standard (jeżeli istnieje) nie został zastosowany i co spowodowało, że proces dopuścił do powstania błędu.
Krok 5. Plan działań
Dopiero teraz tworzymy działania. I tutaj również warto uważać na najprostsze rozwiązanie.
Jeżeli przy każdym błędzie wpisujemy „przeszkolić operatora”, to prawdopodobnie nie analizujemy przyczyny wystarczająco głęboko.
Działania powinny wynikać bezpośrednio z ustaleń HERCA:
- jeżeli problemem jest instrukcja — poprawiamy instrukcję,
- jeżeli problemem jest sposób organizacji stanowiska — zmieniamy stanowisko,
- jeżeli możliwa jest pomyłka komponentów — eliminujemy możliwość pomyłki albo wprowadzamy zabezpieczenie,
- jeżeli problem wynika z konstrukcji procesu — zmieniamy proces,
- jeżeli brakuje wiedzy lub umiejętności — szkolimy,
- jeżeli potrzebna jest kontrola — projektujemy właściwy punkt kontroli.
A następnie określamy: co robimy, kto jest odpowiedzialny, do kiedy, jaki jest oczekiwany efekt i jak sprawdzimy skuteczność działania.
Co HERCA daje organizacji
HERCA daje organizacji coś więcej niż kolejną analizę. Zamiast kolejny raz reagować według schematu:
błąd → operator → szkolenie → koniec
organizacja zaczyna działać tak:
błąd → analiza → przyczyna → działanie → weryfikacja
To oznacza mniej powtarzających się błędów, mniej reklamacji i braków, mniej poprawek oraz mniej czasu poświęcanego na gaszenie tych samych problemów. Dokładnie tę różnicę między naprawą a rozwiązaniem problemu opisywaliśmy w tekście „Po co Ci Problem Solving, skoro możesz po prostu naprawić?”.
A przede wszystkim HERCA pozwala przenieść odpowiedzialność za jakość z pojedynczego człowieka na właściwie zaprojektowany i zarządzany proces.
Jeśli chcesz przećwiczyć analizę przyczyn źródłowych na własnych przypadkach, zajrzyj do kursu Rozwiązywanie problemów: 8D, 5 Why, Ishikawa. A jeśli błędy „operatora” wracają u Was jak bumerang, prowadzimy warsztaty z rozwiązywania problemów na Waszej hali i na Waszych realnych przypadkach.
