文章对工单系统是什么、工作原理和工作流程一一进行了梳理分析，希望通过此文能够加深你对工单系统的认识。

一、准备工作

1. 了解什么是工单系统
2. 整理工单系统的原理
3. 梳理业务流程

1. 了解什么是工单系统

不多说了，看下图：

• 工单系统Ticket system又称为工单管理系统（还可以称为问题工单系统，事务工单系统，事务追踪系统issue tracking system，支持工单系统support ticket system)）,它是一种网络软件系统，根据不同组织，部门和外部客户的需求，来有针对的管理，维护和追踪一系列的问题和请求。一个完善功能的工单系统又可以称为帮助台系统。
• 提供系统化、标准化的工作处理流程。用于企业间和企业内部的工作协作，具有批量性、时效性、绩效性的特点。常见于客户服务管理，比如银行系统的客服工作、游戏行业的客服工作。

不过百度里面也提到了两种“工单系统”

1. BPM（业务流程管理）：https://baike.baidu.com/item/BPM/1933?fr=aladdin
2. BPMN（业务流程建模符号）：https://baike.baidu.com/item/BPMN/9818373?fr=aladdin

我们这次主要是介绍BPM，业务流程管理系统的搭建。

2. 整理工单系统的原理

再引用百度的一句话：

一个工单系统就像一个问题追踪器，能很清晰的追踪，处理和归档内外的问题事务请求，标准化服务追踪用户。

直译过来的意思就是：工单系统，涵盖了问题的发现、追踪、处理、归档。

因此，工单系统的作用就可以大致分为以下三个点：

1. 发现问题
2. 追踪问题
3. 处理问题并归档

二、工单系统的定位

经过上面的一系列前期准备，我们已经得知了工单系统的3个点，而这3个点，其实可以用我们叙事文的写法来概括：起因、经过、结果。

1. 发现问题（起因）
2. 追踪问题（经过）
3. 处理问题并归档（结果）

根据这个分类，下面我们来具体聊聊工单系统应该怎么玩。

1. 发现问题（起因）

问题，是需求的根源，那什么是问题？

在工作中，问题常常意味着新的业务需求，即业务中遇到的冲突点、亟需解决的问题点、困难点等等。

举个简单的关于“冲突点”的场景：

销售小王，发现他的线索客户被系统分配到了小明名下。身为一名销售，每天都要努力努力努力，业绩也要加油加油加油，绩效才能第一第一第一。

而一个潜在的客户被莫名分走，这不是抢绩效吗？断人财路如杀人父母，这可是杀父之仇！必须把客户拿回来！但是不能直接去找小明撕逼呀，不用想都知道他肯定会耍赖，所以必须有人能够站出来撑腰，提供支持！

此时小王发起了“数据冲突申请”工单流程，并提供了一些证据证明线索的所有权，再经过一系列审批，将客户拿了回来。

数据冲突申请，其实处理的就是内部业务上常见的“冲突点”，而冲突点通常都是由内部员工发起的

再来一个“亟需解决的问题点”的场景：

客户买了商品，然后发现并不是他想要的，于是申请退款，并在24小时内收到了退款金。

客户申请退款，就是一个非常常见的，着急的，需及时处理的“问题点”。

2. 追踪问题（经过）

这两个场景，其实都符合我们之前提到的叙事文写法，即都有起因–>经过–>结果。

而这三点，工单系统称之为发起申请（起因）–>审批（经过）–>执行（结果）

我们来分析一下为什么数据冲突和申请退款都符合这个流程：

场景分析一：

销售小王发现数冲问题，并提出申请（发起申请）–>由数据冲突团队确认问题并审核（审批）–>数据冲突团队解决数冲问题（执行）

场景分析二：

客户发现商品有问题，并提出退款申请（发起申请）–>由销售、库管、财务等确认商品问题，确认是否需要退款，并逐步审批（审批）–>执行退款、库存数据等修改（执行）

根据上面两个场景分析，我们可以得出一个初步结论：工单系统好像只需要参与审批流程（经过）即可。（后面会举例证明）

3.处理问题并归档（结果）

我们工单系统需要做的事情就是把工单的归档并将结果传给业务系统，告诉他们审批通过 or 审批不通过。至于后续业务系统是否做后续处理，与工单系统无关。具体原因，我会在下面通过实例来解释。

三、梳理业务流程

经过上面的描述，我们已经初步了解了工单系统的职能“好像”是审批流程（经过）。

那我们来通过实际场景，即梳理业务流程，来证明我们的猜想是否正确。

就拿我们上面提到的退款流程来举例：

这是一个抽象到底层的退款流程，基本上每个行业都是这么操作退款的。只不过对于具体的行业，可能会有相应的额外功能，比如说：电商类行业来说，还需要清点库存；对教育类行业来说，需要计算课消等等，就不展开描述了。

根据退款流程，我们引用上面提到的“发现”进行归纳：

• 发起申请（起因）：用户发起退款
• 审批流程（经过）：业务人员–>财务–>出纳，依次审批
• 执行（结果）：出纳打款，数据归档

有没有发现，经过简单的梳理，很轻易就知道我们工单系统应该负责哪一块内容了？没错，就是中间的审批流程（经过）。经过梳理，我们可以抽象出下面这张图：

再根据这张图，我们可以得出一个结论：工单系统确实只需处理审批流程（经过）。

至于为什么发起申请（起因）与执行（结果）的操作都是在业务系统处理的，解释起来也很简单：

如果没有工单系统，这些发起&执行的工作由哪个业务系统来完成。那么有了工单系统，这些发起&执行的工作依旧是由对应的业务系统来完成。即工单系统是规范业务“因与果”的一个桥梁or渠道，他本身不参与业务发起&执行。

PS：这里一定要认清工单系统的定位，不然会走很多弯路的喔~

也许有朋友要问了，根据这个结论，我们展开理解，是不是在业务系统里面做几个具备审核流程，就可以称为工单系统了呢？

显然也是不对的。工单系统，是平行于其他所有系统的一个系统，是跨系统执行工单的“桥梁”，并不局限于某个业务系统内部。而且，既然称之为系统，那总归是有一套其他系统没有的规范&服务在里面的，如：

• 字段规范
• 流程规范
• 接口规范
• 工作台
• …

当然，除了以上提到的规范&服务，我们还会把相关的增值“小功能”一应俱全的带上：

• 消息通知：站内信、用户端推送等
• 关键数据：展示当前节点处理人最希望看到的数据
• 移动办公：H5形式，接入钉钉、微信服务号、企业微信等
• 增值操作：“协同”，即可以选择指定人（通常是助理），替自己处理一些审批
• 实时跟踪：可以实时查看当前所处节点，以及对应处理人，并可对其发起“催办”
• …

如此一来，这个工单系统就完整了，体验指数也急剧上升。

重点来了！

消息通知这些还好说，关键数据从哪来？难道也是哪里发起，哪里提供？

猜对了。因为上面提到过，工单系统是规范业务“因与果”的一个桥梁or渠道，他本身不参与业务发起&执行。也就是说，这些业务数据工单系统本身是没有的，也无法凭空变出来，必须由发起方所使用的业务系统提供相应字段及数据。

继续拿“退款”这个例子来讲，用户在APP等客户端发起退款，那么就应该APP提供相应的退款数据。而这些数据到了工单系统之后，我们会对数据做一定的权限控制，毕竟每个节点的处理人所关注的数据不同，那么展示给他的数据也就不一样。比如

• 业务人员关注的商品信息比较多
• 财务关注的是金额是否平账
• 出纳关注的是应该打款给谁，打多少钱

当然，具体要求哪些业务数据，肯定是由我们工单系统方与一线业务方确认业务流程的同时顺带确认的，然后以提需求的形式提给APP团队，并提供一个接口规范，要求APP团队按照规范给到我们需要的数据。

如此一来，规范的数据有了，流程节点有了，通知可以自己做（如果公司有现成的服务那就更好了），到了这里，其实一个合格的工单系统已经完成了。如果想要把工单系统做成一个有价值的、意义重大的系统，还需要最后一步。

而这最后一步，就是自动执行。上面也提到了，我们工单只提供审批结果（通过or不通过）给到发起端，然后由发起端根据工单反馈的结果，自动执行处理。相信我，不要求做自动执行，最终肯定会被一线业务方嫌弃的！

实现了上面提到的每一点，那么一个增加所有人工作量的工单系统，能够在根源上规范业务流程的同时，还在一定程度上增加操作人的体验、减少使用者的操作量，实现技术赋能业务，用过都说好！

总结

扯了那么多，其实总结下来，工单系统可以归结为以下5点：

1. 明确业务流程及需求详情，包括各节点处理人、处理方式，及处理人关注的字段
2. 开发工单系统架构（网上很多开源项目），权限系统（用于配置角色）
3. 明确流程结束后，发起端需要执行哪些操作
4. 给业务端提需求，包括字段和自动执行的内容
5. 在工单系统接入，接入节点通知，接入字段，测试流程

如果接入新的流程，只需要重复步骤3~5即可。

看到这里，好像工单系统也没啥大不了的？

本文由 @ RonT 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议。