坊间，市下，一直有这样的言论“许多年前，通过自动化测试工具，脚本，大厂提供的自动化接口，早就可以实现这些功能了，RPA的意义究竟在哪？到底是什么原因让RPA火起来了的？”

咱们来说说，到底为什么？

首先，RPA在欧美日先火起来真正的原因是：RPA产品也好理念也罢，真正获得了最终用户的支持。但凡有一线作业的后台业务部门，都迫切希望通过技术改进解放劳动力。我们曾经对比过RPA VS BPM VS 传统软件开发项目，对比表格只是简单列举了一些指标，并没有详细说明。

设想这样的一个场景，业务部门领导希望技术部门帮忙建设一个新的信息化定制系统或者改进现有系统的不足，技术部门的反馈往往是希望用户提出完整的需求（预算当然也由业务部门跟老板申请），并由技术部门负责评估成本，周期等关键因素。传统的IT开发项目经常被这么定义，只要用户能提出完整需求，只要有足够经费和时间，就很少有定制开发解决不了的问题。

传统的IT开发方案需求评估，开发周期，测试周期，上线周期都比较长，传统软件IT项目适合大型信息化系统建设。对许多最终用户而言，软件开发项目太不透明了，到底成本应该是多少，周期需要多久，项目进度怎么把控，需求变更怎么进行。甚至有些案例经过1-3年的项目开发，最后业务领导发现这个并不是他们当初想要的，或者因为时代快速变化，当初的设计已经Out 了。

普通人都是有未知恐惧心态的，对于自己无法清楚了解也无法控制的事情，还不如不做。

所以传统软件开发项目对于业务人员的黑盒子状态极大的打击了业务开发新需求的积极性。而RPA的特性在于对于业务人员友善：快速部署上线，需求变更灵活，低成本，业务逻辑理解比较容易。

低成本还体现在报价透明性，传统的报价模型有一类是根本业务收益来的，比如：某个系统可以帮企业省 1000万，那系统报价500万应该也不过分吧，而RPA的特点是，某个流程可能帮企业省了1000万，但是那个流程的开发成本可能还是 20 万。业务逻辑理解容易的前提是,RPA Studio流程设计便于理解。正因为RPA的这些特性，业务部门就不需要憋大需求，实现日常工作当中的一项项自动化就变得非常有趣了。

我们研究过几个有趣的案例， 某证券公司CFO绕过了IT部门直接在财务部内部建设了一个RPA运营团队，负责财务部业务流程自动化开发、运营和维护。我们姑且不论这种方式是否是最优方案，但是存在即合理的道理相信很多人应该也都听说过。

RPAPlus的观点： RPA是站在业务立场，特别是一线作业的白领立场而带来的劳动力升级改进革命。站在IT 或者开发视角的理解都是有较大偏差的，RPA需要解决的问题有以下这几个：

1-      可以对接日常企业常见的几乎所有系统。

UI自动化技术是王牌，但是目前有些RPA工具对于企业的一些常见系统并不支持，请一定甄别核验。UI自动化是也是分三个层次的，UI 识别 -> UI 读取- > UI 写入，Computer Vison 或图片识别技术是技术选择的下下策； 另一类对接是通过接口， 数据库接口，  web service接口等，RPA工具需要原生支持尽可能多的对接手段。

2-      提供完善的标准化功能

RPA的卖点就是产品化的工具平台，所以，动不动就靠Coding 绝不是主流RPA思路。流程设计、开发、测试、维护标准化，因为RPA不同于传统开发脚本的程序员，必须是企业级可管理的平台。

3-      安全和审计必不可缺

曾听说过一个非常有想法的观点，“RPA会成为企业里面一个可以对接各类系统，进入各类系统的综合工具平台，那如果这个平台本身不够安全，是不是意味着帮黑客打开了一扇大门”。目前大家对于安全性的考虑还不多，是因为我们还没有看到这一类安全事故，防范于未然 。