Een gids voor gestroomlijnde en flexibele productontwikkeling van medische hulpmiddelen

Het succes van ontwikkelingsprogramma's in de medische hulpmiddelen- en apparatuurindustrie hangt bijna altijd af van het bereiken van technische mijlpalen die samenvallen met interne of externe fondsenwervingsinspanningen.

Vooral aan het begin van het programma is het van cruciaal belang om technische mijlpalen op een kostenbewuste en tijdige manier te behalen. Dit zal uiteindelijk bepalen of een programma benen heeft of zal worden beëindigd.

Dus, hoe zien deze eerste kritieke mijlpalen eruit? En wat kunnen we doen om deze mijlpalen zo snel mogelijk te bereiken zonder te veel uit te geven? Hieronder geef ik vier overwegingen om lean en agile productontwikkelingsprogramma's uit te voeren.

1. Ontwerp je een sterspeler of een facilitator?

Een van de eerste grote mijlpalen in elk ontwikkelingsprogramma is de creatie van het eerste werkende prototype. Het eigenlijke doel van hands-on testen met vroeg werkende prototypes is het bereiken van technische haalbaarheid (of "Proof of Principle"). Dit is het moment waarop het technische team vol vertrouwen kan zeggen dat de onderliggende technologie voor het productconcept de vereiste prestaties levert.

Om zo snel en kosteneffectief mogelijk een werkend prototype te ontwikkelen, is de eerste vraag die je jezelf moet stellen: ontwerp je de sterspeler of de facilitator? Een sterspeler is een product waarvan het ontwerp rechtstreeks van invloed is op de productprestaties. Voorbeelden van producten die als sterspelers worden beschouwd, zijn een kunstknie of een beademingsapparaat dat mensen tijdens een operatie laat ademen.

Bij het ontwerpen van een product dat een facilitator is, moet daarentegen apparatuur of gereedschap worden ontworpen waarmee de 'echte' sterspeler zijn werk kan doen. Voorbeelden van dit soort producten zijn een diagnostisch instrument (dat een assay mogelijk maakt om een ​​diagnostische output te genereren), of een bioreactor (die de productie van een biofarmaceutisch faciliteert).

Om een ​​werkend prototype te maken voor een product van een sterspeler (waarvan het ontwerp direct is gekoppeld aan de prestaties), moeten we eerst de vormfactor en vereisten van het gewenste product begrijpen. We hebben deze informatie nodig om ervoor te zorgen dat het ontwerp en de vormfactor representatief zijn voor het uiteindelijke ontwerp, zodat het prototype zinvolle gegevens over productprestaties kan genereren.

Daarom begint een programma voor een product van een sterspeler vaak met het verkennen van productvereisten/specificaties, gebruiksanalyse en interviews met belangrijke opinieleiders. Pas nadat deze informatie is verzameld, kan het eerste werkende prototype worden gemaakt.

Voor een facilitator-product daarentegen is de uiteindelijke vormfactor niet vereist om de prestaties van de "echte" sterspeler te testen. Een ruw breadboard-systeem dat is gebouwd met kant-en-klare (niet-aangepaste) componenten kan bijvoorbeeld worden gebruikt om vragen te beantwoorden als: genereert mijn assay de juiste diagnostische output? Of is mijn geneesmiddel van voldoende kwantiteit en kwaliteit?

In eerste instantie wordt de oefening van het verkennen van productvereisten, bruikbaarheidsanalyse en interviews met belangrijke opinieleiders tot een minimum beperkt. Alleen de maatstaven die betrekking hebben op de prestatie (bijv. gevoeligheid, specificiteit, hoeveelheid actieve biofarmaceutica, enz.) moeten vooraf worden gedefinieerd.

Zolang de initiële prototypecomponenten de vooraf gedefinieerde productprestaties kunnen bereiken, zal het eerste werkende prototype enorme waarde bieden door de eerste praktische testresultaten te leveren, zelfs als sommige van de kritieke componenten moeten worden gewijzigd in latere ontwerpiteraties.

Niet alle producten passen gemakkelijk in de categorieën 'sterspeler' of 'facilitator'. Het categoriseren van een op maat gemaakt apparaat voor medicijnafgifte hangt bijvoorbeeld echt af van de complexiteit. Als het medicijnafgifteapparaat een therapie mogelijk maakt die anders niet zou kunnen worden toegediend (bijvoorbeeld door een medicijn toe te dienen aan een specifiek deel van de hersenen dat momenteel buiten bereik is), zou het apparaat als een sterspeler kunnen worden beschouwd.

Terwijl, als het medicijnafgifteapparaat een meer kosteneffectieve oplossing biedt voor een reeds bestaande behandeling, het product als een facilitator kan worden beschouwd.

Kortom, vrijwel elk ontwikkelprogramma zal zich richten op het zo snel en goedkoop mogelijk realiseren van technische haalbaarheid door het maken en testen van werkende prototypes. Voor sterspelerproducten duurt het doorgaans langer (en is het duurder) om deze belangrijke mijlpaal te bereiken, omdat er meer productdefinitie nodig is om een ​​zinvol werkend prototype te maken.

Omdat veel van het ontwerp en de vormfactor later kunnen worden gewijzigd, kunt u bij faciliterende producten vrijwel onmiddellijk beginnen met het maken van een werkend prototype, terwijl u zich op de achtergrond bezighoudt met de productvereisten en specificaties.

Figuur 1. Beide programma's werken zo snel mogelijk toe naar "Proof Of Principle". In eerste instantie is een ontwikkelingsprogramma voor een Star Player-product echter meer gericht op productdefinitie dan een programma voor een Facilitator-product dat meteen begint met het maken van een prototype om de prestaties te testen en technische haalbaarheid te bereiken.

2. Ontwerp – test – ontwerp – test – ontwerp – test….. stop.

Hoewel het eerste prototype altijd wordt ontworpen met de bedoeling om technische haalbaarheid te bereiken, slaagt een eerste prototype zelden aan alle eisen. Er kunnen meerdere iteraties nodig zijn. Daarom zijn er in de kern van lean en agile productontwikkelingsprogramma's snelle cycli van ontwerpiteraties, testen, leren en het integreren van de lessen in de volgende iteratie.

Door alle niet-essentiële ontwikkelingsactiviteiten gedurende deze tijd tot een minimum te beperken, helpt het team zich te concentreren en de ontwikkeling te versnellen. In dit stadium moet het aanpassen en hergebruiken van prototype-builds voor verbeterde prestaties vrijelijk worden gedaan zonder impedantie van strengere kwaliteitssystemen.

Voor alle duidelijkheid: deze strenge kwaliteitssystemen zijn van cruciaal belang in een later stadium van het programma, maar door de documentatie vroeg in het programma "licht" te houden, wordt de ontwikkeling versneld.

Snelle iteraties zijn belangrijk voor lean en agile vroege productontwikkeling. Maar dat geldt ook voor weten wanneer je moet stoppen met itereren en succes moet vieren. Ik moet nog een technisch team ontmoeten dat niet gelooft dat "meer verbeteringen een beter product zouden opleveren". En dat zouden ze ook moeten doen! Het is hun taak om te streven naar de best mogelijke ontwerpoplossing.

Daarom moet het doel om vooraf gedefinieerde prestatiestatistieken te bereiken (bijv. detectie van een x hoeveelheid analyt is bereikt, of het monster is gedurende een x tijdsperiode stabiel, enz.) vanaf het begin duidelijk worden vermeld en gedurende het hele proces worden herhaald. projecteren.

Wanneer de gewenste prestatie is behaald, betekent dit dat de technische haalbaarheid is bereikt. Dit betekent dat het programma overgaat naar de volgende ontwerpfase (waarbij een verfijnder prototype wordt gebouwd).

Dit is ook het juiste moment om te beginnen met het genereren van meer gedetailleerde documentatie waarin de architectuur van het prototype wordt geschetst en om te beginnen met het verstevigen van de productvereisten. Deze documentatie blijft relatief vloeiend (buiten de ontwerpcontrole om) tot later in het programma.

Het documenteren van deze informatie helpt interne en externe communicatie, onboarding van extra teamleden en het veiligstellen van het werk tot dat moment.

3. Hoe u programmamijlpalen bereikt met het meest flexibele team

Vaak is de verleiding groot om meer middelen in een programma te steken, ervan uitgaande dat meer slimme mensen snellere en betere oplossingen betekenen. Vooral in gereguleerde industrieën (zoals medische hulpmiddelen en farmaceutische industrieën) kunnen de heersende organisatiesystemen ook aandringen op extra teamleden die er nog niet hoeven te zijn.

Vertegenwoordigers van functies die pas later nodig zijn, kunnen vanaf het begin worden betrokken, wat resulteert in een grote overhead en communicatielast. Het resultaat is dat meer dan 20 mensen in vergaderingen zitten en proberen een programma vooruit te helpen.

Ondanks de grote teamgroottes komen deze programma's vaak traag op gang. Hoewel dit misschien contra-intuïtief klinkt, heb ik ontdekt dat kleinere, toegewijde multidisciplinaire teams sneller kunnen handelen en een onevenredige hoeveelheid innovatie kunnen genereren tijdens de vroege productontwikkeling.

Het concept van het beperken van de teamgrootte om uitstekende resultaten te behalen, is niet nieuw. Jeff Bezos, oprichter en voormalig CEO van Amazon, herkende dit fenomeen en stelde de regel in dat elk team klein genoeg moet zijn om twee pizza's te eten.

De "twee pizza-regel" wordt ondersteund door talloze onderzoeksartikelen en boeken die aangeven dat kleine teams innovatiever zijn en gelukkigere teamleden bevatten [1, 2, 3].

Figuur 2. De communicatielast groeit exponentieel met het aantal mensen in het team, zoals weergegeven in deze afbeelding. De zwarte stippen vertegenwoordigen individuele teamleden en de lijnen vertegenwoordigen unieke verbindingen tussen individuen.

In figuur 2 kun je zien dat teamgrootte exponentieel gerelateerd is aan communicatielast. Het toevoegen van een extra teamlid lijkt misschien niet veel, maar het kan in feite leiden tot aanzienlijke extra belasting en verkeerde afstemming. Vooral in de vroege productontwikkeling helpt het beperken van de teamgrootte tot niet meer dan 5 leden echt tot een snelle en gestroomlijnde ontwikkeling.

De schijnbare tweedeling in dit concept is dat de problemen die moeten worden opgelost bij de ontwikkeling van medische hulpmiddelen vaak deskundige vaardigheden vereisen. Het is uiterst zeldzaam om alle vereiste vaardigheden in een klein aantal individuen te vinden. De uitdaging is dus om een ​​klein team op te zetten dat behendig en snel kan werken en tegelijkertijd toegang heeft tot diepere niveaus van kennis/ervaring.

Helaas is er geen one-size-fits-all team, maar ik heb gezien dat de meest succesvolle teams bestaan ​​uit slechts een paar technische leiders die eigenaar zijn van de ontwerpproblemen. Meestal zijn deze technische leiders goed afgeronde individuen met vele jaren ervaring. Ze weten wanneer ze intern of extern advies moeten inwinnen op gebieden waar ze geen experts in zijn.

In deze structuur formuleert de technische leider de probleemdefinitie en brengt hij het oplossingslandschap in kaart voordat hij overlegt.

De adviseur (intern of extern) maakt geen deel uit van het kernteam (waardoor de communicatielast wordt beperkt) maar kan toch deskundige kennis aandragen voor de voorgestelde oplossingen. Vaak vindt de communicatie tussen technische leiders en consultants plaats in kleine vergaderingen waarbij niet het hele team aanwezig is.

De technische leider zorgt ervoor dat de voorgestelde oplossingen passen in de grotere ontwerpplannen van het prototype en bezit uiteindelijk een aanzienlijk deel van de prototype-architectuur.

Een bijkomend voordeel van deze structuur is dat technische leiders een groot verantwoordelijkheidsgevoel voelen voor hun technische uitdagingen en hun successen echt kunnen vieren en bezitten.

4. Stel een programmakampioen aan

Technische leiders bezitten een deel van de systeemarchitectuur, maar er moet ook een programmakampioen zijn die eigenaar is van het succes van het programma. Deze persoon is eindverantwoordelijk voor het gehele programma en zorgt ervoor dat de juiste mensen aan de juiste ontwerpoplossingen werken.

Een programmakampioen kan vele titels hebben (bijv. productmanager, programmamanager, directeur R&D, CSO, CTO, enz.), maar hun rol wordt niet bepaald door de titel. Dit is iemand die zich verantwoordelijk voelt voor een succesvol programmaresultaat en in staat is om op een meer holistische manier naar de verschillende puzzelstukjes te kijken.

De programmakampioen zal ook navigeren in het gezonde conflict tussen het technische team (met de wens om verdere verbeteringen aan te brengen) en de projectmanager (met de wens om op tijd en binnen budget te leveren). Het runnen van een ontwikkelingsprogramma met innovatie, veel onzekerheden en nieuwe technologieën vereist altijd compromissen van beide partijen.

Uiteindelijk is het effectief navigeren door dat conflict een belangrijk onderdeel van het runnen van een succesvol lean-and-agile ontwikkelteam.

Figuur 3. Een programmakampioen navigeert door noodzakelijke en gezonde conflicten die bestaan ​​tussen het technische team, de projectmanager en het productteam/de productmanager. Een programmakampioen kan een toegewijde programmamanager, CTO, CSO, R&D-directeur zijn, of hij kan lid zijn van het technische of productteam. Het belangrijkste voor deze rol is dat ze onpartijdig door conflicten moeten kunnen navigeren.

Een andere verantwoordelijkheid van de programmakampioen is het vinden van afstemming tussen het technische team en de productmanager. De productmanager is verantwoordelijk voor het doelproductprofiel en voor het stellen van commerciële doelen.

In vroege ontwikkelingsprogramma's heb ik ontdekt dat de rol van productmanager misschien niet wordt vervuld door een toegewijde persoon, maar dat de rol vaak bij meerdere individuen leeft.

Het helpen van deze individuen om de productvisie en productvereisten te stimuleren en het gesprek tussen het technische team en het productmanagementteam te vergemakkelijken, is essentieel om tot een productontwerp te komen dat aan de verwachtingen voldoet en een marktbehoefte vervult.

Samengevat

Samenvattend begint het opzetten van een lean en agile productontwikkelingsprogramma met het definiëren van de activiteiten die zo snel mogelijk technisch haalbaar zullen zijn. Het hebben van een klein, toegewijd team van ervaren technische leiders die snel prototype-iteraties ontwerpen, bouwen en testen, zorgt voor een behendige en kosteneffectieve structuur.

Ten slotte is het van cruciaal belang om een ​​programmakampioen aan te stellen die de algehele afstemming helpt, het moment oproept waarop technische haalbaarheid is bereikt en de gezonde conflicten navigeert die zouden moeten bestaan ​​tussen het technische team, de projectmanager en het productteam/de manager.

1. Steiner ID., 1972. Groepsproces en productiviteit... New York: Academic Press.
2. Laughlin PR. et al., 2006. Groepen presteren beter dan de beste individuen bij letter-naar-cijferproblemen: effecten van groepsgrootte. Journal of Personality and Social Psychology, 90(4), 644-651.
3. Brett J. en Wang D., 2020, Als u creatieve oplossingen wilt, houd uw team dan klein, Wetenschappelijke Amerikaan

Afbeelding: Kan stockfoto / olivier26

Joris van der Heijden is Programmamanager Bio Services bij Zeester Medisch. Voorheen was hij Director of R&D bij Spartan Bioscience, waar hij leiding gaf aan de ontwikkeling van een point-of-care COVID-19 diagnostische test. Joris is gepromoveerd op infectieziekten bij UBC.

[Ingesloten inhoud] 

---

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. Toegang hier.
• Bron: https://starfishmedical.com/blog/a-guide-to-lean-and-agile-medical-device-product-development/