1. 51RPA首页
  2. RPA学院

如何评估RPA需求,RPA需求的模型

大家都知道RPA学习门槛低,用简单到图形界面就可以开发大部分业务流程。虽然RPA开发效率高,拖拖拽拽就可以完成流程开发,看起来比较简单。但开发毕竟是要投入时间和精力的,除非是学习和练习为目的,否则这个流程可能给企业带来不了什么价值。举个不恰当的例子,为了吃鱼这个目标,先包下个池塘,再慢慢养鱼,最后将鱼捞上来再烹饪。且不说整个过程实现的时间周期过长,投入的资金成本也是巨量的。与之相比,去菜市场买一条鱼来烹饪要简单经济并效率得多。

如何评估RPA需求,RPA需求的模型

同理,RPA虽然开发起来是极快的,但依旧需要找到对应的工作包,需要参数配置,需要边开发边测试。这样一套工作下来,比起一次性手工劳作依旧更费时费力的。为了一年1次或几次的工作造一套流程一般是不提倡的。

此外,RPA虽然好,但并不是所有工作都适合RPA来完成的。(妄想RPA帮你写论文,画PPT的朋友们可以一边歇着去了)RPA的工作需要有明确的规则,任何模糊的规则都会使RPA运行错误,甚至压根开发不下去。具体问题接下来会展开来分析。

评估RPA关键词–高度重复的工作

如小标题所示,高度重复的工作(工作仅电脑端,上篇有提,此处不赘述)是RPA最佳实践。具体到我们团队来说,一套流程至少每月一次运行频率,低于这个频率的需求几乎不考虑。这个其实很好理解,如果一套流程开发完,一年都运行不了几次,那其开发的工作量很大程度会高于人去执行的工作量,通俗来说就是亏本买卖。

重复,不仅仅指一个流程每天、每月、每年会运行多少次,还要评估单次流程的重复率。怎么理解呢,我们有不少流程,每个月虽然只运行一次,但每一次运行的工作量特别的大,而对于开发的流程来说,只需写一套完整循环即可,这样的流程也是比较推崇去开发RPA的。

举个例子,我们有一套流程需要下载财务系统Oracle-EBS的资产负债表及利润表。单单是这样两个表的下载,每个月运行一次,是很不值得去开发的。但是,Oracle-EBS并没有批量导出的功能,而集团的分公司,子公司加起来好几百家。

如何评估RPA需求,RPA需求的模型

标准且唯一的操作方式就是一家一家的公司主体去系统中录入参数,提交报告申请,再等系统报告运行完成后,下载报告。注意是每一家,意味着虽是3分钟的工作,但要乘以几百的倍数。每月仅这一项流程,一次运行即可帮人工节省几十个小时。

如何评估RPA需求,RPA需求的模型

同样是因为几百家分公司和子公司这大山压着,税务团队编制报告异常痛苦,每个月虽然只出一份,无奈基数太大,此外税务报告这里还有一个重点,时间紧张,每月有严格的报税deadline。人不能不睡觉,但RPA机器人可以,流程开发完成后,我们每月指定一天RPA连轴运行近20多个小时完成巨量而又紧张的税务报告工作。

对于高度重复的工作,只要单次重复的工作量够大,甚至是不是一个月运行一次或几次都变得不那么重要。我们就开发过一次性流程,没有看错,就是为了运行一次而开发的流程。

当时是有这样一个项目背景,公司的Oracle-EBS系统需要升级,同样升级的还有财务的COA科目,不熟悉财务的朋友可以理解为比方说原来是1-10来计数,后来改成ABCD-XYZ这样方式了,可见影响有多大,整个财务科目都要大换血整理一套崭新的出来。

不仅仅是EBS系统,与之配合的采购系统,也需要跟着“换血”,新的业务还好,直接按照新的科目走流程即可。既有的业务要通过映射规则,把业务旧的科目转换成新的科目。如果采购系统是自家管理,倒也能刷一版数据库,轻松完成。但恰恰这采购系统是外购的SAAS服务(Coupa)。供应商的云平台可不会给你刷他们家数据库的权利。

所有既有业务科目变更换血,必须前台页面来完成,一条一条的”选”,一条费用选出来,A 科目改成什么,B科目改成什么,C科目改成什么,D科目改成什么。。。。。。仅一条费用科目得改10条参数,几万条费用*10,近千小时的工作量,7天的调整期限,几万次的高度重复,这已经不是通宵加班的问题了,手点残,鼠标键盘点废也难以完成。

最终我们RPA团队接下这项任务,通过几个小时的开发,配置几台机器人后,让机器人连轴转了四天”轻松”完成了任务,当然,这套流程任务完成后就没有价值了,即便如此,一次性的收益相比开发任务,也是远超票价的。

如何评估RPA需求,RPA需求的模型

评估RPA关键词–清晰明确的规则

如果说重复率是RPA的黄金指标,那清晰明确的规则就是RPA的铁律。这个如何来理解呢?

机器的工作和人的工作区别在于,机器是听指令干活,人是按照自己的思想来干活。机器人的工作原理很简单,接受指令,执行指令,简单且明了。而到了人这边呢,首先人要去准确的理解收到的指令。正确理解后,还要考虑做或不做,整体的不稳定性比较高。

举个不太正经的例子:

机器人收到指令,把桌面一个销售数据分析报告发送到老板邮箱。

机器人按照既定指令去工作了。选中指定报告,打开outlook邮箱,新建邮件,粘贴附件,输入老板邮箱地址,发送。

如何评估RPA需求,RPA需求的模型

同样的事,人工怎么做呢?

员工收到指令,把桌面一个销售数据分析报告发送到老板邮箱。

在杂乱的电脑桌面好不容易找到报告,打开outlook邮箱,新建邮件,粘贴附件,输入老板邮箱地址,发送按钮点下之前,回想起上个月因为迟到几次被老板扣了好多工资,还当着全部门点名批评。

如何评估RPA需求,RPA需求的模型

怒从心中起,恶向胆边生,鼠标指向右上角那个X,咔嗒点下。。。

↑图为作者对人机工作的理解,若有错误,欢迎拍砖

———————————————————

举这个例子并不是想diss说人工多么不靠谱,而是想说明机器人是绝对靠谱的。即便有不少朋友和我探讨说RPA机器人不太稳定性的问题,但这些case详细分析之后,更多的原因是写入的参数存在一些问题,有些范围指定过死或者过松。

具体如何过死或者过松就聊远了,抱歉关于这个点我要挖一个坑,后续有机会,单开一个话题把坑填上。总之,大家要相信机器人是非常靠谱的就可以了。

机器人的靠谱,源于机器人是严格执行既有指令来完成的,不会由于心情好不好,窗外刮风还是下雨而影响运行过程和结果。但是,问题又又又来了,机器人的指令是谁写的?人。如果人都不靠谱,那人写出来的机器人运作指令能靠谱吗?这真是一个直击灵魂的问题。

我们的最终目标是:靠谱的结果

如何评估RPA需求,RPA需求的模型

如果要靠谱的结果,前提是需要有靠谱的机器人流程,靠谱的机器人流程的前提是要有靠谱的RPA开发,靠谱的RPA开发过程得需要有靠谱的业务需求规则。

靠谱的业务需求规则,就是本小结的标题:清晰明确的规则。(绕了这么大一圈,终于点题了,各位看官辛苦了)

清晰明确的规则,看似简单,但真正去做的时候很容易被忽略。回到这个小标题下面的例子吧:

给老板发一份报告。一句话,这只是一句人话,非清晰明确的规则,更非RPA机器人可以执行的指令。人可以理解,但机器人不行。

如果是清晰明确的规则,这一句话应该怎么展开呢?

在桌面找到销售数据分析报告这份pdf文档,发送邮件给到老板,老板的邮箱地址为:boss_laoban@abcd.com。

如果是RPA机器人可以执行的指令,这句话又要怎样去编译和细化呢?

  • 运行软件:Outlook
  • 动作组件:发送邮件(通过outlook)
  • 发件人:邮箱默认发件人
  • 收件人:boss_laoban@abcd.com
  • 抄送:无
  • 暗送:无
  • 邮件主题:销售数据分析报告
  • 邮件正文:老板好,请查收附件,有任何问题请联系XXX.
  • 附件地址:C:UsersadminDesktop销售数据分析报告.pdf

———————————————————

通过这个例子,不难看出清晰明确的规则是多么重要,如果附件地址错了,发的附件可能变成别的文件;收件人地址错了,可能一不小心重要报告就送给竞争对手;邮件正文黏贴错了,可能就不小心把跟同事发的牢骚一并亮给老板看了。。。

小结

至此,评估RPA需求的两大因素就和大家介绍完了,这两大评估关键字务必牢记。

  • RPA黄金指标:重复率
  • RPA铁律:清晰明确规则

除了这两条,其实还有流程应用对象稳定性评估等一些前提条件,后续会发文慢慢补充。欢迎大家继续关注。

本文是51RPA中文社区原创文章。发布者:RPA小当家,转载请注明出处:https://www.51rpa.net/rpaedu/3291.html

发表评论

电子邮件地址不会被公开。 必填项已用*标注

联系我们

在线咨询:点击这里给我发消息

邮件:kefu@51rpa.net

工作时间:周一至周五,9:30-18:30,节假日休息