Strefa wiedzy

Jak prowadzić analizę SFMEA zgodnie ze standardem AIAG & VDA? – dylematy

Ostatnie lata to dla wielu firm intensywna praca nad wprowadzeniem nowego standardu w zakresie FMEA opracowanego wspólnie przez dwie duże organizacje motoryzacyjne AIAG i VDA.

Jak pokazuje historia, prędzej czy później standard AIAG & VDA stanie się codziennością także w firmach prowadzących analizę FMEA w innych branżach.

Podstawowy pracy z FMEA wg AIAG & VDA

Bardzo upraszczając, podstawowe cechy pracy z FMEA zgodnie ze standardem AIAG & VDA to:

• analiza ryzyka w siedmiu, jasno zdefiniowanych krokach,
• nowy, rozbudowany formularz do dokumentowania analizy,
• wykorzystanie wskaźnika AP (ang. action priority) do pokazania konieczności wprowadzenia działań doskonalących.

Problematyczne kwestie w stosowaniu standardu podczas prowadzenia analiz SFMEA

W kontekście analiz takich jak DFMEA (analiza konstrukcji) czy PFMEA (analiza procesu) ten nowy standard i wprowadzone w nim zmiany wydają się być bardzo dobre – szczególnie jak dostosuję się je dodatkowo do specyfiki danej firmy.

W kontekście analizy SFMEA (ang. software FMEA), nazywanej też SwFMEA, pojawia się jednak poważny problem. Wynika on z tego, jak wyznaczany jest wskaźnik AP. Wykorzystywana jest do tego specjalnie opracowana tabela, która dla dowolnych wartości SEV (ang. severity – dotkliwość), OCC (ang. occurrence – częstość występowania) i DET (ang. detection – wykrywalność) przydziela adekwatną wartość AP: H – high, M – medium, L – low. Wartości H, M, L „pokazują” jak bardzo pożądane są dla danego rozważanego problemu działania doskonalące. Fragment takiej tabeli przedstawiono na rys. 1.

Rys. 1. Fragment tabeli AP Źródło: opracowanie własne na podstawie (1)

Zgodnie ze standardem AIAG & VDA w przypadku AP = H i AP = M powinny zostać wprowadzone działania doskonalące, a dopiero AP = L sygnalizuje sytuację „bezpieczną”, która nie wymaga naszej interakcji.

Taki sposób „wyceny” ryzyka to znacząca zmiana, w porównaniu do dotychczasowych wskaźników takich jak:

• RPN = SEV*OCC*DET
• ARPN = SEV + OCC + DET.

I nie chodzi tu o to, że obecnie nie wyliczamy iloczynu lub sumy, ani o to że nie mamy obecnie liczby (np. RPN = 120), ale symbol (H/M/L).

Problem tkwi w „logice” wyznaczania nowego wskaźnika.

W przypadku RPN lub ARPN każda ze składowych (SEV, OCC, DET) była tak samo „ważna”. Można było równie dobrze obniżyć ryzyko doskonaląc prewencję (obniżając OCC), jak i doskonaląc kontrole (poprawiając DET).

W przypadku AP sytuacja jest bardzo odmienna. Jak widać w tabeli – jeżeli SEV = 9 – 10, a OCC = 7 – 10, to żadna kontrola nie pozwala nam „zejść” z poziomu H. W przypadku np. PFMEA nie jest to problem, a raczej motywacja do zajęcia się doskonaleniem procesu przez ograniczenie występowania przyczyny błędu (obniżenie OCC przez działania prewencyjne np. w zakresie TPM, doskonalenia kompetencji operatorów lub wdrażania poka-yoke).

Robiąc analizę SFMEA nie jest to już takie proste. Otóż jednym z „typów” analizy SFMEA jest ocena oprogramowania w aspekcie użyteczności (ang. viewpoint – usability). W tym rodzaju analizy sprawdza się jak program „reaguje” na błędy użytkownika. Co oczywiste – zwykle programiści nie mają wpływu na to jak często użytkownik popełni błąd. Mogą wprowadzić rozwiązania wykrywające nieprawidłowe użycie i nawet blokujące działanie systemu, żeby nie dopuścić do dotkliwych skutków. Jest to jednak postępowanie rozwijające kontrolę, czyli wykrywanie przyczyny błędu systemu, co pozwala na minimalizowanie wskaźnika DET. Wskaźnik AP „nie docenia” jednak takich rozwiązań pozostając na poziomach H lub M.

Jak prawidłowo robić analizę SFMEA wg standardu AIAG & VDA?

Firmy mające działy programowania, a chcące kompleksowo wprowadzić nowy standard AIAG & VDA mają więc poważny dylemat. Pozostają im trzy wyjścia:

1. Wprowadzić w całej firmie jednolity standard określania AP i pogodzić się z tym, że programiści będą często mieli H lub M.
2. W odniesieniu do oprogramowania i analizy SFMEA wykorzystać alternatywne wskaźniki ryzyka.
3. Zachęceni przykładem ze standardem SAE wprowadzić zmiany w układzie tabeli AP tak, żeby bardziej „doceniane” były działania kontrolne.

Podsumowanie

Wybór konkretnego rozwiązania ostatecznie zależeć będzie oczywiście od specyfiki firmy i kompetencji moderatorów. Jak zawsze warto tu mieć na uwadze przede wszystkim pragmatyzm – oby SFMEA nie stało się ciężarem, ale narzędziem do rzeczywistego doskonalenia oprogramowania.

Źródła powiązane:

1. AIAG & VDA FMEA Handbook, ed.1, 2019