Het maken van een Design FMEA is een flinke klus. Het is dan ook verleidelijk om meteen aan de DFMEA te beginnen. Dat is geen goed idee. Door eerst een functionele analyse te maken begin je met een voorsprong. Je hebt duidelijk in kaart gebracht waar je het over moet gaan hebben en dat bespaart je veel tijd en energie bij het opstellen van de DFMEA.
Wat levert de functionele analyse op?
Een fout in de DFMEA is het falen van een functie. Hij doet het niet, te langzaam, te snel, te veel, te weinig of onbedoeld. Dus om na te kunnen denken over de mogelijke fouten moet je eerst vaststellen welke functies het product moet vervullen. Kortom, zonder een functionele analyse is er geen DFMEA.
Een haalbaar doel stellen
Het is meestal niet mogelijk om àlle functies van een product te analyseren in de DFMEA. Hiervoor is niet voldoende tijd en mankracht beschikbaar. Misschien heb je het zelf ook al eens ervaren. Door alles te willen analyseren groeit de FMEA je boven het hoofd. Het eindresultaat is een half-afgemaakte FMEA, of een FMEA die door tijdgebrek veel te weinig diepgang heeft. In beide gevallen is er veel werk verzet zonder dat het gewenste resultaat is behaald. De mogelijke risico’s zijn niet in kaart gebracht. Dat kan beter. Door een aantal weegfactoren mee te laten lopen in de functionele analyse kunnen we op een onderbouwde en systematische manier prioriteiten bepalen. Door je te beperken tot de meest relevante functies in de DFMEA besteedt je de beschikbare capaciteit zo effectief mogelijk. Zo haal je een optimaal resultaat.
Elkaar begrijpen
Tot slot is de functionele analyse bij uitstek de gelegenheid tot communicatie. Om alle eisen en functies van het product in kaart te brengen is er wederzijds begrip nodig tussen jou en het technische team van je klant. Alleen samen kunnen jullie komen tot een goede specificatie voor het product, ofwel de gewenste functies op systeem niveau. Voor een goede door-vertaling van deze systeemfuncties naar de subsystemen en componenten van je product is goede communicatie tussen de verschillende disciplines binnen je eigen bedrijf nodig. Denk hierbij bijvoorbeeld aan hardware, software, elektronica, veiligheid, assembleerbaarheid enzovoort.
Hoe pak je de functionele analyse aan?
Door een lastige taak in stukjes te verdelen wordt deze overzichtelijk. Dat geldt ook voor de functionele analyse. We delen deze op in:
- Vaststellen van het pakket van eisen voor ons product (het systeem)
- Door-vertalen van deze eisen naar de subsystemen en componenten van ons product
- Vaststellen van de interactie-functies binnen ons product
- Vaststellen van de prioriteit van de functies
Voor we hier mee aan de slag kunnen is het goed om eerst af te spreken wat we onder functies verstaan. Hier kan je met gemak een dik boek over schrijven, maar voor dit artikel hou ik het even simpel. Met een functie bedoel ik zowel een actieve functie die bestaat uit een werkwoord met zelfstandig naamwoord als een passieve functie die bestaat uit een zelfstandig naamwoord met een specificatie. Passieve functies worden meestal product eigenschappen genoemd. Op systeem niveau vindt je vooral actieve functies en naarmate je dieper in de structuur van het product duikt ga je steeds meer passieve functies ofwel product eigenschappen zien. Verder maak ik geen onderscheid tussen functionele (wat moet het product kunnen) en niet functionele (limiet waarbinnen het product moet kunnen functioneren) eisen.
1. Het pakket van eisen (PvE)
Waar moet ons product allemaal aan voldoen? Dat moet worden aangegeven door de klant. Dat klinkt makkelijk en logisch, maar dat is het niet. Meestal zitten er onduidelijkheden in het PvE, ontbreken er zaken in of worden er overbodige dingen gevraagd. Om tot een goed PvE te komen zijn vaak meerdere gesprekken met de klant nodig. Hierin moet je samen komen tot het juiste pakket van zinvolle eisen waarmee je aan de slag kunt met ontwerpen. Deze eisen moeten ook concreet worden gemaakt, dat wil zeggen dat ze moeten worden voorzien van (streef)waarden. De eis “de fiets moet makkelijk te hanteren zijn” is wel relevant, maar nog niet concreet. Wat wordt hiermee bedoeld? Bijvoorbeeld: “Het totale gewicht van de fiets moet minder dan 20 kg zijn” en “het zwaartepunt moet lager dan 45 cm liggen”. Nu hebben we concrete eisen waar we mee aan de slag kunnen.
2. Doorvertalen van de functies
Wanneer we het PvE compleet hebben en alles is omgezet naar concrete functies en eigenschappen moeten we dit gaan projecteren op de subsystemen en componenten van ons design concept. Elk onderdeel van ons product heeft een of meerdere functies die nodig zijn om het PvE te kunnen vervullen. Zo is de hoogte van het zwaartepunt onder andere afhankelijk van de vorm van het frame en het gewicht en de positie van verschillende onderdelen. Om de functionele analyse uit te voeren en overzichtelijk in kaart te brengen zijn er verschillende mogelijkheden.
Quality Function Deployment (QFD).
Dit wordt ook wel “House of Quality”(HOQ) genoemd. Je kunt dit in Excel uitvoeren, maar beter is het om dit in een database omgeving te doen, bijvoorbeeld in Plato Eins. Deze methode geeft een goed overzicht en er kunnen makkelijk weegfactoren worden meegegeven om prioriteiten te bepalen. Bij deze methode is de totale functie analyse verdeeld over verschillende, onderling verbonden HOQ’s.

QFD1 – de fiets

QFD2 – het frame
Een functie netwerk.
Alle functies van alle onderdelen van het design zijn hierin met elkaar verbonden. Het is heel visueel, alles staat in een groot overzicht en het is makkelijk te onderhouden. Dit is de manier waarop de FMEA software APIS werkt.

functie net – compleet overzicht
Het nieuwe FMEA formulier van de AIAG/VDA.
Hierin zijn twee extra kolommen toegevoegd voor functies. Daarmee kan je functies op 3 niveau’s beschrijven. Deze methode geeft weinig overzicht, wat vooral voor meer complexe producten een nadeel is. Voor de meeste producten is dit dan ook niet voldoende en wordt dit met een van beide andere methoden gecombineerd.

DFMEA formulier
3. Bepalen van interactie functies
Wat zeker niet vergeten moet worden zijn de zogenaamde interactie functies. De interactie functies van ons product met zijn omgeving moet worden meegenomen in het PvE. De interactie functies tussen de verschillende delen van ons product moeten in de verder functionele analyse worden meegenomen. Je kunt dit op twee verschillende wijzen doen. Een mogelijkheid is om ze toe te voegen aan de functies van de subsystemen of componenten. Pas op dat je dit altijd op dezelfde manier doet, bijvoorbeeld dat interactie functies altijd worden toegekend aan het grootste component. Zo voorkom je onduidelijkheid en vergissingen. Een ander mogelijkheid is om de interactie tussen component A en component B als een fictief “component” te zien en de voorkomende interactie functies hier aan toekent. Dit is de meest overzichtelijke methode.
4. Bepalen van de prioriteit
Niet elke functie is even belangrijk. De klant zal de ene eis belangrijker vinden dan de andere. Het is belangrijk om dit te bespreken en vast te leggen. Hiermee heb je het eerste criterium te pakken om de prioriteit te bepalen. Het volgende criterium ligt in je eigen organisatie. Hoe moeilijk is het om aan de eisen te voldoen? Zijn er aspecten aan het product waar je nog geen enkele ervaring mee hebt, die op het randje van de technische mogelijkheden liggen of waar je in het verleden veel problemen mee hebt gehad? Die moeten hoog op de prioriteitenlijst komen. Tot slot kan je nog kijken naar de relaties tussen de functies. Een functie van een subsysteem of component die voor relatief veel hoger gelegen functies nodig is krijgt een hoge prioriteit.
Meer FMEA?
Klik hier om u in te schrijven voor dit FMEA vak-blog met regelmatig een nieuw artikel.
Heeft u een goed idee voor mijn volgende onderwerp? Mail naar [email protected]