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

# 详细业务案例
<a name="detailed-business-case"></a>

在此阶段，我们建议验证并扩大业务案例的范围，以提供更详细的信息来支持转型计划。快速整理的初步方向性商业案例旨在提供足够的信心，以投资于基础步骤和下一级别的详细规划。 

制定详细的商业案例可通过以下方式支持这一规划过程：
+ 提供财务分析，为决定哪些内容应迁移和现代化、选择哪些选项以及如何分阶段和确定工作的优先顺序提供依据
+ 通过详细重新审视，验证、完善和发展最初的定向财务案例：
  + 降低基础设施成本的潜力
  + 内部 IT 工作效率和任何外包运营效率
  + 项目设置、迁移和现代化所需投资的估算
+ 识别、估计迁移带来的更多价值驱动因素，并设置流程以跟踪迁移带来的更多价值驱动因素

在详细的商业案例中，您可以确定以下内容：
+ 确保至少执行第一阶段迁移的任务和投资的客观基础
+ 该计划的基准最低财务业绩预期
+ 明确制定各种移民设计和优先顺序决策的财务基础，这样当情况和人员在计划过程中发生变化时，新的领导层可以做出明智的选择。
+ 在工作负载迁移和开始运行时，初始使用数据可用后，深入了解成本优化的增量领域
+ 估计云转型通过提高弹性和敏捷性为业务带来的价值 
+ 相关的 KPI、指标和假设用于估算弹性和敏捷性提高所带来的财务回报，然后构成推动计划实现主要收益的基准

## 确定案例所需的场景
<a name="determine-scenarios-needed"></a>

在构建详细的商业论证时，通常需要开发多个场景来支持商业论证的不同用途。 

**最小变化情景** — 要评估最低财务业绩预期，请准备一个假设现状发生最小预期变化的情景。作为最坏的支持，这种情况在获得移民投资的授权时提供了有用的支持。此情景对容量增长的最低预期程度以及其他服务质量需求（例如可用性和弹性）的最小变化进行建模。对于当前的运营模式，最少的变化会带来最低的成本和最少的资源效率低下。

**最有可能的情况** — 为了为计划策略和优先级决策提供信息，请准备反映企业预期情况的情景。此情景应包括可能的峰值利用率增长或减少以及升级成本，以满足业务对高水平服务质量（尤其是可用性和弹性）的需求。

**其他具体情景** — 如果仍然需要做出可能对商业论证产生重大影响的假设，则制定假设是否成立。但是，我们建议将这些替代方案的数量保持在绝对最小值。任何超过三四个场景的总体进展缓慢，并且会变得昂贵、混乱且难以维护。尽可能进行实验并努力消除更大的假设。

## 验证和完善基础架构和迁移成本模型
<a name="validate-refine-infrastructure-migration-cost-model"></a>

完成投资组合分析并准备好目标的设计和规模后 AWS 服务，针对每种情景完善当前运营模式 (COM) 和 future 运营模式 (FOM) AWS 的运行成本估算。通常需要完善以下各项的估计值：
+ 虚拟机管理程序主机服务器、裸机服务器、存储、网络设备、安全设备硬件更新、安装和维护的 **COM 基础架构成本**。使用场景所需容量的实际定价和折扣级别来计算这些值。
+ **COM 数据中心和并置设施的成本**，包括空间、冷却、电源、机架、不间断电源 (UPS)、电缆、物理安全系统，其规模适合增长并指定满足容量，以及该场景的高可用性和灾难恢复 (DR) 级别。
+ **COM 网络服务成本**，包括广域网链接、内容交付网络和虚拟专用网 (VPN) 的成本，使用合同定价来计算该场景的连接、带宽、吞吐量和延迟需求。
+ **COM 应用程序和基础设施软件成本**基于现有合同，用于提供场景中使用量的增长或减少。
+ **FOM AWS 公用事业成本**，包括所需的技术支持和托管服务，具体取决于完善的服务架构、实例大小、首选定价模式、预期使用量和使用波动性。
+ **FOM 应用程序许可**基于最终的应用程序设计、运行应用程序的基础架构的配置、随时间的增长以及许可证可转让性规则。
+ **FOM 迁移和现代化成本估算**，经过细化以反映该场景的基准迁移浪潮计划，并详细提供了每项工作负载的成本，尤其是那些要进行平台重建、回购或重构的工作负载。 
+ **FOM的退役成本**，包括资产注销和合同提前终止成本的估计，进行了修订，以反映基准迁移浪潮计划中的退役时间，核实哪些资产可以重新利用，哪些资产可以转换以最大限度地减少核销，以及处置实物资产和媒体的成本。 
+ 对@@ **迁移并行运行成本**进行了细化，以反映每次迁移切换和每个现有服务停用的时间。

## 完善 IT 生产力和 IT 运营并支持效率价值模型
<a name="refine-it-productivity-it-operations-support-efficiency-value-model"></a>

与定向业务案例一样，有两种主要方法可以完善和开发围绕IT运营和支持的价值模型。您选择的方法取决于COM是由内部管理还是由承包商或外包服务管理：

### 提高内部团队的工作效率
<a name="internal-team-productivity-improvement.53441e7b-2d1e-5e42-81f0-ed1ddac9abde"></a>

在 IT 运营和支持由内部管理的情况下，业务案例的重点是以下方面：
+ 识别并量化迁移和范围中包含的任何操作自动化所带来的生产率提高
+ 验证为内部团队腾出的时间可以轻松而富有成效地应用于其他通常价值较高的活动，从而为团队提供进步和更大回报的机会，为组织提供更多价值

评估福利需求，分析团队中每个角色的每个成员在各种常规活动上花费的时间，并就不同活动的工作量预期减少提供指导。 

对于那些消耗团队中不同角色的大量 IT 操作和支持工作的任务，下表提供了按活动减少工作负载的典型水平的初步指导。该表包括对如何实现生产率的描述。 

**注意**  
****列出的活动通常由担任多个不同角色的团队成员执行，因此应根据团队中所有角色评估每项任务节省的生产力。例如，在按基础架构塔（例如计算、存储和网络）组织的 IT 运营团队中，资本支出规划和预算对每座塔楼的主管来说可能很常见。 


| 
| 
| 业务和支助活动 | 储蓄水平 | 生产力驱动因素 | 
| --- |--- |--- |
| 基础设施设计 | 中 | 简化了设计，需要考虑的参数更少。 | 
| 资本支出计划和预算 | 高 | OPEX-centric 弹性服务几乎消除了所有预算和规划问题。 | 
| 采购 | 高 | 建立后，采购工作 AWS 账户 大大简化。 | 
| 容量规划 | Medium-very 高 | 网络和计算容量管理工作负载通常几乎可以消除，而对于存储，则大大简化了 | 
| 优化 | High-very 高 | 托管服务不需要调整，其他服务也几乎不需要调整，因为可以随时更改实例的大小。 | 
| 管理硬件故障 | 非常高 | 在云端处理硬件的所有方面都由 AWS透明地处理。 | 
| 监控服务器可用性和通信 | 高 | 通过 AWS 工具支持和自动化，可以大大简化监控和通信。 | 
| 安全管理 | 中 | 通过 AWS 安全功能以及承担 AWS Cloud 硬件、软件、网络和设施 AWS [的安全责任](https://aws.amazon.com/compliance/shared-responsibility-model/)，工作量显著降低。 | 
| 网络和存储升级、维护和补丁。 | 非常高 | 云端网络和存储维护的所有方面都由 AWS透明地处理。 | 
| 机架和堆放-硬件物流 | 非常高 | 云端硬件管理的所有方面都由 AWS透明地处理。 | 
| 备份 | 中 | 借助 AWS 工具、灵活的存储系统和自动化，Backup 得到了极大的简化。 | 
| 托管服务（例如 Amazon S3、Amazon RDS 和 AWS Fargate） AWS Lambda | 非常高 | 托管服务在完全由管理的环境中运行 AWS，因此无需维护、修补、监控或配置管理活动。 | 
| 设备和服务的设置和调试 | High-very 高 | 除了用于建立 VPN 或 AWS Direct Connect 与 AWS 数据中心连接 AWS 的 WAN 连接设备外，迁移到的资产的硬件设置活动通常会减少。 | 
| 端点保护和防病毒保护 | 高 | 作为迁移设计的一部分，端点保护和防病毒服务的应用和维护通常会被广泛自动化。 | 
| 威胁、漏洞和风险评估 | 高 | AWS 为其中的要素提供支持，重点是核心平台和为安全架构 AWS 提供的机制简化了评估。 | 
| 数据中心基础设施项目管理 | 高 | 基础设施服务扩展、更新或停用的安装工作的项目管理。尽管仍对基础设施软件和服务进行一些管理，但这比本地基础设施要简单得多，而且无需进行硬件活动。 | 
| 数据中心设施管理 | Medium-very 高 | 所有迁移的设备都将移除归因于所有服务器、存储设备、安全设备和相关机架的设施管理工作。但是，在为广域网链路网络设备和混合架构中保存在内部的任何基础设施提供设施方面，通常还有一些工作要做。 | 
| 应用程序架构、开发、管理和测试 | 低 | 使用敏捷开发工具链，再加上应用程序堆栈实例化和销毁的自动化以根据需要构建测试环境，可以缩短应用程序开发的交付周期，并消除许多手动测试步骤。 | 
| 安装和配置应用程序软件 | 中 | 使用诸如之类的服务可以很容易地自动完成整个应用程序堆栈的安装 AWS CloudFormation 和配置，并通过使用着陆区来简化，使用着陆区可以很容易地进行配置 AWS Control Tower。 | 
| IT 支持 | 中 | 通过使用 Service Catalog 功能进行自助配置、更多地使用低成本的高可用性架构（减少中断以及配置自动扩展和边缘计算）来减少容量和性能问题，从而减少第 1 层和第 2 层支持。 | 
| 数据库管理 | Minimal-low | 这些活动基本保持不变。它们通常与本地基础设施的 AWS 资源水平相同。 | 
| 基础设施和安全需求的捕获、分析和设计 | Minimal | 
| 文档 | Minimal | 
| 应用程序和性能监控 | Minimal | 
| L3 技术支持、回答疑问以及故障排除和问题解决 | Minimal | 
| 安装和配置应用程序软件 | Minimal | 
| 应用程序 L3 支持（不包括预算和长期容量规划） | Minimal | 

下表显示了每个工作量减少级别的预期节省。


| 
| 
| 级别 | 预期 | 
| --- |--- |
| 非常高 | 85%-100% | 
| 高 | 60%-90% | 
| 中 | 30%-70% | 
| 低 | 10%-35% | 
| Minimal | 0%-10% | 

这些指标为评估生产率提高并将其纳入详细的业务案例提供了一个起点。实际生产率的提高因具体情况而异。计算区间中端和下端的生产率节省可能很有用，以估算典型和保守情景。

随着计划的进展，按角色捕获每项活动所花费时间的实际数据非常有价值。这些数据为估算运营奠定了更好的基础，并支持了新项目和服务扩展的成本。

### 外包 IT 运营和支持成本降低
<a name="outsourced-it-operations-and-support-cost-reduction.70fe627e-2de5-52d3-88db-07b52dd802eb"></a>

如果 IT 运营和支持主要外包或由承包商管理，则可以通过向提供托管服务解决方案的 AWS 合作伙伴索取报价来准备未来运营模式 (FOM) 的成本分配，包括。 AWS Partner-led [AWS Managed Services](https://aws.amazon.com/managed-services/partners/)您也可以联系您的 AWS 客户经理，直接索取 AMS 的价格，如[创建定向商业案例](directional-business-case.md)部分[中关于运营成本优化的构建](directional-business-case.md#building-operational-cost-optimization)小节中所述。

要了解详细的业务案例，请将任何基准数据替换为基于修订后的物料 AWS 服务 清单和预期服务消耗、AMS 套餐和所需的任何选项以及所需服务级别的报价。成本将包括一次性实施部分和基于消耗的运行率。 

包括所有剩余的 IT 运营、必须为任何不会迁移到的服务保留的支持 AWS，以及如果有合同罚款（例如，提前终止），则需支付一次性费用。

## 开发弹性价值模型
<a name="develop-resilience-value-model"></a>

在上 AWS，您可以构建各种高可用性、灾难恢复和容错架构。 Consumption-based 定价意味着仅在使用服务时才收费。这两个因素共同为弹性提供了卓越的成本性能。 

此外， AWS 客户一直在使用它来提高其工作负载的弹性。[IDC 2018 调查](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770)举例说明参与的客户每年减少了 73% 的停机次数，平均恢复时间 (MTTR) 缩短了 58%，生产力损失减少了 94%。同一项调查显示，通过提高弹性获得的财务收益比降低IT基础架构成本的收益高出50％。 

此外，通过对应用程序的软件开发生命周期进行现代化改造，可以进一步提高弹性。在引入具有测试自动化的 CI/CD 管道以支持更高的业务灵活性时，可以在开发周期的早期发现软件缺陷，从而大大降低软件维护成本。

要评估这一价值并将其纳入业务案例中，请首先与应用程序业务所有者合作，了解要迁移的每个工作负载的*总体收益机会***。** 这可能包括以下项目：
+ 服务中断的次数、平均持续时间和性质
  + 服务中断的示例包括中断、性能减慢、计划中的批处理和维护窗口超时、关键功能出现错误以及高峰时段的访问限制。 
+ 创收服务（例如电子商务系统）中断对收入的影响
  + 根据中断时间和交易速率，可能因服务中断而无法完成的交易数量
  + 每笔受影响的交易的平均价值
+ 与在开发过程早期发现缺陷的成本相比，支持工程师解决生产系统缺陷所需的额外成本
+ 对内部用户工作效率的影响和浪费时间的成本

然后，对因服务中断而损失的时间进行预期的、更为保守的缩短情况进行评估，而弹性增强应该会产生****这种缩短。例如，考虑包括以下项目：
+ 使用高可用性架构和改进的恢复时间目标 (RTO) 和恢复点目标 (RPO)，减少停机次数和 MTTR
+ 使用自动扩展等功能，减少减速，消除容量限制，避免批处理超支
+ 通过实施 CI/CD 管道以及对启动和关闭的基础设施进行自动回归测试，减少仅在生产中发现的应用程序错误的数量，以最大限度地降低成本

将它们汇总在一起，得出要迁移和现代化的应用程序组合，并计算每个案例年度的预期和更保守的业务价值数字。收益应根据迁移时间表增加，然后根据贡献应用程序的使用量增长预期扩大容量。 

## 开发业务敏捷性价值模型
<a name="develop-business-agility-value-model"></a>

业务敏捷性是 AWS 客户迁移到的主要原因 AWS。[IDC 2018 年 AWS 客户调查](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770)显示，对他们而言，业务敏捷性收益占测总收益的 47%，是基础架构成本降低所得收益的五倍多。

准确预测任何转型将带来的所有业务敏捷性优势是一项艰巨的任务。但是，通过将重点放在支持大量用户或成为业务差异化来源的应用程序上，您可以对这种优势的很大一部分进行建模，并将其纳入基准详细的业务案例中。

随着迁移的进行，随着更多收益可以量化，逐步完善和扩展业务敏捷性价值模型。这样可以使业务案例保持相关性，因此可以将其用作指导计划的主要决策支持工具。

要构建业务敏捷性价值模型，请使用以下指南：
+ 选择有机会推动最大业务绩效改善的工作负载，例如：
  + Revenue-generating 工作负载 
  + 业务运营工作负载有推动效率提高和降低业务成本的余地
  + 支持大型用户群的业务生产力工具
+ 对于产生收入和效率的工作负载，请执行以下操作：
  + 对主要和次要应用程序升级可能推动的收入增长或运营效率进行现实和更为保守的评估。
  + 估计每年增加的主要版本和次要版本数量，从而 AWS 提高了应用程序开发速度并缩短了基础架构部署时间。IDC 报告中提供了这方面的一些基准指标。
  + 计算现实且更为保守的福利预期。在业务论证期间对它们进行映射，以便在相应的工作负载迁移后的一段时间内提高到最大效率。
+ 要使用业务生产力工具，请执行以下操作：
  + 对主要和次要应用程序升级预计可以节省的时间进行现实和更为保守的评估。
  + 估算受影响用户群中人们的时间和精力的平均成本。
  + 使用这些数字来计算主要和次要发布频率的增加，并计算业务案例期限内的收益。

由于提高开发人员的工作效率和缩短的发布时间不需要额外的资源，因此将每个工作负载的净收益项目添加到业务案例现金流模型中，以便包含在折扣现金流、净现值、投资回报率、MIRR 和投资回报计算中。