乱写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工具你经常找不到人用啊！
这就比较头痛了。
过一段时间各个厂商开始发力，社区培养起来以后，人力资源的问题应该会缓解。