Plan walidacyjny w praktyce: Jak zapewnić niezawodność produktu i minimalizować ryzyka?

Published by

on

Większość projektów dochodzi do fazy, w której trzeba zweryfikować, czy wybrana koncepcja spełnia oczekiwania zdefiniowane w momencie rozpoczęcia prac projektowych. W tym celu przeprowadza się wiele testów, których wyniki powinny pomóc dokonać wspomnianej weryfikacji. Aby proces weryfikacji przebiegł sprawnie oraz zajął najkrótszy możliwy czas, często budujemy plan weryfikacyjny, zwany również planem walidacyjnym. W procesie APQP mamy zazwyczaj dwa takie etapy. DV (Design Verification) – weryfikacja designu produktu oraz PV (Product Verification) – weryfikacja zaprojektowanego procesu wytwarzania i jego wpływu na finalny produkt. Etapów weryfikacji może być oczywiście więcej, co może wynikać ze specyfiki produktu, procesu lub oczekiwań rynku (klientów).

Częste pytania, które pojawiają się w tych fazach to:

  • Ile testów trzeba wykonać, żeby mieć 100% pewność, że weryfikacja jest pewna?
  • Ile sztuk trzeba przetestować, żeby mieć pewność, że wyniki są wiarygodne? 
  • Czy trzeba testować wszystkie możliwe warianty produktu?
  • Ile i jakie części trzeba zmierzyć, żeby potwierdzić wartości nominalne i zakresy tolerancji zdefiniowane na rysunkach?
  • Czy można zmieniać zakres i definicję specyfikacji testowej pomiędzy DV i PV?
  • Jakie testy wykonać i jak je interpretować, jeżeli testowany produkt nie jest dedykowany jednemu klientowi, który zdefiniował co należy testować oraz jak oceniać wyniki testu?
  • Co zrobić, jeżeli wyniki jednego lub kilku testów zakończyły się negatywnie (wynik NOK)?

Artykuł jest próbą odpowiedzi na powyższe pytania.

Aby przygotować się do walidacji produktu, warto odpowiedzieć na  pytanie: jaki jest cel tej fazy projektu? Odpowiedź na to pytanie naprowadzi nas na kolejne kroki przygotowań. 

Głównym celem procesu walidacji jest weryfikacja technicznych ryzyk zidentyfikowanych podczas dotychczasowych prac projektowych. Innymi słowy pozwala odpowiedzieć na pytanie: jak duże (lub małe) jest ryzyko wystąpienia reklamacji lub niezadowolenia Klienta po udostępnieniu produktu na rynku. Dodajmy reklamacji związanej z niespełnieniem deklarowanej funkcji produktu lub niezgodnością z dokumentacją. 

Skoro mowa o ryzykach, to najpierw musimy znaleźć miejsca w dokumentacji projektowej, które zawierają opis zidentyfikowanych ryzyk. Najbardziej oczywistym miejscem są analizy FMEA zarówno dotyczące designu jak i produktu (praktczne wskazówki jak zintegrować DFMEA z zarządzaniem projektem znajdziesz tu) . Kolejnym miejscem będzie dokument(y) który opisuje oczekiwane działanie produktu, segment rynku do którego jest przeznaczony, zakresy parametrów, rozmiarów, cechy które powinien dostarczyć. Te wszystkie informacje docelowo znajdą się w dokumentacji technicznej (Dokumentacja Techniczno Ruchowa lub Karta Danych Technicznych lub Specyfikacja Techniczna, z ang. Technical Data Sheet). Dokumenty zawierające wymienione informacje mogą, ale nie muszą zawierać informacji o poziomie ryzyka. Dlaczego więc o nich wspominam? Jeżeli któraś z wymienionych cech nie będzie dostarczona lub gwarantowana przez produkt, konsekwencją będzie niezgodność, która najprawdopodobniej doprowadzi do reklamacji (lub niezadowolenia Klienta). Kolejnym źródłem ryzyk są rysunki techniczne, ze wszystkimi informacjami tam zawartymi. Często rysunki odwołują się do specyfikacji (wewnętrznych lub ogólnodostępnych), które produkt musi spełniać. Ich niespełnienie prowadzi do wspomnianych wcześniej konsekwencji. 

Mogą istnieć również inne, specyficzne, branżowe specyfikacje lub dokumenty, określające wymagania, które produkt musi spełnić. One również powinny być traktowane jako źródło ryzyk, które należy uwzględnić w planie walidacyjnym. 

Biorąc pod uwagę powyższe informacje można wymienić kilka warunków koniecznych, do tego aby można przystąpić do przygotowania planu walidacyjnego (w fazie DV). Są to:

  • Zamrożony / zwolniony w systemie zarządzania dokumentacją (z ang. PDM) design produktu.
  • Analiza DFMEA zawierająca pełną listę ryzyk z ich określonym poziomem (RPN risk priority number lub poziom wysoki/średni/niski).
  • Wykonane analizy dla krytycznych / istotnych łańcuchów wymiarowych (TCM – tolerance chain management).
  • Zwolniona dokumentacja techniczna (rysunki i specyfikacje) (o tym jak minimalizować ryzyka powstawania błędów na rysunkach technicznych przeczytasz tu).
  • Zrealizowane testy wstępne, mające na celu weryfikację nowych metod testowych.
  • Zwolnione specyfikacje testowe dla wszystkich testów zawartych w planie walidacyjnym.

W celu uświadomienia wagi powyższych warunków, zastanówmy się jakie mogą być konsekwencje ich nie spełnienia przed przystąpieniem do przygotowania planu walidacyjnego? Każde odstępstwo powoduje powstanie nowego ryzyka. Dla przypomnienia, plan walidacyjny pozwala nam na analizę i weryfikację ryzyk. Jeżeli z jakichś względów decydujemy się na takie dodatkowe ryzyka, powinniśmy to transparentnie komunikować całem zespołowi projektowemu. Najczęstszymi konsekwencjami spowodowanymi niespełnieniem warunków krytycznych, są opóźnienia i nieplanowane zwiększenia kosztów w projekcie. Kilka przykładów poniżej:

  • Design produktu nie jest zamrożony – w konsekwencji, podczas tworzenia planu walidacyjnego design może się zmienić. Jeżeli zmiana będzie dotyczyła istotnej funkcji to plan walidacyjny nie będzie jej uwzględniał. Dodatkowo analiza DFMEA nie będzie zawierała analizy ryzyk związanych z tymi zmianami, więc ryzyko nie zaplanowania odpowiednich testów jest wysokie, łącznie z koniecznością powtórzenia planu walidacyjnego,
  • Analiza DFMEA jest niekompletna – jak wyżej, jeżeli jest niekompletna to ryzyko nie zaplanowania odpowiednich testów jest wysokie, łącznie z koniecznością powtórzenia planu walidacyjnego,
  • Analiza łańcuchów wymiarowych jest niekompletna lub pominięta – jeżeli wnioskiem po wykonaniu jakiegoś testu, będzie propozycja zmiany tolerancji, to wpływ tej zmiany na inne wymiary nie będzie znany – więc potencjalnie może spowodować pominięcie niezidentyfikowanego ryzyka lub być powodem do powtórzenia plany walidacyjnego,
  • Rysunki lub specyfikacje są niekompletne lub/i niezamrożone – ryzyka jak wyżej,
  • Nowe metody testowe są niezweryfikowane jakościowo (brak MSA) – jeżeli po zakończeniu planu walidacyjnego okaże się, że metoda testowa ma wskaźnik GRR większy niż 30%, to należy zmienić metodę testową oraz powtórzyć testy w ramach kolejnego planu walidacyjnego,

Załóżmy, że wszystkie warunki konieczne zostały spełnione. Czas rozpocząć prace nad planem walidacyjnym. Potraktujcie to jako inwestycję w przyszłość projektu. Poprawnie przygotowany plan walidacyjny zaowocuje wartościowym wkładem w kolejne fazy projektu. 

Metodologia jest prosta. Do każdego zidentyfikowanego ryzyka należy przypisać test, który pozwoli dane ryzyko zweryfikować. Dla każdego ryzyka warto zadać poniższe pytania:

  • Który test najbardziej nadaje się na weryfikację tego ryzyka? Pamiętamy, że wybieramy tylko spośród testów, które są ustandaryzowane i  mają potwierdzoną wartość GRR – jeżeli nie masz tak przygotowanych testów, to musisz zaakceptować ryzyko konieczności wykonania dodatkowych testów w przyszłości lub wydłużyć czas przygotowań planu walidacyjnego,
  • Który wariant produktu powinien być przetestowany dla tego konkretnego ryzyka? Być może więcej niż jeden? Częstym uproszczeniem jest testowanie wariantu MAX i MIN, zakładając, że wszystkie warianty pomiędzy zachowałyby się podczas testu tak samo, albo conajmniej z takim samym trendem,
  • Jakie jest kryterium OK/NOK dla planowanego testu. To jedno z kluczowych pytań, które nie powinno pozostać bez odpowiedzi. Dlaczego? Wyobraź sobie sytuację, że planujesz wykonanie testu. Testu, który jest ustandaryzowany. Twój zespół wykonywał go wielokrotnie. Ma pełną świadomość jakie rezultat można otrzymać. Jeżeli w takiej sytuacji zespół nie potrafi jednoznacznie określić oczekiwanego wyniku, który będzie zakwalifikowany jako OK lub NOK, to również nie będzie potrafił ocenić wyniku otrzymanego po wykonaniu testu. W takiej sytuacji powinieneś zadać sobie pytanie, czy aby na pewno wybraliście właściwy test, albo czy test jest właściwie ustandaryzowany i Twój zespół rozumie jego istotę. Brak możliwości zdefiniowania kryterium OK/NOK dla wyniku testu (przed jego przeprowadzeniem), zawsze powinno być traktowane jako poważnie ryzyko. Jedynym wyjątkiem może być test o charakterze poznawczym, który jest częścią planu walidacyjnego, ale nie jest połączony z konkretnym ryzykiem i jego wynik nie będzie miał znaczenia na finalne określenie rezultatu planu walidacyjnego. 

Zadając powyższe pytania dla każdego zidentyfikowanego ryzyka (w dokumentach wspomnianych powyżej), tworzymy plan walidacyjny. Ta metoda pozwala na zaplanowanie i weryfikację wszystkich zarejestrowanych ryzyk w projekcie. Kolejną zaletą tej metody jest jednoznaczne określenie końca tej aktywności. Po uwzględnieniu i przeanalizowaniu wszystkich ryzyk oraz zaplanowaniu niezbędnych testów masz pewność, że żadne ryzyko nie zostało pominięte

Szczególnie w przypadku projektów typu NPI (New Product Introduction), których celem jest nowy produkt w portfolio produktów firmy, często zdarza się, że podczas pracy nad planem walidacyjnym zidentyfikujesz test, albo wariant testu, którego procedura testowa nie istnieje. To zupełnie normalne. Przecież zespół pracuje nad zupełnie nowym produktem z perspektywy firmy, więc brak adekwatnych procedur testowych nie powinien dziwić. 

Kolejnym elementem, który będzie wymagał dodatkowych prac projektowych mogą okazać się elementy poszczególnych procedur testowych. Przy definiowaniu testów dla wariantów testowanych części MAX i MIN, często pojawia się potrzeba zaprojektowania i wykonania dodatkowych uchwytów, interfejsów itp. 

Może również pojawić się potrzeba wykonania testów, których zespół projektowy nie będzie w stanie przeprowadzić istniejącymi zasobami firmy. W takie sytuacji warto przeprowadzić analizę zrób-lub-kup (z ang. Make-or-Buy). Dla testów, które w perspektywie obecnego i kolejnych planowanych projektów wydają się być kluczowe, warto zastanowić się nad zakupem infrastruktury testowej (pamiętając o tym, że proces projektowania i inwestycji z reguły jest długi). W takich sytuacjach alternatywnym wyborem jest zlecenie wykonania testu w zewnętrznym laboratorium. Z punktu zachowania wysokiej jakości planu walidacyjnego, realizacja testu wewnątrz lub na zewnątrz firmy, nie powinna mieć żadnego znaczenia. Aby ten wpływ był pomijalny, testy zewnętrzne powinny być traktowane tak jak wewnętrzne, tzn. muszą być realizowane w oparciu o zweryfikowane / zwalidowane metody testowe, ze zweryfikowanym wskaźnikiem GRR< 10% (lub warunkowo <30%).

Po skompletowaniu listy potrzebnych testów, zdefiniowaniu miejsca realizacji, zleceniu wykonania niezbędnych a brakujących elementów oprzyrządowania, przechodzimy do kolejnego pytania: ile części każdego wariantu, w każdym zaplanowanym teście należy przetestować?

W przypadku testów produktu, który jest projektowany i wykonywany dla konkretnego klienta, odpowiedź można znaleźć w dostarczonych specyfikacjach. Jeżeli jednak przygotowujemy plan walidacyjny dla wielu klientów (projekt typu NPI), to musimy tę dezycję podjąć sami. 

Prosta zasada mówi, im więcej części przetestujesz tym bardzie wiarygodne wyniki testu uzyskasz. Ale ta zasada nie zawsze pomaga w określeniu ilości części potrzebnych do testów. 

Zastanówmy się przez chwilę, czy w przypadku każdego testu, ilość części ma takie samo znaczenie?

Przykład 1.

Materiał, który planujesz zastosować w produkcie jest dostarczany zgodnie ze standardem produkcyjnym. Standard ten zakłada zakresy tolerancji dla różnych parametrów. W planie walidacyjnym zaplanowałeś testy dla wartości MIN i MAX dla jednego z krytycznych parametrów dla projektowanego produktu. 

Kluczowe pytanie, które trzeba zadać w tym przykładzie to: czy jesteś w stanie otrzymać od dostawcy materiału, części wykonane w górnej (MAX) i dolnej (MIN) tolerancji parametru

Bardzo często jest to niemożliwe, ponieważ podane w specyfikacji wartości to efekt wpływu wielu czynników, którymi dostawca nie jest w stanie precyzyjnie manipulować w celu osiągnięcia dokładnej wartości parametru

Co zrobić w takiej sytuacji? Zrezygnować z przeprowadzenia testu? 

Z pomocą przychodzą narzędzia z grupy MES – metoda elementów skończonych (z ang. FEA  – finite element analysis).

To kolejny rodzaj testu, obok testów fizycznych, który często jest integralną częścią planu walidacyjnego – test wirtualny.

W przypadku tego typu testów kluczowym elementem jest model numeryczny zastosowany do testu. Jego przygotowanie wymaga conajmniej kilku przeliczeń i dopasowań (iteracji), obliczenia korelacji do rzeczywistych testów (na wysokim założonym poziomie np. 80%) oraz założenia, że trendy / tendencje materiałowe obowiązują w całym zakresie pomiędzy wartością MIN i MAX analizowanego parametru. Jest to często jedyna dostępna metoda, z której pomimo wysokiej czasochłonności, szczególnie dla krytycznych parametrów materiałowych lub funkcjonalnych nie powinniśmy rezygnować. 

Przykład 2.

Częstym dylematem zespołów projektowych w fazie walidacji designu jest weryfikacja zakresów tolerancji wymiarowych umieszczonych na rysunkach. Dylemat polega na tym, jak zapewnić, aby wszystkie komponenty bez względu na to, czy zostaną dostarczone w górnym, czy dolnym zakresie tolerancji, dostarczały zaplanowaną fukcjonalność

Pierwszym krokiem w tego typu analizie może być wyznaczenie kluczowych funkcjonalnych łańcuchów wymiarów i skupienie się tylko na nich. Zakładając, że pozostałe wymiary nie mają istotnego wpływu na funkcjonowanie produktu.

Tak wyznaczone łańcuchy wymiarowe należy przeanalizować używając dostępnych narzędzi ( z ang. TCM). W ten sposób uprościmy fizyczną weryfikację całego łańcucha wymiarów i ich tolerancji, do jednego analizowanego wymiaru w wartości MIN i MAX. Wyznaczając wymiar analizowanego łańcucha warto zastanowić się i zapewnić, aby w fazie walidacji dostarczyć komponent (lub złożenie) w wartości maksymalnej i minimalnej tego wymiaru

Znane mi metody i narzędzia wspomagające analizę łańcuchów wymiarów i ich tolerancji zakładają, że pomiary wymiarów będą miały rozkład normalny i wartość Cpk na poziomie conajmniej 1,33 lub 1,64 dla wymiarów mających wpływ na bezpieczeństwo (wartość tego wskaźnika może być definiowana globalnymi lub wewnętrznymi specyfikacjami. Na etapie walidacji musimy zapewnić odpowiednią ilość pomiarów testowanych części, aby te założenia potwierdzić. O tym, jak to zrealizować można przeczytać tu https://blog.minitab.com/en/30-piece-capability-study-automotive

Po wykonaniu wszystkich zaplanowanych testów w planie walidacyjnym trzeba podsumować otrzymane rezultaty. Jeżeli zespół projektowy ustalił kryteria oceny testów, to proces ten powinien być krótki. 

Co zrobić jeżeli wynik testu został zakwalifikowany jako NOK?

Zacznij od analizy wszystkich dostępnych danych. Może się okazać, że sposób kolekcjonowania wyników był nieprawidłowy (niewłaściwe urządzenie lub metoda lub sposób przygotowania części), w formułach weryfikacyjnych jest jakiś błąd (np. zakresy funkcji w Excel są przystosowane do innej ilości danych), wprowadzone wyniki mają inną jednostkę lub mnożnik w porównaniu do  kryterium oceny itp. Po wyeliminowaniu potencjalnych technicznych, metodologicznych powodów, warto przejść do analizy testowanych części. Czy wyglądają tak jak tego oczekiwaliśmy? Czy zniszczony został komponent, który według obliczeń powinien ulec zniszczeniu? Czy otrzymane wyniki są powtarzalne Cp > 1,33 czy mocno rozproszone? Czy jest jakaś mała grupa części, które zachowały się inaczej niż większość testowanych części? 

Odpowiedź na te i podobne pytania może naprowadzić zespół na powód otrzymania negatywnego rezultatu testu. Po dokonaniu niezbędnych zmian i eliminację zidentyfikowanych powodów, test należy powtórzyć.

Bez zidentyfikowania tego powodu(ów), zespół nie będziecie w stanie nic zmodyfikować w procedurze przeprowadzenia testu. Przeprowadzenie tego samego testu, bez żadnych modyfikacji to ostatni scenariusz do którego zachęcam – ze względu na całkowity brak racjonalnych przesłanek do osiągnięcia sukcesu. Mam również na myśli sytuację, w której po powtórzeniu testu w identycznych warunkach, wynik testu jest pozytywny. Skoro nic nie zostało zmienione dlaczego wyniki jest inny? Czy aby na pewno zespół projektowy ma świadomość podejmowanych decyzji i potrafi wiarygodnie argumentować swoje działania?

Jest również możliwy taki scenariusz, że wynik NOK nie jest spowodowany błędem procedury testowej, niepoprawnym przygotowania części do testów ale wynika z błędnych założeń projektowych, obliczeń lub innych pomyłek lub błędów

To rola planu walidacyjnego. Weryfikuje on, czy to co przygotował zespół projektowy, działa zgodnie z założeniami, definicją i opisem w dokumentacji. Jeżeli wyniki wskazują, że produkt nie spełnia założonych oczekiwań, mamy do wyboru trzy scenariusze. 

Pierwszy to weryfikacja dotychczasowych prac projektowych i próba zmiany definicji produktu w taki sposób, aby kolejne wyniki testów były pozytywne. 

Drugi, to zmiana (obniżenie) wymagań dla produktu, tak aby wyniki testów je potwierdzały. 

Trzeci to zamknięcie projektu na tym etapie. 

Jedno z zadanych na początku artykułu pytań to: Czy można zmieniać zakres i definicję specyfikacji testowej pomiędzy DV i PV? 

Być może po lekturze tego artykułu masz już odpowiedź… 

Moja odpowiedź jest taka. Jeżeli chcesz obserwować, jak praca zespołu projektowego wpływa na właściwości projektowanego produktu / usługi, to każda zmiana planu walidacyjnego utrudni tę obserwację. Najmniejsza zmiana, może być porównana do zmiany zasad gry podczas gry, co utrudnia albo wręcz uniemożliwia ocenę końcowego wyniku. 

Co nie oznacza, że nie możesz tego zrobić. Możesz. Zrób to świadomie, zidentyfikuj ryzyka związane z tą decyzją i poinformuj zespół projektowy. 

W celu usystematyzowania kroków w procesie przygotowania, realizacji i zakończenia planu walidacyjnego, załączam listę kontrolną, która porządkuje cały proces. 

  1. Nowy produkt to gra zespołowa – jak skutecznie zaangażować R&D w sprzedaż i marketing? – R&D Coach Avatar

    […] R&D zakończył prace rozwojowe. Zweryfikował ryzyka projektowe (o tym więcej w artykule: Plan walidacyjny w praktyce), zwolnił dokumentację techniczną (szerzej o tym etapie piszę w artykule „Przegląd […]

    Like

Leave a comment

Previous Post
Next Post