这是一篇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这样的工具去适应短期内无法固化的，可能是更好的选择。

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

继续阅读：