OA系統(tǒng)設(shè)計(1):流程
筆者有OA系統(tǒng)的設(shè)計經(jīng)驗,本系列將分篇章總結(jié)OA中最核心的功能,希望能盡可能全面地記錄筆者的經(jīng)驗,和感興趣的讀者交流分享。
OA系統(tǒng)對于提升企業(yè)和政府單位的辦公效率有非常重要的意義,其應用之廣泛無需多言。由于機構(gòu)內(nèi)部業(yè)務的復雜性、多種人員身份,以及不同組織間辦事流程的差異性,同時兼顧嚴謹和靈活導致OA的功能邏輯極其復雜。體現(xiàn)其復雜性的一個代表功能就是流程,這是本篇文章探討的對象。
一、關(guān)于流程的重要認知
1. 流程讓OA區(qū)別于其他系統(tǒng)
機構(gòu)內(nèi)各部門和人員間有嚴格的管轄關(guān)系,因此諸多業(yè)務都有嚴格的辦事流程。
最容易想到的例子就是行政事務的審批流程,比如員工提交請假申請,需經(jīng)直接領(lǐng)導、部門領(lǐng)導、分管副總審批,最終匯總到人事部門。其他例子還包括部門申請某會議室的使用權(quán)限,或者內(nèi)部公告在發(fā)布前經(jīng)相關(guān)人員審查內(nèi)容等等。
由于OA的主要目的是把線下業(yè)務移至線上,因而OA的業(yè)務模塊往往要遵循特定的事務流程,深深打上了“流程”這個讓OA區(qū)別于其他系統(tǒng)的印記。
2. 流程模塊要獨立于業(yè)務模塊
諸多業(yè)務模塊都可能涉及流程,從程序設(shè)計的角度來看流程的代碼實現(xiàn)應當被作為公用的獨立的函數(shù)被其他代碼模塊調(diào)用,對于產(chǎn)品設(shè)計而言同樣要把流程配置作為單獨可訪問的功能模塊,避免流程和業(yè)務的耦合。
業(yè)務模塊通過特定的接口查詢流程節(jié)點的信息,或者向流程模塊傳遞更新的流程信息。如此一來,產(chǎn)品經(jīng)理需要思考如何讓某個流程和具體的業(yè)務綁定。
解決思路無非兩種,在流程配置模塊里設(shè)計好流程,然后選擇關(guān)聯(lián)的業(yè)務模塊;或者在各業(yè)務模塊里分別嵌入可以配置流程的子功能。第二種方式更靈活,可以根據(jù)業(yè)務模塊的特別需求定制改造流程配置的功能細節(jié)。
二、流程模塊的構(gòu)成
1. 流程繪制
流程繪制過程中的可視化方式因系統(tǒng)而異,我們不討論這個方面的問題,值得探討的是流程節(jié)點的類型。業(yè)務場景決定了系統(tǒng)應該提供哪些流程節(jié)點,下面列舉幾個常見的節(jié)點類型。
1)審批節(jié)點
審批節(jié)點指定了在該流程環(huán)節(jié)由誰完成審批動作,應當提供豐富的選擇以滿足不同的業(yè)務場景。下面列出幾種指定審批人的方式:
- 指定用戶:用于特別要求交給某個人處理時。不具有通用性,不常用,但不排除用于應對特殊情況。
- 直接上級領(lǐng)導:比如請假單這類行政審批單,交給直接領(lǐng)導審批。
- 指定職務的用戶:比如辦公設(shè)備的申請會提交到設(shè)備管理員,只需要指定“設(shè)備管理員”職務。
- 指定接口人:比如提前創(chuàng)建好一個“公文接口人”的接口人類型,包含所有部門的助理。下發(fā)全公司公告時選擇發(fā)給“公文接口人”即可。
- 指定角色的用戶:比如所有的高管都有“高管”角色(角色賦予了用戶特定的權(quán)限,接口人是不定義權(quán)限的,只是圈定某一些用戶而已)。比如公司財務報表最終發(fā)給所有高管查看,在流程節(jié)點里指定“高管”角色即可。
- 指定部門+以上條件:組合條件提供更嚴格的限制。比如請假單提交給“人事部門”的“HR”。
2)會簽節(jié)點
會簽指的是多人共同簽批,該節(jié)點要指定多個審批人,并且設(shè)置會簽規(guī)則,包括一人同意或者全部同意即可進入流程下個環(huán)節(jié)。
3)分支節(jié)點
流程不一定沿著一條路徑從一而終,就像分岔路口一樣,多個分支通往不同的方向和目的地。分支節(jié)點之后定義多個流程分支,流程發(fā)起人或?qū)徟嗽跇I(yè)務模塊里填寫的信息決定了流程向哪個分支發(fā)展。
比如請假天數(shù)少于3天時只需要部門負責人同意,請假天數(shù)超過3天需要分管副總同意。
2. 按鈕配置
這里的按鈕指的是“提交”、“同意”、“退回”等顯示在業(yè)務模塊給用戶使用的按鈕,用戶點擊按鈕后觸發(fā)不同的后續(xù)流程。
雖然按鈕顯示在業(yè)務頁面,但是按鈕應該在流程模塊里定義。在流程節(jié)點上可以自定義按鈕的名稱,并且定義每個按鈕關(guān)聯(lián)的后續(xù)流程。
3. 字段校驗
在流程發(fā)起人或?qū)徟它c擊上文提到的按鈕后,需要校驗業(yè)務頁面的信息是否填寫完整、正確,才能進入到下個流程環(huán)節(jié)。不同按鈕要求校驗的字段可能不同,比如有的按鈕要求頁面所有信息都填寫,有的按鈕要求部分信息填寫就足夠了,一般校驗字段是否必填即可。
有的校驗規(guī)則比如要求填寫純數(shù)字、純字母、或者郵箱地址,在業(yè)務模塊的控件上而不是這里提到的按鈕上施加這樣的校驗規(guī)則比較合適,比如填寫請假天數(shù)的控件只能填寫數(shù)字,這一類校驗規(guī)則應當在業(yè)務模塊定義而不是流程模塊。
4. 字段權(quán)限
處于流程某個環(huán)節(jié)的用戶看到業(yè)務頁面的內(nèi)容應當被限制使用權(quán)限,比如請假單填寫人可以填寫請假時段、請假理由等,審批人只能查看這些字段而不能編輯。字段權(quán)限包括只讀、編輯、隱藏。在流程節(jié)點上設(shè)置字段權(quán)限。
三、流程繪制界面
流程繪制界面常見的有兩種:
1. 全局型
這種類型的展現(xiàn)方式可以直觀地看到整個流程的全貌,特別適合于流程分支很多的情況,只是繪制操作復雜一點,需要考慮節(jié)點和連線的擺放位置避免混亂。
比如下圖展示的是公文發(fā)布流程:
2. 局部型
在這種流程表現(xiàn)形式下,同個頁面只能展示部分節(jié)點,繪制時不用考慮節(jié)點和連線的擺放,流程復雜時可以只聚焦部分流程,減少干擾。
下圖截自阿里的宜搭,流程節(jié)點排列在一條直線上,“環(huán)節(jié)1”節(jié)點是另一部分流程的入口,點擊后查看該部分流程的細節(jié),如圖“宜搭-流程界面2”所示。
宜搭-流程界面1
宜搭-流程界面2
下圖是“請假理由”字段取值不同時的流程分支,查看方式不如全局流程圖直觀,特別當流程分支多層嵌套的時候非常不方便。所以這種展現(xiàn)形式適用于流程簡單的場景。
宜搭-流程分支
本文由 @Twincus靚 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議
對分公司眾多的企業(yè)來說全局性的流程走向展示更方便管控,可流程分支條件太多,每次從集團層面梳理也很費時,市面上的OA基本沒有支持批量導出審批分支條件的功能,對流程管理也是個挑戰(zhàn)
當流程涉及多分支的時候,審核條件是怎么配置的
流程配置中按鈕配置方便進一步解釋下嗎?
OA officeannotation