Funktion, krav och Realisering: kedjan som gör FMEA meningsfull

Av Lennart Larsson Rosén

Tydliga funktioner är grunden i varje FMEA. De beskriver vad kunden värdesätter och vad systemet ska leverera, och utan dem saknar analysen riktning. Men funktionen talar bara om vad som ska hända. Den säger inget om hur systemet faktiskt beter sig när funktionen utförs, eller vilka krav som måste uppfyllas för att det ska lyckas.

Det är där många analyser tappar skärpan.

Ett enkelt exempel: öppna dörren

Ett enkelt exempel: öppna dörren

Ta en så enkel funktion som öppna dörren. Funktionen talar om vad som ska hända. Realiseringen talar om hur det sker i konstruktionen.

Gränssnittsdiagrammet visar vilka komponenter och gränssnitt som är inblandade när funktionen realiseras.

Funktionsträdet bryter sedan ner hur funktionen uppnås genom sina delfunktioner:

Redan detta triviala system går inte att analysera på toppnivå. Det är först på delfunktionsnivå som man ser vad systemet måste göra för att funktionen ska lyckas. Det är också där realiseringen blir meningsfull: gränssnitt, tillstånd, övergångar, begränsningar och beroenden.

Kraven ger felmoderna

Varje delfunktion har, eller borde ha, krav kopplade till sig. När ett krav inte uppfylls får vi en felmod.

Några exempel:

• Handtaget går inte att trycka ned.
• Handtaget faller ned av sig självt.
• Låset frigörs inte.
• Dörren rör sig för lätt.

Inga av dessa felmoder kommer direkt från funktionen. De kommer från hur systemet beter sig när funktionen realiseras, och från de krav som definierar det beteendet.

Varje delfunktion har, eller borde ha, krav kopplade till sig. När ett krav inte uppfylls får vi en felmod.

realisering är navet

I många FMEA:er ser jag samma mönster. Teamet hoppar direkt till felmoder och orsaker, men beskriver sällan systemets beteende tillräckligt tydligt. När beteendet är oklart blir logiken oklar.

Med realisering menar jag hur systemet faktiskt utför en delfunktion, i ett visst tillstånd och under givna förutsättningar. Det är det konkreta beteendet vi fångar med gränssnitts- och tillståndsdiagrammen. Det är också där vi ser hur något kan gå fel.

I en tekniskt sund kedja är beteendet navet:

Funktion → Delfunktioner → Krav → Realisering → Felmoder → Effekter → Orsaker → Verifiering

Varje steg i kedjan har sin egen roll:

• Kraven definierar den acceptabla gränsen.
• Realisering beskriver hur systemet faktiskt utför delfunktionen.
• En felmod uppstår när beteendet passerar gränsen.
• Orsakerna förklarar varför beteendet avvek.
• Verifieringen kontrollerar orsaken, inte symptomet.

När REALISERING saknas

När beteendet inte finns med i analysen händer tre saker:

1. Felmoderna blir breda och otydliga.
2. Orsakerna blir gissningar.
3. Verifieringen blir dyr och ineffektiv.

Analysen blir långsam, frustrerande och tyngre än den behöver vara. Teamet lägger tid på att diskutera symptom i stället för att förstå systemet. Det här ser jag återkommande i utvecklingsprojekt, och det går helt att undvika.

Iterationen gör analysen skarp

Funktionsnedbrytningen talar om vad systemet måste göra. Realiseringen talar om hur det faktiskt gör det. Utan realiseringen är nedbrytningen bara teori, och teori ger inga skarpa felmoder. När man väver ihop funktion, delfunktioner, realisering och gränssnitt får man en integrerad funktionsbild. Det är där analysen på riktigt börjar.

Många team startar med oklara funktioner, svaga delfunktioner och ofullständig realisering, och då blir allt nedströms gissningar. Botemedlet är iteration. Väldigt ofta är det här man upptäcker att funktionsbeskrivningen saknar grundläggande delar, och det är oerhört värdefullt att upptäcka tidigt. Det är också ett av de mest värdefulla resultaten av en bra FMEA: den avslöjar krav som saknas.

När funktion, delfunktioner och realisering förfinas tillsammans förändras analysen helt:

• Felmoderna blir objektiva.
• Effekterna blir korrekta.
• Orsakerna blir realistiska.
• Verifieringen blir riktad och kostnadseffektiv.

Det är i det ögonblicket FMEA slutar vara en workshop och blir ingenjörsarbete.

Vill ni ha hjälp att få den kedjan på plats i era analyser? Läs mer om facilitering av FMEA, eller boka ett samtal.