问题&场景→需求：问题还原至场景，并对应提炼出需求

本次的设计链路主要分为3个环节：

1. 问题&场景→需求：问题还原至场景，并对应提炼出需求；
2. 需求→功能：需求翻译成功能及解决方案；
3. 功能→问题&场景：线后反向追踪验证功能是否解决了问题。

一、 问题(场景) → 需求

凡是需要多人分工协作的企业，无可避免都需要进行审批。既然钉钉、企业微信等各大办公软件上的审批功能都已经十分成熟了，为什么我们B端客户还需要自己做审批呢？原因有三：

1. 不同公司审批流程难以趋同，中大型公司更是很难因为适应一款审批软件而调整自己的流程；
2. 部分审批含有该行业/该公司的一些特色业务表单，钉钉难以打通审批和业务表单数据；
3. 核心数据存在保密性质，企业不愿通过第三方办公软件来审批一些机密数据表单。

因此，虽然OA审批已经是一个相对成熟的业务模块，但仍旧因行业和互联网化程度不同等原因而存在大量的特异化需求和市场。那么，不同公司的审批场景和需求有什么不同呢？

因为笔者面向的都是某一细分行业的客户，故此处我们先忽略行业性质，简单地来从规模上进行区分讨论。就自身经历而言，笔者既待过数十个人的小公司，也待过上千人的上市公司，对二者的审批流程区别有十分深刻的体会：

• 小公司往往审批决策路径短、流程和形式都较为简洁，但缺乏规范性和保障：例如，当我需要出差时，往往只需要当面和leader说一句就ok了，从流程上来看确实效率很高，但假若在出差期间出了什么意外，口头审批并不能给予发起人充分的后续保障。
• 大公司往往决策路径极长，流程和形式都十分复杂，但在一定程度上能够规范多部门多人员协作下的审批流程，保证工作的正确性和安全性。例如，以前每次出差报销都要填写3张不同的表，填完表后还要专门排好序再用胶水对齐粘好以归档，层层审批之后，在等到报销钱款到账时可能就是数周甚至一个月之后了。

大公司的审批流程虽然繁杂，但如果使用口头审批等不太规范的流程，那么其中随随便便在报销金额上出点纰漏，累积下来就是非常高额的代价。

综上我们可以看出，大小规模公司之间的实际审批流程存在很大的差异性。因为笔者目前所涉客户以传统行业的小公司为主，故以下就专门针对传统行业的小公司审批流程来进行探讨。

传统行业小公司线下审批流程的问题常见于：

1. 缺乏规范的流程：没有明确的审批条件/资料准备/结果记录等，容易造成管理混乱；
2. 缺乏数据留存和透明度：纸质表单维护成本高，后期容易就审批结果及相关业务数据产生推诿扯皮；
3. 效率低下：进度查询和沟通成本高。

为什么传统行业小公司会容易产生这些审批上的问题呢？

• 首先：为了节省人力成本，小公司往往一人身兼多职，因此容易造成管理上的混乱；
• 其次：传统行业小公司的老板和管理往往是业务能力过硬的人才，而这类人正好是较为缺乏管理意识能力的；
• 最后：传统行业更多还是在沿用旧有的思路和方式解决问题，难以快速转型和接受新鲜工具和事物来提升效率。

那么，针对传统行业小公司的上述3个主要问题，我们整理出对应的需求如下：

1. 需要完善规范的审批流程；
2. 需要将审批数据和其他关联业务的数据进行沉淀，形成「审批x其他业务」的完整数据流；
3. 需要降低成本、优化审批效率。

二、需求→功能

在了解到客户需求之后，我们需要通过设计功能和确立优先级去思考对应提供怎样的解决方案。针对上述3个需求，我们粗略地给出各自需求对应的模块清单：

1. 规范的审批SOP：包含权限设计、审批模块业务设计等；
2. 数据沉淀&数据流：审批记录、关联业务的数据流等；
3. 效率提升：实时数据进度查询、即时消息推送、审批效率的智能分析统计等。

1. 规范的审批SOP

首先我们来讲如何什么算作一个完整的审批流程SOP：发起审批-等待审批-处理审批（结果告知）。

1）审批角色

在一个完整的审批SOP中，牵扯到的角色共分为4类：

1. 发起人：例如，需要请假的前端程序员小王；
2. 审批直接处理人：例如，前端总负责人A同意了小王的请假；
3. 审批非直接处理人：小王的请假既可以由A处理，可以由B处理，但是A先进行了处理；
4. 抄送人：小王认为本次审批和他的后端同事C有关系，会影响到排期进度，故将本次审批抄送给了C。

上述是一个相对较完善的审批SOP，其中涉及到了4种角色。显然易见，这4种角色对「审批」事件的影响和关联程度有轻有重，那么这自然就需要依赖到权限层面的设计。

这里不展开讲权限层面的设计，但是无论选择哪种权限设计方式，最终需要明确的结论是：哪一些（类）账号可以发起审批、哪一些（类）账号可以处理审批、而哪一些（类）账号能够查看审批。

2）审批方式

常见的审批方式有3种：并行审批、串行审批、并串混合审批，这里就依赖于我们所面对企业的实际审批流是哪种方式来进行设计。