企业应需要怎样的工单管理系统

                                   工单管理系统

一、产品架构

架构，高大上吧，逼格高吧，我们经常会听到一个：架构师的岗位，那架构到底是啥？其实我也不是很了解，这里我就简单谈一下我对产品架构的理解：产品架构是基于业务、深入了解用户需求之后，从0-1开始设计完整的产品方案。

好的产品架构能够完整支撑现有业务诉求、用户需求和管理诉求，同时在业务、用户、管理诉求发生变更的时候，能以最小的实现价值实现对这些变更的支持（有点中台的味道吧）。产品架构的设计离不开数据和用户。

1. 数据

设计产品架构其实是在设计业务线上化，业务线上化的展现形式就是流程，再深入一点：流程是数据+顺序+权限构成，我们在设计产品架构的时候，其实本质是在设计数据的来源、去处，明确数据从哪里来到哪里去。

2. 用户

这里的用户是角色的概念，一个产品的用户不是单一的角色，产品需要支撑多角色共同的诉求，而产品架构应该是最了解用户的，也是可以满足所有的用户诉求的。

再总结一下：梳理产品架构其实是业务线上化的过程，其实也就是梳理数据和用户操作诉求。

二、设计框架前需要明确两点

《工单新义》中已经明确的解释了工单系统是什么，做一个简单的概括：工单其实是一个支撑系统，为了支撑其他业务而存在，所以在设计工单的框架的时候，既要考虑工单本身，也要考虑其他的系统，在设计工单之前，我们先要考虑两点：

1. 工单系统设计需要考虑全公司

谈到工单，我们会联想到：客服。总觉得吧，客服人员是工单的使用人员，然后基于客服的诉求开始设计工单，常常会忽略其他部门。

这样设计出来的工单不仅会给客服造成影响，也会给其他部门带来不便，常见的场景就是：客服线下登记表格，发给其他业务部门，其他部门处理结果客服不知道，反复询问。因外部业务产生的工单（系统自动生成），客服经常会作为第一接收人，有很多情况下，客服人员是无权处理的，是需要其他业务部门支持的，工单系统设计，要考虑全公司。

2. 工单系统设计需要考虑其他系统

工单中有很大一部分数据是来源其他系统的，或者说是其他系统的某个动作导致了工单的产生，当然这一部分不用过多考虑，原因是：其他系统的动作产生工单，对于工单系统来说，就是接受了你的数据而已。

需要考虑工单处理完结或者产生某个结果时，对其他系统的影响，比如：一个订单的退款申请导致了工单的产生，经过客服人员的处理，同意了订单的退款，那么就需要让订单的状态变为：已退款（状态根据自己公司的业务确定即可），其实这个就是工单需要考虑全功的线上呈现。

至于什么新建、分配、了解业务、工单状态这些是必须的，就不在这里赘述了，后续文章会对这些展开详细讲解。

三、工单框架设计

框架图的样式是像上图呢还是思维导图，客官们自己判断吧，这里就不画工单的框架图了毕竟没有一个业务场景（主要是懒），主要就以框架里面需要考虑的内容展开吧。见下图

工单内容：

工单页面中主要记录工单信息，和工单关联信息，比如一个工单就需要有发起人、类型、内容、状态等信息，同时提供处理工单相关联的信息，如订单。

工单状态：

工单在创建好以后，是需要流转的，是需要用状态来标识的。

工单日志：

工单从创建到最终的完结有一个过程，工单日志主要记录这个过程以及这个过程中不同人员对工单的操作。工单日志可以分成：系统日志、操作记录等。

工单分配：

工单创建好以后，会有不同的人员对工单进行处理，就需要提供工单分配功能，需要支持系统分配和人工分配。

工单类型：

工单内容记录的是不同业务场景下的问题，在工单系统中以工单类型来区分，不同的工单类型有不同的使用场景，会产生不同的处理结果。

处理人员设置：

工单的处理人员基本会基于类型进行设置，即不同的工单类型第一处理人不同，通过处理人员设置，系统就可以将工单自动进行分配，同时也可以基于处理人员的设置来进行工单权限的判断，有A类工单处理权限的人员可以在系统中看到A类工单，可以等待系统分配，也可以自动去接工单处理。

处理结果：

工单处理有了结果以后，就需要客服人员进行记录，记录好以后，触发其他系统的单据或者操作。

分析报表：

通过对工单问题的分析，可以反推业务的优化，通过对工单处理时长的分析，可以对工单SOP进行优化，而这些都离不开工单报表。

工单系统的框架离不开以上内容，业务的调研、需求的梳理最终也是对以上内容的不断优化，在设计工单系统的时候，就围绕以上八点进行展开、细化，结合我们的实际业务诉求，设计出一款好用的工单系统（所有的工单系统都是围绕以上八点进行设计，好用的只是更加符合业务诉求和操作诉求罢了）。

四、最后说几句

工单系统本身并不复杂，做一款工单系统、一款通用的工单系统很难，毕竟每一个公司的业务场景、系统功能不一致，所以很难将工单系统saas化，如果不考虑其他系统对接层面，那么可以考虑将其saas话，然后通过集成的方式处理（不过，工单系统本身复杂度不高，集成的成本可能远远大于开发工单系统的成本，客官们自己考虑即可）。

工单框架本身不复杂，复杂的是细节的设计、工单使用者的习惯、以及工单处理的培训成本，作为产品，我们要考虑前两个，后面这一块只能说尽可能的去支持，毕竟工单的处理是业务层面上的事情，我们能做的就是把系统做好，让使用者更方便的去处理系统层面无法处理的工单。