3、需求分析阶段：如何梳理现有审批流程、识别痛点、定义自动化目标
需求分析，说白了就是搞清楚「现在什么样」和「想要什么样」。
我见过不少团队，一上来就急着选工具、写代码。结果自动化上线后，大家发现流程反而更绕了。为什么？因为根本没把现有的审批流摸透。
这一章，我们就聊聊怎么把这一步做实。
3.1 梳理现有审批流程：别凭印象，要画出来
我个人习惯，第一步不是开会，而是找三样东西：制度文件、历史审批单、系统操作日志。这三样能还原出流程的「官方版」和「实际版」——两者往往不一样。
我的经验： 制度文件里写的「3 天审批完」，实际日志里可能平均要 5 天。别信文档，信数据。
梳理时，我建议按这四步走：
- 列出所有审批节点：谁发起？谁初审？谁复核？谁终审？有没有会签？
- 标注流转条件：什么情况下走分支？金额超过 5 万要加签？部门不同审批人不同？
- 记录耗时和退回率：每个节点平均等多久？退回重填的比例有多高？
- 画出「现状流程图」：用泳道图把角色、节点、分支画清楚。
嗯，这里要注意：画图不是为了好看，是为了让所有人看到同一个事实。
3.2 识别痛点：哪些地方在「流血」？
流程图画出来后，痛点往往一目了然。我把它分成三类：
| 痛点类型 | 典型表现 | 我见过的真实案例 |
|---|---|---|
| 效率型 | 审批慢、反复退回、人工催办 | 某公司采购审批平均 7 天，其中 4 天在等领导签字 |
| 合规型 | 流程绕过、事后补单、权限混乱 | 有人直接找终审领导签字，跳过了财务审核 |
| 体验型 | 填表复杂、状态不透明、重复录入 | 每次审批都要重新填一遍项目编号和预算科目 |
避坑指南： 我曾经遇到一个项目，业务方说「流程太慢」，结果一查，80% 的延迟是因为发起人填错了表单。自动化解决不了填错的问题，得先做表单校验。
识别痛点时，我建议用「频率 × 影响度」来排优先级。天天发生的、影响大的，先动。
3.3 定义自动化目标：别想一口吃成胖子
痛点找到了，接下来就是定目标。我见过最典型的错误，就是目标定得太空——「实现审批流程全面自动化」。你想想看，这种目标没法落地。
我建议用 SMART 原则 来拆：
- S（具体）：不是「提高效率」，而是「将采购审批平均耗时从 7 天降到 2 天」
- M（可衡量）：每个节点耗时、退回率、自动通过率，都要有基线数据
- A（可达成）：先挑 1-2 个高频、低风险的流程试点
- R（相关性）：目标要和业务部门的 KPI 挂钩，否则没人配合
- T（有时限）：比如「Q2 完成试点流程上线，Q3 推广到全部门」
一个可参考的目标定义示例：
- 目标流程：员工出差申请审批
- 现状：平均 3.5 天，退回率 22%
- 目标：平均 1 天以内，退回率降到 10% 以下
- 范围：先覆盖销售部和研发部，后续扩展到全公司
- 时间：6 周内完成上线
3.4 需求分析阶段的核心逻辑
下面这张图，是我做需求分析时常用的框架。它帮我把「现状」「痛点」「目标」串起来，避免漏掉关键环节。
3.5 需求分析的交付物清单
每次做完需求分析，我会要求团队交付以下三样东西。缺一样，后面都可能翻车。
| 交付物 | 内容要求 | 验收标准 |
|---|---|---|
| 现状流程图 | 泳道图，标注节点角色、平均耗时、退回率 | 业务方确认「这就是我们现在的流程」 |
| 痛点分析报告 | 列出 Top 5 痛点，附数据支撑和影响评估 | 管理层认可优先级排序 |
| 自动化目标定义 | SMART 格式，包含基线指标和预期收益 | 技术团队和业务方达成共识 |
一个小技巧： 交付物不要一次性扔给业务方。先画草图，找关键用户过一遍，再出正式版。我吃过亏——辛辛苦苦画了三天，业务方看了一眼说「不对，我们不是这么干的」。
需求分析阶段，说白了就是「把账算清楚」。流程怎么跑的、哪里在流血、治好之后能省多少时间多少钱——这些数字摆出来，后面的自动化工作才有底气。