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 这一行业的健康发展。