Digitale activa rationaliseren

Cloudrationalisatie is het proces van het evalueren van assets om te bepalen wat de beste manier is om ze in de cloud te hosten. Nadat u een benadering hebt vastgesteld en een inventaris hebt geaggregeerd, kan cloudrationalisatie beginnen. In cloudrationalisatie worden de meest voorkomende rationaliseringsopties besproken.

Bekijk de volgende video voor een snel overzicht van het voltooien van een uitgebreide evaluatie die u helpt bij het plannen en prioriteren van uw migratie-inspanningen.

Traditionele weergave van rationalisering

Het is eenvoudig om rationalisering te begrijpen wanneer u het traditionele rationaliseringsproces visualiseert als een complexe beslissingsstructuur. Elke asset in de digitale activa wordt ingevoerd via een proces dat resulteert in een van de vijf antwoorden (de vijf Rs van rationalisering). Voor kleine estates werkt dit proces goed. Voor grotere estates is dit inefficiënt en kan dit leiden tot aanzienlijke vertragingen. Laten we het proces eens bekijken om te zien waarom. Vervolgens presenteren we een efficiënter model.

Inventaris: Een grondige inventarisatie van assets, waaronder toepassingen, software, hardware, besturingssystemen en metrische gegevens over systeemprestaties, is vereist voor het voltooien van een volledige rationalisering met behulp van traditionele modellen.

Kwantitatieve analyse: In de beslissingsstructuur zijn kwantitatieve vragen de basis voor de eerste beslissingslaag. Veelvoorkomende vragen zijn onder andere:

• Wordt de asset momenteel gebruikt?
• Zo ja, is deze dan goed geoptimaliseerd en van grootte?
• Welke afhankelijkheden bestaan er tussen assets? Deze vragen zijn essentieel voor de classificatie van de inventaris.

Kwalitatieve analyse: De volgende reeks beslissingen vereist menselijke intelligentie in de vorm van kwalitatieve analyse. De vragen die hier worden gesteld, zijn vaak uniek voor de oplossing en kunnen alleen worden beantwoord door zakelijke belanghebbenden en energiegebruikers. Deze beslissingen vertragen doorgaans het proces, wat de zaken aanzienlijk vertraagt. Deze analyse verbruikt doorgaans 40 tot 80 FTE uur per toepassing.

Zie Benaderingen voor het plannen van digitale onroerend goed voor hulp bij het maken van een lijst met kwalitatieve analysevragen.

Rationaliseringsbeslissing: In de handen van een ervaren rationaliseringsteam zorgen de kwalitatieve en kwantitatieve gegevens voor duidelijke beslissingen. Helaas zijn teams met een hoge mate van rationalisering duur om te huren of maanden te nemen om te trainen.

Rationalisering op ondernemingsschaal

Als deze inspanning tijdrovend en lastig is voor digitale gegevens van 50 VM's, stelt u zich eens de inspanning voor die nodig is om de bedrijfstransformatie te verbeteren in een omgeving met duizenden VM's en honderden toepassingen. De benodigde menselijke inspanning kan gemakkelijk 1500 FTE-uren en negen maanden planning overschrijden.

Hoewel volledige rationalisering de eindtoestand en een goede richting is om in te gaan, produceert het zelden een hoog rendement (rendement op investeringen) ten opzichte van de tijd en energie die nodig zijn.

Wanneer rationalisering essentieel is voor financiële beslissingen, is het de moeite waard om een professionele serviceorganisatie te overwegen die is gespecialiseerd in cloudrationalisatie om het proces te versnellen. Zelfs dan kan volledige rationalisering een kostbare en tijdrovende inspanning zijn die transformatie of bedrijfsresultaten vertraagd.

In de rest van dit artikel wordt een alternatieve benadering beschreven, ook wel incrementele rationalisering genoemd.

Incrementele rationalisering

De volledige rationalisering van een groot digitaal onroerend goed is risicogevoelig en kan vertragingen oplopen vanwege de complexiteit. De veronderstelling achter de incrementele benadering is dat vertraagde beslissingen de belasting van het bedrijf spreiden om het risico op obstakels te verminderen. Met deze aanpak wordt na een periode een organische methode gemaakt voor het ontwikkelen van de processen en ervaring die nodig zijn om efficiënter gekwalificeerde rationaliseringsbeslissingen te nemen.

Inventaris: Detectiegegevenspunten verminderen

Er zijn maar weinig organisaties die tijd, energie en kosten investeren in het onderhouden van een nauwkeurige realtime-inventarisatie van het volledige digitale onroerend goed. Verlies, diefstal, vernieuwingscycli en onboarding van werknemers rechtvaardigen vaak gedetailleerde tracering van activa van apparaten van eindgebruikers. Het rendement van het onderhouden van een nauwkeurige server- en toepassingsinventaris in een traditioneel, on-premises datacenter is vaak laag. De meeste IT-organisaties hebben urgenter problemen dan het bijhouden van het gebruik van vaste activa in een datacenter.

In een cloudtransformatie correleert de inventarisatie rechtstreeks met de operationele kosten. Nauwkeurige inventarisatiegegevens zijn vereist voor de juiste planning. Helaas kunnen huidige opties voor het scannen van omgevingen beslissingen met weken of maanden vertragen. Gelukkig kunnen een paar trucs het verzamelen van gegevens versnellen.

Scannen op basis van een agent is de meest voorkomende vertraging. De robuuste gegevens die vereist zijn voor een traditionele rationalisering, kunnen vaak alleen worden verzameld met een agent die op elke asset wordt uitgevoerd. Deze afhankelijkheid van agents vertraagt vaak de voortgang, omdat er feedback van beveiligings-, operationele en beheerfuncties nodig kan zijn.

In een incrementeel rationaliseringsproces kan een oplossing zonder agent worden gebruikt voor een eerste detectie om vroege beslissingen te versnellen. Afhankelijk van het complexiteitsniveau in de omgeving is een agentgebaseerde oplossing mogelijk nog steeds vereist, maar kan deze worden verwijderd uit het kritieke pad naar de bedrijfswijziging.

Kwantitatieve analyse: Beslissingen stroomlijnen

Ongeacht de benadering van inventarisdetectie kan kwantitatieve analyse de eerste beslissingen en veronderstellingen aandrijden. Dit geldt met name wanneer u probeert de eerste workload te identificeren of wanneer het doel van rationalisering een vergelijking van de kosten op hoog niveau is. In een incrementeel rationaliseringsproces beperken het cloudstrategieteam en de cloud-acceptatieteams de vijf Rs van rationalisering tot twee beknopte beslissingen en passen ze alleen deze kwantitatieve factoren toe. Dit stroomlijnt de analyse en vermindert de hoeveelheid initiële gegevens die nodig zijn om de wijziging door te voeren.

Als een organisatie zich bijvoorbeeld bezig heeft met een IaaS-migratie naar de cloud, kunt u ervan uitgaan dat de meeste workloads uit bedrijf worden genomen of opnieuw worden hosten.

Kwalitatieve analyse: Tijdelijke veronderstellingen

Door het aantal mogelijke resultaten te verminderen, is het gemakkelijker om een eerste beslissing te nemen over de toekomstige status van een asset. Wanneer u de opties vermindert, vermindert u ook het aantal vragen dat in deze vroege fase van het bedrijf wordt gesteld.

Als de opties bijvoorbeeld beperkt zijn tot opnieuw hosten of met pensioen worden teruggetrokken, hoeft het bedrijf slechts één vraag te beantwoorden tijdens de initiële rationalisering. Dit is of de asset moet worden teruggetrokken.

"Analyse geeft aan dat er geen gebruikers actief gebruik maken van deze asset. Is dat nauwkeurig of hebben we iets over het hoofd gezien? Een dergelijke binaire vraag is doorgaans veel eenvoudiger uit te voeren via kwalitatieve analyse.

Deze gestroomlijnde benadering produceert basislijnen, financiële plannen, strategie en richting. In latere activiteiten door ondergaat elke asset verdere rationalisering en kwalitatieve analyse om andere opties te evalueren. Alle veronderstellingen die u in deze eerste rationalisering maakt, worden getest voordat u afzonderlijke workloads migreert.

Veronderstellingen op de proef stellen

Het resultaat van de vorige sectie is een ruwe rationalisering die vol veronderstellingen staat. Vervolgens is het tijd om een aantal van deze veronderstellingen op de een of andere dag uit te dagen.

Assets uit bedrijf nemen

In een traditionele on-premises omgeving heeft het hosten van kleine, ongebruikte activa zelden een aanzienlijke invloed op de jaarlijkse kosten. Op een paar uitzonderingen na wegen fte-inspanningen die nodig zijn om de werkelijke activa te analyseren en terug te trekken op tegen de kostenbesparingen door deze activa te deactiveren en te deactiveren.

Wanneer u overstapt op een cloudboekhoudingsmodel, kan het met het uit bedrijf nemen van activa aanzienlijke besparingen opleveren in de jaarlijkse operationele kosten en de inspanningen van de eerste migratie.

Het is niet ongebruikelijk dat organisaties 20% of meer van hun digitale gegevens na het voltooien van een kwantitatieve analyse met 20% van hun gegevens in rust laten. We raden u aan verdere kwalitatieve analyse uit te voeren voordat u actie onderneemt. Nadat dit is bevestigd, kan het stoppen van deze activa het eerste rendement van de cloudmigratie opleveren. Dit is vaak een van de grootste kostenbesparende factoren. Daarom moet het cloudstrategieteam de validatie en de pensioen van activa overzien, parallel met de uitvoering van de Migrate-methodologie,om een vroege financiële winst te behalen.

Programmacorrecties

Een bedrijf is zelden op weg naar slechts één transformatietraject. De keuze tussen kostenvermindering, marktgroei en nieuwe inkomstenstromen is zelden een binaire beslissing. Daarom raden we aan dat het cloudstrategieteam samen met IT assets identificeert voor parallelle transformatie-inspanningen die buiten het bereik van het primaire transformatietraject vallen.

In het voorbeeld van de IaaS-migratie in dit artikel:

• Vraag het DevOps-team om assets te identificeren die al deel uitmaken van een implementatieautomatisering en deze assets te verwijderen uit het basismigratieplan.

• Vraag de gegevens- en R D-teams om assets te identificeren die nieuwe inkomstenstromen mogelijk maken en deze & te verwijderen uit het basismigratieplan.

Deze programmagerichte kwalitatieve analyse kan snel worden uitgevoerd en zorgt voor uitlijning tussen meerdere migratieachterstanden.

Mogelijk moet u sommige assets nog een tijdje beschouwen als assets opnieuw hosten. U kunt later na de eerste migratie fasering van de rationalisering gaan maken.

De eerste workload selecteren

Het implementeren van de eerste workload is essentieel voor testen en leren. Dit is de eerste kans om te demonstreren en een groei-instelling te bouwen.

Bedrijfscriteria

Om de bedrijfstransparantie te waarborgen, identificeert u een workload die wordt ondersteund door een lid van de bedrijfseenheid van het cloudstrategieteam. Kies bij voorkeur een waarin het team een aangeslagen belang en sterke motivatie heeft om over te gaan naar de cloud.

Technische criteria

Selecteer een workload met minimale afhankelijkheden en kan worden verplaatst als een kleine groep assets. U wordt aangeraden een workload met een gedefinieerd testpad te selecteren om de validatie te vereenvoudigen.

De eerste workload wordt vaak geïmplementeerd in een experimentele omgeving zonder operationele of governancecapaciteit. Het is belangrijk om een workload te selecteren die geen interactie heeft met beveiligde gegevens.

Kwalitatieve analyse

De cloud-acceptatieteams en het cloudstrategieteam kunnen samenwerken om deze kleine workload te analyseren. Deze samenwerking biedt een gecontroleerde kans om kwalitatieve analysecriteria te maken en te testen. De kleinere populatie biedt de mogelijkheid om de betrokken gebruikers te onderzoeken en een gedetailleerde kwalitatieve analyse in een week of minder te voltooien. Zie het specifieke rationaliseringsdoel in de vijf Rs van rationaliseringvoor algemene kwalitatieve analysefactoren.

Migratie

Tegelijkertijd met de voortdurende rationalisering kan het cloudmigratieteam beginnen met het migreren van de kleine workload om het leren uit te breiden op de volgende belangrijke gebieden:

• Vaardigheden versterken met het platform van de cloudprovider.
• Definieer de kernservices en Azure-standaarden die nodig zijn voor de langetermijnvisie.
• Meer inzicht in hoe bewerkingen mogelijk later in de transformatie moeten worden gewijzigd.
• Inzicht in eventuele inherente bedrijfsrisico's en de tolerantie van het bedrijf voor deze risico's.
• Stel een basislijn of minimum viable product (MVP) op voor governance op basis van de risicotolerantie van het bedrijf.

Releaseplanning

Terwijl het cloudmigratieteam de migratie of implementatie van de eerste workload uitvoert, kan het cloudstrategieteam beginnen met het prioriteren van de resterende toepassingen en workloads.

Power of 10

De traditionele benadering van rationalisering probeert te voldoen aan alle verwachte behoeften. Gelukkig is er vaak geen plan voor elke toepassing vereist om een transformatietraject te starten. In een incrementeel model biedt de Power of 10-benadering een goed uitgangspunt. In dit model selecteert het cloudstrategieteam de eerste 10 toepassingen die moeten worden gemigreerd. Deze tien workloads moeten een combinatie van eenvoudige en complexe workloads bevatten.

De eerste achterstanden maken

De cloud-acceptatieteams en het cloudstrategieteam kunnen samenwerken aan de kwalitatieve analyse voor de eerste tien workloads. Hierdoor ontstaat de eerste migratieachterstand met prioriteit en de eerste geprioriteerde releaseachterstand. Deze methode stelt de teams in staat om de aanpak te doorlopen en biedt voldoende tijd om een toereikend proces te maken voor kwalitatieve analyse.

Het proces volwassener maken

Nadat de twee teams het eens zijn over de kwalitatieve analysecriteria, kan de evaluatie een taak worden binnen elke iteratie. Voor het bereiken van consensus over evaluatiecriteria zijn meestal twee tot drie releases vereist.

Nadat de evaluatie is verplaatst naar het incrementele uitvoeringsproces van de migratie, kan het cloudmigratieteam sneller de evaluatie en architectuur doorlopen. In deze fase wordt het cloudstrategieteam ook geabstraheerd, waardoor de tijdsdruk wordt verkleind. Hierdoor kan het cloudstrategieteam zich ook richten op het prioriteren van de toepassingen die zich nog niet in een specifieke release hebben voor een nauwe afstemming op veranderende marktomstandigheden.

Niet alle toepassingen met prioriteit zijn gereed voor migratie. Sequencing zal waarschijnlijk veranderen omdat het team een diepere kwalitatieve analyse doet en zakelijke gebeurtenissen en afhankelijkheden detecteert die mogelijk vragen om het opnieuw prioriteren van de achterstand. Sommige releases kunnen een klein aantal workloads groepeert. Andere kunnen slechts één workload bevatten.

Het cloudmigratieteam zal waarschijnlijk iteraties uitvoeren die geen volledige workloadmigratie produceren. Hoe kleiner de workload en hoe minder afhankelijkheden, des te groter is de kans dat een workload in één sprint of iteratie past. Daarom raden we aan dat de eerste paar toepassingen in de releaseachterstand klein zijn en enkele externe afhankelijkheden bevatten.

Eindtoestand

Na een periode voltooien het cloud adoption-team en het cloudstrategieteam samen een volledige rationalisering van de inventaris. Deze incrementele benadering stelt de teams in staat om voortdurend sneller te gaan met het rationaliseringsproces. Het helpt ook bij het transformatietraject om sneller concrete bedrijfsresultaten te behalen, zonder al te veel inspanning vooraf te analyseren.

In sommige gevallen is het financiële model mogelijk te nauw om een beslissing te nemen zonder extra rationalisering. In dergelijke gevallen hebt u mogelijk een meer traditionele benadering van rationalisering nodig.

Volgende stappen

De uitvoer van een rationaliseringsinspanning is een geprioriteerde achterstand van alle assets die worden beïnvloed door de gekozen transformatie. Deze achterstand is nu gereed om te fungeren als de basis voor het kostenmodel van cloudservices.