De run-rate, niet de projectprijs: wat software echt kost over vijf jaar

Zet twee bedragen naast elkaar. Het ene staat vetgedrukt onder een offerte: de prijs van de bouw, eenmalig, betaald in het eerste jaar. Het andere staat nergens op één regel, en toch keert het elke maand terug zolang het systeem draait. Directies tekenen op het eerste bedrag en leven jaren met het tweede. Dat is de verkeerde volgorde.

Het bedrag dat telt, heet de run-rate: de vaste last die elke maand terugkomt tot iemand het systeem uitzet. Bij software die u per gebruiker huurt, groeit die last mee met uw personeel. Neemt u tien mensen aan, dan stijgt de factuur, of die tien de duurdere modules nu openen of niet. De uitgave hangt aan uw omvang, niet aan wat de software u oplevert. En omvang is precies wat een groeiend bedrijf elk jaar meer van heeft.

Wat per gebruiker echt kost over vijf jaar

Neem een concreet tarief. Microsoft rekent voor Dynamics 365 Finance 210 dollar per gebruiker per maand, en 300 dollar voor de Finance Premium-variant. Zet daar vijftig mensen op: 210 dollar, keer vijftig, keer twaalf maanden, en u zit aan 126.000 dollar per jaar, nog voor er één euro implementatie bij komt. En de implementatie zelf loopt doorgaans van 250.000 tot meer dan 1,5 miljoen dollar. Dat maandbedrag is dus niet het begin van de rekening. Het is het deel dat nooit meer stopt.

Rek dat uit over zestig maanden en het plaatje kantelt. Vijftig gebruikers aan 210 dollar is over vijf jaar 630.000 dollar aan licenties alleen, zonder implementatie, zonder indexatie, zonder de nieuwe mensen die u ondertussen aanneemt. Elk hoofd dat erbij komt, tikt zijn eigen maandtarief aan de teller. De eenmalige bouwprijs die u zo hoog vond, wordt op die tijdlijn een van de kleinere posten.

Het lek dat nog niet in de som zit

En dan betaalt u nog voor stoelen die leegstaan. Het Flexera 2024 State of ITAM-rapport becijfert dat organisaties 20% tot 30% van hun IT-uitgaven verspillen, en dat meer dan de helft van de SaaS-licenties niet wordt gebruikt. In een model per gebruiker is dat geen randgeval maar de kern van de constructie: de factuur telt koppen, geen gebruik. Iemand vertrekt, de stoel blijft in de telling staan. Een afdeling koopt licenties voor een project dat na een jaar stilvalt, en de uitgave loopt gewoon door. U betaalt voor toegang, niet voor waarde.

Er zit nog een laag onder de licenties: het onderhoud van de systemen die u al draait. Verouderde systemen dragen technische schuld, en die schuld heeft een prijs. McKinsey (2020) schat ze op 20% tot 40% van de waarde van uw volledige technologielandschap, en becijfert dat 10% tot 20% van het budget voor nieuwe producten opgaat aan het wegwerken ervan. Elke euro die daarheen gaat, bouwt niets. Ze betaalt een rekening uit het verleden. Een platform in eigendom draait die logica om: de kost volgt de infrastructuur die u echt draait, niet het aantal namen op een gebruikerslijst.

De projectprijs betaalt u één keer. De run-rate betaalt u tot u het systeem uitzet.

Waar het geld staat over vijf jaar

Wees eerlijk over de andere kant. Een platform bouwen is een echte investering vooraf. U betaalt in het eerste jaar meer dan een maandlicentie kost, en dat geld is weg voordat het systeem één factuur heeft bespaard. Wie doet alsof een bouw altijd meteen goedkoper uitvalt, verkoopt u iets. Het punt is niet het startbedrag. Het is waar het geld staat na zestig maanden.

Zet daarom de twee tijdlijnen naast elkaar in plaats van de twee prijzen. Huren per gebruiker: een lage start, dan een bedrag dat elk jaar terugkeert en meestijgt met elk hoofd en elke indexatie. Bouwen in eigendom: een hogere start, dan een run-rate die de servers en de opslag volgt die u werkelijk gebruikt. Wanneer die twee lijnen elkaar kruisen hangt af van hoe snel u groeit, maar kruisen doen ze, en vanaf dat punt betaalt de huurder elke maand door terwijl de eigenaar vooral infrastructuur betaalt. Wij bouwen dat platform in golven met een go/no-go per stap, zodat de investering vooraf geen weddenschap op één datum wordt, maar een reeks beslissingen die elk hun eigen bewijs vragen.

• Uw factuur volgt servers en opslag, niet het aantal koppen op de loonlijst.
• Groei belast de infrastructuur, niet elke nieuwe gebruiker met een eigen maandtarief.
• De code staat in uw eigen repository, overdraagbaar, zonder licentie die per stoel blijft doortikken.
• Geen leegstaande stoelen in de telling, want er is geen telling per stoel.

De eerste stap is niet bouwen, en het is ook niet tekenen. Het is rekenen. Leg drie getallen naast elkaar: wat u dit jaar aan licenties betaalt, hoeveel van die stoelen echt gebruikt worden, en wat datzelfde model over vijf jaar wordt als uw personeel groeit zoals u het plant. Die drie getallen kent bijna niemand uit het hoofd. Een IT FinOps audit zet ze op papier, tegen een vaste prijs en vendor-neutraal, met een baseline die uw eigen finance mee ondertekent.

Vergelijk daarna geen twee prijzen maar twee tijdlijnen. De vraag is niet wat de bouw kost tegenover de licentie van volgende maand. De vraag is welk model u over zestig maanden armer maakt, en welk model de kost laat meebewegen met wat u draait in plaats van met wie u aanneemt. Wie op de projectprijs staart, ziet de goedkope optie. Wie de run-rate optelt, ziet de dure.