彪悍的人生不需要解釋

我對工作流概念的理解

現在，很多所謂的協同工作流實現都出現了理解歪曲。對此，我將描述一種新的工作流概念的理解，然后基于其上，對xpdl做一個改造，形成新的工作流的描述語言。

我們做software,常常自然地關注功能概念，即寫碼+硬件組成一種可用的功能，比如我們常說給用戶編出一個查詢存貨列表的功能，再加一個菜單；我們常常單純基于這種功能概念構造系統。所謂對功能“搭積木”模式更加體現了這種概念。從深層次講，這滿足了一種靜態觀察的需求；而隨著用戶水平的提高，他們逐漸能夠表達一種基于動態觀察的需求。典型地說，管理者希望確保某個產品從進貨到出貨的整個過程都是最有效率的。繼而，整個企業需要整個企業的運作中每個環節都是最正確有效的。對于企業而言，企業的每一個變化，活動，最好都是實現企業目標的最有效，最正確的一步。企業的需要，就是幫助他們實現企業，這個系統，一直以正確的活動序列向著企業目標運行著。目前用戶還沒有完全能把這種需求表達確切，現在所謂“協同”等概念其實就是對這種需求的模糊的表達。下面我試著表達解決這種需求的模型思路。

人如何實現目標？人類有一個一般的解決途徑---控制系統的變化。比如我們追求自己的某個目標，往往先做一個計劃，然后依照計劃不斷實現，反饋，修改計劃。計劃本質上就是對變化的控制。我們的思維中很重要的很基本的一條，就是從目標出發，分析出達到目標的途徑。之后我們按途徑進行受控活動。比如我們想解決溫飽，最終就會分析到占有土地，提高種子質量等，然后我們會控制自己或員工去一步步做這些事。

企業的每一個具體活動如果都是某個定義好的流程實例的環節實例(都是計劃的一部分)，那么所有的活動就可以完全受控。受控就意味著可以進行優化，監控等，所以能控制到所有活動基本就成為實現最終需求的基礎。

?? 控制的粒度需要非常靈活。我們允許用戶去定義提交一個存貨單就是一個環節，也可以包括更多的內容在這個環節中。不同的企業規模，即使同一個業務流程，肯定對控制粒度要求也不同。所以保證這種靈活性非常重要。

?? 流程就是活動的階段性集合。比如全局就是一個流程，就是說企業的整個運作就是一個流程。之后比如什么請假流程都只是其中的一部分。而活動是一個黑盒，不可再分，它的劃分涉及到粒度的把握。定義一個流程，實際是需要規范一系列活動。隨著流程種類的不斷開發，整個企業的運作就會日益受到控制。隨著粒度的分合，運作的管理更加細致科學。而且隨著整個社會的進步，活動系列也會相應調整，流程定義也要不斷更新。所以要保證流程定義的易操作。這個多采用圖形化定義解決。

?? 流程的定義本身是一個控制活動的直接手段。通過借助觀察大量流程實例的數據，可以進行統計分析，反過來改善流程定義。再加上對一個流程實例本身可以做暫停等管理，從而實現對整個企業活動的長期規劃，即時調整，最終滿足企業的需求，控制住企業的良好運作。

?? 這是基于這種需求的理解，這種解決思路，使得這個模型非常不同。

?? 1 流程定義。現在的流程定義，都出現了參與者等信息，而且還出現了如何運作的信息 --- 關聯某個應用功能模塊。這些我認為都是一種歪曲。實際上這樣做就將另一層次的需求混雜了進來。那就是通用的功能模塊。比如某人在某環節可以填某個表的某些字段。這個出現在流程定義中，混淆了流程定義的本義。我認為流程定義本身僅僅是活動的劃分。至于這個活動誰來完成，如何完成，根本不屬于流程定義的范疇。定義一個流程，是對全局流程的某系列活動的一個劃分，描述信息就是做什么的或者說達到什么目標的，本質是劃分依據。每一個元素就是一個活動。這個活動的信息可能沒辦法明確出什么目標，但是基本上也是一個劃分依據的描述。

?? 但是我們描述流程的時候，往往習慣有一個流的概念。即 A 結束后是 B 。實際上這種信息根本無法靜態描述。這一點和前面說的混淆，這兩點導致實現非常不順暢，高度太低的原因爾。

2 反過來說這兩點，以另外的方式處理。表的字段訪問控制作為一個通用功能單元即可，參與者放到權限控制模型中去實現。對于 transition ，由活動環節本身在結束時指定下一個。而如何指定，提供一個根據默認定義指定的通用功能。而這默認指定，則可以在流程定義中給出。雖然形式上仍然是元素間連線，但意義不同，這樣我們不把這種 transition 信息作為流程定義的必需組成。

3worklist 。實現這樣一個功能單位，讓用戶自己去一個列表中領取進行中的環節即可，某個用戶判斷可以結束了，直接聲明結束環節。這是最簡單直接的實現。不用擔心權限問題，因為即使領取了環節，也不一定有功能權限去做實際功能。當然為了方便用戶，可以做一個功能單位，讓不同用戶看到可以做的環節。

4 管理。其實就是那些暫停，看流程實例狀態等。以新的理解，那其實這些也是某環節活動的組成部分。像原來一樣做。當某個流程暫停了，那么系統就不會允許下一個環節的誕生。

5 至于所謂業務數據流，其實對于某一個功能，如果當初設計的是環節相關的，那他就可以通過領取的環節取到環節 id, 流程 id, 這些就足夠了。如果不是環節相關的，比如某人的基本信息錄入，那可能根本用不到這些數據。顯然，一個環節可能是需要使用多個功能，這也和以前的理解不同。實際上我是這樣做對，一個用戶開始進入系統，默認持有系統流程大環節 id, 然后在列表中選擇一個環節來參與進去，那就在會話中一直持有該環節。這體現了用戶 A 正在受理某業務環節中的現實表現。

探索中，歡迎交流！msn:sun_v2006@hotmail.com