开篇：出差审批靠群消息，找审批人靠问
一家 200 人左右的制造企业，年后第一次出差申请是这么走完的：员工在群里 @主管，主管看到后回个"OK"，员工截图保存；财务月底要做差旅报销时，按截图挨个对照预算；HR 年底统计"员工出差天数"，结果发现截图不全、跨部门的数据没对齐。
这不是个别现象。审批这件事在国内大量公司里是这样流转的：
- 找人靠问：新员工入职第一周，最常问的就是"我请假找谁批？我报销谁审？"
- 群消息当凭证：微信或者钉钉群里"@老板 已批"当作审批通过，事后无法审计。
- 跨部门数据对不上：销售部认为客户拜访已经批了，市场部认为没批，财务按销售部的截图付了款。
- 权限靠口头：某经理离职，权限没收回，新人来了不知道原经理审批的合同在谁手里。
这些问题的根源不在"审批这件事有多复杂"，而在审批流没有落进系统。群消息、口头、截图都是临时媒介，缺的是结构化、留痕、可追溯的载体。OA 系统（办公自动化系统）就是把这件事结构化：把"谁、什么事项、什么时候、找了谁、按什么规则批、批完之后数据怎么沉淀"全部沉淀到一条审批流里。
01 业务怎么拆：审批流的三层结构
把审批这件事拆开，其实是三层：
- 事项层：员工发起"出差、请假、报销、合同、用印、采购"等具体事项，每项里都带金额、天数、附件、关联业务对象（出差申请关联销售订单、报销关联发票）。
- 流程层：事项从一个节点流向下一个节点，节点的审批人是动态算的（按部门、级别、金额、品类），不是写死的。
- 数据层：审批通过或驳回后，数据要回写到业务系统（HR、财务、销售、合同库），不能只停在审批流里。
三层的关系是：事项是入口，流程是主干，数据是出口。做 OA 系统如果只做了流程没做数据出口，审批流就成了孤岛；只做事项没做流程，就退化成"填表系统"。
02 怎么设计：动态节点、权限矩阵、留痕三件套
节点设计：审批人不是写死的
很多 OA 一上来就把审批人写死："出差申请 → 部门经理 → HR → 总经理"。结果部门经理换岗、HR 并入行政部、总经理外出，系统全部错乱。
正确做法：审批人由规则动态算出来。规则维度通常有四个：
- 部门维度：申请人所在部门对应到该部门当前负责人（按组织树实时查）。
- 级别维度：金额、天数、合同金额对应不同区间，对应不同审批层级。
- 角色维度：合同金额超过 50 万，法务必须介入；员工出差到海外，安全合规必须会签。
- 代理人维度：审批人请假或者出差，自动转给代理人，代理人由组织关系或者 HR 设定。
把这四个维度组合成"规则表达式"，流程引擎按规则实时算节点，不写死审批人姓名。换岗、组织调整都不需要改流程模板。
权限设计：菜单、数据、字段三级
权限不是"能不能进系统"，而是三级：
- 菜单级：能不能看到这个模块（普通员工看不到"组织架构管理"）。
- 数据级：能不能看这条数据（销售一部只能看本部门员工的报销，看不到销售二部）。
- 字段级：这条数据的某些字段能不能看（普通审批人看不到申请人薪资字段，但 HR 能看到）。
三级权限拆开之后，OA 系统就能支撑复杂的组织结构：集团-分公司-部门-小组，跨级数据要按"我能看到我自己这条线 + 我是这条线的负责人"两条规则并行控制。
留痕设计：审批日志的七要素
每次审批操作必须留七要素：
- 操作人：谁点的。
- 操作时间：精确到秒。
- 操作动作：同意、驳回、转交、加签、撤回。
- 操作意见：驳回意见必填，同意可空。
- 节点位置：当前是流程的哪一节点。
- 关联数据快照：审批时业务对象的字段值（金额、附件）原样保存，不允许事后修改业务对象而审批记录没变。
- 设备和 IP 痕迹：从哪台设备、哪个 IP 发的（合规审计用）。
这七要素缺一项，审计时都会扯皮。常见坑是"操作意见可空"，结果驳回没有理由，员工反复重提，审批流拉长。
03 怎么开发：流程引擎、表单引擎、消息总线三件套
开发 OA 的核心是三个引擎，不是 N 个页面：
流程引擎
流程引擎不写代码，靠配置就能跑流程。要支持的特性：
- 串行、并行、会签、或签：四类基础流，转正申请是串行（HR → 主管 → CEO），采购会签是并行（财务和采购主管同时审）。
- 条件分支：按金额、品类、申请人级别分流，5000 元以下走简易流，5000 到 50000 走部门加财务双审，5 万以上加 CEO。
- 回退和驳回：驳回到申请人、驳回到任意节点、驳回到上一节点，三类驳回都要支持。
- 加签和转签：审批人能把任务转给同事（转签），也能拉一个同事一起审（加签）。
- 撤回和作废：申请人能撤回未审批完的事项；管理员能作废异常事项。
流程引擎做出来之后，新增一类审批不用写代码，画个图、配个表单就能上线。这是 OA 区别于"审批外包开发"的关键。
表单引擎
表单要"零代码设计"：字段类型（文本、数字、日期、附件、关联业务对象）、校验规则、必填选填、显隐条件，全部可视化拖拽配置。这样 HR 调整报销字段、销售增加合同字段，不用 IT 排期。
表单引擎要支持：
- 字段级权限：同一张表单，不同审批人看到的字段不一样（普通审批看不到申请人手机号）。
- 字段联动：选了"合同类型 = 服务合同"，自动展开服务合同特有的字段。
- 数据回写：审批通过后自动回写到业务系统（合同状态、HR 考勤、财务凭证）。
消息总线
审批通过或者驳回，申请人、相关业务系统（HR、财务、销售）都要即时收到通知。消息总线统一发：
- 系统内通知：站内信加待办。
- IM 通知：企业微信、钉钉、飞书 webhook，推送到对应群或个人。
- 邮件和短信：重要节点备份通知（合同审批、海外出差）。
- 业务系统消息：审批通过后，写一条消息到业务系统的待办（财务收到报销待办、HR 收到入职待办）。
消息总线不是"装饰"，是审批流的"打回路"——没有消息通知，申请人不知道下一步该找谁，整个流程就卡住了。
收束：落地的顺序、风险与指标
OA 系统上线分三步：
- 第一期（1 个月）：上请假、出差、报销三件高频事项，覆盖全员。先把微信群里的审批搬进系统，哪怕只搬这三件，跨部门数据就立刻对齐了。
- 第二期（2-3 个月）：上合同、用印、采购、付款四件中等频次事项，接财务系统。这一期要打通数据回写（合同审批通过自动归档到合同库）。
- 第三期（按需）：上绩效、晋升、转正、招聘、离职等人事全流程。这一期是 HR 主导，要打通 HR 主数据。
常见风险：
- 规则过于灵活：审批流配置太自由，结果谁都不知道下一步是谁。原则：流程模板不要超过 30 个，多了就失控。
- 代理人漏配：审批人出差没配代理人，流程卡 3 天无人审。系统检测"流程挂卡超过 24 小时"自动报警。
- 数据没回写：审批通过了，但 HR 系统里考勤没更新，财务系统里没凭证。回写要"双写校验"，OA 写完主动调业务系统的接口确认收到。
检验项目成不成的指标：
- 审批平均完成时长：上线前群里走 3 天，上线后系统里 1 天内闭环。
- 跨部门数据一致性：HR、财务、销售三套口径的对账差错率下降 80% 以上。
- 审计可追溯率：随机抽 20 条历史审批，七要素齐全率 100%。
把审批从微信群里搬到系统里，不是为了"上系统"，而是把"找人"这件事从依赖人变成依赖规则。规则一旦写下来，谁离职、组织怎么变，审批都不会乱。