かなり前になりますが、本ブログでRPAについて取り上げました。
https://toaruit.hatenablog.com/entry/2017/03/27/014651
それから2年たってRPAの認知度は随分上がり話題になることも増えました。今回は、その導入について進め方など調べてみました。
前の現場とかで試しにRPAを導入しているところを横目で見ていたのですが、まず何といっても対象の業務理解がないとロボットが作れない点。これは他のシステム開発と同じで、RPAだから業務理解が不要というわけではないです。また、ITの知識が全くない人が作れるかというと必ずしもそうではなく、一定程度の素養がある人の方が効率的に作れるし、業務の現場の人がロボットを作る暇がないので、外部に発注したりするケースもあります。それってソフトウェアの開発プロセスと同じじゃね、というのが楽天での導入事例をみると分かります。
【楽天の導入事例で見えたRPAは「ソフトウェア開発」というリアル】
https://thinkit.co.jp/article/15954
下記の記事はNTTドコモで取り組んでいるRPAのソリューションです。記事で触れらていてる通り、RPAは業務効率化の銀の弾丸ではなくあくまでツールの一つとして位置付けられるべきと私も思います。ツールとして扱うには、それを使いこなせる人材がいる必要があります。そうでないと、とりあえずRPA入れてみようという意味の薄い取り組みで、成果が出ずに終わってしまうからです。
【「RPAを主体ではなく1つのツールとして取扱う」現場に特化し、顧客のための改革を】
https://enterprisezine.jp/article/detail/12043
さて、実際にVBAのマクロとかとRPAは、どのような違いがあるか比較したのが下記の記事。実際にRPAが優位な点としては、構築時にそれほど深い技術が求められない点くらいかな。。あとは実際に画面の位置で操作を判断するので、処理プロセスの分かりやすさとか保守のしやすさはあるかもしれません。
【RPAって結局何なのか？どうやって選べば良いのか？】
https://qiita.com/nh321/items/93bfdc9c242e18dd835d
もちろん、私もそこまでRPAを使ったことはないので、他にもRPAの良いところなどはあると思いますが、ちゃんと比較検討してRPAが課題解決に結びつくか検討してみても良いかなと思います。
