基于前文對工單的功能架構的重點功能的了解，本文将從【使用者管理】、【工單查詢】、【工單質檢】三個功能子產品進行闡述，對工單系統的功能架構做一些補充，希望對你有所幫助。
前言
工單的功能架構的重點功能前兩篇已經闡述完了，本篇我們主要在于查漏補缺，闡述清楚前兩篇沒有講到的【使用者管理】、【工單查詢】、【工單質檢】三個功能子產品，給工單系統的功能架構結個尾。
同時我們也将前文遺留下來沒有解釋的【管道接入】、【配置元件】、【流轉流程】三個問題解釋清楚。
一、使用者管理
1. 賬号管理
工單系統的賬号體系要與設計規劃相呼應。如果隻是面對背景服務部門的賬号體系，那僅僅與服務部門的業務系統中的賬号體系做好對接，直接複用業務系統的賬号體系就夠用了。
如果在設計階段就期望能夠通過工單系統貫穿全公司業務範圍，那麼工單系統的賬号體系最好和公司内部内網、移動辦公等系統的使用者中心打通，直接和公司級的賬号體對接。
這樣不僅在賬号體系上不需要重新設計，并且能夠與業務系統或使用者中心的使用者賬号同步進行增删改的操作，後續對接各系統時也不用考慮賬号、登陸等問題。
2. 權限管理
在權限控制上和其他所有B端系統一樣，工單也需要根據權限管理的方法對使用者的權限進行控制。權限設計主要有3個原因：
（1）高效分工
權限設計并不僅僅隻是為了系統的安全和保密，也在一定程度上有利于提升專業化分工。各部門的業務人員能夠專注于各自的業務範疇，進而提升工作效率。
畢竟工單系統又對接合作方、又關聯客服、還有商務、維修各個部門，針對不同的部門需求還有不同的處理邏輯，通過對建立環節的工單分類進行控制，可以大大提升業務人員對自己負責業務方面的關注度。
（2）資料安全
如果我們設計的是一個能夠打通全公司上下遊協作的通用工單系統，那麼系統中存儲的使用者、交易、業務問題等資訊在成為公司寶貴的過程資産的同時，也會成為外部重點攻擊的對象，系統自身的資料安全性也将是非常重要的一個方面。通過權限管控也能在一定程度上減輕人員問題導緻的資料洩露。
（3）權責分明
清晰的權限設計也有利于減少操作風險，保證權責分明。權利義務是相等的，權限不僅僅是代表你擁有了通路、檢視、操作某些頁面的權利，同時也代表了你将需要承擔這些頁面通路、檢視、操作的過程中的風險控制責任，在出現問題時也能更容易通過權限進行責任認定。
（4）小結一下
是以，對于權限的設計也是需要考慮的問題。在權限設計上，我們建議使用最通用的RBAC模型設計方法，權限–>角色–>使用者的方式進行通路控制，能夠在滿足最小權限原則的同時比較好的相容更靈活的權限配置。同時根據不同的處理組，我們也可以在處理組上對權限範圍的限定進行補充。
二、工單查詢
工單系統除了能夠提高各部門之間的協同效率之外，做到業務處理的資料留存也非常重要，這些一條條的工單資料也是組織業務發展過程中的資料資産。并且在工單日常營運和管理過程中，營運人員也需要掌握工單的處理情況，對工單資料進行檢視并作出簡單分析。是以對于工單明細記錄的查詢也是輔助性的功能之一。
在工單較多的情況下，工單系統還需要考慮工單查詢的範圍和内容，一般情況下我們的設計方案是一年之内的工單查詢可以連接配接一年内的資料庫查詢，當查詢超過一年需要連接配接曆史資料庫，進行曆史所有工單資料查詢。
三、工單質檢
當工單成為重要工具之後，對于工單的質檢也會成為營運人員的一個重要工作，工單質檢主要是在業務部門，關注業務部門是否按照要求建立工單、處理工單、關閉工單。
1. 作業流程
我們建議在工單場景建立的時候，盡量和業務溝通好，從業務層面必須規定好工單的标準作業流程（SOP），這裡的标準作業流程需要滿足SMART原則。
包括在什麼場景下可以建立工單，什麼場景下用什麼方式處理工單，以及什麼場景下允許以什麼類型關閉工單。
這裡的流程越标準、越具體，工單質檢的時候就越能減輕人工、系統在質檢場景下的處理和設計壓力。
2. 質檢方案
我們建議之間使用人機協同的機制進行，單個的人工質檢人工成本太高，單個的系統質檢錯誤率太高。
（1）人機協同
Step1：通過系統将必須檢查、并且規則清晰的質檢點進行第一輪次全量檢查，通過80分【這裡質檢績效應該不加不減，也可以設計為100分】，不通過0分【這裡應該需要和績效挂鈎，0分失去質檢績效】；
Step2：根據人工的工作量，随機抽取對應的工單量，對必須由人工質檢的點，進行第二輪次随機抽查，通過100【這裡需要增加績效】，不通過根據質檢情況人工打分；
Step3：設計質檢申訴功能， 當質檢有誤時，支援由被質檢人員直接上級發起申訴，由質檢人員再次複審；
（2）質檢目标
工單質檢有利于促進各部門之間的協同體驗，同時SOP的建立也更能夠提升工單協同的規範程度，進而提升整體的協同效率。
是以在提升效率上，營運、系統需要兩手抓，才能夠達到1+1>2的效果，否則一定是1+1<2，人機協同的關系下，要麼大于2要麼小于2，沒有中間的狀态。
尤其是競争壓力日漸增高的今天，1+1到底等于幾，已經成為一個公司的護城河級别的問題。是以尤其是B端産品經理一定要明白，系統設計一定需要和業務做好緊密的協同溝通，适配業務發展的階段現狀，這樣才有機會設計出來1+1>2的産品。
四、補充和總結
1. 對于【多管道接入】的補充
工單系統的接入方式主要就是3種、全系統嵌入、H5接入、接口對接。
（1）全系統嵌入
主要是面向工單系統的重度使用業務部門；例如客服、維修、商城、倉庫等業務部門，它們從工單建立、工單處理到工單關單都有深度的使用場景，并且也貫穿自己業務的全流程，這種部門幾乎可以使用到工單系統任意一個頁面。對于這種業務部門我們提供的方式就是可以直接基于工單系統進行全系統的嵌入。
（2）H5接入
H5接入主要面向移動端的使用者；例如短信、郵件的通知接收人，可以讓使用者直接在短信、郵件中打開H5頁面直接回複；或者以H5的形式嵌入在移動辦公app中，滿足業務人員移動辦公的要求。
（3）接口對接
接口對接主要面向合作方以及一些對工單系統輕度使用的業務系統，提供接口對接的方式更加有利于保護資料安全，并且根據合作方的要求個性化的定義需要的資料字段、傳輸方式等内容，更加能夠滿足各方的要求。
2. 對于【元件化配置】的補充
工單系統是一個較為小衆的産品，在通用設計層面不會有非常多複雜的處理邏輯。工單系統中沉澱的非常多能夠和業務關聯的處理邏輯，這些邏輯是工單系統邏輯複雜的原因，是以我們希望工單系統的設計和開發需要将工作聚焦在不斷的提升工單處理效率和使用體驗。
現在去看很多企業的OA系統，仍然由開發人員進行維護，每新增一個OA流程都需要開發人員開發表單樣式、開發接口、對接聯調。
這樣的上線流程和很多大家在用的工單系統一樣，有3個非常嚴重的弊端：
- 投入産出比差：把原本可以用來提升業務處理效率的時間和精力都消耗價值産出較低的重複性工作上，完全不符合效率提升的邏輯；
- 業務适配性差：如果換成工單系統，在業務發展迅速，流程調整頻繁的情況下，這樣的效率根本跟不上業務的發展速度，不僅不能幫助業務提升效率，反而會成為制約業務發展的瓶頸；
- 人員成長性差：長時間負責維護和處理這種系統，開發或者産品基本上接觸不到其他新方向的技術開發工作，也就談不上自身工作能力的提升了；
是以我們在設計上把工單分類完全做成元件化的配置項，業務營運人員可以直接組裝出來一個個的新分類，流程變更也可以業務調整後由營運或業務人員直接調整。
大大節省了開發上線的時間，也讓工單設計開發人員有足夠的時間能夠研究和開發與業務關聯性更強的擴充功能，讓系統更加适配業務。
3. 對于【雙流轉流程】的補充
在業務場景中，流程上增加一個處理人，實際工作上就會增加一個處理工序，例如：客服需要回訪使用者、維修師傅需要實際去線下維修、倉庫需要将貨物寄出。
這些處理工序短則1個工作日，長則3-5個工作日，如果一個工單将每個處理流程串聯起來，那麼工單的處理時效就隻能是正比增長：流程越多，時效越長。
這裡我們仍然用第一篇中的投訴案例來簡單分析一下工單流程的設計：
客戶小美找315投訴你們公司的維修員大壯，在修理空調的時候把家裡的空調遙控器按壞了。
315将這個投訴單轉給你們公司，你們需要複盤當時的維修工單，并且要求維修部門給出回複。
你們發現維修工單是兩個月前，記錄客戶追評認為大壯修得很好；
你們拿到了維修部門的回複，大壯解釋當時他發現了遙控器有點接觸不良，但是沒有在意；
最終經過向上級請示，你們給商城及倉庫發了工單，要求給客戶寄出一個新的遙控器。
（1）設計為單個主流程的串聯流程
工單建立–>投訴處理–>維修部門–>投訴處理–>上級審批–>投訴處理–>倉庫發貨->投訴處理–>關單；這樣從建立到關單總共9個流程節點。
在實際的業務場景中，業務人員在處理業務的過程中并不能及時的關注到每一個業務的情況，是以一般一個流程節點的處理時長大約為24小時。
我們即使按照0.5天的工作量來計算，9個節點最起碼也需要4.5個工作日。
同時由于工單再給到倉庫或者維修後，投訴人員失去了處理、關單等權利，導緻及時工單再維修部門超出了回複時間，投訴人員也不能采取最終方案關單，這不僅僅影響了使用者體驗，也大大增加了工單的處理效率。
（2）設計為主流程和子流程的并聯流程
工單建立–>投訴支援–>關單；
如果投訴團隊需要維修、上級、倉庫的協助，可以以任務的形式發送給對方，在不影響投訴處理的情況下共同處理該問題。
這樣流程節點就能夠減少至3個，關單時長起碼能縮短至2個工作日；
同時投訴人員也有更多的自主性，在各方超過處理時間未回複的情況下，投訴人員就可以根據規定自己做出最終的處理決定，并關閉工單。
本例能夠明顯看到“主流程”和“子流程”這套雙流轉邏輯的設計能夠提高任務的并發量，減少串聯的等待時長，提高工單處理的自主性。
進而極大的提升多部門協同的效率，從系統設計的角度建立高效的協同機制。
本文由@zxx 原創釋出于人人都是産品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協定
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。