Realistische ROI voor digitale productontwikkeling: waar TAM/SAM/SOM en de financiële prognose elkaar ontmoeten

Beschouw een ROI-berekening als het plannen van een restaurant

Stel: er wordt een restaurant geopend. Dat kan op twee manieren worden benaderd:

De satellietbenadering (top-down): Deze benadering kijkt naar de hele stad en denkt: "Hier wonen 100.000 mensen, iedereen eet twee keer per week buiten de deur, een maaltijd kost gemiddeld $25, dus er is wekelijks $5 miljoen aan restaurantomzet beschikbaar. Als ik daar slechts 1% van pak, verdien ik $50.000 per week!"

De benadering op straatniveau (bottom-up): De redenering luidt: "Mijn restaurant heeft 20 tafels, elke tafel wordt tijdens de avondservice 3 keer bezet, de gemiddelde rekening bedraagt $40, dus op een goede avond verdien ik $2.400. Met $8.000 huur per maand en overige kosten..."

Als deze twee berekeningen niet tot ongeveer dezelfde conclusie leiden over de vraag of het restaurant zal slagen, klopt er iets niet. Hetzelfde principe geldt voor softwareontwikkelingsprojecten.

Het grote geheel: twee verschillende werelden verbinden

De meeste ROI-berekeningen voor software mislukken omdat marktkans (TAM/SAM/SOM) en operationele realiteit (financiële prognoses) als losstaande oefeningen worden behandeld. Het is alsof het marketingteam in een fantasiewereld leeft, terwijl het finance-team zich in doemdenkerij bevindt.

De oplossing is niet nog geavanceerdere modellen. De oplossing is ervoor zorgen dat beide benaderingen met elkaar in gesprek gaan. Zie het als het afstemmen van het gesprek over "we zouden 1% van de markt kunnen pakken" op de realiteit van "dit is wat we elke avond daadwerkelijk kunnen serveren".

Hoe het werkelijk werkt: de gemeenschappelijke basis vinden

Op dit punt verdwalen de meesten in de complexiteit van spreadsheets, maar de eigenlijke methode is verrassend eenvoudig:

Stap 1: breng de brugcijfers in kaart. Zowel de top-downmarktanalyse als de bottom-upfinanciële prognose horen een aantal aannames te delen. Bij softwareprojecten gaat het dan meestal om zaken als:

Hoeveel gebruikers/klanten de organisatie in de loop van de tijd binnenhaalt

Wat de organisatie hen in rekening brengt (prijsstrategie)

Hoeveel het kost om elke klant te verwerven en te bedienen

Stap 2: toets de aannames aan elkaar. Als de top-downanalyse stelt dat het team in jaar twee 10.000 gebruikers verovert, terwijl de bottom-upprognose ervan uitgaat dat met de geplande infrastructuur slechts 3.000 gebruikers aankunnen, is er een cruciale discrepantie aan het licht gekomen.

Stap 3: bereken de overlapzone. Dit is waar beide benaderingen elkaar vinden in wat haalbaar is. In het restaurantvoorbeeld suggereert het satellietbeeld misschien dat 100 gasten per avond binnen bereik liggen, terwijl de analyse op straatniveau laat zien dat er maar 60 bediend kunnen worden. Het realistische doel wordt dan 60 gasten per avond.

Waarom dit echt uitmaakt: wanneer dromen de spreadsheet ontmoeten

Het wordt pas magisch wanneer de Serviceable Obtainable Market (SOM), het realistische deel van de markt dat de organisatie daadwerkelijk kan veroveren, omzetcijfers oplevert die overeenkomen met wat het operationele plan kan realiseren.

Beschouw het zo: als de top-downanalyse aangeeft dat het bedrijf in jaar twee 2 miljoen dollar omzet, maar het bottom-upfinanciële model laat zien dat daarvoor 3 miljoen dollar wordt uitgegeven, dan is het project niet levensvatbaar. Dan is het een dure leerervaring in de maak.

Deze afstemming gaat niet alleen over het voorkomen van rampen. Wanneer beide benaderingen dezelfde richting uitwijzen, is er iets krachtigs blootgelegd: een realistisch pad van de huidige positie van de organisatie naar de plek waar de marktkans zich bevindt.

Het gevorderde inzicht: tijd is de realiteitstoets

Dit is wat succesvolle softwareprojecten onderscheidt van het kerkhof van goede bedoelingen: ze rekenen tijd mee als een randvoorwaarde, niet slechts als een variabele.

Een SOM-berekening hoort een tijdlijn te bevatten die past bij de financiële runway van de organisatie. Als de bottom-upanalyse laat zien dat het geld over 18 maanden op is, terwijl de top-downmarktanalyse ervan uitgaat dat 30 maanden nodig zijn om winstgevend te worden, is er een fundamenteel probleem blootgelegd nog voordat er één regel code is geschreven.

De echte waarheid over financiële modellering

Dit is de misvatting die projecten fataal wordt: denken dat er maanden besteed moeten worden aan het perfectioneren van het financiële model omdat investeerders en VC's gedetailleerde prognoses verwachten, en geloven dat deze berekeningen een sterke voorspellende waarde hebben.

De realiteit? Het afnemende rendement van modelleren treedt vrij snel in. Een eerste model voorspelt de toekomst niet nauwkeurig, maar het dient als een cruciale leidraad om betere beslissingen te nemen. Het is als navigeren met gps. De route kan veranderen op basis van het verkeer, maar een startrichting blijft nodig.

De reden voor deze misvatting is simpel: investeerderspresentaties vragen om gedetailleerde financiële modellen, dus teams gaan ervan uit dat die modellen tot op de komma juist moeten zijn. Maar ervaren investeerders weten dat deze modellen onderbouwde schattingen zijn, bedoeld om het denken te toetsen, en geen glazen bollen.

Een concreet voorbeeld: het interne efficiëntieproject

Stel dat een bedrijf interne software wil bouwen om de kosten van klantenservice te verlagen. Momenteel verwerkt het team 1.000 supporttickets per maand tegen $15 per ticket aan personeelstijd. Dat is $15.000 aan maandelijkse kosten die mogelijk kunnen worden teruggebracht.

Top-downdenken: "Als we 60% van deze tickets automatiseren, besparen we $9.000 per maand, of $108.000 per jaar."

Bottom-upwerkelijkheid: "Het bouwen van dit systeem kost $150.000 en duurt 8 maanden. We hebben 2 maanden nodig om personeel op te leiden en bugs op te lossen. Dus we kijken naar $150.000 vooraf tegenover $54.000 aan besparingen in het eerste jaar (6 maanden van $9.000)."

Wanneer deze cijfers op één lijn liggen, verdient het project zich in ongeveer 20 maanden terug - als alles volgens plan verloopt. Wordt daarbij de realiteit meegerekend dat softwareprojecten doorgaans 50% over budget en planning gaan (bij Eli5 uiteraard niet), dan rekt de terugverdientijd zich plots op tot 30 maanden.

Dit betekent niet noodzakelijk het einde van het project, maar het levert wel eerlijke cijfers op om een eerlijke beslissing te nemen.

Zo werkt het in de praktijk: de ROI-realiteitstoets

Het cruciale inzicht is dit: behandel de ROI-berekening als een gesprek tussen een optimistisch ik en een pessimistisch ik. Het optimistische ik ziet marktkansen en gelooft in efficiënte uitvoering. Het pessimistische ik maakt zich zorgen over kosten, vertragingen en de realiteit van de concurrentie.

Wanneer beide stemmen het erover eens zijn dat een project zinvol is, heeft het team iets gevonden dat de moeite waard is om na te streven. Wanneer ze sterk van mening verschillen, is het team behoed voor een kostbare vergissing.

Het doel is geen perfecte voorspelling. Het doel is een eerlijke beoordeling. Een ROI-calculator hoort het team te helpen betere vragen te stellen: wat zou waar moeten zijn om dit project te laten slagen? Welke aannames zijn het meest bepalend? Waar is de kans het grootst dat we ernaast zitten?

Zo verandert een organisatie softwareontwikkeling van een hoopvolle uitgave in een strategische investering, met de ogen wijd open.