PRODUKTUDVIKLING I EN MEDICO-VERDEN

Transkript

1 TEK notat AGIL PRODUKTUDVIKLING I EN MEDICO-VERDEN Når det er en fordel at kunne lave løbende tilpasninger og blive klogere i hele forløbet fra behov til produkt TN5 December 2013 We help ideas meet the real world / MADEBYDELTA.COM

2 Indholdsfortegnelse Indholdsfortegnelse Resumé... 3 Baggrund Fra idé til marked Front-end innovation Kommercielle forhold Identifikation af brugerbehov Markedsmuligheder Variable omkostninger forventet salgspris Klinisk dokumentation Produktkoncept Dokumentation Regulatorisk Produktudvikling At være agil i medicoudvikling Agil produktudvikling tilfører yderligere fokus på værdiskabelse og risikostyring Fokus på kunder, brugere og andre interessenter er en nøgleværdi Hurtig værdiskabelse kræver optimerede værktøjer, processer og kompetente deltagere Kravstyring Styring, modularisering og arkitektur Dokumentation Kvalitetssikring Risikostyring Konfigurationsstyring Hurtig og løbende risikoafdækning sikrer værdien Alt skal ikke med i første omgang Agil medico kræver disciplin Konklusion

3 Resumé DELTA har igennem mange år arbejdet for medico-virksomheder med udvikling og test af Mechatronic produkter. En kombination af virksomhedernes ønske om at forkorte produktudviklingstiden, samtidig med at myndighederne skærper godkendelseskrav, har rettet DELTA s fokus mod at undersøge mulighederne for agil udvikling af medico-produkter. I det følgende beskrives, hvordan man kan opnå agilitet i udviklingsforløbet. DELTA har I længere tid arbejdet med udvikling og godkendelse af medicinsk udstyr. Udstyr med megen forskellig grad af kompleksitet og i en kombination af mekanik, software og hardware. Indenfor software-udvikling har der gennem mange år været arbejdet agilt i udviklingsforløbet. Fordelene ved at arbejde agilt i udviklingsforløbet er muligheden for løbende at kunne tilpasse sig markedsbehovet i takt med, at projektet udvikler sig og samtidig reducere produktudviklings-tiden. forhold, der har indflydelse på projektet teknologi, koncept, regulatorisk, klinisk, kommercielt, patenter etc.- og deres indbyrdes afhængighed. Når dette overblik er tilvejebragt, har man den nødvendige indsigt til at kunne udarbejde en præcis kravspecifikation (Design Input) og en projekt-risikovurdering. Agiliteten ligger således i stort omfang i at udnytte friheden til at arbejde i den tidlige idéfase indenfor de vigtigste forhold, optimere forholdene og skabe grundlag for et sikkert produkt. Samtidig har man mulighed for at skabe grundlag for et attraktivt kommercielt udgangspunkt. Det er brugerkrav og de markedsmæssige krav til projektet, der er retningsgivende for hvor agilt den efterfølgende produktudviklingsproces skal være. Det vil således give stor værdi i produktudviklingsforløbet at arbejde agilt, da der åbnes op for højere grad af opfyldelse af brugerbehov samt kortere udviklingstid. Mål at reducere forbrug af tid og ressourcer fra ide til marked med 10% for SMV ere. En af udfordringerne med agilitet indenfor udvikling af medicinsk udstyr, er de skarpe krav til dokumentation og styring af udviklingsprocessen. Formålet er at sikre en høj produktkvalitet og herigennem reducere patientrisikoen. Agilitet i udviklingsforløbet indenfor dette område kræver derfor en effektiv styring af ændringer gennemført i produktudviklingsforløbet. En omhyggelig konfigurationsstyring er nødvendig for at kunne validere det udviklede produkts egenskaber i forhold til brugerbehov og tiltænkt anvendelse. TEK notatet gennemgår de vigtigste forhold, der skal have fokus, når der ønskes en agil tilgang i udvikling af medicinsk udstyr. Grundlæggende bør så mange forhold som muligt afklares i den meget tidlige idéfase. Som arbejdet med konceptudviklingen udvikler sig, detaljeres så mange forhold som muligt, i takt med at vidensniveauet bliver større. Resultatet af at arbejde målrettet og intensivt i den tidlige idéfase er at få skabt overblik over de forskellige 3

4 Baggrund Det er alment kendt, at udvikling af medicinsk udstyr stiller store krav til produktudviklingsprocessen. Baggrunden er, at medicinsk udstyr anvendes på patienter og af patienter, og at fejl i de mest kritiske produkter kan være livstruende. Derfor stilles der krav om at udvikle produkter med så lille fejlrisiko for patienten som muligt. Medicinsk udstyr opdeles i forskellige risikoklasser, afhængigt af hvor stor en risiko patienten udsættes for. Udstyrets risikoklasse bestemmes ud fra, hvad det er for et udstyr, hvor det anvendes på/i patienten, og i hvor lang tid det anvendes....overblik over alle de væsentlige krav til projektet og skaber grundlag for en agil tilgang i produktudviklingsfasen, samtidig med at grundlaget for en effektiv gennemførelse af produktudviklingsforløbet bevares De lovgivningsmæssige krav til udvikling af medicinsk udstyr er omfattende og opfattes således ofte som barriere for hurtigt at kunne udvikle nye produkter til markedet. Årsagen hertil kan ofte findes i manglende overblik og fokus, samt en ufuldstændig afklaring af de mange forskellige forhold der danner grundlag for et effektivt produktudviklingsforløb. form af kompetencer og i form af nødvendig kapacitet til at arbejde detaljeret. Der skal arbejdes målrettet med alle de områder, der har indflydelse på det færdige produkt grundlaget for at projektet kan gennemføres med succes. Et projekt har succes, når der opnås høj opfyldelsesgrad af det identificerede brugerbehov, når målene i businesscasen opfyldes, og projektet gennemføres til den aftalte tid. Den teknologiske udvikling går hurtigt, de identificerede brugerbehov kan ændre sig, kliniske erfaringer fra konkurrenter kan gøre det nødvendigt at justere på projektet og konkurrencesituationen kan ændre sig. Alle sammen faktorer der øger behovet for at kunne tilpasse projektet undervejs. Dette TEK notat omhandler således metoder til, hvordan man ved at afdække en række forskellige forhold i de tidlige faser får overblik over alle de væsentlige krav til projektet og skaber grundlag for en agil tilgang i produktudviklingsfasen, samtidig med at grundlaget for en effektiv gennemførelse af produktudviklingsforløbet bevares. Med løbende fokus på de markedsmæssige krav besluttes bevidst, hvor stor agilitet der er behov for i produktudviklingsforløbet. Nye features og varianter vurderes i forhold til det kommercielle potentiale og indflydelse på projektets fremdrift. En række input gemmes til næste generation af produktet og skaber mulighed for løbende fornyelse på markedet. Allerede i den tidlige idé og konceptudviklingsfase, har man mulighed for at skabe grundlaget for, at den efterfølgende produktudvikling kan gennemføres effektivt, og opfylde de identificerede brugerbehov uden mange uforudsete opgaver. For at få succes med projektet er det derfor vigtigt, at der tidligt i forløbet tildeles de nødvendige ressourcer til projektet, både i 4

5 Platform Version 3 Version 2 Version 1 Range Care Range Care Range Care Time Figur 1. Agil produktudvikling åbner mulighed for at komme hurtigt på markedet med første version af produktet. Nye features og varianter vurderes i forhold til det kommercielle potentiale og indflydelse på projektets fremdrift time-to-market. En række input gemmes til næste generation af produktet og skaber mulighed for løbende fornyelse på markedet i form af Range Care versioner. 5

6 1 Fra idé til marked DELTA ønsker at belyse mulighederne for at bryde med den gængse opfattelse af sekventielle forløb i forbindelse med produktudvikling af medicinsk udstyr, og i stedet undersøge hvor agilt man kan arbejde i processen fra idé til marked naturligvis under stadig hensyn til overholdelse af de regulatoriske krav. Indenfor udvikling af medico-produkter er det nødvendigt med en opdeling i nogle hovedfaser, der hver er karakteriseret ved forskellige forretningsprocesser for at kunne opfylde de regulatoriske krav. Livscyklus for et medicinsk udstyr kan ud fra de regulatoriske krav hensigtsmæssigt opdeles i fire hovedfaser: Kommercialisering Efter produktet er taget af markedet Man skal være yderst bevidst om, hvilken fase man befinder sig i med sit projekt, idet dokumentationskravene er meget forskellige i de fire faser. Krav, som i alle faser har til formål at fokusere på patientsikkerheden. I det følgende vil vi koncentrere os om de to første faser fra ideen opstår i front-end innovation fasen til produktet er klar til godkendelse af myndighederne Produktudvikling og salg kan starte. Front-end innovation Produktudvikling Front End Innovation Product Development Commercialisation Idea Gate Product Development Stage Gate Review Process Gate Sales Risk Analysis Risk Evaluation Risk Control Overall Residual Risk Evaluation Post Marketing Information Design Control Requirements User Needs Design Input Design Process Design Output Medical Devices Verification 1. Design Requirements 2. Documentation Requirements 3. Regulatory Requirements 4. Pre-clinical Requirements Validation 1. User Needs 2. Intended Use 3. Clinical Safety and Performance Figur 2 giver et overblik over hovedprocesserne I forbindelse med udvikling af et produkt fra idé til produktet er klar til lancering, og salg kan påbegyndes. 6

7 7

8 1.1 Front-end innovation Ideen til et nyt produkt kan initieres af et konkret behov i markedet, en ny klinisk procedure, en teknologisk mulighed, en konceptidé, en åbning i patentlandskabet eller ændrede regulatoriske forhold. Uanset hvor ideen opstår, er det af stor betydning, at alle forhold omkring produktet undersøges omhyggeligt, og deres indbyrdes afhængighed vurderes i forhold til patientrisikoen. Ideen skal ligeledes bidrage til en business case, hvis indhold passer ind i virksomhedens strategi. Det er derfor af stor betydning for projektets succes, at der allokeres kvalificerede personer til projektet. Personer der besidder de nødvendige faglige kompetencer til at kunne tilvejebringe en solidt grundlag for projektet (se figur 3). Et grundigt forarbejde inkluderer et dokumenteret proof of concept og omfatter en projektstrategi, en kommerciel strategi og en produktstrategi, samt et solidt regulatorisk overblik beskrevet i en regulatorisk strategi - inklusiv en klinisk dokumentationsplan. Med et grundigt forarbejde er der skabt grundlag for at kunne udarbejde en detaljeret kravspecifikation (Design Input). Agilitet i denne fase af projektet er en helt naturlig del og er ukompliceret i forhold til overholdelse af de regulatoriske krav. De vigtigste regulatoriske krav, der skal overholdes, er dokumentation for at konceptvalg er foretaget ud fra et afvejning af patientrisiko i forhold til behandlingseffekt. Det vil sige, at der skal gennemføres et risk management assessment, der bl.a. dokumenterer en systematisk mitigation af risk-faktorer for at skabe et sikkert produkt. Dokumentationskravene i denne fase er helt afhængig af, hvilken klassifikation produktet hører ind under, og i hvilke markeder man ønsker at få godkendt produktet til salg. IPR Freedom to Operate Adequate Inventiveness/ novelty Commercial User Need Market Potential Market Penetration Business Case Product Concept Intended Use Claims Unique Selling Points Reimbursement Cost in Use Quality of Life Idea Product Technology Materials Processes Regulatory Regulatory Strategy Produc Risk Launch Plan Registration Priority Approval Provess Clinical Publications Clinical Evaluation Litteratur Study Clinical Trial Risk Management Patient & Project Figur 3. I den tidlige idéfase arbejdes der bredt indenfor ovenstående områder og deres indbyrdes afhængighed afklares. Der etableres proof-of-concept. 8

9 1.1.1 Kommercielle forhold I den tidlige idéfase er der åbne muligheder for at arbejde med de forhold, der kan vise sig at have afgørende betydning for at skabe en god forretning med et nye produkt. I den tidlige fase udvikles forretningsplanen, som består af mange forskellige input. Nogle af de vigtigste områder, der kræver afklaring er Identifikation af brugerbehov Identifikation af markeder Mål for salgspris og variable omkostninger Investeringsbehov Identifikation af brugerbehov Mange virksomheder påstår, at de er behovs-/markedsdrevne og ser ikke de store udfordringer i at afklare brugerbehov. Analyserer man nærmere, viser det sig ofte, at de er teknologidrevne og ikke er så tæt på brugeren som antaget. Udviklingen er ofte drevet af få kreative medarbejdere med stort kendskab til forretningsområdet og med stor kompetence indenfor konceptudvikling. Indenfor medico-produktudvikling er det af stor betydning tidligt at få afdækket og beskrevet brugerbehovet præcist, således at Intended Use og Claims kan formuleres, og de parametre der har indflydelse på den efterfølgende dokumentation kan defineres. Det er de første initiativer i projektet, som ender med at danne grundlag for godkendelse og registrering hos myndighederne, når produktet er klar til salg. For at være sikker på, at det valgte produktkoncept opfylder brugerbehovet bedst muligt, gennemføres aktiviteter der har til formål at forstå brugssituationen og dermed klarlægge brugerens behov. Aktiviteterne danner grundlaget for input til den efterfølgende proces omkring idegenerering og udvikling af produktet. I processen involveres interessenter i form af brugere, klinikere og specialister indenfor området, og der anvendes brugercentreret design og antropologiske metoder til systematisk at identificere brugerbehovet. Brugervenlighed (Usability) er en væsentlig myndighedsbestemt faktor, der skal tages hensyn til kravene er at produktet er let at anvende, og at risikoen for fejlanvendelse er så lav så muligt Markedsmuligheder Valg af markeder og lanceringsrækkefølge skal foretages tidligt - de forskellige regulatoriske krav og forskellige reimbursement-regler kan have stor indflydelse på, hvor god en business case der kan opstilles. Er de valgte markeder allerede penetreret eller bliver man first mover og lancerer man et produkt til anvendelse i en ny behandlingsmetode. Som first mover skal der budgetteres med væsentlig større omkostninger til klinisk dokumentation og markedsføring, og konsekvensen er ofte længere time-to-market Variable omkostninger forventet salgspris Valg af koncepter og teknologi har stor indflydelse på de variable materiale- og lønomkostninger. Overblik over hvad forskellige features kan have af indflydelse på salgsprisen danner grundlag for, hvilket koncept der vælges Klinisk dokumentation Der stilles krav til klinisk dokumentation for at sikre Safety & Efficacy - mulighederne for at anvende den kliniske dokumentation i kommercielle sammenhæng må ikke forspildes. Med fordel kan man overveje, hvilke kliniske data der skal anvendes overfor beslutningstagerne, brugere og konkurrenter, og hvordan de præsenteres. Gennemføres der kliniske studier med produktet er det derfor af stor betydning, at protokollen bliver skrevet, så resultaterne kan anvendes til at understøtte salg og markedsføring af produktet Produktkoncept Med baggrund i det afdækkede brugerbehov gennemføres der en fokuseret idegenereringsproces indenfor rammerne af det bestående produktkoncept. Resultatet er en løsning tilpasset brugerbehovet. Der arbejdes på workshoppen med at finde den bedste løsning klinisk, teknisk og kommercielt - og samtidig opstilles der afgrænsninger for, hvad der er muligt at implementere af features i produktet under hensyntagen til tid til markedet og hvad der kommercielt er brug for. Materialer og processer fastlægges, og arbejdet dokumenteres i form af en Produktspecifikation (Design Input) Dokumentation For at kunne registrere produktet og starte salg af produktet med et CE-mærke, skal de forskellige aktiviteter i udviklingsforløbet dokumenteres. Alle relevante informationer som materialespecifikationer, verifikationstestrapporter, tegninger, styklister, produktionsgrundlag etc. samles i en Design History File (DHF), som efter produktet er overført til produktion/salg afløses af en 9

10 Device Master Record (DMR). DMR en er en dynamisk fil, der løbende skal opdateres i produktets levetid og i en periode efter produktet er taget af markedet. Foranalysen indeholder arbejdet med at opstille den overordnede plan for indholdet i DHF en Regulatorisk Fra den tidlige konceptfase skal der tages hensyn til de regulatoriske krav. I foranalysen skal der skabes overblik over, hvilke krav der stilles fra myndighederne på de respektive markeder, hvor produktet er planlagt lanceret. Overblikket danner grundlag for, at der tidligt i produktudviklingsfasen kan udarbejdes en regulatorisk strategiplan, som giver overblik over krav til verifikationstest, der skal gennemføres under produktudvikling samt validering af Design Input i forhold til Design Output. Herudover kortlægges de initiativer, der skal igangsættes overfor myndighederne. 1.2 Produktudvikling Forarbejdet i front-end innovation fasen afsluttes med en anbefaling til at gå videre med udvikling af produktet. Anbefalingen tager udgangspunkt i resultaterne af de forundersøgelser, der er gennemført i en projektrisikoanalyse og i den udarbejdede kravspecifikation. Kravspecifikationen anvendes i udviklingsprocessen til at gennemføre verifikationstest af de opstillede forventninger til produktets ydeevne (Claims). Verifikationsprocessen opfattes for det meste som en sekventiel proces, hvor det ikke er muligt at gå tilbage i forløbet. Det vil vi gerne gøre op med, ved at foreslå en mere agil proces. En iterativ tilgang til gennemførelse af projektet, som giver muligheder for løbende at kunne tilpasse sig ændrede krav fra fx konkurrenter, ændrede brugermønster o.lign. Det kan kun lade sig gøre, hvis der er skabt et præcist og godt overblik over projektet, og at der indføres et konfigurationsstyringssystem, der kan sikre overholdelse af de regulatoriske krav. Product Development Product Development Stage Gate Review Process Risk Evaluation Risk Control Overall Residual Risk Evaluation Design Control Requirements Design Input Design Process Design Output Verification 1. Design Requirements 2. Documentation Requirements 3. Regulatory Requirements 4. Pre-clinical Requirements Validation 1. User Needs 2. Intended Use 3. Clinical Safety and Performance Figur 4. I produktudviklingsfasen arbejdes der under Design Control Requirement. Verifikationsprocessen opfattes for det meste som en sekventiel proces, hvor det ikke er muligt at gå tilbage i forløbet. Det vil vi gerne gøre op med, ved at foreslå en mere agil proces. 10

11 2 At være agil i medicoudvikling I regulatorisk sammenhæng reagerer mange umiddelbart ved at sige, at denne overskrift kan ses som en selvmodsigelse! Og lad det være sagt med det samme agil medico-udvikling er IKKE en genvej til godkendelse og det er IKKE et udtryk for, at de regulatoriske krav kan tilsidesættes! Det er også kun i få sammenhænge, produktopdateringer vil kunne markedsføres hver måned! Når det er sagt, så er der en række værdier, principper og metoder i den agile tilgang til udvikling, der giver rigtig meget mening og kan tilføre meget værdi i udvikling under regulatoriske krav. Der er i praksis ofte muligheder for at komme hurtigere på markedet og reducere risici i projekter, samtidig med at produktrisiko er enten den samme eller mindre end i mere traditionelle udviklingsforløb. Allerede i de første eksperimenter med Scrum, udført af Ken Schwaber og Jeff Sutherland i midten af 1990 erne, var udvikling af komplekse produkter i medicinsk sammenhæng en del dog ikke regulatorisk. I en virksomhed, der hed IDX Systems (i dag GE Healthcare) 1, blev Scrum indført og modnet. Det er derfor tidligt i udviklingen af dette rammeværk dokumenteret, at det kan give mening i kompleks sammenhæng og siden har det også været anvendt i regulatorisk styret udvikling, bl.a. hos Radiometer i Danmark. 2.1 Agil produktudvikling tilfører yderligere fokus på værdiskabelse og risikostyring At være agil er i sig selv ikke en udviklingsmodel, men et sæt af værdier og principper, man kan lade sin udviklingsmodel påvirke af. Agil er den egenskab, at man er i stand til at tilpasse sig ændrede vilkår. Dertil er der i fx extreme Programming (XP) og andre metoder angivet en række praktikker, der kan vælges anvendt for at understøtte én i at være agil i den kontekst, man arbejder i. Den altoverskyggende sætning i agil udvikling er, at enhver vision, model, strategi, aktivitet, der gennemføres, skal fokusere på optimalt tilpasset værdiskabelse i den konkrete situation. Det Agile Manifest med de 12 tilhørende principper rammer dette ind 2. Her bør fremhæves de principper, som også Department of Defence i USA har udpeget som de vigtigste i håndteringen af komplekse IT projekter 3, der ellers har vist sig at have svært ved at opnå de mål, der er sat for dem: early and continual involvement of the user multiple, rapidly executed increments or releases of capability early, successive prototyping to support an evolutionary approach a modular, open-systems approach I medico-sammenhæng giver dette mening ved at udfordre den tilgang, der tages til at overholde de regulatoriske krav, specielt den sammenhængende dokumentation fra intended use til, at alle risici i brug og udvikling er håndteret tilfredsstillende. Ændringer undervejs i udviklingen kan medføre, at store dele af den verifikation og validering med dokumentation, der kræves, også skal ændres. Det kan være dyrt i både tid og omkostninger. Det ændrer dog ikke ved, at et produkt, der for sent viser sig ikke at kunne indfri forventningerne, er endnu dyrere at redde! Opgaven kommer til at bestå i at finde den rette balance og konstant udfordre, hvor sent et givet krav kan låses, og hvor tæt man kan komme på reel anvendelse i markedet med én funktionalitet ad gangen. Regulatorisk kræver myndighederne, at der i udstrakt grad involveres brugere, herunder at der tidligt bruges prototyper til at afdække behov og risici. Der er dog krav om, at involveringen skal ske med den version af produktet, som tænkes markedsført, for at det understøtter godkendelsen. 1 Iflg. Jeff Sutherland & Ken Schwaber: The Scrum Guide, October SEI Special Report CMU/SEI-2011-SR-015: A Summary of Considerations for DoD Program Managers 11

12 At der afdækkes risici tidligt gennem flere releases og markedsføring af afgrænsede funktioner de første gange gør også risikobilledet nemmer at overskue også for myndighederne. Udfordringen er at kunne tilføje og ændre funktionalitet uden at dokumentere ALT forfra. Her vil der være behov for sporbarhed af afhængigheder/sammenhænge i produktet. Modularitet og gennemskuelighed i både udviklingsmiljø og -produkt, så det er forberedt til at håndtere udvidelser og ændringer, vil understøtte både at skabe et optimalt produkt og at kunne opnå de nødvendige godkendelser. 2.2 Fokus på kunder, brugere og andre interessenter er en nøgleværdi I det agile manifest er én af sætningerne: Customer collaboration over contract negotiation 4. Igen er det den hurtige feedback-loop fra dem, der sidder med den endelige beslutning, som er i fokus. Forskellige agilt baserede metoder, som Scrum og XP, angiver forskellige praktikker til at løse denne udfordring. Fælles er dog, at kunde og brugers faktiske behov skal være tydelige hos det team, der skal udvikle resultatet. Herunder at der er adgang til løbende at afklare detaljer, når de dukker op i forløbet. Dette er grunden til, at der i agil udvikling lægges mere vægt på kommunikation end aftale! Dette udfordrer på den ene side den regulatoriske tilgang om, at krav skal være aftalt og låst inden udviklingen starter, så grundlaget for risikoafdækning og styring er stabilt og sammenhængende. På den anden side understøtter det fuldt ud, at brugssituationen skal være afdækket. Ved at arbejde ud fra de agile tankegange og metoder vil det være sikret, at der ikke kun er lavet en interessentanalyse, men at interessenterne har en effektiv måde at arbejde sammen med teamet på, og at teamet reelt efterspørger dialogen! 2.3 Hurtig værdiskabelse kræver optimerede værktøjer, processer og kompetente deltagere En væsentlig faktor for at skabe værdi er at komme hurtigt på markedet, hvor kunderne begynder at betale for resultatet af udviklingen. Det udfordrer den tid, det tager at komme igennem både udvikling og godkendelse, men kan understøttes gennem et detaljeret og godt beskrevet Design Input, optimalt samspil mellem kompetente medarbejdere, optimale processer og automatisering af tidskrævende manuelle opgaver. Det er fx vist, at en kompetent udvikler, der har både viden, færdigheder og har lov til at tage nødvendige beslutninger, kan være mere end 10 gange hurtigere end én, der mangler viden eller skal afvente beslutninger. Derfor kan det agile fokus på at sikre optimale vilkår og beslutningskompetence på operationelt niveau gøre en stor forskel mht. reel fremdrift. En agil tilgang kan støtte medarbejdere i at udnytte deres tid optimalt. Kommunikation, feedback-loops og styring bliver sat i system via en række ritualer, der er meget optimeret til at støtte mennesker i den praktiske hverdag. Scrum modellen er fx alene en fremgangsmåde for at håndtere daglig operationel styring af opgaver. Kanban supplerer med at sikre flow et er optimalt ved at synliggøre work in progress og optimal daglig prioritering. Dette understøtter medarbejdere i at agere agilt, men siger fx intet om, hvordan man udvikler hardware eller software. Denne faglighed skal medarbejderen tilføre gennem sine faglige kompetencer. Ligeledes er nok så mange ritualer og metoder ikke bedre end de personer, der udfører rollerne. Det agile manifest har ét af de 12 principper, der hedder Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Hvis det ikke lykkes at motivere medarbejderne til at ville leve op til fx regulatoriske krav, kan metoden synliggøre, at det er tilfældet men det er stadig den rette ledelse, der skal sikre, at det håndteres. Det er herunder et vigtigt agilt princip, at teamet tilsammen har alle de kompetencer, der er nødvendige for at kunne løse opgaven, hvilket ledelsen også skal give stor opmærksomhed for at få succes med en agil tilgang. På samme måde som beslutningsdygtige medarbejdere og understøttende processer hjælper til hurtige feedback-loops, er det vigtigt at automatisere ting som kravstyring, konfigurationsstyring (herunder fastholdelse af sporbarhed mellem krav og test, samt hvilke produkt- og dokumentationsfiler, der indgår i en given konfiguration), testafvikling og enhver anden proces,

13 der forhindrer at kunne arbejde effektivt sammen og kunne nå releases hurtigt. Det er indbygget i et agilt mindset, at man løbende forsøger at identificere spild, der kan optimeres væk! Det vil naturligvis altid være en vurdering, hvornår en investering i tid og omkostninger til at købe og implementere værktøjer til automatisering giver mening! Nogle gange er en tavle stadig mere effektiv! Ligeledes skal det understreges, at værktøjer også i denne sammenhæng kun er en hjælp. Den engelske sætning gælder stadig: A fool with a tool is still a fool! Effektiviteten står og falder derfor stadig med kompetente medarbejdere, der forstår, hvad de laver og har færdigheder i at anvende værktøjerne optimalt til de opgaver, de sidder med. Bemærk også, at i forbindelse med agil udvikling, er høj kvalitet konstant i fokus, da teknisk gæld vil forhindre hurtige releases og binde ressourcer til fejlrettelser. Teknisk gæld vil sige, der er fejl eller uhensigtsmæssigheder gemt i produktet, fx fordi tests ikke er gennemført, eller at koden ikke har været vurderet af en kollega. Denne gæld skal være nedbragt så meget som muligt og som minimum opfylde formelle krav, før opgaven kan meldes done, og resultatet kan blive en del af produktet. Det vil derfor ikke være acceptabelt at springe over aftalt kvalitetssikring for at blive hurtigt færdig. Generelt er begrebet done i agil udvikling en mekanisme, der er stærk, når udviklingen skal understøtte medico-godkendelser. Med done bliver de formelle krav til et helt naturligt element i det enkelte team-medlems opfattelse af opgaven, da de formelle krav er defineret som aktiviteter, der skal være løst før opgaven kan meldes done. Det blive efterspurgt hver eneste dag og synliggjort for kollegerne, når status skal gives på det daglige opgave- og risikostyringsmøde! Derfor er der også et løbende fokus i teamet på at optimere forløbet frem til done. De konkrete steder, der med fordel kan overvejes automatisering, er: 2.4 Kravstyring Kravsudvikling, fx i form af user stories i agile projekter understreger, at værktøjer kan være en forhindring for en optimal dialog, og derfor er papirlapper stadig at foretrække. Kommunikationen om krav skal selvfølgelig også gives den rigtige opmærksomhed i medico-udvikling og værktøjerne må heller ikke hér blive en forhindring. Flere steder løser man dette ved at starte på papir og siden overføre til værktøjer, når det er afklaret, hvad kravene er, og hvilke der er de højst prioriterede. I regulatorisk sammenhæng er der bl.a. krav til dokumentation af gældende produktkrav og styring af deres tilstand. Der findes værktøjer, som kan understøtte, at disse nødvendige informationselementer er på plads, fx om kravet er godkendt og til hvilken brug. Der findes også værkøjer, der understøtter sporbarhed til test og testdokumentation. Automatisering bliver hurtigt en nødvendighed for at kunne arbejde effektivt. Specielt for software, hvor kompleksiteten af krav og deres relationer ofte stiger med en faktor 100 eller mere i forhold til rene mekaniske og elektroniske produkter. 2.5 Styring, modularisering og arkitektur Specielt for softwareudvikling kan modularisering og dermed den samlede arkitektur blive særdeles kompleks, fx med at sikre den konfiguration, man arbejder på, stadig er optimal, og at der fx ikke er indbygget løsninger, der undergraver de afkoblinger, der er forsøgt lavet. Hér vil værktøjer, der både kan understøtte opbygningen af arkitekturen og analysere software hjælpe til at synliggøre tilstanden og effektivisere teamets styring af arkitekturen. 2.6 Dokumentation Der er nogen, der mener, at et agilt team ikke laver dokumentation. Dette beror på en meget forkert tolkning af en sætning i det agile manifest Working software over comprehensive documentation. Sagen er, at dokumentationen selvfølgelig skal have et formål, og hvis den ikke bringer værdi, skal den ikke laves! Ligeledes er det et agilt princip, at man hellere skal få løsningen lavet, testet og releaset end at opbygge bureaukrati, der kræver dokumenter frem for resultater. På sin vis et opgør med V-model som rigid projektstyringsmodel, hvor fx et designdokument opfattes som fremdrift. I en agil tankegang vil kun salgbar funktionalitet være at opfatte som fremdrift, da alt andet er bunden kapital svarende til lager af halvfabrikata. I medico-udvikling er der dog ikke tvivl om, at der er dokumentation, som er en forudsætning for at kunne aflevere produktet. Dermed bliver dokumentationen en del af kriteriet for done. Det bliver også vigtigt at kunne binde dokumentationen sammen med øvrige elementer i en given konfigura- 13

14 tion og dermed, at krævet dokumentationen er under samme konfigurationsstyring som software, hardware og mekanik. Se mere om dette nedenfor. 2.7 Kvalitetssikring At definere kvalitetssikring og styre, hvad der er gennemført og på hvilke versioner, er en ikke helt ukompliceret opgave, der med fordel kan hjælpes på vej af passende værktøjer. Ligeledes kan en proces som review med fordel understøttes af værktøjer, så dokumentationen og styringen af de ting, der identificeres, også er håndteret. Afvikling af tests, hvor det er muligt, vil ligeledes kunne gennemføres mange gange hurtigere allerede anden gang, når det er en del af en automatiseret test. Specielt når der fra starten er planlagt med at skulle lave udvidelser eller varianter, vil dette være den agile måde at udvikle på. Som minimum bør den besluttede regressionstest være så automatiseret som muligt. Der vil naturligvis være forskel på, hvilken kvalitetssikring det giver mening af automatisere. Det vil dog altid være agilt at lave vurderingen, så det er en bevidst og kvalificeret beslutning, der ligger til grund for, hvad der bliver og hvad der ikke bliver automatiseret. 2.8 Risikostyring Risk management er en proces der starter, når ideen opstår og følger produktet i hele dets levetid. Afhængigt af hvilken risikoklasse, produktet befinder sig i, skal man kunne fortsætte sine kvalitetssikringsfiles i en nærmere bestemt årrække for at understøtte eventuelle hændelser med produktet i markedet. I udviklingsforløbet er det vigtigt, at der gennemføres systematisk mitigering af produktets risici, således at der udvikles et produkt med så lav risikoprofil som muligt. Processen dokumenteres løbende. Produktets risk assessment opdateres løbende igennem hele livscyklus for produktet, fra ideen opstår til produktet tages af markedet og en årrække herefter som beskrevet ovenfor. 2.9 Konfigurationsstyring Konfigurationsstyring er sikringen af, at integriteten af projekters arbejdsprodukter vedligeholdes. Hvordan opdager man, at konfigurationsstyringen ikke virker? Man kan ikke finde tilbage til en gammel version af sine krav eller en ældre version af en fil. Man har rettet en fejl og pludselig genopstår den. Man kan ikke finde den kombination af filer, der passer sammen. Det er alt sammen eksempler på uhensigtsmæssigheder, der dukker op, når konfigurationsstyringen ikke er i orden. Uden en ordentlig konfigurationsstyring, kan man ikke opretholde den sporing, som er nødvendig at opretholde i udviklingen af medicinsk udstyr, hvis det både skal være af tilstrækkelig høj kvalitet og kunne godkendes af myndighederne. Konfigurationsstyring er særligt vigtigt i medico-projekter fordi, der er så høje krav til kvalitet der stilles bl.a. krav fra myndighederne om sporbarhed. Konfigurationsstyring er særlig vigtig i et agilt projekt, fordi der sker så hyppige ændringer. Når integriteten af arbejdsprodukter (der er sat under konfigurationsstyring) skal sikres, indgår forskellige elementer. Hvert arbejdsprodukt skal have en entydig identifikation, og opbevares så de atter kan tilgås. Det kan ske på to principielt forskellige måder: enten kan arbejdsproduktet udlånes eller kopieres. Hvis arbejdsproduktet er et fysisk objekt, som fx printkort, værktøj eller en computer, så er udlån den måde, man skal tænke på det kan tilgås, mens hvis det er i form af data (dokumenter, kildetekster eller krav) så giver ordet kopiere det bedste billede. Under alle omstændigheder er et bibliotek en god metafor for en del af konfigurationsstyringen: Når et bibliotek modtager en bog får den en entydig identifikation. Selv hvis biblioteket har to eksemplarer af den samme titel, vil hvert eksemplar have hvert sit ID. Når en bog først er indført, kan man altid låne den den tages (i princippet) aldrig ud af biblioteket. Når man ændrer en fil eller et krav, der er sat under konfigurationsstyring gemmer man i virkeligheden den nye version uden at slette den gamle version. Sporbarhed er også et nøglebegreb indenfor konfigurationsstyring. Sporbarhed er det fænomen, at man kan holde styr på relationer mellem konfigurationselementer, fx hvilket kundekrav er årsagen til, at vi har dette systemkrav? Hvilke systemkrav kommer der fra dette kundekrav? Eller hvordan er denne sikkerhedsrisiko håndteret gennem hvilket safety-krav? Hvordan er dette krav testet? Sporbarheden giver svar på rigtig mange spørgsmål, der er af vital betydning for kvaliteten og sikkerheden af produktet. Et sidste element i konfigurationsstyring, der skal nævnes her, er ændringshåndtering af fx krav. Uanset 14

15 hvordan man finder frem til kravene, som et system skal leve op til, vil der ske ændringer og hvordan ved man, hvad der lige nu er kravene? Er der forslag til at ændre kravene, er der nogle forhold der skal overholdes. Ændringsforslag skal styres i et Engineering Change Control system. En gruppe kompetente personer undersøger konsekvenserne ved at ændre et eller flere krav. Man skal sikre, at kravene er aftalt mellem de forskellige interessenter og at det er formuleret, så det kan forstås, og først når en godkendelse af et krav foreligger, er det blevet til et nyt (eller opdateret) krav. I et agilt medico-miljø er det i praksis umuligt at gennemføre konfigurationsstyring uden brugen af gode værktøjer til versionsstyring og dokumenthåndtering. Det er meget vigtigt, at man kan udpege en konfiguration (en samling af arbejdsprodukter, der hører sammen) så man fx senere kan se, om en given ændring er foretaget på en måde, så sikkerheden opretholdes Hurtig og løbende risikoafdækning sikrer værdien Agil drejer sig som sagt om at få så meget værdi så hurtigt som muligt ud fra den samme tankegang, der er i Lean om, at bunden kapital er spild. Ét meget vigtigt element i dette er hurtig risikoafdækning. Dette er også i tråd med tankegangen i Lean Start-up, hvor et grundlæggende princip er at skaffe kunde-feedback så tidligt som muligt. Dette kan være vha. simple protyper til brugerafprøvning, men det kan også være en undersøgelse af hele kæden fra behovet opstår over indkøb (forretningsmodellen), anvendelse og opmagasinering til endelig bortskaffelse. Vil produktet have en berettigelse hos de, der forventes at betale? I de indledende faser vil det være oplagt at arbejde i iterationer, hvor produktet og forretningsmodellen modnes mere og mere med tilhørende foreløbig validering. Flere og flere perspektiver undersøges, som beskrevet i afsnittet Front-end innovation. Heri ligger også at droppe tanken, hvis teknologien eller forretningsmodellen ikke holder helst så tidligt og med så få investeringer som muligt! Agile metoder vil i denne periode hjælpe med, at der holdes fokus og sikres fremdrift vha. kompetente og fokuserede teams, løbende prioritering fra de forretningsansvarlige og sikring af feedback fra brugerne. På et tidspunkt vil der være et tilstrækkeligt grundlag for at kunne sætte den sidste del af konstruktionsarbejdet i gang, som skal danne grundlag for den store, langsomme og dyre proces mod endelig godkendelse. Hér vil udviklingen overgå til inkrementel udvikling af funktionalitet og den tilhørende verifikation og validering. Agile metoder vil sikre stærkt fokus på hele leverancer, som kan understøtte godkendelse med trinvis risikoafdækning af udviklingen, ved at hvert inkrement kommer så tæt på endelig godkendelse og anvendelse som praktisk muligt. Forretningen beholder fuld kontrol over forløbet ved, at der er synlighed over hvilke funktionaliteter, der er påbegyndt og færdiggjort. Ikke påbegyndte funktionaliteter kan til enhver tid vælges til eller fra, hvis det fx viser sig, at markedsforventningerne ændrer sig. Sidst i forløbet vil der være en række hardening sprints, hvor der er lukket for at tilføre funktionalitet og der alene gennemføres de sidste tests, og hvor det sikres, at pakken til godkendelse bliver klar Alt skal ikke med i første omgang Der kan være en tendens til at ville have så meget med som muligt, når nu det er så svært og dyrt at få godkendelsen. At være agil udfordrer denne praksis. Al erfaring siger, der kommer væsentlige erfaringer, hver gang man tager næste skridt på vej til markedet og daglig brug. Derfor er det et agilt princip, at man hurtigst muligt skal komme på markedet og indsamle den læring! Så korte feedback-loops som muligt! En mulighed kan være, at man starter med tiltænkt anvendelse til fitness, som ikke kræver godkendelse i henhold til medico-direktivet. Så kunne første udgave alene have dette formål med et sæt claims. Når der er skabt noget erfaringer med produktet, og der evt. er indført nogle tilpasninger, kan næste skridt fx være intended use til behandling af en indikation og dermed et medicinsk brug. En begrænset lancering på et enkelt marked kan give megen information om kommunikationsplatformen for produktet. Eventuelle justeringer kan let gennemføres, inden produktet rulles ud på flere markeder. Siden kan man udvide claims i takt med, at der udarbejdes dokumentation herfor. Alt sammen forhold det er fornuftigt at have taget stilling til i sin regulatoriske strategi. 15

16 3 Agil medico kræver disciplin I et regulatorisk styret agilt projekt er der lagt op til en høj grad af gennemskuelighed, og det bliver ikke understøttet af personlige usynlige afvigelser, der kan være imod teamets samlede målsætning. Her gælder, at processer skal udføres som aftalt, og at der er formelle strukturer til at evaluere om samarbejdet og den enkeltes indsats fungerer optimalt, fx ved brug af Retrospectives i hver iteration. Hvis der viser sig et potentiale for optimering, skal det være en fælles beslutning at ændre processer, så alle agerer optimalt for teamet og produktet som helhed. Der er dog en stor forskel ift. mere traditionel styring af processer ved, at det forventes, at processer ejes og optimeres af dem, der bruger dem. Hvis det skal fungere optimalt i et regulatorisk miljø, kræver det meget disciplin blandt udviklere og andre involverede i at skabe resultaterne, så der i den sidste ende kan dokumenteres sammenhæng fra Intended Use over risikovurdering til, hvordan de er håndteret i design og udvikling. Agil udvikling skal i høj grad være funderet i høje kompetencer og modenhed hos de involverede personer og i teamet som helhed. Det er synlighed og egenkontrol, der skal drive værket, ikke team-ekstern kontrol. Teamet skal tage det fulde ansvar for at leve op til de forventninger, de har sagt ja til. Det vil derfor være en nøgleudfordring for en organisation, der vælger at køre agilt i forbindelse med udvikling af medico-produkter, at den skal sikre tilstrækkelig uddannelse, erfaring og rette holdning hos medlemmer i de teams der udfører arbejdet. De skal have de regulatoriske krav inde under huden og kunne navigere sikkert i det daglige projektarbejde. I et team med høj disciplin og bevidsthed om hvordan de understøtter regulatorisk godkendelse, vil den krævede kontrol og dokumentation så til gengæld være nemmere at få på plads. 16

17 4 Konklusion Den fornemmeste opgave i forbindelse med udvikling af medico-produkter er at udvikle produkter, der udsætter patienterne for så lille en risiko som muligt, og at de risici som patienterne udsættes for, er afvejet i forhold til de behandlingsmæssige fordele, der opnås. Ved at have en agil tilgang til hele produktets livscyklus - fra ideen til et nyt produkt opstår til produktet lanceres på markedet, og i den efterfølgende Post Marketing Surveillance proces er der skabt mulighed for implementering af løbende forbedringer af produkterne og dermed mere sikre produkter, samtidig med at der er mulighed for at starte et godt grundlag for kommerciel værdi. Agilitet i front-end innovationsfasen er for de fleste en helt naturlig måde at konceptudvikle. En proces med mange iterationer, som er ukompliceret i forhold til overholdelse af de regulatoriske krav. Agil produktudvikling sikrer i denne fase, at det sker med fokus på hurtig fremdrift. I den efterfølgende produktudviklingsfase bliver kravene til dokumentation skærpet. Den detaljerede udvikling af produktet gennemføres, og der udføres verifikationstest for at dokumentere overholdelse af krav beskrevet i dokumentet Design Input. Ændringer i krav kræver en omhyggelig og præcis Engineering Change Control og stor fokus på konfigurationsstyring. Udfordringerne ved at arbejde agilt i denne fase er, at undgå et stort dokumentationsbureaukrati, samtidig med at fordelene med den agile tilgang indfries. Her vil den primære værdi ved agil udvikling være, at der sikres løbende afdækning af projekt risicis gennem en inkrementel tilgang til udviklingen. Når der arbejdes med udvikling af medico-produkter, er det stadig en stor fordel at front loade projekterne, selv om det kan virke som om det er imod principperne i agilitet. Projektstrategien skal tilpasses kompleksiteten af produktet og den respektive risikoklasse. Herved kan der opnås meget store fordele ved at arbejde agilt. Det er nødvendigt at starte en dialog med myndighederne for at etablere en god forståelse af principperne i den agile tilgang. DELTA vil som en del af Resultatkontrakten Agilt produktudviklingscenter for sundheds- og velfærdsteknologi åbne denne dialog med myndighederne. Et væsentligt element i denne dialog er at redegøre for at de regulatoriske krav, og ønsket om at arbejde agilt understøtter bestræbelserne på at skabe mest mulig værdi. Om TEK notat DELTA udgiver regelmæssigt rapporter i TEK notat-serien for at kommunikere den nyeste internationale viden indenfor vores fagområder. Formålet er at understøtte en fremrykning af tidspunktet, hvor nye teknologiske landvindinger giver et forretningsmæssigt afkast til danske virksomheder. Lars Seier-Petersen Senior Consultant Consultancy, Products lsp@delta.dk Kurt Steen Frederichsen Consultant Consultancy, Process ksf@delta.dk 17

18 DELTA Venlighedsvej Hørsholm Denmark Tel cipoc.dk