基於WF設計業務流程平台 同一流程多種狀態

狀態圖是工作流設計中經常要用到的乙個設計圖形,

許多流程設計人員在與我談論狀態圖時,常對我說對uml中狀態圖的個種圖例都已熟練的掌握了,但每次畫業務流程的狀態圖時,總是覺得畫得不隨手.

其實,在畫業務流程的狀態圖時,很多人都犯了乙個錯誤,想用乙個狀態圖表現出流程的所的狀態

而在實際應用中,同乙個流程是用多組狀態的,在同一流程和不同參與者眼中,流程的狀態各不一樣

下面,我用乙個例子加以說明:

先說一下場景:

a公司(一家商業公司),要舉行一次商業活動,由[市場部]提出,[管理層]批准,[策劃部]策劃,[實施部]實施的乙個流程

先看一下全景流程

這是乙個最常見的流程

該流程是乙個多部門多職能參與的公事流程

在這個流程中體現了

業務公升級:[意向]->[需求]->[方案]->[實施計畫]->[實施]

對外職能對等,

以牽頭部門[市場部]不中新的業務旋轉移交

等標準特性.

這是傳統的企業管理中常用的一種模式,這種業務流程模式與扁平管理模式的業務流程,有著很大的為同.最大的特點就是不透表(其它不同我會在後面的文章中介紹)

當然不透明並不代表不好,很多時候,業務出於保密等原因需要在一定的區間內對外封閉,因此不同參與者眼中流程的狀態是不一樣的

本例中參與者有:

以下是每個參與者眼中的流程狀態

市場部.業務人員

市場部.主管

管理層.業務負責人

策劃部.策劃人員

略策劃部.客服人員

略策劃部.主管

略實施部.主管

略實施部.計畫人員

略實施部.實施人員略

從上面的一組狀態圖可以看出,同乙個流程在實施的過程中,在不同的參與者面前,流程的狀態在不同.

這就是我說的同乙個流程是,多組狀態

每個參與者對流程的認識只是片面的,如果流程製做人員只是根據某個參與者對流程的描述就去構建流程,那一定會出問題.

"不識廬山真面目,只原身在此山中",就是這個道理

如何為不同的參與者,涉眾,管理者,監督者,考核者設定各自的狀態,我將在[流程透明度]一文中具體講解

以下流程的透明原則我也會在以後的文章中具本介紹

本例中沒有涉及結點間的[補齊補正]與[退回重做]的狀態,

[基於wf設計業務流程平台_特殊事項,煩惱的花瓣],[基於wf設計業務流程平台_業務是不能回退的],兩篇文章會談這部分問題

還有,我為大家提供的例子中,已經提供了多狀態的流程設計支援,只是那個wf的客戶端ui中沒的實現圖形化的展現,在以後的公升級中我會加上

基於WF設計業務流程平台 同一流程多種狀態

狀態圖是工作流設計中經常要用到的乙個設計圖形,許多流程設計人員在與我談論狀態圖時,常對我說對uml中狀態圖的個種圖例都已熟練的掌握了,但每次畫業務流程的狀態圖時,總是覺得畫得不隨手.其實,在畫業務流程的狀態圖時,很多人都犯了乙個錯誤,想用乙個狀態圖表現出流程的所的狀態 而在實際應用中,同乙個流程是用...

基於WF設計業務流程平台 資料衝突

當乙個資料自身的改變會景響其資料時，所採取的一種解決方案 自變數據稱為約束源 連變資料稱為被約束源 資料是指儲存在資料庫中，電子文件中，紙質文件中，人們的記憶中的資訊 集聯是指 約束源 改變後使 被約束源 及時更新的一種方式 可集聯修改 是指 約束源 改變後，所有 被約束源 都能及時更新 不可集聯修...

基於WF設計業務流程平台 許可權在流程模板外部對映

基於wf設計業務流程平台 許可權在流程模板外部對映 前面的幾篇文章我介紹了一種許可權與流程模板相結合的設計方式,今天我介紹一種許可權在流程模板外部對映的計方式.限在流程模板外部對映,主要的實現思路是 示意圖如下 下面說一下 許可權在流程模板外部對映 與 許可權與流程模板相結合 兩程方式的各自特點 優...