在工作中，涉及到审计效果的业务场景很多，如请假、加班申请、采购订单等 。既然应用审计的场景那么多，那么审计功效是否可以设计成一个通用的模块来复用？这个是可以的，我就带大家分析一下审计效果 。

01审核表的组成下图是一个常见的请假申请表 。如果按照操作内容来划分，可以分为两个区域:业务表单区和审批表单区 。
业务表单区:业务表单区重要的是填写与具体业务相关的内容信息 。
审批表单区:审批表单区是审批人填写审批意见的重要区域 。根据我们常用的审批单模板，可以看到不同审批单审批区域的可操作性内容基本相同，包括审批人、审批意见、审批状态 。

02参与角色审计中涉及到两个重要的角色:发起人和审计员:
发起人:业务内容的创建者，所有审批流程的开始，基本的操作功能包括提交审批、取消、根据审批意见修改业务表单 。
审核人:根据业务内容完成意见审核的人员 。基本操作效果包括通过、否决、撤销、填写评审意见等 。

03批准操作就单一审核表单而言，其功效相对简单，以下几点比较重要:
提交:发起人发起当前业务进入审批流程的申请，是所有审批流程的起点 。一般由发起人手工提交，也可以根据条件自愿提交 。
通过:审批人根据业务内容做出的决定 。如果满足条件，审批流将进入下一个审批节点或停止 。
拒绝:与通过相反，批准者根据业务做出决定 。如果不满足条件，则拒绝，审批流返回到上一个审批节点或开始节点 。
取消:审核人完成审核后，下一个(通过)或上一个(驳回)节点的审核人做出审核前，可以通过【取消】撤回审核意见，重新修改审核内容 。
取消:发起人因自身原因未完成所有审批流程时，自动取消审批申请，返回业务表单编制节点 。

04批准模型1.连续批准串行审批很重要，就是一个审核节点通过，能力就到了下一个审核节点 。如果拒绝，则拒绝到上一个节点，或任何上一个节点或业务表单编制节点 。

2.平行审批并联审批是指在一个审批节点中可以同时审批多个对象的情况 。当其中一个、多个或全部能力得到批准后，该能力将进入下一个批准节点 。如果拒绝，通常其中一个对象被拒绝，当前节点被认为被拒绝，其他情况很少应用，比如多对象拒绝和所有对象拒绝 。具体的批准或拒绝取决于业务场景 。

3.杂项审计混合审核通常是指包括串行审核和并行审核的 。如下图所示，整个流程是串行审批方式，其中一个节点是并行审批方式 。
通过对上述 的分析可以看出，一个审计流程通常由多个审计节点组成，每个节点最重要的义务就是找到相应的审计人员并做出相应的反馈 。

05应用场景场景1:指定审批人发起申请时，发起人可以指定被审核人，这是很常见的 。优点是功效简单，灵巧度高，缺点是无法形成规模化审核流程 。适用于那些审核要求不高的业务，如请假、补卡晚、加班等 。这种审核流程通常不会太复杂，因为是用户自己设置的 。

场景2:固定审批流企业还有很多审计内容，因为涉及金额和机密信息，所以上面人为定制的 不太实用 。他们的审计流程通常是洪都博客的标准审计流程，比如采购订单和合同 。针对这种情况，需要设计一套规模评审流程，后期由技术人员或产品经理进行保障 。
除了审计员，还需要根据业务参与更多的匹配规则，例如:
1)审批金额:只有满足一定的金额条件，才会触发相应的审批人 。比如企业的采购订单审批，当采购金额小于等于10000时，可以由采购主管审批；如果大于10000，需要采购经理批准 。
2)审核人的动态确认:上面我们已经总结过了，审核其实就是找到对应的审核人，然后完成审核信息 。有几种 可以设置审计员:
指定人:在审批节点明确指定具体的审批人 。
具体岗位:将节点设置为对应部门下的岗位 。当审批流进入节点时，系统会根据职位信息动态获取当前对应的人员 。这样的设计可以保证员工岗位变动后，新员工可以继续审核，而不必修改审核和设置红豆博客 。
3)信息通知:当审核进入相应节点时，向发起方和审核方发送信息通知，及时了解审核状态 。通常这个逻辑是由代码完成的，效果不会体现在原型图中 。
4)抄送:当信息发送给审查者和主办方时，还应发送一份副本给指定的抄送人 。
【电商后台设计：审核流 抄送人和审批人的区别是什么】