“可行性分析”也是需求分析的一部分，需要根据用户的具体业务流程，结合RPA的特性进行具体分析。

1. 业务规则是否明确，未明确的规则或需要人工判断的操作不能使用RPA完成

2. 业务规则是否相对固定

，若业务规则经常变化，也不建议使用RPA开发
，因后期修改维护成本过高。

3. 业务量是否大，重复操作是否多；业务量不大的工作使用RPA性价比不高
。

4. 业务操作是否频繁；业务操作不频繁的工作使用RPA性价比不高。

5. 是否存在需要AI（OCR、NLP等）协同操作的部分；使用AI协同的操作会大大增加项目的不确定性，建议放在后期处理。

6. 是否存在无法识别的内容；若有无法识别的内容需要修改方案绕过该操作。

7. 业务系统是否稳定，业务系统界面是否会经常变化
；业务系统不稳定或界面经常变化，建议暂缓RPA开发的，因不确定性太高
。

8. 网络环境是否稳定；不稳定的网络环境可能导致RPA流程运行失败率升高
。

9.业务系统是否存在难以识别的元素？如SAP或JAVA开发的系统（Oracle、金蝶等）建议先定位测试再开发

。

——（作者

：黄晓明）分享RPA产品的产品特点、项目管理、售前交流
、开发实施等实践经验（欢迎交流）

——【FreeOPA】永久免费
、自动化组件开源的RPA工具（9月发布）；基于我们对RPA的无比热爱，以及自动化技术的钻研分享精神
，我们制作了这款免费软件，旨在和志同道合的朋友们交流
，互相提升。（交流QQ:449145）

——本文原创，转载请注明出处