编辑导读：工单打点系统是为了支撑其它系统而存在的，所以在设计布局时既要思量工单自己，又需要思量其他系统。本文将从工单打点系统的架构方面，对其举办阐明，但愿对你有辅佐。

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

一、产物架构

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

好的产物架构可以或许完整支撑现有业务诉求、用户需求和打点诉求，同时在业务、用户、打点诉求产生改观的时候，能以最小的实现代价实现对这些改观的支持（有点中台的味道吧）。产物架构的设计离不开数据和用户。

1. 数据

设计产物架构其实是在设计业务线上化，业务线上化的揭示形式就是流程，再深入一点：流程是数据+顺序+权限组成，我们在设计产物架构的时候，其实本质是在设计数据的来历、去处，明晰数据从那边来到那边去。

2. 用户

这里的用户是脚色的观念，一个产物的用户不是单一的脚色，产物需要支撑多脚色配合的诉求，而产物架构应该是最相识用户的，也是可以满意所有的用户诉求的。

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

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

《工单新义》中已经明晰的表明白工单系统是什么，做一个简朴的归纳综合：工单其实是一个支撑系统，为了支撑其他业务而存在，所以在设计工单的框架的时候，既要思量工单自己，也要思量其他的系统，在设计工单之前，我们先要思量两点：

1. 工单系统设计需要思量全公司

谈到工单，我们会遐想到： *** 。总以为吧， *** 人员是工单的利用人员，然后基于 *** 的诉求开始设计工单，经常会忽略其他部分。

这样设计出来的工单不只会给 *** 造成影响，也会给其他部分带来未便，常见的场景就是： *** 线下挂号表格，发给其他业务部分，其他部分处理惩罚功效 *** 不知道，重复询问。因外部业务发生的工单（系统自动生成）， *** 常常会作为之一吸收人，有许多环境下， *** 人员是无权处理惩罚的，是需要其他业务部分支持的，工单系统设计，要思量全公司。

2. 工单系统设计需要思量其他系统

工单中有很大一部门数据是来历其他系统的，可能说是其他系统的某个行动导致了工单的发生，虽然这一部门不消过多思量，原因是：其他系统的行动发生工单，对付工单系统来说，就是接管了你的数据罢了。

需要思量工单处理惩罚完结可能发生某个功效时，对其他系统的影响，好比：一个订单的退款申请导致了工单的发生，颠末 *** 人员的处理惩罚，同意了订单的退款，那么就需要让订单的状态变为：已退款（状态按照本身公司的业务确定即可），其实这个就是工单需要思量全功的线上泛起。

至于什么新建、分派、相识业务、工单状态这些是必需的，就不在这里赘述了，后续文章会对这些展开具体讲授。

三、工单框架设计

框架图的样式是像上图呢照旧思维导图，客长们本身判定吧，这里就不画工单的框架图了究竟没有一个业务场景（主要是懒），主要就以框架内里需要思量的内容展开吧。见下图：

工单内容：

工单页面中主要记录工单信息，和工单关联信息，好比一个工单就需要有提倡人、范例、内容、状态等信息，同时提供处理惩罚工单相关联的信息，如订单。

工单状态：

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

工单日志：

工单从建设到最终的完结有一个进程，工单日志主要记录这个进程以及这个进程中差异人员对工单的操纵。工单日志可以分成：系统日志、操纵记录等。

工单分派：

工单建设好今后，会有差异的人员对工单举办处理惩罚，就需要提供工单分派成果，需要支持系统分派和人工分派。

工单范例：

工单内容记录的是差异业务场景下的问题，在工单系统中以工单范例来区分，差异的工单范例有差异的利用场景，会发生差异的处理惩罚功效。

处理惩罚人员配置：