RPA導入時に大抵の意思決定者は「成功事例」を求めてくるものだが、実は成功事例よりもその裏に隠れた「失敗事例」のほうが学ぶものが多い。成功事例はその組織ならではの条件で成功している場合が多いが、失敗は多くのケースに適用できるからだ。この記事では先人たちの失敗事例から学んでいくことにしよう。
RPA導入の現状
日本におけるRPA導入率は38%前後まで来ているという※1。大手企業に限ると51%まで導入が進んでいる。しかし、一方で、複数のタスクをスケールできている企業は16%に留まるという※2。また、大手企業に限っても8割が年5万時間以内、つまり従業員人数換算で約25人以下の削減効果となっている※3。調査対象となっているのはいずれも従業員1,000名以上の大企業であるので、全体で言うと2.5%未満の効果ということになる。まだ、多くの企業ではRPAによる効果をスケールできていないことになる。
課題は導入の各フェーズで異なる
1つ注意をしておかなければならないのは、RPA導入の課題は最初の検討・導入フェーズと、導入加速・スケールフェーズで異なることである。つまり、最初の段階では見えていない課題が後から出てくる可能性があるため、それを最初から予見して計画をする必要があることである。これを怠ると、導入がある程度進んだ段階で頓挫してしまうことになりかねない。
失敗事例でよくあるパターン
そこで、いままでの先人たちのRPA導入事例をもとに、フェーズを2つに分けてそれぞれでどのような課題や失敗が多いかということを見ていくことにする。
1.検討・導入フェーズ
1-①業務の可視化や選定が不十分なまま始めてしまう
最初のフェーズでよくあるのは、自組織で行っている業務の全体像が良く見えないうちに始めてしまって、後で計画が狂ってしまうパターンである。適用しようと思っていた業務の可視化がされないうちに計画をすると、後でRPAで対応できない部分が出てきたときに計画変更が必要になることがある。場合によっては導入前よりも時間が増えてしまうこともあり得る。そのような場合は、100% RPAで自動化することを求めずに、人と連携させる方法を模索するとよい。
理想的には、業務選定をする際にはある程度大きなボリュームで難易度が高くないものを最初に選んで始めると効果が出やすいだろう。また、いままでの業務のやり方をそのまま踏襲するのも短期的にはよいが、あらかじめRPAで対応しやすいように業務整理したうえで適用できた方が効果も上がりやすい。
1-②導入の目的やKPIを決めずに始めてしまう
RPAを導入することで、経営陣も現場も何らかの効果を狙っているはずであるが、それが明確にならないまま開始してしまうと、結果に対して成果があったのかどうかが不明確になり、さらなる投資計画を立てづらくなってしまうことも多い。一番わかりやすいのは「業務削減時間」であるが、大きな成果を得るには一定の時間と工数が必要になるため、最初のフェーズのKPIとして業務削減のみを見てみてしまうと、成果が出ていないように見えてしまうことが多い。
RPA導入による効果としては、もともとの労働人口減少による人手不足、単純作業を行う人材の確保が難しくなっているところのカバー要員でもあり、単純作業から解放された従業員が本来やるべき業務に集中できるようになったことによる効果、ワークライフバランスの向上も効果として挙げてよいだろう。また、RPAの導入を従業員に人員整理ととらえられてしまうと、経営者と現場の対立が起きてしまうため、これも注意が必要である。
加えて、業務の効率化、自動化はRPAだけを使ってやるものでもない。他の手段を使ったり、従業員との連携で実施してもよいものもあるだろう。RPA導入の手段が目的化してしまわないように注意が必要である。
1-③ 従業員のスキルがついていかない
RPAツールを導入し始めるときに判明するのが、従業員にRPAツールを使わせてみたが、本当に基本的な操作以上のことを行おうとすると意外と難しい、という場合があることだ。RPAツールにもさまざまなものがあり、プログラミングの知識やスキルは不要であるといわれているのだが、一般的に広く使われているRPAツールの中には、実はVB.NETやVBScriptの知識が必要なものがある。
プログラミングスキルのある従業員がプロジェクトメンバーに含まれている場合はよいが、そうでない場合は恒常的に外注エンジニアの支援が必要になってくる場合があり、月額一人当たり百数十万円以上のコストが追加でかかってくることになる。
2.導入加速・スケールフェーズ
2-① スキルを持った人材がいない
この内製化の問題は、プロジェクトのフェーズが進んでくるとより大きな問題となってくる。適用対象の業務が増えるほど、エンジニアが必要な場合のコストも膨れ上がってくるからだ。また、プログラミングスキルがある従業員が多くいない場合は、特定のメンバーが抜けてしまうとRPAプロジェクトが成り立たなくなってしまうケースも出てくるため、きちんと内製化ができるRPAツールを最初から選んでおくことが必要となる。
2-② 運用・管理がまわらなくなる
これも検討・導入フェーズではあまり問題にならないが、導入が進んで大規模化してくると問題になってくるケースが多い。ロボット数が増えてくると、管理がきちんとされない場合は野良ロボットの問題や、状況を把握するために従業員が手動でレポートを作って工数がかさんでしまうケースが出てくる。
導入規模が小さい際にはデスクトップ型RPAがお手軽に導入されるケースも多いが、そのままスケールを目指そうとするとうまくいかない。デスクトップ型RPAはあくまでも身の回りの自動化をする場合にとどめ、スケールを目指す業務には最初からサーバ型RPAを選択しておくと手戻りなく進められるだろう。
2-③ 他組織の協力が得られない
これもスケールの段階になって課題になってくることが多い。RPAを継続的に組織内で広げていくための動機が続かず、しぼんでしまうケースも出てきてしまう可能性がある。プロジェクトを継続するには、組織としての仕組みがいくつか必要になってくるであろう。重要なのは、関係する従業員にいかに「当事者意識」を持ってもらってRPAプロジェクトに巻き込まれてくれるか、というところにある。
そのために必要な仕組みとして、以下のようなものが挙げられる。
- 教育制度、社内エバンジェリスト
- レコグニション
- 上司からのサポート
- 社内プロモーション
加えて、RPAプロジェクトを推進する強い旗振り役がいるかどうかでもスケールの度合いが変わってくることがある。経営陣や現場リーダーで、それぞれ旗振り役にあたる人材が求められる。特にコミュニケーション力が強く、プロジェクトメンバーとうまくコミュニケーションを取って動機付けをできるような人材が望まれるであろう。
このように、導入のフェーズによりさまざまな課題が出てくる可能性があるので、あらかじめ予見して動けると、より成功に近づけるはずである。
※2 Capgemini, A game changer for business operations 2020
※3 日経コンピュータ 2019.10.31 『RPA大調査90社が明かした成果・実態・工夫』