PaaS, KaaS, IaaS. het zijn allemaal benamingen voor een SaaS service. Maar hoe reken je af, en, nog veel belangrijker, hoe zorg je dat het ook voor de klant weer transparant wordt, zodat ook de klant kan zien wat het op kan leveren? Want de klant zal het worst wezen hoe het beestje heet, als het voor hem maar beter en goedkoper wordt.
De ict-sector heeft het weer voor elkaar! Er is een buzzword gecreëerd en omdat we allemaal een eigen saus willen gooien over een inmiddels ingeburgerd concept zien kreten als PaaS, KaaS en IaaS, naast het bekende SaaS, het licht. Het Elektronisch Patienten Dossier (het EPD) dreigt hetzelfde lot te ondergaan. Men maakt tegenwoordig zoveel electronische dossiers aan met verschillende inhoud dat het in de wandelgangen al ExD als afkorting heeft gekregen.
Ik verwacht dat het recentelijk geïntroduceerde concept "Software plus Services" hetzelfde lot zal ondergaan. Het woord software in de term zal ongetwijfeld vervangen worden door een ander woord dat een bepaalde service moet onderstrepen en die het voor de klant duidelijker moet maken.
En zo maken we ons allemaal druk om vooral een nieuwe kreet te bedenken die de afnemer aanspreekt op diensten die geleverd worden. Maar hoe ga je het business model omgooien dat er ook verdiend gaat worden? En hoe maak je dat zo transparant mogelijk voor de afnemers? In mijn rondgang door XaaS-land blijkt dat bitter weinig (ict-)dienstverleners van het SaaS maturity model gehoord hebben, terwijl dat juist een essentieel element is om een succesvol verdienmodel neer te kunnen zetten. Ik durf bijna de stelling aan dat als je hoger in het maturity level terecht komt, er meer te verdienen valt voor zowel de software-ontwikkelaar als voor de SaaS hoster, terwijl er voor de klant ook meer financieel voordeel te behalen valt.
De volgende maturity levels zijn te onderscheiden:
- Iedere keer wordt de appliatie opnieuw neergezet voor iedere nieuwe klant
- hetzelfde als 1, maar nu worden meer onderdelen gedeeld en middels configuratie specifiek gemaakt, onderhoud door leverancier/ontwikkelaar is nog nodig
- In dit model spreken we van multi tennancy, de gebruiker kan zelf de configuratie parameters instellen, de leverancier/ontwikkelaar pleegt bijna geen onderhoud meer
- hetzelfde als level 3 maar dan scalable
Het afrekenen van XaaS oplossingen kan op diverse wijzen plaatsvinden; denk maar eens aan het standaard SaaS-afrekenmodel: afrekenen aan de hand van gebruik van applicaties per maand per gebruiker. Alleen al over het bijhouden hiervan kan men zich aardig het hoofdbreken. Nee, dan kan je ook nog variaties hiervoor bedenken: afrekenen per gestarte applicatie, of, in geval van (electronische) dossiers, afrekenen per geopend dossier. Er zijn enorm veel varianten te bedenken die ervoor zorgen dat er weer serieus geld te verdienen is in de SaaS-sector. De uitdaging is het dan voor de aanbieder om dit proces vorm te geven en hier de klant zo transparant mogelijk inzicht in te geven. Tegelijkertijd maakt dit het TCO-model van de CIO enorm diffuus of de CIO moet een enorm goed inzicht hebben op wie binnen het bedrijf welke applicaties/dossiers gebruikt of nodig heeft voor het uitoefenen van zijn of haar functie. En wie bepaalt dat dan?
De truc voor de aanbieder zit hem erin het afrekenmodel voor de klant zo transparant mogelijk te maken om de TCO te kunnen berekenen. Met name daar zou de focus van de ict-sector moeten liggen. Ik zou zowel als aanbieder als klant het liefste een goed afrekenmodel hebben in plaats van mij druk te moeten maken over welke Service nu weer een nieuwe naam heeft gekregen…..of hoe ik mijn nieuwe service naar de markt zou moeten noemen. Ik hoop dat we met de verdere introductie van Software plus Services ons weer gaan concentreren op waar het uiteindelijk om gaat: het neerzetten van een succesvol en transparant verdienmodel.
