基于前文对工单的功能架构的重点功能的了解，本文将从【用户管理】、【工单查询】、【工单质检】三个功能模块进行阐述，对工单系统的功能架构做一些补充，希望对你有所帮助。
工单的功能架构的重点功能前两篇已经阐述完了，本篇我们主要在于查漏补缺，阐述清楚前两篇没有讲到的【用户管理】、【工单查询】、【工单质检】三个功能模块，给工单系统的功能架构结个尾。
同时我们也将前文遗留下来没有解释的【渠道接入】、【配置组件】、【流转流程】三个问题解释清楚。
工单系统的账号体系要与设计规划相呼应。如果只是面对后台服务部门的账号体系，那仅仅与服务部门的业务系统中的账号体系做好对接，直接复用业务系统的账号体系就够用了。
如果在设计阶段就期望能够通过工单系统贯穿全公司业务范围，那么工单系统的账号体系最好和公司内部内网、移动办公等系统的用户中心打通，直接和公司级的账号体对接。
这样不仅在账号体系上不需要重新设计，并且能够与业务系统或用户中心的用户账号同步进行增删改的操作，后续对接各系统时也不用考虑账号、登陆等问题。
在权限控制上和其他所有B端系统一样，工单也需要根据权限管理的方法对用户的权限进行控制。权限设计主要有3个原因：
（1）高效分工
权限设计并不仅仅只是为了系统的安全和保密，也在一定程度上有利于提升专业化分工。各部门的业务人员能够专注于各自的业务范畴，从而提升工作效率。
毕竟工单系统又对接合作方、又关联客服、还有商务、维修各个部门，针对不同的部门需求还有不同的处理逻辑，通过对创建环节的工单分类进行控制，可以大大提升业务人员对自己负责业务方面的关注度。
（2）数据安全
如果我们设计的是一个能够打通全公司上下游协作的通用工单系统，那么系统中存储的用户、交易、业务问题等信息在成为公司宝贵的过程资产的同时，也会成为外部重点攻击的对象，系统自身的数据安全性也将是非常重要的一个方面。通过权限管控也能在一定程度上减轻人员问题导致的数据泄露。
（3）权责分明
清晰的权限设计也有利于减少操作风险，保证权责分明。权利义务是相等的，权限不仅仅是代表你拥有了访问、查看、操作某些页面的权利，同时也代表了你将需要承担这些页面访问、查看、操作的过程中的风险控制责任，在出现问题时也能更容易通过权限进行责任认定。
（4）小结一下
因此，对于权限的设计也是需要考虑的问题。在权限设计上，我们建议使用最通用的RBAC模型设计方法，权限–>角色–>用户的方式进行访问控制，能够在满足最小权限原则的同时比较好的兼容更灵活的权限配置。同时根据不同的处理组，我们也可以在处理组上对权限范围的限定进行补充。
工单系统除了能够提高各部门之间的协同效率之外，做到业务处理的数据留存也非常重要，这些一条条的工单数据也是组织业务发展过程中的数据资产。并且在工单日常运营和管理过程中，运营人员也需要掌握工单的处理情况，对工单数据进行查看并作出简单分析。因此对于工单明细记录的查询也是辅助性的功能之一。
在工单较多的情况下，工单系统还需要考虑工单查询的范围和内容，一般情况下我们的设计方案是一年之内的工单查询可以连接一年内的数据库查询，当查询超过一年需要连接历史数据库，进行历史所有工单数据查询。
当工单成为重要工具之后，对于工单的质检也会成为运营人员的一个重要工作，工单质检主要是在业务部门，关注业务部门是否按照要求创建工单、处理工单、关闭工单。
我们建议在工单场景创建的时候，尽量和业务沟通好，从业务层面必须规定好工单的标准作业流程（SOP），这里的标准作业流程需要满足SMART原则。
包括在什么场景下可以创建工单，什么场景下用什么方式处理工单，以及什么场景下允许以什么类型关闭工单。
这里的流程越标准、越具体，工单质检的时候就越能减轻人工、系统在质检场景下的处理和设计压力。
我们建议之间使用人机协同的机制进行，单个的人工质检人工成本太高，单个的系统质检错误率太高。
（1）人机协同
Step1：通过系统将必须检查、并且规则清晰的质检点进行第一轮次全量检查，通过80分【这里质检绩效应该不加不减，也可以设计为100分】，不通过0分【这里应该需要和绩效挂钩，0分失去质检绩效】；
Step2：根据人工的工作量，随机抽取对应的工单量，对必须由人工质检的点，进行第二轮次随机抽查，通过100【这里需要增加绩效】，不通过根据质检情况人工打分；
Step3：设计质检申诉功能， 当质检有误时，支持由被质检人员直接上级发起申诉，由质检人员再次复审；
（2）质检目标
工单质检有利于促进各部门之间的协同体验，同时SOP的建立也更能够提升工单协同的规范程度，从而提升整体的协同效率。
因此在提升效率上，运营、系统需要两手抓，才能够达到1+1>2的效果，否则一定是1+1<2，人机协同的关系下，要么大于2要么小于2，没有中间的状态。
尤其是竞争压力日渐增高的今天，1+1到底等于几，已经成为一个公司的护城河级别的问题。因此尤其是B端产品经理一定要明白，系统设计一定需要和业务做好紧密的协同沟通，适配业务发展的阶段现状，这样才有机会设计出来1+1>2的产品。
工单系统的接入方式主要就是3种、全系统嵌入、H5接入、接口对接。
（1）全系统嵌入
主要是面向工单系统的重度使用业务部门；例如客服、维修、商城、仓库等业务部门，它们从工单创建、工单处理到工单关单都有深度的使用场景，并且也贯穿自己业务的全流程，这种部门几乎可以使用到工单系统任意一个页面。对于这种业务部门我们提供的方式就是可以直接基于工单系统进行全系统的嵌入。
（2）H5接入
H5接入主要面向移动端的用户；例如短信、邮件的通知接收人，可以让用户直接在短信、邮件中打开H5页面直接回复；或者以H5的形式嵌入在移动办公app中，满足业务人员移动办公的要求。
（3）接口对接
接口对接主要面向合作方以及一些对工单系统轻度使用的业务系统，提供接口对接的方式更加有利于保护数据安全，并且根据合作方的要求个性化的定义需要的数据字段、传输方式等内容，更加能够满足各方的要求。
工单系统是一个较为小众的产品，在通用设计层面不会有非常多复杂的处理逻辑。工单系统中沉淀的非常多能够和业务关联的处理逻辑，这些逻辑是工单系统逻辑复杂的原因，因此我们希望工单系统的设计和开发需要将工作聚焦在不断的提升工单处理效率和使用体验。
现在去看很多企业的OA系统，仍然由开发人员进行维护，每新增一个OA流程都需要开发人员开发表单样式、开发接口、对接联调。
这样的上线流程和很多大家在用的工单系统一样，有3个非常严重的弊端：
因此我们在设计上把工单分类完全做成组件化的配置项，业务运营人员可以直接组装出来一个个的新分类，流程变更也可以业务调整后由运营或业务人员直接调整。
大大节省了开发上线的时间，也让工单设计开发人员有足够的时间能够研究和开发与业务关联性更强的扩展功能，让系统更加适配业务。
在业务场景中，流程上增加一个处理人，实际工作上就会增加一个处理工序，例如：客服需要回访用户、维修师傅需要实际去线下维修、仓库需要将货物寄出。
这些处理工序短则1个工作日，长则3-5个工作日，如果一个工单将每个处理流程串联起来，那么工单的处理时效就只能是正比增长：流程越多，时效越长。
这里我们仍然用第一篇中的投诉案例来简单分析一下工单流程的设计：
客户小美找315投诉你们公司的维修员大壮，在修理空调的时候把家里的空调遥控器按坏了。
315将这个投诉单转给你们公司，你们需要复盘当时的维修工单，并且要求维修部门给出回复。
你们发现维修工单是两个月前，记录客户追评认为大壮修得很好；
你们拿到了维修部门的回复，大壮解释当时他发现了遥控器有点接触不良，但是没有在意；
最终经过向上级请示，你们给商城及仓库发了工单，要求给客户寄出一个新的遥控器。
（1）设计为单个主流程的串联流程
工单创建–>投诉处理–>维修部门–>投诉处理–>上级审批–>投诉处理–>仓库发货->投诉处理–>关单；这样从创建到关单总共9个流程节点。
在实际的业务场景中，业务人员在处理业务的过程中并不能及时的关注到每一个业务的情况，因此一般一个流程节点的处理时长大约为24小时。
我们即使按照0.5天的工作量来计算，9个节点最起码也需要4.5个工作日。
同时由于工单再给到仓库或者维修后，投诉人员失去了处理、关单等权利，导致及时工单再维修部门超出了回复时间，投诉人员也不能采取最终方案关单，这不仅仅影响了用户体验，也大大增加了工单的处理效率。
（2）设计为主流程和子流程的并联流程
工单创建–>投诉支持–>关单；
如果投诉团队需要维修、上级、仓库的协助，可以以任务的形式发送给对方，在不影响投诉处理的情况下共同处理该问题。
这样流程节点就能够减少至3个，关单时长起码能缩短至2个工作日；
同时投诉人员也有更多的自主性，在各方超过处理时间未回复的情况下，投诉人员就可以根据规定自己做出最终的处理决定，并关闭工单。
本例能够明显看到“主流程”和“子流程”这套双流转逻辑的设计能够提高任务的并发量，减少串联的等待时长，提高工单处理的自主性。
从而极大的提升多部门协同的效率，从系统设计的角度建立高效的协同机制。
本文由@zxx 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。