Racionalizace digitálních aktiv

Racionalizace cloudu je proces vyhodnocování prostředků, který určuje nejlepší přístup k hostování prostředků v cloudu. Po určení přístupu a agregaci inventáře může začít racionalizace cloudu. Racionalizace cloudu popisuje nejběžnější možnosti racionalizace.

V následujícím videu získáte rychlý přehled o dokončení komplexního posouzení, které vám pomůže naplánovat a určit prioritu migrace.

Tradiční pohled na racionalizaci

Racionalizaci je snadné pochopit, když vizualizujete tradiční proces racionalizace jako složitý rozhodovací strom. Každý prostředek v digitálních aktivech se předává procesem, který má za následek jednu z pěti odpovědí (pět rs racionalizace). U malých aktiv tento proces funguje dobře. U větších aktiv je neefektivní a může vést k významným zpožděním. Pojďme se podívat na proces, abychom zjistili, proč. Pak představíme efektivnější model.

Inventář: Pro dokončení úplné racionalizace pomocí tradičních modelů se vyžaduje důkladný inventář prostředků, včetně aplikací, softwaru, hardwaru, operačních systémů a metrik výkonu systému.

Kvantitativní analýza: Kvantitativní otázky ve rozhodovacím stromu řídí první vrstvu rozhodnutí. Mezi běžné otázky patří:

  • Používá se prostředek ještě dnes?
  • Pokud ano, je optimalizovaná a správně nastavená?
  • Jaké závislosti existují mezi prostředky? Tyto otázky jsou nezbytné pro klasifikaci inventáře.

Kvalitativní analýza: Další sada rozhodnutí vyžaduje lidskou inteligenci ve formě kvalitativní analýzy. Otázky, které se zde objeví, jsou často jedinečné pro řešení a mohou být zodpovězeny pouze obchodními účastníky a výkonnými uživateli. Tato rozhodnutí obvykle zpožďují proces a výrazně zpomalují věci. Tato analýza obecně využívá 40 až 80 hodin FTE na aplikaci.

Pokyny k vytvoření seznamu kvalitativních otázek analýzy najdete v tématu Přístupy k plánování digitálních aktiv.

Rozhodnutí o racionalizaci: V rukou zkušeného racionalizace tým vytváří kvalitativní a kvantitativní data jasná rozhodnutí. Týmy s vysokou mírou racionalizace jsou bohužel nákladné najmout nebo trvat měsíce na trénování.

Racionalizace v podnikovém měřítku

Pokud je toto úsilí časově náročné a náročné na digitální aktiva 50 virtuálních počítačů, představte si úsilí, které je potřeba k zajištění obchodní transformace v prostředí s tisíci virtuálních počítačů a stovkami aplikací. Potřebné lidské úsilí může snadno překročit 1 500 hodin FTE a devět měsíců plánování.

I když je úplná racionalizace koncovým stavem a skvělým směrem k pohybu, jen zřídka vytváří vysokou návratnost investic (návratnost investic) vzhledem k času a požadované energii.

Pokud je racionalizace nezbytná pro finanční rozhodnutí, je vhodné zvážit organizaci profesionálních služeb, která se specializuje na racionalizaci cloudu, aby urychlila proces. I v takovém případě může být úplná racionalizace nákladnou a časově náročnou prací, která zpožďuje transformaci nebo obchodní výsledky.

Zbytek tohoto článku popisuje alternativní přístup, který se označuje jako přírůstková racionalizace.

Přírůstková racionalizace

Úplná racionalizace velkých digitálních aktiv je náchylná k riziku a může mít zpoždění kvůli své složitosti. Předpokladem přírůstkového přístupu je to, že zpožděná rozhodnutí snižují zatížení firmy, aby se snížilo riziko překážek. Tento přístup v průběhu času vytváří organický model pro vývoj procesů a zkušeností potřebných k efektivnějšímu rozhodování o kvalifikované racionalizaci.

Inventář: Omezení datových bodů zjišťování

Několik organizací investuje čas, energii a výdaje do údržby přesného inventáře digitálních aktiv v reálném čase. Ztráta, krádež, cykly aktualizace a onboarding zaměstnanců často ospravedlňují podrobné sledování prostředků zařízení koncových uživatelů. Návratnost dat udržování přesného inventáře serverů a aplikací v tradičním místním datacentru je často nízká. Většina IT organizací má naléhavější problémy, které je potřeba řešit, než sledovat využití pevných prostředků v datacentru.

V cloudové transformaci inventář přímo koreluje s provozními náklady. Pro správné plánování se vyžadují přesná data inventáře. Aktuální možnosti kontroly životního prostředí bohužel můžou zpozdit rozhodování o týdnech nebo měsících. Naštěstí může shromažďování dat urychlit několik triků.

Kontrola na základě agenta je nejčastěji citovaná prodleva. Robustní data potřebná pro tradiční racionalizaci je často možné shromažďovat pouze s agentem běžícím na jednotlivých prostředcích. Tato závislost na agentech často zpomaluje průběh, protože může vyžadovat zpětnou vazbu od funkcí zabezpečení, operací a správy.

V procesu přírůstkové racionalizace by se k počátečnímu zjišťování mohlo použít řešení bez agentů k urychlení počátečních rozhodnutí. V závislosti na úrovni složitosti v prostředí může být stále potřeba řešení založené na agentech, ale může být odebráno z kritické cesty ke změně firmy.

Kvantitativní analýza: Zjednodušení rozhodování

Bez ohledu na přístup ke zjišťování zásob může kvantitativní analýza řídit počáteční rozhodnutí a předpoklady. To platí zejména při pokusu o identifikaci první úlohy nebo v případě, že cílem racionalizace je porovnání nákladů vysoké úrovně. V procesu přírůstkové racionalizace omezuje tým cloudové strategie a týmy přechodu na cloud pět rs racionalizace na dvě stručná rozhodnutí a používají pouze tyto kvantitativní faktory. Tím se zjednoduší analýza a sníží se množství počátečních dat potřebných ke změně.

Pokud je například organizace uprostřed migrace IaaS do cloudu, můžete předpokládat, že většina úloh se buď vyřadí z provozu, nebo se znovu hostuje.

Kvalitativní analýza: Dočasné předpoklady

Snížením počtu potenciálních výsledků je snazší dosáhnout počátečního rozhodnutí o budoucím stavu aktiva. Když zmenšujete možnosti, snížíte také počet otázek, které firma v této počáteční fázi položila.

Pokud jsou například možnosti omezené na změna hostitele nebo vyřazení z provozu, musí firma během počáteční racionalizace odpovědět pouze na jednu otázku, která určuje, jestli se má prostředek vyřadit.

Analýza naznačuje, že tento prostředek aktivně nepoužívají žádní uživatelé. Je to přesné, nebo jsme něco přehlédli?" Taková binární otázka je obvykle mnohem jednodušší projít kvalitativní analýzou.

Tento zjednodušený přístup vytváří směrné plány, finanční plány, strategii a směr. V pozdějších aktivitách každý prostředek prochází další racionalizizací a kvalitativní analýzou, aby se vyhodnotily další možnosti. Všechny předpoklady, které uděláte v této počáteční racionalizaci, se testují před migrací jednotlivých úloh.

Kritické zhodnocení předpokladů

Výsledek předchozí části je hrubá racionalizace, která je plná předpokladů. V dalším kroku je čas napadnout některé z těchto předpokladů.

Vyřazení prostředků

V tradičním místním prostředí hostování malých nevyužitých prostředků zřídka způsobuje významný dopad na roční náklady. S několika výjimkami převáží úsilí FTE potřebné k analýze a vyřazení skutečného majetku nad úsporami nákladů při vyřazování a vyřazení těchto prostředků.

Když přejdete na model účtování cloudu, vyřazení prostředků může výrazně ušetřit roční provozní náklady a počáteční migraci.

Není neobvyklé, že organizace po dokončení kvantitativní analýzy vyřadí 20 % nebo více svých digitálních aktiv. Před provedením opatření doporučujeme provést další kvalitativní analýzu. Po potvrzení může vyřazení těchto prostředků přinést první vítězství NÁVRATNOSTI migrace do cloudu. Často se jedná o jeden z největších faktorů úspor nákladů. Tým cloudové strategie by proto měl současně s prováděním metodologie migrace dohlížet na ověřování a vyřazení prostředků, aby dosáhl počáteční finanční výhry.

Úpravy programu

Společnost se jen zřídka vydává na jednu cestu transformace. Volba mezi snížením nákladů, růstem trhu a novými datovými proudy výnosů je zřídka binární rozhodnutí. Proto doporučujeme, aby tým cloudové strategie spolupracoval s IT a identifikoval prostředky při paralelní transformaci, které jsou mimo rozsah cesty primární transformace.

V příkladu migrace IaaS uvedené v tomto článku:

  • Požádejte tým DevOps, aby identifikoval prostředky, které už jsou součástí automatizace nasazení, a odebral je ze základního plánu migrace.

  • Požádejte datové týmy a týmy R&D, aby identifikovaly prostředky, které podporují nové datové proudy výnosů, a odebraly je ze základního plánu migrace.

Tuto kvalitativní analýzu zaměřenou na program je možné provést rychle a vytvořit sladění napříč více backlogy migrace.

Možná budete muset ještě nějakou dobu zvážit některé prostředky jako prostředky pro změna hostitele. Po počáteční migraci můžete provést pozdější racionalizaci.

Výběr první úlohy

Implementace první úlohy je klíčem k testování a učení. Je to první příležitost ukázat a vytvořit růst myšlení.

Obchodní kritéria

Pokud chcete zajistit obchodní transparentnost, identifikujte úlohu podporovanou členem organizační jednotky týmu cloudové strategie. Nejlépe si vyberte, ve kterém má tým vested sázku a silnou motivaci k přechodu do cloudu.

Technická kritéria

Vyberte úlohu s minimálními závislostmi a můžete ji přesunout jako malou skupinu prostředků. Doporučujeme vybrat úlohu s definovanou testovací cestou, abyste usnadnili ověření.

První úloha se často nasazuje v experimentálním prostředí bez provozní kapacity nebo kapacity zásad správného řízení. Je důležité vybrat úlohu, která nepracuje se zabezpečenými daty.

Kvalitativní analýza

Týmy přechodu na cloud a tým cloudové strategie můžou spolupracovat na analýze této malé úlohy. Tato spolupráce vytvoří řízenou příležitost k vytvoření a testování kvalitativních kritérií analýzy. Menší populace vytvoří příležitost k průzkumu ovlivněných uživatelů a k dokončení podrobné kvalitativní analýzy za týden nebo méně. U běžných kvalitativních analytických faktorů se podívejte na konkrétní cíl racionalizace v pěti směrech racionalizace.

Migrace

Tým přechodu na cloud může souběžně s pokračováním racionalizace začít migrovat malou úlohu a rozšířit tak výuku v následujících klíčových oblastech:

  • Posílit dovednosti pomocí platformy poskytovatele cloudu.
  • Definujte základní služby a standardy Azure potřebné pro dlouhodobou vizi.
  • Lépe pochopit, jak se operace mohou později v transformaci změnit.
  • Seznamte se s veškerými souvisejícími obchodními riziky a odolností firmy k těmto rizikům.
  • Vytvořte směrný plán nebo minimální realizovatelný produkt (MVP) pro zásady správného řízení na základě tolerance rizik podniku.

Plánování vydaných verzí

Zatímco tým přechodu na cloud provádí migraci nebo implementaci první úlohy, tým cloudové strategie může začít určovat prioritu zbývajících aplikací a úloh.

Mocnina 10

Tradiční přístup k racionalizaci se snaží splnit všechny předvídatelné potřeby. Naštěstí se k zahájení transformace často nevyžaduje plán pro každou aplikaci. V přírůstkovém modelu poskytuje přístup Power of 10 dobrý výchozí bod. V tomto modelu tým cloudové strategie vybere prvních 10 aplikací, které se mají migrovat. Těchto deset úloh by mělo obsahovat kombinaci jednoduchých a složitých úloh.

Sestavení prvních backlogů

Týmy přechodu na cloud a tým cloudové strategie mohou spolupracovat na kvalitativní analýze prvních 10 úloh. Toto úsilí vytvoří backlog migrace s první prioritou a backlog vydání s první prioritou. Tato metoda umožňuje týmům iterovat přístup a poskytuje dostatek času na vytvoření odpovídajícího procesu pro kvalitativní analýzu.

Zralý proces

Jakmile se dva týmy dohodnou na kvalitativních kritériích analýzy, může se posouzení stát úkolem v rámci každé iterace. Dosažení konsensu ohledně kritérií posouzení obvykle vyžaduje dvě až tři verze.

Jakmile se posouzení přesune do procesu přírůstkového provádění migrace, tým přechodu na cloud může iterovat rychleji posouzení a architekturu. V této fázi se také abstrahuje tým cloudové strategie, čímž se zkracuje jejich čas. To také umožňuje týmu cloudové strategie zaměřit se na stanovení priorit aplikací, které ještě nejsou v konkrétní verzi, a zajistit tak těsné sladění s měnícími se tržními podmínkami.

Ne všechny aplikace s prioritou budou připravené k migraci. Sekvencování se pravděpodobně změní, protože tým provádí hlubší kvalitativní analýzu a zjišťuje obchodní události a závislosti, které by mohly vyzvat k přeiritování backlogu. Některé verze můžou seskupovat malý počet úloh. Jiné můžou obsahovat jenom jednu úlohu.

Tým přechodu na cloud pravděpodobně spustí iterace, které nevytváří úplnou migraci úloh. Čím menší je úloha a tím méně závislostí, tím pravděpodobnější je, že se úloha vejde do jednoho sprintu nebo iterace. Z tohoto důvodu doporučujeme, aby první aplikace v backlogu vydaných verzí byly malé a obsahovaly několik externích závislostí.

Konečný stav

V průběhu času tým přechodu na cloud a tým cloudové strategie společně dokončí úplnou racionalizaci inventáře. Tento přírůstkový přístup umožňuje týmům, aby se průběžně urychli procesu racionalizace. Pomáhá také transformační cestě k dosažení hmatatelných obchodních výsledků dříve, aniž by bylo nutné provádět počáteční analýzu.

V některých případech může být finanční model příliš těsný, aby se rozhodl bez další racionalizace. V takových případech možná budete potřebovat tradičnější přístup k racionalizaci.

Další kroky

Výstupem racionalizačního úsilí je prioritní backlog všech prostředků, které jsou ovlivněny zvolenou transformací. Tento backlog je teď připravený sloužit jako základ pro nákladové modely cloudových služeb.