“财务自动化”太大，“合并三份表”才便于评估
一个部门通常同时包含录入、核对、判断和审批。把整个部门写成自动化场景，会掩盖动作之间的差别。更有效的任务描述是：“从哪里取得哪些数据，按什么规则处理，交出什么结果。”下面十类任务都可以进一步收缩成第一期，但是否适合要看现有资料和权限。
十种常见任务，对应十种具体输出
| 任务 | 输入 | 输出 | 关键例外 |
|---|---|---|---|
| 文件重命名 | 固定目录中的文件 | 按编号和日期命名的副本 | 编号缺失、同名冲突 |
| 多表合并 | 字段约定好的门店表 | 明细、汇总、异常表 | 缺列、重复、统计口径不同 |
| 后台报表下载 | 门店与日期条件 | 校验后的导出文件 | 登录失效、合法空结果 |
| 编码格式整理 | 含空格或格式混用的编码列 | 标准格式与变更对照 | 前导零具有业务含义 |
| 两表差异核对 | 有稳定编号的两份记录 | 缺失与字段差异清单 | 一个编号对应多次业务事件 |
| 标准文档填充 | 已确认字段和模板 | 待检查的文档草稿 | 版本混用、字段留空 |
| 到期提醒 | 日期、状态和负责人 | 待办清单或获准的通知 | 已完成事项未更新状态 |
| 目录资料检索 | 命名有规则的文件集合 | 文件位置与匹配依据 | 同名、旧版、无权限文件 |
| 批量生成草稿 | 通过校验的订单字段 | 系统内待确认草稿 | 重复提交、商品编号失效 |
| 结果归档 | 已确认报表与业务编号 | 目录、索引与归档记录 | 目标已存在、文件未生成完成 |
这些任务不必全部使用 RPA。文件已经在本地时，可以直接处理文件；系统提供获准接口时，可以评估接口；必须操作已有页面时，再讨论界面自动化。任务边界应先于工具名称。
一个合并任务怎样形成完整结果
假设三个门店文件共有 110 行，其中 10 行经规则确认是完全重复记录，去重后剩 100 行；其中 8 行缺少门店编号，当前能用于门店汇总的是 92 行。交付结果应同时包含 92 行有效明细、8 行待补记录，以及 10 行重复记录的去重说明。
如果只交一张 92 行的表，业务人员无法知道剩余数据去了哪里。如果把那 8 行按文件名猜成某个门店，又会制造未经确认的数据。首版可以生成待核对汇总，等 8 行补齐后再生成完整正式版本。
用四个问题选出第一项
- 输入能否稳定取得？至少拿出一份正常样本和一份异常样本。
- 输出能否手工复算？例如总额、记录数、差异项是否有明确依据。
- 主要动作是否有成文规则？如果依赖临时判断，先把判断留给人员。
- 试做是否容易隔离？优先选择生成副本、草稿或差异报告的任务。
候选项同时满足这四点时，沟通和验证通常更直接。涉及支付、合同、采购或对外发送的工作，可以先缩小为整理材料、计算结果或生成草稿，再单独定义正式动作的权限和确认方式。
第一期写清楚“交到哪一步”
以门店合并为例，可以约定只支持当前三种文件格式，输出可核对的三类清单，由人员补齐异常并确认报表；自动催交、修改源系统、发送给外部客户另行评估。这使试运行能回答一个具体问题：合并与核对工作是否确实减轻。
后续增加任务时，沿着真实瓶颈推进。若大部分时间花在补门店编号，改善输入表可能比继续增加报表样式更有效。