「怠け心」こそ進歩の源泉?

前回は、RPAの部品化の必要性や、RPAが巨大化した場合の難点、さらには複数のRPAを束ねる外部の仕組み(ワークフローなど)の必要性について説明しました。

4回目となる今回は、RPAを適用すべき業務エリアをどのように選んだらいいのかについて考えてみましょう。

“正しく”怠けるということ

科学の発展について論じるときによく言われる言葉に、「科学は、怠ける気持ちがあるからこそ進歩する」というものがあります。ここで言われている「怠ける気持ち」とは、単なるサボりというよりは、「本質的でないものはなるべく機械に任せてしまいましょう」ということでしょう。つまり、「”正しく”怠けることで進歩する」というわけです。

では、これをRPAの世界で考えた場合、「正しく怠ける」とは、具体的にどのような状態を指すのでしょうか。

RPAの導入はなぜ失敗するのか?

まず、「RPAの導入はなぜ失敗するのか」というところから、順を追って考えてみましょう。プロジェクトが失敗する大きな理由の1つは、RPAのことだけを考えて、近視眼的に導入してしまっていることにあります。

英アーンスト・アンド・ヤング社(以下、EY社)の分析によると、RPA単体の初期導入プロジェクトは、実に30～50％が失敗に終わるようです。詳細はEY社の記事『Get ready for Robotic Process Automation』に譲りますが、主な理由として以下のものが挙げられています。

RPAは、今やIT業界のトレンドと言えます。それを絶対的な”善”と捉え、実行に移すことに疑問を差し挟む人は、あまりいないのかもしれません。しかし、そのようにして始まったプロジェクトが、知らず知らずのうちに破綻していくのです。プロジェクトの結果としてたくさんのロボットが完成し、出来上がったロボットの数そのものが成果であると錯覚してしまいます。このようなプロジェクトは、短期的には社内で高く評価されることがあるかもしれません。しかし、その評価は一時的なものです。往々にして、数多くのRPAが部門ごとに「勝手に」導入され、管理やメンテナンスの面で収拾がつかなくなり、当初想定したほどROIが出ない、といった事態が発生します。

昨今では、RPA市場の成熟に伴い、徐々にこのようなRPA単体プロジェクトの問題点が顕在化してきています。実際、筆者のところにはお客様からこの類の相談を持ちかけられることが多くなりました。

前回述べたとおり、RPA導入の際には、RPAを束ねる外部の仕組み(ワークフローなど)を合わせて検討すべきだと言えるでしょう。

RPAの導入に適した業務領域を知るには?

RPA導入を成功させるには、RPAを業務の「どこに導入するのか」も重要になります。RPAの導入に適した業務領域は、ボリュームゾーン( = 単純×大量)です。これは、単に業務量の多寡だけではなく、「数々の業務から共通項を見いだし、標準化することでボリュームゾーンに仕立てる」という意味合いも内包しています。

例えば、とある企業では、特定の端末から引き出された情報を突合する業務を、複数の部門で各々実施している、という重複がありました。個々の部門の負荷はそれほどではないとしても、これらを全てRPAの処理としてまとめて汎用化できれば、かなりのボリューム減を狙うことができます。

このようなボリュームゾーンを知るには、具体的にはどのようにしたらいいのでしょうか。ここでは2つのアプローチを考えてみましょう。

人間による業務分析

これは、人間が手動で現行業務プロセスを確認し、プロセスの見直しを適宜行いながら、RPAを導入できるボリュームゾーンを探る手法です。ここで重要なのは、導入効果を金額で試算することです。

人間による業務分析の良いところは、業務の意味合いを含めて総合的に分析を行えるところです。ボリュームゾーンを探るだけでなく、対象業務の重要性(RPAが本質的な業務の橋渡しをできているか)を探る意味でも、人間による業務分析は有効であると言えるでしょう。

この業務分析作業は、ユーザー企業が独自に実施することもできますし、外部のコンサルティング企業に委託して客観的に実施することもできます。

システムによる業務分析

業務分析のためのツールを活用して、定性的かつ定量的に業務分析を行うことも可能です。「従業員が、業務時間をどのように使っているのか」「どのアプリケーションのどの画面を使っているのか」「どのアプリケーションからどのアプリケーションへの画面切り替えが多いのか」などのさまざまな情報を、ユーザー単位／部門単位／企業単位で集計できます。

業務分析ツールのなかには、RPAの導入ポイントを具体的に示してくれたり、RPAの導入効果を金額換算で示してくれたりするものもあります。

システム的な分析を行うことのメリットとしては、次のようなものがあります。

A. 定量的な分析結果が出る(RPA導入効果を数字で試算しやすい)
B. 人間による業務分析では気づくことのできない知見が得られる

Bの具体例を1つご紹介しましょう。とある企業で、システム的な業務分析により、毎週水曜の昼過ぎの時間帯に、なぜか社員がメールを一斉に参照していることが明らかになりました。このため、毎週水曜の生産性が若干下がっているようでした。調べてみると、毎週水曜のこの時間帯に人事から一斉メールが全社員宛てに送信されていることがわかりました。社員はそのメールを読んでいたようです。日中同時刻に、一斉に業務が中断されるのは非効率であるため、この企業ではメールの送信時刻を夜の時間帯にずらすことで、業務への影響を最小限にとどめることに成功しました。こうした”気づき”は、人間による業務分析(通常は業務単位で実施されます)だけではなかなか得られません。

人間による業務分析と、システムによる業務分析は、どちらか一方をやればいいというものではなく、互いに補完し合う関係にあると言えるでしょう。

ロボットの定義内容が簡単であればあるほど、メンテナンスコストが低く抑えられるという観点も重要となります。業務分析の結果をRPAの定義内容に落とし込む際の考慮点として、忘れないようにしたいものです。

RPAプロジェクト成功のための必要条件

RPA導入にはコストがかかります。作成コストもかかりますし、メンテナンスコストもかかります。手当たり次第にRPAを導入しても、無駄な高速道路と同じで、有意なメリットは得られません。前述のとおり、RPAの導入にあたってはボリュームゾーンや重要な業務を狙うべきです。

また、RPA導入前に業務プロセスの見直しを行うことも重要です。本連載の第1回でも述べたとおり、安易にRPAを導入すると、現状の業務とシステムを上塗りして定着させてしまい、取り返しのつかない事態になる危険性があります。

そうしたリスクを回避するには、プロジェクトの統制確保が重要です。各部門が勝手気ままにRPAを導入したり、業務プロセスの見直しをせず拙速にRPAを導入したりする状況を発生させてはいけません。

RPAプロジェクト成功のための必要条件は、次の3つです。

- RPAに適した業務領域を選ぶこと
- 業務プロセスの見直しを行うこと
- プロジェクトのガバナンスを確保すること

プロジェクトのガバナンスが確保されれば、作るだけ作って放置される”野良ロボ”の削減にもおのずとつながります。

*　*　*

RPAの導入を真に意味のあるものにするには、「正しく怠ける発想」を持つ必要があります。「正しく怠ける」とは、真に導入効果が得られる業務領域を選択し、無駄なロボットは作らないということです。

言われてみれば当たり前のことですが、実際にこれができている企業は意外と多くありません。筆者は、RPA導入を検討している企業から、セールスの初期段階において、「とりあえず、まずは思いついた業務領域からRPAを導入してみて、様子を見てから今後の展開を決める」ということを、必ずと言っていいほど言われます。多少なりとも業務分析をした結果、RPAの対象業務領域を選んだということであればいいのですが、どうやら「安易なRPA導入」に陥っているケースが大半のように見受けられます。

1人で怠けていたら悪者ですが、周りの皆も一緒に”正しく”怠けさせられたらヒーローです。この発想を、ぜひ頭の片隅に置いてみてください。