RPAにおける「評価・修正」のポイント――「PoC」における確認事項と「導入・構築」に向けての準備：RPA導入ガイド（8）

RPA（Robotic Process Automation）とは何かという基本的なことから、導入するためのノウハウまでを解説する連載。今回は、PoCを受けての「評価・修正」プロセスについて解説します。

[西村泰洋，富士通]

今回の主な内容

• 個別業務の導入パターン
• 導入プロジェクトは並行して進行していく
• 対象領域の再確認
• KPIの設定
• 実行のタイミング
• 次回は「導入・構築」について

　RPA（Robotic Process Automation）とは何かという基本的なことから、導入するためのノウハウまでを解説する本連載「RPA導入ガイド」。前回はPoC（Proof of Concept：概念実証）について解説しました。第8回となる今回はPoCを受けての「評価・修正」プロセスについて解説します。

　RPAの導入は、「全体計画」「机上検証」「PoC」「評価・修正」「導入・構築」の5つのプロセスで進められることは連載第1回から申し上げてきました。全社的な導入であれ、部門導入であれ大きな流れとしては、この5つのプロセスに集約されます。

　ここで連載第5〜7回の「PoC」に関しての解説を踏まえて、「PoC」における確認事項（現在）と「導入・構築」に向けての準備（未来）という視点でまとめてみます。

図表1　「PoC」での確認事項の例

　「PoC」では、「PoC」の前に想定した項目の結果についてYes/Noを確認します。「導入・構築」に向けての準備は今後に向けての検討事項です。プロセス変更は「PoC」前に想定していれば“現在”で、結果として気付いたのであれば“未来”でもあり、ちょうど両者の中間に当たる項目です。

　図表1の「留意点」が「導入・構築」に向けての準備であり、本導入に向けての重要な項目であることから、今回はこれらにフォーカスを当てます。「評価・修正」プロセスは「導入・構築」に向けての準備でもあります。

個別業務の導入パターン

　企業や団体は多数の業務を有しており、全ての業務へのRPAの導入を「用意ドン」で同じタイミングで開始することは不可能です。そこで、「全体計画」からPoCまでの活動を通じて、各業務に対する「導入・構築」パターンを確立する必要があります。実は、これが「評価・修正」のプロセスの最重要ミッションでもあります。

　連載第3回の机上検証でオペレーションフローとして操作の可視化を紹介しています。個別業務の導入パターンの例は以下の通りです。

図表2　個別業務の導入パターン

　業務が可視化されている状況であれば、最初の業務可視化は不要です。文字とブロック図形で見ると簡単そうですが、これらの活動のそれぞれに期間と担当者がいなければ進められません。一例として、「期間」「作成物」「担当者」を示しておきます。

• 期間：ユーザー要求の整理までを3カ月、ロボットの開発を3カ月
• 作成物：導入前後のオペレーションフロー他（詳細は連載第3回参照）
• 担当者：ユーザー要求の整理まで2〜3人（※開発の担当者は規模によって変動）

導入プロジェクトは並行して進行していく

　部門や全社における実際の導入の展開では、プロジェクトが並行して重なるように進んでいきます。

図表3　プロジェクトは折り重なり進行していく

　しかしながら、図表2のように個々の進め方を確立していれば問題はありません。業務の「数」に対しての対策もありますが、これは次回解説します。

　続いてRPAの対象領域の決定に関して触れておきます。

対象領域の再確認

　「PoC」を経験すると、業務の中のデータ入力や照合など、一定の領域でRPAが活用できることが確認できます。

　「全体計画」でもイメージして対象領域を計画していますが、「評価・修正」のプロセスで再確認するとともに見直しも行います。特に「PoC」の影響を受けやすいのは、下記の（3）です。想定していたコストや工数と「PoC」の結果とを比較して評価します。

（1）業務のクラス分け

　業務を大中小や重い／軽いに分けて、小または軽い業務から進める考え方です。

（2）定型業務の洗い出し

　データの入力や照合などのRPAに適している定型業務と、人間の判断や物理的な動作を伴う非定型業務に分けて、前者を優先する考え方です。

（3）予算、工数ベース

　限られた予算や要員であることを前提として、定型的な業務プロセスなどを中心に検討します。例えば、「半期当たりの予算が2500万円であれば、1案件当たり500万円以下で5件とする」などです。

図表4　業務のクラス分けと予算制約の例

　先行企業は、図のような（1）と（3）の組み合わせや、（2）と（3）などを組み合わせて進めています。

KPIの設定

　業務領域の決定とも関連しますが、KPI（Key Performance Indicator）の設定にも触れておきます。

　RPAの導入に関しては、経営的な視点では連載第1回で解説した「リソースシフト」などの目標があります。

　しかしながら、各業務においてまず優先されるのは「業務の自動化」です。より正確に言うなら、業務の一部を自動化することで生産性の向上や効率化を目指します。

　具体的な数値目標や、Yes/Noで判断できる目標があれば、ブレることはありません。KPIの例を紹介しておきます。

1）人の数を基準にする≒作成するロボットの数

　人からロボットへの置き換えは共有しやすい目標の1つです。最も簡単に考えると、「何人の人が何体のロボットに置き換わるか」ということです。例えば、3人が担当しているデータ照合の仕事を幾つかのロボットに置き換えるとすると、ロボットが3体より多くなることはないでしょう。

　ですので、対象の業務に携わる人数か、作成するロボットの数を目標値とします。

2）業務プロセスの数

　業務の中で特定の工程やプロセスをロボットが担当できれば確実に導入効果は上がります。プロセスの数やウエートで測る考え方です。例えば、「20のプロセスで構成されている業務の中で2つをロボットにする」「結果として10％程度の導入を目標とする」などです。

3）業務時間

　「人が1時間かけて行っている仕事をロボット化することで、20分でできる」などの時間や工数を基にして目標を設定します。

4）効果数値

　上記の2）や3）をさらに進めて、効率化や生産性向上の数値目標をKPIとする考え方です。例えば「20％の効率化を目指す」などです。

実行のタイミング

　図表1で「例外処理ほか」を掲載していますが、「導入・構築」プロセスを迎える上での細かい留意点としては、例外処理、エラー対応、実行のタイミングなども気にしておきたい項目です。

　実行のタイミングに関しては、前回までで解説していなかったことから補足しておきます。代表的なのは以下の3点です。

• 人間による実行
  例えば、ある処理の終了を人が見届けて、RPAの処理をキックするなど。現時点では最もポピュラーな実行の形態
• スケジューラーによる実行
  RPAの管理ツールのスケジューラーによる実行、Windowsのタスクスケジューラーによる実行などがある
• イベントドリブン
  例えば、あるアプリケーションの特定のウィンドウが開いたらRPAの処理を走らせるなどのようにイベントに起因する実行

　各業務で導入を進めていく際に、大きな導入のパターンとしては先ほど解説した通りですが、実行のタイミングなどもガイドラインを定めて、当初はできるだけ同じようにした方が展開は容易になりますし、迷うこともありません。

　業務Aでは人がキック、業務Bではスケジューラー、業務Cではイベントドリブンと、業務に合わせて自在に実行するのもメリットはありますが、展開する上では「統一されている」「優先順位が明確である」などの方がスムーズに進みます。

　なお、BPMS（Business Process Management System）と連携できるRPAの場合には、BPMSで実行のタイミングを制御することもあります。

　実行のタイミングを例として挙げましたが、例外処理やエラー対応などでも同様なことがいえます。

次回は「導入・構築」について

　「PoC」の結果や「評価」から「導入・構築」のパターン化ができ、状況によっては「全体計画」を修正するなどして、本導入へと進む準備ができます。

　本連載も終盤に入ってきました。

　次回は「導入・構築」の現場に向かいますが、「どのように開発を進めているのか？」「現場では何が起きているのか？」「先行企業の内製化の状況は？」などの疑問にお答えします。

筆者紹介

西村 泰洋（にしむら やすひろ）

富士通株式会社　フィールド・イノベーション本部　シニアディレクター

顧客企業を全社的に可視化して経営施策の効果を検証するサービスの指揮を執っている。著書に『図解入門 最新 RPAがよ〜くわかる本』（秀和システム）、『RFID+ICタグシステム導入・構築標準講座』（翔泳社）、『成功する企業提携』（NTT出版）がある。