Usage-based billing: van verbruiksdata naar factuur.

Waarom verbruiksfacturatie bij MSP's misgaat.

De techniek is niet het probleem. Elk van deze platforms geeft verbruiksgegevens terug. Het probleem is dat de facturatie maandelijks gebeurt en de meting continu. Wie een keer per maand het verbruik ophaalt, meet een momentopname en factureert die alsof het de hele maand gold: een afnemer die halverwege de maand capaciteit afschaalt betaalt te veel, en een afnemer die opschaalt en aan het eind weer afschaalt betaalt te weinig. In beide gevallen klopt de factuur niet en in beide gevallen kost dat een gesprek.

Het tweede probleem is herleidbaarheid. Als een afnemer vraagt waarom zijn factuur deze maand hoger is, moet je dat kunnen laten zien. Niet met een totaal, maar met de dagen en de bronnen waaruit dat totaal is opgebouwd.

Verbruiksdata ophalen uit drie bronnen.

VMware vCloud Director is het platform waarmee een provider virtuele infrastructuur uitgeeft aan meerdere afnemers naast elkaar. Het houdt bij welke organisatie welke virtuele datacenters, machines, opslag en netwerkcapaciteit gebruikt, en is daarmee de bron voor het compute- en opslagdeel van de factuur. De uitdaging is de indeling: verbruik hangt aan organisaties en virtuele datacenters, en die structuur moet overeenkomen met hoe je administratie de afnemer kent.

Cohesity is een platform voor databeheer en back-up. Het weet hoeveel data er van welke bron is beschermd, hoeveel opslag dat na deduplicatie kost en welke back-upjobs zijn uitgevoerd. Hier ontstaat een keuze met financiele gevolgen: factureer je op brutodata of op werkelijk verbruikte opslag na deduplicatie? Beide zijn verdedigbaar, maar het verschil is aanzienlijk en het moet in het contract staan voordat de eerste factuur eruit gaat.

Zerto verzorgt replicatie en disaster recovery. De relevante eenheid is meestal het aantal beschermde virtuele machines en de replicatiecapaciteit die daarvoor wordt gebruikt. Zerto meet dus in een andere eenheid dan de andere twee, en dat is precies waarom dit een koppelingsvraagstuk is en geen rapportagevraagstuk.

Van ruwe data naar factuurregel.

Drie bronnen, drie eenheden, drie manieren om een afnemer te identificeren. De factuur kent maar een afnemer en een regel per dienst. Daartussen zit de kern van dit systeem: een laag die per bron de identificatie normaliseert naar de afnemer zoals je administratie hem kent, de eenheden omrekent naar de eenheid uit het contract, en het dagelijkse verbruik aggregeert naar een factuurperiode. Dat is precies wat middleware doet. Wat eruit komt is een factuurregel met daaronder een spoor naar de dagen en de bronmeting waaruit hij is opgebouwd. Die herleidbaarheid is niet netjes maar noodzakelijk, want zonder spoor is elke vraag over een factuur een handmatig onderzoek.

Waarom dagelijkse ingest en niet maandelijks.

Dagelijks meten lost drie problemen in een keer op. Het maakt de factuur juist, omdat je verbruik per dag optelt in plaats van een momentopname te vermenigvuldigen: wie op de vijftiende afschaalt betaalt vijftien dagen het hogere tarief en de rest het lagere. Het maakt fouten klein, want valt een bron een dag uit, dan mis je een dag en niet een hele maand, en kun je die dag gericht opnieuw ophalen of, als dat niet meer kan, expliciet interpoleren en dat vastleggen. En het maakt de factuur uitlegbaar, omdat je bij een vraag de dagen kunt laten zien in plaats van een totaal te moeten verdedigen.

Hoe Cube dit gebouwd heeft.

Cube bouwde dit systeem met een dagelijkse ingest uit de drie genoemde bronsystemen en een pay-as-you-go facturatie die daar bovenop draait. Verbruik uit drie platforms komt daarmee samen op een factuur, per afnemer, met een spoor terug naar de dagmeting. Het is het enige traject waarin drie bronsystemen, een normalisatielaag en een financieel proces in een keten zitten, en dat maakt de foutafhandeling zwaarder dan bij een gewone API-koppeling: bij facturatie is er geen ruimte voor stille fouten.

Wanneer usage-based billing niet de juiste keuze is.

Bij een klein aantal afnemers met stabiel verbruik levert dit model niets op. Je bouwt een meet- en normalisatieketen om facturen te maken die je met een vaste prijs per maand net zo goed had gekregen, en je hebt er een systeem bij om te onderhouden. Bij een bronsysteem is het meestal ook niet nodig, want veel platforms hebben eigen rapportage die je met een export naar de boekhouding krijgt: het rendement zit in het samenbrengen van meerdere bronnen. En bij onvoldoende contractuele duidelijkheid werkt het tegen je, want als niet is vastgelegd of je op bruto of gededupliceerde opslag factureert en tegen welke eenheid, dan bouw je een systeem dat elke maand een discussie produceert. Leg dat eerst vast, bouw daarna.

Kort samengevat.

Usage-based billing zet gemeten verbruik om in facturen. Bij een managed service provider komt dat verbruik uit meerdere platforms met verschillende eenheden en verschillende manieren om een afnemer te identificeren, en zit het werk in de normalisatielaag ertussen. Dagelijkse ingest maakt de factuur juist, de fouten klein en het resultaat uitlegbaar. Bij weinig afnemers, stabiel verbruik of een enkel bronsysteem is het model niet de juiste keuze.