第五章:流程設計方法論-成為機器的奴隸,或是製造腐敗

作者:neo yang 時間:2022/06/07 讀: 4689
文件大綱一、流程的本質二、流程的要素1、驅動力模式2、任務與狀態3、節點(1)驗證機制(2)駁回機制4、監理[…]

文件大綱

一、流程的本質
二、流程的要素
1.驅動力模式
2、任務和狀態
3、節點
(1)驗證機制
(2)駁回機制
4.監管機制
三、流程的設計模式
1、面向狀態(誰做都行,以事為中心)
H2、面向節點(不是誰都能做的,以人為中心)
3.面向狀態還是面向節點,這是個問題。
四、流程模型
1、箭頭模型
2.層疊模型
(1)層疊模型有兩種:
(2)回饋機制
3、水池模型
4.模型的混合使用
五、多層流程的設計
1、單一任務,多層狀態
2、單一主任務,多重子任務
3.兩種多層流程設計的方式各有優缺點

零幾年的時候,我曾經在國內的頭部網路企業工作。當時,公司內部使用一套工單系統來實現工作協同。那個時候,不像現在,有很多的協同工具可以選擇。所以,那套工單系統曾被我仔細研究。

也就是那個時候,我開始注意流程的設計和管理。

在後來的很多年裡,我曾經做過很多流程類的產品,甚至也做過流程引擎。

前幾年曾經專門複盤這些流程類的產品,最後,搞出來自己的一套流程設計方法論。

可能不像很多方法論那樣高度抽象,但勝在簡單實用。至少對於大多數流程的設計來說,基本上可以拿來就用。

一、流程的本質

流程的本質就是事物狀態的有序化。

任何事物,依照一定的標準,都可以用一連串的狀態來標註。而這些狀態的有序化便形成了流程。

二、流程的要素

1.驅動力模式

被動模式和主動模式。

任何一個流程的運作都是有自己的驅動力的。

被動模式的驅動力來自上一個流程節點,也就是上一個節點驅動下一個節點。 (簡單理解:任務從上一個執行人轉給下一個執行人,下一個執行人被動執行。)

主動模式的驅動力來自流程節點本身,或稱為自驅動。

不同的驅動力模式,決定了流程設計的時候如何選擇流程模型。

流程設計是必須考慮整個流程的驅動力模式的。否則,很可能會造成,你設計的流程,「不好用」、「不合理」、「太麻煩」。 。 。 。 。 。

在同一個流程中,主動模式和被動模式可以混合使用。主要看具體的事務和場景。

2、任務和狀態

一個流程的流轉,是需要一個狀態化的東西來統籌整個流程的,這就是任務。任務的狀態的有序變化形成了流程。

一個任務,可以是一個文件、一個票據、一個訂單、一個工單、一個卡券等等。

一個流程只能有一個任務。或只能有一個主任務,在流程中可以被分割成多個子任務分別執行。

3、節點

節點就是執行人。

也就是,每一個任務的狀態的具體執行者。可以是人,可以是程序,也可以是機器設備等等。

一個節點可以只執行一個狀態,也可以執行多個狀態。這主要取決於流程的設計模式(詳見後邊的「三、流程設計模式」)。

對於每一個節點來說,狀態的切換,不一定會伴隨節點的切換,但節點的切換一定會伴隨狀態的切換。這算是一個流程設計的原則。

而每一次節點的切換,都會需要對應的驗證機制,以及有可能會用到的駁回機制。

(1)驗證機制

每一次節點的改變,都會執行驗證。

  • 前置驗證:

有的是在節點切換之前驗證目前節點的執行結果,透過驗證,則切換下一個節點。

  • 後置驗證:

在節點切換之後驗證上一個節點的執行結果,如果無法通過驗證,則執行駁回機制。

(2)駁回機制

如果流程的驗證機制是後置驗證,那麼就必須要有駁回機制。駁回機制就是驗證上一個節點提交的任務不合格,而退回給上一個節點的機制。具體的驗證標準、規範、退回方式、駁回後要如何處理等,都是需要在設計流程的時候考慮的。

4.監管機制

每一個流程都應該有監管機制。監管機制主要有兩種。

  • 記錄型監管

最簡單,也是最基本的監管機制,就是將記錄任務的執行過程,即任務狀態的變化和每個狀態的屬性和執行結果等。出了問題,便可以追溯原因。

  • 即時監管

即時監管流程的每個狀態的執行情況,發現不合規之處,可立即介入。

三、流程的設計模式

1、面向狀態(誰做都行,以事為中心)

這個比較常見。重狀態,輕節點。我們大多數見到的和做的流程都是這樣的設計模式。

先做什麼事情,然後得到一個什麼狀態,然後再做什麼事情,再得到一個什麼狀態,然後再透過圖像識別,得到一個什麼狀態,然後再做什麼事情,得到一個什麼狀態。 。 。 。 。 。

流程中的所有節點(人、程序、機器等)圍繞著一件事、一個機械化的步驟,按照固定的規則在做各自負責的事情。

你可以把它理解成「流水線」。

2、面向節點(不是誰都能做的,以人為中心)

這種比較少見。輕狀態,重節點。

任務先交給誰,能得到一個什麼結果,然後再交給誰,能得到一個什麼結果,然後再交給哪個機器,能得到一個什麼結果,然後再交給誰,能得到一個什麼結果。 。 。 。 。 。 。

一般來說,在一些非標準化、節點產出的結果差異較大的情況下,或是在一些鬆散的組織和流程中,才會考慮使用。

在網路產品中,不多見。目前,主要是在一些協同辦公產品中會用到。

3.面向狀態還是面向節點,這是個問題。

或許,上帝之所以會存在,是因為這個世界不完美的原因。

一個流程的設計,無論面向狀態或面向節點,都不可能設計出一個絕對完美的流程。

面向狀態的終極,人類終將成為程式和機器的奴隸。

面向節點,很容易會造成權利的集中和腐敗的產生。

所以,最後,流程要使用什麼樣的設計模式,還要看具體的業務場景。適合的才是最好的。

四、流程模型

以下内容只有VIP用户可以看。

订阅VIP

訂閱我的VIP會員,可以閱讀所有付費VIP內容。

如果您已是VIP会员,请登录.


copyright © www.lyustu.com all rights reserve.
Theme: TheMoon V3.0. Author:neo yang