【実録PoC】毎月数百件以上の文書スキャン業務はロボットで置き換え可能なのか：RPA導入ガイド（5）（2/2 ページ）

RDAのPoC事例　後半戦と結果

　「シナリオ作成」と、実際に検証を行うデスクトップを物理的に分けたシステム構成としています。シナリオ作成と実装から、検証、評価の期間として1カ月を要しています。

図表4　PoCにおけるRDAシステムの構成例

　検証結果としては、下記の2つが挙げられます。

• 「置き換え」は達成できた
• 工数の削減は20％にとどまった

　20％にとどまった理由は、ごく一部にエラーが発生し、それらのトランザクションに関して、オペレーターが目視で検証した後、入力し直したことによります。エラーの原因は、イレギュラーな案件が通常の画面と異なり、それをシナリオに組み込めなかったことです。

PoCの結果から考える

　この事例では、PoCプロジェクトの期間内に、机上検証で期待したほどの数値は出せなかったものの、第一目標である「置き換え」自体は達成しています。

　机上検証で想定した効果を目指すには、例外処理を洗い出してシナリオに組み込むことが必要です。人であれば、例外的な処理も経験や都度の柔軟な対応でこなしています。ロボットには、それらを具体的に教え込む必要がありますが、短い期間では難しいところです。

　一方、「置き換えができて現行以上の効率化ができれば十分」と考えることができれば、「追加情報の入力はロボットにやらせて、人はその後でのチェックとエラー対応処理に徹する」という仕事のやり方もあります。業務プロセスは現行と変わりますが、「割り切り」で業務を楽にすることができます。

　このPoCプロジェクトの振り返りから、今後のRDA導入のロードマップを検討する上では、下記が重要な要素であると分かります。

• 例外処理への対応と、どのレベルまで洗い出すか
• 構築にかける時間と範囲、完成度
• 「仕事のやり方を変えてもいい」と考えるか、「割り切り」ができるか

　これらは、本番の導入に際しても重要な要素となりますが、「全体計画」や「机上検証」の段階で、決め切るのは難しい項目で、PoCをやって初めて気付くことです。

　なお、より大きな視点で見るならば、「今回のPoCで活用したソフトウェアよりも適切なものはないか」（RPAソフトの選定ならびに確認）、「削減できる工数がソフトウェアへの投資に見合うか」（投資対効果）などの検討も併せて行います。

内製化できるのか？

　今回紹介した事例は、導入企業とパートナーが連携して取り組んだケースですが、RDAのPoCであれば、自社のメンバーだけで内製化することも可能です。ただし、RPAは「初物」ですので、下記は、必ず念頭に置いた上で検討してください。

• 必要な場合は、事前にRPAベンダーが行っている研修などを受講して、PoCで使うソフトウェアの学習をしておく
• ソフトウェアの購入などの際に、担当窓口を設定してもらってQ＆A対応が受けられるようにしておく

次回はRPAのPoCについて

　PoCの経験から、その後の本導入に向けた構築を進めていくときに、気を付けなければならない観点があることを理解できたと思います。

　また、あらかじめ、これらを意識した上で、「机上検証」を行うのとそうでないのとでは、机上検証のやり方や結果にも違いが出てくるでしょう。

　今回は、RDAのPoCの進め方や留意点を、事例を基に解説を進めてきました。

　次回は、RPAのPoCについて解説します。筆者も、RPAのPoCを通じて、あらためて「RPAというソフトウェアはどんなものか」を理解できたので、読者の皆さんにも、その体験を共有します。