Een transitie naar de cloud is geen walk in the park. Het betekent competenties aanleren, een nieuwe manier van service delivery richting de interne business en tijdens de migratie, die veel tijd in beslag neemt, ook de huidige omgeving up-and-running houden. Wat te doen om dit in goede banen te leiden?
Bijna elke organisatie waar ik strategisch betrokken ben (geweest) bij dit soort trajecten heeft de ambitie om zelf de benodigde cloudkennis op te bouwen en om zo veel mogelijk van het cloudbeheer zelf te kunnen doen. Bedrijven willen de regie voeren en ook een groot gedeelte van de migratie, en het uiteindelijke beheer zelf uitvoeren. Tegelijkertijd ontbreekt het aan tijd bij de interne it-specialisten. En niet te vergeten bij de diverse product owners van de verschillende domeinen.
Regie voeren
Allereerst moet de organisatie in staat zijn om die regie te kúnnen gaan voeren over het programma en de bijbehorende projecten. De strategie en doelstellingen van de cloudtransitie moeten eerst helder worden. Door middel van strategie en business value workshops uitgevoerd met de belangrijkste (business en it) stakeholders wordt eerst duidelijk gemaakt waarom we de cloudtransitie ingaan, en welke doelstellingen we willen gaan bereiken. Dit kunnen zowel kwantitatieve als kwalitatieve doelstellingen zijn. Het helpt om dit krachtig en beeldend in een infographic te zetten en met het hele betrokken team te delen. Hang het ook als posters aan de muur op kantoor. Dan is voor iedereen helder wat de uitgangspunten zijn. De guiding principles voor de product owners zijn dan duidelijk en dat is belangrijk voor de aanpak en prioritering.
Vervolgens moet de organisatie die verantwoordelijk is voor de transitie en de uiteindelijke doel-omgeving in de cloud vormgegeven worden. Wie heeft wat in de portefeuille en wat zijn de verantwoordelijkheden en taken?
Kennis opbouwen
Natuurlijk is het belangrijk dat externe kennis wordt ingehuurd om zo’n traject te begeleiden. Immers, die hebben het vaker gedaan en kennen de best practices, valkuilen en succesfactoren. Maar de eigen organisatie moet ook de kennis gaan opbouwen op het gebied van cloudservices en delivery van die services richting de business. En tegelijkertijd zijn de eigen it-medewerkers cruciaal bij de overdracht van alle organisatiekennis op het gebied van it richting de externe partij. Zij weten het beste hoe de huidige omgeving in elkaar zit en waarom bepaalde keuzes destijds zijn gemaakt. Veel van deze keuzes zijn ook in de cloud van toepassing.
Tijd vrijmaken
Een aspect dat vaak vergeten wordt, is dat het team dit alles naast de ‘gewone’ werkzaamheden moet oppakken. Dus de huidige omgeving draaiende houden, zelf kennis opbouwen én interne kennis overdragen naar de externe partij, en daarnaast nog eens de nieuw opgeleverde services in de cloud draaiende houden. Dat kost zo 1,5 fte per fte. Dat gaat dus niet. Zeker ook omdat dat betekent dat de externe leverancier, die voor een groot gedeelte afhankelijk is van de input van en vloeiende samenwerking met uw it-medewerkers, hierdoor vertraagd wordt en moeilijkheden krijgt met de resourcing en de deadline van het project.
Om dit zo veel mogelijk te voorkomen:
- Zorg dat er een externe leverancier is aangehaakt die ook (als is het maar tijdelijk of gedeeltelijk) de nieuw opgeleverde services technisch kan beheren in de vorm van een managed services contract. Hier hoeft dan voorlopig even geen eigen aandacht aan te worden besteed;
- Minimaliseer de werkzaamheden aan de huidige it-infrastructuur. Doe alleen het hoognodige nog daaraan, met name op het gebied van security. Hoe langer het transitie traject duurt, hoe groter de kans dat er grotere dingen in de huidige infra opgepakt moeten worden die weer vertragend werken op het cloud transitie traject;
- Zorg dat uw it-medewerkers kunnen focussen en niet te veel tijd kwijt zijn aan randzaken. Blok vaste dagen en uren voor dit cloudtransitietraject. Een goede product owner en scrum master of projectmanager kunnen hierbij ondersteunen en faciliteren;
- Haak niet élke it-medewerker aan in élke vergadering of workshop. Dit kost veel tijd en is meestal onnodig. Bepaal zorgvuldig wie aan wat moet deelnemen. Zorg er voor dat er een communicatieplatform aan het begin wordt opgetuigd waarop de belangrijkste beslissingen worden gedeeld met iedereen, zodat iedereen blijft aangehaakt en betrokken.
- Tot slot: neem signalen van uw eigen it-medewerkers en die van de externen op dit gebeid uiterst serieus. Laat het niet te lang doormodderen en escaleer het tijdig als blijkt dat er niet voldoende tijd kan worden vrijgemaakt voor dit project.
De grootste bottleneck in it-trajecten, en met name cloudtransitietrajecten, is de beschikbaarheid van interne it-middelen. Als dat risico bij de start van het programma of project al bekend is, is het belangrijk om daar gelijk mitigerende maatregelen voor te nemen. Bovenstaande tips helpen daarbij.
Punt 1 in de opsomming blijkt juridisch en beveiligingstechnisch veelal een struikelblok te zijn als bedrijven zelf de benodigde cloud kennis op willen bouwen om zoveel mogelijk het beheer zelf te blijven doen. Want wat betreft het contractuele deel moet je heel goed vastleggen – via een RACI-model – wie uiteindelijk voor wat verantwoordelijk is om achteraf een vingerwijzen in de uitbesteding te voorkomen. De leverancier als ’trusted advisor’ is een optie maar betreffende de regie zul je scherp moeten zijn op de uitbesteding van verantwoordelijkheden want wij van WC-eend kunnen alleen maar adviseren aangaande de strategie en business value want we zijn niet de eigenaar van de business en gaan dat ook niet worden. Ik ben als (enterprise) architect strategisch betrokken geweest bij een groot aantal transitie projecten en het RACI-model helpt je dus om op de man te spelen in plaats van de bal wat wel handig is als je al met te weinig interne IT resources begint maar toch alles zelf wilt blijven doen. Het ‘Too many chief and not enough indians’ van 1,5 FTE per FTE lijkt me namelijk een signaal van de werkvloer welke je niet kan blijven negeren als organisatie want de huidige omgeving draaiende houden betekent in 9 van de 10 gevallen de legacy knuffelen met krimpende budgetten terwijl ondertussen ook Gartner moet bekennen dat lang niet elke workload naar de cloud kan. Want eerder gemaakte (architectuur)keuzen proberen te kopiëren naar de cloud levert maatwerk op wat uiteindelijk heel duur is als ik naar de managed service contracten kijk terwijl de prestaties in deze contracten vaak tegenvallen omdat na verloop van tijd het A-team vervangen wordt door een B-team of nog erger.
ha oudlid, proberen jullie nou een probleem op te lossen, of er paar te maken 🙂 tegen betaling.
doet me denken aan de nette salesmeneer die elke herfst langskomt om aan te bieden voor 2 tientjes te helpen met mijn dakgoot schoonmaken.
na afloop komt een b-team en dat ontdekt altijd dat mijn dak zogenaamd niet deugt en dat dit door hun opgelost moet worden tegen 100 euro per meter.
Dino,
Ik ben eerlijk, elke inspanning kost geld want je kunt alleen 1,5 FTE voor de prijs van 1 doen als je een groot deel van de (beheer)activiteiten automatiseert of de activiteiten naar lagelonen uitbesteed. En de vraag is of je alle activiteiten wel inzichtelijk hebt als je al begint met de organisatorische achterstand van te weinig personeel, een vlucht voorwaarts middels een lift & shift naar de cloud met legacy blijkt overeen te komen met de strekkende meter van herstel via reversed engineering omdat de cloud een kostenmodel van verrassingen achteraf heeft waar de resource efficiëntie geen hoge prioriteit heeft omdat meer strekkende vierkante meters voor de provider interessanter is.