討論一下你覺得一個工作流產品好的標準

NO IMAGE

 工作流現在已經應用的非常廣泛了,審批OA等等自然不必多說,許多業務系統裡也有大量的應用。前兩天的一個專案就是使用工作流將整個專案管理的過程進行整合,包括了前期預算、專案進度管理、合同管理等等。

可供選擇的工作流也很多,商業的、開源的。那麼你是如何評價一個工作流產品的好壞的呢?你的標準是什麼?當然,使用者也經常會問我這個問題,我的回答是:根據你實際的業務。是的,不管是什麼樣的工作流,都是為了滿足業務的需要,你把你的需求提出來,我們看看是否滿足,不能直接滿足,最合適的間接方式又是什麼。你說,我要有催辦。是的,我們有。你說,我要有任意回退和任意流。是的,我們有。你說,我想對流程例項進行分級管理。oh,沒有也,重要嗎?讓我們想想其他辦法。你說,你們符合BPEL標準嗎?這個。。。你說,你們採用了petri網模型嗎?汗。。。你說,你們是SOA架構嗎?。。。

我的衡量標準是這樣的:
1、流轉功能
  包括了基本的工作流模式實現,序列、併發、分支、匯聚、迴圈等等。這個是最基本的。其實開啟流程設計器拖拖拽拽很快就能知道這個產品到底實現了哪些流轉模型。實際這個的實現也是引擎的核心。有多種模型可以選擇。petri 模型應該是最靈活的了,也有很大的實現難度。但是流程模型做這麼靈活,到底實際能用上多少……就我個人的經驗來說,大部分的複雜性都是由流程的分支併發(m/n)引起的,最壞的辦法是強制要求客戶將這些併發的任務改成 step by step 的執行。這樣犧牲一點效率,還是可以把專案做成的。
2、業務的內在支援
  比如說催辦、時間服務、收回等等。我覺得這個與實際業務掛鉤,反而是最為主要的考慮。因為採用間接的方式必然會產生程式設計,而很顯然會耗費成本。
3、與業務的契合方式
  流程維護流轉。業務還是自己實現。如何將這兩者很好的銜接起來。同時這個過程還存在許可權的限定,每個執行節點對業務的許可權肯定存在差別,是否有一套完整的解決方案?當然這其中也包括了組織機構的適配,對各種組織模型的支援。
4、定義良好的API
  通常會存在工作流無法直接滿足的業務場景,那麼肯定需要程式直接呼叫工作流的API,清晰且簡潔的API。
5、流程的模擬
  這種模擬比較簡單,目的在於檢驗所定義的流程是否正確。出錯要有明確的提示資訊。普元的單點除錯?
6、電子表單
  我始終覺得電子表單目前實際應用並不理想,它僅僅只能處理簡單的業務。但是銷售的經驗告訴我,這是一個巨大的閃光點。使用者喜歡自己動手。流程定義實際終端使用者很難實際操作。我在想:簡化版本的流程設計器 電子表單也許會有很好的售前 效果。
7、良好的售後
8、良好的終端使用者體驗
9、效能
10、最好能夠和標準扯上關係,可是誰知道我是否真的有關係呢?