“为什么部署RPA前要进行POC？RPA不是开箱即用吗？”
其实，RPA的实施并非总是一帆风顺，“碰坑”在所难免。
据安永报告显示，30%至50%的初始RPA项目都以失败告终。
之所以会出现这种情况，是由于企业在部署RPA的过程中，碰上了“实施砖墙”。
而在部署RPA前进行POC，则有助于提高RPA项目的实施成功率和可扩展性，以便更好更快地部署RPA。
POC是什么？
概念验证
（Proof of Concept，POC）
POC是一种有效的方法，可根据用户对RPA项目的具体要求，在指定的业务场景，通过对编写好的脚本进行测试，发现其局限性并提供反馈，以提前排除隐患，确保机器人能达到预期效果。其关键特点是匹配用户真实的业务场景。
可以说，POC是企业部署RPA的必经环节，企业需要POC来确定业务流程在技术上是否可行。
尤其对那些尚未部署过RPA的企业而言，RPA到底能带来多大影响，能否达到预期效果，这些都无从考证，因此更需要在部署RPA之前进行POC验证。
根据用户要求，POC大致分为两类：
01 短周期POC
周期短的POC，客户需要在短期内迅速地看到RPA的成效，这种类型的周期在2-4周内，甚至1-2周。
02 长周期POC
周期长的POC，这种类型的项目周期在4到6周左右。虽然是POC项目，但是项目的规模、周期同普通的RPA项目没有区别。
为POC选择正确的流程
RPA项目的失败大都源于选错了流程，即选择了那些过于复杂、变化多端、业务价值低的流程。那么，POC时选择什么样的流程比较合适呢？
POC的理想候选流程类型：
大小合理 | 尽量选择从效益高的小流程入手 |
相对简单 | 选择不太复杂的流程，避免流程分叉 |
基于规则 | 选择操作规则固定明确、有特定程序的流程 |
重复成熟 | 选择高度重复、成熟稳定的流程，节省时间和成本 |
业务量大 | 通过大量业务测试，可确保稳定的投资回报率 |
跨系统 任务 | 选择需要用户访问多个系统才能完成的任务 |
结构化 数据 | 选择结构化数据多、有稳定数据库的流程 |
快速见效 | 选择能快速产生高投资回报的流程 |
建立和执行POC的步骤
01 规划
制定业务方案，其中应包括概述目标、成功标准（KPI）、项目范围、ROI预期、预算。
02 评估
选定业务流程后，需要对该流程中的业务进行简单的梳理和分析，初步判断是否可以进行POC。主要评估依据：业务规则是否固定、技术是否无法实现。
03 流程准备
对业务流程执行进行详细走查，删除过时、无关或多余的步骤。可借力流程挖掘软件查看流程真实状态，提前发现瓶颈。
04 技术准备
建立技术环境以支持POC，这包括：安装POC所需RPA产品的电脑，确保执行流程的相关网站和系统可以访问等。
05 开发
开发POC所需的代码。预先记录流程非常有用，因为它允许开发人员在开发过程中反复检查流程。任务挖掘软件是记录任务的一个很好的选择。
06 结果演示
为用户、关键利益相关者安排并执行自动化演示。验证成功标准，确保达到目标和目的。
POC实施小技巧
01 场景选择
应挑选那些有固定规则、逻辑性强，不需要人工参与，又有大量高度重复的场景进行POC。这样便于用户快速看到成果，有利于后续RPA项目的推广。
02 方案制定
制定方案，首要确定最有可能看到具有积极业务影响的流程。通过ROI（投资回报）分析，挑选最优选择，确保提升实现业务流程自动化的可能性，使其在部署中获得最大价值。
03 后续维护
必须要考虑RPA部署后的可维护性，这是重要测试指标之一。RPA部署必须具备较强的可维护性，RPA操作脚本必须具备参数化调整，同时还必须提供模块化组件，确保在系统调整时能够快速响应。
实施POC是为了更好地部署RPA。若能通过POC快速产生高投资回报率，为企业节省时间和成本，便可增加用户认可度，建立整个企业构建自动化的信心。
