编辑导语：OA审批，是利用通信技术和网络技术把日常办公所需内容整合进一个平台中，实现办公自动化和提高工作效率的各种信息化设备和应用软件。利用OA审批流程的好处是可以简化办公程序，规范员工行为，实现内部有效分工、规范员工岗位职责，也有助于增强团队之间的协作能力。接下来，本文作者就为我们分享了如何设计OA审批。
随着社会节奏日渐加速，越来越多的企业加入了自动化办公OA（Office Automation）的大军，疫情期间更是让企业办公软件钉钉一度冲上了各大软件平台的榜首。
在企业办公中较为常见的场景有考勤打卡、出差报销和请假审批等，那么今天我们就来分享一下如何为ToB企业设计OA审批功能。
本次的设计链路主要分为3个环节：
- 问题&场景→需求：问题还原至场景，并对应提炼出需求；
- 需求→功能：需求翻译成功能及解决方案；
- 功能→问题&场景：线后反向追踪验证功能是否解决了问题。
一、 问题(场景) → 需求
凡是需要多人分工协作的企业，无可避免都需要进行审批。既然钉钉、企业微信等各大办公软件上的审批功能都已经十分成熟了，为什么我们B端客户还需要自己做审批呢？原因有三：
- 不同公司审批流程难以趋同，中大型公司更是很难因为适应一款审批软件而调整自己的流程；
- 部分审批含有该行业/该公司的一些特色业务表单，钉钉难以打通审批和业务表单数据；
- 核心数据存在保密性质，企业不愿通过第三方办公软件来审批一些机密数据表单。
因此，虽然OA审批已经是一个相对成熟的业务模块，但仍旧因行业和互联网化程度不同等原因而存在大量的特异化需求和市场。那么，不同公司的审批场景和需求有什么不同呢？
因为笔者面向的都是某一细分行业的客户，故此处我们先忽略行业性质，简单地来从规模上进行区分讨论。就自身经历而言，笔者既待过数十个人的小公司，也待过上千人的上市公司，对二者的审批流程区别有十分深刻的体会：
- 小公司往往审批决策路径短、流程和形式都较为简洁，但缺乏规范性和保障：例如，当我需要出差时，往往只需要当面和leader说一句就ok了，从流程上来看确实效率很高，但假若在出差期间出了什么意外，口头审批并不能给予发起人充分的后续保障。
- 大公司往往决策路径极长，流程和形式都十分复杂，但在一定程度上能够规范多部门多人员协作下的审批流程，保证工作的正确性和安全性。例如，以前每次出差报销都要填写3张不同的表，填完表后还要专门排好序再用胶水对齐粘好以归档，层层审批之后，在等到报销钱款到账时可能就是数周甚至一个月之后了。
大公司的审批流程虽然繁杂，但如果使用口头审批等不太规范的流程，那么其中随随便便在报销金额上出点纰漏，累积下来就是非常高额的代价。
综上我们可以看出，大小规模公司之间的实际审批流程存在很大的差异性。因为笔者目前所涉客户以传统行业的小公司为主，故以下就专门针对传统行业的小公司审批流程来进行探讨。
传统行业小公司线下审批流程的问题常见于：
- 缺乏规范的流程：没有明确的审批条件/资料准备/结果记录等，容易造成管理混乱；
- 缺乏数据留存和透明度：纸质表单维护成本高，后期容易就审批结果及相关业务数据产生推诿扯皮；
- 效率低下：进度查询和沟通成本高。
为什么传统行业小公司会容易产生这些审批上的问题呢？
- 首先：为了节省人力成本，小公司往往一人身兼多职，因此容易造成管理上的混乱；
- 其次：传统行业小公司的老板和管理往往是业务能力过硬的人才，而这类人正好是较为缺乏管理意识能力的；
- 最后：传统行业更多还是在沿用旧有的思路和方式解决问题，难以快速转型和接受新鲜工具和事物来提升效率。
那么，针对传统行业小公司的上述3个主要问题，我们整理出对应的需求如下：
- 需要完善规范的审批流程；
- 需要将审批数据和其他关联业务的数据进行沉淀，形成「审批x其他业务」的完整数据流；
- 需要降低成本、优化审批效率。
二、需求→功能
在了解到客户需求之后，我们需要通过设计功能和确立优先级去思考对应提供怎样的解决方案。针对上述3个需求，我们粗略地给出各自需求对应的模块清单：
- 规范的审批SOP：包含权限设计、审批模块业务设计等；
- 数据沉淀&数据流：审批记录、关联业务的数据流等；
- 效率提升：实时数据进度查询、即时消息推送、审批效率的智能分析统计等。
1. 规范的审批SOP
首先我们来讲如何什么算作一个完整的审批流程SOP：发起审批-等待审批-处理审批（结果告知）。
1）审批角色
在一个完整的审批SOP中，牵扯到的角色共分为4类：
- 发起人：例如，需要请假的前端程序员小王；
- 审批直接处理人：例如，前端总负责人A同意了小王的请假；
- 审批非直接处理人：小王的请假既可以由A处理，可以由B处理，但是A先进行了处理；
- 抄送人：小王认为本次审批和他的后端同事C有关系，会影响到排期进度，故将本次审批抄送给了C。
上述是一个相对较完善的审批SOP，其中涉及到了4种角色。显然易见，这4种角色对「审批」事件的影响和关联程度有轻有重，那么这自然就需要依赖到权限层面的设计。
这里不展开讲权限层面的设计，但是无论选择哪种权限设计方式，最终需要明确的结论是：哪一些（类）账号可以发起审批、哪一些（类）账号可以处理审批、而哪一些（类）账号能够查看审批。
2）审批方式
常见的审批方式有3种：并行审批、串行审批、并串混合审批，这里就依赖于我们所面对企业的实际审批流是哪种方式来进行设计。
（并行审批）
无论是审批流，还是类似于WBS箭线图这类活动流，只要是以「流」这种形式所存在的任务，都可以与我们的电路图进行类比，即串联电路、并联电路，以及二者混合的电路。
在设计时，我们可以将工作流类比成电路图，那么思路也就会更为形象和开阔。
同时，我们需要在设计时考虑未来的可扩展性。
如若现在决策只支持并行审批，那么未来是否会存在并串混合审批的可能性？从产品角度上来讲，需要通过对业务的理解来给出一定的未来方向预测并融入业务设计中去，这样能够有效提升研发代码的有效性和可扩展性、避免推倒重来。
2. 数据沉淀&数据流
在系统上操作审批，无疑会产生一系列的活动轨迹和行为数据，而这些数据才是系统能够带给客户的最大价值。那么，我们先来按照一个完整的审批流梳理一下对应会产生哪些数据：
- 发起审批——形成审批单（发起人、发起日期、审批单号、审批单状态等）；
- 处理审批——在审批单的基础上形成对应的处理数据（审批结果、审批人、审批时间等）；
- 审批结果对应关联业务的数据处理——例如，请假审批成功后，对应已请假/剩余请假次数的更新；报销审批通过后，对应银行流水的更新等。
在梳理好数据之后，我们需要一个完整的数据管理中心，即就是在整个OA审批流程中需要一个完整的审批单管理。审批单会根据其状态分为待审批、审批通过、审批拒绝（此处简单说明，暂不赘述发起人撤回和再次修改的更多场景）。
同时，审批单管理需要考虑好不同角色在不同场景下的使用需求。
系统虽然是无情的数字机器，但每一个电脑背后都是一个个真实的人在使用，那么我们就要以人为本，从人的角度去思考如何让审批单管理更贴合还原真实的使用场景。
例如，发起人的关注点：是否发起成功？何时审批通过？若被拒绝，被拒绝的原因是什么？我该如何修改后再次发起审批呢？
对应给出的解决方案应该为：发起后即时给出发起结果；提供审批进度查询、即时推送传达审批结果；审批流程受阻时，及时提供原因和解决方案。
审批人的关注点：
- 我今天有没有审批要处理？
- 表单内容是否正确，我是否应该给他通过？
- 如果不通过，我需要告诉他怎样去调整。
对应给出的解决方案应该为：提供审批待办和推送；在审批时，提供关联业务的表单跳转和查询；审批拒绝后，尤其需要提供对应的驳回原因说明。
上述只是提供了几种思路和高频场景，核心理念还是在于当我们设计功能时，要着重注意考虑和权衡不同角色的使用场景。因为这冰冷的数据背后，也是一个个和我们一样面对陌生系统无处下手的普通人。
3. 效率提升
有人说过，产品经理70%的时间都花在了沟通上，但是其实很多从事传统行业的职业也是。他们在忙于自己手头工作的同时，将大部分的协作都简单地使用了电话、微信和当面沟通来处理，方式很简单，但效率却很低下。
因此，在审批流程的效率提升上，我们需要做的第一件要事就是降低沟通成本，将大部分的沟通场景使用系统来进行替代。
例如，发起人需要知道发起后由谁审批、共需要几个审批环节、当前在什么环节等信息，这个时候，我们就需要对应给出明确的审批流和当前进度等供发起人查询。
当审批人在操作审批时，发现报销表单中除金额填写有误外其余表单都是正确的，那么在驳回该项审批时，就需要能够直接注明驳回原因，而不是再私下发微信找到审批人去进行说明。
帮助审批流中的不同角色减少不必要的额外沟通，就已经能够帮助客户提升大部分场景下的工作效率了。
除此之外，也可以像钉钉那样提供一些审批效率的智能分析统计，比如在审批环节中，谁的审批效率最低，平均每个人的审批处理时长是多久等等，从而可以帮助企业优化每一个审批环节，更好地通过数据反哺流程的优化。
三、 功能→问题（场景）
从某种程度上来说，上线前的方案设计都只是产品经理的一厢情愿。只有上线后接受到了客户的真实反馈，才能真正验证解决方案的有效性。
上线后的追踪验证可以分为两条思路：一条依赖于此前的数据埋点，通过定量分析来进行验证；另外一条可以通过客户调研回访来进行定性分析。
理想状态下，最好能够在一个月内就最终验证成果给出一定的响应优化。
归根结底，审批只是诸多办公场景中的一类，而企业办公的核心要义就在于准确和高效。
在整个OA审批设计中，我们需要时时刻刻从发起人和审批人的角度出发，通过还原真实的使用场景来提供审批功能设计，帮助他们快速而准确地完成一次审批。
客户成功，也就从侧面赋予了我们toB企业成功的价值。
本文由 @冰冰酱 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Pexels，基于 CC0 协议