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

2023-02-16 17:01:33 嗨创软服

                                   工单管理系统

一、产品架构


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


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


1. 数据

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


2. 用户

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

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


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


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


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

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


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


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

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

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

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

三、工单框架设计


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

嗨创软服


工单内容:

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


工单状态:

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


工单日志:

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


工单分配:

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


工单类型:

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


处理人员设置:

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


处理结果:

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


分析报表:

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


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


四、最后说几句


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

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