RPA实施与开发/产品

后台-系统设置-扩展变量-手机广告位-内容正文顶部

这是一篇RPA实施项目中关于自定义开发的探索与阶段性思考。

一、源起

RPA项目实施过程中会涉及到或多或少的自定义开发(Python/VBA/...),一方面确实可以加速项目进程,另一方面也会成为后续运维或优化的定时炸弹。

2019年5月16日参加了北京Tableau大会,看到了敏捷BI软件强大的号召力与未来蓬勃发展的潜力。

RPA项目的人员一直的紧缺的。作为咨询公司,希望聘请的同事都是咨询范儿的,但是RPA实施又确实需要撸起袖子。

中美贸易战+华为被国美列入出口管制的Entity List,国内的RPA厂商都没有放过这个宣传国产品牌的大好时机。

 

与RPA开发相关的,提出两个观点并进行说明(其余观点看法另做文章论述)。

观点1:RPA项目中的开发是一把双刃剑,应该关在笼子里;

观点2:RPA项目是一个赋能的过程,应保持对于变化的适应性。

二、RPA项目中的开发是一把双刃剑,应该关在笼子里

RPA进行Excel处理是非常常见的操作,当处理逻辑稍加复杂,且待处理的数据量稍微多一点儿,那么各路大神便开始各显神通(例如:VBA/.Net/Python/存储过程等等)。

这样的操作可以减少UiPath程序的编码的工作量,缩短项目的总体时间。

可以想象这样一个场景:当某个功能被这些计算机语言(非UiPath)实现,程序的开发者以及项目组成员都觉得“好酷炫以及好有技术含量”(褒义词)

BUT,其实这个“技术含量”可能就是一个大坑。当使用所谓“降维打击”的解决当前问题的同时,也增加了RPA项目的“技术复杂度”。

一旦“技术复杂度”被提升,这些问题需要被思考:

2.1. 人员投入

要求多数项目组成员都新学习新的语言吗?

配置专门的成员解决不同项目的问题吗?

抑或是让各个项目的成员八仙过海各显神通?

2.2. 开发规范

是不是会要求开发规范?IDE?

功能说明文档以及粒度要求?版本管理?命名规范?……

都要来一套吗?

2.3. 后续运维

程序的复杂度越高,运维的复杂度可能就越困难,成本就越高。

试想:Python程序员看到需要运维一堆VBA代码时的心情何如?

擅长VBA的同事发现双表互VLookup的逻辑是通过数据库存储过程实现的会作何感想?

这个时候客户幽幽地走过,问到:不好意思,我也不是催您,不过业务用户真的很着急,请问预计什么时候可以解决?

我想这个时候情绪澎湃的程度一点儿都不会亚于之前“好酷炫以及好有技术含量”(贬义词)时。

2.4. 模式匹配

咨询公司的RPA咨询实施团队(作为RPA市场的主流力量),核心价值在于贴身服务,业务快速理解、咨询建议、方案出具;而维持一个技术团队不是好的选择(一是太贵,二是成员没有发展前景)。

开发公司的RPA实施团队(目前如雨后春笋般蓬勃发展),如果能够基于已有的客户资源和聚焦于特定行业,会有不错的表现。除此之外,RPA实施团队无论是走自主研发的路线,还是走人员外包的路线,个人感觉未来的前景都会比较艰辛。

(关于RPA的模式,本文暂不展开,日后可能专门论述)

2.5. 工具推荐

逻辑处理的问题总要被正视和解决,我们正在引入Alteryx作为可视化逻辑处理的工具。

UiPath+Alteryx+Tableau/Qlik的组合会有非常广阔的应用场景。(这个话题以后可以聊一聊)

三、RPA项目是一个赋能的过程,应保持对于变化的适应性

和远在外地的项目组成员交流,他向我质疑:为什么我们要花很大的精力去做一年才使用一次的流程?仅仅是因为合同的约定吗?

很开心能够听到这样的质疑,我回答道:同意你的观点,我们应该对这样的选择保持警惕,应该有更好的选择的!

反思之余,希望团队能够达成如下共识:RPA项目应该能够为客户赋能,为自己的团队赋能,保持灵活性、保持对变化的适应、保持对未来的可能性。

3.1. 为客户赋能

RPA与Tableau类似的一点:让业务人员自己处理流程和数据。

换个角度论述:为业务用户赋能,把高深晦涩的技术拉下神坛,不再是少数人(IT部门)的专利,而是大众(具体业务部门)普及的工具。

对于业务人员:让自己的流程被自动化,让自己的数据被分析,让自己从枯燥中被解脱,享受在工作中创造价值的快感。

对于IT人员:从辅助支持部门进一步提升,去考虑平台的问题(数据中台/计算中台/AI中台等)、去考虑规范的问题(主数据/集成等)、去考虑业务扩展适应性的问题(微服务/虚拟化等)、去考虑网络信息安全的问题……

让技术以更为民主的方式为企业服务,试图营造全员创新的氛围(所以我们的RPA项目组会不遗余力地为客户做知识转移,以及大规模的培训宣传推广)。

RPA团队成员应该更多地思考如何借助技术创造价值,而不仅仅关注于履行现有合同内容。(事实上,我们大多数的实际落地的RPA流程与业务约定书中的约定并不完全一致。具体原因后续可能有文章论述)

基于上述阐述,程序员们的专业开发语言引入RPA项目,显然需要比较谨慎的对待。

3.2. 为团队赋能

RPA项目需要成员的三种能力:项目管理、方案设计、技术落地。

如何培养团队本文也不打算展开论述,在本文的上下文环境中,提出以下观点:

以上三种能力的培养,最好的方式是在项目中经历,而不是培训教室里学习。

越不容易培养的能力越显稀缺,越有价值。相比于技术落地能力(UiPath开发),方案设计能力和项目管理能力的培养更花时间和更具备难度。

具备技术落地能力(有相关的经验),对于方案设计和项目管理的帮助很大,可以说是必要条件。

让团队快速成长,让团队做正确的事情,这个循环就可以良性地循环下去。(说起来容易,做起来也比较费劲;前途是光明的,道路一如既往的曲折)

站在团队成员赋能的角度,重新审视是否要引入一门新的语言,结论可以各异,但思考的过程是有意义的。

3.3. 保持灵活性

先说结论:我们经历的很多的管理活动,都是在追求确定性;而RPA项目更大的意思可能在于追求对于不确定的适应,以及保留对于变化的可能

比如,做ERP咨询与实施,有必要的环节是业务流程梳理,或者是业务流程再造,就会涉及到业务流程的固化。如果业务流程无法固化,那么后续的系统设计和开发就无法展开。但企业中更多的流程是无法固化的,因为市场等内外部环境是瞬息万变的。当可以固化的流程已经在ERP系统中完成了固化,那么针对无法固化的流程予以灵活应对就显得非常重要了。

再比如,业务部门找IT部门提需求,如果需求总是不能明确,并无法落地成为需求说明文档或者蓝图设计文档,那么后续是无法进行开发工作的。但业务部门人员更多时候应该是:我有一个想法,需要尝试一下;很多可能性无法预料,因为这是一个新的事情。

在Tableau大会上听到:马云爸爸已经进入到养猪行业了。未来无法预知,固化可以固化的,用UiPath/Tableau/Qlik这样的工具去适应短期内无法固化的,可能是更好的选择。

站在灵活性适应的角度,对于自定开发的程序,也要考虑下当前开发的程序,在未来打算如何定位的问题。

未经允许不得转载:RPA中国 | RPA全球生态 | 数字化劳动力 | RPA新闻 | 推动中国RPA生态发展 | 流 > RPA实施与开发/产品

后台-系统设置-扩展变量-手机广告位-内容正文底部

评论

留言与评论(共有 0 条评论)
   
验证码: