RPA使えてる? RPA活用の向上策!(vol.7)

2021.12.27

「RPA使ってます!」良く聞きます。でも、がっつり活用出来てますか?
そこそこの効率化で満足していませんか?
人的操作だって間違うし、環境はいつも安定しているわけじゃない、OSもブラウザもVerUPするし、ある程度のエラーは仕方ないと諦めていませんか?
もしかして、折角作ったロボを利用するのを止めていませんか?

エラー改善、出来ますよ。
エラーや人的リカバリのストレスから解放し、RPAの活用度をぐんと上げるための方法があります。

本記事では、RPAの開発および保守改善で極限までエラー率を改善した、その活用方法や対応を解説します。

RPAってそこそこ動けば活用した気になるよね

「ロボのエラー率ってどのくらい?」
「いい質問です!10%程度です」
「そーだよね、9割もやってくれりゃ万々歳ですよね」
ご満悦です、仕事が9割減ったと思っています、しかし、エラーは突如起こる、そしてリカバリも急に割り込む。
こんな事例があります。午前11時に配信したい日次の集計レポートの作成、人手では2人掛かりで2時間。ロボなら40分です。ロボは8時40分にバッチ起動、9時30分の定時に出社したら完成している運用。
担当者は当番制の9時出社から解放です、万々歳。
でもね、たまにこけます(笑)。ユーザは理由も分からず、9時30分から再実行です、運よく2回目で成功すれば、配信は間に合います。
2回目もエラーになったら。。。手作業、ほぼアウトです(泣)。気が気じゃない、高ストレスです(汗)。
ロボで途中まで集計レポートは出来ていたりするので、例えば全15ページの集計レポートのうち、3ページ分を手作業で作ってマージなんてこともあります。エラー率は10%、月に2回は発生します。ストレスですね。
でも月に2回泣くだけだから、しっかり効率化出来ています。『そこそこ満足』です。

普通は、ここでゴール、諦めちゃいます。
残念ながら『成功率90%は、満足度90%』ではないのです。

エラー削減でRPAをとことん活用しよう

エラー率が20%になったら、使われなくなるケースも出てくる。ロボの開発投資も無駄、ライセンスも無駄、パソコンも無駄です。残念、投資効果が失われます。
現場ユーザの失望も大きい、手離れした仕事が舞い戻ってきます。このストレス大きいのです!
そこそこの頻度でエラーがあると恒常的に人的作業のリカバリが必要だから、手作業マニュアルもお蔵入り出来ません、もしもに備えて脈々と受け継がれます。
エラー率、かなり重要です。しっかり作り込んで、エラーが起きないロボを目指しましょう。

これは私が担当した、連携データを元に2つの社内システムに代行登録するロボの話。
エラー率を5%以内と設定した導入前の目標に対して、Aシステム向け登録ロボのリリース時は3%を達成!、Bシステム向け登録ロボのリリース時は1%を達成!
一般的には十分なゴールですが、両システム共に、改善対応を行い、Aシステムは、1%以下、Bシステムは、0.001%以下まで精度を高めました。やれば出来るんです!

ロボの処理量は、2つのシステム合わせて月35万件~60万件の申込登録を約350台のロボ端末で並行処理します。
特にBシステムはクライアントサーバ型のシステムで安定しており、20万件処理してエラー1件という月もあります。

1件の人的リカバリ対応が約15分です、560件/月減らせれば要員をひとり減らせる計算(※1)、60万件の1%の削減効果は10.7人(※2)
事実、エラー削減により、対応するオペレータ要員を十数名削減できたのです!
(次章で、対処方の一部をご紹介します)

※1:7時間×20日×60分=8,400分/15分⇒560件/人(1人月分のエラー対応件数)
※2:60万件の1%=6,000件/560件⇒10.7人(1%削減の人的作業削減効果)

RPA活用、向上の技、着目点と対処方

先ずは、前提情報としてシステムの概要です。
ロボが操作するシステムは、よくある契約管理。契約内容変更、住所や支払い方法の変更、新たなサービスへの申込など多岐にわたります。処理内容に合わせ、メニューや画面を切替え、各画面に応じて連携データから値をセットし登録するのが基本的なロボの動きです。
システムからの応答メッセージに応じて判断分岐したり、別システムのマスターを検索して正誤確認したり、複数の画面を切り替えてデータをコピペ(Copy&Paste)したりと少々複雑な挙動も行っています。
慣れた「人」なら、さくさくできる作業ですね。

そう、「人」なら臨機応変に対応できるのです。クリック反応が悪けりゃまたクリックすれば良いし、検索が遅くても待つし、スクロールだって、画面切り替えだって、無意識に縦横無尽です。
ですが、ロボは愚直です、Aメニューをクリックして、B項目のデータをコピーして、C画面に遷移してD項目にペーストして検索して、表示されるプルダウンリストから、連携データのE項目と同じデータを選択してクリック反転して、右下の[登録]ボタンをクリックして、ダイアログ画面の[OK]ボタンを押す。という感じで手順をすべてプログラミングします。

パソコンに意識は無いと思うが、時々意地悪です、システムもまれにご機嫌斜めで、色々とトラップを仕掛けてきます。我々は負けませんよ。

  1. バリデーションチェック、基本で最重要
    今回の様にシステム登録なら連携されるデータが登録されるシステムの入力規制に則っていることは必須条件です。リリース当初は、全角半角などの属性や桁数が入力規制に則っていないNGデータが連携されることがありました。これはお手上げです。そこで連携データの作成元でバリデーションチェックを強化しました。RPAの直接対応部分ではないが阻害することはすべて潰すという観点で是非!
    機能改定やサービス追加などシステム変更に応じて連携データは進化します。そこで恒常的に精度がキープできるようにロボの初期処理で連携データの正常性チェックをアドオンしました。この水際対策で明らかなNGデータが来て、ロボ処理がスタックすることは皆無です。
  2. タイミングチューニングは、本番環境で!
    我々は「滑る」と表現していました。いわゆるクリックミスです。
    ボタンを押したが無反応、どうしても起こります。描画や利用システムの状況などタイミング問題です。最適なタイミングは、トライ&エラーで最適化です。
    注意すべきは、開発環境と本番環境が違うこと、本番環境でも通常期と繁忙期など、丁寧に最適値を探ります。もちろん一律じゃないです。そこで画面や機能ボタン単位に設定を分けます。外部変数とすると、環境変化に順応しやすいです。
  3. リトライは、状況を整えて再クリック
    これも滑り対策の王道、クリックミスやシステム無反応への対応です。
    画面遷移やプルダウンなど、クリック後が期待した動きになってない場合、再クリック。待ち時間も調整しながら繰り返す、システムのスローレスポンスにハマる事や表示量の問題で時間が掛るケースなどもありますのでケースバイケース。必要なのは、画面状況を確認して的確に行うこと、闇雲にクリックするとエラーを生みます。表示された画面すべて閉じて、ブラウザを再立ち上げし、ログインからのリトライなども考慮すると、救えるケースがぐんと高まります。
  4. つもりはダメ、セット内容確認処理
    値セットしたのに画面にはちゃんと書き込まれていない。文字化けしていた。あるあるです。
    ロボが値をセットした後に、その部分を画面から抽出して、書き込み元の情報と照らし合わせて、正しくセットされているかについてもロボ処理で確認しています。プルダウンの選択なども。
    半角で画面入力すると自動で全角変換されるなど、面倒な項目比較も実施。不一致時はリトライで再セット。手間ですが、安定化にかなり寄与します。
  5. 最適アクティビティ
    UiPathで同じ機能のアクティビティが複数あり、OSや処理に応じて適正なアクティビティがあります。手間ですがエラーが多いと感じたら、他のアクティビティがないか探って試してみるのも手です。答えはひとつじゃないけど、真実はひとつだったりします。
  6. 1000本ノックでエラー撲滅
    どこでロボがエラーで止まるか、簡単には分かりません。我々は1000本ノックしました。エラーが発生した箇所の画面キャプチャを端末に残す処理を埋め込み、1日中回し続け、発生したエラーをひとつひとつ潰し、1件もエラーが出なくなるまで、何度も何度も500件のデータ投入を行いました。精度向上はやはり地道な努力です。
  7. 負荷分散とかち合い防止
    Aシステム登録用ロボ端末:150台、Bシステム登録用ロボ端末:200台、9時-20時の稼働です。
    一部の端末に処理が集中しない様に、バランスを取っています。時間帯別にユニット分割しサイクルで廻したり、投入量が多い朝一の端末比重を上げたり、扱い量に応じて拠点グループ別の端末数を適正にしています。そして各端末が抱えた未処理トランザクションを常時確認し、未処理件数の少ない端末へ優先配布を行うなど、平準化しています。
    また、同一ユーザIDの同時登録はコンフリクトが原因となるケースがあります。そこで同一ユーザIDの処理要求は同一端末に割り振り順次処理とすることで、並行処理でのかち合いが無い様にしました。
  8. リカバリルートで未処理は救済
    ロボに重大な障害が発生した際、当該端末の処理中のトランザクションは仕方なくエラーですが、端末が抱え込んでいる未処理分は救いたい。
    ある端末の処理がエラーとなった際には、未処理データを管理端末に吸い上げ、他の端末に再配布する処理も組み込んでいます。エラー影響を最低限に抑える手段です。
    不慮の事故でも、ロボは、ただ終わるわけではなくバトンを渡してから落ちます。RPAは偉いです。
  9. キャプチャ機能でエラー箇所の特定
    エラー時の画面キャプチャ機能は、本番にも組み込んでいます。投入データと画面状態から、どの局面でエラーが発生したか一目瞭然、リリース以降の改善対応に繋がり、本番リリース後も精度が向上しました。そしてリリース後半年を経た今、1%以下、0.001%以下です!

まとめ

諦めないこと。手段はいろいろあるし、手段を見つけるための仕込みも時に有効です。
RPAは一度作って終わり、一過性のものといった使われ方で、改善よりも新規再作成ってパターンも多いですが、RPAだって立派なシステムです、丁寧に作ればその分、長く活用できます。
活用されないことが何より無駄、予算や優先順はあるものの考えうる対応をぜひ諦めずに、あくなき改善を進めましょう!
諦めていた、あのロボ、このロボの再活用を考えるきっかけになれば幸いです。

弊社ではRPAの推進と活用をもう一度はじめたい方に参考になる資料「今こそ言える、RPA成功への近道 ~推進と活用の2軸から‘もう一度’はじめましょう!~」をご用意しております。本資料は、RPA導入や再活用に向けて必見の資料です。ぜひダウンロードいただき、ご覧ください。