RPAを導入した企業の約7割がなんらかの問題に直面し、RPAの効果を実感できていないと言われています。

この7割という数字は言ってしまえば、多くの企業はRPAを導入したにもかかわらず、失敗に終わっているとも言えるのではないでしょうか?

「人手不足を補いつつ大幅な経費削減ができる」、という謳い文句のもとRPAを導入したものの、失敗に終わってしまっている現状があると言えるでしょう。

ここでは、RPAの導入でありがちな失敗する原因、そして成功して生産性を上げるためには何をすれば良いか解説していますので、参考にしてみてくださいね。

RPAの導入でありがちな失敗パターン!

その①RPAの導入前に定型業務を全て洗い出すのは失敗のもと。

RPAは定型業務を自動化するツールだから、導入前にまずは定型業務を全て洗い出しましょう、と言う話があります。

RPAの導入を検討している企業の担当者の方であれば一度は聞いたことがあるフレーズではないでしょうか?

実はこれは、半分正解で、半分間違いです。

確かにRPAを導入するからには、どんな事務作業を対象とするかは大事なことですが、全ての業務を洗い出すのは実際には現実的でないケースが多々あります。

特に、ある程度の規模の会社ともなると、実際に現場で行われている業務は支店や支社ごとに違いがありますし、その違いを全て把握するのは非常に困難です。

その状態で、本部の情報システム部門がRPAを導入する為に、各支店・各支社に、「RPAの対象となる定型業務を洗い出すように」、と指示を出したとしても、最終的にそれらの業務をまとめ上げるのは困難です。

だからといって、全く対象業務を決めずにRPAの導入を検討するのも本末転倒です。

何も決めずにRPAを導入すれば、何を自動化すれば良いか、現場は迷ってしまいます。

RPAを導入する時の対象業務の決めたのコツとしては、定型業務がどの程度あるか?というのを把握することがポイントです。

RPAの対象業務となり得るのは、あくまでも定型業務になります。

言い換えれば、定型業務であれば、RPAの対象とすることができます。

そして、仮にその定型業務が全て人が行うのではなく、RPAの対象業務にした時に、現場の負担が減るかどうかを考えてみます。

そこで、もし現場の負担が減ると考えられるのであれば、RPAの導入する価値はあるという判断がすることができます。

その②トップダウンでRPAを導入を進めるのは危険!

トップダウン形式で経営層や管理層でRPAの導入を進める場合は要注意です。

なぜなら、RPAはあくまでも現場の定型業務を自動化させるツールですが、多くの経営層や管理層は現場の細かな定型業務をどのように実施されているは知らないことが多いからです。

つまり、RPAを導入することを決定した場合は、それを進めていくには現場主導で進めるのがRPAの導入を失敗に終わらせずに成功に導く最良の導入方法になるんですね。

ただし、そうはいっても一定規模以上の企業であれば、情報システム部門が関わらざるを得ないケースもあると思います。

そんな時でも、情報システム部門はあくまでも、現場のロボット作成を支援する形で関わるのが良いですね。

例えば、「ウェブサイトの情報を取得してデータを作りたいんだけど、RPAをどんなふうに操作したら良いのか?」、という現場からの質問に対して、リアルタイムで操作方法を教えられるような体制があれば理想的ですね。

その③ロボットの作成に時間がかかる

これは企業の情報システム部門がロボットを作成する場合にありがちな失敗パターンです。

情報システム部門がRPAのロボットを作成する際、現場の作業内容を洗い出しきれず、作ってはみたものの、作業内容に抜け漏れあり、その結果なんども作り直すことになる事があります。

 現場と情報システム部門のやりとりには手続きが必要な場合もあり、1つのロボットを作るのに1ヶ月以上かかってしまった例もあります。

RPAのロボットを導入した企業では何十個、何百個と導入していくのが通常ですが、これではいつになっても当初期待していた効果を得ることができません。

この傾向は大きな企業になればなる程起こりがちな失敗です。

やはり、RPAを作るのは現場が主導していくのが最も成功確率が高い、と言えます。

その④現場がRPAのロボットを作成できない

RPAのロボットは、現場の作業負担を軽減するものであるから、現場に作ってもらうのが良いです。

ですが、この時に起こりがちな問題が、現場がスキル不足でRPAのロボットを作れない事。

一般的なRPAのふれこみでは、プログラミング知識がなくても作れると言われていますが、プログラミン知識がなくても作れるといっても、中にはプログラミングの考え方自体は必要なRPAソフトが結構たくさんあります。

つまり、ロボット作成の難易度が高いRPAソフトです。

システム部門の人たちからすれば簡単だという認識はあっても、普段プログラミングに触れていない人からすれば難しく感じることはたくさんあります。

もし、難易度の高いRPAを導入してしまった場合で、現場にロボットを作ってもらおうと思っている場合は、まずは現場のロボット作成スキルを高める必要があります。

だけど、よくよく考えてみると、この状態はおかしいですよね。

RPAを導入する目的は現場の業務を効率化するはずなのに、新たな業務が増えてしいまったことになります。

解決策としては、現場が作れる難易度の低いRPAの導入です。

RPAソフトの中には、直感的に操作できるものもたくさんありますから。

その⑤ロボットが止まる

RPAのロボットは環境に敏感に反応するで、動作が止まってしまう事があります。

例えば、操作対象としているウェブサイトのデザインが変更したことによって動作が停止してしまったり、ネットワーク慣用が混雑していて、作業を始める前までに前の処理が完了できずにエラーで止まってしまう場合などがあります。

ロボットが頻繁に止まってしまえば、現場はロボットの復旧までは手作業で業務を実施しなければいけませんし、さらには復旧作業という新たな業務が増えることになります。

また、外部に復旧作業を外部に依頼すれば、時間もコストもかかってしまいます

対策としては、どのような場合にRPAのロボットが止まってしまうか?を予めRPAベンダーに問い合わせておきましょう。

また、ロボットが止まった時の対処方法を事前に決めておくことが肝心です。

その⑥RPAの維持管理、メンテナンスコストは意外と高い!

RPAの導入目的の1つに自動化によるコスト削減があります。

そこで注意して欲しいのが、RPAのロボットは作ったらおしまいではなく、その業務内容が変わればロボットの修正をしなければならない、という事。

 つまり、メンテナンスが必要だという事ですね。

RPAの導入規模にもよりますが、メンテナンスをするためには、人員も時間も必要になります。

RPAを導入するという事は、それなりコストが発生すると考えておくべきでしょう。

(ただし、RPAのライセンスを3つか4つぐらい導入すれば十分、という規模であれば、このメンテナンスコストについてはそれほど意識しなくても良いでしょうね。普段RPAのロボットを使っている人が1ヶ月11回チェックすれば事足りる事がほとんどでしょうから。)

 そして、維持管理・メンテナンスコストを考えた時に注意すべきものが稼働率です。

RPAのロボットをどんどん作っていってRPAの稼働率が高い間は、RPAにかかるコストは意識しなくてもほとんどの場合は十分な仕事をしてくれて、コストに見合った分の作業をしてくれていると考える事ができます。

でも、「最近、あんまりRPAのロボットを動かしていないな。」と思えるようになってきた時はもしかしたら、RPAの維持管理・メンテナンスコストに見合っただけの作業をしていないかも知れません。

 ライセンス数を減らすなど、RPAの導入規模を縮小させる事も検討してみましょう。

RPAの導入を失敗に終わらせず、成功に導くコツはスモールスタートにあり!

RPAは魔法のツールかのようにもてはやされる事がありますが、これまでにも述べてきた通り、RPAを導入したからといって、必ずしも業務の効率化に成功するわけではありません。

むしろ、多くの失敗を乗り越えて初めて成功すると言っても良いぐらいです。

そこで、1つのコツを提案します。

RPAでいきなり定型業務の全てを自動化するような発想は捨て、小さい定型業務を少しずつ自動化させていく、というスタンス。

そして、そのロボットを作るのは、情報システム部門ではなくて現場の利用者。

現場のRPA利用者が自ら業務を少しずつ自動化させることで、「これができるんだったら、あれもできるかも?」と思うようになればRPAの導入は成功するでしょうね。

例えば、1つのロボットが所要時間10分の業務しかこなしてくれないとしても、それを10個作れば、所要時間100分の業務をこなす事になります。

そして、もしその10個のロボットが毎日発生する業務を自動化させてくれているとしたら、1ヶ月20営業日としても、2,000分(33.3時間)の業務をこなしている事になります。

この自動化された33.3時間は、他の業務に費やすことができますが、そのインパクトは小さいものではないでしょう。

 

また、RPAによる業務の自動化の効果を実感している企業では、業務内容自体をRPA化、つまり自動化させるような仕組みに変えてしまう企業もあります。

自動化させる事ができない業務とは、つまり人の判断が介在する業務と言えます。

人の判断が介在する業務の流れとしては

1.データ収集

2.人の判断

3.データ収集

4.人の判断

といったように、データを収集・認識してから人の判断が介在します。

仮にこのデータの収集・認識をひとまとめにしてしまうと以下のような流れに業務を変更できます。

1.データ収集

2.データ収集

3.人の判断

4.人の判断

こうすれば、最初の1と2はRPAによって自動化する対象となり得るでしょう。

RPAの導入をする際、今ある業務を自動化することに意識が向きがちですが、そもそもRPAの導入目的は業務の効率化にあるはずです。

であれば、今の業務内容を分析した時に、定型業務に切り替えることはできないか?という視点は非常に重要です。

定型業務に切り替えることができれば、RPAによって自動化することができますからね。