誰應該用流程設計器

在業務的梳理和設計階段都有可能用到流程設計器，這里提到的流程設計器是指有圖形界面，可以通過拖拽圖形設計流程圖的設計器，而不是說一個開發者專用的XML編輯器。

既然涉及了圖形化，就可以實現通過流程圖與最終用戶進行交互，對實際業務進行梳理和重組。圖形比文字更容易讓雙方理解，這一點應該不會有什么反對意見吧？

下面就引出我們這次討論的問題：“那么這個流程設計器到底是應該面向程序開發人員使用，還是面向最終用戶使用呢？”

這個問題會衍生出多種不同的推斷，討論的焦點基本是圍繞在：“是否要放權給客戶進行設計工作呢？”

對 于這個問題大部分程序員都能及時給予否定的答案：“怎么能讓不懂技術的人去負責設計工作呢？他們設計出來的東西要是用程序無法實現該怎么辦？”社區中力挺 這種觀點的人不在少數，比如OSWorkFlow就建議開發者通過直接編輯流程定義XML的方式設計流程，它們認為流程設計完全屬于開發范疇，不需要也不 應該由最終用戶介入。

但是，從最終客戶方面又常常傳來：“需要對業務進行定制調整”的聲音，于是迫于市場和客戶方面的壓力，開發設計人員又開始研究如何讓最終用戶可以在應用層面對業務實現進行干預，于是出現了關于自動建表，定制表字段，自動生成表單等等相關的技術。

面對如此浪潮蜂擁，諸如MDA體系架構也開始蠢蠢欲動，想當初多少人怒吼著：“讓開發人員失業，零編碼實現業務系統。”那時的開發人員真是岌岌可危啊，總是擔心害怕自己哪一天就被某個程序給替代了。可實際上過了這些年，也沒看到開發人員集體失業的情況。

難 道是客戶方面定制業務的需求減少了嗎？好像不是因為這個原因，還是有很多客戶抱怨市場瞬息萬變，應用系統不好支持多邊的市場風向。既然不是客戶的需求減 少，而實際開發人員又沒有被諸多的業務定制系統擠掉工作，那只能說明之前烽火連天的業務定制系統還無法完全滿足客戶的需求，客戶依然需要通過開發人員才能 實現自身特定的業務需求。

現在我們依然需要面對的問題是：“客戶需要隨著市場的變動對業務作出調整和變化。”這個需求是現實存在的，既然市場提出了需求，勢必會導致我們聯想到是否可以將圖形化的流程設計器直接提供給最終用戶實現，以便用戶對業務進行修改呢？

必須事先了解一點：“最終客戶不是開發人員”， 他們不可能像程序開發設計人員那樣信手拈來的編寫代碼，對業務模塊進行調用，這一點就決定了我們最終提供給業務人員的設計器必定是功能受限的，不能把所有 功能都對其開發，而是應該限制他們的操作范圍，讓他們的操作保持在可控范圍內，避免出現業務人員設計出一個完全不可能運行的流程圖來，同時又要加強用戶交 互的易用性，從這些方面來看，不論對設計和開發方面對我們提出了不小的挑戰——如何幫助用戶在不犯錯的情況下，很容易設計出一個業務流程呢？

我們可以看到，如果要滿足客戶定制的需求，就需要提供兩套流程設計器，開發版流程設計器需要提供各種接口方便開發擴展調試，最好還能和實際開發的環境集成。業務版流程設計器就要更加強調易用性，在功能方面進行限制，豐富校驗和提示方面的信息。