万字长文 | 微软“刷新”的背后，Satya未讲的另一半故事

2018年的最后一天，微软以7798亿美元市值，超过苹果的7491亿美元以及亚马逊的7344亿美元市值，而跃居全球最高市值公司，并以这个记录结束了整个2018年。就在2013年前任微软CEO Steve Ballmer宣布要退休的时候，业界认为微软已经在移动互联网和智能手机时代落后，对于微软的前景并不乐观。然而，就在2014年2月Satya Nadella上任新CEO后，微软出现了巨大变化，在云计算时代迎头赶上，并在短短4年里创造了新的辉煌。

在很大程度上，Satya把微软自己的成功转型归结于文化转型，甚至亲自出了一本正在进行中的类传记体书《Hit Refresh》，记录了这次微软大转型中很多不为人所知的幕后事情，特别是领导力与文化的转型，引起了业界的极大振动。Satya提出的“同理心”文化，以及一系列从领导层开始扭转企业文化的努力，被业界视为微软成功转型的“法宝”。也有不少企业试图学习微软这种自上而下的文化变革。

然而，微软的文化变革之所以成功，并不完全是因为Satya所发起的自上而下的公司整体文化变革。要知道，在2014年，微软是一家有着12.8万员工的跨国公司，其中6.2万员工位于美国、6.6万员工位于美国之外的其它国家和地区，在100多个国家有办公室。对于这样一个国际化运营的公司来说，6.6万位于不同的国家和地区的员工讲着不同的语言、有着各自的文化和信仰、而且都是高级知识型员工，对不同的外来理念有着不同的理解，可以说是新时代的“乌合之众”，那么微软又如何推动文化变革呢？

其实，今天有很多企业都遇到同样的问题，特别是那些国际化运营的超级大公司，仅仅依靠领导层的意志而进行的文化变革，到中层及一线员工后往往走样变形而导致最后“流产”。但微软的文化变革之所以成功，还在于Satya清楚地知道必须要借助技术平台发起自下而上的变革，要把变革的工具和能力交到每一位员工的手里，让员工自发地完成组织行为变革，才是真正的成功之道。

微软认为，在任何数字化转型中，技术和文化的变化都是相辅相成的。微软核心服务工程和运营（Core Services Engineering and Operations，CSEO）的前身为微软内部IT部门，而微软IT跟其它公司的IT部门一样都是以流程为中心的思维模式、僵化的人工操作模型和不连贯的客户体验。随着微软整体上云，CSEO转向基于微软Azure的运营模型，该模型使用现代软件工程原理，例如可扩展性、敏捷性和自助服务，这些都专注于提升客户体验。

在云端，打通数据

对于微软来说，自身的转型第一步就是把整个微软都搬到云平台上，通过云平台打通所有部门的数据，不仅让公司能够更加敏捷地响应市场变化，而且让统一的数据成为全公司的新沟通“语言”——虽然各国员工讲着不同的语言、有着各自的文化，但显然大家对于数据的理解是高度一致的。

微软与MIT Sloan管理学院的CISR信息系统研究中心（Center for Information Systems Research）合作，调研了微软在自身的数字化转型过程中，是如何成为一家基于云的数据驱动型公司。实际上在云业务成为主导业务之前，微软作为一家产品型公司，有着Windows、Office、Xbox等相互独立的产品线，有着各自的P&L损益表，每条产品线都像一家独立公司那样运营，导致微软内部相当的分裂。而在产品为王的时代，很多公司都像微软一样，有着彼此相互独立的明星产品线，明星产品线都是数据孤岛和组织孤岛，彼此之前既缺乏协同也没有数据的打通。在数字化转型的过程中，越来越多的企业像微软这样试图成为一家平台型公司，这就要求打通企业内部的资源，以一个平台的方式统一对外服务客户。

MIT Sloan CISR认为，微软能否成功转型为一家云服务公司，取决于它的业务流程、企业文化和员工心态转向数据驱动型。通过获得更多数据和更好地使用数据，提高微软对客户需求的理解和响应能力，而这也是有效交付云服务的关键。Satya也经常对公司内部和外部广泛地谈论对数据的日益依赖，他认为向云的转型是颠覆性的，但更重要的是云所驱动的数据，以及数据所带来的新价值。

从2014年开始，微软开展了三项面向数据的工作，以促进业务模式和组织文化的转型。首先，高层管理人员利用新指标丰富了绩效管理流程，以更好地监控云服务以及确定市场需求。其次，业务领导层整合并重新设计业务流程，以便员工可以更有效、基于事实证据的方式工作。第三，微软对内引入了自助服务分析工具套件Power BI，该工具可促进整个微软的数据和分析最佳实践，并启发基于事实证据的决策方式。到了2017年，微软有61%的员工每个月都在使用Power BI。

在为高管建立新的绩效管理方式方面，为了更好的识别那些具有丰富数据的系统以及鼓励跨部门之间的数据共享，Satya主持了一个构建“高管仪表盘（Senior Management Dashboard）”的黑客马拉松（即一群志愿的技术高手在几十个小时里接力开发一个软件），微软各业务部门合作建立了一个高管仪表盘：该工作找到并确认了那些包含关键数据的系统以及相关负责人，它还减少了微软内部数据孤岛和跨部门共享的阻力。

微软Power BI的首席产品经理Patrick Baumgartner表示，团队很快就开发了一个基于Power BI的在线“高管仪表盘”，为每个业务部门的数据开辟了一列，同时写上“N/A”（无效）或“TBD”（待定），这样很快所有业务部门都纷纷找上门来，因为他们希望出现在Satya的仪表盘上。为了鼓励这种跨部门的数据发布和数据共享，Satya开始定期使用这个“仪表盘”。很快，微软的其他高管也效仿Satya那样为自己负责的业务单元开发了管理仪表盘。

某些具有跨公司意义的指标，尤其是反映客户参与度的指标，得以在整个微软公司范围内共享，各业务单元以各自的方式使用这些共享指标。例如，市场营销部门通过这些指标来学习如何更有效地与客户交互，包括通过产品向客户传递品牌信息，从而实现更广泛和更深入的客户参与；产品工程开发团队则通过这些指标来提升服务质量，从而提高了云服务的采用和消费。

微软当时的首席信息官Jim DuBois为了开发IT部门的高管仪表盘而组建了一个三人小组，随后让其他高管也可免费使用这个小组，这样就让整个微软的高管团队都在短时间内开发了自己的高管仪表盘。

随着微软向云服务的转型，微软原先产品导向的企业文化成为了服务导向战略的阻碍，Satya于2015年开始着手整合公司的核心流程（销售、市场营销等），一方面鼓励开放的平台型企业文化而不是孤立的产品型文化，另一方面让微软以“统一界面”面对客户。而微软IT也分为了两部分：一部分以共享IT服务方式提供核心企业服务功能，一部分则与业务部门合作以服务业务部门的需求。为了鼓励跨部门的协作，微软调整了员工激励机制，员工在整个组织中的协作情况成为了员工绩效评估的三大核心支柱之一。 

以销售流程为例。在销售部门内，销售高管确定基于云的服务要求采用全新的、以服务为导向的销售方法，而这要求对所有云服务产品进行全面查看，包括客户采购、支持请求、市场曝光以及客户与微软的各种沟通。然而，为了收集这些数据以形成微软的整体公司视角，销售主管不得不从多达80个不同的系统中扫描、手动选择并提取数据。为了解决效率低下的问题，微软的销售高管选择重新设计核心销售流程，包括潜在商机管理、销售机会管理和预测。销售高管们希望微软的销售人员花更多的时间与客户互动而不是收集数据。而如果从企业的系统中通过计算得到洞察，就能取代低效的数据收集。

为了达成面向服务销售的统一公司视角，销售高管们重新定义了共享的销售概念，例如什么是“销售管道”（pipeline）或“潜在商机”（lead）”，并在销售人员、销售主管以及IT部门等相关组织中达成共识。其中，关于什么是“潜在商机”（lead）”的讨论就长达一个月，最终达成共识，即一个“潜在商机”（lead）”就意味着一个可联系的企业客户，并据此重新设计销售平台和数据模型。接下来，销售主管们们试图找到相关的内部数据源以连接到新的公司平台上，然后就发现已有的数据源非常分散。微软的销售和共享服务IT以及相关业务部门在一年的时间里开发了一个全新的销售平台，即Microsoft Sales Experience（MSX），该平台对销售数据进行筛选和整合，以产生微软与企业客户关系的360度视图。对于每一个企业客户，该新系统都概述了采购历史、详细的问题和投诉，并将沟通存档。微软的财务、营销和人力资源等共享职能部门，都经历了类似的转型。

随着微软高管和员工越来越依赖数据做出决策，微软IT投资并建立了四个企业共享服务组——数据、数据科学、变更管理和商业智能。其中，数据组为微软内部共享的所有数据建立了一个“单一的真实来源”（例如提供给华尔街的财务指标、一个共同的国家列表等）。工作组确保核心数据符合预期的质量标准，并致力于纠正数据质量问题。此外，该小组还赞助和/或与数据治理委员会合作，以解决业务相关负责人之间的问题、控制数据访问并找出应该集中管理的共享数据。数据科学组则负责微软内部分析和机器学习的“全民化”，该团队与IT和非IT同事合作，以确定需求并创建企业数据服务。例如，数据科学小组和IT中的安全专家一起开发了可以改进安全和风险管理实践的分析技术；在IT之外，这个团队和基础设施的同事利用分析技术创建了“智能”建筑供暖和制冷解决方案。变更管理组则专注于设计和交付服务，以改进整个组织对分析工具的采用。例如，团队与业务流程负责人一起准备专业的培训材料，并与业务单元一起监控采用率。

值得一提的是商业智能组，又称为BI@Microsoft。BI@Microsoft需要依赖频繁且可扩展的沟通策略来推动BI自助服务。该计划赞助了一个网站，其中包含手册、视频和快速入门指南，用以回答“什么是数据，我如何在我的世界中使用数据?”该计划还发布了每月通讯，提供在线课程，以及举办线上办公活动。BI@Microsoft团队使用Yammer来培养互动社区。Yammer社区成员彼此响应回答问题、分享想法、激发创新。BI@Microsoft的领导者还通过雇佣市场营销人员和培训现有的IT服务团队成员的营销技能来推动Power BI的采用。BI@Microsoft团队依靠微软内部的业务和IT高管来鼓励在本地使用Power BI，嵌入式IT团队（例如销售 IT、财务IT）是推动全公司采用数据服务的重要合作伙伴。 

“全民”数据驱动的文化，让微软扩展云平台和服务方面取得了显著的成功。 2016年最后一个季度，Microsoft Azure的使用量增加了一倍以上，成为第二个最受欢迎的云平台，并使微软获得了显著的云市场份额。

数字化转型的指标示例

微软自身的数字化转型由微软IT也就是后来的微软核心服务工程和运营 (Core Services Engineering and Operations，CSEO）部门主要负责推动。微软CSEO开发了一个大数据可视化解决方案，可以总结和跟踪重要的业务流程和系统。该解决方案与常规流程集成，并将大量数据提炼为准确且可执行的信息，以供整个微软内部组织使用。凭借该大数据解决方案，CSEO提高了员工满意度、推动公司业务增长，并在数字化转型的道路上驱动运营效率。这个解决方案就是CSEO记分卡，它改变了CSEO理解和管理业务的方式。而CSEO记分卡仪表盘，是微软高管仪表盘的代表之一，主要服务于CSEO负责人既早先的微软CIO Jim DuBois以及后来的CSEO负责人也是微软首席数字官Kurt DelBene（Jim DuBois离开微软后由Kurt DelBene接任并更改职位名称为微软首席数字官）。

在微软, 数据无处不在。随着微软持续向数字化转型迈进, 微软数字系统和流程产生的数据近乎泛滥。微软的业务流程不断产生各种日志和事件数据, 从员工满意度到财务结果, 再到安全合规性。在任何时候,微软的系统都会有数千个关于正在运行进程的单独数据点。在完整的CSEO组织系统流程状态视图中，根本没有可行的方法来表达每个单独的数据点。即使收集和汇总数据，重要数据和信息也会在大量平均值和中位数计算中丢失。

了解哪些是重要数据，这是现代IT组织面临的另一个挑战。在微软这样拥有超过12万名员工的全球性组织中，确定哪些数据对整个组织和各个业务部门很重要，这本身就是一项艰巨的任务。

微软CSEO如何收集和汇总相关数据？如何决定哪些数据提供了对组织最关键业务流程的可见性, 以便更好地监控、理解和管理业务？微软CSEO高层提出了一个简单的请求，以便更好地了解CSEO的运作：提供一个显示前35个指标的在线仪表盘，这些指标要展示微软CSEO组织运作情况。这个请求看似简单，但要满足该请求却并非如此。在CSEO的环境中存在的数十万个单独指标，如何找到对某个高管最重要的35个指标？CSEO团队不得不问自己一些重要问题，例如：CSEO的工作是什么以及如何衡量？如何确定哪些指标是正确的或最重要的指标，从而可以放在仪表盘上？哪些指标将战略性地推动微软的业务向数字化转型？而最后的这个问题，为高管仪表盘提供了方向。

整体开发流程涉及CSEO组织各部分的利益相关者，CSEO记分卡开发团队要求系统和流程的负责人提供意见, 他们知道什么是其部门中重要的数据，这也是获取指标的主要手段之一。一旦通过不断讨论过程建立了指标，就能够创建一个解决方案, 能够检查和使用这些指标并着手进行改变。整个开发过程类似于以下步骤：1，CSEO从领导团队中获得方向和目标；2，与整个CSEO组织的系统和流程负责人展开回顾和指标讨论；3，查看系统和流程负责人收集的指标；4，查看领导团队列出的第一个指标列表，并优化领导仪表盘上显示的主要指标列表；5，获取领导团队对于指标的批准；6，创建和测试CSEO记分卡；7，确定顶级指标的目标；8，执行第一个CSEO记分卡版本以检测和测试指标的目标；9，完成CSEO记分卡, 并在全组织范围内实施。第1步到第9步花了大约三个月时间，最终结果是通过仪表盘和记分卡解决方案，使CSEO领导团队能够准确、灵活地了解整个组织。

为了确定哪些指标适合该仪表盘, CSEO开发了一组标准：1，指标必须反映组织的战略价值，只需那么要能够推动CSEO朝着目标方向发展的指标，总结为对CSEO和CSEO的客户（微软内部业务部门）都很重要的数据；2，指标提供的数据必须是可操作的，如果指标没有按预期运行, 则希望将其显示在仪表盘上, 以便引起注意并进行处理；3，指标必须及时准确，如果支持指标的数据不是最新的或没有准确地代表业务状态的话也没有帮助，微软高层的业务回顾每月进行一次, 因此更新频率低于每季度一次的指标就没有用处；4，指标必须易于理解, 并有明确的定义，指标要清晰简洁, 不需要进一步的推断或参考卡来解释其代表含义；5，指标必须要有至少一年的有效数据支持，想要了解CSEO从现在起一年后的样子就意味着捕获重要的业务数据，而且这些数据要可持续；6，指标需要有明确的价值和时间表，需要确定指标的目标以及实现这些目标的时间表，如果无法建立准确的时间表来改善表现不佳的指标，那么它就不应存在于领导力仪表盘上；7，指标必须具有单一负责人，负责指标的统一定义、统一获取数据以及协助咨询如何将该指标用于更高层的领导力记分卡上。

除了选择标准之外，CSEO开发小组还与领导团队合作，为CSEO仪表盘报告的内容建立了高级目标。CSEO的领导团队想要一个真正有益于业务的方案，为仪表盘提出了三个主要目标：提高员工和供应商的满意度，改善为CSEO工作的体验，这意味着提高员工和客户的满意度；实现增长，能够帮助CSEO规划未来发展并作为一个组织朝着正确的方向前进；提高运营效率，运营效率是数字化转型愿景和其根源的重要部分。

另一个重要的考虑因素是CSEO组织的不同部分对整体的贡献，将微软的组织分解为主要业务和职能部门，使CSEO能够应用已经设置的指标。这些类别是：1，工程，此类包含跟踪管理IT运营绩效的指标，指标包括重大事故、未实现收入、数据中心打补丁；2，效率，此类指标旨在衡量能否最大程度利用CSEO资源，指标包括每个项目启动的成本、按时交付给客户（业务部门）；3，合规，此类指标展示了CSEO在合规性方面的立场, 包括法律合规性和内部策略合规性等重要领域，指标包括合规应用程序的可获得性、全生命周期的安全开发、DevOps工具包的合规性；4，成本和人员，此类指标强调了关键的人力资源和财务方面，指标包括员工与供应商的比率、预算和支出差异（year-to-date，年至今）、预算预测和支出差异（quarter-to-date，季度至今）；5，体验，此类指标告诉CSEO员工、合作伙伴和客户如何参与CSEO的产品和服务，指标包括正面情绪百分比、零售店用户参与度、搜索成功率；6，质量，此类指标具有衡量支持业务服务的关键质量和性能指标，这些指标包括Microsoft Teams会议索引、销售机会转化率。

建立了CSEO的目标和指标后，CSEO开发团队就开始创建仪表盘，命名为CSEO记分卡。CSEO使用以下技术创建：首先是Microsoft Power BI，Power BI为几乎所有高级解决方案的目标提供了现成解决方案，它提供有关实时数据的动态视图以及深入查看数据的能力，可以轻松地与基于云的流程和业务系统集成，并且可以直观、轻松地开始创建数据可视化。实际上，Power BI实施的简易性是CSEO能够在三个月内从构思到构建解决方案的主要原因之一。其次是Azure Analysis Services，利用CSEO记分卡基于云的特性，即可使用Azure Analysis Services进行数据分析，可从庞大的数据集中提取数据，使用不同的模型来操作和表达数据，以支持在CSEO记分卡中构建各种深入分析的功能。

CSEO记分卡改变了CSEO定期组织业务回顾和讨论会议的方式，通过仪表盘显示实时数据以及立即深入查看特定指标和结果的能力, CSEO现在能够简化会议流程，还改进了决策过程。如果会议中出现问题,也不再需要额外的时间来发布额外的报告或与指标负责人协商。使用CSEO记分卡, 就可以公开必要的数据, 找到改进流程的答案, 并在会议期间确定业务方向。记分卡为CSEO建立了新的业务节奏，通过围绕CSEO记分卡创建流程和节奏，CSEO确保拥有最相关和最准确的数据, 并为指标负责人提供时间来验证结果并在进入CSEO月度业务回顾会议之前进行评论。CSEO数据分析师致力于维持CSEO记分卡的业务节奏，他们创建和管理仪表盘, 执行数据分析任务, 并与指标负责人合作, 为记分卡上的指标建立业务和数据标准。

每月的节奏类似于以下：1，此过程的第一步是更新记分卡，所有数据都会刷新和汇总并形成报告，刷新的初始结果将发送给指标负责人，他们有10天的时间来审核结果以确保准确性、找出亮点和缺点，并以评论的形式提供反馈；2，一旦指标负责人查看了刷新后的结果, 数据分析师就会检查评论, 确认亮点和缺点, 并对仪表盘的结果进行必要的更改；3，当数据分析师的更改完成后, 他们会锁定记分卡, 为每月的回顾审查做准备，指标负责人者可以查看最终的亮点和缺点；4，记分卡锁定后，将由领导团队进行月度回顾审核，领导团队使用仪表盘评估业务绩效，确定潜在的行动方案，并创建必要的行动项目；5，在月度回顾审核完成、领导团队与所涉及的指标负责人讨论了行动项目之后，将记分卡发布给所有CSEO人员以供查看。

在筹备CSEO记分卡的过程中, 也遇到不少挑战, 例如：1，指标太多，指标的数量和业务的广泛性意味着很难选择最重要的指标，开发团队最初能够将提供的指标数量减少到近80个，远远超过要求的35个，开发团队继续与高层和指标负责人合作、检查和比较指标，直到能够确定最终在最初CSEO记分卡上的指标只剩下33个，之后进一步减少到了23个，并一直努力创建最适用且可操作的仪表盘指标；2，指标的成熟度，许多指标都没有使用完整或准确的数据集，也没有像所设想的那样更新，很多有抱负的目标必须要面对现实，开发团队与指标负责人合作以提高数据质量并确定指标的实际目标；3，不愿分享信息和贡献，虽然都属于同一个组织，但指标负责人有时会保护其责任范围，他们想知道为什么要关注其业务以及为什么其指标需要向组织的其他人披露，在许多情况下发现指标负责人都保护性的，因为他们认为指标不会对其业务部门有利，事实上CSEO的目标不是让团队受到批评，而只是向领导层揭示改进的必要性，这导致资源得以分配、问题得以纠正、最终使指标负责人得到更好、更有效的过程或系统，开发团队需要向指标负责人展示CSEO记分卡如何帮助他们而不是阻碍或带来不便。

截止2018年底，微软CSEO正在使用记分卡来实现主要目标: 增长、提高运营效率和满意度。CSEO记分卡的优势包括：首先是节约成本和时间，可以利用实时数据进行业务回顾和讨论会议, 并在会议上根据结果制定目标和计划，因此大家从走出会议室走出后就可以马上准备改进，而无需团队和领导之间来回拉锯, 也不需要获得后续数据或信息，一切都在实时中完成。此外, 筹备业务回顾讨论会议所需的时间大为减少甚至完全消除，因为用实时仪表盘进行报告，也无需在开会前创建任何报告或PPT，仪表盘适用于所有内容讨论。其次，快速的质量改进。在仪表盘上采用的指标使CSEO领导团队能够了解业务, 并快速揭示可能需要改进的领域，这样就能快速、高效改进，而一旦启动行动计划就可以监控结果, 以确保改进工作。第三，减少未决问题。凭借仪表盘提供的极高透明度，CSEO可以轻松地查看哪些流程无法正常工作。在六个月内，团队将仪表盘中达到或超过其阈值的指标数量提高了一倍。

CSEO记分卡改变了CSEO理解和管理业务的方式，CSEO已经将它用于常规流程，它为CSEO提供了最明确的运营真相来源。CSEO已经采用了数PB的系统和流程数据，并将其细化为工具，从而为整个CSEO组织提供准确且可操作的信息。通过CSEO记分卡，CSEO在微软数字化转型的道路上提高了满意度，促进了增长并提高了运营效率。由于记分卡仪表盘的成功，CSEO还计划为组织内的每个团队创建二级仪表盘，希望为组织内的小型业务部门提供相同的价值。CSEO还计划为记分卡仪表盘提供更深入的数据详细信息，从更深入、更细致的数据收集中受益。

一切运行在云端

自2011年以来，微软就积极在公司内部推行云计算技术，希望从平台效率、开发灵活性和快速部署功能中受益，微软的愿景始终是“一切都在云中运行”。Microsoft IT（后更名为CSEO，Core Services Engineering and Operations）就在推动Microsoft上云，Microsoft IT上云策略的一部分是将大约2100个业务线应用程序迁移到云平台，这些应用程序当时分布在微软全球8个数据中心、包括40,000多个不同的操作系统实例。

微软IT战略“一切运行在云端”既适用于新应用程序，也适用于在数据中心环境中运行的现有应用程序。微软IT由两大组成部分：业务流程单元（BPU），与公司财务、销售或人力资源等业务流程保持一致，BPU负责内部LOB应用程序（财务、销售、人力资源等）；集中式IT服务，负责各种服务，包括服务器基础架构、SAP实施、安全和架构指南等。为了推动微软自身的上云工作，微软IT专门组建了Stratus团队。

与任何IT部门一样，微软IT的核心任务是创建支持其客户（公司内部其它业务部门）的解决方案、维护和升级服务器、服务器应用程序、数据库以及所需硬件，这是一项巨大的任务；而且维护所需的所有资产包括硬件、数据中心和人员的成本都是巨大的，还有持续的软件更新和安全补丁。为了保持硬件运行，需要每年数百万美元的可观预算。例如，当有新产品发布时，微软IT面临着升级三大洲数据中心的任务，而通过将其大部分基础架构和数据迁移到云，微软IT能够将大部分工作交给Microsoft Office 365服务。

而微软IT的管理层认识到，将应用程序和数据移动到Office 365云，可以改善协作并随时随地访问从台式机或笔记本电脑到平板电脑或智能手机，任何可以运行Office 365的设备都能使用。微软的目标是通过公有云服务托管80％的服务和应用程序，自2011年以来该战略不断发展和完善，调整目标为用公有云覆盖90％以上的IT服务和应用程序。

向云迁移是一个需要仔细规划、执行和沟通的项目，微软IT部使用Microsoft Project软件来管理此次迁移项目，但其实可以使用任何项目管理工具。关键是要遵循良好的项目管理原则，识别利益相关者和风险，建立具有可拆解任务的计划，并设置实际的结束日期，预测每种可能的情况并为意外做好准备。

微软认为分享有关云端迁移消息的沟通计划应该：吸引关键利益相关者和最终用户；尽可能透明；建立最佳沟通渠道（电子邮件、PPT、网站消息）；概述发送消息的时间和安排；使用有针对性的电子邮件；使用相关且及时的信息更新SharePoint网站主页；举办讲解和问答环节；在沟通中加入品牌。

Microsoft IT的上云是一个渐进的过程。在早期阶段，当Microsoft IT开始选择要迁移到云的应用程序时，它对应用程序进行了简单的分类，以确定何时应该将应用程序作为迁移的目标。在评估云迁移应用程序时，团队权衡了两个因素：技术复杂性和业务影响。微软IT从对业务影响最小的最不复杂的技术应用程序开始。这种方法可以让团队构建新的体系结构模型，并提高工程团队的技能，从而在没有很大风险的情况下充分利用新功能。

Stratus团队为每个业务流程单元（BPUs）的云端迁移提供支持，鼓励尽快上云。如果某个部门不想将应用程序迁移到云，则需要证明这样做的合理性。但是一旦决定将应用程序迁移到云端，Stratus团队就会采取“快速试错”的方法。如果应用程序在云端应用的不顺畅，团队就会努力发现失败的原因，探索解决方案。如果暂时无法解决，则应用程序将保留在数据中心中。

在微软，每个应用程序都有详尽的记录，以便于对应用程序的生命周期进行审核。在向云端迁移时，Stratus团队将会仔细查阅各部门应用程序的记录。微软使用“维持”和“投资”来描述将要迁移到云的应用程序：如果将应用程序移至云端，并且没有计划进一步投资进行重新开发，则该应用程序处于“维持”模式，应该在IaaS中重新托管；如果应用程序需要重建或本身就是新开发的，则应该为PaaS或SaaS模型。

如果某个部门开发了一个新应用程序，则该应用将在纯云环境的PaaS中运行。如果将现有应用程序移至云端，则或者重新构建应用程序以在PaaS中运行，或将主机转换以在IaaS中运行。随着整体迁移的推进，更多因素被纳入战略考虑，Stratus团队使用多种策略，以将应用程序顺利迁移到云端。

Stratus团队最终决定开发一个决策框架，以评估应用程序是应该转移到IaaS、被整合还是关闭。该决策框架基于远程数据，以及Stratus团队对现有虚拟机和物理服务器环境的理解，这些环境具有基于以下几个特殊因素：硬件要求、软件版本、网络和所需的内部资源访问权限、安全考虑。

该团队构建了一个架构，将内部部署环境与微软Azure中的IaaS交付方式进行了比较。Stratus团队还对迁移应用程序进行了全面了解。通常，一个应用程序需要多个服务器来支持环境。因此，Stratus团队综合理解了应用层的上下游关系。在某些情况下，可以在混合IT模型中移动一台服务器，而不会影响整体运行状况或服务级别协议（SLA）。

该决策框架很快变得非常复杂，新开发的框架使用了大量数据点，并建议重新构建SaaS或PaaS应用程序，或在IaaS中重新托管。

云端迁移的一个关键部分是增加应用程序开发团队之间的知识库。 微软IT构建了一个全面的模型，来共享有关云技术的信息以及有关迁移和重新构建应用程序的成功案例。这样做有两个目标：提升IT团队整体的知识水平，以及提供一个了解正在迁移工作任务的平台从而支持云的采用。

一个关于云的维基百科提供了全面的信息，可帮助开发团队了解云技术及其使用示例（微软IT采用可共享的微软OneNote笔记本实现这个功能）。

微软IT已经发现了管理Azure平台所需的角色和技能变化，Azure对快速开发、自动化和自助服务技术的重视引起了巨大的变化，这包括：更少的业务项目经理、随着职位转变为开发/运营而几乎消除了开发/测试角色、更少的解决方案提供者、更多具有敏捷思维和云技能的项目经理、更多具有开发技能的开发人员和支持工程师。

云端迁移项目旨在利用云服务的优势作为开始，通过对微软应用程序组合的现代化，微软IT正在实现这些潜在的好处。微软IT发现，推动采用云服务的团队至关重要，这是因为Stratus团队不断分析正在演进中的云功能、服务器和应用程序需求。当云服务能提供所需功能时，Stratus团队将使用决策框架并与相关BPU部门合作，以找到将应用程序移至云端的最佳解决方案。Stratus团队还发现了报告的重要性，通过在部门间共享报告数据，Stratus团队不仅可以跟踪项目的进度，还可以推进BPU部门间的责任感。

“一切运行在云中”战略是微软迁移到云的关键。这也可让那些优先考虑减少内部资产及相应运营支出的企业受益，这也是一个重新审视现有环境并大胆按照云规模而重新调整、关闭未使用环境并实现可能的成本节约。

在微软迁移到云的过程中，有如下经验：1，首席信息官（CIO）和IT部门应提供培训和支持，推动对云服务的应用；2，创建一个积极推动云端迁移的团队；3，把尝试解决业务问题作为每个云服务决策的核心，但一定要在做决定时平衡业务和技术因素；4，没有一种放之四海而皆准的解决方案；5，将云服务作为一个缩小规模、发现适合规模和优化的机会，以避免服务器数量的持续扩展；6，在开发或重新构建云应用时，使用PaaS的可扩展性和能力；7，在将多层应用程序迁移到云时，考虑采用混合策略；8，将应用程序保持在云模块中以利用云弹性；9，积极暂停或消除未充分利用和废弃的服务器；10，意识到云服务的采用将改变任何组织中IT的角色，快速开发技能将变得越来越重要。

与Azure一同演进

微软IT部门（后来的微软CSEO核心服务运营）正在拥抱数字化转型，从僵化的、以流程为中心的运营转变为在Azure中运行的敏捷、以客户为中心的组织。现在，CSEO的运营基于现代DevOps工程原理。CSEO与业务伙伴合作，为员工提供支持和培训，并重塑CSEO服务。

“一切在云端”的好处之一是首先在微软自己的大型企业环境中部署和彻底测试微软对外部发布的任何应用程序或服务；其次，微软可以向外界展示新技术的应用，并借此鼓舞客户的创新。此外，微软还得以与客户分享各种经验教训。

在微软向云迁移的过程中，混合云是比较现实的技术方案。尽管微软Azure是适用于许多工作负载的基础架构平台，但有些应用程序还不适合云的方式，而且遗留的旧有应用程序因其复杂性和法规要求使得移动一小部分都变得极具挑战性。尽管如此，绝大多数LOB应用程序都是尽快迁移的目标。当然，随着Azure平台的发展，微软计划在内部数据中心部署的内部应用程序数量越来越少。

微软IT的策略是首选公有云，因为它提供了最大的灵活性和可扩展性。微软IT通过选择SaaS来使用商品化云服务，例如微软Dynamics CRM Online、SharePoint和电子邮件；而计划投资的现有应用程序，则尽量使用Azure PaaS，以缩短战略和服务交付之间的时间；对那些不准备进一步投资的应用程序，如果仍然可以完成服务，将转移到Azure IaaS。此外，所有预生产环境都将移至Azure。而对于具有特定法规遵从性要求且在公有云解决方案中不可用的少数现有应用程序，微软IT则使用内部部署私有云。

经过评估，近30％的应用程序组合可以退役、调整规模或关停，微软IT能够将这些功能整合到单个应用程序或服务中，数以千计的物理服务器和虚拟机（VM）被淘汰；大约15％的应用程序组合被SaaS解决方案取代，例如Office 365、SharePoint Online和一些第三方解决方案，这使微软IT能够将功能从定制应用程序转换为标准化的解决方案；复杂和定制的LOB应用程序占应用程序组合的50％，其中的大多数是可以“首批移动”，包括基本的Web应用程序或重新设计的解决方案，其余的被确定为“第二批”向IaaS积极“移动”的候选，一小部分被确定为“难以移动或成本高昂”；不到5％的应用程序将保留在本地。

IT治理方式变革有助于推动上云的过程。从2015年6月开始，微软实施了各种审批级别。物理服务器需要获得总经理的批准、高级领导团队的批准，以及CFO、CIO和Azure产品开发组的批准，内部部署虚拟机则需要投资委员会（Capital Committee）批准。这种治理和审批方式强化了云平台的“唯一性”(Cloud-Only)，除非业务团队向领导层申请特殊场景并提供相应的支持数据。

微软IT将用户教育和推广、外包服务、访问控制、应用程序安全性和其它策略结合起来，确保向云的安全过渡。迁移前的重点是保护网络边界和设备安全，需要严密控制网络边界，用户必须登录公司网络才能访问任何资源。一旦应用和服务开始转移到云端，内外边界变得更加模糊，安全成为一种逻辑而非物理的挑战。用户可以访问各种基于云的文件共享服务，因而需要了解合规性要求，例如存储数据的位置以及数据的分类方式。除了用户意识外，外包安全服务还可以保护物理、网络和应用层安全。访问控制是控制访问（网络层）和维护逻辑控制的关键；如果发生违规，细分的应用程序将彼此隔离。过去，如果用户通过有效登录进入内网，应用程序就是安全的；现在，在应用程序开发或迁移期间需要更高级别的安全测试，例如入侵测试。

微软IT使用System Center Operations Manager来管理Azure和Windows Server实例的混合环境，System Center Operations Manager在单个窗口中显示服务器可用性、运行状况和性能数据。这使得IT团队可以自动执行重复性任务，监控可用性并识别潜在的安全问题。业务部门可以使用IT服务所提供的映像（Image）在Azure中快速构建虚拟机，通过使用映像模板在内部IT环境和Azure中构建虚拟机，可以在两种环境中使用相同的部署逻辑。而应用程序开发团队使用Azure Application Insights来监视应用程序。Application Insights允许将性能、使用情况和远程数据发送到Azure门户以供审核。用户可以查看有关微软ASP.NET应用程序、Azure Web应用程序或Java网站的信息。

在容量规划和使用方面，微软IT提供了一个托管资源和恢复（HRR）计划，为业务部门提供可持续的端到端解决方案，以检查服务器的使用情况，然后对结果进行分类，将其纳入分层响应资源流程——服务器可能已退役、重新分配或以其他方式使用。HRR通过针对未充分利用的服务器、已经关闭的数据中心、完全折旧的硬件和不合规类别等领域来推动服务器容量的正确使用并减少未使用的占用空间。

迁移到云对企业现有网络基础架构提出了挑战。云迁移极大地改变了企业网络内外流量的数量和性质。在15个月的时间内，从微软内部企业网络到互联网的流量增加了十倍，大部分流量都流向公有云服务，取代之前前往内部网络上的本地服务的流量。总体而言，已有的网络基础架构不足以在微软部署和支持基于云的新解决方案。微软IT对于网络的改进主要是两个：分布式网络和Azure边缘网络。微软IT使用基于硬件的防火墙替换了旧网络代理，以实现更分布化和更高容量的配置。通过实施默认互联网和Azure边缘网络，可以在安全性和服务级别方面区别对待其它所有互联网流量和微软云流量。

在应用程序现代化方面，微软内部的许多不同组织和业务部门都开发了自己的应用程序，而且对这些应用程序的分析表明所有的功能都包含在应用程序中，这种架构使得应用程序变得庞大，难于托管且难以维护。微软IT对内部应用程序开发策略进行了现代化并使其更高效：创建了一个内部业务和数据服务的共享组，可跨组织使用共享的业务、数据和实用程序服务，这些共享服务确保开发人员和工程师始终与相同的资源和数据进行交互，而新的应用程序设计原则确保模块化的应用程序能够尽可能简单的被采用和集成，通知、日志记录和安全处理功能等低级功能被封装到可重用的实用程序服务中。现代化后的微软内部应用程序发布新功能不再需要三个月的时间，凭借现代软件工程方法的灵活性和速度，高优先级项目可在短短两周内发布，而最终将每天都能发布增量更新。

微软上云的许多好处使得IT成为业务的战略合作伙伴：通过降低运营开销，IT能够专注于为业务提供价值和功能；云让客户体验至关重要，所有业务部门共同负责用户体验和服务，并致力于不间断在线（Live Site）的文化；云计算推动了前瞻性思维和战略性技术投资，鼓励实验并将失败用作广泛分享的学习机会；随着向云的迁移，微软IT的核心角色也发生了变化，以前IT是计算资源的集中化管理和分配角色，而云计算的分布式模型意味着IT现在必须有效地管理越来越自助的环境。

截止到2016年3月，随着PaaS和IaaS的采用逐年加速（同比），自动化增加、支持成本降低。与此同时，本地物理和虚拟机的数量减少，基础设施事件的数量也减少了。具体来说，已经看到：本地物理服务器同比下降63％，从14,584降至9,208；PaaS采用率同比增长257％，从88增加到252；IaaS采用率同比增长286％，从2,536增加到6,507；事故同比下降66％，从7,902降至5,197；最终，运营成本得以下降。例如，使用自助服务功能，用户可以快速申请VM，PaaS自动化DevOps功能，支持费用也有所下降。

数据的迁移

就像搬家时的分拣和包装一样，数据和应用程序也经过评估和优先排序。有些资产根本不需要移动，所以可以离线存档或留下。重要的数据和应用程序计划首先移动，然后是简单的，最后是困难的应用程序。某些应用程序和门户需要重新设计才能在云中工作并保留在本地,这些在迁移的过程中被更新了。

一开始的时候，微软IT必须移动大量数据，主SharePoint门户包含36 TB的数据。对网络吞吐量的测试以及迁移过程本身表明，整个迁移需要四年时间。因此，微软IT团队制定了“有机地”移动数据的策略：为全新的网站开放云端注册，并停止在内部开设新网站——鼓励用户移动他们自己的网站和数据是一个成功的策略。

仅将处于激活状态（Active）的内容移动到云中大幅减少了要移动的数据量，此策略还意味着微软IT不必花费时间来占用空间并存储未使用的数据，因此专注于迁移日常运营中所需的协作内容，有助于优先考虑从最重要到最不重要的资产。这其中可以让用户评估他们自己的数据，然后存档需要保留但不再主动用于离线存储的任何内容，留下不用进一步使用的不需要的数据。主动迁移自己内容的团队和用户可以更快地获得云服务并能够创建新站点，他们可以随时随地从任何设备上访问云平台。一个成功迁移的经验是：促进及时的合作和准备，并通过谈判和确定每个集团迁移的确切日期和时间来满足期望，然后按计划进行。

在迁移数据的过程中，由于微软IT无法简单地将硬件驱动器连接到云数据中心并高速移植数据，而必须像其他任何客户一样通过企业网关将数据发送到Office 365云平台。因此，微软IT在首次迁移到云中时，最初移动了大约2,000个邮箱。由于没有必要的基础设施来支持企业内部网和云之间突然流动的大量数据，当用户在迁移后连接并且其邮箱缓存开始同步时，导致整个网络陷入困境。IT部门不得不撤销更改并与网络团队合作，以确保迁移成功而不会中断任何其他服务。

将现有基础架构迁移到云，这比仅将数据从一个地方复制到另一个地方更复杂。IT部必须考虑防火墙、数据带宽限制、延迟、配置文件同步以及可能适用的其它技术注意事项。以使用微软Exchange服务器处理电子邮件的企业为例，在迁移到基于云的Office 365邮件之前，应牢记这些重要概念：先移动一小部分邮箱以确定进程是否正常，以及网络是否可以处理从本地服务器通过网络网关移动并最终进入云的数据量；避免停机，在周末或非工作时间进行移动；移动后，在从本地服务器切换到云之前（即，更改邮箱指向的路径）同步用户的邮箱；如果出现问题，制定计划以退出流程，消除或最大限度地减少停机时间并防止数据丢失。

除了将要迁移的用户以及执行迁移的团队之外，IT还必须确定可能受影响的其他团队。例如，网络团队可能会突然发现大量数据突然涌向云端。除了需要向网络团队提供迁移计划的详细信息，并告知网络流量可能会突然激增外，网络团队的专业知识对于确定网络硬件是否足以满足云与本地网络之间增加的数据流量非常重要。

减少要迁移的数据量，以减少完成该过程所需的复杂性和时间；仔细检查硬件和网络，以确定它是否可以处理云的额外流量；咨询专家并根据需要升级基础架构；使用“迁移房屋”的类比来鼓励用户留下日常业务运营不再需要的内容和数据；从在第一次尝试中取得成功的小流程开始迁移，并从经验中学习，以此为基础来应对更具挑战性的项目；在迁移过程中避免丢失任何数据，执行备份并监视操作的进展；时刻准备面对变化和挫折。

总结：

微软的数字化转型，其成功依赖于成功的文化转型，而成功的企业文化转型则依赖于高层的决心、自上而下的推动和自下而上的平台，这三者缺一不可。特别是自下而上的技术平台，是微软整个公司成功转型的保障，也是微软向平台型数字化业务转转型的根本。只有把整个微软搬到统一的云平台上，通过统一的技术平台赋能企业的每一个员工以数字化的能力，才能让员工自行根据转型中的任务构建自己的新流程，从而完成整个企业的数字化转型。整个数字化转型，就是对于企业和产业流程的重构，这虽然可以自上而下构建起整体框架，但其中的细节却需要员工自行处理和完善，再通过统一打通的数据和平台进行全球化、全局化、全域化、自动化和智能化对接。数字化转型就像Satya使用的高管仪表盘，一个小小的仪表盘连接着整个企业的核心动态数据，又通过Satya的反馈指引整个微软的下一步发展方向。而这个仪表盘的背后是整个微软数据的打通、重构和价值再造，其根本是微软整体向Azure云平台的迁移。微软用自身实践说明，如何通过数字化平台实现自下而上的数字化转型。