要写在前面的是,企业上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工具你常常找不到人用啊!
这就比较头痛了。
过一段时间各个厂商开始发力,社区培养起来之后,人力资源的问题应该会缓解。
原文地址:https://www.cnblogs.com/ybyebo/p/12432258.html