工单管理系统设计——架构篇

编者按：工单管理系统存在于支持其他系统中，因此在设计结构时不仅要考虑工单本身，还要考虑其他系统。本文将分析工单管理系统的结构，希望对您有所帮助。

高层建筑平地起，建筑时，先起基础。产品设计先定架构，再打磨细节。今天，我们开始谈论工单的架构。

一、产品结构

架构，高，假装高，我们经常听到一个：架构师的职位，架构是什么？事实上，我不太了解，这里我将简要谈谈我对产品结构的理解：产品结构是基于业务，深入了解用户需求，从0-1开始设计一个完整的产品解决方案。

良好的产品结构可以完全支持现有的业务需求、用户需求和管理需求。同时，当业务、用户和管理需求发生变化时，可以以最小的价值实现对这些变化的支持（有点中间平台的味道）。产品结构的设计与数据和用户是分不开的。

1. 数据

设计产品架构实际上是在线设计业务，业务在线显示形式是流程，更深入：流程是数据 顺序 权限构成，当我们设计产品架构时，其实本质是设计数据的来源和地点，明确数据从何而来。

2. 用户

这里的用户是角色的概念。产品用户不是单一的角色。产品需要支持多角色的共同需求，产品架构应该是最了解用户的，能够满足所有用户的需求。

综上所述，梳理产品架构实际上是一个在线业务的过程，即梳理数据和用户操作需求。

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

《工单新义》明确解释了什么是工单系统，做了一个简单的总结：工单实际上是一个支持系统，为了支持其他业务，所以在设计工单框架时，考虑工单本身，也考虑其他系统，在设计工单之前，我们应该考虑两点：

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

说到工单，我们会想到：客户服务。我一直认为客户服务人员是工单的用户，然后根据客户服务的需求开始设计工单，往往忽视其他部门。

这样设计的工单不仅会影响客户服务，还会给其他部门带来不便。常见的场景是：客户服务线下登记表，发送给其他业务部门，客户服务不知道其他部门的处理结果，反复询问。由于外部业务产生的工单（系统自动生成），客户服务通常是第一个接收人。在许多情况下，客户服务人员无权处理，需要其他业务部门的支持。工单系统的设计应考虑整个公司。

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

工单中很大一部分数据来自其他系统，或者其他系统的某个动作导致工单的产生。当然，这部分不需要考虑太多，因为其他系统的动作产生工单，只是接受你的数据。

当工单处理完成或产生一定结果时，需要考虑对其他系统的影响。例如，订单的退款申请导致工单的产生。客服人员处理后，同意订单的退款，需要将订单状态改为：退款（状态可根据自己公司的业务确定），事实上，这是工单需要考虑的全功在线呈现。

至于新建、分配、了解业务、工单状态，这里就不赘述了，后续文章会详细讲解。

三、工单框架设计

框架图的风格是上图还是思维导图？客人和官员应该自己判断。这里没有工作单的框架图。毕竟没有商业场景(主要是懒惰)，主要是基于框架中需要考虑的内容。见下图:

工单内容：

工单信息主要记录在工单页面上，与工单相关。例如，工单需要发起人、类型、内容、状态等信息，并提供与工单相关的信息，如订单。

工单状态：

创建工单后，需要流通，需要用状态标记。

工单日志：

工单从创建到最终结束有一个过程。工单日志主要记录不同人员在此过程中对工单的操作。工单日志可分为系统日志、操作记录等。

工单分配：

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

工单类型：

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

处理人员设置：

工单处理人员基本上是基于类型设置的，即不同类型的第一处理人员不同，通过处理人员设置，系统可以自动分配工单，也可以根据处理人员设置判断工单权限，有A类工单处理权限的人员可以在系统中看到A类工单，可以等待系统分配，也可以自动接收工单处理。

处理结果：

工单处理结果后，需要客服人员记录，记录后，触发其他系统的文件或操作。

分析报表：

通过对工单问题的分析，可以推动业务优化，通过对工单处理时间的分析，可以对工单进行分析SOP优化离不开工单报表。

工单系统的框架离不开上述内容。业务研究和需求梳理最终是对上述内容的不断优化。在设计工单系统时，我们将围绕上述八点进行扩展和细化，并结合我们的实际业务需求设计一个易于使用的工单系统（所有工单系统都围绕上述八点设计，易于使用的只是更符合业务需求和操作需求）。

最后说几句话

工单系统本身并不复杂。制作工单系统和一般工单系统非常困难。毕竟，每个公司的业务场景和系统功能都不一致，因此很难制作工单系统saas如果不考虑其他系统的对接层次，可以考虑saas然后通过集成处理(但系统本身并不复杂，集成成本可能远远大于开发工单系统的成本，客官可以自己考虑)。

工单框架本身并不复杂。复杂的是细节设计、工单用户的习惯和工单处理的培训成本。作为产品，我们应该考虑前两个，后一个只能尽可能支持。毕竟，工单的处理是业务层面的事情。我们能做的就是做好系统，让用户更方便地处理系统层面无法处理的工单。

从最后一个工单新意义开始，工单系统系列文章已经开始，基本保持每周更新的节奏，从工单定义到工单框架到工单细节设计，产品合作伙伴可以注意，当然，如果有任何问题，想嘲笑写不好，希望在后续文章中详细介绍可以通过信息告诉我。

就这样，下周见！

本文由 @摸鱼不划水 每个人都是产品经理，未经许可不得转载

题图来自 unsplash，基于 CC0 协议