1.この記事の目的
いざRPAを導入する！というときにぶつかりがちな「RPAを導入する業務の選定」。
そんな業務選定について、イベント・勉強会などで学んだ業務選定基準や検討の観点をご紹介したいと思います。
備忘録的な内容であり、決してベストプラクティスではないことをご留意の上、お読みいただけると幸いです。
※業務選定の前段階となる業務調査については別で記事を書こうと思っています。
2.前提事項
RPA導入を決める際に、まず最初に認識しなければならないこと。
それは、
RPAは業務改善という目的を達成するための１手段に過ぎない
ということです。
イベント等では常に言われていることですが、まだまだ浸透していないと感じます。
日本では、RPAツールは「なんでも自動化できるもの」と認識されがちです。
実際のところ、2017年～2018年頃に比べてRPAが自動化できる範囲は大幅に広がっています。
それでも、RPAで自動化するよりもよりよい手段があるケースは多くあります。
RPAに囚われすぎると、RPAの導入が目的化してしまうケースが多く、危険です。
などと言いつつ当記事では今後、「自動化」という言葉を「RPA（デジタルレイバーorロボット）による自動化」という意味合いで使用します。
3.業務選定の3段階
業務選定を進めていくにあたり、段階的に判断を行うのが良いでしょう。例えば…
1.自動化可否の判断（机上選定）
2.自動化優先順位の判断（机上選定）
3.実装可否の判断（実検証）
まずは簡易ヒアリングを行い、1.自動化可否の判断
自動化可能と判断された業務に対し、2.自動化優先順位の判断
詳細ヒアリングを経て、設計・開発と同時に3.実装可否の判断
といったようなイメージです。
3-1.自動化可否の判断（机上選定）
業務の簡易的なヒアリングを行い、自動化の可否の判断を行います。
大まかに3つの観点があります。
- 自動化の可否
自動化ができるか。
RPAツールの技術的制約や、業務で使用するシステム・アプリケーションの技術的制約に関する観点が多い。 - 自動化の是非
自動化すべきか。
セキュリティやガバナンスに関する観点が多い。 - その他
自動化に向けての環境があるか
開発環境、インフラ環境の制約に関する観点が多い。
判定基準は現場により多岐に渡るため、以下は一例です。
業務改善の目的に沿った選定基準を検討する必要があります。
| No | タイトル | 観点 | 詳細 |
|---|---|---|---|
| 1 | ルール化できるか | 自動化の可否 | デジタルレイバーに業務を任せるには、その業務を定型のルールにまとめる必要がある。人の判断が必要であるためルール化できない業務や、ルールが頻繁に変わる業務は自動化に向かない。 |
| 2 | 画像・紙データを使用するか | 自動化の可否 | RPAツールの基本機能のみでは画像等の非構造化データに対応するのが難しいため、自動化は要検討 ※導入計画時に自動化の範囲をどう規定しているか次第。AI-OCR等他技術との併用も計画している場合はこの限りではない |
| 3 | 業務で操作するシステム・アプリケーションをRPAツールで認識できるか | 自動化の可否 | RPAツールが認識できないシステム・アプリが操作対象となっている業務は自動化が難しい ※社内で使用されているシステム・アプリがRPAツールで認識できるか、事前に調査しておくと早い段階で判断しやすい |
| 4 | 機密情報の取り扱う業務か | 自動化の是非 | 機密情報（個人情報、顧客情報など）の取り扱いがある業務は漏洩リスクの担保を同時に検討する必要がある |
| 5 | 人手によるリカバリが可能か | 自動化の是非 | デジタルレイバーでの実行が失敗した際に、人手によるリカバリが難しい場合は自動化に向かない |
| 6 | 承認系業務か | 自動化の是非 | 人間による承認が必要な業務は自動化すべきではない |
| 7 | 操作対象のシステムに更改予定があるか | 自動化の是非 | システム更改前に作ったロボットはシステム更改後に稼働できない可能性が高いため、システム更改後に自動化検討をすることが望ましい |
| 8 | 稼働時刻が保守範囲内か | 自動化の是非 | デジタルレイバーが稼働する時間帯が保守範囲内ではない場合は自動化対象としない ※24時間365日稼働するからお得、と宣伝されるが、運用保守の観点が欠けている事例がある |
| 9 | 別手段で自動化済みか | 自動化の是非 | VBA等、ほかの手段で自動化が完了している業務については原則ロボットに作り替えることは行わない ※VBAなどで安定稼働している場合、作り替えることでのメリットが小さいことが多いため。ただし、RPAの中央管理機能の管理下に置きたいという理由で、当該プログラムを起動させて結果(処理ステータス)を受領するロボットを作成した事例がある |
| 10 | デジタルレイバー専用アカウントを準備できるか | その他 | 人による操作・デジタルレイバーによる操作は区別しておく必要があるため、デジタルレイバー専用アカウントを準備できないシステム・アプリの操作は自動化しない |
| 11 | 開発環境(テスト環境)があるか | その他 | データを更新する業務など本番環境に大きい影響を与える業務を自動化する場合、開発環境がないとテストを行うことが難しい。 |
などなど、現場によって様々です。
上記の基準で自動化対象外となっているものでも、自動化対象となっている現場もあります。
3-2.自動化優先順位の判断（机上選定）
自動化可否を判断し、自動化可能と判断された業務について、優先順位を決定していきます。
以下のような観点がありそうです。
| No | 観点 | 詳細 |
|---|---|---|
| 1 | 作業時間 | 対象業務で１件を処理するのにかかる時間 |
| 2 | 処理件数 | 対象業務で対応する処理の件数 |
| 3 | 頻度 | 対象業務が発生する頻度 |
| 4 | 対応人数 | 何名で対象業務を行っているか |
| 5 | ミスの発生率 | 対象業務実施時のミス発生の度合い |
| 6 | 汎用性 | 部署横断性の高さ |
| 7 | 繁忙期の負荷 | 時期により業務の負荷のばらつき |
などなど、こちらも現場によって様々だと思います。
業務を行う際の精神的な負荷(失敗できない、処理が複雑など)についても観点に入れている現場もあるようです。
個人的には、経営に対する貢献度合い(≒RPA導入効果)に直結するような観点が多いように感じます。
3-3.実装可否の判断（実検証）
本当は1.自動化可否の判断で同時に判断できれば良いのですが、
実際に設計や開発をする段階にならないと細かく実検証できないケースが多いことが想定されるので第3フェーズになっています。
各RPAツールで要件を実装できるかの検証を行う段階です。
ここで実装が難しいことが発覚した場合はユーザー部門と協議の上、「中止」や「実装できない箇所を除いて自動化継続」「業務プロセスを変更し、自動化を継続」等の判断を行うことになります。
4.まとめ
あまりQiitaっぽい内容ではありませんでしたが、業務選定の例を紹介致しました。
いくつかのプロジェクトを経験して感じるのは、
どの現場でも通用する特効薬のようなベストプラクティスはなく、それぞれの現場に合わせたベストプラクティスを辛抱強く検討していくのが重要ということです。
どこでも当たり前のことなのですが、RPAにおいては特にこの傾向が強いと感じています。
とはいえ、ここは押さえておくポイントというのはあると思いますので、皆様のご経験も共有いただけると幸いです！