乱写RPA

要写在前面的是，企业上RPA是一个大趋势。我仍然十分看好RPA的未来。

只是一直以来的RPA从业生涯中，遇到了种种问题和困惑。

在这里想到哪写到哪。

只求达意，不拘文法。

 

RPA的目标是降本增效，但实际项目中常常变成增本增效的结果。

首先说增效。
它毫无疑问提高了企业员工的能效。
其它条件相同的前提下，具备RPA能力的企业肯定可以处理更多的工作。
但问题是，将同样的资源投入到其它的技术提升中，是否能产生一样多甚至更多的能效？在这个问题上，企业往往有自己的评估和衡量，进而导致企业其实有很多选择。
我能不能二次开发SAP，Oracle，金蝶，用友呢？
我能不能上Python，VBA，甚至更原始的批处理呢？
我能不能上BPM，或者改用SaaS平台呢？
工作方式的改变，有时带来的不是量的提升，而是质的飞越。这种情况下，RPA是否还是企业的首选？
其实UiPath也好，AA也好，官方培训内容其实已经说明了，在没有其它流程优化手段的情况下，才应该最终考虑上RPA。
问题就在于，许多实施商是直接冲着RPA去的，就是常常说的“为了RPA而RPA”，流程优化反而没有很好地考虑。
这就造成，应该让企业质变的时候，不恰当的RPA却让企业进行量变，反而拖慢了质变的时机。

另一方面，RPA机器人常常并未全负荷运行，这导致了算力的浪费。
4核，8核，甚至16核的CPU，8G，16G，32G，甚至64G的内存，机器人能用到的有多少计算资源？
一天24个小时，机器有效处理工作任务用了多少时间？那么空余的算力和时间，则全是浪费的成本。
也就是说作为计算机它本该处理更多事务，但是作为RPA机器人，反而降低了它可以处理的事务量。
从这个角度看，是否应该说它增效了呢？

还有的时候RPA只能让人轻松一点，却未必效率更高。
因为机器处理事务与人工处理事务的逻辑未必完全一致，也没有必要完全一致。
而这些差异的环节，通常会让机器比人类更快，偶尔会让机器比人类更慢。
不过即便机器比人慢，但我们省了人力，就还是有人愿意投入。
有时候是因为企业看重的点并非机器人的快慢。
有时候是我们可以通过简单堆加更多机器，来解决处理速度比人类慢的问题。
毕竟堆机器比堆人要快得多。

假设它是增效的，但这不能代表降本。
RPA常常无法如预期地那样减少必要的员工数量。
很少人的工作可以完全被机器替代的。
而且RPA目前普遍应用粗浅，软件本身的总体购买和长期使用成本未必比人工便宜。
中国不像欧美日本，有许多企业人工很便宜。
便宜到什么程度呢？总裁一个不高兴，可以把副总裁以下的所有人员全部砍掉重新招。
这种情况下，RPA只是可有可无的锦上添花，对企业来说还没有起到非常重大的影响。

而且RPA长期使用，还有不少的运维成本。
不论是自己家的IT负责维护，还是请乙方公司来运维，都存在直接或者间接的运维成本。
所以通常那些已知6个月内界面将发生较大变化的应用，不建议通过RPA来实现自动化。
RPA的客户端通常对软硬件要求较低，但是服务器端就有相对较高的要求。配服务器不用钱？
而且RPA工具本身数据处理能力相对薄弱，只要有数据处理的场景基本上都需要引入数据库，这有可能带来额外的成本。
另外常常用到的高精度OCR，有些项目会有专用的USB Hub/Server等等，这些都有额外的成本。
这些成本不归厂商管，所以厂商不会跟你讲，也不需要跟你讲。
但是你不投入又上不了RPA。
这就是矛盾。
这不是降本，而是增本。
这让RPA到底是降本增效，还是增本增效，变得复杂起来。

那么往客户这边推RPA就比较困难，常常面临诸多问题。
首先是前面提及的人力成本，本来就很低，这样的话RPA的性价比就不那么明显。
RPA主要是针对那些有规则的，重复度高的人工操作。
但是你想，做这些工作的人，是什么水平的人？
这种水平的人，平常能领多少薪水？
你砍掉这个人头，可能并不能省下多少钱。
当然了，有的人会强调RPA不只是省钱这一个好处，它全年无休，不会出错。。。
但是企业并不总是介意这些好处。
毕竟原本做这些工作的人，虽然一天只工作8小时，还要双休和各种假期，还要交五险一金。但反正薪资不高，企业本来就已经可以忍受甚至接受。
那企业为啥没事动这些人呢，吃饱了撑的？
人类天性如此，很难主动欢迎变化。
就算人工处理事务出错了，造成的损失未必很大，甚至企业根本无所谓。
这时候你强调那些不能带来直接经济效益的方面，企业真的会谢谢你吗？
说到底累计节省的FTE要很高，才能产生效益。
基本上要比官方课程推荐的要高很多才行。

RPA行业的生存空间也面临来自多方面的挤压。
有些企业自身也有一定的IT开发能力，在应用推广RPA之前，已经采取了其它的自动化方案。
比如前面讲的Python，VBA，批处理。。。
那么人家就会问，没有RPA的情况下我已经已经实现了自动化，我为啥要用RPA来“重新发明轮子”？
那么企业已有的自动化能力，反而有可能成为RPA推广的阻力。

一些企业采用的是SaaS的方案，买公共的按量计费的服务。
比如一些云端版本的财务平台，CRM等等。
SaaS供应商本身对特定领域的业务已经有长期且深入的研究。
你为了上RPA做的那点功夫，比得上人家长年累月的积累吗？

还有许多人分不清RPA与RDA的区别。
总以为RPA像RDA一样简单。
总以为RPA就是单机的自动化。
不论他是怎么产生这个误解。
这将RPA直接拉入与Python，VBA，甚至批处理的直接竞争。
这是技术的倒退。。。
我甚至见过声称是RPA的自动化项目，其实每一步都用Excel的VBA去处理，只是最外面用UiPath去调用了一下。
UiPath在整个项目中的唯一作用就是启动VBA脚本。。。
然后把这称之为RPA！
然后客户居然还买单了！
有时候不得不承认，客户买单就是真理。
客户不买单，RPA还是RDA，又有什么分别？
可是我想问，你们知道为什么这个项目没有二期吗？
挂RPA的羊头，卖RDA的狗肉，比比皆是。

本质上来说，RPA圈子真正的资深人士还是太少。
有些人或许有多年工作经验。
但对于RPA这种综合了多方面知识的专业技术，还是掌握得不够全面，不够深入。
有些人可能技术很好，会.net开发。
然后不断地在RPA项目中写代码，还洋洋自得。
好像会写自定义组件非常了不起。。。
然而RPA工具本身默认自带的功能，他不去研究，他自己写代码。
真牛逼！

厂商也是，喜欢说自己的产品容易上手。
这样讲字面上也没错。
但是给人营造一种错觉，好像“RPA非常容易”。
考认证很容易，不等于实际做项目很容易好吗！
懂业务的人，基本都不愿意静下心来学习RPA。
毕竟有业务背景的人，职业生涯选择太多，搞RPA来钱太累。
搞IT的又难得有机会去深入学习业务。
但是业务又常常兼职项目经理，项目经理又常常兼职技术架构。。。
所以RPA的潜力有时候都是被技术架构所局限的。
技术已经翻天覆地了，能做什么不能做什么，已经超越了绝大多数外行的想象。
但却由外行来指导内行？
你不翻车你找我，我好好学习一下！

UiPath不是最好的RPA工具。
但是人材匮乏让UiPath成为我们迫不得已的首选。
有钱的企业非常多，RPA工具也不是很贵的企业级软件。
但是你买得起，不代表你用得起。
软件配上了，你的人会用吗？
会用的人你招吗？
你招的人他真的会用吗？
你敢确定供应商不是用RPA工具调用VBA来糊弄你？
说到底RPA厂商还没把国内的社区培养起来。
UiPath也不能说花了大力气培养，但是它来得早，就有先发优势。
人力资源多嘛，有项目的时候你找得到人上。
别的RPA工具不好吗？我看未必。
但是别的RPA工具你常常找不到人用啊！
这就比较头痛了。
过一段时间各个厂商开始发力，社区培养起来之后，人力资源的问题应该会缓解。