Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Creazione di un business case direzionale
Le parti interessate di tutta l'azienda dovrebbero comprendere e accettare il business case per la trasformazione in ogni fase del percorso.
Nelle fasi iniziali, è importante mostrare rapidamente un valore potenziale sufficiente di un programma di migrazione, in modo da poter disporre delle risorse necessarie per pianificare e stabilire il programma. Il business case direzionale è progettato per fornire una ragionevole certezza nel raggiungimento di un valore aziendale convincente con i dati limitati che possono essere raccolti in anticipo.
Una volta stabilito il programma, il business case viene ulteriormente sviluppato. Il caso dettagliato fornisce una maggiore precisione, un quadro più completo del valore del programma e informazioni sulle priorità di pianificazione. Definisce e quantifica i risultati aziendali pianificati a cui l'organizzazione partecipa e stabilisce la linea di base rispetto alla quale l'ufficio di governance del programma può quindi indirizzare il programma e misurarne i risultati.
Definizione dell'ambito del business case direzionale
Un business case direzionale viene in genere assemblato rapidamente, entro 2-4 settimane. Deve generare sufficiente fiducia in modo da poter garantire le risorse necessarie per costituire il team principale, coinvolgere AWS i partner se necessario e, come minimo, completare le fasi prioritarie di valutazione delle applicazioni, analisi del portafoglio e pianificazione della migrazione.
In genere, i business case direzionali che supportano le migrazioni del portafoglio vengono creati in uno dei seguenti modi:
-
Un semplice confronto del costo totale di proprietà (TCO) tra il panorama dell'infrastruttura as-is e l'architettura post-migrazione. Servizio AWS Il confronto mostra la differenza nelle frequenze di esecuzione previste per determinati volumi di carico di lavoro.
-
Un business case che mostra il valore attuale netto (NPV), l'utile sul capitale investito (ROI), il periodo di ammortamento, il tasso di rendimento interno modificato (MIRR) e le analisi del flusso di cassa a 3-5 anni per la migrazione, comprensivi dei costi di migrazione rispetto al mantenimento dello stato attuale. AWS
L'ambito direzionale del business case è in genere limitato a uno dei seguenti:
-
Un confronto tra i costi della tecnologia dell'infrastruttura
-
Un confronto tra la tecnologia dell'infrastruttura e i costi operativi
In generale, più ampio è il portafoglio, meno sviluppato deve essere il caso. Questo perché è possibile formulare ipotesi più ampie senza influire in modo significativo sul risultato. Per un portafoglio più piccolo, qualsiasi modifica avrà un impatto maggiore, quindi sono necessari maggiori dettagli.
Inizia creando il confronto dei costi dell'infrastruttura di base. Quindi decidi se il confronto è sufficientemente convincente prima di continuare. In genere, i portafogli con più di 400 server mostrano un business case promettente solo per quanto riguarda la riduzione dei costi dell'infrastruttura entro 3 anni dall'operatività AWS, oppure 250 server entro 5 anni, anche se questo dato può variare. Per portafogli più piccoli, potrebbero essere necessari maggiori dettagli.
Al contrario, in questa fase è raramente utile esaminare altre componenti del valore aziendale, ad esempio il valore derivante da una maggiore resilienza o agilità aziendale, a meno che l'ambito di migrazione totale non sia inferiore a circa 5 carichi di lavoro o 50 server.
Concentrarsi sui fattori di valore
Il confronto del TCO relativo alla tecnologia dell'infrastruttura confronta un modello dei costi dell'infrastruttura così com'è con un modello base della Servizio AWS distinta base necessaria per eseguire i carichi di lavoro con prestazioni e disponibilità equivalenti. È possibile eseguire molte ottimizzazioni. In questa fase, tuttavia, l'attenzione si concentra sull'elenco seguente perché sono più facili da valutare e in genere consentono di risparmiare circa il 30% sul TCO, il che è sufficiente per andare avanti:
-
Elasticità di calcolo: mappa i server il cui utilizzo non è al 100%, come i server di sviluppo o UAT che eseguono 8x5 (24% di utilizzo), 10x5 (30%) o 10x6 (36%) e i server di disaster recovery (DR) che funzionano al 2%, ai servizi on demand che vengono fatturati solo quando utilizzati.
-
Approvvigionamento con un piano di risparmio: pianifica l'acquisto di server di produzione e altri server con un utilizzo elevato (superiore al 36 percento) con un piano di risparmio adeguato per ridurre i costi fino al 75 percento. Le opzioni includono impegni di 1 o 3 anni, con diversi livelli di pagamenti anticipati per garantire sconti maggiori.
-
Rimuovi gli zombi: identifica i server con un utilizzo della CPU inferiore al 2% che puoi confermare non sono più necessari e rimuovili dall'analisi dei costi.
-
Calcolo del giusto dimensionamento: utilizza i dati delle serie temporali di utilizzo della CPU e della memoria per valutare, per ciascun server, la potenza di elaborazione e la memoria necessarie. Quindi seleziona l'istanza Amazon Elastic Compute Cloud (Amazon EC2) adatta.
-
Dimensionamento corretto della licenza del sistema di gestione di database relazionali (RDBMS): rivaluta le tue esigenze di licenza RDBMS dopo aver calcolato il corretto dimensionamento sui tuoi server di database, confronta la licenza Bring Your Own License (BYOL) e la licenza Procuring di ed esplora il AWS potenziale di Amazon Relational Database Service (Amazon RDS) per aumentare i risparmi.
-
Storage: dimensiona correttamente il volume di storage totale necessario e identifica le esigenze di operazioni di input/output al secondo (IOPS) in tutto il portafoglio. Determina quanto può essere spostato nello storage di oggetti con diversi costi. SLAs
Esigenze relative
La tabella in Comprensione dei requisiti relativi ai dati di valutazione iniziale mostra i dati necessari per creare ogni parte di un business case direzionale e se sono obbligatori o facoltativi.
Per creare il caso, è necessario il sottoinsieme infrastrutturale dei dati di pianificazione iniziale più i dati sui costi. Determinare come identificare l'infrastruttura da includere dipende dall'obiettivo aziendale:
-
Se l'obiettivo del programma è migrare e modernizzare applicazioni specifiche, create il portafoglio di infrastrutture in base alle esigenze delle applicazioni, prendendo in considerazione l'infrastruttura condivisa.
-
Se l'obiettivo del programma è incentrato sull'infrastruttura, ad esempio la migrazione da un data center il cui contratto di locazione sta per scadere, la mappatura delle applicazioni non è necessaria per confrontare il TCO dell'infrastruttura.
I dati contrassegnati come opzionali (come l'utilizzo massimo della CPU e della memoria per i server) in genere possono essere sostituiti con valori di benchmark standard. Puoi discuterne con un AWS partner o con un servizio AWS professionale. Oppure puoi estrapolare i valori dai punti dati disponibili in una parte del tuo portafoglio (come i dati raccolti da un hypervisor). Più grande è il portafoglio, più accurato è.
Confronti del TCO dell'infrastruttura degli edifici
Gli strumenti sono fondamentali per creare confronti tra il TCO dell'infrastruttura. AWS Professional Services
Sono disponibili strumenti per eseguire le seguenti operazioni:
-
Raccogli dati di inventario.
-
Raccogli dati di utilizzo.
-
Fornisci dati accurati di benchmarking dei costi dell'infrastruttura così come sono.
-
Identifica e rimuovi gli zombi.
-
Effettua valutazioni delle dimensioni corrette.
-
Consiglia le opzioni di acquisto.
-
Confronta le opzioni di licenza software.
-
Produci semplici analisi grafiche del flusso di cassa.
Migration Evaluator from
Principali vantaggi:
-
Gratuito
-
Rilevamento senza agente o configurazione manuale dei dati di inventario laddove l'individuazione basata su strumenti è limitata
-
Supporto dedicato per facilitare l'implementazione, la configurazione, la raccolta dei dati e la creazione del business case base o direzionale
-
Comodità del funzionamento SaaS, ma può eseguire la raccolta dei dati interamente all'interno della rete del cliente per supportare la pulizia prima del caricamento nel motore di analisi
-
Forte supporto per il corretto dimensionamento delle licenze Microsoft
-
Funzionalità complete di esportazione dei dati
Limitazioni principali:
-
Valuta solo i server con architettura x86 (Windows e Linux)
-
Opzioni limitate per configurare o calibrare i dati di costo del benchmark così come sono
-
Nessun supporto per l'ottimizzazione dei costi delle operazioni di modellazione
-
Nessun supporto per la modellazione dei costi di migrazione
-
Nessun supporto diretto per la creazione di casi aziendali oltre al confronto del TCO
Se si decide di utilizzare uno strumento di scoperta commerciale per le funzionalità di scoperta e analisi del portafoglio, come lo stack di applicazioni e l'individuazione dell'interdipendenza, di solito fornisce anche un confronto del TCO dell'infrastruttura. Per indicazioni sull'uso degli strumenti per l'individuazione e la valutazione del portafoglio, consulta Evaluating the need for discovery tooling. Per esaminare e confrontare le funzionalità chiave degli strumenti leader di mercato, consulta gli strumenti di migrazione Discovery, Planning e
Integrare l'ottimizzazione dei costi operativi
Il miglioramento della produttività delle operazioni IT è spesso un importante fattore di valore per le migrazioni. In media, dopo la migrazione verso AWS, la produttività del personale operativo IT aumenta del 62% grazie alla migrazione, secondo il white paper di International Data Corporation (IDC) Fostering Business and Organizational Transformation to Generate Business Value with Amazon Web Services
Innanzitutto, la valutazione dell'intera gamma di incrementi di produttività richiede un'ampia raccolta di dati ed è più appropriata per un business case dettagliato. Questa sfida può essere risolta concentrandosi su alcuni elementi che possono essere valutati e dimensionati più facilmente con semplici dati di benchmark, ma che mostrano comunque vantaggi significativi.
In secondo luogo, concentrarsi sulla produttività come fonte di riduzione dei costi può generare preoccupazioni e negatività tra i principali stakeholder dei clienti e i membri del programma. Assicuratevi di fornire informazioni chiare su come verrà realizzato il vantaggio e su cosa ciò significhi per le persone coinvolte. Tali problemi possono essere evitati chiarendo che ciò non farà che migliorare i ruoli del team:
-
Il programma di migrazione include un percorso per sviluppare e trasferire il personale operativo interno verso nuovi ruoli, ad esempio unirsi DevSecOps ai team per la creazione di infrastrutture come l'automazione del codice e le automazioni di test che favoriranno la crescita del team.
-
Il vantaggio può essere realizzato ridefinendo e ridimensionando i contratti di outsourcing delle operazioni, in modo che il personale interno possa concentrarsi maggiormente su attività di maggior valore
Approcciatevi alla costruzione di questo elemento del business case sulla base delle trasformazioni operative da prendere in considerazione:
-
Se disponi già di un team operativo interno, migliora le competenze dei membri del team e mostra il miglioramento della produttività previsto.
-
In alternativa, passa dalla tua attuale soluzione operativa a AWS Managed Services (AMS) o a un'offerta alternativa di servizi gestiti di un partner. AWS
Per la prima trasformazione, per ottenere una stima finanziaria prudente del miglioramento della produttività che può essere incluso nel caso, consigliamo quanto segue:
-
Concentratevi in particolare sulla produttività delle operazioni di gestione dei server. Tende a rappresentare una parte significativa dello sforzo operativo, può essere valutata più facilmente e può essere verificata più facilmente in un secondo momento.
-
Calcola il personale necessario in base ai benchmark relativi al numero di server che possono essere gestiti da ogni dipendente equivalente a tempo pieno (FTE). In sede, tale numero è di circa 150 server. No AWS, si tratta di circa 400 server.
-
Applica queste metriche al numero di server locali rispetto al numero di EC2 istanze.
-
Moltiplica il tempo risparmiato con una tariffa di costo mista per l'intero team operativo.
Puoi quindi verificare i risultati con entrambi gli approcci verificando che il risultato non superi di molto gli incrementi di produttività medi per ruolo forniti nella tabella seguente (dati tratti dal white paper IDC Fostering Business and Organizational Transformation to Generate Business Value
Ruolo |
Aumento di efficienza |
|---|---|
Gestione dell'infrastruttura IT |
62% |
Supporto IT |
59% |
Gestione delle applicazioni |
43% |
Gestione del database |
19% |
Sviluppo di applicazioni |
25% |
Per la seconda trasformazione, è possibile aggiungere i risparmi sui costi operativi confrontando direttamente gli attuali costi totali di operazioni e supporto per il portafoglio in questione con il costo del servizio gestito considerato.
Per ottenere il costo del servizio gestito, fornite al vostro AWS account manager o a qualsiasi AWS Managed Services
partner
Espansione verso un business case completamente direzionale
In generale, per creare un business case completo, è necessario creare il confronto del TCO, con o senza l'elemento relativo alla produttività IT, e stimare tutti i costi di migrazione e modernizzazione. Quindi crea un flusso di cassa che copra due scenari diversi. migrate-and-modernize t-migrate-and-modernize
Il caso più semplice è la preparazione di una singola coppia di scenari, in cui lo t-migrate-and-modernize scenario da non fare è la situazione attuale e migrate-and-modernize lo scenario presenta le seguenti caratteristiche:
-
Nessuna crescita o riduzione del volume transazionale, della capacità di calcolo o della capacità di rete
-
Crescita costante a basso volume dei requisiti di storage
-
Quality-of-service funzionalità (quali disponibilità, durata, velocità effettiva e prestazioni) corrispondenti alle funzionalità del sistema esistente
Per tutti i portafogli, tranne quelli molto piccoli, ciò si adatta bene all'obiettivo di creare un case direzionale. Dimostra un valore sufficiente in tempi rapidi per ottenere il mandato di andare avanti.
Per i portafogli più piccoli, può essere utile aggiungere coppie di t-migrate-and-modernize scenari migrate-and-modernize e non, che dimostrino altri aspetti del maggiore valore della migrazione al cloud, come ad esempio:
-
Una combinazione di requisiti di crescita moderati e ad alta capacità per tutti i carichi di lavoro in cui è prevista tale crescita
-
Inclusione di una maggiore resilienza, come l'alta disponibilità, il DR e la tolleranza agli errori
-
Prestazioni globali migliorate con edge computing, rete per la distribuzione dei contenuti (CDN) e replica di database in più regioni.
-
Qualsiasi altro miglioramento specifico della qualità del servizio che hai considerato prioritario per il programma
Per questi scenari, assicurati che i costi e le implicazioni sul flusso di cassa dell'aggiornamento dell'attuale architettura dell'infrastruttura non cloud per soddisfare le nuove specifiche siano stimati con precisione. Il modo più diretto per ottenere questa stima può essere richiedere un preventivo a un integratore di sistemi, soprattutto se è anche un partner di AWS consulenza con Migration Competency, che può supportarti in entrambi gli scenari. migrate-and-modernize t-migrate-and-modernize
Per ogni coppia di scenari, assemblate una custodia contenente quanto segue:
-
I costi dello scenario da non fare. t-migrate-and-modernize Nel caso più semplice, ciò include:
-
Il costo totale di proprietà nel periodo di validità del business case per l'attuale configurazione dell'infrastruttura
-
Aumenti periodici del consumo di elaborazione, storage e traffico di rete
-
-
I costi dello scenario migrate-and-modernize, tra cui:
-
Impostazione del programma, che include l'individuazione dettagliata, la pianificazione della migrazione, lo sviluppo dettagliato dei business case, la creazione del core team e il suo miglioramento delle competenze, l'istituzione di una landing zone se non è già presente e la definizione della gestione della sicurezza e dell'integrazione delle operazioni per i carichi di lavoro migrati
-
Costi di migrazione e modernizzazione dei carichi di lavoro
-
I costi dell'infrastruttura di migrazione, comprese le connessioni di rete, i servizi di migrazione dei dati come AWS Snowball Edge
e AWS DataSync e i costi delle AWS utenze per l'architettura necessaria durante il processo di migrazione stesso (ad esempio, per i test) -
L'aumento dei costi delle AWS utenze nel corso della migrazione man mano che le ondate si fanno sentire e la riduzione dei costi dell'infrastruttura esistente man mano che questa viene sostituita da servizi basati su servizi AWS basati e dismessa
-
I costi di smantellamento e le cancellazioni di eventuali asset bloccati
Stima della configurazione del programma di migrazione e modernizzazione
Per impostare con successo un programma, potrebbe essere necessario eseguire una serie di attività di base per sviluppare le funzionalità di base e il piano dettagliato, se ciò non è mai stato fatto prima. Queste attività fondamentali includono quanto segue:
-
Esecuzione dell'individuazione dettagliata del portafoglio, della pianificazione della migrazione e dello sviluppo dettagliato dei business case, come descritto nella sezione Analisi del portafoglio e pianificazione della migrazione, oltre alla documentazione del costo degli strumenti di scoperta utilizzati.
-
Creazione di un core team tecnico e aziendale basato sul cloud e sviluppo di competenze interne attraverso la formazione e l'assunzione. Identifica i membri dell'organizzazione IT che avranno bisogno di formazione e assegna un budget di formazione per ogni persona.
-
Stabilire una landing zone
e configurarla per supportare le funzionalità di governance dei costi, operative e della sicurezza necessarie.
AWS I partner di consulenza possono contribuire a fornire stime per gli articoli 1 e 3.
Stima dei costi di migrazione e modernizzazione
Per raggiungere gli obiettivi di un business case direzionale e dimostrare il potenziale commerciale sufficiente per passare alla fase successiva, fate in modo che la stima dei costi di migrazione e modernizzazione sia quanto più semplice possibile.
A tal fine, si consiglia di preparare il business case direzionale concentrandosi sulle applicazioni che rientrano nelle seguenti strategie di migrazione:
-
Ritiro
-
Mantenimento
-
Trasferisci
-
Riospitare
-
Conversione piattaforma
-
Riacquisto
In genere, circa il 70 percento dei carichi di lavoro può essere riospitato, trasferito o riorganizzato e un altro 5 percento può essere ritirato. La valutazione delle applicazioni in base alla strategia di migrazione di solito affronta la questione centrale della riduzione dei costi.
La stima dei costi per il refactoring, o la riprogettazione, può essere complessa. Non è pratico tentare di farlo entro il lasso di tempo previsto per la preparazione di un business case direzionale. Come discusso in precedenza in Determinazione del tipo R per la migrazione, prendi in considerazione l'utilizzo di strategie di rehosting, trasferimento o ripiattaforma per la prima fase di migrazione e modernizzazione. Queste strategie R probabilmente accelereranno il recupero iniziale, ridurranno il rischio di implementazione e miglioreranno il business case a breve termine. Inoltre, è sostanzialmente più semplice per i team addetti alle applicazioni modernizzare le applicazioni in esecuzione nell' AWS ambiente rispetto a quelle che non lo sono. È preferibile aggiungere stime per il refactoring (riprogettazione) di applicazioni specifiche al momento della preparazione del business case dettagliato.
Stima degli sforzi per la migrazione in base alla strategia
Ogni migrazione è diversa. Prima di impegnare budget o piani, preparate le stime del carico di lavoro per le attività di migrazione dal team responsabile del progetto, che si tratti dei team addetti alle applicazioni interni, dei Servizi AWS professionali o di un'organizzazione partner. AWS
Per contribuire a definire la situazione direzionale, la tabella seguente fornisce gli intervalli di sforzo indicativi per i diversi trattamenti. Questi intervalli presuppongono che sia in corso la migrazione di un medium-to-large portafoglio e che il team addetto alla migrazione sia formato ed esperto. Per i portafogli di piccole dimensioni, è meglio che il team responsabile della migrazione prepari la stima anche per un caso direzionale.
| Strategia di migrazione | Processo di stima | Elementi | Ore della persona | Ore della persona |
|---|---|---|---|---|
| Mantenimento | Non fate nulla, senza costi, senza vantaggi e senza ridurre il debito tecnologico. | – |
– |
– |
| Ritiro | Stima dello smantellamento delle apparecchiature hardware utilizzate, se presenti. | – |
– |
– |
| Trasferire | Stima la copia del carico di lavoro nell'ambito degli strumenti di utilizzo. VMware VMware Ciò include la copia dei dati, i test sul fumo per verificarli e l'eventuale smantellamento dell'hardware. Lo sforzo di trasferimento VMs è in genere inferiore rispetto ai modelli di rehosting a bassa complessità. | – |
– |
– |
| Riospitare | Prevedi la possibilità di copiare il carico di lavoro e i dati con una copia dell'immagine, test di fumo, test di alta disponibilità (HA) e disaster recovery (DR), se del caso, per i server di produzione e l'eventuale smantellamento dell'hardware. La migliore pratica consiste nell'utilizzare strumenti come. AWS Application Migration Service |
Impegno per app per server | Migrazione | Test HA/DR |
| Bassa | 10-14 | 3—5 | ||
| Media | 16—24 | 4—6 | ||
| Elevata | 26—38 | 8—12 | ||
| Conversione piattaforma | Per le migrazioni su più piattaforme che includono aggiornamenti al sistema operativo o alla versione RDBMS, calcola una stima del rehost e aggiungi il tempo necessario per eseguire una ricostruzione e uno smoke test sulla nuova piattaforma. Se la ripiattaforma prevede la modifica della tecnologia della piattaforma, calcola il tempo aggiuntivo per l'uso degli strumenti di conversione, come and, e un test dell'applicazione più completo. AWS Schema Conversion ToolAWS Database Migration Service |
Impegno per app per server | Versione aggiornata | Cambiamento tecnologico |
| Bassa | Aggiungi 1—3 | Aggiungere 10—15 | ||
| Media | Aggiungi 2—5 | Aggiungi 20-30 | ||
| Elevata | Aggiungi 4—8 | Aggiungi 40—60 | ||
| Riacquisto | Stima l'estrazione, la trasformazione e il caricamento dei dati nel servizio SaaS appena acquistato, la sostituzione e l'eventuale disattivazione dell'hardware. | – |
– |
– |
Stima dei costi dell'infrastruttura di migrazione
Includi le stime per l'infrastruttura che utilizzerai nel corso della migrazione. In genere, queste stime comprendono:
-
Un budget per i servizi di connettività e scambio di dati per il carico di lavoro e la migrazione dei dati dall'ambiente corrente a AWS
-
Un budget per Servizi AWS (in particolare l'elaborazione e lo storage) necessario per ospitare i carichi di lavoro migrati durante i processi di migrazione, test e cutover
-
L'aumento dei costi delle AWS utenze man mano che ogni ondata di migrazione viene completata
-
I costi di smantellamento dell'infrastruttura esistente che non eseguirà più i carichi di lavoro migrati
Per lo scambio di dati, esamina i volumi totali di dati e valuta la fattibilità dell'utilizzo della rete. Se avete predisposto in anticipo un AWS Direct Connect
Se la capacità di rete è insufficiente, un aumento a breve termine della larghezza di banda Internet con una rete privata virtuale (VPN) è spesso una soluzione molto conveniente. In caso contrario, AWS i dispositivi di scambio multimediale come AWS Snowball Edge
La modellizzazione del potenziamento dei AWS servizi e dello smantellamento dell'infrastruttura esistente è importante per l'analisi del flusso di cassa del business case. In questa fase, è improbabile che si disponga di un piano onnicomprensivo per determinare esattamente quando verranno sostenuti i costi. Consigliamo quanto segue:
-
Incremento dei costi AWS a un ritmo costante durante la migrazione.
-
Riduzione dei costi dell'infrastruttura esistente che si prevede di smantellare a un ritmo costante per la stessa durata.
Iniziare ad aumentare i AWS costi 1-2 mesi prima che l'infrastruttura esistente diminuisca. Ciò fornisce 1 mese di utilizzo delle AWS utenze per effettuare la migrazione per ogni ondata. Include il tempo necessario per i test e il tempo aggiuntivo per completare i lavori di smantellamento necessari per evitare di incorrere in costi sull'infrastruttura sostituita.
Stima dei costi di smantellamento
Lo smantellamento delle apparecchiature che non possono essere riutilizzate e lo smaltimento delle stesse in modo legale e rispettoso dell'ambiente può comportare alcuni piccoli costi. Tuttavia, per un business case direzionale, in genere l'unica somma potenzialmente rilevante è il costo della cancellazione dell'eventuale valore contabile residuo degli asset sostituiti.
Per il business case direzionale, ti consigliamo di fare quanto segue:
-
Controlla l'elenco delle tue risorse.
-
Identifica quelli che verrebbero disattivati.
-
Per ridurre le perdite, esaminate le opportunità di cambiare dispositivo, in modo che i dispositivi più recenti presenti nell'elenco possano essere utilizzati per sostituire gli asset più vecchi e più completamente ammortizzati.
-
Effettua una valutazione del valore contabile futuro degli asset che verrebbero smantellati a quel punto.
-
Includetelo come costo di migrazione della disattivazione.
Assemblaggio e regolazione dell'intero business case direzionale
Dopo aver preparato la serie completa di costi per ogni coppia di scenari, create un rendiconto finanziario scontato per ciascuno e rappresentatelo graficamente. Consigliamo di creare casi aziendali direzionali nello stesso periodo del ciclo di aggiornamento dell'hardware. In genere si tratta di 5 anni per server, storage e dispositivi di rete. Se si utilizza lo stesso periodo del ciclo di aggiornamento dell'hardware, i costi di un solo aggiornamento sono inclusi nei costi così come sono per ogni scenario.
Quindi calcola le metriche finanziarie chiave necessarie per ottenere l'approvazione per passare alla fase successiva del programma. Di solito includiamo quanto segue:
-
Il valore attuale netto (NPV) per misurare il valore assoluto delle riduzioni dei costi e degli aumenti di produttività valutati
-
Il periodo di ammortamento, espresso in mesi, necessario per verificare che i resi siano sufficientemente rapidi
-
Il confronto finale del tasso di esecuzione per verificare se il processo sta riducendo i costi in misura sufficiente nel corso del periodo
-
Il ritorno sull'investimento (ROI) e il tasso di rendimento dell'investimento modificato (MIRR) per valutare la performance finanziaria relativa del programma rispetto ad altre esigenze di capitale a cui l'organizzazione potrebbe dare priorità
Utilizzate la prima iterazione del caso per determinare se la performance finanziaria prevista richieda dei perfezionamenti, come illustrato negli esempi seguenti:
-
Se il recupero dell'investimento è troppo lento, prendi in considerazione le opzioni per accelerare e ridurre i costi della migrazione, come le seguenti:
-
Utilizza AWS Partner o AWS Professional Services per espandere le risorse disponibili e parallelizzare ulteriormente la migrazione dei carichi di lavoro con modelli più semplici.
-
Per i carichi di lavoro in esecuzione VMware, confronta la strategia di trasferimento con la strategia di rehosting o replatform, almeno per la fase iniziale. L'utilizzo della strategia di trasferimento può ridurre i costi di migrazione e aumentare la velocità di migrazione.
-
Laddove tecnicamente fattibile, trasferisci i carichi di lavoro che richiedono strategie più complesse di ripiattaforma o rifattorizzazione (riprogettazione) in una fase futura, al di fuori dell'ambito del business case iniziale.
-
-
Se il ROI e il MIRR sono troppo bassi, considera quanto segue:
-
Gli scenari che state considerando sono troppo conservativi? Avete uno scenario che riflette le esigenze più probabili di crescita della capacità e di elasticità? Disponete di scenari che confrontano i costi, comprensivi degli aumenti della qualità del servizio, entro i vostri obiettivi?
-
Potete affinare l'ambito del portafoglio di applicazioni da migrare nella prima fase per concentrarvi sui carichi di lavoro che produrranno rendimenti più elevati, come quelli con un utilizzo corrente inferiore o costose esigenze di disaster recovery (DR)?
-
È possibile affinare l'ambito del portafoglio di applicazioni per escludere inizialmente carichi di lavoro specifici che ottengono risultati inferiori dal punto di vista commerciale? Ad esempio, è possibile posticipare i carichi di lavoro per i quali le licenze software di terze parti diventano più costose a causa delle diverse condizioni di implementazione nell'infrastruttura cloud pubblica?
-
-
Se il confronto finale della frequenza di esecuzione non soddisfa l'obiettivo previsto, esplora quanto segue:
-
Innanzitutto, conferma che le altre metriche soddisfino le aspettative. L'argomentazione aziendale direzionale consiste principalmente nel dimostrare che esistono sufficienti opportunità finanziarie per giustificare l'avvio della fase successiva di preparazione alla migrazione.
-
Identificate un elenco delle opportunità per continuare a migliorare la performance in termini di costi AWS dopo la fase iniziale della migrazione.
-
Includi una valutazione dell'elenco di opportunità nella preparazione del business case dettagliato. Inoltre, includi una valutazione delle opportunità nella manutenzione continua del caso e il processo di month-to-month ottimizzazione dei costi dopo il completamento della migrazione.
