工單系統(tǒng)——深度解析高效的功能架構(gòu)(下)
基于前文對工單的功能架構(gòu)的重點功能的了解,本文將從【用戶管理】、【工單查詢】、【工單質(zhì)檢】三個功能模塊進行闡述,對工單系統(tǒng)的功能架構(gòu)做一些補充,希望對你有所幫助。
前言
工單的功能架構(gòu)的重點功能前兩篇已經(jīng)闡述完了,本篇我們主要在于查漏補缺,闡述清楚前兩篇沒有講到的【用戶管理】、【工單查詢】、【工單質(zhì)檢】三個功能模塊,給工單系統(tǒng)的功能架構(gòu)結(jié)個尾。
同時我們也將前文遺留下來沒有解釋的【渠道接入】、【配置組件】、【流轉(zhuǎn)流程】三個問題解釋清楚。
一、用戶管理
1. 賬號管理
工單系統(tǒng)的賬號體系要與設(shè)計規(guī)劃相呼應(yīng)。如果只是面對后臺服務(wù)部門的賬號體系,那僅僅與服務(wù)部門的業(yè)務(wù)系統(tǒng)中的賬號體系做好對接,直接復(fù)用業(yè)務(wù)系統(tǒng)的賬號體系就夠用了。
如果在設(shè)計階段就期望能夠通過工單系統(tǒng)貫穿全公司業(yè)務(wù)范圍,那么工單系統(tǒng)的賬號體系最好和公司內(nèi)部內(nèi)網(wǎng)、移動辦公等系統(tǒng)的用戶中心打通,直接和公司級的賬號體對接。
這樣不僅在賬號體系上不需要重新設(shè)計,并且能夠與業(yè)務(wù)系統(tǒng)或用戶中心的用戶賬號同步進行增刪改的操作,后續(xù)對接各系統(tǒng)時也不用考慮賬號、登陸等問題。
2. 權(quán)限管理
在權(quán)限控制上和其他所有B端系統(tǒng)一樣,工單也需要根據(jù)權(quán)限管理的方法對用戶的權(quán)限進行控制。權(quán)限設(shè)計主要有3個原因:
(1)高效分工
權(quán)限設(shè)計并不僅僅只是為了系統(tǒng)的安全和保密,也在一定程度上有利于提升專業(yè)化分工。各部門的業(yè)務(wù)人員能夠?qū)W⒂诟髯缘臉I(yè)務(wù)范疇,從而提升工作效率。
畢竟工單系統(tǒng)又對接合作方、又關(guān)聯(lián)客服、還有商務(wù)、維修各個部門,針對不同的部門需求還有不同的處理邏輯,通過對創(chuàng)建環(huán)節(jié)的工單分類進行控制,可以大大提升業(yè)務(wù)人員對自己負責(zé)業(yè)務(wù)方面的關(guān)注度。
(2)數(shù)據(jù)安全
如果我們設(shè)計的是一個能夠打通全公司上下游協(xié)作的通用工單系統(tǒng),那么系統(tǒng)中存儲的用戶、交易、業(yè)務(wù)問題等信息在成為公司寶貴的過程資產(chǎn)的同時,也會成為外部重點攻擊的對象,系統(tǒng)自身的數(shù)據(jù)安全性也將是非常重要的一個方面。通過權(quán)限管控也能在一定程度上減輕人員問題導(dǎo)致的數(shù)據(jù)泄露。
(3)權(quán)責(zé)分明
清晰的權(quán)限設(shè)計也有利于減少操作風(fēng)險,保證權(quán)責(zé)分明。權(quán)利義務(wù)是相等的,權(quán)限不僅僅是代表你擁有了訪問、查看、操作某些頁面的權(quán)利,同時也代表了你將需要承擔(dān)這些頁面訪問、查看、操作的過程中的風(fēng)險控制責(zé)任,在出現(xiàn)問題時也能更容易通過權(quán)限進行責(zé)任認定。
(4)小結(jié)一下
因此,對于權(quán)限的設(shè)計也是需要考慮的問題。在權(quán)限設(shè)計上,我們建議使用最通用的RBAC模型設(shè)計方法,權(quán)限–>角色–>用戶的方式進行訪問控制,能夠在滿足最小權(quán)限原則的同時比較好的兼容更靈活的權(quán)限配置。同時根據(jù)不同的處理組,我們也可以在處理組上對權(quán)限范圍的限定進行補充。
二、工單查詢
工單系統(tǒng)除了能夠提高各部門之間的協(xié)同效率之外,做到業(yè)務(wù)處理的數(shù)據(jù)留存也非常重要,這些一條條的工單數(shù)據(jù)也是組織業(yè)務(wù)發(fā)展過程中的數(shù)據(jù)資產(chǎn)。并且在工單日常運營和管理過程中,運營人員也需要掌握工單的處理情況,對工單數(shù)據(jù)進行查看并作出簡單分析。因此對于工單明細記錄的查詢也是輔助性的功能之一。
在工單較多的情況下,工單系統(tǒng)還需要考慮工單查詢的范圍和內(nèi)容,一般情況下我們的設(shè)計方案是一年之內(nèi)的工單查詢可以連接一年內(nèi)的數(shù)據(jù)庫查詢,當(dāng)查詢超過一年需要連接歷史數(shù)據(jù)庫,進行歷史所有工單數(shù)據(jù)查詢。
三、工單質(zhì)檢
當(dāng)工單成為重要工具之后,對于工單的質(zhì)檢也會成為運營人員的一個重要工作,工單質(zhì)檢主要是在業(yè)務(wù)部門,關(guān)注業(yè)務(wù)部門是否按照要求創(chuàng)建工單、處理工單、關(guān)閉工單。
1. 作業(yè)流程
我們建議在工單場景創(chuàng)建的時候,盡量和業(yè)務(wù)溝通好,從業(yè)務(wù)層面必須規(guī)定好工單的標(biāo)準(zhǔn)作業(yè)流程(SOP),這里的標(biāo)準(zhǔn)作業(yè)流程需要滿足SMART原則。
包括在什么場景下可以創(chuàng)建工單,什么場景下用什么方式處理工單,以及什么場景下允許以什么類型關(guān)閉工單。
這里的流程越標(biāo)準(zhǔn)、越具體,工單質(zhì)檢的時候就越能減輕人工、系統(tǒng)在質(zhì)檢場景下的處理和設(shè)計壓力。
2. 質(zhì)檢方案
我們建議之間使用人機協(xié)同的機制進行,單個的人工質(zhì)檢人工成本太高,單個的系統(tǒng)質(zhì)檢錯誤率太高。
(1)人機協(xié)同
Step1:通過系統(tǒng)將必須檢查、并且規(guī)則清晰的質(zhì)檢點進行第一輪次全量檢查,通過80分【這里質(zhì)檢績效應(yīng)該不加不減,也可以設(shè)計為100分】,不通過0分【這里應(yīng)該需要和績效掛鉤,0分失去質(zhì)檢績效】;
Step2:根據(jù)人工的工作量,隨機抽取對應(yīng)的工單量,對必須由人工質(zhì)檢的點,進行第二輪次隨機抽查,通過100【這里需要增加績效】,不通過根據(jù)質(zhì)檢情況人工打分;
Step3:設(shè)計質(zhì)檢申訴功能, 當(dāng)質(zhì)檢有誤時,支持由被質(zhì)檢人員直接上級發(fā)起申訴,由質(zhì)檢人員再次復(fù)審;
(2)質(zhì)檢目標(biāo)
工單質(zhì)檢有利于促進各部門之間的協(xié)同體驗,同時SOP的建立也更能夠提升工單協(xié)同的規(guī)范程度,從而提升整體的協(xié)同效率。
因此在提升效率上,運營、系統(tǒng)需要兩手抓,才能夠達到1+1>2的效果,否則一定是1+1<2,人機協(xié)同的關(guān)系下,要么大于2要么小于2,沒有中間的狀態(tài)。
尤其是競爭壓力日漸增高的今天,1+1到底等于幾,已經(jīng)成為一個公司的護城河級別的問題。因此尤其是B端產(chǎn)品經(jīng)理一定要明白,系統(tǒng)設(shè)計一定需要和業(yè)務(wù)做好緊密的協(xié)同溝通,適配業(yè)務(wù)發(fā)展的階段現(xiàn)狀,這樣才有機會設(shè)計出來1+1>2的產(chǎn)品。
四、補充和總結(jié)
1. 對于【多渠道接入】的補充
工單系統(tǒng)的接入方式主要就是3種、全系統(tǒng)嵌入、H5接入、接口對接。
(1)全系統(tǒng)嵌入
主要是面向工單系統(tǒng)的重度使用業(yè)務(wù)部門;例如客服、維修、商城、倉庫等業(yè)務(wù)部門,它們從工單創(chuàng)建、工單處理到工單關(guān)單都有深度的使用場景,并且也貫穿自己業(yè)務(wù)的全流程,這種部門幾乎可以使用到工單系統(tǒng)任意一個頁面。對于這種業(yè)務(wù)部門我們提供的方式就是可以直接基于工單系統(tǒng)進行全系統(tǒng)的嵌入。
(2)H5接入
H5接入主要面向移動端的用戶;例如短信、郵件的通知接收人,可以讓用戶直接在短信、郵件中打開H5頁面直接回復(fù);或者以H5的形式嵌入在移動辦公app中,滿足業(yè)務(wù)人員移動辦公的要求。
(3)接口對接
接口對接主要面向合作方以及一些對工單系統(tǒng)輕度使用的業(yè)務(wù)系統(tǒng),提供接口對接的方式更加有利于保護數(shù)據(jù)安全,并且根據(jù)合作方的要求個性化的定義需要的數(shù)據(jù)字段、傳輸方式等內(nèi)容,更加能夠滿足各方的要求。
2. 對于【組件化配置】的補充
工單系統(tǒng)是一個較為小眾的產(chǎn)品,在通用設(shè)計層面不會有非常多復(fù)雜的處理邏輯。工單系統(tǒng)中沉淀的非常多能夠和業(yè)務(wù)關(guān)聯(lián)的處理邏輯,這些邏輯是工單系統(tǒng)邏輯復(fù)雜的原因,因此我們希望工單系統(tǒng)的設(shè)計和開發(fā)需要將工作聚焦在不斷的提升工單處理效率和使用體驗。
現(xiàn)在去看很多企業(yè)的OA系統(tǒng),仍然由開發(fā)人員進行維護,每新增一個OA流程都需要開發(fā)人員開發(fā)表單樣式、開發(fā)接口、對接聯(lián)調(diào)。
這樣的上線流程和很多大家在用的工單系統(tǒng)一樣,有3個非常嚴(yán)重的弊端:
- 投入產(chǎn)出比差:把原本可以用來提升業(yè)務(wù)處理效率的時間和精力都消耗價值產(chǎn)出較低的重復(fù)性工作上,完全不符合效率提升的邏輯;
- 業(yè)務(wù)適配性差:如果換成工單系統(tǒng),在業(yè)務(wù)發(fā)展迅速,流程調(diào)整頻繁的情況下,這樣的效率根本跟不上業(yè)務(wù)的發(fā)展速度,不僅不能幫助業(yè)務(wù)提升效率,反而會成為制約業(yè)務(wù)發(fā)展的瓶頸;
- 人員成長性差:長時間負責(zé)維護和處理這種系統(tǒng),開發(fā)或者產(chǎn)品基本上接觸不到其他新方向的技術(shù)開發(fā)工作,也就談不上自身工作能力的提升了;
因此我們在設(shè)計上把工單分類完全做成組件化的配置項,業(yè)務(wù)運營人員可以直接組裝出來一個個的新分類,流程變更也可以業(yè)務(wù)調(diào)整后由運營或業(yè)務(wù)人員直接調(diào)整。
大大節(jié)省了開發(fā)上線的時間,也讓工單設(shè)計開發(fā)人員有足夠的時間能夠研究和開發(fā)與業(yè)務(wù)關(guān)聯(lián)性更強的擴展功能,讓系統(tǒng)更加適配業(yè)務(wù)。
3. 對于【雙流轉(zhuǎn)流程】的補充
在業(yè)務(wù)場景中,流程上增加一個處理人,實際工作上就會增加一個處理工序,例如:客服需要回訪用戶、維修師傅需要實際去線下維修、倉庫需要將貨物寄出。
這些處理工序短則1個工作日,長則3-5個工作日,如果一個工單將每個處理流程串聯(lián)起來,那么工單的處理時效就只能是正比增長:流程越多,時效越長。
這里我們?nèi)匀挥玫谝黄械耐对V案例來簡單分析一下工單流程的設(shè)計:
客戶小美找315投訴你們公司的維修員大壯,在修理空調(diào)的時候把家里的空調(diào)遙控器按壞了。
315將這個投訴單轉(zhuǎn)給你們公司,你們需要復(fù)盤當(dāng)時的維修工單,并且要求維修部門給出回復(fù)。
你們發(fā)現(xiàn)維修工單是兩個月前,記錄客戶追評認為大壯修得很好;
你們拿到了維修部門的回復(fù),大壯解釋當(dāng)時他發(fā)現(xiàn)了遙控器有點接觸不良,但是沒有在意;
最終經(jīng)過向上級請示,你們給商城及倉庫發(fā)了工單,要求給客戶寄出一個新的遙控器。
(1)設(shè)計為單個主流程的串聯(lián)流程
工單創(chuàng)建–>投訴處理–>維修部門–>投訴處理–>上級審批–>投訴處理–>倉庫發(fā)貨->投訴處理–>關(guān)單;這樣從創(chuàng)建到關(guān)單總共9個流程節(jié)點。
在實際的業(yè)務(wù)場景中,業(yè)務(wù)人員在處理業(yè)務(wù)的過程中并不能及時的關(guān)注到每一個業(yè)務(wù)的情況,因此一般一個流程節(jié)點的處理時長大約為24小時。
我們即使按照0.5天的工作量來計算,9個節(jié)點最起碼也需要4.5個工作日。
同時由于工單再給到倉庫或者維修后,投訴人員失去了處理、關(guān)單等權(quán)利,導(dǎo)致及時工單再維修部門超出了回復(fù)時間,投訴人員也不能采取最終方案關(guān)單,這不僅僅影響了用戶體驗,也大大增加了工單的處理效率。
(2)設(shè)計為主流程和子流程的并聯(lián)流程
工單創(chuàng)建–>投訴支持–>關(guān)單;
如果投訴團隊需要維修、上級、倉庫的協(xié)助,可以以任務(wù)的形式發(fā)送給對方,在不影響投訴處理的情況下共同處理該問題。
這樣流程節(jié)點就能夠減少至3個,關(guān)單時長起碼能縮短至2個工作日;
同時投訴人員也有更多的自主性,在各方超過處理時間未回復(fù)的情況下,投訴人員就可以根據(jù)規(guī)定自己做出最終的處理決定,并關(guān)閉工單。
本例能夠明顯看到“主流程”和“子流程”這套雙流轉(zhuǎn)邏輯的設(shè)計能夠提高任務(wù)的并發(fā)量,減少串聯(lián)的等待時長,提高工單處理的自主性。
從而極大的提升多部門協(xié)同的效率,從系統(tǒng)設(shè)計的角度建立高效的協(xié)同機制。
本文由@zxx 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議
該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。
想問一下,這個么一個工單系統(tǒng),4個后端,一個前端。這種配置要多久能做完?
作者你好,你文章所講的工單系統(tǒng)架構(gòu)下的原型可以學(xué)習(xí)下嗎
想請教一下,子流程中存在多人任務(wù),這個功能是嵌入進了工單表單中嘛?如果是嵌入了,那么任務(wù)協(xié)助人也能看到當(dāng)前這個工單并且僅能操作是否完成任務(wù),但沒有工單操作權(quán)限包括關(guān)單、分派等
是的,任務(wù)操作人能看到工單,但是他只有處理分給他的這個任務(wù)的權(quán)限,只有工單的處理人有工單的處理權(quán)限
問的稍微技術(shù)一些,待處理的任務(wù)與工單其實是兩個對象,任務(wù)只是掛在工單下,但是并不影響工單的正常閉環(huán)嗎?會出現(xiàn)工單關(guān)閉了,但是工單下的任務(wù)其實未完成的情況?
可以說是很詳細了
五篇看完了,再次感謝大佬的分享
幾篇下來,太硬核了