创建方向性商业案例 - AWS 规范性指导
确定方向性商业案例的范围聚焦价值驱动因素数据需求建筑基础架构 TCO 比较内置运营成本优化扩展到全方位的商业案例估算迁移和现代化计划设置

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

创建方向性商业案例

整个企业的利益相关者都应该理解并认同转型过程中的每一步的商业案例。

在早期阶段，重要的是要迅速显示出迁移计划的足够潜在价值，这样您才能获得规划和建立计划所需的资源。定向商业案例旨在提供合理的信心，让人们能够利用可以尽早收集的有限数据实现引人注目的商业价值。

计划建立后，将进一步发展商业案例。详细的案例提供了更高的准确性，更全面地了解了计划价值，并深入了解了规划优先事项。它定义和量化了组织认同的计划业务成果，并设定了基准，然后你的项目治理办公室可以据此指导计划并衡量其成就。

确定方向性商业案例的范围

定向性商业案例通常在 2-4 周内快速整理。它需要产生足够的信心，这样您才能获得足够的资源来建立核心团队，在需要时与 AWS 合作伙伴接触，并至少完成按优先顺序排列的应用程序评估和产品组合分析以及迁移规划阶段。

通常，支持产品组合迁移的定向业务案例按以下方式之一创建：

  • 现状基础架构格局和迁移后 AWS 服务架构之间的简单总拥有成本 (TCO) 比较。比较结果显示了给定工作负载量的预期运行速率的差异。

  • 一个商业案例，显示了净现值 (NPV)、投资回报率 (ROI)、投资回报期、修改后的内部收益率 (MIRR) 以及迁移到 AWS 包括迁移成本与保持原状的3-5年现金流分析。

定向商业案例的范围通常仅限于以下内容之一：

  • 基础架构技术成本的比较

  • 基础架构技术和运营成本的比较

总的来说，投资组合越大，案例就越不完善。这是因为可以在不显著影响结果的情况下做出更广泛的假设。对于较小的投资组合，任何变化都会产生更大的影响，因此需要更多的细节。

首先进行基础架构成本比较。然后再决定比较是否足够引人注目，然后再继续。通常，超过400台服务器的产品组合将在运行后的3年内显示出仅基础设施成本降低的积极商业案例 AWS，或者在5年内显示出250台服务器的积极商业案例，尽管情况可能有所不同。对于较小的投资组合，可能需要更多细节。

相反，除非总迁移范围少于大约 5 个工作负载或 50 台服务器，否则在此阶段研究其他业务价值组成部分（例如从提高弹性或业务灵活性中获得的价值）几乎没有用处。

聚焦价值驱动因素

基础架构技术总拥有成本比较将基础架构成本模型与以同等性能和可用性运行工作负载所需的 AWS 服务物料清单的基本模型进行了比较。可以进行许多优化。但是，在现阶段，重点放在以下列表上，因为它们更易于评估，并且通常可以节省约30％的总拥有成本，这足以向前推进：

  • 计算弹性 — 将使用率不是 100% 的服务器（例如运行 8x5（24% 使用率）、10x5（30%）或 10x6（36%）的开发服务器或 UAT 服务器，以及运行率为 2% 的灾难恢复 (DR) 服务器，映射到仅在使用时才计费的按需服务。

  • 使用@@ 节省计划进行采购 — 计划采购使用率高（大于 36%）的生产服务器和其他服务器，并制定适当的节省计划，最多可将成本降低 75%。选项包括1年期和3年期承诺，预付款水平不同，以获得更大的折扣。

  • 移除僵尸 — 找出 CPU 利用率低于 2% 且您可以确认不再需要的服务器，并将其从成本分析中删除。

  • 计算大小合理 — 使用 CPU 和内存利用率时间序列数据来评估每台服务器所需的计算能力和内存。然后选择适合的亚马逊弹性计算云 (Amazon EC2) 实例。

  • 关系数据库管理系统 (RDBMS) 许可证大小合适 — 在数据库服务器上进行适当调整后，重新评估您的 RDBMS 许可需求，比较自带许可证 (BYOL) 和从 AWS中获取许可证，并探索 Amazon RDatabase Service (Amazon RDS) 在增加成本方面的潜力。

  • 存储 — 适当调整所需的总存储量，并确定整个产品组合的每秒输入/输出操作 (IOPS) 需求。确定在不同的 SLA 和成本下，可以将多少钱转移到对象存储。

数据需求

了解初始评估数据需求中的表格显示了构建方向性商业论证的每个部分所需的数据，以及它是必需的还是可选的。

要构建案例，您需要初始规划数据中的基础架构子集以及成本数据。确定如何确定要包括的基础架构取决于您的业务目标：

  • 如果该计划的目标是对特定应用程序进行迁移和现代化改造，则应根据应用程序的需求构建基础架构产品组合，同时考虑共享的基础架构。

  • 如果该计划的目标是以基础架构为中心，例如迁出租约即将到期的数据中心，则不需要应用程序映射来比较基础架构 TCO。

标记为可选的数据（例如服务器的 CPU 和内存峰值利用率）通常可以替换为标准基准值。您可以与 AWS 合作伙伴或 AWS 专业服务部门讨论此问题。或者，您可以从部分投资组合中可用的数据点（例如虚拟机管理程序收集的数据）中推断出值。投资组合越大，其准确性就越高。

建筑基础架构 TCO 比较

工具对于构建基础架构 TCO 比较至关重要。AWS 专业服务或AWS 合作伙伴可以为所有类型的定向案例提供帮助，特别是如果您计划让他们参与更广泛的迁移过程。

有一些工具可用于执行以下操作：

  • 收集库存数据。

  • 收集利用率数据。

  • 提供准确的现状基础设施成本基准数据。

  • 识别并移除僵尸。

  • 进行适当规模的评估。

  • 推荐购买选项。

  • 比较软件许可选项。

  • 生成简单的图形化现金流分析。

来自的@@ 迁移评估器 AWS 是一种选择。它以免费托管服务的形式提供所有这些功能。您可以通过您的 AWS 客户经理或迁移能力合作伙伴或在线提交申请来申请 AWS迁移评估员。Migration Evalutor 专为单点解决方案而设计，可快速进行基础设施技术总拥有成本比较。

主要优势：

  • 免费

  • 在限制基于工具的发现的情况下，无需代理发现或手动配置清单数据

  • 提供专门支持，以协助部署、配置、数据收集和构建基础案例或定向业务案例

  • SaaS 操作的便利性，但可以完全在客户网络中进行数据收集，以支持在加载到分析引擎之前进行清理

  • 对 Microsoft 许可证大小调整的强大支持

  • 完整的数据导出功能

主要限制：

  • 仅评估 x86 架构服务器（Windows 和 Linux）

  • 按原样配置或校准基准成本数据的选项有限

  • 不支持建模运营成本优化

  • 不支持迁移成本建模

  • 除了比较 TCO 之外，没有直接支持构建业务案例

如果您决定使用商业发现工具进行投资组合发现和分析功能，例如应用程序堆栈和相互依赖关系发现，它通常还会提供基础架构总拥有成本比较。有关使用工具进行投资组合发现和评估的指导，请参阅评估对发现工具的需求。

内置运营成本优化

IT 运营效率的提高通常是迁移的重要价值贡献者。根据国际数据公司 (IDC) 的白皮书《利用 Amazon Web Services促进业务和组织转型以创造商业价值》，迁移到后，IT运营人员的工作效率通过迁移平均提高62％。 AWS但是，在调整规模以及在定向情况下包括这些好处方面存在两个挑战。

首先，评估生产率的全面提高需要收集大量数据，而且更适合详细的商业案例。这一挑战可以通过专注于一些更容易使用简单的基准数据进行评估和定量但仍显示出显著优势的要素来解决。

其次，将生产力作为降低成本的来源可能会引起主要客户利益相关者和计划成员的担忧和消极情绪。请务必明确说明收益将如何实现，以及这对受影响的人意味着什么。通过澄清这只会增强团队的角色，可以避免此类问题：

  • 迁移计划包括培养内部运营人员并将其调到新职位的轨道，例如加入 DevSecOps 团队，构建基础架构，例如代码自动化和测试自动化，这将推动团队的发展。

  • 通过重新调整业务外包合同的范围和规模，可以实现这种好处，这样内部员工就可以更多地关注价值更高的活动

根据您要考虑的运营转型来构建此业务案例元素的方法：

  • 如果您有现有的内部运营团队，请提高团队成员的技能，并显示预期的生产力提高。

  • 或者，从您当前的运营解决方案迁移到Man AWS aged Services (AMS) 或 AWS 合作伙伴提供的替代托管服务。

对于第一次转型，为了对案例中可能包含的生产率提高进行保守的财务估计，我们建议以下几点：

  1. 特别关注服务器管理运营效率。它往往占运营工作的很大一部分，可以更容易地进行评估，并且更容易在以后进行验证。

  2. 根据每位全职同等学历 (FTE) 员工可以管理的服务器数量的基准，计算所需的人员配置。在本地，这个数字约为 150 台服务器。开启 AWS，大约有 400 台服务器。

  3. 将这些指标应用于本地服务器数量与 EC2 实例数量的对比。

  4. 将节省的时间乘以整个运营团队的混合成本费率。

然后，您可以通过验证结果是否大大超过下表中提供的按角色划分的平均工作效率提高幅度（数据来自 IDC 白皮书《通过 Amazon Web Services 促进业务和组织转型以创造商业价值》）来检查结果。

角色

效率增益

IT 基础架构管理

62%

IT 支持

59%

应用程序管理

43%

数据库管理

19%

应用程序开发

25%

对于第二次转型，您可以直接将范围内产品组合的当前总运营和支持成本与正在考虑的托管服务的成本进行比较，从而增加运营成本节约。

要获得托管服务的费用，请向您的 AWS 客户经理或任何AWS Managed Services 合作伙伴提供您提议的物料 AWS 清单、您的服务级别选择（Plus 或 Premium）以及 AMS 套餐（AMS Accelerate 或 AMS Advanced）。这将为您提供转换后的解决方案的 AWS 服务组件的托管服务的总成本。同样，您可以从根据自己的参数提供自己的托管服务包的 AWS 合作伙伴那里获得定价。

扩展到全方位的商业案例

通常，要整理一个全方位的业务案例，请进行总体拥有成本比较，无论是否包含IT生产力要素，并估算所有迁移和现代化成本。然后创建涵盖成对t-migrate-and-modernize 情景 migrate-and-modernize 的现金流。

最基本的案例是准备一对场景，其中 “不要” 场t-migrate-and-modernize 景是您当前的情况，并且该 migrate-and-modernize 场景具有以下特征：

  • 交易量、计算能力或网络容量没有增长或萎缩

  • 存储需求稳步低量增长

  • Q uality-of-service 功能（例如可用性、耐久性、吞吐量和性能）与现有系统的能力相匹配

对于除非常小的投资组合以外的所有投资组合，这完全符合建立方向性案例的目标。它很快就证明了足够的价值，足以获得向前迈进的授权。

对于较小的投资组合，添加成对的 migrate-and-modernizet-migrate-and-modernize 场景来展示云迁移价值增加的其他方面，可能很有价值，例如：

  • 不同工作负载中等容量和高容量增长要求的组合，预计会有这种增长

  • 包括增强的弹性，例如高可用性、灾难恢复和容错能力

  • 通过边缘计算、内容分发网络 (CDN)、多区域数据库复制提高全球性能。

  • 您已将该计划列为业务优先事项的任何其他具体提高的服务质量

对于这些场景，请确保准确估算升级当前非云基础设施架构以匹配新规格所产生的成本和现金流影响。要获得此估算值，最直接的方法是向系统集成商索要报价，特别是如果他们也是具有迁移能力的 AWS 咨询合作伙伴，他们可以在两种场景中 migrate-and-modernize 为您提供支持。t-migrate-and-modernize

对于每对场景，请组装一个包含以下内容的案例：

  • “不要” t-migrate-and-modernize 情景的代价。在最基本的情况下，这包括：

    • 当前基础架构配置在业务案例期限内的总拥有成本

    • 计算、存储和网络流量消耗量定期增加

  • migrate-and-modernize; 场景的成本，包括：

    • 设置计划，包括详细的发现、迁移规划、详细的商业案例开发、建立核心团队并提高他们的技能、如果尚未建立 landing zone，则建立一个 landing zone，以及为迁移的工作负载建立安全管理和运营集成

    • 工作负载迁移和现代化成本

    • 迁移基础架构成本，包括网络连接、数据迁移服务（例如 AWS Snowball 和）AWS DataSync，以及迁移过程本身所需的架构的 AWS 公用事业成本（例如，用于测试）

    • 随着浪潮的上线，在迁移过程中， AWS 公用事业成本上升，而现有基础设施被 AWS 基础服务所取代并停用，从而降低了现有基础设施的成本

任何滞留资产的退役成本和注销

估算迁移和现代化计划设置

要制定成功计划，您可能需要开展一系列基础活动来建立基准能力和详细计划（如果以前没有这样做）。这些基础活动包括以下内容：

  1. 执行详细的产品组合发现、迁移规划和详细的业务案例开发（如投资组合分析和迁移规划部分所述），并记录所使用的任何发现工具的成本。

  2. 建立云业务和技术核心团队，通过培训和招聘培养内部技能。确定需要培训的 IT 组织成员，并为每个人分配培训预算。

  3. 建立 landing zon e 并对其进行配置以支持所需的成本、运营和安全治理能力。

AWS 咨询合作伙伴可以帮助提供第 1 项和第 3 项的估算值。

估算迁移和现代化成本

为了实现方向性商业案例的目标并展示足够的商业潜力来进入下一阶段，请尽可能将迁移和现代化成本估算保持在基本水平。

为此，我们建议您通过重点关注属于以下迁移策略的应用程序来准备定向业务案例：

  • 停用

  • 保留

  • 重新定位

  • 重新托管

  • 更换平台

  • 回购

通常，大约 70% 的工作负载可以重新托管、重新部署或平台重建，另外 5% 的工作负载可以停用。通过迁移策略评估应用程序通常可以解决降低成本的核心问题。

估算重构或重新架构的成本可能很复杂。在准备定向商业论证的时间范围内尝试这样做是不切实际的。如前面在确定迁移的 R 类型中所述，请考虑在迁移和现代化的第一阶段使用重新托管、重新定位或平台重置策略。这些 R 战略可能会在短期内加快初始投资回报，降低实施风险并改善商业案例。对于应用程序团队来说，对在环境中运行的应用程序进行现代化改造也比不在 AWS 环境中运行的应用程序容易得多。在准备好详细的业务案例时，最好添加重构（重新架构）特定应用程序的估算值。

按策略估算迁移工作量

每次迁移都是不同的。在提交任何预算或计划之前，请负责项目的团队（无论是内部应用程序团队、 AWS 专业服务团队还是 AWS 合作伙伴组织）对迁移活动进行工作量估算。

为了帮助建立方向性案例，下表提供了不同治疗方法的指示性工作范围。这些范围假设 medium-to-large投资组合正在迁移，并且迁移团队经过培训且经验丰富。对于小型投资组合，即使是方向性案例，也最好让负责迁移的团队准备估算值。

迁移策略 估算过程 元素 人员工时 人员工时
保留 什么都不做，没有成本，没有收益，也不会减少技术债务。

–

–

–
停用 如果有的话，估计要停用所使用的硬件设备。

–

–

–
重新定位 估计使用 VMware 工具在 VMware 中复制工作负载。这包括复制数据、进行烟雾测试以进行验证以及任何硬件的停用。与低复杂度的重新托管模式相比，迁移虚拟机的工作量通常要少。

–

–

–
重新托管 估计复制工作负载和数据，包括映像副本、烟雾测试、高可用性 (HA) 和灾难恢复 (DR) 测试（如适用），以及任何硬件的停用。最佳做法是使用诸如AWS 应用程序迁移服务之类的工具。根据数据库或其他基础架构软件是否在运行、数据库复杂性、是否集群、集成复杂性和数据量等因素，将工作负载分为低、中和高复杂度。 每台服务器每个应用程序的工作量 迁移 HA/DR 测试
低 10—14 3—5
中 16—24 4—6
高 26—38 8—12
更换平台 对于包括升级操作系统或 RDBMS 版本在内的平台重构迁移，请估算重新托管的时间，并增加在新平台上运行重建和冒险测试的时间。如果重新平台包括更改平台技术，请估计使用转换工具（例如AWS Schema Conversion Tool和 AWS Database Migration Service）以及更完整的应用程序测试所需的额外时间。技术变革的一个例子是从专有商业数据库迁移到开源替代数据库。 每台服务器每个应用程序的工作量 版本升级 技术变革
低 添加 1—3 加 10—15
中 添加 2—5 加 20—30
高 加 4—8 添加 40—60
回购 估算数据提取、转换和上传到新购买的 SaaS 服务替代产品以及任何硬件的停用情况。

–

–

–

估算迁移基础架构成本

包括您在迁移过程中将使用的基础设施的估算值。通常，这些估计值包括：

  • 用于连接和数据交换服务的预算，用于将工作负载和数据从当前环境迁移到 AWS

  • 在迁移、测试和切换过程中托管迁移的工作负载所需的 AWS 服务（尤其是计算和存储）的预算

  • 随着每个迁移浪潮的 AWS 完成，公用事业成本上升

  • 将不再运行迁移工作负载的现有基础架构的停用成本

对于数据交换，请检查您的总数据量并评估使用网络的可行性。如果您已在迁移后提前在 WAN 上预配置了AWS Direct Connect链路或AWS VPN从 AWS 某一点供操作使用，则可以在不超过其服务配额的情况下使用该资源。

如果您的网络容量不足，那么使用虚拟专用网络 (VPN) 短期增加互联网带宽通常是一种极具成本效益的解决方案。否则，诸如 AWS Snowball和Sn AWS ow cone之类的 AWS 媒体交换设备可在大多数地区提供解决方案。 AWS 此外，对于容量非常大的数据迁移，可以考虑包括预算 AWS DataSync，这样可以提高可靠性，并且无论使用何种介质，都可以加快传输速度。

对 AWS 服务的增加和现有基础设施的缩减进行建模对于商业案例的现金流分析要素很重要。在这个阶段，你不太可能有波浪计划来确定何时会产生成本。我们建议执行下列操作：

  • 在迁移过程中，以恒定的 AWS 速度提高成本。

  • 降低您计划在相同时间内以固定费率停用的现有基础设施的成本。

在现有基础设施缩减前 1-2 个月开始增加 AWS 成本。这为每个浪潮提供了 1 个月的 AWS 公用事业使用量，以进行迁移。这包括测试时间，以及完成停用工作所需的额外时间，以停止在更换后的基础设施上产生成本。

估算退役成本

停用无法重新部署的设备，并以合法和环保的方式处置这些设备，可能会产生一些小额成本。但是，对于有针对性的商业案例，通常唯一潜在的重大金额是注销被替换资产任何剩余账面价值的成本。

对于方向性商业案例，我们建议您执行以下操作：

  • 查看您的资产清单。

  • 确定那些将要退役的。

  • 为了减少注销，请研究切换设备的机会，以便清单上的新设备可以用来取代较旧、折旧得更充分的资产。

  • 评估届时将退役的资产的 future 账面价值。

  • 将此作为退役的迁移成本包括在内。

整理和调整全方位商业案例

在为每对情景准备好全套成本后，为每种情景构建贴现现金流报表并绘制图表。我们建议在硬件更新周期的同一时期内建立有针对性的业务案例。服务器、存储设备和网络设备通常为 5 年。当您使用与硬件更新周期相同的时间段时，每种场景的按原样成本中包含一次更新的成本。

然后计算获得批准以进入该计划的下一阶段所需的关键财务指标。我们通常包括以下内容：

  • 净现值（NPV），用于衡量所评估的成本削减和生产率提高的绝对价值

  • 以月为单位的投资回报期，以验证回报是否足够快

  • 最终的运行速率比较，以验证该过程在整个期限内是否节省了足够的成本

  • 投资回报率 (ROI) 和修改后的投资回报率 (MIRR)，用于评估该计划的相对财务业绩，而不是贵组织可能优先考虑的其他资本需求

使用案例的第一次迭代来确定预期的财务业绩是否意味着应该进行改进，如以下示例所示：

  • 如果投资回报太慢，可以考虑加快迁移速度并降低迁移成本的选项，例如：

    • 使用 AWS 合作伙伴或 AWS 专业服务来扩展可用资源，并使用更基本的模式进一步并行迁移工作负载。

    • 对于在 VMware 中运行的工作负载，请将迁移策略与重新托管或平台重置策略进行比较，至少在初始阶段是如此。使用迁移策略可以降低迁移成本并提高迁移速度。

    • 在技术上可行的情况下，将需要更复杂的平台重构或重构（重新架构）策略的工作负载推入未来阶段，超出最初的业务案例范围。

  • 如果 ROI 和 MIRR 太低，请考虑以下几点：

    • 你正在考虑的情景是否过于保守？ 您是否有一种情景可以反映最有可能的容量增长和弹性需求？ 您是否有方案可以比较目标中包括服务质量提高在内的成本？

    • 您能否完善要在第一阶段迁移的应用程序组合的范围，将重点放在能够带来更高回报的工作负载上，例如当前利用率较低或灾难恢复 (DR) 需求昂贵的工作负载？

    • 能否完善应用程序组合的范围，以便在最初排除商业化程度较低的特定工作负载？ 例如，由于公共云基础架构中的部署条款不同，第三方软件许可证变得更加昂贵的工作负载，您能否推迟这些工作负载？

  • 如果最终的运行速率比较未达到预期目标，请探索以下内容：

    • 首先，确认其他指标是否符合预期。方向性商业案例主要是为了表明有足够的财务机会来证明启动下一阶段的迁移准备是合理的。

    • 确定在迁移初始阶段 AWS 之后继续提高成本效益的机会清单。

在准备详细的商业论证时，包括对机会清单的评估。此外，在案例的持续维护和迁移完成后 month-to-month 的成本优化流程中包括机会评估。