RPA实施过程中可能会遇到的14个坑

RPA的实施过程并非如我们所想的那样,总是一帆风顺。
碰坑,在所难免。但也不必为此过于惊慌,因为,我们已经帮你把RPA实施之路上的坑找了出来。
RPA实施过程中,将会遇到哪些坑?

【不看全文大纲版】
●组织层面:
1-缺乏当地团队的时间承诺
2-缺乏领导力支持
3-缺乏IT支持
4-缺乏分析/数据功能的支持
5-缺乏人力资源支持
6-责任划分不明确
●流程层面:
7-选择了对业务影响微不足道的流程
8-选择了涉及更高层次认知任务的流程
9-选择了一个子流程很简单但流程本身很复杂的流程
10-选择了存在更好自定义解决方案的流程
11-当成本效益不高时,努力实现端到端自动化
●技术层面:
12-选择需要密集编程的解决方案
●实施后:
13-可扩展性
14-维护

【1427字全文版】
组织层面:协调是任何项目成功的关键
组织的协调性至关重要,特别是在缺少外部实施合作伙伴的项目中。RPA实施的顺利与否,需要本地团队和领导层的全面掌控,高层管理人员定期审查进度。本地团队将花费大量时间自动化流程,以获得战略等部门的协助。
考虑到RPA机器人有可能创建大量数据,团队领导者可以在实施早期考虑关于机器人创建的数据格式,频率和其他重要决策。如果企业没有投入足够的资源和管理层注意力,或者没有明确责任,那么在具体实施RPA项目中可能会遇到挑战。
不要忘记从这些关键部门中获得支持
IT:在选择RPA解决方案之前,需要检查IT路线图。另外,IT部门还可以充当其他部门在RPA技术采购决策中的协调人。如果企业中已经有过RPA的实现,那么IT部门应该及时总结相关经验,以帮助其他人员学习。
HR:人力资源对于RPA培训计划能否顺利实施很重要,否则其可能永远不会在企业培训计划中占据一席之地。RPA培训可以帮助员工更好地了解和掌握RPA的操作,有助于减少组织对RPA顾问的依赖,同时还可给员工赋权。

流程层面:能否成功部署,就看它了!
理想的用来部署RPA的流程应该是,业务量大、简单的、不涉及高级认知层面、有影响力且不需要自定义解决方案的流程。

RPA项目对于业务量小、影响力较低的流程几乎没有实施的动力。具有高业务影响力的流程往往都具有高成本属性,并且还会触及到大量客户,这些对企业业绩的影响也非常大。这样的流程才能让RPA施展开拳脚。
没有明确定义、规则的任务通常不适合自动化。目前阶段,RPA机器人还无法胜任高级认知任务,它很难解释什么是一个好的广告形象,如何与客户沟通。这些需要人工智能技术才得以逐步实现。而那些如添加数字、复制粘贴等的低级认知任务,才是RPA机器人的最爱。
自定义解决方案往往优于通用解决方案,但单独为某一公司的某一流程部署RPA的解决方案,往往需要耗费更高的成本与时间。
全流程实现自动化绝对是个很棒的想法,尽管企业需要为此付出更多的成本。
目前,企业的许多流程可以实现70-80%的自动化。但是,随着自动化水平的提高,企业将会面临逐渐走低的回报,而那些完全自动化的流程可能会比部分自动化的流程高出五倍。当然,这并不绝对,一切还是要以企业具体的业务情况为实施依据。

技术层面:RPA是一个不断发展的领域,不要购买过时的解决方案
如果在经济条件允许的情况下,没有企业不愿意使用最先进的技术。
RPA技术正处于一个上升期。从起初需要大量编程的解决方案,到如今的自学习或低代码/无代码RPA解决方案,RPA的进化远比我们想象的要快。乘着人工智能技术的快车,未来的RPA还会转向智能自动化(IA),并更好地实现自主性及认知性。

当企业将RPA的实施外包给了顾问或BPO时,要注意这里面可能存在的利益冲突。可编程RPA解决方案往往需要更长时间才能实现,所需要的资金也会相应增加,但是如果使用无代码解决方案,则可能会省时省钱的多。

实施后:后续工作对企业数字化转型亦很重要
●可扩展性
可扩展性是一个被广泛注意的问题,特别是那些希望扩大其RPA实现规模的大企业。管理RPA安装的复杂性会随着机器人数量的增加而迅速增长,机器人遇到的问题以及受机器人影响的流程也会增长。确保机器人在实施后进行审核,简化机器人体系结构并逐步实现自动化,有助于促进RPA安装的管理。
●维护
维护是RPA实施后面临的最重要挑战。监管或商业环境的变化迟早会倒逼企业改变机器人的部署。由于大多数机器人都已编程,因此遵循软件编程中的最佳实践可以相对轻松地维护机器人。尽管如此,需要对变更进行优先排序,并且需要将必要的工作用于机器人维护上面。

原文地址:https://blog.51cto.com/14319181/2392222

时间: 2024-10-12 22:47:55

RPA实施过程中可能会遇到的14个坑的相关文章

学习编程的过程中可能会走哪些弯路?

整理自知乎问题:学习编程的过程中可能会走哪些弯路,有哪些经验可以参考? @Crossin 回头看学生时代,最大的弯路就是怕走弯路.想不走弯路. 纠结该学什么语言.该研究哪个方向.该做项目还是啃算法,生怕一失足成千古恨,踏上一条不归路. 很久之后才发现,与其纠结选择,不如找个点坚持下去.好比爬山,你在山脚下纠结该从哪条路上去,而实际上,每一条都能通往山顶,每一条都不会是笔直平坦的.你怕错过另一条路的风景踟蹰不前,却不知道只要登上山顶就可以一览众山小. 如果一定要说个经验教诲,那就是尽可能多地写代码

BI实施过程中的工具与服务

成功的BI项目,不仅仅是应用了BI工具软件,还要具备完善的BI服务体系,才能称之为真正成功的商业智能bi项目. 现在的BI(商业智能)比起几年前的ERP一样,成为CIO们关注的焦点.在ERP等基础信息系统部署完之后,企业能够对其业务数据进行更为有效的管理,如何利用这些数据创造价值成为企业下一步思考的问题.在这一背景下,BI被提上日程.与操作型系统ERP不同,BI是分析型系统,利用BI分析的结果给企业带来商业价值才是BI系统实施成功的重要标志. 2008年,某著名品牌饮料公司宣布其以应用分析系统建

IT实施过程中如何管理业务需求

目前,大多数企业IT建设与管理都滞后于业务变革,更谈不上引领企业发展了.对于这些企业而言,IT对企业业务的支撑或者说推动,是由业务需求到了一定程度来决定的.总的来说,企业的IT发展将取决于业务需求,而不是IT投资. 企业的常规做法是比较典型的交钥匙工程,业务部门提需求,IT部门就去张罗方案论证并组织实施,业务部门最后验收评价和使用,IT部门负责系统维护和更新.这样做的结果往往是系统不好用,不适用,或者跟不上业务的发展,业务部门不愿意用,最终成为摆设,浪费了投资,而带来的唯一好处可能是给企业相关人

那些年,我们在学习编程的过程中可能会走的弯路!

学习编程可能没有捷径,但一定是有弯路的,按危害程度,依次为: 1.不上机. 2.死磕“经典”. 3.玩鄙视链. “不上机” 这个毛病我都不想多说了,野生程序员 - 收藏夹 - 知乎 里多个回答都已经说过很多遍了.不管你是看书还是看视频,正确的姿势都是左边翻开教科书,右边就同时打开电脑——把代码敲进去,把程序跑起来啊!在书上画叉叉圈圈有个毛用!? @姚冬 的说法我觉得特别到位:编程本质上是门手艺.三天不练手生,手艺是练出来的.你当然要看书,但绝对不是只看书就够了. 自己上机过个手,首先能发现问题,

如何在项目设计与实施过程中改变老板?

与其说习惯是最难改变的,还不如说人是最难改变的.人们多年养成的习惯,谁会轻易改变?对于一个相对成功的企业老板而言,企业规模日益扩大.员工数量不断增加.荣誉等身,更关键的是市场征战多年一路走来多以胜利告终,奉迎吹捧的人环绕身边,自信自负理所当然.想要改变老板在多数员工看来都是一句话:"难!,我看难!"对于习惯了靠个人能力管理企业的老板,要改变他真的很难.但是,如果不改变老板单打独斗的习惯.不改变老板"一言堂"的作风.不改变老板"事无巨细亲力亲为"的

记录LNMP多主机架构Wordpress博客实施过程中的一些坑

**首先来介绍一下LNMP** LNMP就是:Linux系统下Nginx+MySQL+PHP网站服务器架构 Nginx是一个高性能的HTTP和反向代理服务器,也是一个IMAP/POP3/SMTP代理服务器. Mysql是一个小型关系型数据库管理系统. PHP是一种在服务器端执行的嵌入HTML文档的脚本语言. lnmp都是免费开源软件,组合到一起,就是一个免费.高效.扩展性强的网站服务系统. **整个框架我们可以部署的方式有以下几种**: 使用rpm包逐个主机进行安装及部署: 使用编译源代码的方式

书写sql过程中可能会遇到的问题

1.这种写法不安全,可能有sql注入的情况: 可以这么写: 原文地址:https://www.cnblogs.com/Yanglei-Faith/p/10411521.html

记一个在训练模型过程中自己给自己挖的坑

根据一个图像拼接和融合的需求,训练一个模型,输入为一组图像,输出为一张图像,输入数据和ground truth的像素值都归一化到[-1, 1] 我当时使用了UNet结构,卷积和反卷积都单独封装了一个函数,方便调用,在函数内部,卷积都会默认接一relu激活层 训练结果出来后,发现内容基本都能和ground truth对应上,但是颜色很怪异,特别接近灰色,如下 然后寻找原因许久未果,陷入纠结.第二天开始思考修改网络,猛然发现,我希望最后一层的输出为[-1, 1],但最后一层卷积默认接了relu激活层

研发环境容器化实施过程(docker + docker-compose + jenkins)

目录 背景介绍 改造思路 容器构建 基础准备 中间件容器 外部依赖容器 业务应用容器 容器整合 自动构建容器 Maven相关 非Maven项目 总结 背景介绍 目前公司内部系统(代号GMS)研发团队,项目整体微服务规模大概是4+9+3的规模,4个内部业务微服务,9个是外部平台或者基础服务(文件资源/用户中心/网关/加密等),3个中间件服务(数据库/Redis/Nacos). 分为2个组,迭代周期为2周.需求和排期都是会有交叉,会保证每周都有迭代内容交付,另外技术部门也在进行性能优化以及代码规约的