Pamiętam jedno ze spotkań dotyczących nowych uruchomień, jeszcze z czasów, gdy pracowałem jako SQE dla klienta. Omawialiśmy na nim plan badań niezawodnościowych. Niby zwykły dokument. Tabela, trochę danych, odniesienia do FMEA, DVP&R, kilka działań, kilka komentarzy.

Z zewnątrz nic spektakularnego.

Tylko że bardzo często właśnie takie dokumenty mówią o projekcie więcej niż niejedna prezentacja ze statusami na zielono.

Jeśli dokument jest dobrze przygotowany, to znaczy, że łączy doświadczenia z wcześniejszych projektów, dane z rynku, analizę ryzyka, działania projektowe i testy walidacyjne.

Jeżeli jest zrobiony słabo, to staje się kolejnym wymaganiem odznaczonym na spotkaniu. Właśnie dlatego ten temat jest ciekawy. Bo sam dokument niczego nie zabezpiecza. Zabezpiecza dopiero to, co z niego wynika dla projektu, testów i decyzji zespołu.

I właśnie dlatego ten temat jest ciekawy. Bo sam dokument niczego nie zabezpiecza (w sumie jak niestosowana procedura). Zabezpiecza dopiero to, co z niego wynika dla projektu, testów i decyzji zespołu.

Czym jest plan badań niezawodnościowych

Najprościej mówiąc, plan badań niezawodnościowych to dokument, który ma uporządkować myślenie o ryzyku wyrobu przed startem produkcji seryjnej. Nie chodzi tylko o to, żeby wpisać badania wytrzymałościowe, funkcjonalne albo kilka punktów z walidacji.

Chodzi o to, żeby zespół miał wspólny obraz tego:

• jakie problemy mogą się pojawić,
• których komponentów dotyczą,
• skąd wiemy, że takie ryzyko istnieje,
• co trzeba sprawdzić,
• co trzeba zmienić,
• kto za to odpowiada.

Tu pojawia się pierwszy błąd, który widzę dość często.

Wiele osób w organizacji, w szczególności z zakładów produkcyjnych, nie zna tego dokumentu. Jeśli natomiast jakaś wiedza występuje to bardziej identyfikują go jako dokument laboratoryjny. Tymczasem to nie jest papier tylko dla test engineerów. To jest dokument dla całego zespołu projektowego: jakości, R&D, dostawcy, walidacji, czasem również osób od reklamacji (w szczególności tych od zwrotów gwarancyjnych).

W praktyce taki plan znajduje się gdzieś pomiędzy APQP, FMEA i DVP&R. Ma pomóc połączyć ryzyko z działaniem i wspierać projekt w dojściu do produkcji seryjnej.

To nie jest lista testów

Jeżeli plan badań niezawodnościowych staje się tylko listą badań, to bardzo szybko traci sens. Wtedy pojawiają się wpisy typu:

• zrobić test,
• sprawdzić wytrzymałość,
• potwierdzić w DVP&R,
• temat do weryfikacji.

Niby coś jest. Ale z takiego wpisu niewiele wynika. Dobry dokument powinien pokazać prostą logikę: jaki problem widzimy, czego on dotyczy, skąd o nim wiemy i jakie działanie ma ograniczyć ryzyko. To jest ogromna różnica.

Co taki dokument pokazuje w praktyce

Najczęściej dany wyrób gotowy rozbijany jest na komponenty i konkretne objawy.

Przykładowo dla kompletnych siedzeń (którymi się zajmowałem) pojawiają się tematy związane z zużyciem elementów zagłówka, luzami we  współpracujących mechanizmach, wpływem temperatury na regulację, interferencją sąsiadujących elementów, niewłaściwą gęstością pianki PUR (stosowanej na siedzisku, oparciu i zagłówku), czy problemami wynikającymi z nieprawidłowego momentu dokręcania.

Są też odniesienia do DVP&R, DFMEA, PFMEA, analiz CAD i działań projektowych. Tak to powinno wyglądać. Nie „siedzenie może mieć problem”.

Tylko:

• który element,
• jaki objaw,
• jaki mechanizm awarii,
• jakie działanie,
• jaki dowód zamknięcia.

Niby brzmi banalnie, ale właśnie na tym poziomie szczegółu odróżnia się dokument użyteczny od dokumentu, który tylko istnieje.

Skąd biorą się wpisy do planu badań niezawodnościowych

Dobre pytanie brzmi nie „co wpisaliśmy do planu”, tylko „dlaczego to tam w ogóle jest”. Sensowny plan badań niezawodnościowych nie bierze się z kreatywności uczestników spotkania (to nie Ishikawa). Powinien wyrastać z kilku źródeł.

Pierwsze to wcześniejsze problemy z rynku.

Jeżeli podobny komponent miał już kiedyś problem z luzem, zużyciem, hałasem, pękaniem, regulacją albo estetyką, to nie jest ciekawostka historyczna. To jest sygnał ostrzegawczy dla nowego projektu i element strategii Lesson Learned.

Drugie źródło to FMEA.

I tu nie chodzi o to, żeby w prezentacji rzucić hasło „jest w FMEA”. Chodzi o to, żeby DFMEA albo PFMEA naprawdę podpowiadały, gdzie produkt lub proces są wrażliwe.

Trzecie źródło to DVP&R i inne ustalenia walidacyjne.

Jeżeli zespół już wie, jakie badania mają potwierdzić odporność rozwiązania, to plan badań niezawodnościowych powinien to odzwierciedlać.

Czwarte źródło to doświadczenie ludzi, którzy ten wyrób znają.

Czasem ktoś z jakości, ktoś z dostawcy albo ktoś z rozwoju produktu pamięta, że podobny temat miał miejsce przy poprzednim projekcie. Takie doświadczenie też ma znaczenie. O ile kończy się konkretem, a nie „opowieścią drzewa sandałowego”.

Na co patrzeć, gdy czytasz taki dokument jako jakościowiec

Z perspektywy jakości ten dokument ma pomóc zadawać niewygodne pytania, zanim zrobi to klient. Ja zacząłbym od pięciu rzeczy.

1. Czy problem jest konkretnie opisany

Jeżeli widzisz wpis typu „possible issue” albo „to be checked”, to jeszcze nic nie wiesz.

Dużo lepiej, gdy dokument mówi wprost:

• nadmierny luz,
• hałas,
• zużycie elementu,
• ciało obce w mechanizmie,
• niewłaściwa regulacja w zmiennej temperaturze,
• kontakt dwóch sąsiednich części.

Wtedy wiadomo, o czym rozmawiamy.

2. Czy wiadomo, skąd bierze się ryzyko

To jest bardzo ważne.

Jeżeli temat wynika z DFMEA, PFMEA, DVP&R, wcześniejszego programu, analizy CAD albo problemów z rynku, to dokument ma fundament.

Jeżeli nie wiadomo, skąd wpis się wziął, to zwykle są dwie opcje. Albo temat jest wrzucony na wszelki wypadek. Albo przeciwnie – jest zbyt ogólny i nikt nie umie go obronić. Tak czy siak, jedno i drugie osłabia cały plan.

3. Czy działanie rzeczywiście odpowiada na problem

Masz ryzyko związane z ciałem obcym w mechanizmie regulacji, a działanie jest opisane tak szeroko, że równie dobrze mogłoby dotyczyć pięciu innych tematów.

Masz problem z nadmiernym luzem, a wpis kończy się na ogólnym „verify in testing”.

Masz ryzyko wynikające z temperatury, ale nie ma jasności, w jakich warunkach temat będzie oceniany.

To są sygnały, że dokument nie prowadzi jeszcze do decyzji.

4. Czy jest właściciel i termin

Bez tego plan bardzo szybko staje się listą życzeń.

Niby wszyscy widzą temat, niby wszyscy się zgadzają, ale nikt nie czuje się odpowiedzialny za doprowadzenie go do końca.

A potem na kolejnym review okazuje się, że temat nadal jest „open”, tylko trochę ładniej zapisany. Lub „green” i niech sobie z tem później ewentualnie radzi zakład produkcyjny.

5. Czy wiadomo, jaki będzie dowód zamknięcia

Status zielony nie jest dowodem. Powtórzmy to jeszcze raz, bo to jest jeden z tych tematów, które wracają bez końca. Status zielony nie jest dowodem.

Dowodem może być:

• wynik testu,
• zmiana konstrukcyjna (nazywana także prjektową lub designową),
• potwierdzenie z walidacji,
• aktualizacja DVP&R,
• aktualizacja FMEA,
• potwierdzenie po stronie dostawcy,
• wynik analizy po wdrożeniu zmiany.

Jeżeli tego nie ma, to temat może wyglądać dobrze tylko w tabeli.

Jak odróżnić żywy dokument od dokumentu pod spotkanie

To widać bardzo szybko. Żywy plan badań niezawodnościowych ma konkretne wpisy. Widać w nim logikę, aktualizacje, reakcję na nowe dane i zamknięcia oparte na dowodach.

Martwy dokument wygląda inaczej.

Jest tam sporo ogólników. Statusy się świecą. Część tematów ma wpisane „to be confirmed”. Ownerzy bywają rozmyci (na przykład wpisanie funkcji zamiast nazwisk). Po testach nie ma jasnej decyzji. Wtedy może pojawić się złudzenie, że projekt jest zabezpieczony, bo dokumentacja istnieje. Nie. Dokumentacja może istnieć i jednocześnie niczego realnie nie zabezpieczać.

Co plan badań niezawodnościowych mówi o dojrzałości projektu

Dla mnie to jest jedna z ciekawszych rzeczy.Dlaczego? Ponieważ taki dokument pokazuje nie tylko ryzyko produktu – pokazuje też jakość myślenia zespołu.

Jeżeli zespół potrafi wziąć wcześniejsze problemy, przenieść je do nowego projektu, połączyć z FMEA, z walidacją i z decyzjami konstrukcyjnymi, to widać dojrzałość.

Jeżeli każdy program startuje tak, jakby firma pierwszy raz robiła ten komponent, to też to widać. Zwykle kończy się to podobnie.

W branży motoryzacyjnej nie brakuje narzędzi do uczenia się na błędach. Mamy 8D, mamy lessons learned, mamy read across, mamy FMEA, mamy przeglądy reklamacji i najczęściej dane z sieci gwarancyjnej. Problem zwykle nie polega na tym, że nie ma narzędzi. Problem polega na tym, że organizacja nie przekłada ich na konkretne działania w nowym uruchomieniu.

Co z tego wynika dla całego projektu

Dobrze przygotowany plan badań niezawodnościowych powinien kończyć się decyzją.

Czasem decyzja brzmi:

• dokładamy test,
• zmieniamy detal,
• poprawiamy geometrię,
• zmieniamy materiał,
• dodajemy zabezpieczenie,
• wracamy do dostawcy,
• aktualizujemy FMEA,
• wrzucamy temat do lessons learned.

Wtedy dokument zaczyna mieć sens. Jeżeli po przeglądzie nic się nie zmienia poza statusem w tabeli, to nie ma znaczenia, ile tam jest wpisów.

Dariusz Kowalczyk