ちょっと待て その RPA 本当に必要ですか？
最近、新聞やニュースで「ＲＰＡ」の道入効果が書かれた記事を良く見かけます。
ＲＰＡ(Ｒｏｂｏｔｉｃ Ｐｒｏｃｅｓｓ Ａｕｔｏｍａｔｉｏｎ）は、その名の通り、これまで人によるルーチンワークなどをロボットに代行させるソリューションです。ＲＰＡはニュースなどで金融機関など大企業の導入事例で「人員勘定で約６、０００名分の削減」とか、作業効率向上効果を中心に据えた記事が多数報道されています。
「ＲＰＡ」ですが今導入をお考えの事業者の皆さんは、今一歩立ち止まって、これから筆者が述べることを念頭に、是非再考いただけばと思います。
本記事は「ＲＰＡ」を決して否定するものではありません。むしろ「ＲＰＡ」ソリューション提供事業者、導入検討中の事業者の双方に役立つ情報だと確信しています。
ＲＰＡを導入する事前の課題
「ＲＰＡ」は業務を自動化するわけですので、現状の業務分析が不可欠です。筆者も元プログラマー、ＳＥ、プロジェクトマネージャー、そしてコンサルちっくな業務をしていたので業務分析の重要性はとても良くわかります。
そして業務分析を終えて仕上がった業務に最適化した「ＲＰＡ」システムが動きだすと、顕在化してくるのが、ヒアリングでは浮かび上がなかったイレギュラーの業務です。
実はこのイレギュラー対策は、かなり手強くて、対策に「時間とコスト」がかかります。
まして、その対策には正規系の何倍もの工数とコストがかかる場合があります。
また予期せぬイレギュラーな対応というものは、要件定義の曖昧さに比例して、その度合いが大きくなります。
さてこのイレギュラー処理が発生した場合の対応ですが、システム屋さんばかりが被るわけではありません。システム屋さんはもちろん想定外の工数と出費が強いられます。では導入する側は「システム屋さん任せてじっと待ていれば良い」などと言った事はなく、既にシステムは切り替わっているわけで、情報システム部門は社内のトラブル対応に追われることになります。
実は「ＲＰＡ」もシステム構築と同じようなリスクを抱えているのです。
「ＲＰＡ」現状分析のリスク
「ＲＰＡ」導入の際、業務システムと同様に、導入する部門に対してベンダーによるヒアリングが行われます。たいがいは検討中の「ＲＰＡ」のシステムに合わせたチェックシートに沿ってヒアリングが行なわれ、ユーザから聞き取った内容はチェックシートに書き込まれます。その後「ＲＰＡ」の実装検討が検討されます。
その実装検討案が、実質要件定義となり、見積り書となり、双方合意すると晴れてめでたく受注と相成ります。そして「ＲＰＡ」の導入にゴーサインがだされます。
「ＲＰＡ」の知られざるリスク
先程述べたヒアリング漏れのリスクの他に、もう一つ重要な見逃されがちなリスクがあります。
クラウドサービスが抱えるリスク
昔と違い今々の業務システムはクラウドサービスを使用するケースが増えました。自社の業務に合わせてフルスクラッチでシステムを構築するより、社内の業務をクラウドサービスに合わすやり方です。
これについては筆者は一言、言いたいことがあるのですがそれはまた別の機会で申し上げます。
クラウドサービス、その機能はＷｅｂブラウザを使って利用します。
実はそこに落し穴があるのです。
「ＲＰＡ」のリスクとなるＷｅｂサービスの落とし穴
Webシステムを「ＲＰＡ」で自動化する場合、一体どういう仕掛けで動いているのでしょうか。ここからはややもすると少し技術的な話しになるのですが、出来るだけ身近な言葉で説明致します。
わかりやすく説明するために、下記の様な業務システムを例に説明します。
【送り状発行システム】
- 顧客コードを「マスター検索欄」に入力します。
- 該当する顧客情報を表示します。
- 配達する品名を入力します。
- 送り状発行ボタンをクリックすると「送り状」を発行します。
画面イメージはこんな感じです。
さてここでクイズです。
どちらも正解です。
回答の解説
| 座標（位置）で見つける | 「ＲＰＡ」はＷｅｂ画面に配置された入力欄を相対アドレス位置、絶対アドレスなどの位置を頼りに、マスターコード覧と認識して顧客コードを入力します。 |
| HTMLの名前を見つる | 「ＲＰＡ」はＷｅｂの画面にある入力欄、今回の場合マスターコード覧に付けられた目に見えないＨＴＭＬで記述された”名前”を頼りに、そこに顧客コードを入力します。 |
どちらの正解にも潜むリスク
さて貴社の「ＲＰＡ」が完成しました。早速ルーチンワークの自動化を開始します。暫く問題なく動き、導入推進者と「ＲＰＡ」ソリューションベンダーは意気揚々です。
ところがある日、突然動かなくなります。導入推進者は驚いて、すぐに「ＲＰＡ」ソリューションベンダーに連絡します。
保守期間なのでベンダーはすぐに駆けつけて原因を調べます。そして「ＲＰＡ」ソリューションベンダーから導入推進者へ動かなくる理由の説明を受けます。
原因は次の通りです。
さて原因はなんでしょうか。先ほどの表のケースで説明します。
| 座標（位置）で見つける | 「Ｗｅｂの画面レイアウトが変わりました。」 |
| HTMLの名前を見つる | 「マスターコード欄の見えない名前が変わっていました。」 |
このトラブル原因の根本的理由は読者の方は、すでおわかりだと思います。
そう、クラウドサービス側の仕様変更が原因なのです。
さあここで解決するための課題を整理してみます。
- 今回のトラブルは一体だれの責任なのか。
（クラウドサービス事業者？ｏｒ「ＲＰＡ」ベンダー？ｏｒ導入事業者？） - 一体だれが直すのか。
（クラウドサービス事業者？ｏｒ「ＲＰＡ」ベンダー？） - 一体だれが費用負担をするのか。
（クラウドサービス事業者？ｏｒ「ＲＰＡ」ベンダー？ｏｒ導入事業者？）
導入事業者が、こうした事態に備え、保守サービスに入っていれば、上記の①②③の全てはベンダーが開発した「ＲＰＡ」の仕様を修正することで解決できるでしょう。
しかしそのような保守サービスを契約していないと必ず上記①②③はもめる事態となります。
原因はクラウド事業者の仕様変更なので弊社には責任がありません！
こうなると泥沼状態に陥る寸前です。
まとめ
こうしたトラブルを防ぐには事業者側がちゃんとこういった事態に備えることです。下記の条件を盛り込むことが大切です。
- クラウドサービス側と連携を図り、サービスが変更された場合、連携が取れる体制を敷く。
- こうした事態に備え保守サービスを契約する。
- 導入事業者が音頭を取り、クラウドサービス事業者と「ＲＰＡ」ベンダーとリスクについて打合せを行う。
ただし上記を揃えるにはコストがかかります。
これまでお伝えしてきたことを念頭に、かかるコストで本当に業務改善ができるのか、費用対コストの視点で十分に検討をすることをおススメいたします。
筆者はこうした問題が「ＲＰＡ」で起きることは当初から予見していました。ですのでお付き合いのあるＷｅｂ制作屋さんなどに、お客様のＷｅｂシステムを導入した後に、お客様に了解なく「画面レイアウト、入力欄の見えない名前を変えることはしない」など、より詳しい内容と具体例でミニセミナー、説明会（啓蒙活動）をしてきました。
また「ＲＰＡ」を検討中の事業者さんには費用対コスト計算でＮＧだった場合の代替手段などを提案しています。
「ＲＰＡ」ソリューション導入検討事業者様のおかれましては、これまでの話で何か気になった時は、是非に、問い合わせからご相談ください。
筆者はそんじょそこらの駆け出しのコンサルと違うわい！！
最後は自慢話で終わり、誠に恐縮です。