RPA 之术业有专攻篇

在传统的软件开发项目中，业务和技术是相辅相成的，缺一不可。业务搞得再明白，技术实现不了，或者，技术水平再高，业务搞的一团糟，都是不行的，最终都无法顺利的完成项目。

只不过传统的开发项目中，二者的分工比较明确。业务这块有其的领域性，需要有一定业务背景的人员（BA）参与。技术这块也有一定的专业性，也同样需要技术背景的人员（SA）参与。二者属于互相配合，协同作战。

但是，有些业务性不是很强的项目，就不需要专业的业务人员（BA）参与了，有些懂业务的 SA 就完全可以独立完成。

那么，在 RPA 项目中，靠业务还是靠技术？

笔者在之前 《企业如何快速打造自己的RPA特种部队》一文中提到过，RPA 项目需要特种作战的打法，小快灵，稳准狠。所以单兵作战能力要强，RPA的从业者就要做到懂技术还要做到懂业务，也就是现在比较流行的复合型人才。

现在市场上存在的一种误区，认为RPA项目比较简单，没有编程基础的人也可以，拖拖拽拽就可以轻松搞定。有些RPA的厂商也存在夸大宣传和广告效应，说业务人员完全可以掌握RPA；还有些说RPA工具就像办公软件一样，大家都可以轻松使用。

有些业务人员也会认为，RPA的项目就是结合业务，将需要的组件拖拖拽拽连接到一起就可以了，也不是很复杂，作为业务人员也可以做到的。这些认识是对 RPA 项目的体系和细节还不是很了解。说白了就是只看到表面，没有看到本质的东西，仅仅掌握了些基本的概念和简单的操作步骤。每一个学习编程的人都会编一段小程序，那会编小程序就代表掌握一门语言了吗?

RPA 工具虽然提供了比较丰富的功能组件，操作步骤也是拖拖拽拽就可以，但这只是最基本的操作方式，也就是刚刚迈出了第一步，后续还有很多步骤来完成。

流程能运行并跑通只是刚刚开始，在开发的过程中，需要考虑到各种各样的特殊情况，考虑到异常的处理，考虑到如何进行上下游数据的串联，考虑到是否使用了最优的方案，并如何将你的代码做到优化，健壮，安全，通用，易维护。 

RPA 项目是遵循软件开发的流程的，有专门的框架，有通用的组件库，有统一的代码存储，有严格的编码手册和编码规范。这些相应的要求或者规范，如果没有在传统软件开发领域实践和沉淀过几年，是很难达到的。

还有一点就是风险意识的缺乏，做高风险的事情都存在绝对的利和弊。例如，股票和期货是挣钱最快的方式，但是如果操作不当，也会赔的倾家荡产。如何在规避风险的情况下还能挣到钱才是最重要的。

RPA 项目也同样面对潜在的业务数据出现错误的风险。对客户来讲，RPA 工具是提高生产效率和正确性最有效的方式，但是如果由于考虑不周或者存在缺陷导致业务数据出现错误，就适得其反了。

不可否认有些业务人员是可以开发简单的 RPA 流程，但是我不确定在没有上述开发体制和经验保证的前提下，业务人员是否对代码质量有充分的信心？是否敢把流程放到生产环境中运行？是否能保证运行中不出现任何的错误？以及在遇到问题的时候，能快速地解决问题？有没有 Backup机制？谁去维护和升级代码？

作为专业的 RPA 团队，我们在国内开展 RPA 项目也较早。其实，我们对于开发人员的要求也是很高的。从 2015 年至今，我也面试过几百个候选人了。要成为我们团队成员的前提是技术开发出身，可以是 Java 或者 C#，有1-3年，3-5 年和 5 年以上工作经验。根据这 4 年多，在工作中的各个方面的观察和考核，我发现真正能做到独当一面的（技术好，业务通），还是 5 年左右开发经验的这一批开发人员。

目前市面上的 RPA 工具都是功能组件和技术实现的结合，短期内是无法脱离技术实现的。由于 RPA 的业务流程不是很复杂，对于有一定经验的开发人员，再加上有一定的流程改善经验，要做到独当一面，不是很难。但是业务人员想要通过掌握 RPA 工具的操作来到达项目落地，在现阶段很难。业务人员的价值更多的体现对业务流程的梳理，然后将这些业务上真正的 RPA需求发掘出来，能准确的反馈给 RPA 开发团队。

还有就是，能做 RPA 和能做好 RPA 完全是两码事。

总之，术业有专攻，让专业的人做专业的事才是正道，才能更好的促进 RPA 这一行业的健康发展。