有人私问，统一回答。

RPA核心是模拟人的操作、模拟人的操作、模拟人的操作，重要的事情说3遍。

这种模拟通常是基于操作界面（UI）的，所以当年Gartner总结RPA三大类关键技术时，明确把“Integration via UI”作为第一项。

这一项，是RPA优势和劣势的根源。

先模拟个场景。

员工A对技术部的开发工程师小z说：”我有个需求，要从X系统下载报表，没接口，只能页面下载。下载的数据还要整理一下，最后邮件发给别人，每天一次。虽然每次只花10分钟，可天天重复做，我都要烦死了。”

小z说，小case，我分分钟给你搞定，随即用某语言（Python最近很火，就它吧）实现了一个小程序，程序就在A的电脑里运行，运行一次只要几秒，A很高兴。

员工B也有类似的需求，小z处理方式也类似，绝大部分代码只要ctrl+C/V就ok了。员工B甚至比A还高兴：“程序做的又快又好用。z哥威武！”

过了段时间，A找小z，“现在有新要求了，邮件发送从一天一次，改为上下午各发一次”。小z很快就改了程序。

B也找小z，"z哥，老板要求，邮件cc给他，并且一周一次就行，在工作时间发啊。"

小z有些苦恼，“算了，我做个任务调度器，你们自己配置程序运行时间吧。”

这时，C也找小z，小z说：“明白了，我把这个小程序运行的管理能力放在服务端，这样大家都能用。什么，你的程序只能你自己用？好说，我加个权限管理就OK了。啥？你也用发送邮件功能，好好，我抽象个邮件组件，大家公用，我也省事。还要看看发送成功了没有，没问题，我加个日志。卧槽，还要操作excel？还有啥？？？”

为了满足大家的要求，小z最后一个做了一个完整的工具，有任务调度、有权限、有日志，甚至还做了个“拖拉拽”的流程编排设计工具，而这，基本就是rpa的雏形了。

这个场景熟悉么？反正，当年某熟人（非朋友）遇到的就是类似问题。

大概体会一下：

• 员工A、B、C都有重复性的工作。小z为了满足众人的需求，最后做了一个比较完整的系统；
• 这个完整系统现在不用小z做了——RPA厂家已经提供了，小z只要开发机器人流程（bot）就行，这就简单很多了，小z也轻松了；
• 甚至A、B、C自己就有可能开发简单的bot了，就没小z啥事了。

也有些深层次的问题：

• 小z是自己公司的人，才能及时应对A、B、C的需求变更；这变相说明，RPA卓越中心的重要意义，因为谁也不想上生产的系统出问题，除非说自己的工作不重要；
• 不是的话，厂家/SI也应该想办法把客户的某个人变成小z，至少让客户有维护的能力，特别是大客户；
• 流程尽可能短，并且bot对接的系统中，多数方（甚至是绝大多数）的变化是可控的，这样运维的时候问题会少很多；

如果公司觉得小z干的不错，让他去运维RPA，可能出现的场景：

• 小z在短时间可能会很喜欢RPA；
• 长期让他做rpa开发，就有难度了——开发rpa流程（特别是短流程），某种意义上也是低端的、重复性的工作，说穿了，RPA就是一个低代码开发平台，uipath都提出”人手一个机器人“的概念了，他能高端到哪儿？某大行省分行负责PRA实际开发的人，已经换了好几茬了，都是主动要求换岗的，注意，不是升职了，只是同一技术部门换岗而已。