萬字長文 | 微軟“重新整理”的背後，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雲平台的遷移。微軟用自身實踐說明，如何通過數字化平台實作自下而上的數字化轉型。