作者 榮浩 發佈於 2011年2月28日 上午12時0分
儘管在企業應用中工作流應用的越來越多，但對國內的工作流廠商們來說，這並沒有給他們帶來期望中的快速增長，這並不奇怪，因爲國內工作流產品基本上全部面 向開發者和系統集成商，解決的是編程問題，旨在簡化對流程進行支撐的軟件創建，這個定位決定了當越來越多的系統集成商開始自己研發工作流和越來越多的開發 者採用開源工作流時，原有的工作流廠商發現生存日益艱難。
在這篇文章裏，我們將一起回顧一下國內主要工作流廠商的產品以及發展策略，接着討論他們當前所面臨的困難以及未來的機會。這裏分析的工作流廠商包括了東方易維、西安協同、普元、炎黃動力、有生博大、華創動力、攜創、天翎、博彙數碼、中創、浪潮以及臺灣的華芩。
一、 現狀
大部分的工作流產品都實現了WFMC工作流參考模型（參見附錄）的接口1、接口2、接口3和接口5：
- 接口1，流程設計器：包括了兩種類型的設計器，一種是基於Web的設計器，實現技術包括了Swing和Flex，一種是基於 Eclipse插件的本地應用實現。除去普元之外，大部分工作流產品都選擇實現了一種類型的設計器。Web設計器的好處在於對最終用戶友好，基於 Eclipse的設計器的好處在於對開發人員友好，能夠比較容易的進行單元測試和流程測試，缺點則是基本上隔絕了最終用戶對工作流的使用，將工作流死死限 制在開發者的層次上。普元同時實現了兩種類型的設計器，是做得最好的廠商，東方易維和西安協同實現了基於Web的設計器，通過流程仿真來彌補測試的不足。
- 接口2，工作項客戶端接口：通過API暴露調用和交互接口，完成工作項的列表展現、拾取、退回和提交。
- 接口3，外部應用調用接口：基本上都沒有對主流ERP、企業管理軟件和財務軟件進行集成的專有支持，這和國內工作流產品應用的場景有關係，工作流多作爲支持單個應用的嵌入式使用，在這一點上天翎提供有與SAP的集成接口。大部分通過支持Web服務調用進行支持。
- 接口5，管理控制檯：包括兩部分，一部分是對運行中的案例進行監控和干預，包括了案例的中止、掛起與恢復，任務的中止、跳過、掛起與恢 復，參與者的重新指定和催辦，工作流變量的修改查看等；一部分是對案例的統計與分析，包括了針對案例、任務的時間統計，針對參與者的任務效率統計等。
除去對工作流參考模型的支持，基本上所有的工作流產品都實現了電子表單，在處理以數據填報及數據收集爲主的應用中（數據不需要過多的邏輯處理和沒有 複雜的關係關聯），電子表單能夠顯著的增加生產力，但是更現實的情況是企業應用大都具有複雜的業務邏輯，在這一方面，電子表單不是銀彈。
通觀所有的工作流產品，儘管有些產品不乏閃光點，但是整體用乏善可陳來形容是合適的，有些產品甚至可以用非常初級來描述，這不能責怪廠商，因爲他們所要解決的問題域決定了他們產品所能解決的問題域。
乏善可陳表現在6個方面：
- 除去華芩（支持XPDL，WFMC成員），大部分的工作流產品都不支持流程定義規範（東方易維對XPDL進行了很多擴展），主流的規範包括了XPDL、BPMN和BPEL。
- 對工作流模式的支持不夠。工作流模式反映出產品對業務流程的建模能力，選擇一個工作流產品最重要的考量就是其對工作流模式的支持程度。在 這一點上老牌的廠商如東方易維、西安協同、攜創和普元做得好一點，而一些以平臺爲銷售重心的廠商做的就差一些，甚至有產品非常初級，建模只提供開始、結束 和任務三種節點類型。
- 流程可視化差。流程定義作爲企業重要的資產，並沒有看到有產品對其可視化管理的直接支持。這裏的管理包括了在組織結構內進行不同層次之間 的流程可視化導航、流程權限和職責在組織中的分配、流程的全文檢索和查找、與流程相關的文檔管理等。流程定義更多的是作爲了開發者和IT部門的私有財產。
- 流程建模與測試沒有很好的統一。如何對建好模型的流程進行測試？兩種方式，一種方式是進行流程仿真，將流程模擬的跑起來，這種方式效率低，另一種方式是將流程定義導入IDE進行單元測試/調試。除去普元，大多數產品都沒有提供對IDE的支持。
- 整合能力弱。這個在上面已經提到了，基本上都是通過支持Web服務調用進行支持。
- 版本更新遲緩，沒有持續投入。很多工作流產品早已停止更新。
- 儘管存在上述種種不足，但是也不乏亮點：
- 業務流程治理（BPG）的提出。東方易維首先明確提出了BPG的概念，並將企業流程應用清晰分爲了三個層次，分別是BPG、BPMS和工 作流。BPG解決的是企業流程是什麼的問題，這涉及到企業流程的設計、梳理和協調；BPMS和工作流解決的是企業流程如何執行的問題，區別在於BPMS的 要點在於打破各個應用系統（CRM、ECM、ERP、SCM）之間的界線，將分散在這些系統中的流程集中管理；而工作流則旨在簡化對流程進行支撐的軟件創 建。在此之前，大部分廠商將工作流產品與BPMS產品混爲一談。
圖1不同層次流程所對應的問題
- 雲平臺的提出。炎黃盈動提出了搭建流程私有云平臺和將流程平臺部署到公有云中。觀念在國內廠商中比較超前，但是仔細思考，私有云其實是工 作流產品向BPMS產品提升的一次嘗試：工作流不再嵌入滿足單個應用的使用而是暴露出流程服務讓所有應用可以調用，但這項工作絕不是暴露出幾個API可以 完成的，涉及的方面非常多。至於公有云，國外產品如Cordys早已有成熟的流程服務，這能夠顯著降低企業的流程應用成本，特別是對中小企業，炎黃盈動提 出了這個想法，但是並不是直接提供類似的流程服務。
- 高可靠性。西安協同和普元的產品都有很高的可靠性，這和他們的客戶有關係，電信、金融。
1、 工作流與平臺
幾乎所有的工作流廠商都提供平臺，攜創是個例外，但是這讓他的市場非常狹窄。爲什麼會提供平臺？我們先來看看工作流要解決的問題域，工作流旨在簡化對流程進行支撐的軟件創建，既然是簡化編程，那麼更進一步提供平臺就顯得水到渠成了。
平臺分爲兩種，一種是快速開發平臺，一種是業務平臺（或者提供相關的業務套件）。
- 快速開發平臺主要包括了電子表單、一套開發框架還有爲宣傳所需要的ESB和SOA設施（這些所謂的支持都是浮雲）。
- 業務平臺則包括了文件管理、在線編輯、即時通訊、電子印章、門戶、內容管理、人力資源、客戶服務、行政管理等套件/模塊。
與單純的快速開發平臺相比，業務平臺顯然站在了一個更高的層次上。在軟件開發中，最大的浪費往往並不在於技術本身，而是在於對業務的不熟悉，在於核心領域模型的頻繁變動。對用戶而言，根據需要選擇合適業務平臺和相關服務無疑能夠產生最大的價值。
爲什麼有的廠商提供快速開發平臺，而有的廠商提供業務平臺呢？這取決於兩個方面，一是廠商切入工作流市場的年限，年限越長，越積累有豐富的項目經 驗，這些經驗很容易轉化成業務套件；二是廠商的客戶定位，不難發現提供快速開發平臺廠商的客戶都是系統集成商，自己並不承接相關項目。而反觀這些快速開發 平臺，很難發現有特別突出的技術優勢，大部分都是對Struts、Spring、Hibernate、Ibatis簡單封裝後的CRUD框架，加上代碼自 動生成和Eclipse插件支持，沒有任何閃光點（普元是個例外，但是我們同樣對其平臺發展持不樂觀態度，這可以再開一個話題）。
我們的觀點是：快速開發平臺沒有太大價值，提供行業應用的業務套件/模塊纔是正道。
2、 客戶
觀察臺灣地區的工作流應用和國內的工作流應用，我們能夠明顯的發現：臺灣地區的應用大部分集中在製造業（私企），而國內的應用則集中於政府、電力和金融行業（國企）。爲什麼會出現這種情況，作爲製造業的大國，爲什麼工作流的應用卻只集中在國企和政府，答案不得而知。
拋開工作流應用，工作流廠商的客戶包括了以下2種：
- 系統集成商。這包括了兩部分需求，一部分是系統集成商採購工作流產品或平臺自己進行開發，一部分是系統集成商直接將項目外包給工作流廠商。這條路限制很多，越走越窄，但對於小的工作流廠商來說沒有選擇（沒有資質和足夠的資金）。
- 政府和企業。也就是自己直接接項目，這基本上是目前最好的一條道路。有些原有的工作流廠商早就轉向（或部分轉向）項目型公司，工作流產品不再更新和銷售。
3、 廠商的層次分類
根據上面的討論，我們不難將工作流廠商分爲3類：
- 只提供工作流產品。這類廠商產品單一，儘管產品質量能夠得到保證，但是發展最爲困難。
- 提供工作流產品和快速開發平臺。這類廠商在工作流的基礎上提供開發框架進一步簡化編程，相比第一類廠商會更有競爭力，但是其發展受到系統集成商的限制。同時需要注意的是，部分廠商着力點在於開發平臺，工作流產品水平非常一般甚至初級。
- 提供工作流產品和業務套件/平臺，同時自己接項目。這是目前生存狀態比較好的廠商，多是老牌廠商或是有充足的資金。業務套件/平臺能夠給用戶提供最大的價值。在任何時候，直接面對最終用戶都是王道。
二、 挑戰與機遇
儘管在企業應用中工作流應用的越來越多，但對國內的工作流廠商們來說，這並沒有給他們帶來期望中的快速增長，單純的工作流產品甚至面臨銷售越來越困難的窘境。
1 、困境
工作流廠商面臨的壓力來自於3方面：
系統集成商由購買轉向自主開發。這是工作流廠商發展受阻最重要的原因，工作流應用越來越多，沒有集成商願意將這個重要的中間件依賴於他人。大多數集成商選擇的方式是直接購入現有工作流廠商的源代碼，也有基於開源工作流進行開發的，但是不多。
開源工作流的競爭。對於中小軟件公司來說，如果遇到有流程的需求，他們的第一反應是採用開源工作流，而事實是開源工作流做的並不差，除去對國情的支持較弱外，開源甚至比一些商業產品還要好，尤其在對標準和模式的支持上。
不能面向最終用戶。這是最根本的問題。工作流解決問題域的限制讓最終用戶根本感覺不到工作流產品價值的存在，而又沒有一家工作流廠商能夠做到像英特爾公司那樣：組裝電腦時指明要一顆奔騰的心。於是發展嚴重受限於系統集成商。
2 、機會
那麼，工作流廠商的機會在哪裏？最重要的就是：將產品面向最終用戶。
- 提供行業應用業務套件。能夠做到對某類應用的快速實施，例如對於電子政務和協同辦公，東方易維和西安協同都積累了豐富的經驗，很多功能能 夠做到開箱即用。這樣的好處是顯而易見的，一是對集成商和中小軟件公司來說，能夠最大程度的節約成本，二是能夠直接面對企業進行快速的項目實施。是時候拋 棄單純的快速開發平臺了。
- 轉向BPMS。在工作流的基礎上開發BPMS，這需要兩方面的努力：一是業務方面需要與業務流程諮詢公司進行合作，二是產品需要增加 BPMS特性，這些特性包括了對BPMN的支持、實現流程及相關文檔可視化的內容存儲倉庫、提供在組織結構內進行不同層次之間的流程可視化導航、更好的業 務活動實時監控預警與控制以及對流程執行的統計分析與反饋。轉向BPMS的目的也很簡單：產品面向最終用戶，不再隱藏在某個應用內部。但是如何在市場上推 廣產品，這又是個問題，幾乎所有的工作流廠商都宣稱自己的工作流產品是BPMS。
- 提供雲中的流程服務，降低中小企業的流程應用成本。這個是未來的趨勢，但是從目前工作流應用集中在政府和國企的情況來看，並不樂觀。
- 自己做項目。大公司靠財務，小公司靠銷售。有很多原有的工作流廠商轉變成了項目性公司，在有工作流實施經驗的情況下，開發成本相比其他一些公司會更有競爭力。
三、 總結
國內工作流產品全部面向開發者，解決的是編程問題，旨在簡化對流程進行支撐的軟件創建。
國內工作流廠商分爲3類，分別是工作流、工作流+開發平臺、工作流+業務平臺/套件。
工作流廠商面臨困境的主要原因在於產品不能面向最終用戶，這樣當越來越多的系統集成商開始自己開發工作流和越來越多的開發者採用開源工作流時，生存日益艱難。
工作流廠商的機會與困境相對，就是將產品面向最終用戶，這包括了自己實施項目、轉向BPMS以及提供雲中的流程服務。
附錄
WfMC之工作流參考模型
圖2 WFMC工作流參考模型
圖2是工作流管理聯盟（WFMC）提出的工作流管理系統參考模型，工作流執行服務器周圍的接口是WAPI（Workflow APIs），通過這些接口可以訪問工作流管理系統的服務，這些接口還控制工作流控制軟件與其他系統組件間的交互。在這5個接口中的許多功能，都是被2個或 更多個接口同時擁有的，因此WAPI可以看作是統一的服務接口，可以交叉使用這5個接口來支持工作流管理功能，而不是單獨的使用其中某個接口，其中各個接 口的具體含義如下：
- 接口1：工作流定義接口，爲用戶提供一種可視化的，可以對實際業務進行建模的工具，並生成業務過程的可被計算機處理的形式化描述即流程定義。
- 接口2：工作流客戶應用接口，它給用戶提供一種手段，以處理過程案例運行過程中需要人工干預的任務。每一任務的最小工作單元就被稱爲一個工作項(workitem)。工作流管理系統爲每一個用戶維護一個工作項列表，它表示當前需要該用戶處理的所有任務。
- 接口3：工作流調用應用接口，指工作流執行服務在案例的運行過程中，調用的、用以對應用數據進行處理的程序。在過程定義中包含這種應用程序的詳細信息，如類型、地址等。
- 接口4：工作流引擎協作接口，在大型的分佈式的工作流管理系統中，工作流需要多個工作流引擎共同完成，甚至需要其他異質的工作流執行服務來輔助完成，此接口爲不同的工作流管理系統之間的協作提供了一種標準。
- 接口5：管理接口，其功能是對工作流管理系統中案例的狀態進行監控與管理，如組織機構管理、實例監控管理、統計分析管理、資源控制等。
工作流引擎：它是工作流管理系統的核心，工作流引擎對使用工作流模型描述的過程進行初始化、調度和監控過程中每個任務的執行，在需要人工介入的場合完成計算機應用軟件與操作人員的交互。另外它的另外一個重要的功能是完成與應用軟件及操作人員的交互。
關於作者
榮浩，ThoughtWorks諮詢師，關注敏捷和企業流程改進過程，目前正與辛鵬合著《Head First Process-深入淺出IT流程》一書。博客地址http://ronghao.iteye.com 。
本文出處：http://www.infoq.com/cn/articles/rh-workflow-manufacturer-analysis
