Als je als ISV overstapt van een legacy-applicatie naar een SaaS-applicatie, gaat je organisatie op een vijftal vlakken een transformatie door: Strategie, Financieel, Organisatie, Go To Market en Technologie. In deze vijfdelige reeks nemen we deze vlakken onder de loep. De vlakken overlappen elkaar wel deels of de één heeft impact op de ander, dus je kunt ze niet echt zien als vijf afzonderlijke gebieden. Maar ze hebben ieder hun eigen vragen en onderwerpen om rekening mee te houden.
Dit artikel gaat in op de organisatiewijzigingen en de keuzes die een ISV moet overwegen bij de overgang van een legacy-applicatie naar een SaaS-applicatie in de public Cloud. Ik raad je aan om ook het ISV-playbook van Microsoft te bekijken. Ze behandelen veel van de transformatievlakken aan de hand van diepgaand onderzoek, wat kan helpen de juiste beslissingen te nemen.
Organisatie
Nadat we de onderwerpen strategisch en financieel hebben behandeld gaan we nu dieper in op hoe je je organisatie kunt voorbereiden voor de switch naar de publieke cloud. Want als je er over na nadenkt dat vroeger applicaties op een pc werden geïnstalleerd en daarna vanuit client-server beschikbaar werden gesteld, verandert er best veel. Overigens zijn eindgebruikers al geruime tijd gewend om met Software as a Services (SaaS) applicaties te werken. Denk alleen maar aan e-mail, wat vanaf begin af aan tot ons kwam via het web. Weliswaar gehosted vanuit lokale datacenters, maar toch. Of kleding bestellen. Waar we vroeg belde met Jimmy, als voice-response systeem, is dat nu natuurlijk via de app of het web. Dat betekent dat er van jouw organisatie als je transformeert minimaal hetzelfde wordt verwacht. Je bent altijd aanwezig (zowel technisch als organisatorisch), er is minder tolerantie voor fouten en downtime, eindgebruikers verwachten constant nieuwe functionaliteiten en verwachten snelheid en een goede performance. Dit klinkt misschien als veel en intensief, maar biedt ook enorme kansen. Laten we ze stuk voor stuk wat uitdiepen.
Altijd beschikbaar – Customer service
De techniek hieronder is al in meerdere artikelen beschreven, dus deze keer houden we ons bij de organisatorische kant van het altijd beschikbaar zijn. Je kiest een publieke cloud dienst die je de juiste SLA biedt met de juiste configuratie, dan heb je het technisch zo goed als afgedekt. Daarnaast heb je nog een support afdeling of een customer service afdeling, je eindgebruikers verwachten onmiddellijke reactie dan wel een juiste verwijzing hoe ze hun eigen problemen kunnen oplossen. Dat betekent dat je dus een oplossing moet hebben voor het altijd beschikbaar zijn voor je eindgebruikers. En misschien is dit onder kantoor tijden geen probleem. Dit wordt complexer als jouw SaaS oplossing ook buiten onze tijdzone wordt gebruikt. Tegenwoordig is het relatief eenvoudig om chatfunctionaliteiten af te nemen, al dan niet met AI geïnjecteerd, die je eindgebruikers te woord staan of naar de juiste informatie wijzen. Afhankelijk van het soort applicatie dat je hebt, is het één beter dan het ander. Daarnaast is het mogelijk om middels een derde partij een 24 x 7 telefoondienst op te zetten die de meest voorkomende vragen kan beantwoorden. Of die een telefoonboom kan afbellen op het moment dat problemen zich voor doen, van welke aard dan ook.
De impact van het niet beschikbaar zijn is ook vele malen groter. Waar er vroeger één klant tegelijkertijd uitlag, zijn nu alle klanten down als je het technisch niet goed regelt. Ben je qua communicatie hier op voorbereid? Er zijn bedrijven om minder failliet gegaan denk ik. Dus vanuit organisatie wordt het goed stroomlijnen van communicatie bij downtime en andere calamiteiten van cruciaal belang wil je het in de ogen van de eindgebruiker goed doen.
Minder tolerantie voor fouten vs hogere verwachting nieuwe functionaliteiten
Aangezien je in de ogen van de eindgebruiker ook redelijk snel weer bent ingewisseld voor een andere SaaS leverancier is relevant blijven van levensbelang geworden. Als een goede performance en 100% beschikbaarheid als vanzelfsprekend worden beschouwd, kun je je onderscheiden door een fantastische user experience en door met grote regelmaat nieuwe functionaliteiten beschikbaar te stellen. Als je gebruikers invloed geeft binnen je bedrijf op de user experience kun je ook consequent werken aan verbeteringen vanuit hun wensen en behoeftes. Dat zal je geliefd maken. Een van de grote voordelen van werken met de publieke cloud en bijvoorbeeld DevOps is dat je constant nieuwe updates kan pushen en staging on the fly kan swappen voor productie zonder dat eindgebruikers het merken. Wij hebben klanten die van 2 keer per jaar updaten naar 5 keer per dag gaan. Bedenk de snelheid die dit met zich meebrengt, het gemak van terugrollen is ook groter en de impact is kleiner. Kortom je bent veel beter in staat om snel nieuwe functionaliteiten uit te brengen, te testen en als het niet goed gaat terug te rollen. Dit maakt dat je niet alleen hoge ogen gooit bij de eindgebruikers, het maakt ook dat je de concurrentie op die manier kunt voorblijven. Dus van het feit dat eindgebruikers steeds meer verwachten en weinig tolerantie meer hebben voor fouten, kun je een voordeel maken door steeds sneller gecontroleerd nieuwe functionaliteiten naar de markt te brengen.
Snellere time to market
Als je dan sneller functionaliteiten kunt uitrollen is een bijkomend voordeel dat je sneller meer klanten kunt aansluiten. Doordat je in de publieke cloud werkt hoef je klanten niet per stuk af te gaan, maar je hebt één plek waar je al je klanten aansluit. Of je dat nu wel of niet multi-tenant doet, maakt op zich niet zo veel uit. Wij hebben een klant die voor de implementatie elk van zijn klanten tot een aantal jaar geleden per stuk afging. Hou er organisatorisch ook rekening mee dat je dit dan ook moet doen bij elke update. Nu wordt een nieuw klant in het CRM systeem geregistreerd, er wordt een webhook afgetrapt en bij ons start automatisch een deployment op Azure. Time to market nu? 10 minuten. 1,5 jaar geleden was dat 2 weken. Je kunt dus door automation en autodeploy in Azure met hetzelfde aantal mensen meer klanten aansluiten en dat ook sneller doen. Wat een positief effect heeft op je marge en je omzet, wat broodnodig is, omdat wijzigen van licentiemodel geld kost, zoals we hebben besproken in het artikel over het transformatievlak financieel.
Samenvattend
Het is organisatorisch best uitdagend om van een on-prem, legacy applicatie naar de publieke cloud te gaan. Maar als je een dergelijke verandering langzaam introduceert, biedt het ook veel kansen om juist je eindgebruikers meer in de watten te leggen. Mijn advies? Automate, automate, automate en “under promise, over deliver”.
Verder lezen over transformatievlakken voor ISVs?
Dit artikel is onderdeel van een serie over transformatievlakken bij de overstap naar de Cloud. Wil je weten wat de transformatie naar de Cloud op Go to market vlak inhoudt? Schrijf je dan in voor onze Intercept Insights.