社内事務の自動化ツールとして、RPAは効果的な製品ですが、導入・保守の際、いくつか気をつけるべき点があります。それについて、順番に説明していきたいと思います。
今の事務作業をそのまま移植するのはダメ
RPA製品の導入も、上流工程は、通常のシステム開発の予備検討・要件定義と開発プロセスは同じです。つまり、現状事務（AsIsモデル）を分析し、あるべき姿（ToBeモデル）を検討します。その過程で重複のある事務などの無駄なプロセスを排除し、シンプルな事務フローにします。
RPAもプログラミングの一種に変わりないので、可能な限りシンプルな設計にした方が、開発効率もよいですし、リリース後の保守性も高くなります。事務の見直しを全く検討しないまま、RPA開発を開始するのは避けるべきです。
対象業務の重要度によっては、普通のシステム開発が無難
RPAは通常のシステム開発に比べて比較的安価で導入できますが、例えば、Google社のChrome、Microsoft社のExcelといった風に、複数ベンダーの製品にアクセスする技術であることから、やや安定感を欠きます。つまり、各製品のバージョンアップ時の影響を受けることがあり、最悪、プログラム修正しないとRPAが動かなくなります。
業務重要度が高く、十分な費用対効果が期待できる（多額のシステム投資が可能である）のであれば、RPAではなく、システム開発による対応も有力です。
また、費用が安いということは、RPAは開発工数・開発期間が少ないことを意味します。対象業務が頻繁に事務変更されるような特性を持つのであれば、スピード・コスト重視で、RPAの方がシステム開発よりも優位です。
インターネットのWebサイトの参照は、いきなりRPAが使えなくなるリスクあり
例えば、検索サイトの検索結果の一覧を抜き出して、Excelに貼り付ける、といったこともRPAではできます。しかし、RPAは抽出対象の要素の位置・内容を意識して実装していますので、検索サイトのバージョンアップで画面デザインが変更されると途端に動かなくなります。この点に留意してRPAの開発範囲を検討して下さい。
また、社内システムでも開発部署が異なると十分な情報連携が取れないことが多いです。RPAで参照・更新している社内システムを整理し、そのシステムが改修することがあれば連絡してもらう仕組みを作る必要があります。
スポンサーリンク
まとめ
RPAは、通常のシステム開発にない利点がある反面、運用上、気をつけるべき点がいくつかあることをお伝えました。ただ、通常のシステム開発でも気をつけるべき点はたくさんあるわけで、一概にRPA特有の問題というわけでもありません。RPAの長所・短所をよく理解した上で、うまく活用して頂きたいです。
こちら（↓）のコンテンツも参考になると思います。よければご確認下さい。
