工作流項目實施的一些問題和解決策略
更多工作流參考文檔，請訪問在 http://www.javafox.org
這兩年工作流應用越發火爆了，大多管理信息系統都或多或少涉及到流程應用。一方面
客戶對流程認識和需求在提高，另一方面開發商也希望通過流程技術爲客戶提供更靈活的應
用支持。
先簡單說說什麼是工作流：
工作流（Workflow）就是工作流程的計算模型，其表示的是：對流程中的任務（活動），
以什麼樣的邏輯或者規則串接起來，並以什麼樣的模型進行表示和計算。
上面的概念解釋比較抽象化，由於本篇不是定位於講解工作流概念的文章，所以我們暫
且不深入的探討工作流的一些基礎知識和理念。簡單的舉例加以說明：例如，在日常辦公中，
當撰寫好某份報告之後，可能需要將其提交給領導進行審閱或批示；審批意見可能需要彙集
並提交給另外一個人，以便對報告進行進一步的修改。這樣，可能會形成同一篇文檔在多個
人之間的順序或同時傳遞。對於這樣的情況，我們可以使用工作流技術來控制和管理文檔在
各個計算機之間自動傳遞，而非手工傳遞。這就可以稱之爲工作流。
本篇主要探討工作流實施過程中的一些需要注意的問題。對於工作流的實施，其實就是
基於一個工作流引擎或平臺，通過擴展開發實施，滿足客戶對流程信息化應用的需求。從一
個開發商接手一個流程應用開發，到其給客戶實施成功，需要面對一些比較棘手的決策性問
題，而這就是本篇所要探討的主題。通過對一些工作流實施問題的講解和方案探討，來輔助
開發商進行一些基本決策。
第一個問題：爲什麼就一定需要使用工作流技術？
首先簡單闡述一下爲什麼一定需要使用工作流技術。
我想最直接的原因應該是來自於客戶的管
理和運營信息化的需求推動：在客戶的運行管理
體系中，在不同的職能領域，是由各種各樣的處
理流程交互協助的，而這些處理流程都是由一些
處理活動和任務組成的。傳統的信息系統僅能滿
足客戶對數據處理信息化的最基本要求，卻很難
滿足客戶對“協助處理信息化”的要求，這就是
客戶爲什麼需要工作流技術的基本原因。
而從另一個角度來說，開發商也希望通過流程技術的應用，一方面提高流程項目的實施
進度，另一方面則希望能夠爲客戶帶來更高體驗度的實施效果。
這個問題不過多的解釋，因爲目前工作流的應用已經是越來越廣泛。
第二問題：工作流技術就真的可以提供工作流項目實施進度嗎？
這幾年在工作流培訓過程中，碰到很多技術人員問我這個問題。在他們看來：首先他們
對工作流系統是存在一些困惑的，特別是從來沒有接觸過工作流系統的開發人員；其次他們
搞不清楚工作流技術是否真的能提高項目開發進度。
單純說使用工作流技術提高項目實施效率，這不一定就有
效。這幾年的實施的流程項目很多，但只有個別幾個，因爲客
戶對流程相關的應用應用的需求不是很複雜（如表單、權限
等），我們流程產品本身輔助的表單系統也基本滿足客戶的需
求，在這樣的情況下實施的流程應用相對是快很多的。
但絕大多數實施的流程項目，單純從按照客戶的需求來完成流程運行和實施，有沒有工
作流引擎支持，其實並沒有提高的太多。我記得2002 年下半年的時候，給國家發改委實施
了一個“提案信訪”的流程，流程本身不是很複雜，如右圖所示。當時我們已經有一個較爲
完善工作流系統了，但這個流程項目依然實施了半年多。主要原因是耗費了大量的開發精力
在客戶操作習慣、交互界面以及組織管理中的一些非常規權限方面。
可以說，一個單純的工作流引擎，本身似乎並不能提高多少的流程項目實施效率。但是
我們依然推崇使用工作流技術來解決流程性問題。這是因爲工作流技術本身是基於“定義模
型、解析模型、運行模型”原則，這就是說“流程是可被描述的”，一般我們會採用xml 來
描述流程定義。基於這個模型“定義——解析——運行”原則，則會帶來兩個最直接的益處：
（1） 基於可被描述的模型，也就意味着流程定義是可被複制的。那麼對於類似的流
程就可以很容易被快速複製和擴展。
（2） 基於模型的解析運行，也就代表着可被有效的監控和管理，這是傳統硬編碼開
發很難逾越的。
第三個問題：如果去獲取一個工作流引擎或平臺？
工作流項目實施的前提就是必須已經存在一個工作流平臺或工作流引擎，基於這個引擎
或平臺實施項目：這個平臺或引擎，不論是夠買第三方的，還是自己研發的，抑或是擴展自
開源的，但總歸必須是有那麼一個了。
如果某一個廠商，其有自己的工作流產品，那麼這個問題似乎就沒有存在可能性了。但
是對國內大多數開發商來說，這是一個很頭疼的問題。當這些開發商接到一個工作流項目的
時候，擺在他們面前的最直接問題就是：怎麼搞定這個基礎的工作流系統或工作流引擎，是
夠買一個現有流程產品，還是基於開源引擎擴展，抑或是自主研發？
這三個選擇似乎都很困難，因爲現在國內的工作流應用蓬勃發展，工作流廠商也如雨後
春筍般一個接着一個的冒出來了，而且其中不乏有很多是以提供Platform 爲主的；而開源引
擎也越來越成熟和完善；而很多開上也着實希望能夠用有自己知識產品的引擎，爲以後項目
實施解決成本。
下表就顯示了一些代表性廠商和開源引擎：
平臺廠商 起步、浪潮樓上、炎黃盈動、普元、中創
工作流廠商 西安協同、東蘭、Joinwork、信亞達、華創動力、盛鬆
開源工作流引擎 jBpm、OSWorkflow、Shark
所以對開發商來說，選擇什麼樣的方式，是首要問題，甚至有可能上升到戰略性問題。
在此，提供一些基本分析意見， 供參考：
（1）如果僅僅只是實施一個或一些簡單的流程應用，這個簡單的意思不是指流程的結構簡單，而是指客戶的操作性簡單，沒有諸如“回退”“會籤”“跳躍”之類的運轉模型；而且客戶對流程圖形化定義也沒有什麼要求，只要能保證流程穩定運行，以及可進行簡單的管理和監控操作即可。那麼這種情況下，應該首先考慮“基於開源引擎擴展”。這是因爲目前開源引擎基本上都比較成熟和穩定了，特別是jBpm，自從其被JBoss 收購之後，jBoss3 是越來越完善。據我所知，目前國內很多開發商就是基於jBpm 之上
進行擴展實施流程項目的，並且很多都已經成功應用。
（2）如果項目要求非常緊，而且客戶對流程設計、流程運行的要求也比較高。那麼這種情況下，一般建議優先考慮商業應用產品，雖然採用商業產品必然會帶來成本的增加，但是從滿足客戶的需求應用角度來講，還是比較值的。但選擇
什麼樣的產品，這對很多廠商來說，也是較難於把握的。這一點我們隨後再講，先接下來看
看什麼情況適合自主研發。
（3）相信很多開發商都希望能擁有自己的工作流引擎或平臺，因爲對他們來說，首先
是採用第三方的廠商產品會帶來採購成本的增加，其次較爲擔心在流程項目實施過程中，因
爲客戶需求的複雜或突然變更，而廠商產品接口有限或功能卻恰巧不滿足的情況下，則會帶
來非常麻煩的事情。
但自主研發只在如下情況比較合適：目前項目交付壓力不是很大，有至少兩至三人的研
發團隊，持續投入半年到一年，並且其中有對工作流系統結構模型等方面有較深理解，並有
適當的實際引擎開發經驗更好。從上面的條件可以看出來，這個要求是很高的，對國內大部
分開發商來說，是很難提供這樣的研發環境。
自主研發工作流引擎或系統，一般都需要半年到一年左右的研發期，還需要一兩年左右
的項目實施和完善期，才大約能夠走向成熟。比較有代表性的開發商如下：
公司 工作流引擎名稱 研發啓動時間 引擎初版發佈
北京用友軟件工程 Nucleus 2004 年初 2005 年中
北京慧點科技 Galaxy 2003 底或2004 初2004 年底或2005 年初
在這裏也順便提個忠告，存在一些開發商的管理人員把工作流技術看的過於簡單。當突
然碰到有類似的項目的時候，以爲找個開發人員，讓其在開源引擎上去研究一段時間就可以
應付複雜流程項目，這是大錯特錯的，而且大多都以失敗告終。在我前面的參考方法中，第
一句話就是——“僅僅只是實施一個或一些簡單的流程應用”，才應該優先考慮開源引擎。
第四個問題：如果考慮第三方工作流產品，那麼選擇哪家產品更合適自己？
接下來，講講如何選擇商業工作流引擎。
這兩年國內工作流廠商是越來越成熟，產品的定位和分層也逐漸顯現出來，比如西安協
同的流程產品逐漸開始支持於基於ESB 的分佈式流程應用，而上海攜創的Joinwork 則依然
定位在嵌入式工作流引擎。但是對於那些決定採用第三方工作流產品的開放商來說，如何選
擇一個最適合的產品，也依然是件非常困難的事情，畢竟國內大大小小的工作流產品有數十
家：
在 google 上搜索“工作流產品”，大約會搜索出7840000 條記錄。下表列出一些較爲常
見的工作流廠商和產品（不包括一些平臺性廠商，如起步、普元、炎黃盈動等）：
神馬 EasyFlow、西安協同SynchroFLOW、上海攜創的Joinwork、
信雅達 SunFlow、東蘭LiveFlow、中創InfoFlow、
有生博大 RiseBPM、華創動力MatrixFlow、慧點Galaxy
東方易維Workflow、華苓AgentFlow、世紀金政Koof、盛鬆W-Flow、
東方通 TongWorkFlow、維泰WiseFlow、超微SuperFlow、明基逐鹿eFlow
面對這麼多的工作流廠商，開發商的選擇主要困難在三個方面：
（1） 很多開發商只有在接到工作流項目的時候才匆忙考慮購買產品，但此時客戶需
求詳細調研還尚未完成，其所面對的客戶也很難提出清晰明確的流程應用需求。
所以開發商很難有個準確的衡量標準來評價什麼產品最適合他們
（2） 很多產品的功能表述的都很類似，產品演示也看似相近。功能似乎很多，但是
到底哪些功能是真正需要的，而哪些產品是適合後續應用和擴展的，對開發商
來說是很難決斷的。
（3） 開發商的心理擔心和猶豫：畢竟購買的工作流產品，對他們來說，似乎就像一
個“黑匣子”一樣，很擔心後期實施中，因爲客戶的需求不滿足而又無法更改
產品，從而造成實施不下去的情況發生。
基於這幾年工作流諮詢和培訓的經驗，簡單闡述一些選擇的標準。主要是從如下幾個角
度進行選擇：
（1） 首先搞清楚客戶對流程設計器的要求或期望如何，是傾向於B/S 的web 設計器
還是，還對C/S 設計器也可接受。可能很多最終客戶對這兩者是用上的區別不
勝清楚，那麼就需要開發商首先自己需要清楚這兩者的區別，以及斟酌所定位
的客戶的應用習慣和場景，那種操作凡是更適合客戶使用。
（2） 其次，客戶對流程的應用模型和操作習慣如何，諸如是否支持“串型”“並型分
支”“條件分支”“同步異步子流程”“多種類型的執行人分配”“會籤”“回退”
“取回”“跳躍（速稱自由流）”等等，這些都是國內常用的基本流程應用需求。
相信這些功能很多產品也都宣稱支持，但是具體支持的力度，卻需要自己仔細
分析。舉個例子：有些產品宣稱支持回退，但是在項目實施的時候，卻告訴開
發商在流程圖上需要額外多繪製一條轉移連接線來實現回退的操作。那麼一旦
開發商所面對的客戶要求能夠實現“逐級回退”則變得非常棘手。
（3） 客戶的流程變更性如何，如果客戶提出了流程變更，那麼如何維護流程的變更
操作是開發商需要仔細考慮的。一方面以此來分析工作流產品如何支持流程變
更，一方面需要確定是否會存在客戶自己進行流程定義更改的情況。畢竟一個
工作流系統實施後，最終的使用者還是客戶，而客戶的業務應用有可能會在後
續發展中發生變化的。
（4） 客戶的應用系統中流程是否很多。存在有些工作流應用中，只實施幾個流程而
已，但也存在有的項目實施中，一個系統卻包含幾十個甚至上百個流程定義。
前一種情況如果產品提供商所提供的工作流系統完整性還不夠的話，通過後續
開發商的實施尚且可以彌補；而後一種情況則要非常小心了，開發商必須選擇
一個系統完整化和成熟度比較高的工作流產品。這樣一類的工作流產品除了流
程設計器和引擎以外，還可能會包含：可擴展的組織模型、表單系統、工作列
表系統，甚至還有監控和管理部分。——但是系統複雜度越高，擴展複雜度也
越大，所以開發商必須在這個層面尋找一個適度的平衡。
（5） 就國內目前的絕大多數流程應用來說，流程監控應用性需求還不是很高。很多
客戶提出對流程監控的需求，也僅僅只是“覺得有這個必要”，但等到系統真正
上線後，使用流程監控功能的卻很少的。但是，有這一類功能的工作流產品總
歸比沒有要強一些，但需要哪種深度的監控，那就需要開發商自己斟酌一下了。
這兩年在給一些開發商諮詢的過程中，碰到很多開發商希望工作流產品能夠“assembling
on demand”，就是能夠按照需要的功能組裝。因爲很多開發商抱怨，他們用昂貴的價格選擇
了一個很好的工作流產品，但是卻只使用了很少的功能；而那些價格較低的輕量型流程產品，
卻在有些功能上不能滿足或細粒度不夠，很難達到客戶和二次開發的需求。事實上我也一直
在期待國內能有這樣架構的流程產品出現。
第五個問題：如何更加有效的進行流程系統實施
如果此時開發商已經有一個基礎的工作流引擎或產品了，不論是採購第三方的，還是自
主研發的，那麼接下來所面對的最大的一個問題就是如何更加有效的實施流程了。
很多工作流實施階段本身其實沒有太多的技術難度關口，最大的難度是在需求調研階段
的“流程梳理”。很多開發商在需求階段都會反覆抱怨“客戶沒有什麼需求，或者客戶讓我
們先做個demo 再提需求”。
就目前國內流程應用情況來說，絕大多數客戶都會直接把“流程需求”的問題直接推給
開發商自己處理。這就需要開發商採取正確的策略和方式來一步步推進，而不能再像早期實
施其它MIS 系統似的採用“需求+靜態頁面Demo+數據庫設計+開發”策略了。
對於很多客戶來說，實施工作流系統一方面是響應“從有紙化轉變爲無紙化”號召，逐
漸推進信息化應用；另一方面則希望通過“流程系統”有效的梳理出某些流程在辦理過程中
的真正處理過程。
在早期沒有流程系統的時候，不論在政府辦公還是企業管理，某些處理流程雖然有“規
章制度約束”，但是在真正辦理過程中，因爲一些人爲的因素，會存在一些變通的處理，從
而會造成某些流程實際在審批過程中會“跳過”或“多出”一些環節。而且對一個管理人員
來說，當其面對一個審批文件過來的時候，一般是很難非常清晰這個事情到底要經過哪些環
節、哪些人的審批的。所以在現實操作過程中，很多情況是依據一些常規經驗和個人判斷處
理。
那麼流程信息化就要逐步幫助管理人員來逐步規範和梳理這些流程的處理步驟。這也是
很多客戶在流程信息化中的現階段真實目標。開發商只有摸清客戶對流程的真實目標期待，
才能過採取有效的需求調研和實施方案，以及流程實施功能定位。
網絡上不乏有一些所謂工作流實施介紹的文章，大體會告訴大家採用如下的步驟：建立
項目管理辦公室、業務分析、確定目標、確定實施計劃、流程建模、軟件集成······。這套
步驟對於那些具有深厚的行業應用積累經驗以及成熟的工作流實施經驗的廠商是非常合適
的，但是對於很多開發商來講，卻存在很大的誤導性。
前面已經說過，對很多客戶來說，其真正關心的是“梳理真實清晰的現實流程”。如果
開發商能夠通過與客戶的不斷溝通，逐漸幫助客戶梳理現實操作中的流程處理過程，並用流
程系統實現，則基本百分之九十的滿足客戶需求了。這個梳理過程不是一次兩次就可以清晰
搞定的，需要開發商在需求調研階段不斷的繪製流程圖（最好就用流程設計器直觀的繪製），
每繪製一次就與客戶進行溝通和演示，依據客戶確認後提出意見再修改，再完善，再由客戶
確認。如此反覆，才能正確幫助客戶梳理出流程。
在梳理流程階段，一定要把握幾點：
（1） 一定不要抱怨客戶提不出什麼需求，這個必須自己去逐步挖掘需求。因爲客戶
對流程系統和流程信息化所帶來的辦公操作和影響並沒有預見性，這需要開發
商逐步幫助客戶去理解，去應用。
（2） 一定要不斷的找相關業務處理的負責人進行流程確認，找真實辦理職員進行系
統演示，因爲只有這些人員才清楚現實流程的真實辦理過程。
（3） 不要把需求調研和流程實施過分區分開，如果在需求調研過程中，就一步步地
用流程設計器進行流程繪製，並給客戶演示，則更容易讓客戶提出一些潛在的
流程需求，而不至於到了項目後期或上線試運行階段，客戶才大量的提出修改
需求來。
作者簡介：
胡長城，網名“銀狐 999”。就職於TIBCO CDC，Infrastructure team
國內J2EE 開源應用的支持者，有過六年的J2EE 應用和產品開發及架構經驗，huihoo
開源組織成員。
國內工作流應用的推廣者，有過四年的工作流研發經驗。利用個人主頁和 Blog 共享了
很多寶貴的工作流研究心得。嘗試開拓了工作流培訓方式，爲企業工作流應用提供諮詢和指
導。