はじめに
RPAは、他ITツールに比べて、短期間・低コストで導入をスタートできます。また、開発直後から効果を実感できるという即効性もあります。
しかし、実務で使う運用フェーズに入ると一転、「RPAが止まる」「RPAは使えない」と判断されることが少なくありません。
RPAは本当に使えないのでしょうか？いえ、RPAは使えます。
運用フェーズに入り、RPAが評価されなくなるのは“RPAの本質”を理解されていないことが原因です。
ネット検索をしても出てこない・本にも書かれていない”RPAの本質”をお伝えします。
“RPAの本質”を理解したら運用でつまずくことがなくなります。
対象とする読者
・RPA導入を検討している方
・RPA導入の意思決定権者
・RPAツールの検証中の方
・検証が終わり、これからRPAの導入範囲を拡げていこうと計画している方
・RPA導入を行ったが効果を実感できず撤退した方
は必読の内容です。
“RPAの本質”とは
“RPAの本質”とは「不安定」ということです。
想像してみてください。
昨今のITツールで、RPAほど、導入前の期待と導入後後の失望の落差（ギャップ）が大きいツールはあるでしょうか。
このギャップが生じる本質的な理由は、「RPAは不安定」である、ということです。
しかし、ベンダーは、RPAが不安定なITツールであることを一切語っていません。そのため、ユーザー部門および管理者は、RPAに実態以上の期待値を乗せてしまっています。実態にそぐわない期待値のせいで、運用時に発生するエラーに過敏に反応してしまうのです。また、エラーが発生すると、ユーザー部門および管理者からRPA開発者への風当たりが強くなるケースも少なくありません。
「RPAは不安定であること」をお伝えする目的は、RPAへの期待値を下げることではありません。RPA運用でぶつかる壁を突破していただきたいのです。RPAは、業務効率化を実現するために有用なツールです。
「RPAは不安定であること」を前提として、2018年から、大企業から中堅企業まで企業規模・業種によらず、大規模RPA導入プロジェクトを成功させてきた当社だから把握しているRPA運用の壁を乗り越える方法をお伝えします。
“RPAの本質”をとらえておけば、RPA運用時に発生しうるエラーを想定できますし、実際にエラーが発生しても想定内ととらえることができるため、慌てることなくエラー解消が可能になります。
運用体制をつくっても根本的な解決にはならない
ロボットが止まることを解決しようと、「RPA 運用」「RPA 運用保守」などの検索ワードで解決策になりそうな情報を収集すると、
・ロボット開発やメンテナンスを行う運用体制をつくりましょう
・ロボット開発およびエラー発生時の担当者や申請方法などのルールを決めましょう
・特定部署での利用ではなく、全社に広がる工夫をしましょう
・ベンダーによるコンサルティングや運用代行を利用しましょう
・RPA人材を育成するための教育を実施しましょう
という内容がほとんどではないでしょうか。
投資対効果を出すためのRPA運用方法として、いずれも間違っていませんが、ロボットが止まってしまうことに対する本質的な答えではありません。これらを取り入れたとしても、あなたが解決したい、RPA運用時にロボットが止まることは何一つ変わりません。
RPA運用は手がかかる
RPAは、業種業界を問わず活用できることに加え、システム導入の中でも、開発期間が短く、即効性があるためスタート時は「どの業務から自動化しようか」「どんどん開発しよう」と盛り上がるものの、運用段階になると「開発時の検証では問題なく動いていたのに、実運用を始めたらロボットが止まる」「運用（システムの正常状態を維持）と保守（不具合が発生したときの対応）に時間がかかる」という状況が出てきます。
RPA導入を行ったが効果を実感できず撤退した方の主な撤退理由がこれにあたるのではないでしょうか。
しかし、必ずしも「RPAの運用に労力がかかること」＝「RPA導入の失敗」ではありません。
RPA運用は工数がかかるものだからです。なぜなら、RPAは不安定だからです。
では、なぜ、RPAは不安定になるのでしょうか。
開発者のスキルが低いから？開発難度が高いから？RPAと業務/システムの相性が悪いから？
どれも原因にはなりますが、十分ではありません。また、いずれもコントロール可能な原因ですので、対処すれば安定性が出てきて運用工数を低減できるはずです。しかし、これらの原因を改善しても必ずしも安定し、工数低減を実現できるわけではありません。RPA運用時に発生するエラーには「コントロール不可能な原因」があるためです。
コントロール不可能な原因とは、
・操作対象となる基幹システム/Webサイトの仕様変更
・開発時には想定していなかった例外処理の発生
・ブラウザの仕様変更
・ネットワークの遅延
といった利用環境の変化です。
RPAは、想定していない利用環境の変化が発生すると止まってしまいます。
つまり、RPAは、外部要因（利用環境）に大きく影響を受ける不安定なツールです。
RPAは不安定。これが”RPAの本質”です。
このことを押さえておかなければ、RPAへの失望から抜け出すことはできません。
RPAの品質だけではなく、実行した利用環境に大きく依存するため、RPAを実行して発生するエラー率は、一般的なシステムに比べて必然的に高くなることを理解ください。
RPA開発時に要求通りに動くことを確認しているにもかかわらず、運用時にエラーが発生するのは、ほとんどがRPA自体のエラーではなく、利用環境に起因するものです。
RPAを使って省人化・省力化を実現するためには、「RPAは不安定なので、止まる可能性があり、運用と保守対応に工数を割かなければならないツール」という前提を関係者内で共有しておかなければなりません。
ロボットが止まった場合、開発者を責めるのではなく、原因を突き止め、次に同じような事象が発生したときに止まらないよう追加開発を行う必要があります。RPAとは、運用の中で精度を高めていかなければならないITツールなのです。
この前提を持っておかなければ、開発ルール・運用ルール・開発者の育成にお金・人・時間というリソースをいくら投入してもRPA運用の壁を乗り越えることはできません。ベンダーに丸投げしても効果を実感することはありません。
RPA運用の壁を乗り越えるためには
RPA運用で発生するエラーは、利用環境の変化によって発生するため再現性が乏しく、全ての変化を想定して開発することは不可能なため、都度対応になってしまいます。運用工数が大きくなるのはこのことが原因となります。しかし、エラー対応を進めることによって、開発者（運用担当者）の勘所が良くなり、事前にエラー対応のための処理を入れることができるようになるなど、エラー発生頻度が低減に向かうようになります。RPAは、100点満点のものを開発できるのではなく、運用の中で100点に近づけていくITツールであることを理解ください。
RPAは不安定であり、処理を100%完遂できるわけではない。このことを踏まえておけば形骸化しない運用ルールおよび運用体制をつくることができるようになります。
RPA運用について立場別に認識しておくべきこと
・開発者（運用担当者）
「RPAは、利用環境に依存する不安定なツールであること」を念頭に置き、運用時にエラーが発生したら、当該エラーが、RPA自体に起因するものなのか、利用環境に起因するものなのかを切り分けてください。そして、利用環境に起因する場合には、同事象が今後発生してもエラーを回避できるよう改修を行うとともに、利用環境に起因するエラーであることをユーザー部門と管理者に正しくエスカレーションしてください。
・ユーザー（RPA利用者）
RPAは完全なものではないため、止まるときもあることを前提に業務に取り入れてください。
・管理者（意思決定権者）
短期視点ではなく、エラー発生が低減されていく過程を追いかけてください。RPAとは、運用の中で100点に近づけていくITツールであると認識してください。
まとめ
RPA導入を検討している方は、「RPAは、設定（開発）したことは必ず実行する」と思われていたのではないでしょうか。また、導入に携わっている方の多くは、「なぜ、こんなにRPAは止まるんだ」と開発者を不安視したり、RPAというITツールへの失望感が出てきていたのではないでしょうか。RPA導入を撤退した方は、合点がいきましたでしょうか。
RPAの”本質”が「不安定」であることを理解いただけたことで、RPA運用のハードルは以前よりも下がったのではないでしょうか？
RPAは実運用の中で100点に近づけるITツールであることが頭にあれば、RPA運用時にエラーが発生しても落ち着いてて、現実を直視できます。発
生したエラーが、RPA自体（RPAの品質）に起因するものなのか、それとも、利用環境の変化によるものなのかを切り分けてください。
コメント