“可行性分析”也是需求分析的一部分，需要根據用戶的具體業務流程，結合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）
——本文原創，轉載請注明出處
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。
