傅一平評語：
這篇文章寫得很好，基于IT發展歷史的分析，剝掉各種表面的東西，就數字化的本質做了深入的辨析，下面是我總結的文章核心觀點及自己的淺見：
1、文章認為，業務流程數字化是企業數字化轉型的根本，傳統信息化只是做到了線上化，即“業務對象數字化”，只有基于業務流程管理(BPM)和SOA架構的“工作流數字化”（digital workflows)，才是真正的“流程數字化”，亦即操作本身被數字化，并且實現了自動銜接、結構化、受控。
這個流程數字化概念還是很抽象的，華為公司針對業務流程數字化專門提出了“三個化”，即業務對象數字化、業務過程數字化和業務規則數字化，大家可以看《華為數據之道》和《華為數字化轉型之道了解》詳細了解，跟以上提法有異曲同工之妙，應該來講，以前信息化在這三個方面都沒有做徹底，即使是業務對象數字化也沒做好，只是將數據做了線上存儲，沒有結構化掉，不能算是數字化
2、文章認為，中國互聯網公司發明的中臺理論早就為IBM很早提出的SOA的概念所覆蓋，包括“可復用的業務服務（reusable business services）”、“共享服務（shared services）”、前端組合應用、協同等等名詞，而且中臺強調的微服務等技術解決方案并不適合傳統企業，因為傳統企業業務構成業務流程的“服務組件”沒有那么碎，內部流程變動也沒有那么頻繁，企業運營的問題是如何實現業務流程的體系化、標準化、可控化，在此基礎上利用物聯網、大數據、人工智能等新技術，從而實現對業務流程的優化，對用戶進行賦能；數字化還是要回歸到“業務流程管理”的本質上去。
針對微服務和SOA的區別我當初也挺困惑的，本質的確區別不大，但實現方式的變革卻能帶來業務價值的巨大不同，比如傳統SOA拆分的粒度較大，一般按業務域劃分系統，但很少涉及系統內細粒度地拆分，傳統SOA多需要集中的服務總線，容易產生性能瓶頸 ESB（Enterprise service bus）幾乎是傳統SOA必備的，姑且不說現在很多傳統企業也在轉型，業務也在加速迭代，SOA笨重的架構使得業務調整讓IT動一發而牽全身，比如以前系統做大割接沒個半年下不來，現在采用微服務分布式架構，每個系統再拆分形成一個個獨立的服務單元，比如幾十個中心，風險的確大幅降低了，這也是客觀現實。
3、文章認為，今天中小型企業實現BPM（即數字化），不需要重型的BPM/工作流平臺以及SAP這樣復雜的核心系統，而是這樣的技術組成：
（1）輕量級的表單工作流應用，即低代碼開發工具
（2）API集成平臺，例如美國最近很火的Zapier
（3）各種完成特定業務需要的SaaS，例如看板工具、溝通工具、項目管理SaaS、輕量級CRM SaaS、HR SaaS等
這個還是很中肯的，即使是大型企業也不是鐵板一塊，它也有大量的小IT組織生態，它們需要這些技術來降低數字化的門檻。
正文開始
企業搞“數字化轉型”說了這么些年，如果問傳統企業（制造業、流通業、金融服務業……）的老板：你究竟希望“數字化”給你解決什么問題？在現實中，我從絕大多數企業家那里聽到的答案還是：“業務流程”。我很欣賞中國某超大民企的領導人對數字化的精辟總結：“一切業務在線、數據驅動業務”，按這個說法，業務流程數字化是企業數字化轉型的根本。
如果你對“數字化轉型”究竟解決了企業什么問題的答案，是幫助企業增長用戶、創新商業模式的話，也不能說不對，不過，下面的文字就不用看了。
我們假設企業信息化做得好，已經用了、并且用好了CRM、ERP、HCM等管理信息系統，那還只是做到了“業務對象數字化”，這里的“業務對象”指的是數據庫里的客戶、供應商、物料、賬戶、訂單等等業務信息實體，但是沒有做到“業務流程數字化”。對這些業務對象的“增刪查改”操作和操作組合，并沒有被結構化地數字化了——我們過去做SAP ERP實施時，“業務流程”其實只是存在于紙面的業務流程圖，實際的系統操作是不受控的。
只有基于業務流程管理(BPM)和SOA架構的“工作流數字化”（digital workflows)， 才是真正的“流程數字化”，亦即操作本身被數字化，并且實現了自動銜接、結構化、受控，如下圖所示：
工作流（workflow）是業務流程（business process）的實現方式，一般認為是由現代科學管理和工業工程之父弗雷德里克·泰勒和亨利·甘特（對，就是項目管理“甘特圖”的那位）師徒發明的，而利用信息技術來實現工作流的自動化、數字化，實現信息系統對工作流處理的標準化、可互操作性，早在九十年代初，在ERP、CRM熱潮開始之前，就由當時的企業級IT大廠IBM、惠普等公司牽頭，聯合學術界和軟件工業界成立了“工作流管理協會（簡稱WfMC）”來建立行業標準；該協會對于整個企業級IT應用行業影響深遠，90年代以來的ERP系統、業務流程管理、共享服務轉型、Java、XML、SOA、企業架構等等產生和發展，都可以從WfMC的活動中找到源頭。直到2019年，該協會宣布完成了歷史使命而解散。
WfMC很早就提出了業務流程管理和工作流實現的參考模型，并致力于這個框架的一系列標準制定，例如業務流程定義、業務流程模擬、工作流系統互操作、數據集成等等，雖然實現“技術共產主義”式的產業標準在商業社會現實面前已經夢碎，不過，其框架對于我們構思企業的業務流程數字化架構仍然非常有參考價值：
如上圖所示，企業業務流程管理（BPM）從業務流程建模開始，通過標準化的業務流程編程語言來開發可施行的業務流程服務，在客戶端程序（例如ERP核心系統）上執行，同時可以調用外部程序服務（例如互聯網上的SaaS）、并且實現和其他工作流服務的互操作，所有的程序接口和信息交換可以通過集中的集成平臺來集成。
作為WfMC開山祖師的IBM，在2005年后將這套企業級的業務流程管理和工作流應用的架構理論發展到了新高度，就是著名的“面向服務的架構”（SOA），其基本原理如下圖所示：各個企業級應用程序（套裝軟件、自開發系統等）解耦為若干企業業務組件，再形成原子級（Atomic）的業務服務，以及業務服務的聚合（Composite），這就是今天還廣為流傳的IBM業務能力組件理論CBM的來源，參見《》。而“業務流程”則是對這些業務服務（services）的組合、舞臺編排和狀態控制，服務于企業的信息消費用戶：
IBM將SOA定義為“一種可通過服務集成，復用軟件組件的方法”，下圖解釋SOA概念的“可復用的業務服務（reusable business services）”、“共享服務（shared services）”、前端組合應用、協同等等名詞，不就正是號稱由中國互聯網公司發明的中臺理論所謂的“中臺能力”、“中臺對前臺賦能”嗎？
IBM在2007年將這套SOA方法論授權給了“企業架構”組織Open Group，形成了企業架構方法論TOGAF的最核心內容。BPM、SOA、企業架構等理論是一脈相承，而且有高度對應關系的，下圖紅框是TOGAF的企業架構元模型和SOA實體的對應關系：
來源：OpenGroup官方文檔
再說到今天致力于“數字化轉型”的企業，很多沖上來就找咨詢顧問梳理四級流程、五級流程，越細越好。我一直認為，業務流程咨詢和實施業務流程管理（BPM）是兩回事，前者是解決業務流程中的某個具體的業務問題，例如產銷銜接、內部交易議價、職能合并或拆分等等，在這種工作中，用手工畫“五級業務流程體系”毫無意義，后者是體系性、自上而下、由粗而細的企業架構規劃，面向企業級信息系統建設。參見《系統實施前搞業務流程詳細設計咨詢沒用》
我們可以觀察到絕大多數中國企業都沒做到企業級BPM落地，很多管理者抱怨企業信息系統“豎井式”建設，流程割裂，數據不一致，信息沒拉通，解決問題的正解是用業務流程管理來牽動各個應用系統的內部業務處理整合（例如ERP系統內的每個交易動作）以及跨系統的互操作，在技術實現上，則是實施SOA架構。
然而最近幾年來，企業數字化動不動就扯“微服務架構”、“業務中臺”，連國內頭部企業軟件廠商也在趕這些名詞時髦，我覺得這完全是把企業數字化真正的問題給帶偏了！
“業務中臺”是全渠道零售、電商以及互聯網平臺特有的架構形式，因為IT系統需要支持這類企業業務隨時變化的前端，所以系統的服務要拆得足夠碎，敏捷迭代。這種方式跟傳統企業的業務流程設計卻有很大差別，傳統企業業務構成業務流程的“服務組件”沒有那么碎，內部流程變動也沒有那么頻繁，企業運營的問題是如何實現業務流程的體系化、標準化、可控化，在此基礎上利用物聯網、大數據、人工智能等新技術，對業務流程進行優化，對用戶進行賦能；數字化還是要回歸到“業務流程管理”的本質上去。
十多年前BPM/SOA聽起來理論體系完善，又有一系列大廠助陣，當時IBM、SAP、Oracle等都是BPM的擁躉，為啥在實際的企業應用情況里，BPM/SOA卻是個美麗的海市蜃樓呢？我認為這個問題的答案是：一個概念從提出到產業化落地，十多年并不算很長的歷史周期；企業級信息技術應用的代際替換沒那么快的，新興技術很難全面替換老技術，不像是消費電子，手機每年都可以換個新的。我在2006年左右就接觸過“流程挖掘”，那時候這個詞可能僅存在學術界中，是BPM里非常前沿的課題，今年卻突然火爆起來。
對中國企業數字化來說，無論是廠商還是企業，應該少追逐那些虛頭巴腦的新潮概念，在各家廠商制造的名詞霧霾污染中，踏踏實實地研究自己的問題；十多年前被提煉出的BPM/SOA概念，到今天可能才是真正成熟應用的時機。
今天企業級IT技術也有新的發展：流程挖掘、RPA、低代碼開發、API集成平臺，我認為這四者今天企業IT在全面上云的新環境下，促成實現企業級BPM的殺手級應用，可能是推動企業數字化走向下一輪高潮的真正革命性因素。前天寫了“超自動化 ｜ 業務流程數字化和ERP的終極型態”，這應該是BPM在今天的新生。
今天中小型企業實現BPM，我認為不需要重型的BPM/工作流平臺以及SAP這樣復雜的核心系統，而是這樣的技術組成：
輕量級的表單工作流應用，即低代碼開發工具
API集成平臺，例如美國最近很火的Zapier
各種完成特定業務需要的SaaS，例如看板工具、溝通工具、項目管理SaaS、輕量級CRM SaaS、HR SaaS等
而大型企業的BPM數字化，則需要考慮在架構現代化（即所謂“下一代ERP”，參見《企業如何走向下一代ERP（Next Gen ERP）》）環境下，在數字化平臺上部署工作流管理。以SAP為例，在早期的SAP ERP系統內就有內置的工作流編輯器（Workflow builder），由于配置復雜，運行效率低，使用并不廣泛，到Netweaver時代，獨立的SAP BPM工具成為SAP實施中的BPM首選，和ERP搭配使用，當時Oracle的BPM平臺也是和Oracle ERP以及其他套件搭配使用的。今天，在SAP最新的架構中，工作流管理被定位在SAP數字化平臺上（即SAP BTP），涵蓋了流程自動化、低代碼開發和流程挖掘等：
新一代廠商，例如流程挖掘廠商Cenolis基于其流程挖掘軟件之上包裝的“業務執行管理”方案，則可以看成新一代的BPM方案：
