De verborgen operationele kosten van een complex enterprise-platform

Het budget voor een enterprise-platform draait om één getal: de licentiekosten. Over dat bedrag wordt elk jaar onderhandeld, daar kijkt de CFO het scherpst naar, en iedereen weet dat het betaald wordt. Voor de meeste enterprise-organisaties is het ook het kleinste deel van wat het platform werkelijk kost.

De grotere kosten komen nooit op een factuur terecht. Ze lopen stil op. In de dagen dat een campaign wacht tot er een developer vrij is. In de integraties die een team jaar na jaar moet blijven onderhouden. In de roadmap-punten die weer een kwartaal opschuiven, omdat het platform niet zo snel kan als de business wil. Niets hiervan heeft een eigen regel in de begroting. Niets hiervan wordt beoordeeld als het budget wordt vastgesteld. En omdat niemand het kosten noemt, stelt ook niemand er vragen over.

Dit gaat niet over de prijs. Het gaat over het verschil tussen wat je volgens het contract betaalt en wat het je elke dag kost om de operatie draaiende te houden. Zodra je dat verschil ziet, wordt de vraag wat een platform kost een heel andere vraag.

Wat enterprise-teams onder platformkosten verstaan

Komt een platformkeuze ter discussie, dan schuift het gesprek over kosten vanzelf naar de bedragen die goed zichtbaar zijn. Ze staan in een contract, finance kan ze in een spreadsheet doorrekenen, en een inkoopproces is gemaakt om precies zulke bedragen te vergelijken. Het probleem is niet dat die getallen niet kloppen. Het probleem is dat ze maar een deel van het verhaal vertellen, en vanuit het budget zie je dat moeilijk.

De posten die iedereen begroot

De bekende kosten zijn bij de meeste enterprise-organisaties hetzelfde: de licentie of het abonnement, hosting en infrastructuur, een support- of success-pakket en, afhankelijk van het platform, transactie- of verwerkingskosten. Wie op een verouderde enterprise-stack draait, heeft meestal ook een retainer voor development in de begroting staan. Die geldt als vaste kosten van het zakendoen, niet als signaal over het platform zelf.

Die kosten zijn echt, en ze horen in het budget. Het punt is niet dat teams ze vergeten. Het punt is dat deze lijst compleet voelt, en op het moment dat hij compleet voelt, stopt de analyse.

Waarom de factuur het hele verhaal lijkt

Een factuur is een afgesloten document. Er staat een bedrag op, dat bedrag wordt betaald en daarmee is de zaak rond. Juist dat gevoel van afronding maakt een factuur misleidend als maatstaf voor kosten. De factuur van je platform vertelt wat de leverancier rekent. Hij zegt niets over wat het platform van je organisatie vraagt om te kunnen functioneren. Op een complexe enterprise-stack is dat veel.

Voor een Head of eCommerce die het jaarbudget voor het platform opstelt, zijn licentie en infrastructuur bovendien de enige bedragen die je precies kunt noemen. De operationele kosten zijn diffuus. Ze zitten verspreid over teamagenda's, releaseplanningen en uitgestelde plannen, en daardoor voelen ze minder als kosten en meer als de omstandigheden waaronder je nu eenmaal werkt. Dus blijven ze buiten beeld. Niet door onachtzaamheid, maar omdat ze niet passen in de vorm waarin een budget wordt opgesteld.

De vraag die deze kijk op kosten nooit stelt

Er is een vraag waar de gebruikelijke kijk op kosten nooit aan toekomt: wat kost het je organisatie om op dit platform te draaien, bovenop wat de leverancier ervoor rekent? Niet de prijs van het platform, maar de prijs van het werken ermee. Dat is een ander getal, en bij de meeste enterprise-stacks is het het grootste. De rest van dit artikel gaat over waar dat getal zich verstopt en hoe je het zichtbaar maakt.

Wat je aan de operationele kant echt terugziet

Als de factuur de verkeerde plek is om te zoeken, dan is de agenda de juiste. De werkelijke kosten van een enterprise-platform zitten in hoe je organisatie haar tijd besteedt. Op een verouderde stack gaat verrassend veel van die tijd op aan om het platform heen werken, in plaats van ermee. Dat zijn echte uitgaven. Ze worden alleen betaald in uren en uitgestelde plannen in plaats van in euro's, en daarom komen ze nooit in de boekhouding terecht.

Wachten op een developer

Op veel verouderde enterprise-platforms kan het merchandisingteam zelf weinig aanpassen. Een nieuwe landing page voor een campaign, een gewijzigde actie, een seizoensaanpassing in de navigatie: elk daarvan wordt een ticket, en elk ticket sluit aan in de releasewachtrij. Het werk zelf kost een developer misschien een middag. Het wachten eromheen duurt weken.

Dit is de duurste post die de meeste teams nooit meetellen, omdat hij helemaal niet op kosten lijkt. Het lijkt gewoon het normale tempo waarin dingen gebeuren. Kijk wat het in werkelijkheid is: een marketingteam dat niet sneller kan dan de backlog van engineering toelaat. Een eCommerce-manager die campaigns plant rond releasemomenten in plaats van rond de markt. En een afhankelijkheid van developers die zo diep in de dagelijkse gang van zaken zit, dat niemand er nog bij stilstaat. Het platform heeft hier nooit een rekening voor gestuurd. Betaald heb je toch.

Integraties die je eindeloos blijft onderhouden

Een enterprise-organisatie is nooit alleen een webshop. Het is een webshop die gekoppeld is aan een ERP, een PIM, een OMS, een warehousesysteem, een tax engine en alles wat het bedrijf in de loop der jaren verder heeft opgebouwd. Op een verouderde stack zijn veel van die koppelingen maatwerk, en een maatwerkintegratie bouw je niet één keer. Je blijft hem onderhouden zolang hij bestaat.

Elke API die verderop in de keten verandert, elke versie-upgrade, elke nieuwe markt die net een andere datastroom nodig heeft: het levert allemaal onderhoudswerk op aan koppelingen die er al zijn. Dat is het verschil tussen een infrastructuurprobleem en een procesprobleem. Een proces verbeter je één keer en dan laat je het met rust. Infrastructuur moet je in leven houden. De retainer die dit werk stilletjes dekt, zie je wel. Het groeiende deel ervan dat opgaat aan voorkomen dat bestaande koppelingen breken, zie je niet.

Campaigns die te laat live gaan

De eerste twee kostenposten stapelen zich op tot een derde, die lastiger te meten is en zwaarder weegt dan elk van beide. Als elke wijziging op een developer wacht en elke integratie onderhoud vraagt, beweegt de organisatie langzamer dan de business nodig heeft. Campaigns die vóór een piekperiode live hadden moeten staan, gaan live tijdens die piek, of erna. Tests die het volgende kwartaal richting hadden kunnen geven, worden nooit gedraaid. De roadmap wordt niet geschrapt. Hij wordt uitgesteld, telkens met een reden die op zich redelijk klinkt.

Deze kosten worden niet eens met het platform in verband gebracht, omdat ze zich voordoen als een gemiste kans en niet als een uitgave. Een campaign die twee weken te laat start, wordt niet geboekt als platformkosten. Hij wordt hooguit genoteerd als een campaign die tegenviel. Maar die vertraging zat in de structuur, en die structuur was het platform. Zo werkt de operationele rem: een beperking van het platform verandert in iets wat lijkt op een reeks losse uitvoeringsproblemen.

Waarom je deze kosten niet ziet

De kosten zelf zijn nu wel duidelijk. De lastigere vraag is waarom een organisatie ze jarenlang kan dragen zonder ze te benoemen. Dat komt niet doordat enterprise-teams slordig zijn. Het komt doordat drie dingen samen deze kosten uit beeld houden: de manier waarop een budget is opgebouwd, de vorm van een organisatie die in meerdere markten verkoopt, en één geruststellende aanname. Ze zijn elk de moeite waard om los te bekijken, want pas als je het mechanisme ziet, kun je de kosten beoordelen.

Geen eigen regel in de begroting, dus geen beoordeling

Organisaties beoordelen wat ze meten, en ze meten wat ergens vastgelegd kan worden. Licentiekosten hebben zo'n plek: ze staan in een contract, komen op een regel in het budget terecht en worden bekeken zodra die regel aan verlenging toe is. De operationele rem heeft zo'n plek niet. Er is geen veld in het platformbudget met de naam “uren verloren in de releasewachtrij” of “deel van de retainer dat opgaat aan integraties in leven houden”.

De kosten zijn dus niet verborgen in de zin dat iemand ze wegmoffelt. Ze zijn verborgen omdat ze nergens worden vastgelegd, en kosten die nergens staan, gedragen zich alsof ze niet bestaan. Ze komen nooit in een review, worden nooit naast een alternatief gelegd en hoeven zich nooit te verantwoorden. Het ontbreken van een eigen regel is geen klein gat in de boekhouding. Het is precies de reden dat de grootste platformkosten nooit onderzocht worden, terwijl over de kleinste elk jaar wordt onderhandeld.

Hoe meerdere markten de rem verzwaren

Bij een Europese enterprise blijft die rem zelden gelijk, omdat de organisatie zelden eenvoudig blijft. Een merk dat in meerdere landen verkoopt, heeft te maken met btw-regels die per land verschillen, fulfilment over grenzen heen, vertalingen en lokalisatie, en gegevensverwerking die op operationeel niveau aan de AVG moet voldoen, niet als bijzaak achteraf. Op een verouderde stack wordt elk van die onderdelen meestal een eigen integratie, een eigen onderhoudsstroom en een eigen bron van tickets.

Daarom kunnen twee organisaties die dezelfde licentie betalen totaal verschillende werkelijke kosten hebben. Een merk dat in één markt verkoopt en een merk dat acht Europese markten bedient, zitten operationeel gezien niet op hetzelfde platform, ook al zegt het contract van wel. Complexiteit telt niet op bij de rem, ze vermenigvuldigt hem, en Europese organisaties met meerdere markten zitten aan de bovenkant van die vermenigvuldiging. Het contract laat dat niet zien. De agenda wel.

Waarom “het platform is betaald” het verkeerde uitgangspunt is

Onder dit alles ligt één aanname die de kosten beter verstopt dan welk gat in de boekhouding ook: het idee dat het platform betaald is zodra het contract getekend is en de build live staat. Dat is de denkwijze van een aankoop, iets wat je één keer koopt en daarna bezit. Maar een enterprise-platform bezit je niet. Het is een voorwaarde waaronder je werkt, en voor die voorwaarde betaal je doorlopend. Je betaalt met wat je organisatie kan doen, en hoe snel.

Hier draait het hele kostenplaatje om. Een verouderd platform kan juist goedkoop aanvoelen omdat de grootste kosten niet in het contract staan. Ze zitten in de releasewachtrij, de onderhoudslast en de uitgestelde roadmap, en geen daarvan stuurt een rekening. “Het platform is betaald” klopt op de factuur en klopt niet in de praktijk. Pas als je dat beeld vervangt door een eerlijker beeld, namelijk dat het platform je elke dag laat betalen in tempo en capaciteit, worden de verborgen kosten zichtbaar genoeg om te meten.

Zo breng je je eigen operationele kosten in beeld

De kosten benoemen is één ding. Je eigen kosten meten maakt er iets van waar je mee aan de slag kunt, en daar heb je geen speciale tools of consultant voor nodig. De getallen zijn er al. Ze liggen alleen verspreid over plekken waar een budget niet kijkt. Met drie oefeningen breng je ze bij elkaar, en elk daarvan kun je deze week nog doen met informatie die je team al heeft.

Zet de tijd tussen idee en livegang op een rij

Kies een representatieve wijziging uit het afgelopen kwartaal. Een pagina voor een campaign, een actie, een aanpassing in de navigatie, alles waarvan de business besloot dat het live moest. Zet dan de hele tijdlijn op een rij: de datum waarop iemand besloot het te doen, en de datum waarop het echt live stond. Het gaat niet om de uren werk, maar om de afstand in de agenda tussen besluit en uitvoering.

Dat is je doorlooptijd van idee tot live, en geen getal zegt meer over de operationele rem. Doe het voor vijf of zes wijzigingen en er tekent zich een patroon af: hoe lang je organisatie er echt over doet om te bewegen als ze dat wil, en hoeveel van die tijd werk is en hoeveel wachten in een wachtrij. Dat wachten is de kostenpost. Een team dat steeds drie weken tussen idee en livegang ziet, betaalt voor een platform dat maar een fractie haalt van het tempo dat de business vraagt, wat het contract ook belooft over uptime.

Tel de integraties die onderhoud vragen

Maak een lijst van elk systeem waar je webshop mee gekoppeld is: ERP, PIM, OMS, warehouse, belastingen, betalingen, marketingtools, alles met een live datastroom. Markeer welke daarvan maatwerk of half maatwerk zijn, en dus geen standaardkoppelingen met ondersteuning. Schat vervolgens per koppeling hoeveel tijd er het afgelopen jaar in ging. Niet aan iets nieuws bouwen, maar de bestaande koppeling werkend houden bij veranderingen verderop in de keten en versie-updates.

Dat getal is je onderhoudslast, en het verrast vaak, omdat het meestal onzichtbaar opgaat in een retainer voor development die als één bedrag op papier staat. Juist door het uit elkaar te halen zie je het verschil tussen de contractprijs van een platform en wat het kost om ermee te werken. Pak het aan zoals je de volledige prijsopbouw van een platform zou ontleden, waarbij de variabele en doorlopende kosten veel zwaarder wegen dan het bedrag op de prijslijst. De onderhoudspost is zelden de post waarvan teams verwachten dat hij groot is. Op een verouderde stack met jaren aan maatwerkkoppelingen is hij dat vaak wel.

Tel de groei op die je uitstelde terwijl je wachtte

Het derde getal is het lastigst vast te pinnen en het belangrijkst, omdat de andere twee het veroorzaken. Kijk terug op het afgelopen jaar en schrijf op wat het team wilde doen maar niet deed, omdat capaciteit of snelheid ontbrak en niet omdat de strategie iets anders vroeg. Tests die niet zijn gedraaid. Markten die niet zijn geopend. Features waar het eCommerce-team op zat te wachten. Campaigns die te laat of helemaal niet live gingen.

Een precies bedrag in euro's krijg je hier niet, en dat hoeft ook niet. De lijst zelf is het bewijs. Het is de uitgestelde roadmap zwart op wit, en hij beantwoordt de vraag waar de gebruikelijke kijk op kosten niet aan toekomt: niet wat het platform kost om te draaien, maar wat het draaien erop je kost aan groei die je nooit hebt binnengehaald. Kan een team deze lijst snel vullen, dan kijkt het naar de werkelijke prijs van zijn platform. Die prijs staat nergens op de factuur.

Wat het echte kostenplaatje verandert

Drie getallen samen veranderen het gesprek. Zodra je je doorlooptijd, je onderhoudslast en je uitgestelde roadmap ziet, is het platform geen vaste post meer waarvoor je hebt getekend. Het wordt een variabele post die je doorlopend betaalt. Die verschuiving klinkt klein. In de praktijk verandert ze welke vraag je stelt, en de vraag die je stelt bepaalt welk besluit je uiteindelijk neemt.

Van “wat kost het?” naar “wat kost het ons?”

“Wat kost het?” is een vraag over het contract, en het contract geeft een helder antwoord. “Wat kost het ons?” is een vraag over de operatie, en die heeft een ander antwoord, meestal een hoger. De eerste vraag komt op tafel bij de verlenging en is in een middag beantwoord. De tweede wordt zelden gesteld. Daarom blijven organisaties op platforms die ze stilletjes afremmen, lang nadat de rekensom al tegen de afspraak is gekeerd.

Daar dient het meten van die drie getallen voor: van de eerste naar de tweede vraag komen. Het zegt je niet dat je iets moet veranderen. Het zegt je wat je werkelijk betaalt, zodat elk besluit over het platform uitgaat van het echte bedrag en niet van het bedrag in het contract. Voor de meeste enterprises is een platformkeuze een verbintenis van vijf tot zeven jaar. Wie die verbintenis aangaat op basis van het verkeerde kostengetal, wordt verrast door een platform dat betaalbaar leek en het duurste bleek van alles wat de organisatie draaiende hield.

De vergelijking die je hierna maakt

Zie je wat je huidige platform echt kost, dan volgt de volgende vraag vanzelf: hoe verhouden die werkelijke kosten zich tot een alternatief, op dezelfde manier gemeten? Daar gaan de meeste platformevaluaties de mist in. Ze zetten licentie naast licentie en noemen dat een analyse. De eerlijke versie zet operationele kosten naast operationele kosten: doorlooptijd naast doorlooptijd, onderhoudslast naast onderhoudslast, en het tempo dat elk platform de business echt toestaat.

Die vergelijking kost meer moeite, en het is de vergelijking die een besluit oplevert waar je de hele contractduur achter kunt blijven staan. Wil je zien hoe dat uitpakt bij een concrete keuze, een modern enterprise-platform tegenover de verouderde stacks waar de meeste enterprises op draaien, dan is een eerlijke vergelijking van Shopify Plus met verouderde enterprise-platforms de logische volgende stap. Het gaat er niet om welk platform wint. Het gaat erom dat de vergelijking pas iets betekent als je beide kanten meet aan wat ze kosten in gebruik, niet aan wat ze vragen bij het tekenen.

Die vergelijking goed maken en daarna uitvoeren wat eruit komt: precies dat werk doet ons eCommerce-bureau voor klanten die voor deze keuze staan.