Sådan bruger du XFMEA som et brainstormingværktøj

Genudgivet af Platon

Abonnenter: 0

Fejltilstand og effektanalyse (FMEA) brainstorm kan lyde som en oxymoron for nogle, men anvendelse af Systems Engineering skræddersyet til den strenge FMEA-proces har afsløret et kraftfuldt tidligt design-inputværktøj, som vi bruger hos StarFish Medical. Læs videre for at lære, hvordan du også kan få det til at fungere for dig!

Failure Mode and Effects Analysis (FMEA) har oprindelse i det amerikanske militær fra 1960'erne og blev udviklet til at identificere potentielle fejltilstande i militære systemer og prioritere, hvad og hvordan de skal løses. I årenes løb har variationer af FMEA udviklet sig til forskellige formål og blevet vedtaget af adskillige industrier. I dag kan du finde litteratur om Functional FMEA, Design FMEA, Process FMEA og andre. Med væksten i variationer af FMEA blev xFMEA akronymet vedtaget (f.eks. DFMEA for Design FMEA).

Konceptet xFMEA tegner et billede af en meget struktureret, systematisk og stringent teknik i modstrid med lean design og udviklingsprogrammer. Men ved at reducere procestrinene og tydeligt skitsere et alternativt værdiforslag, kan rammen for xFMEA bruges til hurtigt at identificere adskillige risici og generere designideer under produktdefinitionsfasen af et medicinsk udstyrsprogram. Dette giver et startskud for patientrisikostyringsindhold og teknisk projektrisikoidentifikation for at hjælpe med at reducere sandsynligheden for senfasedesigngentagelser, der stammer fra uforudsete risici.

En typisk xFMEA starter med at identificere en liste over input-elementer: funktioner, use cases, designfunktioner, procestrin osv. De næste trin er at identificere potentielle fejltilstande, de tilknyttede virkninger, årsag(erne) og evnen til at opdage fejltilstande, der fører til skade. Når det først er scoret, hjælper risikoprioritetsnummeret med at finde ud af, hvor der skal fokuseres på idéer om designreduktion og implementering.

For at konvertere denne proces til et brainstormværktøj har du brug for et par af de samme ingredienser, og nogle få fra åben brainstorming. xFMEA-brainstorm-processen starter med et sæt input-elementer og en række fejltilstand-brainstorm-prompter. Det fjerner alle scoringer og kulminerer i en tabel over effekter, kategoriserede risici og en liste over potentielle ideer til at løse identificerede problemer i designet. Nedenstående figur illustrerer procesflowet for Functional FMEA Brainstorming som implementeret hos StarFish Medical. For at bruge den samme ramme til brug eller design af FMEA-brainstorming er der kun brug for et andet sæt input (f.eks. Use Case-trin) og nogle skræddersyede prompter.

For at udføre xFMEA-brainstorming skal du liste inputtet (f.eks. funktioner) og derefter overveje fejltilstande ved at kombinere de forskellige prompter med hver inputsætning. For eksempel, hvis funktionen er at levere strøm: Overstrøm, Understrøm, Ingen strøm, Intermitterende strøm osv. bør begynde at generere visioner om fejltilstande og tilhørende effekter i sindet (strømstød, dødt batteri, sprunget sikring, brun ud). Nøglen er at nærme sig aktiviteten med en ubegrænset tankegang og ikke bruge for lang tid på én ting. Lad tankerne vandre for at bruge fejl, pålidelighedsproblemer osv. ud over indledende fejltilstande og tilknyttede effekter genereret fra inputelementet og prompten. Målet er bredden af dækningen uhindret af hensyntagen til sværhedsgrad eller sandsynlighed for hændelse.

Når der findes en liste over fejltilstande for hvert input, fuldender dokumentering af virkningerne billedet af risikoen. Nogle elementer er muligvis ikke realistisk realiseret, og det er OK. Andre kan være ikke-indlysende åbenbaringer. Idéer at tage fat på kan komme til at tænke på, mens du går; hvis de gør det: skriv dem ned. Generelt finder vi det mest effektivt at arbejde ned hver liste i modsætning til på tværs af linjepost for linjepost. Men hold det løst – denne aktivitet skal også være sjov!

For at hjælpe med at prioritere – og i sidste ende sortere – risiciene, er en vis grad af kategorisering nyttig. Vi valgte en grov sammenlægning af Patient/Operator Skade-relaterede poster og Business Risk-poster. Vi tog fat på patient-/operatørskader først med øje for alt, der kunne påvirke fysisk design. En ekstra ventil eller knap kan have større indflydelse på designindsats i form af omarbejdelse eller backtracking end at tilføje et ikon på en GUI.

Overfør endelig dit gode arbejde til den formelle Risk Management File og Design History File-dokumentation, hvor det er nødvendigt. Vores tilgang er at flytte og kombinere patient-/operatørskader til risikoanalyse for mere grundig scoring og formel afbødning med sporbarhed. Effektive elementer i kategorien Business Risk er fanget i dokumentationen til systemarkitektur eller designbeskrivelse. Tekniske projektrisici flyttes til Projektrisikoregistret. Nogle emner behøver ingen yderligere handling - det er de emner, vi ved, vi vil tage fat på som en del af god ingeniørpraksis. Når det er påkrævet, bring teamet sammen for at generere risikobegrænsende ideer eller planlæg, hvordan man tackler en risiko, og prøv, hvor der skal tages yderligere handling.

Konceptet med xFMEA Brainstorming er mest effektivt i de tidlige udviklingsstadier til at informere designbeskrivelser og beslutninger i modsætning til at evaluere et eksisterende design for, hvad der kunne gå galt. Som designere, jo mere vi forestiller os fremtidige problemer og afbøder dem før detaljeret design, jo tættere vil vi være på et fuldt realiseret design første gang.

Hvordan har Systems Engineering skræddersyet til tekniske processer hjulpet dig med at øge værdien af dine projekter? Vi vil meget gerne høre fra dig!

Billeder: StarFish Medical

Ariana Wilson er en Jr. Systemingeniør i produktudvikling hos StarFish Medical. Hun fik sin Bachelor of Engineering (BEng) grad i Mechanical Engineering fra University of Victoria, hvor sit fjerde år primært består af biomedicinske og væskemekaniske kurser.

Julian Grove er en Sr. Systemingeniør i produktudvikling hos StarFish Medical. Han tog sin Bachelor of Engineering (BEng) grad i Mechanical Engineering fra University of Victoria og brugte flere år på at udvikle mekaniske løsninger til medicinsk udstyr med StarFish, mens han havde øje for det overordnede systemdesign. Julian skiftede officielt til Systems Engineering i 2020 og nyder at anvende Systems Engineering-strategier og skræddersy til at gøre design og udvikling så effektiv og effektiv som muligt.