RPA 和 API 怎么选，先看这件事值不值得做
接口能做的事别用机器人，机器人能做的事别硬写接口。这篇讲同步、对账这类跨系统数据同步该走哪条路。先看这件事一个月发生几次，再看两个系统之间有没有现成接口。RPA和API的区别不在技术难度，在于对方系统升级时谁来善后。也会写清什么场景适合RPA，混着用的时候接口该放在流程的哪个位置。
业务方说「同步一下不就行了」
会议室里，业务方指着一张表说，把这些订单每天同步到 ERP，现在全靠人工导出再导入，一天花十分钟左右。开发同学问了句，对方有没有 API。业务方说不知道，反正也没多麻烦。
十分钟这个数字，其实已经把答案给了一半。这件事做自动化的收益上限就是每天省十分钟，一年下来不到四十个小时。按任何一种算法算，都撑不起一次开发加一次维护的成本。
但这类请求不会消失，它们会换个说法再来一次。所以这篇想聊的不是怎么用 RPA 同步订单，而是一个更靠前的问题，一件跨系统数据同步的活到底该走哪条路。
先问频次，再问有没有接口
两问的顺序不能反。先问频次，因为频次决定这件事有没有自动化的价值。一天一次和一天五十次，是两种完全不同的东西。
频次高到什么程度才值得动手。粗略一点，一天跑三次以上，或者一次跑动的人工量在半小时以上，就该认真算一笔账。一天一次、十分钟以内，答案基本是不做。这个数字只当锚点用，真有特殊情况可以推翻，但要能说清为什么。
RPA和API的区别，往往到这一步才谈得上。前两问没走完就开始比工具，顺序就反了。
频次过了，接着找接口。这件事有个坑，业务方往往不知道有没有接口，研发也没去查过，因为手动导一下也能用，这个现状把接口的存在挡住了。于是自动化方案在会议室里被讨论起来的时候，没人提过 API 这个选项。
所以第一个动作往往是让研发花半小时去查。对方有开放平台接口、有数据库只读权限、有以前对接留下的痕迹，都说明这条路可能是通的。
RPA和API的区别，不在技术难度
找到接口之后，真正的比较才开始。很多人默认接口一定比机器人好，这个判断不成立。两者的差别集中在三件事上。
第一是对方改版时的成本。接口一般有版本号，对方要改结构会走一轮升级流程，你跟着改代码，改动范围能估出来。RPA 绑的是页面，对方换个按钮位置、插一个二级确认、加一道滑块，流程就断了。断得悄无声息，流程跑到一半取到空值，报表里少了几行，往往要等到对不上账才被发现。
第二是取数的完整性。接口给的是结构化字段，一条订单有哪些字段是约定好的。RPA 看到的是页面上显示的东西，页面上不显示的字段就取不到，或者得靠拼接文字、解析表格。这一层的可靠性天然低一档。
第三是出问题时谁负责。接口是双方对过文档的东西，对不上可以拿着文档去问。RPA 抓的是别人的界面，对方不欠你任何承诺。这条在真出事的时候最要紧。
接口该怎么用，别把接口用成脚本
接口能用，不等于用好。用接口最常见的失败方式，是把它当成一个定时脚本，每天拉一遍数据塞进表里。这条路能跑，但省不掉关键的一环。
差的一环是状态。订单系统里有一条订单，昨天没同步，今天状态变了，你今天拉一次，是覆盖还是追加。拉的时候正好赶上对方系统在更新数据怎么办。同一条订单因为状态变化被改过两次，要不要都留着。这些问题不在接口层解决，在流程里解决。
所以用接口至少要有三样东西。一个自己维护的状态表，记哪些单子拉过、拉的时候对方是什么状态。一个幂等的写入逻辑，重跑一次不会产生重复。还有一个对账口子，每天比对两侧的数量和金额，差上了要能被人看见。
这三样做完，接口方案才算能用。否则它只是把人工的重复劳动换成了机器的重复劳动，出错的时候还更快。
还有一个接口对接经常被忽略的点，权限。对方给接口的时候，权限范围是跟着账号走的。一个只能读不能写的账号，和一个能直接改单据的账号，接口调用方式完全一样，但风险差很多。申请权限的时候按实际需要来，别一上来就要管理员权限，对方安全岗多半会卡。卡下来的流程最后往往变成让流程共用一个高权限账号，这比一开始把权限拆细更麻烦。
什么场景适合RPA
把两边摆开看，什么场景适合RPA，判据不全在对方给不给接口这一条上。接口那一条只决定了一半，另一半在流程本身长什么样。
对方系统没有你能用的接口，也不太可能开。供应商的后台、老的行业软件、只有网页表单的内部系统，都属于这一类。
流程的判断条件多，而且规则写在人的脑子里，没有落在文档上。老财务知道哪些单据要特殊处理，这个判断没法翻译成接口调用条件，只能让机器去点、去填、去试。
触发的时机不定，需要有人喊一声才动。这时候用消息触发比定时跑更合适，群里一句话就能拉起一条流程。
操作本身有不可替代性。对方要求必须从网页走一遍，或者留痕要求必须是在页面上操作产生的记录，接口拿不到。
反过来，什么场景该直接走接口。数据量大、频次高、字段结构明确的，都是接口的主场。两边数据量差一个量级的时候，RPA 逐条点击的成本会高到没法看。
还有第三种情况，两边都不合适，改流程。这不算逃避，有些需求本来就不该靠自动化实现，得把流程本身简化掉。真到了接口对接这一步才发现流程绕，可以退回去重来，代价只是白查了一次文档。
混着用的情况最多
跨系统数据同步最后落到什么形态，多半取决于对方系统给不给接口，以及两边数据的量差多少。这两件事在项目开始时能问到，就不会在实施到一半时返工。
实际项目里最常见的形态，是接口和 RPA 各干一段。取数用接口，中间处理用 RPA 或者脚本，写回用接口。
为什么取数用接口。因为取数是最容易出错、量又最大的一段。列表页翻页抓取，页面结构一变就少数据，而且这个错误往往不报错。用接口取一份全量，几秒钟的事，字段还带类型。
为什么中间处理可以交给 RPA。因为中间处理常常需要判断，而判断用的那个系统不一定有接口。这一段逻辑单条执行，不涉及大量数据。
为什么写回用接口。写回涉及对方系统的状态机，接口能拿到明确的返回值，失败了知道卡在哪一步。RPA 点完提交按钮，只能靠再读一次页面来判断成没成。
这个结构还有个附带的好处，出问题时好定位。取数阶段的错查接口，中间阶段的错查那一段 RPA，写回阶段的错查接口返回。三段的分界线是清楚的。
上线前把责任问清楚
不管走哪条路，上线前有一件事必须落到纸上，就是对方系统改了怎么办。
走接口的时候，这句话是，接口升级我们提前多久知道、怎么通知、版本不兼容时流程怎么处理。一般大厂的系统有变更公告周期，能写进流程。
走 RPA 的时候，这句话是，我们怎么发现对方改版了、谁去改、多久能修好。这里有个务实的判断，如果对方一个月改一次界面，这条路的维护成本会很高。真要上，得把监控做起来，流程跑不通能第一时间发现，而不是等月度报表少了数据才追问。
还有一条常见但容易被跳过的事，谁来维护这个流程。人会离职，系统不会。人走了以后流程还在跑，出问题找谁，这句话在项目开始的时候问，比在出事的时候问容易得多。
这几件事写下来花不了多少时间，省的是半年后重新翻聊天记录。
把这些问完，答案通常自己就浮出来了，剩下的只是执行。
延伸阅读