元事務員が語る！RPA導入の失敗談から学ぶ、失敗と成功のポイント５選

本当にあった失敗談①　『RPAによる誤請求』

以前、私はECサイトを運営する会社にて請求業務を行っていました。 

運用上24時間受注があり、午前10時までに受注したものはお昼の12時までに請求データを印刷会社に渡さなくてはいけませんでした。しかし請求データは複雑で、取得した受注データを加工する必要があり、毎朝出勤後は、時間内に請求データを作成するという作業に追われていました。 

そんな中、少しずつ社内の業務が自動化されていき、ついに私の行っていた請求処理業務も自動化されることになりました。

今まで苦労していた手作業がついに自動化される！私たちは喜んで自動化に取り組みました。 出来上がったRPAは、毎朝私たちが時間に追われながら作っていた請求データを出勤時には作成してくれるという、まさに思い描いた理想そのものを実現してくれました。 

そう思ったのもつかの間。その RPA開発担当者が作成した処理の中に不具合があったため誤った金額を請求してしまう事態が発生しました。 

具体的には、消費税の計算処理部分に問題があり、RPAが自動で計算した金額が実際の請求額と異なっていました。  私たちはそれに気づかず、 RPAが処理した金額そのままに請求書を作成してしまいました。そのため、私たちは再計算や原因追及、作成してしまった請求書の費用に対する後処理等に追われました。

すんでのところでお客様に請求書が渡るという事態は避けられたものの、社内のRPAへの不信感を高めることになりました。 

このように、RPAの導入には実際に業務を理解している業務担当者が十分なテストを行う必要があります。 
また、人手で処理をする業務と異なり、自動化された処理が予想外の問題を引き起こす可能性があるため、リスクマネジメントの観点からも注意が必要です。 

本当にあった失敗談②　『RPAは常にメンテナンスや監視が必要。RPAの難易度は？』

RPAの課題の一つとして、実装には専門知識が必要になる可能性が挙げられます。  

RPAシステムの構築には、自動化されるプロセスの正確な理解とワークフローの設計が必要になる場合があり、そのため、選定するRPAによっては、プログラミングに関する高度なスキルを持った専門家が必要となる場合があります。 

さらに、使用しているシステムの変更等により、正常稼働していたRPAとの連携がうまくいかなくなり、トラブルが起こる事があります。その為、システムのモニタリングや調整が常に必要になります。 

 例えば、こんな事例がありました。 

あるオンラインシステムに対して、RPAが毎日深夜に処理をしていました。ある時、オンラインシステムのメンテナンス作業がRPAが稼働する直前の時間まで行われるという連絡が入りました。 

RPA開発担当者に伝えたところ、RPAの稼働時間と被らないので処理には問題がないと判断したが、実際にはメンテンナンス時間が延長し、RPAが稼働出来ませんでした。 

翌朝。心配になった業務担当者が早朝に確認したところ、RPAの処理が終了していない事が分かりました。急いでRPA開発担当者に連絡をし、緊急対応を行い何とか後続の処理に影響が出ないように完了することが出来ました。 
このように、イレギュラーな状態には注意深く対応する必要があります。 

またその他にも、連携しているアプリケーションやシステムの変更・バージョンアップ等によりRPAで作成した処理が正常に動作しない場合があります。 

システムを利用する業務部門の担当者が、RPAの処理に関係するシステムの仕様変更等を正確に把握し、RPA開発担当者に伝える必要があります。 

もし、上述のような緊急対応が出来るRPA開発担当者がいなかった場合どうなっていたでしょうか？ 

また、システム変更でRPAの処理フローに変更があった場合、社内で即座に気づける業務担当者が退職等によりいなくなった場合どうなるでしょうか？ 

RPAの専門的なメンバーを準備する、もしくは外注するのも一つの手ではあります。しかし、作業フローを常に把握し即座に理解出来るのは、現在作業をしているメンバーではないでしょうか。 

そのためには専門的な知識が不要なRPAを選ぶ必要があります。 

 

本当にあった失敗談③　『RPAに仕事を取られる』

『僕はマクロやRPAに反対だ。だって僕たちの仕事がなくなるじゃないか』 

これは当時の先輩社員の意見です。 

当時の会社の方針として、『ルーティンワークのような単調な仕事は自動化し、人はより生産性の高い作業を行うべき』というものを掲げていました。 

そのため、RPA導入は自然な流れだったのですが、先輩社員からすると今まで手作業により発生していた仕事の一部が自動化されることで、機械に取って代わられる可能性があります。RPAによって自分の仕事が失われることに対する反発だったのでしょう。 

しかし、RPAによって自動化される仕事は、人的ミスで手戻りが多く、作業効率や品質に問題を抱えていました。

RPAがこれらの作業を自動化することで、作業時間の削減や生産性の向上、人的ミスの軽減など、多くのメリットが生まれることが期待されます。 
また、RPAがルーティンのような単調な仕事を請け負うことで、会社の求める「より生産性の高い作業」に私たちは集中することができます。 
恐らく先輩社員はそれらを理解した上で、新たな仕事に取り組むことが不安だったのでしょう 

反対意見の中には、こうした新たな業務に対する不安などが含まれる場合があります。しかし、自動化を行うにあたり業務を熟知した業務担当者の協力は不可欠です。前向きに協力をしてもらう為にも、こうした方へのメンタルケアも必要になる場合があります。その為、RPAを活用した自動化が行われた場合でも、人々が必要とされる分野で活躍できるようにスキルアップ支援を行っていく必要があります。

本当にあった失敗談④　『RPAは無駄だった』

RPAを導入する際には、自動化する対象の選定が非常に重要です。 

当時の会社は成長途中で、手探りで販促やクーポン発行等を手探りで行っている部分が多数ありました。そのため、価格や販売方法が頻繁に変更されていました。 

そのため、作業手順が変更になり、作業者には大きな負担がかかり、RPAによる自動化に取り組むことになりました。 

しかしながらRPAで自動化したものの、価格や販売方法が変更になるたびにRPAを修正する必要が出てきました。 
RPAを導入する際には、本当にRPAによる自動化で根本解決になるのかを見極める必要があります。 

この失敗談から得た成功のポイントは、以下２点です。 

　・ポイント①　頻繁に作業手順が変わる業務は自動化しない 
　・ポイント②　修正が発生しない部分のみを自動化し、徐々に自動化範囲を増やしていく 

せっかくの自動化が、更なるストレスになる場合もあります。
自動化する業務を選定をする場合は、プロセスの見直し等、根本から洗い出す必要があります。 

そのため、ポイント①のように、一旦は自動化を見送る決断も重要です。 
また、ポイント②のように徐々に自動化する範囲を増やすには、試行錯誤をしながらRPAを育てていく必要があります。 

そのため、業務担当者自らが自動化を行える環境が望ましいといえます。  

 

 

本当にあった失敗談⑤　『RPA は AI ではない』

RPAはAIではありません。こんな話がありました。 

24時間インターネット上で受注を行っているので、お客様からの問い合わせも24時間頂きます。 

しかし、タイミングによっては返答に時間を要し結果苦情へと繋がったり、また、問い合わせ時にあった商品への熱意が時間をあけたことにより下がってしまう事がありました。そのため、より早い対応が求められたのです。 

では、RPAで解決できないだろうか？チャットボットのようにRPAに対応をさせれば良いのではないか？そう考えたのですが、残念な結果に終わってしまいました。 

RPAは、作成したロボットにより、ルーチン業務や繰り返し作業を自動化するための技術です。例えば、データ改修やファイルの自動転送、電子メールの送信など、人間の判断が不要な作業を自動化することができます。 

一方、問い合わせへの対応は、人間の自由な言葉と対話をすることが求められます。そのため、判断や分析があまりにも多く、人間的なコミュニケーションはRPAには出来ません。 

この様なケースではAIと組み合わせて利用するなど、より高度な技術が必要なります。 

上記は極端な例ですが、RPAは何でもできる！という幻想は持つべきではありません。 

導入前に、自動化したい業務は本当にRPAで実現できるのか？まずは見極める必要があります。 

一度興味のあるRPAベンダーにてご相談ください。 

 

---

弊社でも無料のご相談を承っておりますので、是非ご活用ください。

 

---

 

最後に

いかがだったでしょうか？ 

私が経験した失敗から得られた教訓や成功のポイントについてお話ししました。 
RPAは様々なルーティンワークを自動化出来る反面、幻想を持ったり反発したりと関わる人の感情も様々です。 

失敗事例から学び、システムの改善や更新を継続的に行っていくことが重要です。 
抱えている課題の解決手段としてRPAは適しているのか ？また、RPAの種類にも着目して考えてみることをお勧めします。 

御社の業務改善に少しでも役立つ情報を提供できたなら幸いです。