ちょっと待て その RPA 本当に必要ですか?

IT
Sponsored Links

ちょっと待て その RPA 本当に必要ですか?

最近、新聞やニュースで「RPA」の道入効果が書かれた記事を良く見かけます。

【RPAとは】
RPA(Robotic Process Automation)は、その名の通り、これまで人によるルーチンワークなどをロボットに代行させるソリューションです。RPAはニュースなどで金融機関など大企業の導入事例で「人員勘定で約6、000名分の削減」とか、作業効率向上効果を中心に据えた記事が多数報道されています。
「RPA」はニュースの記事にあるように、そこに書かれた効果が、導入企業にとって、まんべんなくそのメリットをもたらすのでしょうか。

「RPA」ですが今導入をお考えの事業者の皆さんは、今一歩立ち止まって、これから筆者が述べることを念頭に、是非再考いただけばと思います。
本記事は「RPA」を決して否定するものではありません。
むしろ「RPA」ソリューション提供事業者、導入検討中の事業者の双方に役立つ情報だと確信しています。

RPAを導入する事前の課題

「RPA」は業務を自動化するわけですので、現状の業務分析が不可欠です。筆者も元プログラマー、SE、プロジェクトマネージャー、そしてコンサルちっくな業務をしていたので業務分析の重要性はとても良くわかります。

少し話は脱線しますが、業務システムを構築する時に、正規系、つまり大半の業務プロセスの大半は、お客様からのヒアリングで把握できます。頑張ると業務プロセスの90%くらいは把握できると思います。

そして業務分析を終えて仕上がった業務に最適化した「RPA」システムが動きだすと、顕在化してくるのが、ヒアリングでは浮かび上がなかったイレギュラーの業務です。

実はこのイレギュラー対策は、かなり手強くて、対策に「時間とコスト」がかかります。

まして、その対策には正規系の何倍もの工数とコストがかかる場合があります。

また予期せぬイレギュラーな対応というものは、要件定義の曖昧さに比例して、その度合いが大きくなります。

さてこのイレギュラー処理が発生した場合の対応ですが、システム屋さんばかりが被るわけではありません。システム屋さんはもちろん想定外の工数と出費が強いられます。では導入する側は「システム屋さん任せてじっと待ていれば良い」などと言った事はなく、既にシステムは切り替わっているわけで、情報システム部門は社内のトラブル対応に追われることになります。

実は「RPA」もシステム構築と同じようなリスクを抱えているのです。

Sponsored Links

「RPA」現状分析のリスク

「RPA」導入の際、業務システムと同様に、導入する部門に対してベンダーによるヒアリングが行われます。たいがいは検討中の「RPA」のシステムに合わせたチェックシートに沿ってヒアリングが行なわれ、ユーザから聞き取った内容はチェックシートに書き込まれます。その後「RPA」の実装検討が検討されます。

その実装検討案が、実質要件定義となり、見積り書となり、双方合意すると晴れてめでたく受注と相成ります。そして「RPA」の導入にゴーサインがだされます。

ヒアリング漏れがないか再度確認しましょう。漏れがあれば後々のトラブルに繋がります。

 

「RPA」の知られざるリスク

先程述べたヒアリング漏れのリスクの他に、もう一つ重要な見逃されがちなリスクがあります。

クラウドサービスが抱えるリスク

昔と違い今々の業務システムはクラウドサービスを使用するケースが増えました。自社の業務に合わせてフルスクラッチでシステムを構築するより、社内の業務をクラウドサービスに合わすやり方です。

これについては筆者は一言、言いたいことがあるのですがそれはまた別の機会で申し上げます。

クラウドサービス、その機能はWebブラウザを使って利用します。

実はそこに落し穴があるのです。

「RPA」のリスクとなるWebサービスの落とし穴

Webシステムを「RPA」で自動化する場合、一体どういう仕掛けで動いているのでしょうか。ここからはややもすると少し技術的な話しになるのですが、出来るだけ身近な言葉で説明致します。

わかりやすく説明するために、下記の様な業務システムを例に説明します。

【送り状発行システム】

  • 顧客コードを「マスター検索欄」に入力します。
  • 該当する顧客情報を表示します。
  • 配達する品名を入力します。
  • 送り状発行ボタンをクリックすると「送り状」を発行します。

画面イメージはこんな感じです。

さてここでクイズです。

「RPA」はこのWeb画面の一番上にあるマスターコード入力エリアをどう認識するのでしょうか?
マスターコード入力エリアを座標(位置)で見つける :正解です。
マスターコード入力エリアについている、HTMLの名前を見つける :正解です。

どちらも正解です。

回答の解説

座標(位置)で見つける 「RPA」はWeb画面に配置された入力欄を相対アドレス位置、絶対アドレスなどの位置を頼りに、マスターコード覧と認識して顧客コードを入力します。
HTMLの名前を見つる 「RPA」はWebの画面にある入力欄、今回の場合マスターコード覧に付けられた目に見えないHTMLで記述された”名前”を頼りに、そこに顧客コードを入力します。

どちらの正解にも潜むリスク

さて貴社の「RPA」が完成しました。早速ルーチンワークの自動化を開始します。暫く問題なく動き、導入推進者と「RPA」ソリューションベンダーは意気揚々です。

ところがある日、突然動かなくなります。導入推進者は驚いて、すぐに「RPA」ソリューションベンダーに連絡します。

導入推進者
すみません。突然貴社で開発して頂いたRPAが動かなくなりました。

保守期間なのでベンダーはすぐに駆けつけて原因を調べます。そして「RPA」ソリューションベンダーから導入推進者へ動かなくる理由の説明を受けます。

RPAベンダー
原因がわかりました。弊社にミスはありません。
原因は次の通りです。

さて原因はなんでしょうか。先ほどの表のケースで説明します。

座標(位置)で見つける 「Webの画面レイアウトが変わりました。」
HTMLの名前を見つる 「マスターコード欄の見えない名前が変わっていました。」

このトラブル原因の根本的理由は読者の方は、すでおわかりだと思います。

そう、クラウドサービス側の仕様変更が原因なのです。

さあここで解決するための課題を整理してみます。

  1. 今回のトラブルは一体だれの責任なのか。
    (クラウドサービス事業者?or「RPA」ベンダー?or導入事業者?)
  2. 一体だれが直すのか。
    (クラウドサービス事業者?or「RPA」ベンダー?)
  3. 一体だれが費用負担をするのか。
    (クラウドサービス事業者?or「RPA」ベンダー?or導入事業者?)

導入事業者が、こうした事態に備え、保守サービスに入っていれば、上記の①②③の全てはベンダーが開発した「RPA」の仕様を修正することで解決できるでしょう。

しかしそのような保守サービスを契約していないと必ず上記①②③はもめる事態となります。

導入推進者
貴社が開発したRPAなので無償で直してください。
RPAベンダー
ちょっと待ってください。受注条件(要件)でちゃんと開発しました。
原因はクラウド事業者の仕様変更なので弊社には責任がありません!

こうなると泥沼状態に陥る寸前です。

まとめ

こうしたトラブルを防ぐには事業者側がちゃんとこういった事態に備えることです。下記の条件を盛り込むことが大切です。

  1. クラウドサービス側と連携を図り、サービスが変更された場合、連携が取れる体制を敷く。
  2. こうした事態に備え保守サービスを契約する。
  3. 導入事業者が音頭を取り、クラウドサービス事業者と「RPA」ベンダーとリスクについて打合せを行う。

ただし上記を揃えるにはコストがかかります。

【今回のまとめ】
これまでお伝えしてきたことを念頭に、かかるコストで本当に業務改善ができるのか、費用対コストの視点で十分に検討をすることをおススメいたします。

筆者はこうした問題が「RPA」で起きることは当初から予見していました。ですのでお付き合いのあるWeb制作屋さんなどに、お客様のWebシステムを導入した後に、お客様に了解なく「画面レイアウト、入力欄の見えない名前を変えることはしない」など、より詳しい内容と具体例でミニセミナー、説明会(啓蒙活動)をしてきました。

また「RPA」を検討中の事業者さんには費用対コスト計算でNGだった場合の代替手段などを提案しています。

ネタバレになりますが、今回想定した「送り状発行システム」ですが、実際に筆者が対応した実話で「RPA」ではなく代替手段で課題を解決しました。

「RPA」ソリューション導入検討事業者様のおかれましては、これまでの話で何か気になった時は、是非に、問い合わせからご相談ください。

筆者はそんじょそこらの駆け出しのコンサルと違うわい!!
最後は自慢話で終わり、誠に恐縮です。

Sponsored Links
最新情報をチェックしよう!