規模化敏捷沒準備好，就別想數字化轉型成功了

不少著急上火著要搞數字化轉型的企業老闆在招標時說，希望你們這些見多識廣、腦子又夠聰明的諮詢顧問們，來給我做個“數字化轉型規劃”——規劃要求必須能“落地”，分析文件的顆粒度越詳細越好，恨不得寫到“五級功能需求“，程式設計師們拿著這個需求文件就能對著寫程式碼、開發功能;系統開發出來，數字化轉型就實現了。

我很想對他們說：老闆，你這真的是要做“數字化轉型”嗎?

“數字化轉型”和“資訊系統建設”都是資訊科技(IT)在業務中的應用。IT應用於業務包含了三個方面：

·業務數字化形式

·關鍵使能技術

·組織變革

從資訊化階段到數字化階段，這三方面呈現出顯著變化。在組織變革方面，數字化企業要實現組織的“規模化敏捷(Agile at scale)”，即敏捷的運作方式不僅體現在單一的軟體產品小組或者專案小組，而是擴充套件到整個數字化組織內的各個組織層級運作，以及業務組織和技術組織的協作關係上。

敏捷本來是最近三十年興起的軟體工程思想，強調在軟體開發中貫穿這樣一些原則：“人際互動勝於流程工具，能用的軟體勝於詳細的文件，客戶協作勝於合同條款談判，響應變化勝於遵循計劃”。傳統軟體開發過程中常見的管理行為，例如結構化的過程控制、詳細的文件記錄、嚴謹的範圍控制和進度計劃、基於工作任務書來明確的需求方和開發方的交易關係等等，都是敏捷所極力摒棄的做法。

有若干種軟體開發方法論代表了這樣的理念，其中為大眾熟知、應用最廣的是SCRUM。雖然各種方法框架的概念、名詞、工具等有所區別，面向軟體生命週期不同階段或者不同開發型別，但都是強調軟體產品的功能交付——或稱軟體開發生命週期(SDLC)——以使用者價值為導向，迭代式(Iterative)生成和階段式增長(incremental)相結合，涵蓋了人性化設計(設計思維)、精益啟動、視覺化迭代開發(Sprint/Kanban)、持續整合和運維支援(DevOps)的軟體生命週期全過程。

企業的數字化過程是企業業務不斷“軟體化”的過程，隨著企業級軟體開發方法論從傳統瀑布式到現代敏捷的演進，企業數字化跟新的軟體開發方法相適應;所以，敏捷不僅僅是技術課題，而是企業數字化轉型中組織變革的課題。

網際網路公司是原生的數字化企業，可以說是傳統企業數字化轉型的終極目標。由於網際網路公司先天的技術公司特性，具有良好的敏捷應用條件，其業務和技術融合的組織，資料驅動業務，持續迭代的交付等運營模式都體現了敏捷的特點。網際網路公司也存在應用架構規劃不合理造成研發精益度不夠，產品經理和開發人員協作不好、相互內卷等問題;除了持續創新等優勢外，網際網路公司被人詬病的超時勞動、內部競爭等等，也是敏捷組織可能產生的負面問題。傳統企業和原生網際網路公司不同，大型企業存在既有的核心業務系統(例如製造業的ERP系統或者銀行的核心銀行系統)，流程有管控和風控要求，技術和業務都必須保留變化速度相對穩定的“非敏捷”部分。在數字化轉型過程中，IT系統的穩態模式和敏態模式的“雙模式”並存逐漸成為大家共識，參見舊文《IT戰略規劃 | 數字化取代了資訊化嗎?不，是雙模式》。

最近這些年在中國國內，製造業、流通業等傳統企業的敏捷實踐大多僅限於電商等純網際網路業務環境，雖然核心業務上在大談特談系統升級換代、上雲賦智云云，卻鮮見提到大規模敏捷轉型。例如華為、美的、三一等媒體上宣傳很熱門的傳統企業的數字化轉型標杆，從媒體公開披露的轉型故事來看，幾乎看不出來這些企業推廣、實施“企業級規模化敏捷”的實踐，從這個角度上說，雖然這也符合傳統企業“雙模式IT”的特點，但是這些先進企業的數字化實踐很難說完全符合“數字化轉型”的定義。

在國內聲稱大量引進敏捷實踐的傳統企業可能大多來自金融服務行業，包括銀行、保險以及證券公司等，從大型到小型的都有。我覺得很大原因是中國的金融企業有大規模自研資訊系統的傳統，具有龐大的自有IT研發團隊，包括核心系統在內的系統大都是自研的;就我跟國內敏捷從業人員交流的觀察，絕大多數國內金融機構引進敏捷僅僅侷限在軟體中心的研發效能提升上，談不上企業級的範圍組織變革。

網際網路公司和新興軟體公司在技術研發上的敏捷實踐主要表現在幾個方面，例如：

·敏捷開發過程

·使用者價值導向的需求管理

·持續交付和DevOps

·基於OKR的研發團隊管理

為支援這些實踐，產生了一系列的敏捷應用工具，既有專業公司或組織提供的Jira、禪道一類的通用工具，騰訊、位元組等網際網路大廠都開發了自己的工具，此外，一些敏捷諮詢公司以及軟體開發團隊還推出自己研發的敏捷工具，以金融機構軟體中心為代表的敏捷研習者紛紛引進源自科技公司的實踐及工具。

而中國金融機構的軟體中心長期以來面臨的挑戰是如何更好地滿足使用者，即業務部門的需求，根據使用者開發需求的重要、緊急程度，衡量和分配研發資源——金融機構CIO最常見的吐槽是開發需求排期、IT專案成效評估等等，最近幾年金融企業的“企業架構”熱也於此有關(參見《下一個爛大街的會是企業架構和業務架構嗎?》)。然而，網際網路公司的產品KPI，亦即“使用者價值“，是先天用數字化方式衡量並展現的，例如使用者數、活躍度、營收、市場影響力等，產品團隊盯著這些KPI的改進去驅動技術團隊，不需要官僚主義的需求評審或者是實施效果評審;一旦使用者價值衰退，這段程式碼就被棄用了。傳統企業的很多數字化應用是支援業務執行的核心繫統，幫助業務人員完成業務，其使用者價值很難被數字化，這就使得業務和技術完全融合協作的敏捷模式很難開展。

從企業的軟體開發部門延展到全企業的敏捷轉型，要求企業建立支援數字化轉型的“敏捷型組織”，其運作模式涵蓋了管控模式、組織架構、工作流程、人才技能、績效評估和技術基礎等：

企業級的規模化敏捷有幾種主要方法論流派，例如Scaled Agile Framework——SAFe，大規模Scrum——LeSS等等。上規模的敏捷既具備專案敏捷的靈活，也需要包容組織傳統，體現出轉型的折衷藝術，例如：區域性和整體的折衷，自下而上和自上而下的折衷，現狀變革和白紙畫圖的折衷，部門視角和價值流視角的折衷······

規模化敏捷實施面臨諸多常見挑戰，例如，規模化敏捷要解決企業技術投資中業務需求優先順序評估以及資源分配的問題，組織的創新處於混沌狀態，企業的資源是有限的，過度投入可能無法產生期望的效益，企業管理者必須建立價值評估模型和機會管道，持續管理敏捷專案的不確定性。參見我幾年前寫的舊文《敏捷戰略 —— BLM之後，今天IBM的戰略模式》，然而在現實中，各個產品專案之間爭奪資源，使得這種自上而下的管控又顯露出非敏捷的官僚主義性質。

又例如自治型組織運作，“Spotify模式”(常被稱為“部落制”)可能是企業級規模化敏捷中最被廣泛引用的最佳實踐，又最受廣泛爭議被認為是“數字化烏托邦”的組織變革措施。

網上關於“Spotify模型”的原理、適用前提討論很多，此文不再贅述。不少傳統企業在嘗試用這種模式進行組織變革來支援數字化轉型，例如某家金融服務機構將產品向客戶交付的體系定義為“客戶交付部落”，包括銷售、產品開發、技術支援、流程改進等“部落”。然而，敏捷專家們從一開始就認為Spotify模型沒法在各家組織中生搬硬套，這跟每個組織的文化特質有關，如果真要實施，一定要有諮詢顧問引導。而有位Spotify高管離職後聲稱，這個在管理學界被神化了的組織模型，其實在Spotify內部從來沒真正被實施過。參見《被全球過度炒作的Spotify敏捷部落制，連Spotify公司自己都不用 | IDCF》。

我觀察到的中國企業數字化轉型的敏捷實踐的現實困境是：

1、大多數敏捷是IT部門內部的開發流程最佳化，這類最佳化的推動力量往往來自軟體工程領域的技術諮詢公司，而非業務推動;很少有企業的IT部門在企業內的政治地位能搞得定業務部門，如果沒有企業領導強力推進的變革，規模化敏捷可能只是存在於IT部門內部和敏捷教練們的自嗨了。同時，有些業務衝動很強、對自己能力充滿自信的IT部認為，自己應該跑到業務前面，甚至抱怨業務部門提不出高質量的需求，自己對做業務躍躍欲試地越俎代庖。

2、有極少數企業在外部管理諮詢公司助力下，獲得企業高層對敏捷的理解和認可，推行諸如“部落制”的敏捷運營模式。然而，純管理諮詢顧問或者業務領導們可能缺乏指揮技術人員的能力，甚至被詬病為“外行指揮內行”，難得到IT部門的支援認同，可能就演變成IT部門和業務部門之間的政治角力，敏捷組織轉型變成了“分拆IT部”的鬥爭。參見《繼拆掉人力資源部後，專家又建議要砍掉IT部了》。

3、規模化敏捷要求形成公司級的業務和IT的治理模式再造，而傳統中國大型企業大多沒有形成完善的BT/IT治理模式，(參見《FCT模型 | 大型企業業務流程和資料的治理體系》)，大都存在流程管理的斷層，業務和IT協作對話是個老大難問題：

4、從文化角度上，敏捷是一種極客文化，中國企業的傳統價值觀既重官僚權力，也重商業交易，就是沒有推崇“技術大牛”的基因，缺乏技術大牛的敏捷沒有靈魂。

企業敏捷轉型的成熟度存在演進過程，一般認為企業級規模化敏捷需要3～5年的轉化週期，從IT專案試點，到全面的IT專案級敏捷，到專案群級敏捷，再到企業全面敏捷;在這個過程中，IT逐步成為企業或不可缺的能力，和企業業務完全融合：

據說數字化轉型成功率只有20%，那在這80%不成功的案例中，我覺得主要原因不是技術問題，技術問題都可以用錢來解決，能用錢解決的問題都不是問題，最主要的成功障礙是領導和人員的意識轉變，以及運營模式和組織變革。不過，實施敏捷的困境也不是數字化轉型特有的問題——我過去幹了幾十年的資訊化，理論上說資訊化推進業務流程管理，可是花錢上資訊系統的企業我見得多了，也沒見有多少企業真正把“業務流程管理”搞起來的。

最後強調一下，本文開頭那些老闆做的真不是“數字化轉型”，如果沒有準備好接受企業級規模化敏捷的挑戰，企業老闆們不要輕言“數字化轉型”。