“可行性分析”也是需求分析的一部分，需要根据用户的具体业务流程，结合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）
——本文原创，转载请注明出处
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
