前段时间写了一些文章，关于做B端产品的一些原则，有很多读者要求我多写些案例，慢慢开始我会来通过一些常见简单需求的例子，教会一些初级的B端产品经理怎样熟练的使用这些原则：无论是OA, HR,CRM,ERP 系统，审批流的是我们经常碰到的问题，比如说组织架构变动，请假，出差，报销，采购申请等等。那在面对一个审批流的时候，我们怎样来进行产品的设计呢？

我们拿一个大家在公司里面经常会碰到的休假申请审批来举例说明吧。比如说我们拿到了一些客户的需求：

比如说公司A, 需要管理一下年假的申请，3天以内的年假只需要直接上司来进行审批，如果超过3天的年假需要二级审批，另外所有休假单子还需要管辖范围的HR的审批。

比如说公司B,需要管理一下年假的申请，2天以内的年假只需要直接上司来进行审批，如果超过2天需要二级审批，超过5天需要三级审批。

公司C的需求比较简单，就是所有年假都只需要支持一级审批。所有超过5天的申请都需要通知一下HR人员。

…….

这种类似的需求非常正常吧，面对这样需求的时候我们怎样做出一个标准产品来满足所有的需求呢？还是说我们需要满足所有的需求吗？这个基于不同的情况实际上最后判断的结果可能不同。

这篇文章就一般情况来进行分析说明一下,首先我们先来看看需求的内容，整体上面来说需求主要包括下面几个部分：

1: 所有的需求来说，前面的审批基本上都是直接汇报对象来进行审批，只是基于天数可能审批的层级不一样。

2: 针对A公司来说，需求有些不一样，一个是超过3天最后一级需要HR进行审批， 

3: 对于C公司来说，超过5天的申请需要通知HR人员。

对于需求1，笔者觉得问题不大，逻辑合理通用。对于第二，三个需求来说，我们需要支持吗？我们可以从下面的维度来进行判断：

1: 需求的逻辑是否合理。

2: 需求的价值有多大。

对于第二个需求来说，需要询问HR，现在三天以上的单子的频率是怎样的？在这个频率基础上面，如果业务部门审批通过，你们拒绝的概率有多大？

对于第三个需求来说，需要继续询问为什么要通知HR人员相关的几个问题，通知到你们了有什么后续动作吗？是可能进行干涉吗？如果进行干涉，什么样的情况下才会进行干涉，怎么样进行干涉？基于公司现在的情况，干涉的概率和量为多少？

你们发现如果深究下去，对于第二三个需求来说，

事实上通知HR以及让HR参与审批意义可能没有那么大，根本没有多大的可能性在业务部门同意休假的情况下，HR会再来拒绝。

这样处理反而让休假申请审批的流程变得低效，而且单子多了HR自己也会觉得很烦（HR因为在业务部门之外，审批休假的动力还有实时性都会很差）。

HR经常的询问业务部门关于休假的细节情况，会让业务部门负责人感到麻烦和不被信任。

实际上HR需要的只是一个能够方便找到多少天以上休假申请的记录而已，如果有太离谱的情况，进行一下干涉。这样的话，可能在原来就需要的HR查询休假纪录功能的记录上面

支持超过一定休假天数的检索就够了。

如果不问青红皂白，就来支持这几个小功能会有什么后果呢？你会发现这个功能并不是很小的功能，一个小的功能要成为逻辑完整的产品功能都不是很容易的事情。

这里面要注意几个点：

1: HR可能是有管辖范围的，产品上面需要支持可以配置每个HR人员的管辖数据权限范围，如果要做成通用产品功能，可能要基于组织架构。这里的产品化配置功能会相当复杂。

2:如果配置HR的数据管辖范围是配在HR员工身上的，主要该HR离职或者调动的情况，要重新进行配置，有可能没有人记得去修改配置。

3:如果一些单子，该HR还没有审批，就离职的情况，这些单子怎样进行处理的问题。

4: 如果一些单子，HR人员自己休假了，没有审批怎么办？

……

我这里只是举例说明了一些例子，你们就知道产品的减法有多重要，一点点的增加可能带来很多的复杂度。如果实现一些逻辑不合理，或者低价值的功能，用户不会因为你实现了而感谢你，实际上他用的

可能会相当烦，天天骂娘，然后因为不好用，又提了一大堆改善的需求或者解决方案，日复一日，年复一年，这个产品会这么样？事实上如果你透彻的理解了产品功能实现的真实效果，是经常可以说服

客户的。（关于需求优先级管理这块，大家可以参考之前的一篇文章：如果定义B端产品的MVP）

通过需求梳理以及确认之后，我们发现需求变成下面的样子：

1:公司A, 需要管理一下年假的申请，只需要支持一级审批，HR需要方便的查看3天以上的年假单子。

2:公司B,需要管理一下年假的申请，2天以内的年假只需要直接上司来进行审批，如果超过2天需要二级审批，超过5天需要三级审批。

3:公司C, 所有年假都只需要支持一级审批。HR需要方便的查看5天以上的单子。

那我们看看主要需要哪几个功能：

1:休假申请，用户可以方便的提交休假申请，填写休假期间，休假类型，请假原因等。

2:休假审批，上级可以收到休假申请的通知，可以方便进行审批通过或者拒绝，拒绝需要填写拒绝原因。

3:休假查询，HR，经理，个人可以进行休假纪录的查询。

4: 如果要做成标准产品，需要一个配置功能，可以配置对应请假天数的审批层级。可以基于客户来配置请假天数范围对应的层级。

然后我们来设计一下整个实现需要的数据库结果，需要包含如下的几个表格：

员工表：员工编号，员工姓名，基本信息字段，汇报对象等。

休假申请表：员工编号，请假开始日期，结束日期，假期类型，请假原因等。

休假审批表：员工编号，请假开始日期，请假结束日期，审批层级，审批人，审批结果，审批日期，审批备注等等（多个审批层级存放多条记录）

配置表：休假类型，天数，审批层级数等。

我们再来看看大致的几个功能页面：

对于所有的需求，所有的设计都没有标准答案，无论整体还是细节的设计都要基于各种因素综合来寻求最佳答案，笔者更希望能够基于一些基于典型案例的梳理，帮助大家找到自己思考的方法论。

作者：李东林（微信公众号：SaaS产品说；微信号：jianguzhuxin），原ADP大中华区产品负责人，14年To B研发与产品设计，团队管理经验，主导过多款大型企业管理软件的设计、研发、上线，也有过2年移动互联网TO C的创业经验，以文会友，欢迎大家加我微信交流。