机器人流程自动化 (RPA) 正在获得认可,尤其是在金融和电信行业,但是我们已经与许多高管进行了交谈,并且也有很多 RPA 失败的故事。最近的一项调查显示,超过 40% 的 RPA 项目未能在以下方面达到预期
实施时间
实施成本
通过 RPA 节省成本
分析的好处
我们概述了导致现实与期望之间存在这些差距的一些最常见的陷阱。我们在下面详细解释这些要点:
组织陷阱:
1-当地团队缺乏时间承诺
2- 缺乏领导认同
3- 缺乏 IT 支持
4-缺乏分析/数据功能的支持
5-缺乏HR的支持
6- 责任不明确
7- 公司缺乏明确的 RPA 战略
工艺陷阱:
8-选择一个经常变化的过程
9- 选择对业务影响不大的流程
10- 选择一个错误成本不成比例的流程
11-选择一个涉及更高层次认知任务的过程
12-选择一个复杂的过程。虽然它的子流程很简单,但如果它的子流程太多,流程本身可能会很复杂
13-选择存在更好的定制解决方案的流程
14- 在不具有成本效益的情况下努力实现端到端自动化
实施陷阱:
15- 与没有足够能力的内部团队一起进行内部 RPA 开发
技术陷阱:
16- 选择需要大量编程的解决方案
17-不依赖RPA市场和其他现成的工具
18- 选择没有展示可扩展性的解决方案
实施后的陷阱:
19- 不为可扩展性而构建
20- 不考虑维护需求
21- 不保护 RPA 特权凭证
组织陷阱:一致性是任何项目成功的关键
特别是在没有外部实施合作伙伴的项目中,组织协调是关键,因为您的组织将负责整个解决方案。本地团队和领导层都需要充分参与,高层管理人员会定期审查进度,本地团队会花费大量时间来实现流程自动化,以获得战略等部门的帮助。
依赖自动化流程的相邻团队也需要提前得到通知和说服,尤其是在自动化开始时,他们应该注意任何问题。
这些不仅仅是与实施相关的问题。 RPA 解决方案一旦推出,就需要进行维护,因为流程会发生变化,以使其更高效、更有效或符合新法规。满足这些维护需求很重要,如果公司没有投入足够的资源和管理注意力,或者如果他们没有明确责任,则可能具有挑战性。
不要忘记从这些关键功能中获得支持
它
在选择 RPA 解决方案之前,需要检查 IT 路线图。例如,如果 IT 计划迁移到 Citrix,这将对所选的 RPA 工具产生影响
此外,IT 可以在其他单位的这些技术购买决策中充当协调者。如果企业中已经实施了 RPA,IT 应该将两者结合起来,并帮助他们从彼此的经验中学习。影子 IT 导致使用无数工具的不同部门导致 IT 成本和数据孤岛次优。
数据/分析
数据/分析是大多数高级领导者的议程,机器人有可能创造大量数据。如果及早涉及分析功能,则可以及早考虑有关机器人创建的数据的格式、频率和其他重要决策。这导致机器人创建有价值的数据,而不是大多数机器人安装中的简单诊断信息。然而,RPA 对分析的好处不应该像我们之前解释的那样被夸大。
人力资源
与人力资源保持一致很重要,否则 RPA 培训计划可能永远不会在企业培训计划中占据一席之地。 RPA 培训对于减少对 RPA 顾问的依赖和赋予员工权力非常重要。
拥有明确 RPA 战略的公司是可持续 RPA 部署的关键
RPA 部署或维护有多种模型。决定公司的 RPA 方法很重要,以确保团队不会浪费时间从一开始就创建 RPA 方法,最终造成多余的责任。正如普华永道报告指出的那样,RPA 卓越中心 (CoE)、IT、财务或负责流程的团队可能负责 RPA 部署。此外,公司可能依赖外部顾问进行 RPA 部署。
流程陷阱:最重要的决定是自动化流程
在选择要自动化的流程之前,充分了解流程至关重要。普华永道的声明和案例研究表明,进行 RPA 试点项目通常需要 4-6 个月,而不是预期的 4-6 周,因为企业对其现状流程没有足够的了解。
理想的流程是有影响力的、简单的、不需要高级认知任务、缺乏定制解决方案并且难以使用非 RPA 技术实现自动化。让我们解释所有这些要点:
业务影响是激发组织的关键。业务影响较小的流程上的 RPA 项目将几乎没有动力。具有高业务影响的流程往往是触及客户的大量、高努力的流程。没有什么比告诉 CEO 我们可以在 2 分钟内而不是 2 天内批准贷款更重要的事情了。
过程应该是容错的,或者这些需要是一个质量保证系统。由于 RPA 机器人依靠 UX 来完成任务,因此当 UX 发生变化时,它们可能会出错。在高度关键的任务中,RPA 可能不是最佳选择。但是,只要通过其他机制(可能包括手动控制)验证导致代价高昂的错误的情况,几乎所有流程都可以部署 RPA。
过程不应依赖于定义不明确的高级认知任务。阅读一封电子邮件,其中解释了许多任务,包括与客户沟通和查看广告图片,对于营销专业人士来说是非常简单的任务。然而,目前这些都不是明确定义的任务,因此不适合自动化。例如,很难解释什么是好的广告形象。这并不意味着这样的自动化程序是不可能的。自动化系统可以使用众包来挑选合适的广告,但成本高、速度慢且难以编程,这在良好的自动化软件项目中并不具备正确的品质。
尽管一些高级认知任务难以自动化,但一些需要大量认知能力的任务正在被自动化。最好在过程级别上查看认知需求。例如,从文档中获取数据并处理该数据需要强大的认知能力。但是,可以通过深度学习以高精度捕获发票。 RPA 工具可以与深度学习插件相结合,以自动化该过程。
赞助:
例如,深度学习解决方案供应商 Hypatos 声称,公司可以通过自动发票捕获解决方案将成本降低多达 90%。您可以查看我们的数据驱动数据提取工具列表,了解有关该主题的更多信息。
过程复杂性是与高级认知任务不同的问题。一个过程只能涉及低层次的认知任务,如添加数字、复制粘贴等。然而,基于不同的输入,可能需要执行不同的指令集。例如,根据用户对问题的回答,不同的部门可能需要通过不同的流程来处理用户的请求。这样的过程可能很复杂,并且很难在不同的场景中提取正确的过程流。
目前,它需要大量的手动流程数据提取、访谈和长时间的试点才能成功地自动化这些流程。然而,对于 RPA 供应商和初创公司来说,这是一个正在进行的研究领域,旨在从日志和视频中自动提取流程数据,以成功实现复杂流程的自动化。我们称这些自学自动化解决方案。称为认知自动化或智能自动化(取决于推广解决方案的公司)的较新解决方案能够观察人类执行的自动化工作,了解所需的自动化并在准备好时接管。我们正在研究此类创新解决方案,并在它们可用时列出它们。
定制解决方案往往优于通用解决方案,而 RPA 是一种非常通用的解决方案。例如,AppZen 的 Anant Kale 最近提到了一些公司如何尝试使用 RPA 进行费用审计。我认为对于存在高质量定制解决方案的流程来说,这是一个很好的例子。没有任何 RPA 解决方案能够像 AppZen 那样深入探讨费用项目。
AppZen 拥有一个欺诈模式数据库,并构建了一个关于人们在哪里以及如何消费旅游和娱乐 (T&E) 的知识层。与自定义费用审计解决方案相比,RPA 解决方案将无法访问任何数据,并且可能表现不佳。但是,管理多个解决方案会带来新的 IT 复杂性,因此最好确保新的自定义解决方案值得迁移。
RPA 并不是唯一的自动化模式。替换旧系统或为旧系统构建强大的 API 接口可以帮助您以比构建 RPA 解决方案更少的工作量实现众多流程的自动化。由于 RPA 系统使用不完善的屏幕抓取解决方案,升级旧系统可提供更快、更准确的自动化解决方案。
有关更多详细信息,请参阅我们关于识别和优先处理流程以使用 RPA 实现自动化的深入文章。
一旦 RPA 展示了它的价值,让组织保持专注就很难了
第一个自动化的过程可能会选择一个健壮的过程。如果这种自动化带来了巨大的价值,所有高级管理人员都会很高兴加入并开始自动化他们的流程。这可能会导致注意力不集中,因为不同部门的需求使 RPA 专家捉襟见肘。与初始试点相比,不太关键流程的自动化提供的价值更少,这可能导致“自动化疲劳”。尽管许多部门花费了大量精力来实现流程自动化,但最终收效甚微。
为了保持组织的积极性,RPA 专家应该专注于数量有限的高影响项目。随着组织中 RPA 专业知识的增加,各个团队将开始采取主动并自动化他们自己的流程。这是理想的状态,因为自动化将改善运营,而无需高层领导投入大量时间。
全过程自动化是可取的,但可能不经济
许多流程可以轻松实现 70-80% 的自动化。然而,随着自动化水平的提高,企业面临的收益递减。完全自动化流程可能比自动化流程高达 80% 的成本高五倍,因为额外的 20% 将需要比自动化高达 80% 所需的代码复杂得多的自动化代码。流程重新设计,让人类参与边缘案例的循环都是以最佳效率运行 80% 自动化流程的解决方案。
实施陷阱:RPA 开发是一项重点工作,依赖于有能力交付的团队
部署 RPA 机器人需要了解流程并对 RPA 机器人进行编程。虽然这些需要数周时间,但它们需要专注。除非组织内有团队有时间进行 RPA 部署,否则明智的做法是推迟项目或依靠顾问来完成 RPA 实施。
技术陷阱:RPA 是一个不断发展的领域,不要购买过时的解决方案,并充分利用您选择的解决方案的全部能力
特别是当您将 RPA 设置外包给顾问或 BPO 时,请记住他们可能存在利益冲突。例如,可编程解决方案需要更长的时间来实施,因此需要更长的计费时间,但是使用低代码/无代码解决方案可以减少编程时间。
银行家,尤其是技术方面的银行家,喜欢吹嘘他们的银行实际上是如何成为科技公司以及他们如何使用最先进的技术。然而,当我们开始讨论他们如何实施 RPA 解决方案时,有些人甚至没有听说过自学习或低代码/无代码解决方案。我们在上面讨论了自学习解决方案,另一个有趣的新领域是无代码 RPA 解决方案。虽然普通的 RPA 解决方案需要密集的编程,但无代码 RPA 解决方案用旨在使 RPA 民主化的记录和拖放界面取代耗时的编码。
RPA 市场上提供的可重复使用的 RPA 插件/机器人,减少了 RPA 开发时间,并使您的团队免于重新发明轮子。确保您的团队充分利用您选择的 RPA 平台提供的 RPA 工具。大多数领先的 RPA 公司都有可重用代码的 RPA 市场。随意阅读我们的 RPA 市场或可重复使用的 RPA 机器人文章以了解更多信息。
最后,使用已在大型部署中证明的机器人可以降低未来出现可扩展性问题的风险。大多数主要的 RPA 提供商都有大型(公司中有 100 多个机器人)部署,因此这应该是一个较小的问题。但是,最好检查您的 RPA 软件提供商的最大部署规模。
实施后的陷阱:这些可能会减慢甚至阻止组织的转型
可扩展性
可扩展性被广泛认为是一个主要问题,特别是对于希望扩展其 RPA 实施的财富 500 强组织而言。管理 RPA 安装涉及根据业务需要启动和停止机器人、管理维护过程、确保错误率是可接受的。 RPA 管理还应该要求非常短的时间承诺,以确保 RPA 的好处得到优化。
随着机器人数量、机器人遇到的问题和受机器人影响的流程的增加,管理 RPA 安装的复杂性会迅速增加。确保在实施后对机器人进行审计、简化机器人架构并采用渐进的自动化方法有助于促进 RPA 安装的管理。
鉴于越来越多的 RPA 安装,供应商似乎正在有效地解决这个问题。例如,UiPath 与 IBM、埃森哲、安永和普华永道合作,在三井住友金融集团推出了 RPA 机器人,以自动化 200 个流程中的活动,从而每年节省 40 万小时。每年 40 万小时大约相当于 250 个 FTE,使其成为全球最大的 RPA 部署之一。
维护
维护是实施后最重要的挑战。监管或商业环境的变化迟早需要对机器人进行更改。由于大多数机器人都是经过编程的,因此遵循编程中的软件最佳实践可以相对轻松地维护机器人。尽管如此,仍需要对更改进行优先排序,并且需要为机器人维护付出必要的努力。
RPA 本质上为流程所有者增加了新的责任。虽然他们可能会管理规模较小的劳动力,从而产生更高质量的结果,但他们需要分配时间来管理和维护他们的机器人。
安全
RPA 技术的部署还意味着企业需要保护的另一个接触点。 RPA 机器人需要特权访问权限才能登录到 ERP、CRM 和其他业务系统,以通过流程从一个步骤到下一步提取和移动数据。由于 RPA 软件直接与您组织的业务系统和应用程序交互,它可能会带来重大风险,例如
将特权凭证直接硬编码到脚本或基于规则的过程中
从不安全的位置检索凭据,例如现成的解决方案配置文件或数据库。
请参阅我们关于如何在实施后衡量 RPA 成功的文章。
对 RPA 客户的其他调查也显示公司正在努力应对这些陷阱
福瑞斯特
最近,分析公司 Forrester 对一组 RPA 客户进行了调查,作为其对 UiPath 研究的一部分,并将其结果作为报告发布。我们已经看到突出显示的类似问题
我们无法获得免费文本回复,但第一个问题肯定突出了这些公司面临的实施问题。扩展 RPA 解决方案需要付出努力,而公司可能很难在需要确保业务顺利运行的同时将人员投入到自动化工作中。对于不属于公司最有价值和最频繁的流程的流程,与顾问一起扩展自动化可能在经济上不可行。
第二个问题清楚地强调了在流程发生变化时维护机器人的挑战。明确维护责任是解决此问题的第一步。
最后 3 个问题表明客户对他们选择的 RPA 解决方案不满意。选择最好的可用产品有助于最大限度地减少这些问题。我们下面的内容可以帮助您为您的业务选择合适的 RPA 产品:
选择正确 RPA 软件的最佳指南
最新、最全面的 RPA 产品列表
一旦您选择了您将使用的 RPA 软件,我们将提供选择 RPA 实施合作伙伴的深入指南以及所有 RPA 实施合作伙伴的完整列表。
普华永道
普华永道的调查也强调了类似的问题
资料来源:普华永道
到目前为止,这些都是我经常从战壕中听到的案例。 随着我们听到更多的实施故事,将继续更新。 如果您有其他故事,请发表评论。
既然您了解了 RPA 的陷阱,那么您可以从我们流行的 RPA 实施分步指南中受益。
如果您相信您的企业将从 RPA 解决方案中受益,请随时探索我们的 RPA 和自动化供应商数据驱动中心。
原文:https://research.aimultiple.com/rpa-pitfalls/
本文:
- 登录 发表评论
- 7 次浏览
最新内容
- 5 days 10 hours ago
- 5 days 13 hours ago
- 5 days 13 hours ago
- 1 week 1 day ago
- 1 week 1 day ago
- 1 week 1 day ago
- 1 week 1 day ago
- 1 week 1 day ago
- 1 week 6 days ago
- 1 week 6 days ago