一般在稍微複雜一些的後臺系統中，工作流的設計是不可避免的一個重要部分。
設計好一個後臺工作流，不僅可以使得後期使用系統的時候更加高效，同時也是十分考驗產品經理的。
一、瞭解什麼是工作流及工作流的類型
在企業級的一些系統中，工作流是非常常見的一個輔助功能，因爲許多操作是無法通過操作者一個人來完成的。
在後臺系統中，用到工作流的我認爲大致可以分爲以下兩個方面：
①涉及到流程審批的系統功能
工作流涉及到流程審批的系統很常見，比如一般OA中的請假申請，加班申請，出差申請；人事系統中的入職流程審批，離職審批。
公司內部如果有業務系統中某些比較重要或者比較謹慎的操作，也需要層層審批。
對於流程審批類的工作流，其特點爲會將審批的角色劃分爲生產者與處理者。生產者即生產數據的角色，其在工作流的工作爲新數據的添加；處理者即對已有數據的進行某些操作。
從某種意義上講，工作流所進行的某些功能操作是以處理者的需求進行設計的。只是因爲某些生產類型的工作較爲低級，或者某些生產工作較爲繁瑣，處理者的職能地位已經不允許他去做這些工作，所以這些工作就被“下放”到了生產者當中，而處理者只需要判斷一下生產者的工作是否進行得當，並且提出一定的意見，讓生產者不斷地修改以期達到處理者最終想要得到的目的。
例如在進行請假審批的時候，領導需要看到的是請假者請假的事由，天數，請假類型等等，而不是請假者爲了讓領導看明白自己將請假的內容填寫的詳盡。所以我們在設計流程審批類的工作流時，需求方更多的要從處理者去考慮，要去把握他們需要什麼，再從中去設計定義內容。
②需要多人協作完成的工作
對於此種工作流來說，其目的主要是爲了讓某個角色更加專注的去進行某項工作。類似於流水線工作，在系統中所體現的就是到了哪一個步驟就將該工作流程流轉到某個角色，完成後再流轉到下一個角色，將所有的角色的工作流程串接起來，就是某項工作完整的工作流程。
比如電商後臺中WMS的庫存盤點。此功能的工作必然要涉及到覈對採購單，覈對銷售單，入庫盤點，差異登記，庫存更新等這一些列的操作，而這些操作則可以簡單分爲盤點前，盤點中，盤點後。
所以其流程就可以按照功能設計成這樣：首先採購人員、銷售人員報備採購單、銷售單，接着庫管人員進行庫存盤點，最後數據記錄人員進行差異登記，庫存更新，三個部分相互獨立卻又依次關聯。
關於此種類型的工作流，梳理前後邏輯關係流程，進行有效的功能拆分。並且可以通過某些操作將其串聯起來是設計中的重點。
二、工作流的設計要點
那麼，在瞭解什麼是工作流後，要設計好一個工作流，應該要考慮以下幾個設計要點。
首先，我們按照一個正常工作流的功能，可以將工作流拆分成以下幾塊內容。
1. 工作流內容的生產，處理，消費
對於流程審批類的工作流來說，工作流內容的生產端一般來說角色等級都比較低，僅僅作爲數據的記錄者而沒有任何的處理權限。所以在設計的時候，任何可以在生產端直接進行數據處理的操作都要慎重考慮。
比如，是否允許數據基本的錄入者直接進行刪改的權限？
某些對於數據狀態的變更是否可由其進行變更。而進行到了數據的處理階段，最終要對該項功能所填寫的數據進行產出，而在處理階段的操作，可以分爲兩種情況：
只做流轉操作，其流程節點可以理解爲一個高級篩選功能，目的只是爲了決定是否讓此條數據流轉到下一節點。
流轉的同時需要進行數據的修改或者補充。
這兩種流程角色的不同，定義着其在整個流程中的操作不同，一個只做通過駁回掛起等流轉性操作，一個卻可以進行信息的補充，刪改，以及其他內容的添加。
在設計工作的時候，要理清處理階段的角色工作模式，才能將工作流設計好。
對於多人協作的工作流來說，其每一個角色都是數據的生成者，每一個角色也都是數據的處理者。這個時候，類似於流程審批類的處理權限控制就沒有必要設計了。
因爲每一個流程操作的內容劃分的都很明確，流程與流程之間的操作並沒有重疊之處，上一個流程的操作只是作爲一個流程的前置支撐而已。所以在這個時候，要處理好的是角色之間的功能拆分，確保每一個角色每一個流程所進行的操作都是在流程下的充分必要條件。
關於數據的消費，指的是數據產生後是爲了做什麼。對於不同的角色來說數據的產生有着不同的功能，在設計工作流的時候，也要適當的把這些考慮進去。因爲我們設計的時候往往只關注數據的生成，而不去關注生成之後他要去做什麼。
比如我最近在做的一套商管系統，簽訂合同完成後是爲了生成店鋪，進行店鋪的操作，所以數據審批完成後就應該抄送一份給店鋪管理的角色。
比如某些採購單審批通過了 ，可能消費數據的並不是採購貨物的人員，還有財務人員需要進行入賬處理，所以數據應該也給財務一份。所以我們在設計工作流的時候，不僅僅要考慮到數據在整個工作流中的直接消費者，其間接消費者也應當進行考慮設計。
2. 不同情況的工作流狀態
一般來說，一個審批類工作流的狀態只從流程上來說的話大致可以分爲這幾個階段：未審批–審批中–審批結束。不同的階段又可以拆分成不同的情況。
比如在未審批的情況下，可能會有已經填寫但是未提交到工作流的情況，也可能會有已經提交到工作流但是發現提交內容出錯無法撤回的情況。
所以在審批的情況下，視情況可以添加保存的操作（對應的工作流狀態可爲未提交）；緊急撤回的操作（對應的工作流狀態可爲已撤回）。
在審批中，除了正常的一個節點一個節點的審覈外，可能會遇到的情況還會有該條工作流流轉到這裏時已經廢棄了，此時可以加上廢棄的操作（對應的工作流狀態可爲已廢棄）；還有可能流轉到這裏時發現整個流程有問題或者由於其他原因對於整個工作流有異議，但是可能該節點還有其他角色可以進行操作，所以需要將工作流暫時凍結，待確定後再重新激活，所以此時工作流應該加凍結/掛起的操作（對應的工作流可爲已凍結），以及對應的重新激活的操作（對應的工作流狀態展示即回到原有工作流的狀態）。
同時，在審批中可能因爲會有多個工作流的操作，但是這條操作比較着急，所以在數據的生產者端可以加上加急處理的操作，此時在處理者中看到的此條記錄應當爲置頂狀態。
但是由於加急處理的權重比較高，所以並不是每一個角色都賦予這個操作權限。
最後，應該給審批中設置一個審批時效，超時後是應當進行超時作廢還是超時退回也應該有明確的目標。
最後，是審批結束，其也分爲兩種情況：
一種是審批通過，一種是審批不通過。
對於審批通過，即爲該條記錄生成完成，可進行消費者的抄送等等操作，審批不通過，一般可以爲駁回狀態。對於駁回狀態，設計者需要考慮的是完全駁回還是駁回到上一個節點。
如果是完全駁回，則需要操作者重新填寫提交。如果是駁回到上一個節點，則上個節點的處理者應該有數據的編輯權限，由其進行二次編輯後重新提交其優點時流程較爲優化，時間可縮短，缺點爲並不是所有的處理者都有編輯權限，邏輯方面需要設計者思考。
對於協同工作類的工作流，工作流的狀態相對來說就是比較簡單的了，其每一個流程節點都是獨立的，只有上一個節點的工作完全完成後，纔可以流轉到下個節點，而且由於其沒有存在審批流的功能，所以在該節點填寫完成，提交至下一節點後當前節點的工作的工作就完成了。到下一個節點時與上一個節點邏輯相同直至結束。
三、工作流程的制訂及角色的劃分
這一點只針對審批類的工作流進行闡述。
傳統的工作流程來說大致可以分爲這樣幾種情況：自由/半自由流程、固定流程、分支流程、併發流程與執行、併發流程或執行。
自由流程指的是從生產者到處理者每一個流程節點都可以由上個節點的操作者指定角色，半自由流程指的是指定角色的時候限定一定的範圍。固定流程指的是流程是所有的流程即角色都是固定好的，不能修改。
這種情況的優點和缺點都極度的明顯：優點即操作簡單，邏輯簡單，開發難度小。缺點爲實用性較小，較爲死板，不夠靈活。
分支流程指的是當流程滿足某一個跳轉條件時即進行流程的跳轉執行子流程，當流程執行完畢後再跳回到主流程進行接下來的流程操作。
比如某次採購單的採購，當採購金額小於100萬時需要採購經理即可進行審批，當大於100萬時需要副總級別的人物進行審批後纔可以進行。
併發流程與執行指的是多個流程共同執行，所有流角色程都執行完畢後才流轉到下一個節點，比如某次項目的開始需要招商部，企劃部，工程部共同完成。 只有當這些角色都審批完成了才能開始。
併發流程或執行指的是多個流程共同開始，只要有一個角色進行審批了，則流轉到下一個節點。在此不做贅述。
在一般涉及到工作流的後臺中，這幾種情況大致就可以滿足。
以上可以稱之爲標準工作流，即後臺給予固定的模板，相關配置人員進行配置即可。但是，在有些複雜的後臺系統中，可能是以上幾種情況共同出現的，也可能是出現了其他情況，這個時候，就需要整體流程定製化的操作。
那麼，要設計一個非標準工作流，首先是分清上文提到的角色、內容、流程之間的關係——即角色與內容是掛在流程節點上的功能點。所以我們只需要將流程節點控制好，再將不同的角色，以及對應的操作內容掛靠上去即可，這樣一來是可以方便理清關係，另外也可以使系統更有層次。
所以接下來我們只需要將流程節點控制好即可 。
控制好非標準流程節點，可以由以下幾個方面着手。
第一、如果流程配置者有配置SQL的能力，那麼 將數據庫流程配置權限開放，讓配置者自行配置 ，這樣的開發工作壓力會小一些，但與此同時，風險也會很大。
第二、畫流程圖的方式 。一個流程的執行可以通過流程圖來表現，對於產品經理來說是再熟悉不過了。通過流程圖的基本邏輯，可以將流程中遇到的各種情況可視化的展示出來，條理清晰而且操作簡單。缺點即開發難度過大，一般小團隊難以勝任。
第三、通過一一配置功能來進行配置 ，這種方式雖然表面上看起來十分的繁瑣，但是相對於前兩種來說開發難度小，且對於配置者的能力要求不高。
具體來說，要單獨配置每一項功能的流程，先確定流程的主流程有幾個節點，如果碰到判斷的節點選擇是，碰到併發流程或執行的節點選擇最長的一個流程。
確定之後，將所有節點的內容操作與角色配置出來，然後再配置該節點是否進行判斷，是否進行或操作，是否進行與操作。
如果有判斷操作時，則分出一個子流程，再將子流程按照上述方式進行配置，最終歸於主流程的某一個節點。如果有與操作時，要確定配置與操作的分支節點時是要配置在單個節點還是多個節點。
單個節點的話則需滿足這兩個節點才往下進行，多個節點時則將這幾個節點作爲一個小流程單獨按照上述方式進行配置再合併至主流程，看是否滿足與行爲。
如果有或操作判斷時，同樣要確定在哪個節點的或操作至哪個節點可以進行另外的節點流轉。
以上這些情況對於開發團隊來說也是一個巨大的考驗，因爲不同的工作流程代表着不同權限的操作，不同狀態的流轉，而可定製化的流程則代表着其中的變化無窮，對於服務器的壓力，數據庫的冗餘情況都不容樂觀。
接下來的部分，我會簡單的分享一下如何才能高效的設計非標準工作流。
三、如何設計高效的非標準工作流
設計一個後臺壓力小，操作簡單的高效非標準工作流，我總結了兩個方式：第一、將非標準工作流拆分成多個標準工作流。第二、開闢獨立與配置權限之外的工作流角色模塊。
1. 將非標準工作流拆分成多個標準工作流
一個非標準工作流固然麻煩，可是在大多數的情況下，其可以拆分爲幾個標準工作流。比如，某個非標準工作流可以線性拆分爲多個分支流程，併發流程與執行、併發流程或執行。
將其每一個組合到一起，即可形成完整的工作流，那麼我們就可以在系統中提供組合模板，讓配置者可以進行選擇，組合到一起形成一個非標準工作流。
如果是非線性的，比如可能爲分支套分支，併發套併發的情況，我們可以將每一種情況都拆分成一個工作流，然後將生產端入口保持統一，每一步的不同操作可以進入不同的工作流，最終流轉的出口保持一致即可。有點類似於開發中設計模式的工廠模式。
2. 開闢獨立與配置權限之外的工作流角色模塊
一般來說，我們在配置工作流角色的時候，都是使用類似權限控制的角色，比如到這個節點角色爲庫管，另一個節點角色爲商管。其實換個角度想想，再說設計工作流的時候，完全可以設計一個獨立於權限之外只配置工作流的角色。
比如“分支節點角色1號”“流程角色1號”“併發或角色2號”，然後再通過窮舉法，將所需要用到的使用流程都列出來，把角色放置於節點上。
這樣，一個活的需要配置的流程就變成了一個個的死流程。
再將這些角色賦予權限角色。再定義一些規則：比如若沒有配置此節點的角色則此節點默認通過，將某個工作流角色配置兩個權限角色則爲或操作/與操作。這樣也就解決了上述的問題。
工作流可以說是後臺 系統中比較複雜的一部分。即便某些系統中一開始沒有工作流，隨着系統功能的增加，也不可避免會用到工作流，所以提前瞭解下工作流的設計方法，對於產品來說很有幫助，在開始設計的階段也可以考慮將內容設計進去以免後期維護成本過大。
