オペレーション・ITの中期的変革RPA効果を最大化するには

RPA(Robotic Process Automation)が、企業における業務効率化や働き方改革を実現する手段の一つとして注目されている。一方で、想定したような効果が出ないという声も聞かれる。せっかく導入したものの、想定していたよりもコストがかさんで割に合わない、あるいは 業務の効率化が思ったように進まないというものだ。

RPAの効果を引き出すためには、正しい手法をもって開発と運用に取り組まねばならない。闇雲に行うと、せっかく作ったのに活用されない「野良ロボット」を生み出す要因となる。

導入する際のポイントとして、「従来のシステム開発プロジェクトと同様の手法を取ること」、「現行業務を見直してから導入すること」の2点が挙げられる。また運用時も、これまで各企業が行ってきたEUC(エンドユーザー・コンピューティング)に対するガバナンスと、同等以上の工数をかけることも重要なポイントとなる

以上のポイントについて、詳しく解説する。
この記事をシェア
2019.01.11

課題意識

 RPAのメリットは、業務の効率化や高度化(迅速化、ミスの削減など)が実現でき、導入が容易であることだ。

 だが、この「業務の効率化・高度化」には注意が必要だ。
 RPAは人間の代替となるロボットを作ると言われるが、現状は業務をシステム化するに過ぎない。派手な効果の事例が紹介されているが、「それほどの効果が出るのであれば、なぜこれまでシステム化してこなかったのだろうか」という素朴な疑問が湧く。そもそも、大きな効率化ができるのであれば、以前から業務システムとして構築しておくべきだったということにもなる。
 RPA導入の対象となるのは「従来の業務システムやEUCでは実現できなかった業務、かつ業務量が膨大」であることが前提なのである。これに該当する業務がないのに、謳い文句に誘われて導入しようとしても、効果は期待できない。

 また、「導入が容易であること」も問題が起きやすい要因となるので注意が必要だ。
 新しいデジタル技術は「とりあえず使ってみないとわからない」ということで、実証実験(PoC:Proof Of Concept)を行うことが多い。まずは実際に使ってみて、どの程度効果を得ることができるのかを試そうというものだ。
 RPAでは導入コストが低くて操作性の高いツールが販売されているため、PoCに至るハードルは低い。これだけ世の中で騒がれると、「よし、わが社も」という勢いで導入の検討が進む。
 しかし実証実験とはいえ、導入作業が進むにつれて、経営層の「とりあえず」が、担当者にとっては「何とか成功させたい」に置き換わっていく。実際に業務に活用できれば「成功した」と言えるのだが、うまく活用できなかった場合には、その原因を説明しなければならなくなる。うまくいかない原因は様々であろうが、導入責任者は説明責任を負う。場合によっては、余計なコストや人員を使ったという批判を受ける可能性も生じる。
 その結果、「導入して何が何でも活用すること」が最優先事項となる。本来は業務の効率化を目指すのだが、導入することがゴールとなる。手段が目的化してしまうのだ。RPAの場合、導入自体はそれほど難しくないので失敗することはない。現場担当者もRPAを使って業務を開始してしまうので、使っていること自体が既成事実化するのだ。
 
 上記2点を通じて実現されるRPA導入は、業務の見直しが伴っていないため、人的リソースのロボへの転換、および別業務への大胆なシフトまでは実現できない。担当者の責任範囲にそれらが含まれていなければなおさらだ。また、複数の部署で思い思いに導入する事で、ガバナンスの効かないロボットが社内の方々に出現し、トラブル対応に追われるケースも珍しくない。
 
 結果として、確かに業務は楽になったのだが、人手は減らず、担当者の空き時間が増えるだけという状況が生じる。労働時間は減ったのだがコストは上がった、という笑えない話になる。

必要なアクション

  • RPAは現行業務を見直してから導入すべき(効果の最大化)
  • RPAといえどもシステム開発プロジェクトと同様の手法で導入する(最低限のマネジメント)
  • ガバナンスはEUCと同等以上の工数をかける(リスクの最小化)

成功の鍵

RPAは現行業務を見直してから導入すべき
 「RPAの前提として、BPRが必要」ということが謳われることも多い。BPRとはBusiness Process Re-engineeringの略で、業務プロセスを抜本的に再構築し、効率化と高度化を実現することだ。
 もちろん、業務の効率化を進めることは必要だ。非効率になっている箇所を見直すことで業務にかかる時間は短縮し、顧客に提供するサービスのリードタイムは短くなる。業務時間を短縮することになり、働き改革にも直結する。
 だがRPAを導入するにあたり、必ずしもBPRを前提とする必要はない。BPRをしなくてもRPAを導入することはできる。むしろ、プロセスを抜本的に再構築する必要がないからこそ、RPAの導入により簡単に効果を得られるとも言える。
 重要なのは、どのような業務があって、それがどのようなプロセスで行われているのか、を整理することだ。要するに「業務の可視化」である。当たり前のことだが、以下の点が整理されている必要がある。
  1. 業務が一覧化されていること
  2. 各業務プロセスの正常処理と例外処理が整理されていること
  3. どのデータを入力として使い、どのデータを出力しているのかが整理されていること
  4. 業務を実施するのに必要な業務システムが整理されていること
 業務が可視化されていないのに、ロボットの一覧を作れるはずがない。RPA導入は小規模であってもシステム開発プロジェクトであると述べたが、それ以前にシステム化の対象となる業務を整理しておくことが必要なのだ。

 ただし、単に「整理してくれ」と現場に指示しても上手くいかない。業務担当者が必ずしも自身の業務を整理することが得意とは限らず、業務プロセスの全体像が網羅的に明らかにならないことが多い。個別の業務プロセスについても、担当者が思い思いの形式で書き上げてくることも少なくない。業務一覧が整理できたとは言えない状態だ。この状態でRPA導入に着手すると、前述の通り、そもそも思ったような効果が出ないと言う問題につながる。

RPAといえどもシステム開発プロジェクトと同様の手法で導入する
 いくらRPAの導入が容易であるといっても、システムを導入することに違いはない。このための手順を軽んじてしまうと、せっかく作っても活用されない野良ロボットが発生する。RPAを取り扱うITベンダーは、導入の手軽さと効果を大々的に宣伝している。経営や事業部門のトップは「素晴らしい打ち手だ」と判断し、現場への導入を急がせる。指示を受けた業務部門は導入を急ぎ、効果を早く出すことに意識が集中する。 
 システム導入なので、本来ならIT部門が関与すべき課題だ。IT部門が本腰を入れて対応しないとトラブルになりやすい。導入時だけでなく、その後の運用においても果たす役割は大きい。IT部門はこれまでも、IT資産(ハードウエア、ミドルウエア、アプリケーションソフトウエアなど)の管理に頭を悩ませてきた。データ保護やユーザー権限などのセキュリティ上の問題にも気を使ってきた。
 その結果、今やIT部門は普段の業務で手いっぱいの状態だ。「IT部門に相談すると時間や費用がかかる」と苦々しく思っている業務部門も少なくない。結果、業務部門は自分たちで導入を進めようと考える。RPA導入に慣れているITベンダーに発注することで導入を進めようとするわけだ。その結果、野良ロボットが生まれる。場合によっては、野良ロボット以前の問題として、導入にすら失敗することになる。
 それがわかっているだけに、IT部門は導入に対してさらに慎重に姿勢を取ることになる。そもそも新しい技術を導入する際には様々な問題が発生するので、簡単には手を出しにくい。IT部門が主導しておきながら失敗すると、自分たちの責任にされてしまうことを恐れるからだ。しかしながら、発生する問題は従来のシステム開発プロジェクトで起きるものとまったく同じなのだ。RPAを導入する場合に、「業務部門が導入を主導しているが。IT部門は関知しない」状況になっているのであれば是非注意を払ってもらいたい。 

ガバナンスはEUCと同等以上の工数をかける
 RPA導入を成功させるためには、全社のロボットを管理する役割を担う管理責任者が必要だ。管理責任者はロボットを作るためにRPA製品を選定し、導入した製品の機能更新があれば全社に適用しなければならない。導入しているパソコンやサーバーとのバージョンの整合性を確認する必要もある。
 ロボットが利用する業務システムの機能更新にも注意しなければならない。対象の業務システムに変更があれば、ロボットにも変更が必要となる。業務システムの機能更新の内容やタイミングを知っておく必要もある。新しい環境下におけるロボットの動作を確認し、全社的に機能を更新するタイミングも見定めなければならない。
 RPAはよくEUC(エンドユーザー・コンピューティング)と比較される。EUCとは業務部門のユーザーがパソコン上のアプリケーションを活用して、自分の業務を効率化するためにプログラムを組むものだ。RPAと同様に業務部門が主導するために、野良EUCが生まれるリスクがある。
 ただ、RPAに必要な管理は、EUCのそれとは少し様相が異なる。EUCではExcelやAccessといったマイクロソフト製品が使われることが多い。したがって、マイクロソフト製品のバージョンアップには気を使う必要があるため、マイクロソフトがバージョンアップを発表すると、ユーザー企業はこれまで使ってきたEUCを再点検するのが一般的だ。
 一方、RPA製品では「業界標準」と言えるような圧倒的に優位な製品はなく、今はまさに戦国時代だ。どの製品も皆、今後とも継続的に機能を改善していくはずだ。RPAベンダーが買収され、サポート等の体制や方針が一新される事態も想定される。RPAを導入したのはよいが、その後の維持・管理に工数がかかることにもなりかねない。
 つまり、ロボットの管理にはEUCと同等以上の工数がかかるのだ。そして、導入後は更に大変になる。RPA製品のバージョンアップに対応しなければならないだけでなく、ロボットが利用するアプリケーションのバージョンアップにも対応しなければならないからだ。

 以上の3つのポイントをおさえ、RPAの開発と運用に取り組むと、「野良ロボット」に陥るリスクを回避するとともに、RPA導入による効果を上げることができるであろう。