第一部分 采用阶段

如果您刚刚接触云计算，那么很可能提出这样的问题：“云计算对我的组织而言意味着什么？”“我该如何开始？”“需要做出哪些改变，又该遵循怎样的顺序？”“我将面临怎样的挑战？”“团队中的哪些成员应该参与其中？”以及“我该如何与同行们交流云转型意见？”，等等。而这些，正是本部分打算回答的问题。

大多数打算利用云服务实现重要目标的企业，都整理出了自己的广泛业务驱动因素与转型计划。这些驱动因素往往与文化、财务或者创新相关，但鲜有高管人士会从技术的角度持续追踪。在大多数情况下，这些努力主要受到主观愿望或客观需求的推动——例如希望进一步提升商业竞争力，或者在组织内建立起更强大的现代化数字功能等。

针对这样的期望，目前存在多种不同的表达方式：IT现代化、云优先、大规模迁移等。但相信大家最常听到的，还是“数字化转型”。

从某种意义上讲，“数字化转型”让你无可非议。大多数高管都会认同其中承载的意义，即企业能够从更高的自动化水平中受益，并借此为客户提供更出色的体验。话虽如此，但在我看来，数字化转型从开头、到中间、再到末尾，都有些闲扯的意味。

但我也不会一味加以否定。如果大家希望以数字化转型为手段推动组织改进，或者按照管理咨询下达的指令而行，那么你尽可放手去做。不过必须强调的是，我们的最终目标绝对不是对技术形态做出转变达到某个预设的目标——而是我们要建立面向技术的快速部署能力，从而满足组织内的业务需求，至于技术的来源反而不再重要。

另外，虽然我不喜欢数字化转型这样的表达，但我承认建立数字化能力或者实现数字化原生能力是个漫长的过程，且往往充满挑战与阻碍。

每一家公司的转型之旅都会有所不同，但我在其中发现了一些常见的模式与共性。很明显，企业高管更乐于向拥有相关经历的人们学习。在与数百家企业进行会面的过程中，我一直在关注他们各自的转型过程与进步方式，并总结出了一套所谓的非完美模式。这些阶段（第一阶段：项目；第二阶段：基础；第三阶段：迁移；第四阶段：重塑）代表着大型组织在逐步迈向数字化企业的无止境的过程中，所必然经历的一切。

第一阶段：项目（第2章）

如您所料，大多数组织会以少部分项目为起点，试验如何以不同方式建立IT体系，同时探索云计算能够带来怎样的实际收益。由于大多数组织在起步阶段往往缺乏（甚至根本不具备）云技能，因此我一般建议他们选择一个人们相当关注、但又不致太过重要的项目（换言之，不致因项目失败而令您被公司解雇）。而在熟悉了云服务的使用感受之后，大家往往会自发地做出更多探索。

第二阶段：基础（第3章）

在这一阶段，高管们开始意识到：“好吧，现在我们需要认真探索一些真正的可能性了。为了应对这种规模化尝试，我们需要进行几项基础性投资，从而立足组织内部建立新的能力。”在这一阶段，我们通常会建立一支专门负责转型工作的跨职能团队（我们称之为云卓越中心，简称CCoE，详见第24～31章）并部署“AWS登陆区”，旨在为云资源的规模化利用建立正确的治理与运营模式。

第三阶段：迁移（第4～9章）

随着这种基础性能力的建立，我们观察到各类组织通常开始意识到云计算的介入，能够帮助他们逐步摆脱以往累积的技术债务，从而更专注于实施创新活动。到这一阶段，他们往往已经开发出商业案例，用以量化将遗留系统迁移至云端所能实现的具体收益。

第四阶段：重塑（第10章）

随着企业IT的布局由内部转移至云端，企业通常会发现自身的运营状态得到显著改善，特别是拥有更为强大的IT成本以及业务功能（包括产品与服务）优化能力。包括GE石油与天然气公司在内的很多企业意识到，在将应用程序迁移至云端的过程中，他们积累起大量专业知识并能够更轻松地借此完成应用优化。也有不少组织开始感受到自我重塑的意义，并将自身新拥有的功能应用到整个业务流程中。

逐步实现云优先

在这些阶段，我们看到许多组织进入“云优先”状态。在将技术解决方案应用于自身业务时，这些组织已经将“我们为什么要使用云”的问题转化为“我们为什么不使用云”。

不同的企业可能在其旅程的不同阶段建立起云优先政策。一部分拥有自信直觉的CIO们会尽可能早地在旅程当中宣布云优先；有些人会建立起精心设计的商业案例，从而在实际进行云迁移之前首先证明云优先的意义；有些人为积极开发者或者影子IT提供空间，从而将云优先的思维逐渐引入企业之内；也有一些人以试验性方式推进云项目，并通过一个接一个的项目实现云优先（我在道琼斯选择的就是最后一种方式）。

因此，尽管很难为每家组织确定公布云优先的正确时间，但组织内存在的不少特定因素能够有效简化这一流程。

首先，很多企业将自身认为多个松散耦合、独立管理业务单位（简称BU）的集合体。根据企业的不同，这些业务单位可能拥有着不同的技术决策自主权。一部分企业拥有高度集中的模型——即中央IT部门负责选择及控制哪些技术方案能够跨业务单位使用，另一部分企业给予各个业务部门自行制定技术决策的自主权，而大多数企业介于两者之间。

在组织之内，技术决策的结构方法没有对错之分，我们真正需要关注的是，在集中化（效率与标准化）与自治化（上市时间与创新）之间寻求平衡点。在与广大企业高管的接触过程中，我发现人们越来越支持后一种方法。在这部分内容中，我们将共同探讨未来的技术组织结构、Amazon.com提出的双披萨团队概念，以及如何引入云卓越中心并发挥作用。

***

虽然我将这些采用阶段作为一种连续串行的过程，但也发现某些拥有多个业务单位（这些单位间往往彼此无关）的企业可能同时并行处于不同阶段。因此在组织之内，这种多个阶段并行存在的情况亦属正常，而且能够在理想情况下带来更为广泛的飞轮效应。

希望这里提到的采用阶段能够帮助您了解其他组织正在经历的转型情况，并思考如何将这一模式应用于您自己的组织。我们也期待着能够听到来自您的真实声音与反馈！