產品設計思考:績效管理系統詳解
本文對績效管理系統設計展開分析,筆者拆解了詳細的流程步驟,并對設計過程中的一些問題進行了思考總結,希望能夠給你帶來些啟發。
前段時間,筆者所在公司正在尋找績效管理的解決方案。先后考察過薪人薪事、歡雀、i人事等SaaS平臺,發現這些人力資源管理系統是對員工檔案/招聘/薪酬/績效/培訓等綜合事項進行高效統一管理,績效管理只是其功能的一個分支。
然而對于員工檔案/薪酬計算/招聘管理等我司已有成體系的解決方案,單為了一個績效管理功能而采購一整套人力資源管理系統是不明智的。而且這些人力資源管理系統的績效管理板塊并不能滿足公司頗具“個性化”的績效考核需求。
可能正是因為這些原因,公司才決定根據自身具體業務邏輯與組織架構的開發一套績效管理系統。
績效管理系統旨在高效的對員工的考核指標與績效評分實現線上統一記錄與管理,這個任務落在了筆者頭上。在與需求方對接完畢考核流程以及功能需求后,我仍然對薪人薪事等人力資源管理系統進行了簡單體驗。
薪人薪事績效考核流程
i人事績效考核流程
公司的績效考核流程
可見,績效管理是一個較簡單的工作流,包含:審批內容(即績效表單)+審批流程+審批節點(上級/HR等)。圍繞績效表單的關鍵節點動作有:發布/編輯/提交/通過/駁回等。
體驗了薪人薪事等系統的績效管理板塊后,我發現他們僅提供了較通用的績效考核方案,與公司所要求的考核方案有以下差別:
- 公司要求績效考核流程分為了“方案(考核指標)審核”與“結果評定”兩個階段,只有通過了“方案審核”的流程才能進入“結果評定”階段;而薪人薪事等系統的績效考核流程都是“考核指標“與”“評分”一并進行考核;
- 公司要求績效考核流程中各審批節點都需有通過/駁回的操作項,薪人薪事等系統不能滿足這樣較為復雜的審批流;
- 公司要求根據員工職級不同,其績效考核各指標占比以及績效審核流程也是不同的。
鑒于這些競品與公司要求的績效考核邏輯差別很大,實際參考意義并不大,所以績效系統設計中的坑還得我自己踩。
這篇文章是我對設計過程中的思考點的總結,算是一個簡短的項目復盤,以供自省。
一、審批流程的思考——逐級駁回or直接駁回
在與需求方確認完績效管理系統所必需的審批節點后,我一直再思考怎么盡量精簡整個考核流程。
比如各節點實行“駁回”操作時逐級駁回與直接駁回的選擇——“逐級駁回”顯然減慢了審批流轉速度,增加了無意義的審批流。
比如績效結果評定階段進行到副總審批,副總查閱后不認可評分結果,
逐級駁回的流程是:
- 駁回自評分:副總駁回→HR駁回→上上級駁回→上級駁回→員工修改后再提交;
- 駁回他評分:副總駁回→HR駁回→上上級駁回→上級修改后再提交;
直接駁回的流程是:
- 駁回自評分:副總駁回→員工修改后再提交;
- 駁回他評分:副總駁回→上級修改后再提交;
因為員工或上級才能對評分進行修改,他們必然是駁回的終點,所以選擇直接駁回讓流程更加簡單。
二、績效列表頁的信息展現方式的思考
列表頁的展示方式無非就是以表單狀態為維度或是以部門為維度或是以員工為維度三種方式,這三種維度實際上是瀏覽效率與信息詳細程度的權衡。
在做選擇之前,我們應該先思考相應審批節點的用戶(主要是HR與副總)打開”績效方案管理“頁面的需求:
- 進度把控——查看各個審批節點的方案數量,催促相關節點進行方案提交/審核;
- 高效篩選——快速找到需要自己審批的方案;
我們再來對比幾種方式的優缺點:
1. 以表單狀態區分的展示方式
優點:可以總覽全公司/各部門的各種狀態的績效表單數量統計;
缺點:單頁展示內容有限,瀏覽完各個部門的總覽需要多次翻頁,導致瀏覽效率降低;
根據組織架構以部門列表的展示方式
- 優點:為用戶提供了以部門為維度的初步篩選,瀏覽效率較高;
- 缺點:不能詳細展示各部門績效表單概況(因為頁面長度有限,不能將績效表單各種狀態在表頭中羅列,否則會出現橫向進度條,橫向進度條既不利于信息的直觀展示也增加了用戶操作成本;
ps:橫向進度條增加了用戶操作成本是指,相較于Windows用戶可直接用鼠標滾輪快捷操作豎向進度條,而操作橫向進度條時需要按住左鍵拖動鼠標)。
2. 直接羅列所有員工績效方案的展示方式
- 優點:-
- 缺點:數據量巨大,無法高效管理。如果一級頁面直接羅列,那就沒有了部門績效表單概況,即無法滿足“進度把控”的需求。
顯然,直接羅列所有績效方案的方式是不可取的;而以表單狀態進行區分的展示方式能同時滿足”進度把控“和”高效篩選“的需求,是最優選擇。
三、賬號權限分配方式的思考
績效管理系統里面根據用戶職級不同,他的操作權限、查看權限肯定是不一樣的。
進行權限板塊設計的時候必須要考慮的情況包括:人員組織架構的變動(部門變更+職級變更),人員的入職與離職等。
那么該怎樣設計系統功能從而達到高效又適用的權限分配?
我大致考慮到了三種方式:
1. 直接對每個賬號進行權限分配的方式
如果選用這種方式,那么每個賬號在創建時其權限就固定了,而且直接對賬號進行權限分配的方式在用戶基數較大時其操作就顯得相當繁復了。
考慮到公司的規模以及目前正處于快速發展階段,公司的組織架構與員工的職級調整都較頻繁,這種權限分配方式顯然是不合適的。
賬號分配職級,職級關聯權限的方式:考慮到每個職級(員工/上級/上上級/HR/副總)都有固定的操作權限,所以只需要將相應的的操作權限與用戶職級信息捆綁,管理員可通過修改用戶的職級信息間接的對用戶進行權限分配。
2. 賬號分配權限組,權限組分配職級,職級關聯權限的方式
將系統中所有功能對應的操作權限提取出來,由管理員建立權限組并配置權限組成員。即是在方案二的基礎上延展了“用戶組”的概念。
權限組的方式適用性更廣,擴展性更強(考慮到某個人身兼數種角色的情況,比如上級或上上級,作為普通員工績效流程中的審批節點,如果也被列入績效考核對象,管理員只需新搭配相應的權限組即可解決問題)。
第一種方案實際上就是傳統的權限模型,方案二和方案三是RBAC(Role-Based Access Control)權限管理模型,即用戶關聯角色,角色再關聯權限,從而間接地賦予用戶權限。
相較于對用戶直接賦予權限的傳統模型,能實現對用戶權限的批量管理。
試想用戶基數較大系統,如果在傳統模型下分別對每一個用戶設置或者修改權限,將是一項操作量巨大的工作。
但是即使用戶基數較大的系統,其抽離出的角色類型也不會太多,在RBAC模型下通過對角色對應權限的設置或修改就能簡化這個操作。
綜合考慮,選擇了方案二。因為已經與需求方確認過績效考核流程中這些角色及其操作權限都是固定的,且考核流程不會變動。
方案三在方案二基礎上增加的“權限自主配置功能”目前看來是多余的(不排除后續迭代會添加上這個功能)。
四、用戶體驗優化
B端產品雖然相較C端產品對交互體驗要求不是很高,但是易用性/穩定性仍然需要保障。
系統上線后,用戶抱怨在填寫績效時,系統會自動退出登錄導致填寫內容丟失(排查后發現是因為開發調用的tymon/ jwt-auth組件有定時退出登錄的默認設置)。
因為是內部系統,每一個差評都直接觸達,簡直振聾發聵。
這里我總結了一些優化用戶體驗的方法:
1. 避免橫向進度條
操作按鈕并未完全展示,“查看”前需要先拖動橫向進度條,增加了用戶操作成本。
2. 操作簡化
點擊某條績效方案除操作按鈕外的區域也可以直接進入績效方案詳情(同“查看”按鈕的功能)。
3. 各節點關鍵操作(發布/提交/駁回等)需要二次確認
主要是防止用戶誤操作。
4. 頁面排版自適應
5. 填寫內容自動保存
防止異常情況(自動退出登錄等)導致用戶填寫內容丟失。
總結
績效管理系統的設計最重要的就是把握好工作流,即審批內容+審批流程+審批節點。我也是太在意審批流程的正確性以及績效表單狀態的變化,卻忽略了另外一個重要內容——表格設計。
B端產品中的表格實際上是信息展示+詳情入口的功能,也涉及到部分交互體驗,那么設計一個能提高辦事效率的表格就尤為重要。
績效管理系統上線后再去回顧系統的表格設計,我發現了更多的思路。比如設計表格時每頁行數的規定、每屏行數的規定、豎向滾動時表頭的凍結、表頭內容的哪些在前哪些在后、表格中數據排序規則等其實都是值得深究的點,只能說B端產品的設計任重而道遠啊。
本文由 @伊甸東 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
目前也在設計,有幾點疑問不知道可否看下:
1、方案需要發起后,進入流程的審批環節,目前我在設計的時候,列表頁會顯示流程編號,該流程具體的考核人(因為我們是按人員制定考核方案,每個人的或多或少不太一樣)。
2、這種業務系統里有流程的,列表應該怎么設計呢,一直很頭疼,設計成跟OA那樣的臺賬列表貌似不太對。
原型可以分享嗎
寫得挺好的
謝謝認可 ??
大佬 可以留個聯系方式交流一下嗎
不敢當。人人平臺內容屏蔽較嚴。朋友如果有相關問題,直接留言交流吧。