工单管理系统设计——架构篇2021/7/13 18:57:32

知识力量

　　编辑导读：工单管理系统是为了支撑其它系统而存在的，工单管理所以在设计结构时既要考虑工单本身，又需要考虑其他系统。本文将从工单管理系统的架构方面，对其进行分析，希望对你有帮助。


　　万丈高楼平地起，在盖楼的时候，先起地基。产品设计先定架构，再打磨细节。接上一篇《工单新义》今天我们开始聊工单的架构。

　　一、产品架构

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

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

　　1. 数据

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

　　2. 用户

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

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

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

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

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

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

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

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

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

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

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

　　三、工单框架设计

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

　　工单内容：

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

　　工单状态：

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

　　工单日志：

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

　　工单分配：

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

　　工单类型：

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

　　处理人员设置：

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

　　处理结果：

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

　　分析报表：

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

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

　　四、最后说几句

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

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

　　从上一篇工单新义开始，工单系统系列文章已经开始，基本会保持每周更新一篇的节奏，从工单定义到工单框架在到工单细节的设计都会讲到，产品小伙伴可以关注一下，当然如果有什么问题、想吐槽写的不好的地方、有什么希望在后续文章里面详细介绍的都可以通过留言的方式告诉我。

　　好啰嗦啊，就这样，下周见！

　　本文由 @摸鱼不划水 原创发布于人人都是产品经理，未经许可，禁止转载

　　题图来自 unsplash，基于 CC0 协议

　　给作者打赏，鼓励TA抓紧创作！