*Dit blog is deel 3 van een 4-delige blogserie Scale Up Your Tech Company.
Klik hier om alle 4 artikelen te ontvangen.
Veel software-leveranciers hebben een fors klantenbestand. Speciaal in B2B-applicaties. Traditioneel worden deze klanten bediend met ‘on premise’-projecten. Tegenwoordig zijn SAAS-oplossingen de norm. Hoe maak je als software-leverancier soepel de transitie van ‘on premise’ naar SAAS?
‘On premise’ projecten waren de norm tot een paar jaar geleden.
On premise = de klant kocht software die geïnstalleerd werd op eigen servers van de klant. De implementatie was een project, waarin klant en leverancier beide veel investeerden. Na acceptatie ging het project over in een supportfase met een jaarlijks bedrag. Eventuele wijzigingen werden als nieuw project opgepakt.
Op zich werkte dit prima, omdat klanten ‘custom made’ bediend werden. Elke implementatie was specifiek voor die klant en daarmee waren kleine stukjes maatwerk mogelijk. Veel leveranciers hebben jarenlang (soms wel 20 jaar lang) een prachtig klantenbestand opgebouwd. Daarmee hebben ze hun doodvonnis getekend. Tenzij het ze lukt om de overstap te maken naar het aanbieden van SAAS-oplossingen.
SAAS-oplossingen zijn per definitie standaard voor alle klanten.
SAAS is voor je klanten minder beheer en gedoe, voor jou aantrekkelijk want het model is veel meer schaalbaar.
Maar wat is het probleem?
De kern van het probleem is dat het omzet van de bestaande situatie (‘on premise’) naar de nieuwe situatie (SAAS) technisch, functioneel en financieel complex is, andere mensen vereist, veel tijd kost en leiderschap vraagt tijdens de transitie. Het probleem is groot qua omvang en complexiteit. Maar niets doen is voor de software-leverancier ook geen optie. Het is een keuze tussen het laten doodbloeden van het bedrijf of het bedrijf volledig heruitvinden.
Probleem 1: technisch complex
SAAS-oplossingen vereisen nieuwe technologie, terwijl de traditionele oplossingen vaak geprogrammeerd zijn in een nu verouderde technologie. Omzetting naar een andere technologie (programmeertaal) vraagt een volledige herbouw van de applicatie.
Probleem 2: functioneel complex
De traditionele oplossing is vaak rijk aan functionaliteit. Hoe zet je dat allemaal over? Moet dat allemaal overgezet worden? Traditionele implementaties met veel klantspecifieke wensen zijn bijna onmogelijk om over te zetten naar SAAS. Maar de oude én de nieuwe oplossing in de lucht houden is op langere termijn voor de software-leverancier onhoudbaar. Wat te doen?
Probleem 3: transitie kost veel tijd
Hoe je de transitie ook insteekt, het kost je veel tijd. Denk aan 24 tot 36 maanden. Als het niet meer is, want als je niet de juiste mensen hebt en/of onvoldoende leiderschap toont dan wordt het langer. In die tijd bedien je twee groepen klanten met twee oplossingen. Alsof je tijdelijk twee huizen hebt met dubbele woonlasten.
Probleem 4: andere mensen nodig
Mijn grootste inzicht was destijds dat er nieuwe mensen nodig waren voor de nieuwe oplossing. De oude mensen dachten traditioneel en probeerden precies na te bouwen wat er al was. Daarmee gingen ze voorbij aan de mogelijkheden die de nieuwe technologie bood. Een nieuwe oplossing vraagt nieuw bloed en kan er niet ‘even’ bij gedaan worden door de mensen die de traditionele oplossing hebben gebouwd en in de lucht moeten houden.
Probleem 5: vraagt leiderschap
Het leiderschap bestaat vooral uit het helder nemen van moedige beslissingen en verwachtingen intern en extern goed te zetten en te managen. Leiderschap in dilemma’s en paradoxen. Er komt veel op de leider af die snel en duidelijk moet beslissen. Als het leiderschap onduidelijk is, dan loopt alles uit of van de rails.
Probleem 6: financieel complex
De transitie vraagt een enorme investering. In ontwikkeling en overzetten. Plus het afbreukrisico dat klanten niet mee kunnen of willen gaan. De kosten gaan hier duidelijk voor de baten uit. Dat kan zo maar het fulltime jaarsalaris van twee programmeurs en een part-time project manager zijn voor een periode van 24 maanden. Als je het goed doet. Denk dan aan een investering van minimaal € 250.000. In die transitietijd verkoop je bijna niets meer. Klanten wachten wel op de SAAS-oplossing. SAAS is een ander businessmodel, waarmee de inkomsten minder snel op gang komen. Dus een kwart miljoen out of pocket terwijl de inkomsten teruglopen.
*Dit blog is deel 4 van een 4-delige blogserie ‘Scale Up Your Tech Company’.
Klik hier om alle 4 artikelen te ontvangen.
Een transitie die werkt: een case study
Destijds liep mijn CRM-softwarebedrijf tegen dit probleem aan. Het bedrijf bestond toen al 15 jaar en had een prachtig klantenbestand opgebouwd. Ruim 400 klanten in de bouw- en installatiebranche. Het CRM-pakket INTRAC-CRM was het allerbeste dat er in de markt verkrijgbaar was. De klant kon er werkelijk alles mee (en anders bouwden we dat er wel bij). De situatie was… kansloos. Wat te doen? Dit is wat we deden:
- stap 1: een plan maken. We zetten de data, de eerste datum was 28 maart. We namen 6 maanden ontwikkeltijd. Maar de volgende twee data stonden ook al: 28 september en 28 december.
- stap 2: nieuwe mensen zoeken. We zochten twee nieuwe programmeurs met ervaring in de nieuwste ontwikkelomgeving. Die zetten we aan het werk voor de nieuwe SAAS-oplossing. Ze mochten NIET betrokken worden in de bestaande oplossing (lees: erin gezogen worden).
- stap 3: bestaande klanten benaderen. We benaderden alle klanten en vertelden wat we van plan waren. We communiceerden de precieze data. We boden ze aantrekkelijke overstaptarieven. Beter als ze snel overstapten (en referent wilden zijn) en minder goed als ze liever de kat uit de boom wilden kijken. Klanten met veel maatwerk adviseerden we naar een andere oplossing uit te kijken en deden proactief voorstellen voor alternatieven.
- stap 4: we sloten onze eigen vluchtweg af. We noemden ons eigen poduct INTRAC-CRM Classic en kondigden aan dat we geen nieuwe ontwikkelingen meer zouden uitbrengen.
- stap 5: versie ‘6’ opleveren. We leverden op 28 maart een goede maar uiterst basale versie op. Weinig functionaliteit, maar het werkte goed. Tegenwoodig zouden we dit een MVP noemen. Maar het was een beetje meer, niet veel. De beperkte hoeveelheid klanten die de 6-versie aandurfden waren superenthousiast.
- stap 6: versie ‘8’ opleveren. We leverden op 28 september een complete versie op en die werd goed ontvangen. Compleet? Lees verder wat we leerden.
- stap 7: versie ‘9+’ opleveren. Twaalf maanden na 28 maart, wederom op 28 maart, leverden we de 9+-versie op. Die was helemaal top.
Wat hebben we geleerd tijdens deze transitie?
We leerden in deze transitie het volgende:
de zuigende kracht van de traditionele oplossing was enorm
We moesten vaak ‘nee’ zeggen tegen het bestaande. De zuigkracht van het verleden was enorm.
we hebben uiteindelijk <60% van de ‘oude’ functionaliteit overgezet naar het nieuwe SAAS-platform
Ons eerste plan was 100% (dat was oud denken, zo bleek). Veel functionaliteit was ooit voor een klant ingebouwd, maar die klant was er niet meer.
een beperkt aantal klanten verlieten ons
We haten het om klanten te verliezen en we hopen dat ze elders een betere toekomst hebben gevonden.
ongeveer 80 klanten bleven trouw aan Classic
Om een groot scala aan redenen. We hebben het Classic-programma verkocht aan een oud-programmeur. Daarmee was de transitie compleet. We waren volledig klaar voor toekomst en hadden het verleden goed afgerond.
Een enorm omvangrijk traject, maar noodzakelijk. Het was pompen of verzuipen óf overleven. Het werd Luctor et Emergo.
*Dit blog is een onderdeel van een 4-delige blogserie Scale Up Your Tech Company.
Klik hier om alle artikelen te ontvangen.
