工单系统

上一节刚刚讲了内容中台，这节聊聊工单系统。因为正好在“耕种”这两块业务。

任何企业都需要工单，从最简单的“休假申请”，到在淘宝上提交“退货申请”，都可以归纳到工单业务。

简单来说，凡是能够记录事件并被跟进处理的任务，都可以称其为【工单】。

工单参与者是谁？

• 创建人：工单用于记录处理事件，这个事件就会有一个发起人，即为创建人。
• 请求人：上面提到工单的创建人和工单事件本身的请求人员可能是同一个人也可能是不同的人员，对于企业服务来说，有可能内部员工帮助客户去提工单，那么工单的请求人实际是客户，但创建人是内部员工（请求人是真正发起工单，工单的被服务主体）。
• 处理人：工单发起以后，需要有人跟进、处理工单所记录的事件，而这个人则为工单的处理人。
  • 情况1：可能有多个处理人
  • 情况2：可能没有处理人，工单创建后自动关闭。比如，淘宝申请退款退货，如果用户的信誉比较好，系统就自动通过审核且关闭该工单。
• 关注人：关注工单处理结果的人
• 协作人：复杂工单在处理过程中可能处理人无法独立解决问题，需要其他人员来协助支持处理工单。
• 其他参与者

工单参与者.png

工单系统概览

基于几个角色，大致的工单系统如下图：

工单系统.jpg

工单系统最关键的就是流程处理，一个复杂的工单系统，会在处理过程中不断和用户交互，并不是一个单线流程。比如，可能是下面的状态机：

流程处理.png

工单类型也复杂多样，“请假工单”和“退货工单”需要用户提供的信息肯定不同，所以，不同类型工单的表单字段差异性非常大。
如果工单系统做不好，就会导致来一个工单类型，做一套交互，最后有陷入无尽的“增量开发”中。

工单还涉及到各种分配规则，客服人员会根据上班时间（白班，夜班或者休假），技能组归属（主要负责哪一类工单）等条件，自动分配工单。

当然，权限管理也必不可少。处理工单的客服团队可能是内部团队，也可能是外包服务提供商，那么，同一套能力必须提供内部和外部两套系统，在系统层级上先做好数据隔离，然后，根据账号级别做细粒度权限管理。

一个工单系统是不是很复杂呀？下面，不得不说下如何建设工单中台。

工单中台

最核心的是通用层和领域能力层。
业务产品服务只是举例，不限于图中的产品。展示层也可能涉及到更多的前端领域。

工单中台.png

前端能够做什么？

除了一个复杂的工单管理系统，前端还有很多可以做的，主要涉及到低代码领域（用于提效）：

• 因为工单涉及到形式多样的表单，前端可以在动态表单的基础上，加上后端业务对象模型，构建出无穷的工单模板。
• 不同的工单类型可能有不同的处理流程，那么，需要提供动态配置流程节点的能力 - 流程编排。
• 预警监控需要提供图表能力
• 等等

小结

突然想到一句话，不管什么软件架构，核心都是「分层」和「关注点分离」。

soc.png