編輯導讀：工單管理系統是為了支撐其它系統而存在的，所以在設計結構時既要考慮工單本身，又需要考慮其他系統。本文將從工單管理系統的架構方面，對其進行分析，希望對你有幫助。

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

一、產品架構

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

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

1. 數據

設計產品架構其實是在設計業(yè)務線上化，業(yè)務線上化的展現形式就是流程，再深入一點：流程是數據+順序+權限構成，我們在設計產品架構的時候，其實本質是在設計數據的來源、去處，明確數據從哪里來到哪里去。

2. 用戶

這里的用戶是角色的概念，一個產品的用戶不是單一的角色，產品需要支撐多角色共同的訴求，而產品架構應該是最了解用戶的，也是可以滿足所有的用戶訴求的。

再總結一下：梳理產品架構其實是業(yè)務線上化的過程，其實也就是梳理數據和用戶操作訴求。

二、設計框架前需要明確兩點

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

1.?工單系統設計需要考慮全公司

談到工單，我們會聯想到：客服?？傆X得吧，客服人員是工單的使用人員，然后基于客服的訴求開始設計工單，常常會忽略其他部門。

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

2. 工單系統設計需要考慮其他系統

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

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

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

三、工單框架設計

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

工單內容：

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

工單狀態(tài)：

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

工單日志：

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

工單分配：

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

工單類型：

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

處理人員設置：

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

處理結果：

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

分析報表：

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

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

四、最后說幾句

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

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

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

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

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

題圖來自 unsplash，基于 CC0 協議