Kan en riskanalys ge bättre krav?

Kravhantering är ju en central och självklar del av all produkt- och tjänsteutveckling. Gedigna analyser av kundbehov och kundbeteenden är a och o för att kunna kravställa och utveckla rätt produkt som fyller ett behov. Det finns många olika verktyg och metoder för att vaska fram kravbilden. Men i det här inlägget tänkte vi specifikt se lite närmare på riskanalysen som ett sätt att säkerställa kravspecificeringen.

I vissa branscher är kravhanteringen styrd av mer eller mindre tvingande processer. Jag tänker på säkerhetsrelaterade branscher som flygindustri, medicinsk teknik, kärnenergi med flera. Där förväntas organisationen kunna visa upp för myndigheterna dokumenterade analyser av vilka risker som är förknippade med produkten/verksamheten, och på vilket sätt kravställningen anpassats för att ge en acceptabel risk benefit kalkyl för användaren.

Inom medicintekniska branschen används riskhantering för att identifiera alla säkerhetsrelaterade problem med produkten i sin tänkta användningsmiljö. Dessutom går man systematisk igenom på vilket sätt produkten kan gå sönder eller fela under användning, och vilka konsekvenser det kan få för användaren. Korrekt implementerad i verksamheten ska riskanalysen inledas redan på idéstadiet till ny produkt för att kunna påverka kravställningen. Riskanalysen ska följa produkten under hela dess livscykel, från utveckling av design till dess produkten slutligen tas bort från marknaden. För att få sälja produkten måste tillverkaren kunna visa upp dokumentation för myndigheterna som styrker att riskerna är allsidigt belysta och att kravspecifikation utformats för att sänka riskerna ”så långt som är möjligt” (ISO 14971:2012, Annex ZA). Rätt gjord och planerad är analyserna inte bara ett nödvändigt ont, utan ett utmärkt verktyg för att också skapa en bättre produkt. Genom att vrida och vända på idé och sedan prototyp innan något är ”hugget i sten”, öppnar sig möjligheter att designa bort potentiella risker och felkällor redan från början. Analysen kan också hjälpa till att identifiera vilka områden som testningen ska fokusera på för att maximera nyttan av testinsatsen. Den breda nyttan av analysmetodiken gör att riskanalysen som verktyg har spritt sig även till verksamhet som inte har direkt säkerhetsmässig problematik kopplad till produkten. Metodiken fungerar ju utmärkt i tex generellt kvalitetshöjande syfte och varianter kan nu ses i en mängd olika typer av företag.

Ett vanligt verktyg för riskanalyser, med ursprung i flyg- och fordonsindustrin, är den sk FMEA:n (Failure Mode and Effect Analysis). Förenklat kan man se det som ett sätt att tydliggöra händelsekedjan (i) orsak till fel, (ii) inträffat fel och slutligen (iii) konsekvens för användaren. Sannolikheten för att hela händelsekedjan inträffar och allvarligheten av konsekvensen (skadan) används för att utvärdera och ranka riskerna inbördes. Genom att tydliggöra orsaken kan man sedan identifiera åtgärder som minskar sannolikheten eller till och med eliminerar risken att felet uppträder. Man kan också tänka sig åtgärder som lindrar konsekvenserna om felet väl inträffar. FMEA erbjuder alltså ett sätt att systematisk gå igenom produktens funktion och design utifrån ett säkerhets- eller kvalitetsperspektiv. Men verktyget passar utmärkt även för andra frågeställningar, tex.

• Projektplanering – orsaker till projektförseningar eller fördyringar och identifiera motåtgärder
• Kundtillfredställelse - analysera vad som kan orsaka missnöje med produktens utformning eller funktion
• Användarvänlighet – analysera arbetsflöden och produktkrav för att fungera i olika miljöer och sammanhang.
• Tillverkning – identifiera potentiella tillverkningsproblem och implementera åtgärder för att skapa en kostnadseffektiv tillverkning med så liten risk för stillestånd som möjligt

Tyvärr har riskanalysering fått dåligt rykte i många organisationer. En djup suck kan ofta höras från utvecklare när riskanalysen kommer på tal. Jag kan förstå att det blivit så, det är lätt att fastna i en tungrodd överambitiös insats. Ett lämpligt recept för att köra in i väggen är att försöka lösa hela analysen på en gång med alla projektdeltagare samtidigt. Halvdagslånga möten med dussintal berörda utvecklare leder oftast till att man inte hinner så långt och i värsta fall även en dålig analys. Men det finns bättre sätt. Flera men korta fokusmöten runt ett avgränsat område i taget, med bara närmast berörda, kan vara ett sätt. Det ställer krav på den som leder arbetet att koordinera och kunna sätta samman informationen. Vidare kan man som ledare av analysen välja att inte fastna i detaljerna runt varje risk och lösa allt under sittande möte, utan gå vidare utan att tappa tempo och arbetslust. Sedan kan man enskilt eller med sakkunnig komplettera det sista.

Har man i sin projektorganisation gjort riskanalyser har man en god källa att ösa ur för att identifiera och specificera krav. Samtidigt kan man utifrån analysen tydligt dokumentera motiveringen till kravet, något som är väldigt värdefullt den dagen man inte längre minns varför kravet en gång ställdes...

Sammanfattningsvis, riskanalyser kan vara ett effektivt sätt att öka chansen att göra rätt från början och få en bärkraftig kravspecifikation. Genom att verktygen uppmuntrar till systematik och stringens kommer man en bra bit på vägen att ”göra rätt från början”.

/Johan Eckerdal, Require AB