工單系統之重新定義工單系統

相信每一個PM都知道“工單”，同時每個PM對於工單都有自己的理解。

工單系統分為兩大類：一是企業內部部門工作任務傳達的系統；二是專門用於售後安裝維修類的系統，這種是把工單派給外勤人員上門去維護的軟件。

在這裏我們嘗試重新定義工單系統，明確工單使用場景和參與者，為後面我們設計工單系統做準備。

一、重新定義工單

工單的一詞出現比較早，主要用於售後。

隨着電商的發展，工單順勢搭上了電商的順風車，成了一隻上天的“豬”；每個電商公司都在構建自己的工單系統，當然非電商公司也在提工單。

百度定義工單以後，我們拿着“工單”的概念就開始用了，那有沒有想過百度對於工單的定義能不能符合我們自己企業對於工單系統的定義嗎？或者説我們企業對於工單系統的定義到底是什麼？下面我們嘗試重新定義工單。

我們再來看一下百度對工單系統的定義，先看定義的前半段：用於記錄、處理、跟蹤一項工作的完成情況；那是不是隻要滿足這個定義的我們都可以將其稱之為“工單系統”，比如流程、比如郵件。

再來看後半段：專門用於售後安裝維修類的系統，這個在現在已經不適用了，我們可以將其忽略；基於此，我們可以説：每個企業都有自己的“工單系統”，可能是一條流程、可能是郵件系統等等。

工單系統更像是一種統稱，凡是能夠能夠記錄事件並被跟進處理的系統，都可以稱其為工單系統——這裏的工單系統是一種廣義的工單系統定義。

在實際中，我們會將一些類“工單”系統賦予其他的名稱，比如流程、比如郵件管理等等，狹義的工單系統定義只能根據我們的實際情況來定。

二、工單使用場景

基於前面對於工單系統的定義，我們再來看工單系統的使用場景，準確來説是工單的使用場景，工單是用於記錄事件、跟進處理事件的；那麼工單的使用場景則是：任何場景，在企業日常工作中、在我們的日常生活中，工單都可以被使用，當然工單更多是被用於企業日常工作。

在企業日常工作中，基於組織架構，我們將參與者分成內部員工和外部客户，內部員工的溝通、內部員工和外部客户的溝通都可以使用“工單”來記錄和處理事件。

在個人日常工作中，我們也可以利用工單來記錄事件、安排日程等等；當然我們可能並不把這其稱為工單，但其本質還是工單。

三、工單參與者

瞭解了工單的定義和使用場景，我們來看一下工單有那些參與者。

工單的參與者我們需要用角色去定義，下面我們看看到底有那些角色參與到工單中：

創建人：工單用於記錄處理事件，這個事件就會有一個發起人，對於單個工單來説，工單的創建也會有一個創建人；在實際使用的過程中，工單的創建人和工單事件本身的觸發人員可能是同一個人也可能是不同的人員——這裏的創建人指創建工單的人員。

處理人：工單發起以後，需要有人跟進、處理工單所記錄的事件；而這個人則為工單的處理人，有些情況下，處理人可能是多個，多個處理人的關係有以下情況：一起處理、先後處理、多個人員中某一個人員處理即可，當然也有可能沒有處理人，如工單創建以後自動關閉。

通知人：工單處理到一定階段或者完結以後，需要告知的人員，有可能是創建人，有可能是其他人員。

督辦人：為了保證工單的處理效率，或者説工單完成率，需要有一個督辦人去跟進（當然這個角色可有可無）。

管理員：針對於單個工單來説，一般沒有管理員的角色，但是針對於工單系統來説就需要有管理人員，負責維護整個工單管理系統。

其他參與者：其他參與者會比較多，如事件的觸發者、可以查看工單但不處理工單的人員等等。

在設計工單系統的時候，需要根據業務需求和使用場景來確定工單參與者，可能工單創建人是系統、處理人也有可能是系統、可能督辦人員不需要等等。

四、結束語

做系統之前，定義系統是必不可少的事情，工單系統之重新認識工單是我對於工單的定義及認識。

從工單的使用場景等來看，百度上對於工單的定義已經過時，需要我們重新結合自己的訴求重新定義。

我們都知道工單，我們也要知道什麼是工單：能夠記錄事件並被跟進處理的系統，都可以稱其為工單系統，同時我們要知道工單是誰在什麼時候用；瞭解這些，再結合實際定義適合我們公司的工單系統並設計出能給業務帶來價值的工單系統。

針對工單，我會先從工單定義開始整理到工單的設計整理系列文章，歡迎大家持續關注。

本文由 @墨語 原創發佈於人人都是產品經理，未經許可，禁止轉載

題圖來自 unsplash，基於 CC0 協議