企业 RPA 项目失败，很少是因为工具选错了。市面上主流 RPA 平台的基础能力早已趋同，真正拉开差距的是三件事：流程选得对不对、异常处理设计得好不好、以及回报算不算得清。这三件事都发生在写代码之前。
第一步：选对流程，比什么都重要
不是所有流程都适合 RPA。选错流程的典型后果是：开发投入不小，上线后发现需要人工介入的次数太多，最后被弃用。
适合 RPA 的流程通常满足以下特征，可以按这个清单给候选流程打分：
- 高频重复：每天或每周都在发生。频率越高，单次节省的时间才越能累积出价值。
- 规则明确：判断逻辑能用文字写清楚，不需要依赖经验判断。凡是需要"看情况"的环节，都要单独评估。
- 系统稳定：涉及的系统界面与字段不经常变动。如果目标系统每季度大改一次界面，维护成本会吃掉大部分收益。
- 人工错误成本高：这是最容易被忽略、但往往回报最大的一条。对账、报税、数据录入这类工作，人工错一次可能要花一整天返工，机器人的价值不只是省时间。
- 数据来源结构化：输入是系统里的字段、Excel 表格，而不是扫描件或手写单据。涉及 OCR 的场景要先验证识别准确率。
反过来，以下几种流程建议暂缓：需要频繁人工判断的、规则本身还在变动的、涉及外部系统接口极不稳定的（比如某些只提供网页端的老旧政务系统，反爬与验证码会持续制造麻烦）。
第二步：真正的开发工作量在异常处理
新手常犯的错误，是认为 RPA 开发就是"把正常路径录一遍"。实际上，一个流程的正常路径可能占 20% 的开发量，剩下 80% 都在处理各种异常：
- 目标系统当天维护，登录不上
- 数据源表格里多了一列，或者某一行是空的
- 网络波动导致页面加载超时，元素找不到
- 待处理的数据本身不符合业务规则（金额为负、日期倒挂）
- 需要审批的节点，审批人三天没处理
每一种异常都需要明确三件事：怎么发现、怎么重试、什么时候转人工。没有设计这三点的流程，上线后一定会以"卡在那里不动了，没人知道"的方式失败——而这类失败比直接报错更危险，因为它不产生告警，只产生静默的数据积压。
一个实用的做法是：给每个流程定义"最大重试次数"和"超时阈值"，超过就生成一条待办推送给责任人。宁可让人多看一眼，也不要让流程无声地停住。
第三步：ROI 怎么算才算清楚
很多 RPA 项目在立项时算不清回报，导致后续争取资源时说不明白。一个可以直接套用的框架是：
年化收益 = 单次节省工时 × 年执行次数 × 人力小时成本 + 年化错误成本降低 + 响应周期改善的间接收益
其中三部分值得展开：
- 单次节省工时：注意要算"净节省"，即原来的耗时减去机器人执行期间人工仍需投入的监控与处理异常的时间。只算前者会明显高估。
- 年化错误成本降低：把过去因人工失误造成的返工、赔付、客户投诉处理成本汇总，乘以预估的降低比例。这部分常常比人力节省更可观。
- 间接收益：比如月末结账从 5 天缩短到 2 天，让管理层更早看到数据，这个价值难以直接折算，但可以在汇报时单独说明。
成本侧不要漏掉：许可证费用、开发投入、以及上线后的维护成本。维护成本常被低估——系统界面每变一次，相关流程就需要跟着调整。
第四步：上线只是开始，运维机制决定成败
RPA 上线之后会遇到三类变化：业务规则变了、目标系统升级了、数据格式改了。没有运维机制的团队，往往在这三类变化中逐渐失去对机器人的信任，最后退回人工。
建议在项目验收时就同步建立三件事：
- 执行监控看板：成功率、平均耗时、异常类型分布、人工接管次数。指标异常时能第一时间发现。
- 责任人机制：每个流程都有明确的业务负责人和技术支持人，出了问题是找谁要清楚。
- 变更同步流程：目标系统要升级时，提前通知自动化团队评估影响，而不是等流程跑挂了才知道。
小结
RPA 是一项工程性很强的工作，它的难度不在工具，而在对业务流程的理解深度。选对流程、设计好异常处理、算清回报、建立运维机制——这四件事做扎实，成功率的提升远比换一个更贵的平台明显。
如果你们正在评估第一个 RPA 场景，把候选流程列出来，按上面的清单逐项打分，通常很快就能看出哪个值得先做。需要更具体的建议，也可以直接联系我们做一次场景评估。