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!

 

[Vroom]

Nederland kent een professor die een heel mooi model ontwikkelt heeft om de R&D goed af te stemmen met een prachtig simulatiemodel. Het jammere is dat geen naam mag noemen op het platform, omdat dit gezien wordt als reclame.

[Frans Sijtsma]

Nederland kent een professor die een heel mooi model ontwikkelt heeft om de R&D goed af te stemmen met een prachtig simulatiemodel. Het jammere is dat geen naam mag noemen op het platform, omdat dit gezien wordt als reclame.

 

Nee hoor, geen enkel probleem om de naam te geven en evt te linken. Tenzij je het zelf bent, dan moeten we er nog eens een nachtje over slapen

[krd]

@brood, uit onderzoek blijkt dat het meer winstgevend is als je eerder op de markt komt metminder features dan maar door ontwikkelen, maar elke situatie is natuurlijk anders.

[herman van der helm]

krd, toch wil ik een voorbeeld geven waar ik denk dat jouw verhaal niet goed zal werken.

 

Ik heb in 1992 een steekkar ontwikkeld die kon tillen. Ik heb hem gemaakt voor eigen gebruik en hij was mechanisch aangedreven. Ik ben toen aan het zoeken geweest of er een markt voor was. Niemand was toen bezig met arbo en bescherming van werknemers tegen rugklachten. Als ik toen door had gezet was ik met een ontwikkeling op de markt gekomen, waar maar weinig mensen interesse in zouden hebben, en het product was vermoedelijk geflopt. Nu 19 jaar later begint zich een aardige markt af te tekenen en ik denk dus dat het een goed moment is geweest om er in 2010 mee op de markt te komen. Stel dat ik het toen uitontwikkeld had, en er ook het huidige patent op had gevestigd, zou dit volgend jaar zijn verlopen. Wil je dit voorbeeld eens in jouw stelling plaatsen?

[P.J.]

De markt is altijd bepalend en ook vaak een factor die zich niet gemakkelijk laat bepalen, daar hij op vele fronten ook doorlopend in beweging is. Een stilstaande mart is een "dode" markt, danwel een jammermarkt. Leidingwater hoef je niet meer uit te vinden. De waterleidingbedrijven laten zich echt die markt niet afpakken en kunnen een prijs vragen die ordinair uit de neus is getrokken.

[Hans v N]

krd, toch wil ik een voorbeeld geven waar ik denk dat jouw verhaal niet goed zal werken.

 

Ik heb in 1992 een steekkar ontwikkeld die kon tillen. Ik heb hem gemaakt voor eigen gebruik en hij was mechanisch aangedreven. Ik ben toen aan het zoeken geweest of er een markt voor was. Niemand was toen bezig met arbo en bescherming van werknemers tegen rugklachten. Als ik toen door had gezet was ik met een ontwikkeling op de markt gekomen, waar maar weinig mensen interesse in zouden hebben, en het product was vermoedelijk geflopt. Nu 19 jaar later begint zich een aardige markt af te tekenen en ik denk dus dat het een goed moment is geweest om er in 2010 mee op de markt te komen. Stel dat ik het toen uitontwikkeld had, en er ook het huidige patent op had gevestigd, zou dit volgend jaar zijn verlopen. Wil je dit voorbeeld eens in jouw stelling plaatsen?

 

Precies. Er moet eerst een markt zijn voor het product en ik wil daar nog aan toevoegen dat het betaalbaar moet zijn. Denk bijvoorbeeld aan geheugen / GPS chip voor Tomtom. Als die eerder gekomen waren met een heel dure module was de concurrentie veel eerder op de markt gekomen en hadden ze veel korter kunnen profiteren van een hoge marge. In het verleden was daardoor vaak niet de eerste op de markt succesvol maar de volger.

 

En daar komen we precies op het punt waar COD wel belangrijk is realiseer ik me nu. De "me too" producten in de technische markten. Als je een bijvoorbeeld een tablet op de markt zet als die markt volwassen wordt of is, zijn de marges lager, concurrentie heviger en loopt het product veel eerder terug in volume. Maar om een echte berekening te kunnen maken is toch weer een Sjamaan nodig. Voor echte (Bleu Ocean) innovaties werkt het dus niet of contra productief.

 

 

[Highio]

Misschien moet de boodschap dan iets genuanceerd of verduidelijkt worden tot zo snel mogelijk de markt op (technisch realiseren) als alle seinen van marktonderzoek op groen staan.

 

Doet eigenlijk niks aan het idee af. Ik ben nog steeds benieuwd vanuit welke markt of branche deze inzichten opgedaan zijn.

 

Groet,

 

Highio

[krd]

Allen, hier even een korte samenvatting van het nog uit te brengen artikel:

Escalation, de-escalation, or reformulation: Effective interventions in delayed NPD projects

 

http://www.kimvanoorschot.info/abstract%20Escalation.htm

 

Ik heb de beschikking over de voorpublicatie, stuur me even een pm als je die wil ontvangen.

[RoelO]

Hallo,

Ik vind cost of delay zoals dit gebruikt wordt een vreemd begrip. Ten eerste wordt het niet berekend als kosten, maar als een soort gederfde inkomsten per dag.

Dit heeft tot gevolg dat als er twee projecten lopen, het project met de meeste "gederfde inkomsten" voorrang krijgt. Of dat voordelig is hangt mijns inziens niet van de gederfde opbrengsten, maar van de gederfde netto winst af.

Ten tweede zullen bij een dergelijke beslissing ook de ontwikkelkosten bij beide projecten veranderen, zonder te kijken naar de budgetten.

Begrijp me goed: ik zie het voordeel wel van een raamwerk, maar zou dat niet moeten zijn ontwikkelkosten per dag?

Het lijkt me namelijk een logischer veronderstelling dat bij vertraging de totale ontwikkelkosten evenredig hoger worden, omdat de vertraging optreedt als gevolg van meerwerk. Dat die kosten afgezet worden tegen de meerwaarde van het product is redelijk.

Als laatste: de mate waarin opbrengsten werkelijk gederfd worden is mijns inziens heel moeilijk te bepalen, de vooronderstelling dat de vertraging de totale vraag evenredig vermindert lijkt me gewaagd.

[Andreas | Alskar Design]

Ben het met RoelO eens dat de cost of delay een raar begrip is. Productontwikkeling kost natuurlijk geld, maar het daadwerkelijk industrialiseren van een product kost vaak nog vele malen meer, en kan ook nog behoorlijk wat tijd vergen. Daarom kan het toch regelmatig gebeuren dat producten ontworpen worden, ontwikkeld worden, getest worden en dat nog steeds daarna wordt besloten om het project af te blazen of uit te stellen, als bijv. blijkt dat de markt is veranderd of er nog niet klaar voor is. En dat is soms een wijze beslissing.

 

Snelheid van ontwikkeling is belangrijk, maar te vaak komen we producten in de markt tegen die niet goed zijn door ontwikkeld, waar te weinig tijd aan in besteed, waardoor de ervaring voor gebruikers veel minder is. De kwaliteit laat dan te wensen over, de software is niet goed afgestemd op de hardware, de hardware vertoond kleine problemen, etc.