3、需求调研与流程梳理：访谈技巧、流程文档编写、AS-IS与TO-BE分析、优先级矩阵

好，咱们进入第三章。这一章，说白了就是整个RPA项目的「地基」。

我见过太多项目，开发团队代码写得飞起，结果上线第一天就被业务部门打回来重做。为什么？需求没搞清楚。你想想看，你连人家每天怎么干活、痛点在哪都不知道，怎么可能做出好用的机器人？

所以，这一章咱们重点聊聊：怎么把业务需求「挖」出来，怎么把流程「写」清楚，怎么分析现状和未来，以及怎么给一堆需求排个优先级。

3.1 访谈技巧：别让业务人员把你当外人

需求调研的第一步，通常是访谈。但很多工程师一上来就问：「你这个流程有几个步骤？」「数据从哪里来？」——嗯，这样问，基本聊不出什么有价值的东西。

我个人习惯，访谈前先做三件事：

• 看资料：先找业务部门要SOP、操作手册、报表模板。心里有个底。
• 列提纲：不是死板的问卷，而是几个关键问题。比如「这个环节你每天花多少时间？」「哪一步最让你头疼？」
• 约时间：别在人家月底结账、月初出报表的时候去访谈。那是找骂。

访谈时，记住一个原则：多听少说，别装专家。业务人员才是流程的主人。你只需要引导他们讲出真实的工作场景。

还有，一定要现场观摩。访谈是「听他们说」，观摩是「看他们做」。我遇到过好几次，业务人员说「这个操作很简单，点几下就行」，结果我去看，发现他开了七八个窗口，来回切换，还手动复制粘贴。嗯，这才是真正的痛点。

3.2 流程文档编写：把「怎么做」变成「怎么写」

访谈完了，下一步就是写文档。流程文档是RPA开发的「施工图纸」。图纸画不好，后面全是返工。

我一般用两种文档：

• 流程描述文档：用文字描述每个步骤。适合给业务人员确认。
• 流程图：用泳道图或BPMN图。适合给开发人员看。

写流程文档，我有个「三要素」原则：

1. 输入：这个步骤需要什么数据？从哪来？
2. 处理：具体做什么操作？有没有判断条件？
3. 输出：结果是什么？存到哪里？

举个例子，一个简单的「发票录入」流程：

步骤1：打开邮箱
  输入：新邮件提醒
  处理：筛选主题包含「发票」的邮件
  输出：邮件列表

步骤2：下载附件
  输入：邮件列表
  处理：逐个下载PDF附件到本地文件夹
  输出：本地PDF文件

步骤3：读取发票信息
  输入：PDF文件
  处理：使用OCR识别发票号码、日期、金额
  输出：结构化数据（Excel格式）

你看，这样写，开发人员一看就知道要做什么。业务人员也能看懂，方便确认。

3.3 AS-IS与TO-BE分析：现状和未来，差在哪？

AS-IS是「现状流程」，TO-BE是「目标流程」。说白了，就是搞清楚现在怎么干，将来想怎么干。

我习惯用一张表格来对比：

做AS-IS分析时，我特别关注「异常处理」。比如：

• 系统卡顿怎么办？
• 数据格式不对怎么办？
• 网络断了怎么办？

这些在现状流程里可能靠「人工经验」处理，但在TO-BE里，必须明确写进机器人逻辑。

3.4 优先级矩阵：先做哪个？别拍脑袋

需求调研完，你会发现一堆流程都可以做自动化。但资源有限，先做哪个？

我常用「优先级矩阵」，两个维度：

• 业务价值：这个流程自动化后，能省多少时间？减少多少错误？
• 技术可行性：这个流程好不好做？系统是否稳定？有没有API？

画个四象限：

你看，「高业务价值 + 高技术可行性」的流程，就是所谓的「Quick Win」。先做这些，快速出成果，让业务部门看到RPA的价值。后面再推其他流程，阻力就小多了。

嗯，这一章的内容差不多就这些。总结一下：

• 访谈要「多听少看」，还要现场观摩。
• 流程文档要写清楚「输入-处理-输出」。
• AS-IS和TO-BE对比，重点看异常处理。
• 优先级矩阵，先做Quick Win。

下一章，咱们聊聊怎么把这些需求变成真正的RPA机器人。到时候见。