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


http://m.tkk7.com/ronghao 榮浩原創，轉載請注明出處：）