Nieuwe produkten ontwikkelen? Bouw een economisch raamwerk!

[krd]

De huidige manier van ontwikkelen is traditioneel, vastgeroest en inefficiënt. En het valt niet mee om daar los van te komen. Maar er gloort licht aan het eind van de tunnel.

 

Wat zijn de problemen in de huidige manier van werken?

Het zijn er velen maar laten we beginnen bij het begin. Nog nooit ben ik een bedrijf of R&D afdeling tegen gekomen die een juist economisch raamwerk had waarop beslissingen konden worden genomen. Heb jij geen last van, je hebt het natuurlijk allemaal dik in orde. Maar als ik je de vraag stel, wat is de Cost of Delay van alle projecten die je onderhanden hebt, dan heeft maar 15% van de product ontwikkelaars een antwoord. Hoeveel minder life-cycle opbrengst heb je als je project een week uitloopt? Waarschijnlijk weet je het niet. Productontwikkelaars denken dat ze begrijpen wat er gebeurt met kosten en opbrengsten als specificaties, kostprijzen en planningen veranderen. Maar dat doen ze dus niet.

 

Value-added time

Product ontwikkelaars zijn gefocust op de activiteiten die waarde toevoegen, de zogenaamde value-added time. Daarom vullen we allemaal urenbriefjes in zodat we precies weten hoeveel tijd we aan een project hebben besteed. Als we te weinig uren maken op projecten moet er even een gesprek volgen, want het moet omhoog. Maar als ik ze vervolgens vraag hoeveel dit de life-cycle opbrengst verhoogd. Wederom geen antwoord.

 

Het economisch raamwerk

Het belangrijkste doel in productontwikkeling is dat we goede economische beslissingen nemen. Wat zijn de economische gevolgen over de complete life-cycle van het product als de planning uitloopt, een specificatie verandert, de kostprijs omhoog gaat of een feature onhaalbaar is?

 

Tip: Maak het visueel, het onzichtbare zichtbaar en het vage concreet, zodat je goede beslissingen kunt nemen die de life-cycle opbrengsten verhogen, want uiteindelijk is dat het enige dat telt!

 

[P.J.]

Geweldige tip! Huur een sjamaan om het onzichtbare zichtbaar te maken.....

Kijk naar Apple. Wat 3 jaar geleden op de ontwikkelingstafel lag als een embrio, is zojuist op de markt gebracht! Welke starter of eenpitter kan dat nu realiseren?

[Hans v N]

In de tijd dat ik exploratieve research deed was er vaak niet eens een concreet productidee. Iemand had een wild idee naar aanleiding van een wetenschappelijke publicatie of een intern ontwikkelde techniek en er werd geld vrijgemaakt voor onderzoek. Zolang er maar regelmatig winstmakers gemaakt werden, of op zijn minst gouden beloften, bleef de geldkraan open.

Die tijd is al lang voorbij.

 

Maar knappe jongen die bij het ontwikkelen al zinnige uitspraken kan doen over de levenscyclus van een nieuw product of nieuwe dienst. De meeste ondernemingen komen met nieuwe zaken in de HOOP dat er eens in de zoveel tijd een hit bij zit en de vele zeperds op zijn mist break-even halen.

 

Natuurlijk kan je alles "calculeren". Kijk maar naar de meeste marketingplannen die vol zitten met aannames en extrapolaties. Vrijwel altijd zit men er goed naast.

 

[herman van der helm]

Het enige wat ik in de loop van 30 jaar als uitvinder gemerkt heb bij het ontwikkelen van een idee is, dat er geen zinnig woord over het ontwikkeltrajekt te zeggen valt. Naarmate ik meer zeperds gescoord heb, kan ik nu (als een sjamaan) aanvoelen of iets een grote kans van slagen heeft of gedoemd is in de archieven te verdwijnen.

 

Eén van de meest noodzakelijke dingen die je moet doen als je gevoel zegt "dat het goed is", is focus houden op je ontwikkeling. Je dus niet af laten leiden door toepassingen die er ook mee kunnen. Mijd de zogenaamde spinoffs. Het doel voor ogen houden levert de meeste besparing op.

 

Als je mij vraagt wat een ontwikkeling kost en om er een planning voor te maken, kan ik dat wel. Ik ga namelijk met eenzelfde natte vinger te werk om de begroting te maken als hoe ik met de natte vinger de ontwikkeling uitvoer. Heel soms, en dat is me toevallig één keer gebeurd, heb ik exact volgens de begroting gewerkt. Meestal maak ik geen begroting, maar in dit geval heb ik een subsidieaanvraag ingediend op verzoek van de overheid om een tilhulpmiddel te ontwikkelen. Deze aanvraag is afgewezen en ik ben het toch maar gaan ontwikkelen. Nooit meer naar de begroting gekeken. Toen het project marktklaar was de begroting er naast gelegd en toen bleek dat we één maand overschreden hadden op een traject van anderhalf jaar, en 2% aan uren overschreden hadden. Ik denk dat dit echter louter toeval is geweest omdat vanwege de economische crisis ikzelf meer tijd had, en mijn dochter me een halve werkweek per week heeft kunnen assisteren.

[P.J.]

De openingszin van deze column:

 

"De huidige manier van ontwikkelen is traditioneel, vastgeroest en inefficiënt."

 

irriteert me een beetje. De inhoud van het verhaal levert me geen enkel bewijs om deze stelling waar te maken. Ik ben benieuwd naar de praktische ervaringen van de CS, die hem ertoe hebben gebracht om met deze stelling te openen.

[Frans Sijtsma]

Je gooit R&D en productontwikkeling op een hoop.

 

Productontwikkeling is alleen de D van R&D en heel misschien, als je de basis van je idee al heel goed hebt staan, kun je daar een economisch raamwerk aan hangen.

 

Punt is alleen dat je om die basis goed te krijgen een onbekende hoeveelheid tijd en geld in de R moet steken, met name als het om innovatieve producten gaat.

 

Hoe ziet CS zo'n economisch raamwerk voor zich? Welke elementen moet die bevatten en op basis waarvan neem je binnen dat raamwerk beslissingen?

 

[krd]

Even ter introductie en verduidelijking, ik ben al actief in productontwikkeling sinds 1987, dus heb heel goed geleerd hoe het niet moet. Maar dat even terzijde. Eén ding is in ieder geval goed gelukt. Het lokt reactie uit.

Misschien moet ik het zo stellen. Je wil een product lanceren. Je hebt uiteraard in beeld wat je verwacht van dit nieuwe of verbeterde produkt. Natuurlijk hebben we de apples in deze wereld, maar bijna niemand denkt na, of maakt afwegingen, wat er gebeurt als een ontwikkelingstraject uitloopt. Wat is de cost of delay? Er komt een vraag voor een nieuwe feature, wat kost het om deze feature te ontwikkelen (nog voor lancering) en wat zijn de geschatte opbrengsten tijdens de levencyclus. Natuurlijk als je een nieuw produkt in nieuwe markt zet, is dit bijna ondoenlijk, maar een nieuw produkt of verbeterd produkt in een bestaande markt is wel redelijk in te schatten. Daarnaast gaat het om leren, dus mocht de schatting niet kloppen is dat een leermoment voor de volgende keer.

Ik noem de huidige manier van ontwikkelen vastgeroest omdat we nog steeds traditioneel ontwikkelen, namelijk met fases. Door mijn ervaringen Lean in produktie ben ik al langer tijd bezig met Lean in ontwikkeling en als je dan ziet hoe je de output van techneuten enorm kan verhogen dan zeg ik dus de huidige manier is vastgeroest en inefficiënt.

Goed hoe ziet zo'n raamwerk er dan uit. Dat raamwerk is eigenlijk niet eens zo heel ingewikkeld, maar daar staat in de geschatte kosten voor ontwikkeling, de verwachte marge en de kosten van vertraging per dag. Later kun je daar nog factoren aan toevoegen zoals, strategisch belang of klantsatisfactie. In dit overzicht kun je dus meteen zien wat de gevolgen zijn als een project uitloopt, oftewel kun je trade-offs maken tussen kosten van nieuwe features, doorlooptijd en totale opbrengsten tijdens de looptijd van het product. We doen nu vaak in ontwikkeling dingen op gevoel en waar ik heen wil is, beslissingen maken op basis van cijfers. Natuurlijk snap ik ook dat dit, als je er mee begint, niet meteen klopt. Maar door te leren en de werkelijk te vergelijken met de praktijk wordt zo'n raamwerk steeds beter heb ik zelf ervaren. Zou nu niet meer zonder kunnen.

[herman van der helm]

We doen nu vaak in ontwikkeling dingen op gevoel en waar ik heen wil is, beslissingen maken op basis van cijfers.

 

Mijn ervaring is, dat ik de dingen op gevoel doe, en als men cijfers vraagt (bijvoorbeeld voor een bedrijfsplan) dat ik dan de cijfers perfect op de wens van de degene die de cijfers nodig heeft kan laten aansluiten. Ook hier probeer ik weer in te voelen wat men wil horen.

[krd]

Herman, je gaat nu twee dingen vergelijken die totaal los van elkaar staan. Daarnaast maak je de cijfers voor jezelf.

Het opvallende is als je zo'n raamwerk hebt gemaakt, je al snel ziet det de ontwikkelingskosten van ondergeschikt belang zijn

in de berekening van de cost of delay.

 

Voorbeeld, ik classificeer een ontwikkeling in 500, 2500 en 5000 uur en de kosten van materialen in 50k, 250k en 500k. Even simpel rekensommetje. Je product kost 2500 om te maken en je marge is 4000 euro. Je verwacht er ongeveer 1000 te verkopen per jaar, dan is je cost of delay 10k per dag! Als de ontwikkeling door een wijziging 1 maand langer duurt, dan is de cost of delay 300k. Die nieuwe feature of wijziging moet dan wel echt heel veel opbrengen om het rendabel te laten zijn. De maand meer ontwikkelingskosten zijn, zoals je zelf snel kunt uitrekenen, ondergeschikt aan de cost of delay.

 

En dat is dan ook precies wat ik bedoel. Met zo'n raamwerk kun je betere beslissingen nemen want uiteindelijk gaat het om wat er over blijft onder aan de streep. Een verandering moet simpelweg geld opleveren ipv andersom. Vaak zijn techneuten zich hier niet van bewust en dus ook helemaal niet mee bezig.

[P.J.]

Mijn (ouderwetse) ervaring is dat je zo min mogelijk druk op ketels moet zetten als je idee in hardware wordt omgezet. Wel opletten en bewaken dat je precies krijgt wat je hebt gepland. Dit kan natuurlijk alleen maar in het geval als een dergelijk product al is besteld. Als de markt "open" ligt. In jouw verhaal ga je daar in feite ook al vanuit. Wat als je die markt nog niet "open" hebt liggen en er juist vóór je eigen introductie, de concurrent met nét iets slimmers in die markt aan komt zetten? Heb je dat ook in je raamwerk meegenomen?

[Highio]

Beste krd,

 

vanuit de column probeer ik een vertaalslag te maken naar de situatie van bijvoorbeeld een kleine ontwikkelaar van eenvoudige consumentenproducten of naar de diensten op projectbasis van een internetbureau van bescheiden omvang, want dit soort partijen zijn hier veelal je publiek..

 

Wat ik uit de column opmaak, is een voorkeur voor een introductiestrategie van een basisvariant of minimale, werkbare versie volgens specificatie of briefing en een waarschuwing voor onderlinge verdringing door productvarianten (concurrenten) of voor doorschieten in optimalisatiestappen, waardoor ander (betaald) werk blijft liggen.

 

Porfoliomanagement of projectmanagement bij middelgrote en kleine innoverende ondernemers is daarbij eerder een verdeling van uren over de verschillende bedrijfsfuncties dan een keuze voor verschillende innovatieprojecten. Over welke markten en producten spreek jij? Zijn dat industriële producten? En daarbij ondernemingen van behoorlijke omvang?

 

Groet,

 

Highio

[krd]

@Peter, op dit gebied wordt er veel onderzoek gedaan op de TU in Eindhoven. Daar hebben ze wetenschappelijk onderzoek gedaan naar de winstgevendheid van nieuwe produkten. Wat blijkt, de maximale life-cycle winst haal je:

1. Door in het begin van de ontwikkeling maximale capaciteit in te zetten in het project en

2. Zoveel mogelijk features toe te voegen

 

of:

1. Door aan het eind de maximale capaciteit in te zetten om het project zo snel mogelijk te beëindigen zodat je de markt op kan en

2. Zoveel mogelijk features weg te laten (voor zover dat mogelijk is)

 

Alle andere scenario's leiden tot minder winst! Inmiddels hebben ze daar ook een management game voor ontwikkeld. De onderzoek wordt binnenkort gepubliceerd.

 

Zoals je terecht zegt, heeft ontwikkelen tijd nodig, maar wel zo min mogelijk! Door lean Development toe te passen, is Toyota in staat nooit!!!! een marktintroductie te missen. Maar goed dat is in feite het doorontwikkelen van een bestaand product. Al hoewel op subsysteemnivo er veel innovaties worden toegevoegd.

 

Als je iets totaal nieuws neer zet, zoals elektrische auto's, dan werkt dit niet. Inderdaad het verschil tussen research en ontwikkeling

Waar je echter wel voor kan zorgen is flow. Flow in je projecten, in de ontwerpcycli en flow in kennis. In productontwikkeling komen de volgende verspillingen nog vaak voor:

 

1. Teveel detail, onnodige of dubbele informatie

 

2. Teveel informatie, onvolledige inhoud

 

3. Communicatie storingen, data op meerdere plekken

 

4. Informatie ge-pushed naar verkeerde mensen

 

5. Informatie te vroeg beschikbaar, informatie niet op juiste tijd beschikbaar

 

6. Gebrek aan kwaliteit, conversie fouten, verkeerde niveau van informatie

 

7. Teveel iteraties, beslissingscriteria onduidelijk

 

Leon Limonard heeft er een artikel over geschreven: Meer output met minder verspilling!

 

[P.J.]

Ik denk dat het gemakkelijk wordt om ons van je verhaal te overtuigen, als we een praktijlkvoorbeeld nemen om dat in het "oude" en in het "nieuwe" (theoretische) rekenmodel op te nemen.

 

Een uitvinder is naast het feit dat hij handig is, ook heel goed thuis in de chemie. Hij vindt een nieuw soort inkt uit, die gebaseerd is op nieuwe stoffen. Hij is de eerste die deze samenstelling heeft gevonden en er enkele proeven mee heeft gedaan. De inkt kan geproduceerd worden van veel goedkopere grondstoffen. Er is geen afhankelijkheid meer van de olie-industrie en bovendien is de inkt biologisch afbreekbaar.

 

Dit lijkt me een mooi scenario om met en zonder raamwerk te bespiegelen. Ben benieuwd naar de praktische verschillen.

[krd]

@Peter, ik wil helemaal niemand overtuigen, probeer mijn zienswijze en ervaring te delen zodat een ieder, die dat wil , daar zijn of haar voordeel mee kan doen.....

Soms hoor je iets nieuws waarvan je denkt, verhip nooit zo over nagedacht....

[krd]

is een leuk voorbeeld....mag ik wel. Waarschijnlijk heb je wel eens gehoord van de BlueOcean strategie. Dit lijkt me daar, zo op het eerste gezicht, een mooi voorbeeld van. Net zo als de ipad. Die is natuurlijk niet de becijferen. Snap ik ook wel, alleen worden er maar weinig van dit soort producten ontwikkeld. Veel ondernemers vissen nog steeds in de rode oceaan, vol haaien en andere gevaarlijke dieren....en dan ligt het iets genuanceerder.

 

Zo'n raamwerk is zeker niet theoretisch maar gewoon een heel praktisch hulpmiddel voor dagelijks gebruik. Feit is gewoon dat er vaak simpelweg niet over nagedacht wordt....

[P.J.]

Ik vind het wel interessant en nuttig als je een soort raamwerk zou kunnen ontwikkelen, dat als basis door elke uitvinder kan worden gebruikt. Vandaar ook het voorbeeld en de vraag of je dat kunt bespiegelen t.o.v. de "traditionele aanpak. Dan zouden meteen de voordelen van dat raamwerk zichtbaar worden.

[krd]

@Peter, goed idee, zal eens even nadenken of ik een blog hierover kan schrijven met een bijlage die iedereen dan kan downloaden, kunnen we die sheet misschien gezamenlijk verbeteren...

[StefanO]

Geinige insteek. De tijd dat je geld met een innovatie kunt verdienen is beperkt. Een mooi voorbeeld vind ik altijd de farmaceutische industrie. Eerst ontwikkelen, patenten regelen, goedkeuring krijgen (duurt lang) en in de tijd die dan nog over is moet het geheel worden terugverdiend en een merk worden neergezet zodat klanten na afloop van het patent nog steeds voor het origineel kiezen (en niet voor generics). De costs of delay zijn dan heel goed meetbaar (je weet wanneer je monopolie op je vinding afloopt).

 

Hoe bepaal je dan de einddatum van een innovatie? Wanneer wordt je door de markt ingehaald? Hoe kan je de life cycle nog verlengen? Best lastige materie. Sinds enige tijd ben ik met 'failure fast forward' aan het experimenteren. Het idee hierachter is dat je niet vooraf aan de tekentafel helemaal kunt bedenken hoe het nieuwe eruit moet komen te zien, maar dat je in rap tempo kleine stappen zet en deze test in de markt (of afgeleide daarvan). Hierdoor krijg je snel feedback en zodra je merkt dat je 'beet hebt' moet je opschalen en verder uitbouwen.

[krd]

Hele goede strategie StefanO. Vaak wordt er te lang doorgegaan, terwijl je soms sneller naar de markt kunt gaan om te testen. Ik hou altijd aan bij een doorontwikkeling, maximaal 3 nieuwe features en een extreem korte time-to-market. Nogmaals de cost of delay is echt onderschat, maar een zeer belangrijke factor....

[arjannn]

Geweldige tip! Huur een sjamaan om het onzichtbare zichtbaar te maken.....

Kijk naar Apple. Wat 3 jaar geleden op de ontwikkelingstafel lag als een embrio, is zojuist op de markt gebracht! Welke starter of eenpitter kan dat nu realiseren?

 

Die ipad?

 

Een simpele tab die er al jaren is een nieuwe jasje geven....

 

Gewoon hoop marketing, zoals jij het brengt hebben ze t wiel opnieuw uitgevonden.

 

Maar, dat is mijn mening.

[Hans v N]

Hihi. ;D

Net als de Volkswagen new Beetle, gewoon een gepimpte Kever en de rest is gebakken lucht. Dit is overigens niet mijn mening. ;)

 

Dat productontwikkeling doelmatiger kan als je vrij simpel toe te passen regels volgt is duidelijk. Maar dat geldt voor vrijwel alles in het leven. De auto één keer per maand tussen de middag vol tanken, daar je boterham eten terwijl hij door de wasstraat gaat, i.p.v elke zaterdag zelf spons en zeem te pakken levert een gigantische besparing op in tijd en geld.

 

Die boodschap is duidelijk en het kan zeker geen kwaad daar eens bij stil te staan, ook voor productontwikkeling. Maar ik vraag me af wat het toevoegt om paraat te hebben als productontwikkelaar wat de Cost Of Delay is voor elke vraag die wordt gesteld. Ik denk zelfs dat het de creativiteit en het onderscheidend vermogen van een organisatie danig aan kan tasten.

[Iwan van Geelen]

Ik mis een beetje een ondernemers standpunt/visie maar zie vooraal veel termen die zoooo 2006 zijn

[krd]

@Hans, als je dat niet snapt dan moet ik mijn huiswerk overdoen. Een goed verhaal schrijven is ook een kunst daar heb ik nog veel in te leren.

Maar goed, Ik rank zelfs projecten volgens de cost of delay, projecten met de hoogste cost of delay krijgen meestal voorrang. Ik kan je verzekeren dat het zeker niet de creatviteit aantast. Veel meer focus en duidelijkheid bij iedereen

@iwan, welke termen zijn zo 2006?

[Hans v N]

Ik snap best wat je duidelijk wil maken. Heb alleen mijn bedenkingen hoe dat in de praktijk uitpakt. Zoals in mijn vorige post staat heb ik zowel een volledig creatieve organisatie gewerkt als ook in een project management organisatie waar alles in timetable's en trakke begrotingen ging.

 

Natuurlijk is projectmatig werken doelmatiger. Zie mijn voorbeeld in de wasstraat hierboven.

Maar doelmatig werken en hiermee winstmaximalisering nastreven conflicteert in mijn ogen altijd met creativiteit en daarmee anders zijn. Een recht pad is het meest doeltreffend maar de creatieve zaken en daarmee het onderscheidende vermogen van een onderneming zit vaak in de zijweggetjes.

 

Als altijd werkt hier de gulden middenweg. Voorbeelden zijn (wederom) Apple maar ook Google en Microsoft. Die laten, naast een strakke projectmatige weg, mensen bewust de zijpaadjes ingaan en beslissen later of er gebruik van wordt gemaakt. Kost wel wat meer, maar dan heb je ook wat anders. Nokia is wellicht een goed voorbeeld van bedrijf met een strakke projectmatige ontwikkelingsafdeling. Of kijk naar de auto-industrie.

 

 

[P.J.]

Misschien is een kort vragenlijstje voor de startende uitvinder ook al voldoende?

[brood]

Bestaat er ook zoiets in tegenstelling met “cost of delay” als “profit at extension” of “profit of contingency”?

 

Wanneer laat op de markt gekomen wordt loopt het wellicht ook langer door voordat het daalt.