一個(gè)完整的工作流引擎，應(yīng)該具備哪些功能模塊？這篇文章里，作者嘗試結(jié)合實(shí)際工作經(jīng)驗(yàn)和實(shí)際案例，對(duì)構(gòu)建工作流引擎這件事兒進(jìn)行了總結(jié)，并對(duì)工作流引擎的功能模塊進(jìn)行了大概講述，一起來(lái)看。

最近我做了工作流引擎系統(tǒng)，借鑒了市面上的一些成熟工作流引擎，將其做了一些簡(jiǎn)化以更適用于實(shí)際情況，同時(shí)在復(fù)盤的時(shí)候發(fā)現(xiàn)當(dāng)初踩了一些坑。所以希望以文章的形式寫出來(lái)構(gòu)建一個(gè)完整的工作流引擎應(yīng)該有哪些功能模塊，哪些功能邏輯，可以抽象哪些業(yè)務(wù)邏輯，有哪些思考的點(diǎn)。希望對(duì)需要的同學(xué)有所幫助，也和大家一起討論改進(jìn)。

文章分為兩篇，由4個(gè)板塊組成：

1. 工作流引擎簡(jiǎn)介；
2. 從案例出發(fā)推演功能；
3. 功能模塊概覽；
4. 功能與邏輯詳解。

本文包括前三個(gè)板塊。

一、工作流引擎簡(jiǎn)介

1. 工作流是什么？

為了完成某一項(xiàng)工作，而需要有多個(gè)環(huán)節(jié)、多個(gè)人員來(lái)分工、配合共同完成；而每個(gè)環(huán)節(jié)和每個(gè)人員的處理操作是有先后順序的，所以有流向性的特征，也就稱之為“工作流”。

做了8年产品经理后，我是这么看产品经理的

我个人是从非常初级的产品经理做起，再到负责一个大产品的项目管理，现在有幸跳出了日常基础的工作更多的去看产品的PMF，product strategy...

查看详情 >

常見的工作流簡(jiǎn)單的有如請(qǐng)假流程、離職流程，較為復(fù)雜的有采購(gòu)流程、立項(xiàng)流程等。

大家經(jīng)歷過就會(huì)知道一個(gè)工作流會(huì)有多個(gè)操作節(jié)點(diǎn)，也就對(duì)應(yīng)多操作人員；比如請(qǐng)假需要部門領(lǐng)導(dǎo)通過、人事經(jīng)理通過等，比如采購(gòu)需要領(lǐng)導(dǎo)驗(yàn)收合同、財(cái)務(wù)付款等（工作流和審批流的概念本文就不展開）。

2. 工作流引擎主要是用來(lái)做什么的？

工作流引擎是一個(gè)為實(shí)現(xiàn)工作流程的定制化，并驅(qū)動(dòng)工作流程完整進(jìn)行的工具。其特點(diǎn)在于可以實(shí)現(xiàn)隨著公司實(shí)際業(yè)務(wù)的發(fā)展（如組織架構(gòu)的改動(dòng)、業(yè)務(wù)邏輯的改動(dòng)），而能快速做出靈活響應(yīng)更改工作流，減少重復(fù)性的開發(fā)成本。

• 比如一開始公司只有10個(gè)工作流，隨著業(yè)務(wù)發(fā)展需要20個(gè)，多出來(lái)的這10個(gè)不用寫死在代碼里，直接可以在工作流引擎內(nèi)配置；
• 比如公司有人事變動(dòng)，需要更改某些工作的審批人，也可以直接配置；
• 公司的業(yè)務(wù)發(fā)生了一些改變，原來(lái)的審批節(jié)點(diǎn)只有5個(gè)，現(xiàn)在要增加到10個(gè)，等等情況都可配置。

3. 工作流引擎的邊界是什么？

工作流引擎主要只配置工作流，所以需要與業(yè)務(wù)系統(tǒng)如ERP區(qū)隔開，并需與業(yè)務(wù)系統(tǒng)通過接口對(duì)接，以此業(yè)務(wù)系統(tǒng)方可發(fā)起流程、審批流程、完成流程。

也就是說工作流引擎和業(yè)務(wù)系統(tǒng)是相互獨(dú)立但又通過接口對(duì)接的兩個(gè)系統(tǒng)，一個(gè)工作流引擎可以對(duì)接多個(gè)業(yè)務(wù)系統(tǒng)，為其配置工作流。

所以操作邏輯應(yīng)該是：先在業(yè)務(wù)系統(tǒng)定義有哪些流程，然后在工作流引擎中配置具體流程，再在業(yè)務(wù)系統(tǒng)中發(fā)起/處理流程，并在工作流引擎中可以對(duì)已發(fā)起流程進(jìn)行管理；當(dāng)公司的各類業(yè)務(wù)系統(tǒng)較多時(shí)，不用每個(gè)業(yè)務(wù)系統(tǒng)都去開發(fā)自己的工作流管理模塊，這樣可以較大地也提高了開發(fā)和維護(hù)效率，減少了開發(fā)成本。

二、從案例出發(fā)推演功能

了解了工作流引擎是干嘛的，我們就可以來(lái)看看其應(yīng)該包含哪些內(nèi)容。但是如果我一來(lái)直接就從某個(gè)功能開始講，大家肯定是比較抽象的。

所以我們先從一個(gè)審批案例著手，從0開始為完成這個(gè)案例我們?cè)撆渲媚男?shù)據(jù)？這樣更有助于大家能先有一個(gè)全局的認(rèn)識(shí)，然后再來(lái)講一個(gè)個(gè)的功能，這樣大家可能更容易接受。

前提條件：

某公司有甲、乙、丙、丁4個(gè)部門：

• 條件1：每個(gè)部門各有1個(gè)部門負(fù)責(zé)人a、b、c、d
• 條件2：甲/乙部門的分管領(lǐng)導(dǎo)是e，丙/丁部門的分管領(lǐng)導(dǎo)是f
• 條件3：東南區(qū)域的總監(jiān)是g，西南區(qū)域的總監(jiān)是h

假設(shè)成立項(xiàng)目也就是立項(xiàng)需要走流程，不同類型的項(xiàng)目走的流程肯定不一樣，假設(shè)關(guān)于項(xiàng)目的維度有項(xiàng)目等級(jí)（包括一級(jí)、二級(jí)），項(xiàng)目區(qū)域（包括東南，西南）。通過排列組合，我們可以得到以下4類項(xiàng)目：

• 項(xiàng)目1：一級(jí)項(xiàng)目，東南
• 項(xiàng)目2：二級(jí)項(xiàng)目，東南
• 項(xiàng)目3：一級(jí)項(xiàng)目，西南
• 項(xiàng)目4：二級(jí)項(xiàng)目，西南

有了前提條件，我們?cè)俜謭?chǎng)景來(lái)看，不同部門的人員發(fā)起不同類型的項(xiàng)目，流程會(huì)怎樣走。

場(chǎng)景1

如果一級(jí)項(xiàng)目由分管領(lǐng)導(dǎo)審批，二級(jí)項(xiàng)目由部門負(fù)責(zé)人審批，不管哪個(gè)區(qū)域的項(xiàng)目都要由區(qū)域總監(jiān)審批。根據(jù)這個(gè)前提我們就可以得到下面這個(gè)流程圖：

先解釋一下流程的構(gòu)成元素，如上圖：

• 有操作節(jié)點(diǎn)，比如提交、分管領(lǐng)導(dǎo)、部門負(fù)責(zé)人；
• 有網(wǎng)關(guān)，如菱形帶×這個(gè)是互斥網(wǎng)關(guān)；
• 有流轉(zhuǎn)條件，如圖內(nèi)的一級(jí)項(xiàng)目、二級(jí)項(xiàng)目，流轉(zhuǎn)條件是和互斥網(wǎng)關(guān)是一起使用，通過流轉(zhuǎn)條件來(lái)判斷不同的工作流數(shù)據(jù)該流向哪個(gè)操作節(jié)點(diǎn)。

如果從0開始，這個(gè)時(shí)候系統(tǒng)里什么數(shù)據(jù)都沒有，那我們是不是要先錄入部門、人員等組織架構(gòu)信息？所以就會(huì)得到如下圖簡(jiǎn)化的表單信息：

但是注意，這上圖只是組織架構(gòu)信息，并不是該人員在流程中的實(shí)際角色。

再回頭看一下流程圖，我們?cè)诹鞒讨兄粫?huì)有部門負(fù)責(zé)人、分管領(lǐng)導(dǎo)、區(qū)域總監(jiān)這3個(gè)角色，并沒有指定這個(gè)3個(gè)角色具體是誰(shuí)進(jìn)行審批？因?yàn)閍是部門負(fù)責(zé)人，b也是，g是區(qū)域總監(jiān)，h也是。

所以這個(gè)時(shí)候我們需要引入用戶矩陣這個(gè)概念來(lái)解決這個(gè)問題，也就需要再錄入一個(gè)表單來(lái)記錄流程中的實(shí)際角色，如下圖：

先說為什么要這樣一張表來(lái)記錄這些信息？為什么不直接用組織架構(gòu)表？這樣做主要達(dá)到2個(gè)目的：

1. 為了解決多個(gè)人員擔(dān)任同一角色，但又存在變量的情況（比如部門、區(qū)域不同），這樣在流程中只需要配置一個(gè)角色就行了，不用每個(gè)人員都配置一次（具體后面演示）；比如同樣是部門負(fù)責(zé)人，a管理甲部門，b管理乙部門。
2. 為了將組織結(jié)構(gòu)中的職位與流程中的角色進(jìn)行解耦；同時(shí)調(diào)整更靈活，比如在公司中叫部門負(fù)責(zé)人，在流程中可以叫部門老大，如圖3所示。

然后解釋一下為什么要條件變量和變量值？是因?yàn)椴煌捻?xiàng)目會(huì)流向不同的操作節(jié)點(diǎn)，系統(tǒng)就需要通過條件變量來(lái)判斷，而哪種項(xiàng)目要走哪條流程，是由其變量值來(lái)確定的。

根據(jù)以上變量值，再結(jié)合之前的流程圖，我們就可以得到下圖：

有了流程的相關(guān)數(shù)據(jù)，我們?cè)賮?lái)看流程會(huì)怎樣走。假設(shè)張三是丙部門的人員，他來(lái)走立項(xiàng)流程，不同的項(xiàng)目屬性會(huì)經(jīng)歷下列審批人：

流程的配置大概就是這些，但有1個(gè)思考的點(diǎn)：如果沒有用戶矩陣這張表，我們的流程會(huì)配置成什么樣？

如圖所示，我們需要把每個(gè)參與到人員都配置到流程中去，也就是一個(gè)人員就要占一個(gè)審批節(jié)點(diǎn)；并且只能通過流轉(zhuǎn)條件來(lái)控制該項(xiàng)目需要走到哪個(gè)審批節(jié)點(diǎn)。這樣流程將會(huì)非常龐大且臃腫。

場(chǎng)景2

基于場(chǎng)景1，我把這些元素打亂了再重新排一下來(lái)設(shè)定場(chǎng)景：如果甲/乙部門的項(xiàng)目由分管領(lǐng)導(dǎo)審批（e負(fù)責(zé)一級(jí)項(xiàng)目，f負(fù)責(zé)二級(jí)項(xiàng)目），丙/丁部門的項(xiàng)目由區(qū)域總監(jiān)審批（g負(fù)責(zé)東南，h負(fù)責(zé)西南），最后再統(tǒng)一由部門負(fù)責(zé)人審批。所以得到如下流程圖：

組織架構(gòu)的表單我們已經(jīng)有了，就不再贅述了。然后第二步我們需要往用戶矩陣表里添加信息：

第三步就能得到這個(gè)帶有用戶矩陣的流程圖：

所以可以得到以下結(jié)論：

• 假設(shè)張三是丙部門員工，發(fā)起一個(gè)一級(jí)、東南區(qū)域項(xiàng)目立項(xiàng)，會(huì)走g和c的審批；
• 假設(shè)李四是甲部門員工，發(fā)起一個(gè)一級(jí)、東南區(qū)域項(xiàng)目立項(xiàng)，會(huì)走e和a的審批。

為什么我會(huì)舉場(chǎng)景2這個(gè)例子？

通過場(chǎng)景1和場(chǎng)景2，大家可以看出條件變量有很多，包括人員所屬部門、項(xiàng)目所屬區(qū)域、項(xiàng)目等級(jí)，而對(duì)比這兩個(gè)場(chǎng)景大家可以發(fā)現(xiàn)，這些條件變量都是可以放到操作節(jié)點(diǎn)或流轉(zhuǎn)條件里去配置的。

比如場(chǎng)景1中不同的項(xiàng)目等級(jí)走不同的順序流，場(chǎng)景2中的項(xiàng)目等級(jí)是放到操作節(jié)點(diǎn)里，不同的等級(jí)經(jīng)過不同的人審批，而這個(gè)審批的角色都叫分管領(lǐng)導(dǎo)。

三、功能模塊概覽

經(jīng)過上面的例子，我們知道了一個(gè)完整的流程應(yīng)該包含哪些元素：組織架構(gòu)、用戶矩陣、條件變量等，有了這些數(shù)據(jù)才能配置到流程內(nèi)。

所以我們就可以看到一個(gè)工作流引擎應(yīng)該由以下功能來(lái)組成：

下一篇接著講工作流引擎具體的功能與邏輯。