Our expert opinion on cloud.

Zo ontwikkel je een Cloud business case

Geschreven door Bart M. Veldhuis op 22-okt-2020 8:46:01
Volg mij op:

Cloud Business CaseVeel organisaties migreren naar Cloud met financiële motieven. Voor cloudapplicaties betaal je immers naar gebruik én je kan contracten met datacenters opzeggen. De meest gestelde vraag is hier dan ook: "Wat kost een applicatie in mijn datacenter nu, en wat zijn de financiële consequenties van de gang naar Cloud?" Het antwoord wordt verwerkt in een financiële analyse, ook wel de Cloud business case genoemd, en maakt een belangrijk onderdeel uit van de cloudstrategie. Handig, maar het is ietwat kortzichtig. Ja, Cloud kán kosten besparen, maar het grootste voordeel van een cloudmigratie zit ‘m nog steeds in de mogelijkheden om bijvoorbeeld sneller software naar de markt te brengen en de beheerlast te verlagen. Daarom lees je in dit blog hoe je een Cloud business case maakt én hoe je het management van jouw organisatie verder leert kijken dan kostenbesparingen.  

“De rode cijfers in een Cloud business case zijn soms zwarter dan je denkt”

De financiële gevolgen van de verschillende cloudbewegingen

Het doel van de Cloud business case is om inzichtelijk te maken wat de financiële gevolgen zijn van de verschillende cloudbewegingen. Oftewel: wat gebeurt er als ik deze applicatie oppak en naar de Cloud breng? De kosten gaan hierbij niet per se omlaag. Zo kan het gebeuren dat je een applicatie uitzet en in plaats daarvan afneemt als SaaS, waardoor je meer geld kwijt bent omdat je per gebruiker moet gaan betalen. Hierdoor bespaar je echter wel manuren, die je weer kan besteden aan innovatie. En aangezien het juist die innovatie is die jouw organisatie op de lange termijn bestaansrecht geeft, zou je kunnen zeggen dat je wel degelijk kosten bespaart. Daarom zijn de rode cijfers in een Cloud business case soms zwarter dan je denkt.

Breng je applicatielandschap in kaart

De kosten van een cloudbeweging kan je berekenen als je weet wat de ideale landingsplaats is per applicatie. Om die duidelijk te krijgen, raad ik je aan om met een beslisboom te werken. Hiermee deel je applicaties in op basis van twee karaktereigenschappen:

  1. Is de applicatie bedrijfs-kritisch? Ja/nee
  2. Biedt de applicatie een onderscheidend vermogen? Ja/nee

Per applicatie zijn er steeds vier antwoorden mogelijk (wel bedrijfs-kritisch en niet onderscheidend, wel bedrijfs-kritisch en wel onderscheidend, etc.). Op basis van het antwoord zie je snel wat de beste en meest efficiënte landingsplaats is per applicatie. Zo wil je onderscheidende applicaties misschien wel graag in eigen beheer houden, terwijl je de niet-onderscheidende applicaties liever vervangt door SaaS zodat je er minder omkijken naar hebt. De beslisboom helpt je niet alleen om de beste landingsplaats te vinden per applicatie; het helpt je ook in je argumentatie richting het management. Als jij kan verdedigen waaróm je het beheer van die ene applicatie uit handen hebt gegeven, is de kans groter dat je groen licht krijgt. Zolang jouw keuzes bijdragen aan overkoepelende, strategische doelen, zit je goed.

Werk je technical debt weg

Bovenstaande wil overigens niet zeggen dat “Geld keine rolle spielt”. Voordat je een nieuwe landingsplaats kan bedenken voor een applicatie, heb je wel degelijk inzicht nodig in de huidige gebruikskosten van die applicatie. Zo kan je besparen waar mogelijk en geld vrijmaken voor -wederom- die innovatie. Het komt vaak voor dat mensen er tijdens het assessment van hun applicatielandschap achter komen dat applicaties eigenlijk uit kunnen, dat er sprake is van dubbele applicaties of dat applicaties beter kunnen worden vervangen door andere, slimmere applicaties. Daarnaast leent een migratie naar Cloud zich er soms (maar zeker niet altijd) ook voor om technical debt weg te werken. Door de technische “schuld” die je met je meezeult te verkleinen, krijg je meer financiële ruimte voor de zaken die bijdragen aan de innovatiekracht van je organisatie. Bereken daarom per applicatie hoeveel je momenteel betaalt en wat het nieuwe maandbedrag wordt als de applicatie is gemigreerd (of uitgezet en vervangen door SaaS!). Hoe je dit doet, lees je hieronder.   

Bereken de kosten per applicatie

Voor het inzicht in de gebruikskosten per applicatie heb je een financieel model nodig waarmee je verschillende ‘views’ van de kosten maakt. Zo wil je een dwarsdoorsnede kunnen maken van alle kosten die geassocieerd zijn met één applicatie, of een doorsnede van de kosten die gemaakt worden voor één type platform. Bijvoorbeeld: “Wat kost het onderhouden van de Linux-servers in ons eigen datacenter?”

Hoe diep je moet analyseren, hangt af van de toepassing van de applicatie. Over het algemeen geldt dat hoe gedetailleerder het model gevoed wordt met (betrouwbare) informatie, hoe beter de verschillende scenario's te analyseren zijn. Soms is het lastig om verbanden te leggen tussen al deze bronnen van informatie. Je zal moeten vertalen, interpreteren én je aannames moeten valideren. Wat helpt, is om de analyse te visualiseren. Dat kan bijvoorbeeld met ons power BI-model. Hieronder zie je een voorbeeld:

Visualisatie Cloud Business Case

Benodigdheden voor je Cloud business case

Bovenstaand model biedt je houvast tijdens het berekenen van verschillende scenario’s. Maar hoe kom je aan al die informatie? Hieronder heb ik wat voorbeelden van bronnen op een rij gezet:

  • Om de kosten van een server in het datacenter te kunnen vergelijken met die van de Cloud heb je niet alleen alle investeringen en onderhoudskosten van het datacenter nodig. Ook moet je weten welke netto capaciteit dit oplevert.
  • Om te bepalen wat een applicatie kost, moet je onder andere weten welke infrastructuur footprint zo'n applicatie heeft (hoeveel servers, storage, memory en licenties gebruikt die applicatie?).
  • Om de kosten van softwareontwikkeling nauwkeurig te kunnen toewijzen, moet je weten hoeveel uren een ontwikkelaar aan welke applicatie besteedt.

Gebruik benchmarkdata in je voordeel

Gelukkig is het niet per se nodig om medewerkers te vragen te turven hoeveel uren er aan het beheer van een bepaalde applicatie worden besteed. Het is in veel gevallen voldoende om te werken met standaardeenheden zoals een gemiddelde capaciteit van een server. Kijk ook naar de tijd die het kost om een server te beheren. Handige vuistregel: in het eigen datacenter kan één beheerder zo’n 100 servers beheren, in Cloud is dit 400. Ook is er heel veel benchmarkdata beschikbaar; informatie over hoe de kosten eruitzien bij vergelijkbare organisaties. Die benchmarkdata kun je gerust gebruiken om de ontbrekende data aan te vullen. Belangrijker is het dat je niet vanuit je onderbuikgevoel redeneert, maar al je aannames onderbouwt met data.

Hoe bouw je het financiële model op?

Om de boel overzichtelijk te houden, raad ik je aan om de kosten te consolideren tot een aantal lagen en alleen verder in te zoomen als dat nodig is. Het vereiste detailniveau zoals hierboven beschreven is afhankelijk van de toekomstige verdeling van applicaties over de verschillende landingsplaatsen en de gekozen migratiestrategie. Als je een lift-and-shift doet vanuit je eigen datacenter naar Cloud, dan heb je meer details nodig om appels met appels te kunnen vergelijken. Bij het inkopen van een SaaS-product wil je meer aandacht besteden aan de huidige kosten voor technisch applicatiebeheer en softwareontwikkeling, omdat deze bij het SaaS-product komen te vervallen. Om je op weg te helpen, vind je hieronder en in de infographic een aantal lagen waarop je de informatie zou kunnen uitwerken:

  1. Infrastructuur (inclusief beheer)
  2. Software (licentiekosten en onderhoud)
  3. Applicatie-, middleware en databasebeheer (zowel technisch als functioneel beheer)
  4. Softwareontwikkeling (bijvoorbeeld maatwerk, uitbreidingen, onderhoud)

Op deze lagen aggregeer je de informatie uit het detailniveau eronder; zo kan je onderscheid maken tussen bijvoorbeeld het Linux en het Oracle platform of tussen high-performance storage en archief storage.

Schermafbeelding 2020-10-20 om 15.09.12

We zijn er bijna (maar nog niet helemaal)

Om de analyse vervolgens verder uit te werken tot een businesscase moet er een niveau bijkomen: dat van de investeringen (transitiekosten), de nieuwe operationele kosten en de verwachte opbrengsten. In andere woorden: hoeveel moet ik investeren in de transitie en hoe is mijn kostenniveau na de transitie? Pas dan zie je of een cloudmigratie financieel interessant is op de korte én langere termijn. Daarnaast staan er in de cloudstrategie misschien doelstellingen die niet meteen te kwantificeren zijn, maar wel een grote drijfveer zijn voor de transitie. Dit is bijvoorbeeld die innovatiekracht die jullie op de lange termijn veel gaat opleveren, maar op de korte termijn geen zwarte cijfers oplevert. Zolang je de verwachte effecten van de cloudstrategie op dat doel kan onderbouwen, zit je goed.


Voor IaaS en PaaS zijn de nieuwe kosten redelijk eenvoudig te berekenen met behulp van de online calculators zoals bijvoorbeeld AWS en Azure die aanbieden. De transitiekosten (kosten van de migratie zelf) zijn een stuk lastiger te berekenen, maar daarvan ligt de bandbreedte tussen de 2.000 en 3.500 per te migreren server.

Voorkom 'Analysis Paralysis'

Een financiële berekening maken voor je migreert, is een belangrijke voorwaarde voor toekomstig succes. Hou bij het analyseren echter wel steeds in het oog wat het doel is van de analyse; het is zeer verleidelijk om steeds dieper te analyseren, maar dit is niet altijd zinvol. Wie te lang blijft hangen in analyses, loopt het risico op een ‘analysis paralysis’: de situatie waarbij de analyse tot stilstand leidt. Zorg daarom altijd voor balans tussen onderzoek, gezond verstand én je planning.

Aan de slag met jouw business case?

Wil je meer weten over de Cloud business case en de rol die deze speelt in je overall cloudstrategie? Download dan ons gratis e-book!

New call-to-action

 

 

 

Laat een reactie achter!

Onderwerpen: financial analysis, business case