1. 51RPA首页
  2. RPA学院

RPA 之术业有专攻篇

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

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

RPA 之术业有专攻篇

但是,有些业务性不是很强的项目,就不需要专业的业务人员(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 这一行业的健康发展。

本文转载自微信公众号:流程自动化机器人教程,本文观点不代表51RPA立场。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

联系我们

在线咨询:点击这里给我发消息

邮件:kefu@51rpa.net

工作时间:周一至周五,9:30-18:30,节假日休息