Maand: maart 2020

Tijdens meerdere ontmoetingen deze week (online, uiteraard) kwam dezelfde uitdaging naar voren: bedrijven en hun klanten zijn bijzonder slecht in het precies definiëren van het gewenste resultaat dat ze willen bereiken. Op het eerste gezicht beweert iedereen die ik ontmoet precies te weten wat hij of zij wil bereiken, maar als puntje bij paaltje komt en de persoon wordt gevraagd dit nauwkeuriger te definiëren, wordt het gebrek aan specificiteit snel duidelijk.

Dit is natuurlijk lang niet de eerste keer dat ik hiermee in aanraking kom en het interessante is dat er een verscheidenheid aan woorden is die bedrijven gebruiken om het gebrek aan specificiteit te verdoezelen. Woorden als klantwaarde, kwaliteit, snelheid, betrouwbaar en robuust worden vaak gebruikt als algemene termen om goed over te komen, maar blijken geen echte betekenis te hebben als ze nader worden onderzocht.

De uitdaging is dat het niet duidelijk zijn over het gewenste resultaat allerlei problemen veroorzaakt voor organisaties. Een daarvan is dat prioritering in het bedrijf de neiging heeft te worden gedreven door de luidste klant. Klanten hebben de neiging om veel lawaai te maken over iets waar ze op dat moment toevallig om geven, vooral als het niet goed werkt. Het gevolg is dat ze contact opnemen met het bedrijf met berichten over een verslechterende kwaliteit. Als je niet hebt gedefinieerd wat je bedoelt met kwaliteit en je hebt geen statistieken om op te volgen wat het huidige niveau is, is het heel gemakkelijk om gewoon mee te gaan in de mening van de klant en aanzienlijke middelen toe te wijzen aan het aanpakken van dit potentiële kwaliteitsprobleem. De opportuniteitskosten hiervan zijn enorm, aangezien het verkondigde probleem een kleinigheid kan zijn en het heel goed mogelijk is dat het veel beter voor het bedrijf zou zijn geweest om de middelen elders in te zetten.

Een gebrek aan een precieze definitie van gewenste resultaten creëert ook verschillende problemen binnen de organisatie. Ten eerste kan het gemakkelijk leiden tot teams waarvan de inspanningen tegenstrijdig zijn door verschillende interpretaties van hoe succes eruit ziet. Bijvoorbeeld, teams die de klantwaarde willen verbeteren door een eenvoudigere, meer intuïtieve gebruikersinterface te ontwikkelen, komen in conflict met teams die de klantwaarde willen verbeteren door extra functies of meer configuraties en varianten van bestaande functies te ontwikkelen. De laatstgenoemden zullen UI-ruimte nodig hebben om de gebruiker te laten kennismaken met de extra functionaliteit en opties die de inspanningen van de eerstgenoemden gemakkelijk teniet zullen doen.

Een ander aspect, waar ik al eerder over heb geschreven, is de inefficiëntie van ontwikkeling die niet is gebaseerd op nauwkeurig, of liever kwantitatief, gedefinieerde klantwaarde. Voor een bedrijf dat 5 procent van de omzet aan R&D besteedt en een gemiddelde FTE kost van 120 k€/jaar, kost een agile team van 8 mensen dat in sprints van 3 weken werkt ongeveer 60 k€ per sprint, maar moet het per sprint 1,2 M€ (60 k€/0,05) aan bedrijfswaarde genereren. Vage uitspraken over kwaliteit, snelheid, betrouwbaarheid en waarde helpen organisaties niet om dit resultaat te bereiken.

Concluderend, veel organisaties schieten tekort in het precies definiëren van het gewenste resultaat voor initiatieven, projecten, producten, enzovoort. Middelen worden toegewezen vanwege luide klanten, historische patronen, ingesleten gedrag of interne politiek, niet omdat deze middelen de hoogste RoI voor het bedrijf opleveren. In ons onderzoek werken we met bedrijven aan waardemodellering om deze uitdagingen te overwinnen en hen op weg te helpen bij het nauwkeurig en kwantitatief definiëren van gewenste uitkomsten. Neem contact met me op als je meer wilt weten.

Een van de welbekende worstelingen van elk bedrijf waar ik mee werk is het combineren van innovatie met efficiëntiegerichte activiteiten. Dit is het klassieke probleem van ambidexteriteit: het bedrijf moet de omzet en marges van vandaag waarmaken en tegelijkertijd de toekomst veiligstellen. Het probleem is niet dat bedrijven zich niet bewust zijn van de uitdaging, maar dat ze de hulpmiddelen of mechanismen missen om de balans op een goede manier te bereiken. Dit is in sommige opzichten verrassend, aangezien er vele pagina’s vol geschreven zijn over deze uitdaging, variërend van boeken tot onderzoekspapers en van blogposts tot bedrijfspresentaties.

De belangrijkste uitdaging is dat de twee bedrijfssystemen fundamenteel verschillend zijn. In Operations gebruiken we de klassieke lopende band manier van denken door het werk in brokken te hakken, het aan verschillende mensen en functies te geven en overdrachten tussen hen te hebben. De focus ligt op hoe elke stap in het proces kan worden uitgevoerd tegen de laagste kosten. Aan de verkoopkant ligt de focus op tactieken om klanten met een bekende en vastgestelde behoefte aan het product ons te laten verkiezen boven concurrenten en om nu te kopen in plaats van later. Dit leidt tot watervalprocessen, hiërarchische organisaties, transactionele bedrijfsmodellen en een niet aflatende focus op efficiëntie. De toewijzing van middelen is gebaseerd op operationele behoeften en investeringen die innovatie ondersteunen hebben meestal een voorspelbare RoI die een Gaussiaanse waarschijnlijkheidscurve volgt.

Innovatie daarentegen houdt zich bezig met het vinden van nieuwe kansen. Dit betekent experimenteren met nieuwe concepten voor bestaande klanten en mogelijk bestaande concepten verkopen aan nieuwe klanten. Aangezien we zoveel mogelijk concepten willen testen tegen de laagste kosten per experiment en het concept tegelijkertijd alle relevante aspecten moet omvatten, waaronder technologie, techniek, bedrijfsmodel en ondersteuning, vereist de aard van innovatie krachtige cross-functionele teams die zich bezighouden met voortdurende relaties met potentiële klanten. De RoI van dit type innovatie volgt meestal een machtsfunctie, wat betekent dat de RoI van de meest succesvolle innovatie hoger is dan het rendement van alle andere innovatie-initiatieven samen. Innovatie is van nature een spel met een hoog risico en een hoog rendement.

Veel bedrijven gaan de fout in bij het duidelijk scheiden van de twee besturingssystemen, wat resulteert in een groot aantal problemen rond innovatie. Omdat de meeste middelen aan de operationele kant van het bedrijf zitten, worden innovatie-inspanningen vaak geëvalueerd op basis van criteria die worden aangestuurd door een operationele mindset. Dit leidt tot twee uitersten. Het eerste is waar elk innovatief idee wordt gedood voordat het de kans heeft gehad om zichzelf te bewijzen. Omdat innovatie per definitie het doorbreken van de bestaande spelregels is, ligt het voor de hand dat de meningen binnen het bedrijf zullen proberen het idee om zeep te helpen, tenzij het wordt beschermd. Aan de andere kant van het spectrum zijn er situaties waarin een innovatief concept volledig ontwikkeld en klaar voor productie moet zijn voordat we het zelfs maar aan een klant willen laten zien. Dit leidt tot de [minimaal levensvatbare olifant](https://bits-chips.nl/artikel/are-you-building-a-minimal-viable-elephant/) waar ik eerder over schreef.

Innovatie en operatie combineren is moeilijk. In mijn ervaring zijn er ten minste twee hulpmiddelen die nuttig zijn in deze context, namelijk het drie horizonten model en ongestructureerde tijd. Het drie horizonten model (toegeschreven aan McKinsey) verdeelt de activiteiten van het bedrijf in drie categorieën. Horizon 1 zijn de volwassen cash cow-producten die het grootste deel van de inkomsten genereren. Het model zegt dat deze horizon 70 procent van alle middelen in het bedrijf moet krijgen, maar ook dat individuele producten in deze categorie een middelentoewijzing moeten krijgen die 5-10 procent onder de groeisnelheid ligt. Dat betekent dat als het product met 5 procent per jaar groeit, dit nog steeds kan betekenen dat de beschikbare middelen gelijk blijven of elk jaar krimpen.

Horizon 2 houdt zich bezig met de bewezen, snelgroeiende producten die de ambitie hebben om toekomstige H1-producten te worden. Dit deel van het bedrijf zou 20 procent van de middelen moeten krijgen en de toewijzing van middelen aan individuele producten kan en moet waarschijnlijk sneller groeien dan de omzetgroei om dingen te versnellen.

Horizon 3 houdt zich bezig met nieuwe innovatieconcepten die nog niet bewezen zijn. Dit deel van het bedrijf zou 10 procent van de middelen moeten krijgen en deze middelen worden toegewezen aan het uitvoeren van experimenten met klanten met de bedoeling om levensvatbare opties te vinden. In [eerdere columns](https://janbosch.com/blog/index.php/2017/02/05/innovation-is-hard-work/) heb ik beschreven hoe dit naar mijn ervaring moet worden georganiseerd.

Het belangrijkste is te beseffen dat elke organisatie minstens 10 procent van de totale middelen aan innovatie moet besteden. Een manier om die middelen toe te wijzen is door werknemers ongestructureerde tijd voor innovatie aan te bieden. Zo kan iedereen die dat wil 10 procent van zijn tijd gebruiken voor innovatie-inspanningen zonder dat daar toestemming voor nodig is van een manager. Deze uren kunnen worden gebruikt om teams samen te stellen van mensen die allemaal hun 10 procent gebruiken om een bepaalde innovatie te onderzoeken. In [dit artikel] (https://janbosch.com/blog/index.php/2017/10/13/the-end-of-innovation-as-we-know-it/) geef ik meer details.

Concluderend is het combineren van innovatie en operatie moeilijk, maar ook essentieel om het voortbestaan van het bedrijf te garanderen. We moeten vandaag overleven en een levensvatbare toekomst garanderen. Hoewel iedereen dit conceptueel begrijpt, is mijn ervaring dat in de meeste bedrijven deze twee bedrijfssystemen conflicteren, waarbij de investering in innovatie vaak het slachtoffer is. Dus denk hier eens over na: ondanks al het gepraat over innovatie, voert uw organisatie echt innovatie door, beschermt ze die en laat ze uit haar innovatie-inspanningen nieuwe bedrijven groeien? Of zijn het alleen maar ‘feel good’ praatjes?

Als onderdeel van het onderzoek in het Software Center werk ik samen met tientallen bedrijven op het gebied van software-intensieve embedded systemen aan verschillende onderwerpen. Een van deze onderwerpen is de ontwikkeling van nieuwe producten. Omdat ik zowel met online bedrijven als startups heb gewerkt, ben ik geïndoctrineerd geraakt in de ideeën van Steve Blank en de “lean startup” concepten. Een van de basisprincipes is dat je bij elke stap valideert met klanten. In feite probeer je de hoeveelheid R&D-investeringen tussen klanttestmomenten te minimaliseren. Het tweede principe is om alleen te vertrouwen op wat klanten zeggen als het echt nodig is, maar waar mogelijk te vertrouwen op het meten van hun gedrag.

In de embedded systemen industrie zijn bedrijven om de een of andere reden extreem terughoudend om met klanten te valideren voordat het hele product is gebouwd. In de loop der jaren heb ik verschillende redenen gehoord waarom dit zo is. De belangrijkste zijn onder andere: “We kunnen klanten niets anders laten zien dan een compleet product”, “We beschadigen het bedrijfsmerk als we een vroeg prototype laten zien”, “Dit idee is zo goed dat ze het zullen kopen als we het alleen maar bouwen”, “Experimenteren met klanten laat ons eruit zien als idioten omdat het lijkt alsof we het niet weten”, “Dit spul is geheim en we willen de concurrentie niet tippen”, “Het is zo moeilijk om dit in het hele bedrijf te organiseren omdat ik met iedereen moet coördineren.”

Het gevolg hiervan is dat bedrijven de neiging hebben om, zoals een van mijn collega’s zei, minimaal levensvatbare olifanten (MVE’s) te bouwen in plaats van minimaal levensvatbare producten (MVP’s). Wanneer ik mensen hiermee confronteer en we voorbij de ‘excuses’ komen, lijkt het mij dat er ten minste drie fundamentele oorzaken zijn voor dit fenomeen.

Ten eerste vestigden de meeste bedrijven zich en werden succesvol door mechanische en elektronische producten te bouwen. Vanwege verschillende redenen, niet in de laatste plaats de noodzaak om productiefaciliteiten op te zetten, zijn de ontwerpprocessen voor atomaire producten van oudsher erg waterval- en specificatiegericht. Met de komst van additive manufacturing en rapid prototyping hardwarefaciliteiten is dit natuurlijk aan het veranderen, maar de traditionele benaderingen zijn nog steeds wijdverspreid. Het is belangrijk om te beseffen dat het bouwen van innovatieve digitale producten een fundamenteel ander proces vereist dan het bouwen van fysieke producten. In feite is het gebruik van het traditionele proces een recept voor een ramp, omdat je blind vliegt en je beslissingen baseert op de overtuigingen van jou en de anderen in je bedrijf – overtuigingen die bijna zeker verkeerd zijn.

Ten tweede, vooral bij de ontwikkeling van nieuwe producten, maken ingewikkelde interne politieke processen en spelletjes vaak deel uit van de vergelijking. Als gevolg daarvan verschuift de aandacht van de klant en het bedrijfsecosysteem naar het interne politieke landschap. De mensen die betrokken zijn bij de ontwikkeling van het nieuwe product moeten vaak compromissen sluiten met verschillende krachten binnen het bedrijf. Dit zorgt ervoor dat functionaliteit wordt toegevoegd of gewijzigd onafhankelijk van de werkelijke feedback van de klant, maar op basis van de meningen van HIPPO’s. In het ergste geval resulteert dit in nieuwe producten die in de praktijk een Zwitsers zakmes zijn dat veel kleine dingen kan doen, maar niet dat ene belangrijke probleem oplost dat de aanzet gaf tot de productontwikkeling.

Ten derde zien veel mensen de ontwikkeling van nieuwe producten als een eenmalige kans die we meteen goed moeten doen. Dit heeft natuurlijk te maken met de moeilijkheid om mechanische en elektronische producten te veranderen na de start van de productie. Digitale aanbiedingen zijn echter vergelijkbaar met een gesprek: constante updates zijn goedkoop, je kunt meten hoe klanten reageren en worden in feite door veel klanten verwacht.

Het bouwen van digitale producten die ook mechanische en elektronische componenten bevatten vereist een andere kijk op de prioriteiten en het proces. Ten eerste, stel de probleem/oplossing-fit vast door eenvoudigweg veel tijd door te brengen met de beoogde klanten, ruim voor enige R&D-inspanning. Ten tweede, stel de product/markt-fit vast door het beoogde oplossingsconcept aan klanten te presenteren en de fit te valideren, evenals hun bereidheid om te betalen. Ten derde, bouw de meest schraperige, snelste, kleinste realisatie van het product die validatie op kleine schaal mogelijk maakt. Hier ga je over van het meten van wat klanten zeggen naar wat ze daadwerkelijk doen. Ten vierde, bouw een iets geavanceerder prototype van het product dat op grotere schaal gevalideerd kan worden.

Natuurlijk wordt elk van deze stappen iteratief uitgevoerd en ga je pas verder met de volgende stap als de feedback die je van klanten hebt gekregen dat rechtvaardigt. In de praktijk betekent dit vaak dat de mechanische en elektronische onderdelen van het product overgedimensioneerd zijn qua specificaties om een grotere ‘ontwerpruimte’ van mogelijkheden voor het digitale deel mogelijk te maken.

Concluderend, het innoveren van digitale aanbiedingen is moeilijk voor bedrijven die embedded systemen maken en het resultaat is vaak een ‘minimale levensvatbare olifant’ die geen feedback van klanten krijgt tot na de start van de productie. Richt je in plaats daarvan uitgebreid op het verzamelen van klantfeedback gedurende het hele innovatieproces en op klantgedrag waar dat mogelijk is. Uiteindelijk is het de klant die bepaalt of u succesvol zult zijn.