*) DFMEA to skrót od Design Failure Mode and Effects Analysis (tłum. analiza przyczyn i skutków błędów projektu) i jest rodzajem FMEA, która analizuje błędy w procesie projektowania produktu, designu, opracowywania.

Kiedy rozmawiam lub czytam o praktycznym stosowaniu DFMEA, często dochodzę do wniosku, że każdy rozumie jego wagę, słyszał, że gdzieś działa dobrze (tu często pojawia się przykład branży lotniczej – ciekawe czy słusznie…), lecz akurat w tym konkretnym projekcie – o którym rozmawiamy, albo w tej konkretnej firmie, podejście do DFMEA jest inne i finalnie dokument DFMEA istnieje… Ale jego wartość nie jest zbyt duża. 

Po uruchomieniu produkcji nikt tam praktycznie nie zagląda, chyba, że ktoś wpisze do poreklamacyjnego planu korygującego „przegląd i weryfikacja / aktualizacja DFMEA” lub klient albo audytor zapyta podczas audytu… Często przytaczane argumenty tłumaczące taki stan to: brak czasu w projekcie, trudności z uzupełnianiem poszczególnych rubryk i szacowaniem poziomów ryzyka. 

Myślę, że nie jestem odosobniony w tym co teraz napiszę. DFMEA bardzo często jest traktowane przez zespoły projektowe jak „piąte koło u wozu”. Jest na liście rzeczy do wykonania. Z realizacją czeka się do ostaniej chwili, tak żeby „przejść” formalne wymagania podczas kolejnych kamieni milowych lub audytów. W rezultacie powstaje dokument – nie dlatego, że komuś pomógł w realizacji projektu – ale dlatego, że musiał powstać.

Jest pozytywna wiadomość. Większość osób (które miałem okazję poznać) zaangażowanych w rozwój produktu ma świadomość, że ten dokument powinien być ważny. Co zatem zrobić, aby takim się stał?

Zastanówmy się przez chwilę jaki jest główny cel zespołu projektującego nowy produkt? Patrząc z perspektywy organizacji, to dostarczenie produktu na rynek w założonym czasie, budżecie oraz jakości. W praktyce sprowadza się to najczęściej do wybrania najlepszego pomysłu (patrz artykuł “Recepta na doby pomysł“) na produkt, a następnie urzeczywistnieniu tej wizji poprzez przygotowanie niezbędnej dokumentacji. Zmierzam do tego, że głównym wyzwaniem od samego początku do końca projektu, jest zarządzanie ryzykiem. Na początku jest to identyfikacja wszystkich ryzyk (technicznych, komercyjnych…), następnie planowanie sposobu ich eliminacji lub minimalizacji, aby docelowo wprowadzić na rynek produkt z akceptowalnym poziomem ryzyk. 

Jeżeli przyjąć taką perspektywę, to zespół projektowy potrzebuje narzędzi do identyfikacji, zarządzania i minimalizowania ryzyk. Takim właśnie narzędziem jest FMEA. W tym artykule skupiam się głównie na DesignFMEA (DFMEA) ale ProcessFMEA (PFMEA) to praktycznie to samo narzędzie skupione na procesie wytwarzania. 

Jak zatem połączyć te trzy elementy?

• świadomość ważności DFMEA
• potrzebę zarządzania ryzykiem
• stosowanie DFMEA jako praktycznego narzędzia do definiowania zadań projektowych.

Pierwszym i najważniejszym krokiem jest umieszczenie DFMEA w centrum zarządzania projektem. Nie mam na myśli wizualnej prezentacji, jak na poniższej ilustracji (chociaż z pewnością pomaga) ale przede wszystkim, realne korzystanie z tego narzędzia podczas planowania kolejnych zadań projektowych.

Zadania te możemy pogrupować w poniższy sposób. To tylko propozycja, która pomoże w dalszej części opisać jak efektywnie wspierać każdy z tych obszarów pracując z DFMEA. 

Grupa 1 – Wymagania techniczne

Grupa 2 – Scenariusze testowe (laboratoryjne i FEA)

• Testy poznawcze
• Testy weryfikacyjne

Grupa 3 – Specyfikacje testowe

Grupa 4 – Przyrządy testowe

Grupa 5 – Charakterystyki specjalne

Grupa 6 – Rysunki techniczne

Grupa 7 – Rekomendacje dla procesu produkcyjnego

Grupa 8 – Specyfikacje techniczne

Wizualnie można to przedstawić następująco:

Każda grupa (1-8) jest połączona z DFMEA dwoma strzałkami: dane wejściowe (kolor pomarańczowy) i wyjściowe (kolor zielony). Podczas spotkań DFMEA zespół definiuje potrzebę, która musi być zrealizowana w poszczególnych grupach (to pomarańczowe strzałki symbolizujące dane wejściowe do działania). Po zrealizowaniu zadania, zespół wraca do analizy DFMEA z otrzymanym wynikiem (to zielone strzałki symbolizujące dane wyjściowe) i decyduje o zmianie lub utrzymaniu powiązanych z tym działaniem ryzyk. 

Proces generowania danych wejściowych i wyjściowych trwa tak długo, jak długo wartość ryzyk jest na nieakceptowalnym przez organizację poziomie. Takie podejście pozwala na zdefiniowanie jasnego kryterium zakończenia prac projektowych. Zdarza się, że zespół projektowy nie potrafi jasno zdeklarować kiedy nastąpi koniec ich prac – no bo przecież zawsze można coś poprawić lub zrobić trochę inaczej… Ocena poziomu ryzyk jest tu bardzo pomocna i pomimo swojego subiektywnego charakteru, może być obiektywnym kryterium końca prac projektowych. Łatwo też w oparciu o to kryterium zbudować projektowy wskaźnik KPI (patrz artykuł “6 kluczowych wskaźników projektowych“).

Warto zaznaczyć, że taki sposób pracy jest możliwy tylko wtedy, kiedy rozwiązanie techniczne zostało już określone. Oznacza to, że zespół wie jak będzie wyglądał produkt, potrafi go zwizualizować (szkice, modele 3D, rysunki techniczne) i znane są jego najważniejsze funkcjonalności.

Poniżej przedstawiłem kilka przykładów jak może wyglądać zarządzanie projektem z użyciem DFMEA jako głównego narzędzia, nadającego kierunek rozwoju produktu. Nawiązuję do wcześniej zaproponowanych grup. Nie skupiam się na tym, w jaki sposób wypełnić arkusz DFMEA. To umiejętność którą można nabyć na szkoleniu i jak każdą kompetencję – trzeba ćwiczyć. Moim celem jest pokazanie jak można wykorzystać spotkania DFMEA do planowania istotnych zadań projektowych.

Wyobraźmy sobie zespół który zastanawia się jakie wymagania techniczne (grupa 1) powinien spełniać produkt. Proces ten nie polega jednak jedynie na zbudowaniu listy, ale zastanowieniu się nad ryzykami niespełnienia tych wymagań przez produkt. 

Firma planuje wprowadzić na rynek produkt, który musi być odporny na rdzę. Wymaganie może być regulacyjne (narzucone prawnie) albo wynikać z oczekiwań Klientów. W zależności od tego jak dotkliwe dla Klienta będzie pojawienie się rdzy, zespół oceni ryzyko odpowiednim poziomem wskaźnika. Najciekawszą częścią jest jednak poszukiwanie powodów pojawienia się rdzy.

Pierwszy powód: zastosowano nieodpowiedni materiał. 

Zachęcam do precyzowania potencjalnych powodów w taki sposób, aby były one obiektywnie weryfikowalne. W tym przypadku mogłoby to być np. Zastosowano materiał, który nie spełnia kryterium jakościowego przedstawionego w normie XYZ po przeprowadzeniu testu w komorze solnej zgodnie z normą ABC. Tak zdefiniowany powód łatwo zweryfikować. Pierwsza definicja nieodpowiedniego materiału w żaden sposób nie przybliża zespołu do wyeliminowania tego ryzyka. Oczywiście może się okazać, że zespół nie wie, według jakiej normy wykonać test. I to jest ten moment, w którym spotkanie DFMEA staje się spotkaniem planującym zadania projektowe w zakresie specyfikacji testowych (grupa 3). W tym przypadku zadnie to: Identyfikacja norm testu w komorze solnej zgodnych z oczekiwaniami docelowych Klientów. 

Drugi powód: produkt został użyty niezgodnie z przeznaczeniem.

Kolejny przykład nieprecyzyjnego określenia potencjalnego powodu, który można sformułować na przykład tak: produkt został wystawiony na bezpośrednie działanie wilgoci (powyżej 80%). Jeżeli produkt musi znajdować się pod zadaszeniem albo w zamkniętym pomieszczeniu to ta informacja musi znaleźć się w specyfikacji produktu (grupa 8), którą otrzyma Klient. 

W tym miejscu warto się zastanowić, jak chcemy ograniczyć sposób użytkowania produktu? Jeżeli musimy zapewnić jakiś okres czasu, w którym produkt powinien być odporny na działanie wilgoci, to wtedy potencjalny powód wystąpienia ryzyka powinien być zapisany tak: produkt został wystawiony na bezpośrednie działanie wilgoci (powyżej 80%) dłużej niż 24h.  Tak zdefiniowany powód można jednoznacznie przetestować i zweryfikować. Jeżeli zespół uzna, że poprzednio zdefiniowany test w komorze solnej jest nieodpowiedni do weryfikacji tego powodu wystąpienia, to powinien zaproponować inny test. Jeśli jednak są wątpliwości, jaki to miałby być test, to właśnie zdefiniowaliśmy kolejne zadanie projektowe z 8 grupy.

Warto zastanowić się jeszcze nad jednym aspektem planując testy w komorach solnych. Ze względu na konstrukcję produktu, niezbędnym może być zaprojektowanie i wykonanie stojaka, który zapewni odpowiednią orientację podczas testu. Jeżeli tak, to zespół powinien zaplanować wykonanie przyrządu testowego (grupa 4).

Kolejne powód wystąpienia ryzyka: niezabezpieczone krawędzie obrabiane mechanicznie nie spełnią warunków normy ABC testu wykonanego według normy XYZ. 

Tak opisane powód wystąpienia wydaje się być całkiem precyzyjny… Wiedząc jednak, że niezabezpieczone krawędzie będą rdzewieć, warto od razu zastanowić się nad formą ich zabezpieczenia i zmienić definicję. Na przykład tak: Cynkowanie ogniowe według specyfikacji VYZ nie zabezpiecza obrabianych krawędzi, tak aby spełnić warunki normy ABC, testu wykonanego według normy XYZ. 

Specyfikacja cynkowania powinna być umieszczona na rysunku produktu (grupa 6) i być oznaczona jako charakterystyka specjalna (grupa 5). Tak określony powód wystąpienia, w przypadku nie spełnienia kryteriów oceny testu, od razu prowadzi zespół do weryfikacji specyfikacji cynkowania lub zdefiniowania innej ochrony. 

Precyzowanie opisów pozwala zadbać o to, aby wybrana później metoda weryfikacji powodu wystąpienia ryzyka, jednoznacznie prowadziła zespół do kolejnego kroku, czyli weryfikacji poziomu ryzyka po otrzymaniu wyników testu. 

Może się zdarzyć, że zespół nie ma doświadczenia w tego typu procesach i nie wie jakie zabezpieczenie antykorozyjne zdefiniować na rysunku. W takim przypadku można zaplanować scenariusz testu poznawczego (grupa 2) wykonując prototypy zabezpieczone różnymi technologiami. Po otrzymaniu wyników wiadomo, które zabezpieczenie ma największe szanse na spełnienie warunków testu. Jest to również podstawa do zmiany poziomu powodu wystąpienia ryzyka na znacznie niższe, oraz element rekomendacji dla procesu produkcyjnego (grupa 7). 

Powyższy przykład pokazuje, ze odpowiednio moderowane spotkanie DFMEA jest miejscem gdzie analizując ryzyka związane z designem produktu, w naturalny sposób definiujemy kolejne kroki w projekcie. Kroki, które identyfikują kolejne ryzyka, planują metody ich weryfikacji i są skupione na ich minimalizacji – co jest celem projektu. 

Analizując tylko jedno ryzyko i kilka potencjalnych powodów jego wystąpienia, zespół zdefiniował zadania w każdej z ośmiu zidentyfikowanych grup. I nie jest to przypadek. Taka sytuacja będzie miała miejsce w analizie każdego kolejnego ryzyka. 

Aby tak się stało, trzeba jedynie pamiętać, aby moderacja każdego spotkania skupiona była na precyzyjnym opisie ryzyka oraz powodów wystąpienia, dla których będzie precyzyjnie zdefiniowane działanie, po wykonaniu którego poziom ryzyka będzie łatwy do weryfikacji / modyfikacji.