工作流現(xiàn)在已經(jīng)應用的非常廣泛了，審批OA等等自然不必多說，許多業(yè)務(wù)系統(tǒng)里也有大量的應用。前兩天的
一個項目就是使用工作流將整個項目管理的過程進行整合，包括了前期預算、項目進度管理、合同管理等等。
可供選擇的工作流也很多，商業(yè)的、開源的。那么你是如何評價一個工作流產(chǎn)品的好壞的呢？你的標準是什么？
當然，用戶也經(jīng)常會問我這個問題，我的回答是：根據(jù)你實際的業(yè)務(wù)。是的，不管是什么樣的工作流，都是
為了滿足業(yè)務(wù)的需要，你把你的需求提出來，我們看看是否滿足，不能直接滿足，最合適的間接方式又是什么。你說，我要有催辦。是的，我們有。你說，我要有任意回退和任意流。是的，我們有。你說，我想對流程實例進行分級管理。oh,沒有也，重要嗎？讓我們想想其他辦法。你說，你們符合BPEL標準嗎？這個。。。你說，你們采用了petri網(wǎng)模型嗎？汗。。。你說，你們是SOA架構(gòu)嗎？。。。
我的衡量標準是這樣的：
1、流轉(zhuǎn)功能
  包括了基本的工作流模式實現(xiàn)，串行、并發(fā)、分支、匯聚、循環(huán)等等。這個是最基本的。其實打開流程設(shè)計器拖拖拽拽很快就能知道這個產(chǎn)品到底實現(xiàn)了哪些流轉(zhuǎn)模型。實際這個的實現(xiàn)也是引擎的核心。有多種模型可以選擇。petri 模型應該是最靈活的了，也有很大的實現(xiàn)難度。但是流程模型做這么靈活，到底實際能用上多少……就我個人的經(jīng)驗來說，大部分的復雜性都是由流程的分支并發(fā)（m/n）引起的，最壞的辦法是強制要求客戶將這些并發(fā)的任務(wù)改成 step by step 的執(zhí)行。這樣犧牲一點效率，還是可以把項目做成的。
2、業(yè)務(wù)的內(nèi)在支持
  比如說催辦、時間服務(wù)、收回等等。我覺得這個與實際業(yè)務(wù)掛鉤，反而是最為主要的考慮。因為采用間接的方式必然會產(chǎn)生編程，而很顯然會耗費成本。
3、與業(yè)務(wù)的契合方式
  流程維護流轉(zhuǎn)。業(yè)務(wù)還是自己實現(xiàn)。如何將這兩者很好的銜接起來。同時這個過程還存在權(quán)限的限定，每個運行節(jié)點對業(yè)務(wù)的權(quán)限肯定存在差別，是否有一套完整的解決方案？當然這其中也包括了組織機構(gòu)的適配，對各種組織模型的支持。
4、定義良好的API
  通常會存在工作流無法直接滿足的業(yè)務(wù)場景，那么肯定需要程序直接調(diào)用工作流的API，清晰且簡潔的API。
5、流程的仿真
  這種仿真比較簡單，目的在于檢驗所定義的流程是否正確。出錯要有明確的提示信息。普元的單點調(diào)試？
6、電子表單
  我始終覺得電子表單目前實際應用并不理想，它僅僅只能處理簡單的業(yè)務(wù)。但是銷售的經(jīng)驗告訴我，這是一個巨大的閃光點。用戶喜歡自己動手。流程定義實際最終用戶很難實際操作。我在想：簡化版本的流程設(shè)計器+電子表單也許會有很好的售前效果。
7、良好的售后
8、良好的最終用戶體驗
9、性能
10、最好能夠和標準扯上關(guān)系，可是誰知道我是否真的有關(guān)系呢？


http://www.aygfsteel.com/ronghao 榮浩原創(chuàng)，轉(zhuǎn)載請注明出處：）