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