編輯導(dǎo)讀：工單管理系統(tǒng)是為了支撐其它系統(tǒng)而存在的，所以在設(shè)計結(jié)構(gòu)時既要考慮工單本身，又需要考慮其他系統(tǒng)。本文將從工單管理系統(tǒng)的架構(gòu)方面，對其進行分析，希望對你有幫助。

萬丈高樓平地起，在蓋樓的時候，先起地基。產(chǎn)品設(shè)計先定架構(gòu)，再打磨細節(jié)。接上一篇《工單新義》今天我們開始聊工單的架構(gòu)。

一、產(chǎn)品架構(gòu)

架構(gòu)，高大上吧，逼格高吧，我們經(jīng)常會聽到一個：架構(gòu)師的崗位，那架構(gòu)到底是啥？其實我也不是很了解，這里我就簡單談一下我對產(chǎn)品架構(gòu)的理解：產(chǎn)品架構(gòu)是基于業(yè)務(wù)、深入了解用戶需求之后，從0-1開始設(shè)計完整的產(chǎn)品方案。

好的產(chǎn)品架構(gòu)能夠完整支撐現(xiàn)有業(yè)務(wù)訴求、用戶需求和管理訴求，同時在業(yè)務(wù)、用戶、管理訴求發(fā)生變更的時候，能以最小的實現(xiàn)價值實現(xiàn)對這些變更的支持（有點中臺的味道吧）。產(chǎn)品架構(gòu)的設(shè)計離不開數(shù)據(jù)和用戶。

1. 數(shù)據(jù)

設(shè)計產(chǎn)品架構(gòu)其實是在設(shè)計業(yè)務(wù)線上化，業(yè)務(wù)線上化的展現(xiàn)形式就是流程，再深入一點：流程是數(shù)據(jù)+順序+權(quán)限構(gòu)成，我們在設(shè)計產(chǎn)品架構(gòu)的時候，其實本質(zhì)是在設(shè)計數(shù)據(jù)的來源、去處，明確數(shù)據(jù)從哪里來到哪里去。

2. 用戶

這里的用戶是角色的概念，一個產(chǎn)品的用戶不是單一的角色，產(chǎn)品需要支撐多角色共同的訴求，而產(chǎn)品架構(gòu)應(yīng)該是最了解用戶的，也是可以滿足所有的用戶訴求的。

再總結(jié)一下：梳理產(chǎn)品架構(gòu)其實是業(yè)務(wù)線上化的過程，其實也就是梳理數(shù)據(jù)和用戶操作訴求。

二、設(shè)計框架前需要明確兩點

《工單新義》中已經(jīng)明確的解釋了工單系統(tǒng)是什么，做一個簡單的概括：工單其實是一個支撐系統(tǒng)，為了支撐其他業(yè)務(wù)而存在，所以在設(shè)計工單的框架的時候，既要考慮工單本身，也要考慮其他的系統(tǒng)，在設(shè)計工單之前，我們先要考慮兩點：

1.?工單系統(tǒng)設(shè)計需要考慮全公司

談到工單，我們會聯(lián)想到：客服。總覺得吧，客服人員是工單的使用人員，然后基于客服的訴求開始設(shè)計工單，常常會忽略其他部門。

這樣設(shè)計出來的工單不僅會給客服造成影響，也會給其他部門帶來不便，常見的場景就是：客服線下登記表格，發(fā)給其他業(yè)務(wù)部門，其他部門處理結(jié)果客服不知道，反復(fù)詢問。因外部業(yè)務(wù)產(chǎn)生的工單（系統(tǒng)自動生成），客服經(jīng)常會作為第一接收人，有很多情況下，客服人員是無權(quán)處理的，是需要其他業(yè)務(wù)部門支持的，工單系統(tǒng)設(shè)計，要考慮全公司。

2. 工單系統(tǒng)設(shè)計需要考慮其他系統(tǒng)

工單中有很大一部分數(shù)據(jù)是來源其他系統(tǒng)的，或者說是其他系統(tǒng)的某個動作導(dǎo)致了工單的產(chǎn)生，當然這一部分不用過多考慮，原因是：其他系統(tǒng)的動作產(chǎn)生工單，對于工單系統(tǒng)來說，就是接受了你的數(shù)據(jù)而已。

需要考慮工單處理完結(jié)或者產(chǎn)生某個結(jié)果時，對其他系統(tǒng)的影響，比如：一個訂單的退款申請導(dǎo)致了工單的產(chǎn)生，經(jīng)過客服人員的處理，同意了訂單的退款，那么就需要讓訂單的狀態(tài)變?yōu)椋阂淹丝睿顟B(tài)根據(jù)自己公司的業(yè)務(wù)確定即可），其實這個就是工單需要考慮全功的線上呈現(xiàn)。

至于什么新建、分配、了解業(yè)務(wù)、工單狀態(tài)這些是必須的，就不在這里贅述了，后續(xù)文章會對這些展開詳細講解。

三、工單框架設(shè)計

框架圖的樣式是像上圖呢還是思維導(dǎo)圖，客官們自己判斷吧，這里就不畫工單的框架圖了畢竟沒有一個業(yè)務(wù)場景（主要是懶），主要就以框架里面需要考慮的內(nèi)容展開吧。見下圖：

工單內(nèi)容：

工單頁面中主要記錄工單信息，和工單關(guān)聯(lián)信息，比如一個工單就需要有發(fā)起人、類型、內(nèi)容、狀態(tài)等信息，同時提供處理工單相關(guān)聯(lián)的信息，如訂單。

工單狀態(tài)：

工單在創(chuàng)建好以后，是需要流轉(zhuǎn)的，是需要用狀態(tài)來標識的。

工單日志：

工單從創(chuàng)建到最終的完結(jié)有一個過程，工單日志主要記錄這個過程以及這個過程中不同人員對工單的操作。工單日志可以分成：系統(tǒng)日志、操作記錄等。

工單分配：

工單創(chuàng)建好以后，會有不同的人員對工單進行處理，就需要提供工單分配功能，需要支持系統(tǒng)分配和人工分配。

工單類型：

工單內(nèi)容記錄的是不同業(yè)務(wù)場景下的問題，在工單系統(tǒng)中以工單類型來區(qū)分，不同的工單類型有不同的使用場景，會產(chǎn)生不同的處理結(jié)果。

處理人員設(shè)置：

工單的處理人員基本會基于類型進行設(shè)置，即不同的工單類型第一處理人不同，通過處理人員設(shè)置，系統(tǒng)就可以將工單自動進行分配，同時也可以基于處理人員的設(shè)置來進行工單權(quán)限的判斷，有A類工單處理權(quán)限的人員可以在系統(tǒng)中看到A類工單，可以等待系統(tǒng)分配，也可以自動去接工單處理。

處理結(jié)果：

工單處理有了結(jié)果以后，就需要客服人員進行記錄，記錄好以后，觸發(fā)其他系統(tǒng)的單據(jù)或者操作。

分析報表：

通過對工單問題的分析，可以反推業(yè)務(wù)的優(yōu)化，通過對工單處理時長的分析，可以對工單SOP進行優(yōu)化，而這些都離不開工單報表。

工單系統(tǒng)的框架離不開以上內(nèi)容，業(yè)務(wù)的調(diào)研、需求的梳理最終也是對以上內(nèi)容的不斷優(yōu)化，在設(shè)計工單系統(tǒng)的時候，就圍繞以上八點進行展開、細化，結(jié)合我們的實際業(yè)務(wù)訴求，設(shè)計出一款好用的工單系統(tǒng)（所有的工單系統(tǒng)都是圍繞以上八點進行設(shè)計，好用的只是更加符合業(yè)務(wù)訴求和操作訴求罷了）。

四、最后說幾句

工單系統(tǒng)本身并不復(fù)雜，做一款工單系統(tǒng)、一款通用的工單系統(tǒng)很難，畢竟每一個公司的業(yè)務(wù)場景、系統(tǒng)功能不一致，所以很難將工單系統(tǒng)saas化，如果不考慮其他系統(tǒng)對接層面，那么可以考慮將其saas話，然后通過集成的方式處理（不過，工單系統(tǒng)本身復(fù)雜度不高，集成的成本可能遠遠大于開發(fā)工單系統(tǒng)的成本，客官們自己考慮即可）。

工單框架本身不復(fù)雜，復(fù)雜的是細節(jié)的設(shè)計、工單使用者的習慣、以及工單處理的培訓(xùn)成本，作為產(chǎn)品，我們要考慮前兩個，后面這一塊只能說盡可能的去支持，畢竟工單的處理是業(yè)務(wù)層面上的事情，我們能做的就是把系統(tǒng)做好，讓使用者更方便的去處理系統(tǒng)層面無法處理的工單。

從上一篇工單新義開始，工單系統(tǒng)系列文章已經(jīng)開始，基本會保持每周更新一篇的節(jié)奏，從工單定義到工單框架在到工單細節(jié)的設(shè)計都會講到，產(chǎn)品小伙伴可以關(guān)注一下，當然如果有什么問題、想吐槽寫的不好的地方、有什么希望在后續(xù)文章里面詳細介紹的都可以通過留言的方式告訴我。

好啰嗦啊，就這樣，下周見！

本文由 @摸魚不劃水 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 unsplash，基于 CC0 協(xié)議