RPAに適した業務、適さない業務は?

2020/07/31 コラム



 RPAによる自動化を検討する際に、いくつかの観点でRPAによる自動化をすべきか、他の自動化の手段を検討すべきか、あるいはアウトソースに出すのか、派遣社員を雇ったり従業員がやったほうがいいのか、という件等を行うことになる。その際に検討すべき事項や一般的な判断基準について見て行こう。

 

検討すべき項目

以下の点を順番に検討していくとよいだろう。

  • ソフトロボットによる操作が可能か
  • 人間の判断が必要か
  • 業務の全行程がデジタル化できるか
  • 汎用製品・サービスや他の自動化手段が存在するか
  • 業務の適用規模
  • スピードとアジリティ
  • 複雑すぎないか
  • 社内人材が確保できるか

 

ソフトロボットによる操作が可能か

 RPAを活用する出発点として、ソフトロボットによる画面操作ができるかどうかはまず検討すべき内容である。これができないと、そもそもRPAの活用ができないからだ。

 たとえば、そもそもパソコンの画面内で収まらないことにはRPAは使えないし、OSWindowsにほぼ限定される。MacLinux、スマートフォンやタブレットを使った自動化を行いたい場合は特殊な場合を除いてRPAは使えない。

 加えてRPAでは操作が難しい類のソフトウェア (リモートデスクトップや一部のソフトウェアなど画面要素が分解できないもの、複雑な描画を行っているソフトウェアやウェブページ)RPAには向かない。

 

人間の判断が必要か

 業務の工程で、得られた条件を論理的に処理して条件分岐をさせれば完了できるものは、RPAによる自動化処理に向いている。逆に明確なルールを明文化することが難しく、人間がファジーに判断する必要があるものは、RPA単体では処理できない。

 ただし、ここは自動化に対する考え方次第であり、人間の判断が必要なところだけは抜き出して人間が判断し、他の部分はRPAで自動化を行い、受け渡しのインターフェイスをうまくつくることもできる。自動化するかどうかは必ずしも01かの問題ではなく、中間も選択肢としてはあり得ることを認識しておこう。

 

業務の全行程がデジタル化できるか

 これもRPAを適用するうえで効率や複雑性にかかわってくる。デスクワークの場合、特に多いのは紙業務であり、パソコンの外側で書類の処理を行っていたり、捺印が必要だったりするものは、AI-OCR等を組み合わせたデジタル化ができるかどうかがカギとなってくる。ただし、これも紙があるからRPAが適用できないという01かの問題ではなく、中間も選択肢としてはあり得る。

 

汎用製品・サービスや他の自動化手段が存在するか

 自動化処理がどの会社でも行われている一般的な処理、かつ汎用製品やサービスが提供されている場合、自分たちでわざわざ自動化を組むよりは汎用品を使ってしまったほうが早くかつ安い場合が多い。会計処理や業務の処理も、自分たちのやり方を変えずにITのしくみを無理やり合わせる方法も過去には取られていたが、カスタマイズ費用がかさむ割りには、それが自社の差別化につながらなく投資対効果が悪くなってしまうケースが多かった。

 汎用製品やサービスは、その分野でのベストプラクティスが集積されたものなので、なるべく汎用品をそのまま使い、どうしても手が届かないところだけカスタマイズをしたりRPAで自動化をするという方針にすることが望ましいだろう。

 また、製品によってはマクロなどの自動化機能を備えているものもある。その場合は、その製品内だけで自動化するのであれば、RPAを使わなくても実現で切れる場合があるので検討するとよいだろう。

 

業務の適用規模

 RPAによる自動化が可能な業務であっても、同じ方法で対応できる業務量や範囲が狭い場合は、投資をする割には大きな効果が得られないという結果になる場合が多い。理想的には組織内でトップダウンでRPA適用業務を探す作業を行い、その際に似た業務は標準化をするプロセス (BPR: Business Process Re-Engineering)を入れることが望ましい。

 その結果、適用業務量が多くなった業務から優先順位をつけてRPA化していくと、投資対効果の高い結果が得られる可能性が高いだろう。

 

スピードとアジリティ

 今日のようなコロナ禍でのリモートワーク、事業継続対策が求められる環境では、突発事項への対応が求められることが多いだろう。その中で自動化できるものはしてしまい、従業員はより本質的な業務を行うことに集中すべきである。RPAはそのようなスピードが求められる自動化構築に向いている。多くのRPAの事例で、自動化の構築にかかる時間は早くて数日、多くは2週間~1カ月くらいでアジャイルに稼働できる。

 一方、ウォーターフォール形式のプロジェクトでシステムをきちんと構築するとなると数カ月から年単位での対応となってくるため、どちらの手法が良いか検討するとよいだろう。

 

複雑すぎないか

 RPAはITの専門家ではなく、業務を理解している現場のユーザーが取り組めることが特徴となっているため、ロジックがあまり複雑になりすぎるものには向かない。RPAソフトは、ロジックをフォローチャートで表しているものも多いが、その場合、たとえばIF分が23回入れ子になると、それだけでフローチャートがとても複雑に見えてしまう。

 加えて、シナリオのステップが多すぎても、メンテナンスの手が負えなくなる。ステップは多くても1つのロボット当たり50100程度に留めておくのが良いだろう。

 

社内人材が確保できるか

 これもとても重要な事であるが、RPAITの専門家だけでなく、いかに業務を知る現場ユーザーを巻き込めるかが成功のカギとなる。これを行うには、現場での協力者、それからプロジェクトが複数部門にわたる場合は、コミュニケーション能力にたけた人材を確保しておくことも重要となる。このようにツールの使い方にたけた人材だけではなく、業務を知る人材、コミュニケーションを取る人材など、RPAプロジェクトに必要な人材を社内で継続的に確保できるか、協力が得られるかということがとても重要になってくる。

 

 また、RPAツールによっては外部からのIT専門家の支援が継続的に必要になるケースもあり、運用の仕方に注意が必要である。