Het SaaS maturity model

Visies > Strategie en Innovatie > Methode > Het SaaS maturity model

Het SaaS maturity model
None

Maurice van der Woude, Organisatie Adviseur, Netherlands

Het SaaS maturity model

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 Electronisch 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 (IT) 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:
1. Iedere keer wordt de appliatie opnieuw neergezet voor iedere nieuwe klant
2. hetzelfde als 1, maar nu worden meer onderdelen gedeeld en middels configuratie specifiek gemaakt, onderhoud door leverancier/ontwikkelaar is nog nodig
3. In dit model spreken we van multi tennancy, de gebruiker kan zelf de configuratie parameters instellen, de leverancier/ontwikkelaar pleegt bijna geen onderhoud meer
4. hetzelfde als level 3 maar dan scalable

Dit model wordt door mij op diverse seminars en workshops nader toegelicht. Indien meer informatie gewenst is, kunt u hier uiteraard contact met mij over opnemen.

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 truuk 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.

Reageer | Meer over de auteur | Meer over dit aandachtgebied

Andere Visies van deze auteur: SaaS voor het MKB | CaaS: Business First! | Zonder innovatie geen differentiatie