RPA与SAT（软件自动化测试）在技术实现上非常相似。二者最大的区别，其一是服务对象不同，RPA服务于业务，是可以为企业带来直接ROI回报的，所以业务价值高；SAT服务于开发，带来的可能是更好的软件质量这类的间接价值，所以相对的业务价值偏低。

RPA与SAT第二个差异是，RPA运行在生产环境，SAT运行在测试环境。正是因为RPA是直接上生产的，导致有些维护问题会变得更加棘手。

很少有RPA产品公司在宣传自身产品和解决方案的时候会主动提到RPA后续的维护问题。随着RPA在企业内部应用的逐步扩展，维护RPA会变得越来越麻烦。以下几类原因都可以导致RPA无法正常工作：

基础环境：网络连接故障、服务器维护、应用服务器挂起、访问权限丢失、URL更改等原因可以归于基础环境因素。这是导致RPA运行中断最主要的原因之一，如果无法及时找到问题原因，那么所有问题都会变成RPA供应商的问题。

应用变更：指RPA与之交互的应用，修改了或更新了，而且变更的内容导致RPA机器人元素识别出现异常。C/S应用更新后安装了新的本地客户端，B/S应用更新后浏览器显示出了不同的UI，那么很有可能需要维护RPA流程文件（或者也可以这么理解– 需要修改生产环境上的RPA流程源代码）。

• 【有时维护是高效的】：有熟悉的RPA技术人员，可以直接在生产环境操作，受影响的业务流程少，那么有可能仅仅需要几分钟就可以修复中断的RPA机器人。

• 【有时维护是痛苦的】：产品业务流程可维护性差，RPA技术人员对流程不熟悉，受影响的业务流程数量还不少，而且无法直接在生产环境上操作。最极端的情况是，生产环境已经应用了新版本，测试环境没有部署，又无法直接上生产操作，想想就头疼。这样的情况，没有半天一天，根本搞不定。

输入格式：有时前置输入格式错误，往往导致后续任务失败。因为RPA机器人是严格按照逻辑规则步骤执行的。

软件死机：RPA软件产品自身奔溃死机，导致的中断。解决问题的方法不复杂，往往是通过重启主机，但如果这类故障率高，那么RPA产品的可靠性问题就很严重。

在以上举例的几类问题中，最难维护的还是“应用变更”问题，因为只有这类问题才需要修改业务流程。而且，需要重点说明，一旦出现异常，异常恢复前工作了一半的流程如何继续，也是非常考验RPA产品和RPA工程师能力的地方。

克服RPA维护的痛苦

如何确保自动化流程的业务连续性。

RPA带来了全面的变化，改变了现代企业对每个关键业务流程的看法。事实上，Gartner预测，到2024年，大多数组织将能够通过重新设计流程和实施自动化技术，将其运营成本降低多达30％。但是，由于预测到的对自动化技术的高度依赖，重要的是，企业应制定应急计划，以应对意外情况和错误情况。这就是RPA维护发挥作用的地方。

确保业务连续性

麦肯锡公司表示，有88％的企业希望实施更多的机器人自动化技术，但往往不知道从哪里开始，尤其是在确定哪些流程应该首先实现自动化时。在考虑从何处开始其自动化策略时，公司通常会依靠最复杂且对业务至关重要的任务-但这是错误的方法。

在过去几年中，最成功的自动化项目已经通过自动化一些具有最小业务连续性风险的简单流程（例如薪资等HR流程）来开始其自动化之旅。但是，随着企业希望提高其自动化水平，他们必须清楚了解其流程和业务重要性。在此阶段，企业应寻求进行彻底的业务影响分析（BIA），以便他们可以了解与某些流程的自动化停机有关的风险，并在出现问题时采取正确的响应和维护协议。

组织应该为每个自动化流程设定关键的恢复时间目标（RTO）；那是使流程恢复正常运行所需的时间。这应考虑到执行过程的特定时间。

其他重要的考虑因素包括查看流程停机将在多长时间内导致对企业的财务或声誉影响。这里的业务挑战是资源。数字工作者为内部IT资源增加了另一层复杂性。实际上，最近一项针对RPA的影响的研究发现，有41％的受访者表示，机器人程序管理所花费的时间和资源比他们预期的要多。因此，当企业缺乏内部资源来维护其数字化劳动力时，就会出现一个挑战。

弹性维护

当组织希望扩展其自动化时，就会出现另一个挑战。RPA应该始终与组织的长期战略目标联系在一起。应该将其视为帮助企业实现其总体目标的工具，而不仅仅是试图解决流程中损坏的部分的短期解决方案。因此，不可能在同一业务中建立单独的RPA项目，但在各自为战的情况下，对帮助业务实现其总体战略目标很有用。

因此，组织应该自然而然地寻求扩大规模。这是第二个RPA维护挑战出现的地方。组织应如何看待扩大其实时数字化员工队伍的维护？

一种选择是利用负责实施自动化的开发人员的交付团队。尽管这是维护方面的有效选择，但并非没有风险。这是因为一旦他们成功交付了5到10个自动化功能，他们的角色就会从实际成为开发人员的角色转变为全职RPA维护者。这限制了他们开发和交付新自动化项目的能力，并且可能导致其整个业务计划陷入停滞。

管理–>合适的团队

有证据表明，最成功的自动化项目是在规模上进行自动化，但是在内部完成规模化自动化会导致巨大的维护成本。简单的从若干个人RPA开发工程师，升级为RPA共享服务团队，亦或更高层次的RPA卓越中心。

如果希望规划部署RPA战略，创建合适的团队，无论是自建团队，还是使用外包团队都需要优先考虑。

产品–>提升产品可维护性

产品易用性强，业务流程框架清晰，应用模型提升可维护性。

举一个关于国家税务局网站例子，假设企业有5个不同的税务流程需要到税务局网站操作，脚本模型自动化需要分别修改5个流程文件以适应可能而来的税务局网站升级。应用模型可能仅需要修改税务局网站模型，而无需分别修改5个流程文件。