Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Création d'une analyse de rentabilisation directionnelle
Les parties prenantes de l'ensemble de l'entreprise doivent comprendre et accepter l'analyse de rentabilisation en faveur de la transformation à chaque étape du processus.
Au début, il est important de démontrer rapidement la valeur potentielle d'un programme de migration, afin de pouvoir obtenir les ressources nécessaires à la planification et à la mise en place du programme. L'analyse de rentabilisation directionnelle est conçue pour apporter une confiance raisonnable quant à l'obtention d'une valeur commerciale convaincante avec les données limitées qui peuvent être collectées à un stade précoce.
Une fois le programme établi, l'analyse de rentabilisation est développée plus avant. Le cas détaillé fournit une plus grande précision, une image plus complète de la valeur du programme et un aperçu des priorités de planification. Il définit et quantifie les résultats commerciaux prévus auxquels l'organisation adhère, et il définit la base de référence par rapport à laquelle votre bureau de gouvernance du programme peut ensuite orienter le programme et mesurer ses réalisations.
Définition de la portée de l'analyse de rentabilisation directionnelle
Une analyse de rentabilisation directionnelle est généralement assemblée rapidement, en 2 à 4 semaines. Il doit générer suffisamment de confiance pour que vous puissiez obtenir les ressources nécessaires pour constituer l'équipe principale, engager des AWS partenaires si nécessaire et, au minimum, terminer l'évaluation des applications prioritaires, l'analyse du portefeuille et les étapes de planification de la migration.
Généralement, les analyses de rentabilisation directionnelles qui prennent en charge les migrations de portefeuilles sont créées comme suit :
-
Une simple comparaison du coût total de possession (TCO) entre le paysage d'infrastructure tel quel et l'architecture Service AWS post-migration. La comparaison montre la différence entre les taux d'exécution attendus pour des volumes de charge de travail donnés.
-
Une analyse de rentabilisation qui montre la valeur actuelle nette (VAN), le retour sur investissement (ROI), la période de remboursement, le taux de rendement interne modifié (MIRR) et des analyses des flux de trésorerie sur 3 à 5 ans pour une migration AWS incluant les coûts de migration plutôt que de rester en l'état.
La portée de l'analyse de rentabilisation directionnelle est généralement limitée à l'un des éléments suivants :
-
Comparaison des coûts des technologies d'infrastructure
-
Comparaison de l'infrastructure, de la technologie et des coûts d'exploitation
En général, plus le portefeuille est important, moins le dossier doit être développé. Cela est dû au fait que des hypothèses plus larges peuvent être formulées sans affecter de manière significative le résultat. Pour un portefeuille plus petit, tout changement aura un impact plus important, c'est pourquoi plus de détails sont nécessaires.
Commencez par établir la comparaison des coûts d'infrastructure de base. Décidez ensuite si la comparaison est suffisamment convaincante avant de poursuivre. En général, les portefeuilles de plus de 400 serveurs présentent une analyse de rentabilisation positive sur la seule base de la réduction des coûts d'infrastructure dans les 3 ans suivant leur exploitation AWS, ou 250 serveurs dans les 5 ans, bien que cela puisse varier. Pour les petits portefeuilles, des détails supplémentaires peuvent être nécessaires.
À l'inverse, il est rarement utile d'examiner d'autres éléments de valeur commerciale à ce stade, tels que la valeur dérivée d'une résilience ou d'une agilité commerciale améliorée, sauf si l'étendue totale de la migration est inférieure à environ 5 charges de travail ou 50 serveurs.
Facteurs de valeur focalisés
La comparaison du coût total de possession des technologies d'infrastructure compare un modèle des coûts d'infrastructure tels quels à un modèle de base de la Service AWS nomenclature nécessaire pour exécuter vos charges de travail avec des performances et une disponibilité équivalentes. De nombreuses optimisations peuvent être effectuées. À ce stade, toutefois, l'accent est mis sur la liste suivante, car ils sont plus faciles à évaluer et permettent généralement de réaliser des économies d'environ 30 % sur le coût total de possession, ce qui est suffisant pour aller de l'avant :
-
Élasticité de calcul — Mappez les serveurs dont l'utilisation n'est pas de 100 %, tels que les serveurs de développement ou UAT fonctionnant 8 x 5 (24 % d'utilisation), 10 x 5 (30 %) ou 10 x 6 (36 %), et les serveurs de reprise après sinistre (DR) fonctionnant à 2 %, vers des services à la demande facturés uniquement lorsqu'ils sont utilisés.
-
Achetez avec un plan d'économies : planifiez l'achat de serveurs de production et d'autres serveurs très utilisés (plus de 36 %) avec un plan d'économies approprié pour réduire les coûts jusqu'à 75 %. Les options incluent des engagements d'un an et de 3 ans, avec différents niveaux de paiements initiaux pour garantir des remises plus importantes.
-
Supprimez les zombies : identifiez les serveurs dont l'utilisation du processeur est inférieure à 2 % et dont vous pouvez confirmer qu'ils ne sont plus nécessaires, et retirez-les de l'analyse des coûts.
-
Calcul adapté : utilisez les séries chronologiques d'utilisation du processeur et de la mémoire pour évaluer la puissance de calcul et la mémoire nécessaires pour chaque serveur. Sélectionnez ensuite l'instance Amazon Elastic Compute Cloud (Amazon EC2) qui vous convient.
-
Dimensionnement correct des licences du système de gestion de base de données relationnelle (RDBMS) : réévaluez vos besoins en matière de licences RDBMS après avoir calculé le bon dimensionnement sur vos serveurs de base de données, comparez Bring Your Own License (BYOL) et Procuring license from, et explorez le potentiel AWS d'Amazon Relational Database Service (Amazon RDS) pour augmenter les économies.
-
Stockage : dimensionnez correctement le volume de stockage total nécessaire et identifiez les besoins en opérations d'entrée/sortie par seconde (IOPS) sur l'ensemble du portefeuille. Déterminez la quantité qui peut être transférée vers le stockage d'objets avec SLAs des coûts différents.
Besoins en données
Le tableau de la section Comprendre les exigences en matière de données d'évaluation initiale indique les données requises pour élaborer chaque partie d'une analyse de rentabilisation directionnelle, et indique si elles sont obligatoires ou facultatives.
Pour étayer le dossier, vous avez besoin du sous-ensemble d'infrastructure composé des données de planification initiales et des données de coûts. La détermination de la manière d'identifier l'infrastructure à inclure dépend de votre objectif commercial :
-
Si l'objectif du programme est de migrer et de moderniser des applications spécifiques, créez le portefeuille d'infrastructures en fonction des besoins des applications, en tenant compte de l'infrastructure partagée.
-
Si l'objectif du programme est centré sur l'infrastructure, par exemple la migration depuis un centre de données dont le bail arrive à expiration, le mappage des applications n'est pas nécessaire pour comparer le coût total de possession de l'infrastructure.
Les données marquées comme facultatives (telles que l'utilisation maximale du processeur et de la mémoire pour les serveurs) peuvent généralement être remplacées par des valeurs de référence standard. Vous pouvez en discuter avec un AWS partenaire ou des services AWS professionnels. Vous pouvez également extrapoler les valeurs à partir de points de données disponibles dans une partie de votre portefeuille (comme les données collectées par un hyperviseur). Plus le portefeuille est grand, plus il est précis.
Comparaisons du coût total de possession des infrastructures du bâtiment
Les outils sont essentiels pour établir des comparaisons du coût total de possession des infrastructures. AWS Les services professionnels
Des outils sont disponibles pour effectuer les opérations suivantes :
-
Collectez les données d'inventaire.
-
Collectez les données d'utilisation.
-
Fournissez des données d'analyse comparative des coûts d'infrastructure précises telles quelles.
-
Identifiez et éliminez les zombies.
-
Procédez à des évaluations de la bonne taille.
-
Recommandez des options d'achat.
-
Comparez les options de licences logicielles.
-
Produisez des analyses graphiques simples des flux de trésorerie.
Migration Evaluator
Principaux avantages :
-
Sans frais
-
Découverte sans agent ou configuration manuelle des données d'inventaire lorsque la découverte basée sur des outils est limitée
-
Support dédié pour faciliter le déploiement, la configuration, la collecte de données et l'élaboration du scénario de base ou de l'analyse de rentabilisation directionnelle
-
Facilité d'utilisation du SaaS, mais possibilité d'exécuter la collecte de données entièrement au sein du réseau du client pour faciliter le nettoyage avant le chargement dans le moteur d'analyse
-
Support solide pour le dimensionnement correct des licences Microsoft
-
Capacités complètes d'exportation de données
Principales limites :
-
Évalue uniquement les serveurs d'architecture x86 (Windows et Linux)
-
Options limitées pour configurer ou calibrer les données de coûts de référence telles quelles
-
Aucun support pour l'optimisation des coûts des opérations de modélisation
-
Aucun support pour la modélisation des coûts de migration
-
Aucun soutien direct pour l'élaboration d'analyses de rentabilisation autres que les comparaisons du coût total de possession
Si vous décidez d'utiliser un outil de découverte commercial pour des fonctionnalités de découverte et d'analyse de portefeuilles telles que la pile d'applications et la découverte des interdépendances, il fournira généralement également une comparaison du coût total de possession de l'infrastructure. Pour obtenir des conseils sur l'utilisation des outils de découverte et d'évaluation du portefeuille, voir Évaluation du besoin d'outils de découverte. Pour examiner et comparer les principales fonctionnalités des principaux outils du marché, consultez la section Outils de migration de découverte, de planification et de recommandation
Intégrer l'optimisation des coûts opérationnels
L'amélioration de la productivité des opérations informatiques contribue souvent de manière significative à la valeur des migrations. En moyenne, après la migration vers AWS, la productivité du personnel opérationnel informatique augmente de 62 % grâce à la migration, selon le livre blanc Fostering Business and Organizational Transformation to Generate Business and Organizational Transformation to Generate Business Value with Amazon Web Services
Tout d'abord, l'évaluation de la gamme complète des gains de productivité nécessite une collecte de données approfondie et convient mieux à l'analyse de rentabilisation détaillée. Ce défi peut être résolu en se concentrant sur quelques éléments qui sont plus faciles à évaluer et à dimensionner à l'aide de simples données de référence, mais qui présentent tout de même un avantage significatif.
Deuxièmement, le fait de se concentrer sur la productivité comme source de réduction des coûts peut susciter des inquiétudes et de la négativité chez les principaux clients, les parties prenantes et les membres du programme. Assurez-vous de préciser comment l'avantage sera réalisé et ce que cela signifie pour les personnes touchées. De tels problèmes peuvent être évités en précisant que cela ne fera que renforcer les rôles de l'équipe :
-
Le programme de migration comprend une piste permettant de développer et de transférer le personnel des opérations internes vers de nouveaux rôles, tels que rejoindre des DevSecOps équipes pour créer une infrastructure sous forme d'automatisations de code et de tests automatisés qui stimuleront la croissance de l'équipe.
-
L'avantage peut être obtenu en redimensionnant et en redimensionnant les opérations, les contrats d'externalisation, afin que le personnel interne puisse se concentrer davantage sur les activités à plus forte valeur ajoutée
Approche de construction de cet élément d'analyse de rentabilisation en fonction des transformations opérationnelles que vous souhaitez prendre en compte :
-
Si vous disposez déjà d'une équipe opérationnelle interne, améliorez les compétences des membres de l'équipe et montrez l'amélioration de productivité attendue.
-
Vous pouvez également passer de votre solution d'exploitation actuelle à AWS Managed Services (AMS) ou à une autre offre de services gérés proposée par un AWS partenaire.
Pour la première transformation, afin d'obtenir une estimation financière prudente de l'amélioration de la productivité pouvant être incluse dans le cas, nous recommandons ce qui suit :
-
Concentrez-vous spécifiquement sur la productivité des opérations de gestion des serveurs. Cela représente généralement une part importante de l'effort opérationnel, peut être plus facilement évalué et est plus facilement vérifié ultérieurement.
-
Calculez le personnel nécessaire sur la base de points de référence relatifs au nombre de serveurs pouvant être gérés par chaque employé équivalent temps plein (ETP). Sur site, ce nombre est d'environ 150 serveurs. Non AWS, il s'agit d'environ 400 serveurs.
-
Appliquez ces mesures au nombre de serveurs sur site par rapport au nombre d' EC2 instances.
-
Multipliez le temps économisé par un taux de coût combiné pour l'ensemble de l'équipe opérationnelle.
Vous pouvez ensuite vérifier vos résultats avec l'une ou l'autre approche en vérifiant que le résultat ne dépasse pas largement les gains de productivité moyens par rôle fournis dans le tableau suivant (données provenant du livre blanc d'IDC « Favoriser la transformation commerciale et organisationnelle pour générer de la valeur commerciale avec Amazon
Rôle |
Gain d'efficacité |
|---|---|
Gestion de l'infrastructure informatique |
62 % |
Support informatique |
59 % |
Gestion des applications |
43 % |
Gestion de base de données |
19 % |
Développement d'applications |
25% |
Pour la deuxième transformation, vous pouvez ajouter les économies de coûts d'exploitation en comparant directement le total actuel des opérations et des coûts de support pour le portefeuille concerné avec le coût du service géré considéré.
Pour obtenir le coût du service géré, fournissez à votre responsable de AWS compte ou à tout AWS Managed Services
partenaire
Passage à une analyse de rentabilisation complète
En général, pour élaborer une analyse de rentabilisation complète, établir une comparaison du coût total de possession, avec ou sans l'élément de productivité informatique, et estimer tous les coûts de migration et de modernisation. Créez ensuite un flux de trésorerie qui couvre des paires de scénarios migrate-and-modernize et de t-migrate-and-modernize scénarios à ne pas faire.
Le cas le plus simple est la préparation d'une seule paire de scénarios, dans lesquels le t-migrate-and-modernize scénario à ne pas faire correspond à votre situation actuelle et le migrate-and-modernize scénario présente les caractéristiques suivantes :
-
Aucune augmentation ou diminution du volume transactionnel, de la capacité de calcul ou de réseau
-
Croissance régulière des faibles volumes des besoins de stockage
-
Quality-of-service des fonctionnalités (telles que la disponibilité, la durabilité, le débit et les performances) correspondant aux capacités du système existant
Pour tous les portefeuilles, à l'exception des très petits portefeuilles, cela correspond à l'objectif consistant à bien élaborer un argumentaire directionnel. Il démontre rapidement une valeur suffisante pour obtenir le mandat nécessaire pour aller de l'avant.
Pour les portefeuilles plus petits, il peut être utile d'ajouter des paires de scénarios migrate-and-modernize et de t-migrate-and-modernize scénarios à ne pas faire qui mettent en évidence d'autres aspects de la valeur accrue de la migration vers le cloud, tels que :
-
Une combinaison d'exigences de croissance de capacité modérées et élevées pour les charges de travail pour lesquelles cette croissance est attendue
-
Intégration d'une résilience améliorée, telle que la haute disponibilité, la reprise après sinistre et la tolérance aux pannes
-
Performances mondiales améliorées grâce à l'informatique de pointe, au réseau de diffusion de contenu (CDN) et à la réplication de bases de données multirégionales.
-
Toute autre amélioration spécifique de la qualité de service dont vous avez fait une priorité commerciale pour le programme
Pour ces scénarios, assurez-vous que les coûts et les implications en termes de flux de trésorerie liés à la mise à niveau de l'architecture d'infrastructure non cloud actuelle pour qu'elle corresponde à la nouvelle spécification sont estimés avec précision. Le moyen le plus direct d'obtenir cette estimation peut être de demander un devis à un intégrateur de systèmes, en particulier s'il s'agit également d'un partenaire AWS consultant compétent en matière de migration, qui peut vous aider à trouver des solutions à la fois aux scénarios migrate-and-modernize et aux scénarios à éviter. t-migrate-and-modernize
Pour chaque paire de scénarios, assemblez un boîtier comprenant les éléments suivants :
-
Les coûts du t-migrate-and-modernize scénario « Don't ». Dans le cas le plus élémentaire, cela inclut :
-
Le coût total de possession sur la durée de l'analyse de rentabilisation pour la configuration actuelle de l'infrastructure
-
Augmentations périodiques de la consommation de calcul, de stockage et de trafic réseau
-
-
Les coûts du scénario migrate-and-modernize, notamment :
-
Configuration du programme, qui comprend la découverte détaillée, la planification de la migration, l'élaboration d'une analyse de rentabilisation détaillée, la mise en place de l'équipe principale et le renforcement de ses compétences, l'établissement d'une zone de destination si ce n'est déjà fait, et la mise en place d'une gestion de la sécurité et d'une intégration des opérations pour les charges de travail migrées
-
Les coûts de migration et de modernisation de la charge de travail
-
Les coûts de l'infrastructure de migration, y compris les connexions réseau, les services de migration de données tels que AWS Snowball Edge
et AWS DataSync , et les coûts AWS utilitaires liés à l'architecture requise pendant le processus de migration lui-même (par exemple, pour les tests) -
L'augmentation des coûts des AWS services publics au cours de la migration au fur et à mesure de la mise en service des vagues, et la réduction des coûts d'infrastructure existants au fur et à mesure de leur remplacement par des services AWS basés et de leur mise hors service
-
Les coûts de mise hors service et les amortissements de tous les actifs bloqués
Estimation de la configuration du programme de migration et de modernisation
Pour mettre en place un programme couronné de succès, vous devrez peut-être exécuter une série d'activités de base pour renforcer les capacités de base et le plan détaillé si cela n'a pas été fait auparavant. Ces activités fondamentales sont notamment les suivantes :
-
Réalisation de la découverte détaillée du portefeuille, de la planification de la migration et de l'élaboration d'une analyse de rentabilisation détaillée, comme décrit dans la section Analyse du portefeuille et planification de la migration, ainsi que de la documentation du coût de tous les outils de découverte utilisés.
-
Mettre en place une équipe principale commerciale et technique dans le cloud et développer les compétences internes par le biais de la formation et du recrutement. Identifiez les membres du service informatique qui auront besoin d'une formation et allouez un budget de formation à chaque personne.
-
Établir une zone d'atterrissage
et la configurer pour prendre en charge les capacités de gouvernance des coûts, des opérations et de la sécurité dont vous aurez besoin.
AWS Les partenaires consultants peuvent vous aider à fournir des estimations pour les articles 1 et 3.
Estimation des coûts de migration et de modernisation
Pour atteindre les objectifs d'une analyse de rentabilisation directionnelle et démontrer un potentiel commercial juste suffisant pour passer à la phase suivante, veillez à ce que l'estimation des coûts de migration et de modernisation soit aussi simple que possible.
À cette fin, nous vous recommandons de préparer l'analyse de rentabilisation directionnelle en vous concentrant sur les applications répondant aux stratégies de migration suivantes :
-
Mise hors service
-
Conserver
-
Déménager
-
Réhéberger
-
Recréation de plateforme
-
Rachat
En règle générale, environ 70 % des charges de travail peuvent être réhébergées, déplacées ou replateformes, et 5 % peuvent être supprimées. L'évaluation des applications par stratégie de migration porte généralement sur l'essentiel du cas de réduction des coûts.
L'estimation des coûts de refactorisation ou de réarchitecture peut s'avérer complexe. Il n'est pas pratique de tenter de le faire dans le délai imparti pour préparer une analyse de rentabilisation directionnelle. Comme indiqué précédemment dans Déterminer le type R pour la migration, envisagez d'utiliser des stratégies de réhébergement, de relocalisation ou de replateforme pour votre première phase de migration et de modernisation. Ces stratégies R accéléreront probablement le retour sur investissement initial, réduiront les risques liés à la mise en œuvre et amélioreront l'analyse de rentabilisation à court terme. Il est également nettement plus facile pour vos équipes d'application de moderniser les applications qui s'exécutent dans l' AWS environnement que celles qui ne le sont pas. Il est préférable d'ajouter des estimations pour la refactorisation (réarchitecture) d'applications spécifiques lorsque l'analyse de rentabilisation détaillée est préparée.
Estimation de l'effort de migration par stratégie
Chaque migration est différente. Avant d'engager des budgets ou des plans, établissez des estimations de la charge de travail pour les activités de migration auprès de l'équipe qui sera responsable du projet, qu'il s'agisse de vos équipes internes chargées des applications, des services AWS professionnels ou d'une organisation AWS partenaire.
Pour aider à établir le dossier directionnel, le tableau suivant fournit des plages indicatives d'effort pour les différents traitements. Ces plages supposent qu'un medium-to-large portefeuille est en cours de migration et que l'équipe de migration est formée et expérimentée. Pour les petits portefeuilles, il est préférable que l'équipe responsable de la migration prépare l'estimation, même dans le cas d'un scénario directionnel.
| Stratégie de migration | Processus d'estimation | Eléments | Heures par personne | Heures par personne |
|---|---|---|---|---|
| Conserver | Ne rien faire, sans frais, sans avantages et sans réduction de la dette technologique. | – |
– |
– |
| Mise hors service | Estimez la mise hors service de l'équipement matériel utilisé, le cas échéant. | – |
– |
– |
| Déménager | Estimez la copie de la charge de travail à VMware l'aide VMware d'outils. Cela inclut la copie des données, les tests de fumée à des fins de vérification et la mise hors service du matériel. L'effort de relocalisation VMs est généralement moindre que pour les modèles de réhébergement peu complexes. | – |
– |
– |
| Réhéberger | Estimez la charge de travail et les données à l'aide d'une copie d'image, de tests de détection de fumée, de tests de haute disponibilité (HA) et de reprise après sinistre (DR), le cas échéant, pour les serveurs de production et de toute mise hors service du matériel. La meilleure pratique consiste à utiliser des outils tels que AWS Application Migration Service |
Effort par application et par serveur | Migration | Test HA/DR |
| Faible | 10 à 14 | 3 à 5 | ||
| Moyen | 16 à 24 ans | 4—6 | ||
| Élevé | 26—38 | 8 à 12 | ||
| Recréation de plateforme | Pour les migrations de replateforme qui incluent des mises à niveau vers le système d'exploitation ou la version du SGBDR, faites une estimation pour un réhébergement et ajoutez du temps pour effectuer un test de reconstruction et de fumage sur la nouvelle plateforme. Si la replateforme inclut une modification de la technologie de la plate-forme, estimez le temps supplémentaire pour l'utilisation des outils de conversion, tels que AWS Schema Conversion Tool |
Effort par application et par serveur | Version supérieure | Changements technologiques |
| Faible | Ajoutez 1 à 3 | Ajoutez 10 à 15 | ||
| Moyen | Ajoutez 2 à 5 | Ajoutez 20—30 | ||
| Élevé | Ajoutez 4 à 8 | Ajoutez 40 à 60 | ||
| Rachat | Estimez l'extraction, la transformation et le téléchargement des données dans le cadre du remplacement du service SaaS récemment acheté et de toute mise hors service du matériel. | – |
– |
– |
Estimation des coûts de l'infrastructure de migration
Incluez des estimations pour l'infrastructure que vous utiliserez au cours de la migration. En général, ces estimations comprennent :
-
Un budget pour les services de connectivité et d'échange de données pour la charge de travail et la migration des données de l'environnement actuel vers AWS
-
Un budget Services AWS (en particulier pour le calcul et le stockage) nécessaires à l'hébergement des charges de travail migrées pendant les processus de migration, de test et de transition
-
L'augmentation des coûts des AWS services publics à mesure que chaque vague de migration est terminée
-
Les coûts de mise hors service de l'infrastructure existante qui n'exécutera plus les charges de travail migrées
Pour l'échange de données, examinez vos volumes de données totaux et évaluez la faisabilité de l'utilisation du réseau. Si vous avez configuré AWS à l'avance une AWS Direct Connect
Si la capacité de votre réseau est insuffisante, une augmentation à court terme de la bande passante Internet grâce à un réseau privé virtuel (VPN) est souvent une solution très rentable. Sinon, AWS les dispositifs d'échange multimédia tels que AWS Snowball Edge
La modélisation de l'augmentation des AWS services et de la réduction de l'infrastructure existante est importante pour l'élément d'analyse des flux de trésorerie de l'analyse de rentabilisation. À ce stade, il est peu probable que vous disposiez d'un plan de vagues permettant de déterminer exactement quand les coûts seront engagés. Nous vous recommandons la procédure suivante :
-
Augmenter les coûts à un taux constant AWS tout au long de la migration.
-
Réduire les coûts de l'infrastructure existante que vous prévoyez de mettre hors service à un rythme constant pendant la même durée.
Commencer l'augmentation des AWS coûts 1 à 2 mois avant la réduction de l'infrastructure existante. Cela permet d'utiliser l' AWS utilitaire pendant un mois pour effectuer la migration pour chaque vague. Cela inclut du temps pour les tests et du temps supplémentaire pour terminer les travaux de mise hors service nécessaires afin de ne plus encourir de coûts sur l'infrastructure remplacée.
Estimation des coûts de mise hors service
La mise hors service des équipements qui ne peuvent pas être redéployés et leur élimination de manière légale et respectueuse de l'environnement peuvent entraîner de faibles coûts. Cependant, pour une analyse de rentabilisation directionnelle, la seule somme potentiellement significative est généralement le coût de la radiation de la valeur comptable restante des actifs remplacés.
Pour l'analyse de rentabilisation directionnelle, nous vous recommandons de procéder comme suit :
-
Passez en revue votre liste d'actifs.
-
Identifiez ceux qui seraient mis hors service.
-
Pour réduire les amortissements, examinez les possibilités de changer d'appareil afin que les nouveaux appareils de la liste puissent être utilisés pour remplacer des actifs plus anciens et plus entièrement amortis.
-
Faites une évaluation de la future valeur comptable des actifs qui seraient mis hors service à ce moment-là.
-
Incluez ce montant dans le coût de migration lié à la mise hors service.
Assemblage et ajustement de l'analyse de rentabilisation entièrement directionnelle
Après avoir préparé l'ensemble complet des coûts pour chaque paire de scénarios, établissez un tableau des flux de trésorerie actualisés pour chacun d'eux et représentez-les sous forme de graphique. Nous recommandons d'élaborer des analyses de rentabilisation directionnelles au cours de la même période que le cycle d'actualisation du matériel. Ce délai est généralement de 5 ans pour les serveurs, le stockage et les périphériques réseau. Lorsque vous utilisez la même période que le cycle d'actualisation du matériel, les coûts d'une seule actualisation sont inclus dans les coûts tels quels pour chaque scénario.
Calculez ensuite les indicateurs financiers clés dont vous avez besoin pour obtenir l'approbation nécessaire pour passer à la phase suivante du programme. Nous incluons généralement les éléments suivants :
-
La valeur actuelle nette (VAN) pour évaluer la valeur absolue des réductions de coûts et des gains de productivité évalués
-
Le délai de remboursement en mois pour vérifier que les retours sont suffisamment rapides
-
Comparaison finale du taux d'exécution pour vérifier si le processus réduit suffisamment les coûts sur le terme
-
Le retour sur investissement (ROI) et le taux de rendement d'investissement modifié (MIRR) pour évaluer la performance financière relative du programme par rapport aux autres demandes de capital auxquelles votre organisation pourrait donner la priorité
Utilisez la première itération du cas pour déterminer si les performances financières attendues nécessitent des améliorations, comme dans les exemples suivants :
-
Si le retour sur investissement est trop lent, envisagez des options pour accélérer et réduire le coût de la migration, telles que les suivantes :
-
Faites appel à AWS des partenaires ou à des services AWS professionnels pour étendre les ressources disponibles et paralléliser davantage la migration des charges de travail avec des modèles plus basiques.
-
Pour les charges de travail entrantes VMware, comparez la stratégie de relocalisation à la stratégie de réhébergement ou de replateforme, au moins pour la phase initiale. L'utilisation de la stratégie de relocalisation peut réduire les coûts de migration et augmenter la vitesse de migration.
-
Lorsque cela est techniquement possible, reportez les charges de travail qui nécessitent des stratégies de replateforme ou de refactorisation (réarchitecture) plus complexes à une phase future, en dehors du cadre de l'analyse de rentabilisation initiale.
-
-
Si le retour sur investissement et le MIRR sont trop faibles, considérez les points suivants :
-
Les scénarios que vous envisagez sont-ils trop conservateurs ? Avez-vous un scénario qui reflète la croissance des capacités et les besoins d'élasticité les plus probables ? Avez-vous des scénarios qui comparent les coûts, y compris l'augmentation de la qualité de service, dans le cadre de vos objectifs ?
-
Pouvez-vous affiner l'étendue du portefeuille d'applications à migrer au cours de la première phase afin de vous concentrer sur les charges de travail les plus rentables, telles que celles dont le taux d'utilisation actuel est plus faible ou les besoins coûteux en matière de reprise après sinistre (DR) ?
-
Est-il possible d'affiner la portée du portefeuille d'applications pour exclure dans un premier temps les charges de travail spécifiques moins rentables sur le plan commercial ? Par exemple, pouvez-vous reporter les charges de travail pour lesquelles les licences de logiciels tiers deviennent plus chères en raison de conditions de déploiement différentes dans une infrastructure de cloud public ?
-
-
Si la comparaison finale de la fréquence d'exécution n'atteint pas l'objectif attendu, explorez les points suivants :
-
Tout d'abord, confirmez que les autres indicateurs répondent aux attentes. L'analyse de rentabilisation directionnelle vise principalement à démontrer qu'il existe des opportunités financières suffisantes pour justifier le lancement de la phase suivante de préparation de la migration.
-
Identifiez une liste des opportunités permettant de continuer à améliorer les performances en termes de coûts AWS après la phase initiale de migration.
-
Incluez une évaluation de la liste des opportunités lors de la préparation de l'analyse de rentabilisation détaillée. En outre, incluez une évaluation des opportunités dans le cadre de la maintenance continue du dossier et du processus month-to-month d'optimisation des coûts une fois la migration terminée.
