【経理】RPA導入に失敗した理由―返金業務の自動化で見えてきた現場とのギャップ
通販会社の返金業務を自動化しようとしてRPA導入に挑戦したものの、最終的には断念することになりました。当時の背景や導入経緯、実際に直面した課題をもとに、RPAのメリットと限界について振り返ります。
はじめに
前回の記事では、以前勤務していた通販会社で行われていた返金業務の全体像と、自動化の難しさについて紹介しました。
今回は、その続きとして、
「なぜRPA導入はうまくいかなかったのか」
について、当時の状況を振り返りながら紹介したいと思います。
今振り返ると、失敗の原因はRPAツールそのものではなく、
「導入するための前提条件が整っていなかったこと」
にあったように思います。
RPAとは？
RPA（Robotic Process Automation）は、なるべくプログラムを書かずに、PC作業を自動化するツールです。
Excelのマクロに近い機能を持っていて、
- コピペ、印刷、ファイルを開くなどの操作を選択
- マウスで画面の位置を指定
- データの計算式を入力 することで、自動化の流れを設計していきます。
返金業務を効率化したいという思いは以前からあった
当時の通販会社では、売上の増加に伴い、返金対応件数も徐々に増えていました。
返金自体は毎日発生する業務ではありませんでしたが、毎月数回、まとまった件数の返金対応が発生していました。
経理担当者は、
- 返金対応リスト
- 振込データ
- 返金明細書
- 宛名用紙
などをExcelで管理しており、それぞれを手作業で作成していました。
一つひとつの作業は難しくありません。
しかし、
- 同じ情報を何度も転記する
- 印刷物ごとにレイアウトを調整する
- 件数が増えると作業時間も増える
といった特徴があり、
「なんとか効率化できないだろうか」
という話は以前から経理内で出ていました。
また、
Excelのデータを別の帳票に転記するだけなら、自動化できそうだ
という感覚もありました。
全社的な業務効率化の流れが生まれていた
ちょうどその頃、会社全体でも事務作業の増加が課題になっていました。
そこで情報システム部主導で、
各部署が自発的に業務改善できる環境を整えたい
という方針が打ち出されました。
背景には、テレオペ部署でRPAツールを導入した実績があったこともあります。
そのため、
「他部署でもRPAを活用すれば、同じように業務改善できるのではないか」
という期待がありました。
さらに、社内では、
- Excel関数を使いこなせる人が少ない
- プログラミング経験者がほとんどいない
- ITスキルにばらつきがある
という状況もありました。
業務改善の余地は大きい一方で、
「専門知識がなくても使える」
という点から、ノーコード・ローコードで利用できるRPAツールに期待が集まっていました。
実は、成功事例のノウハウは残っていなかった
ただし、後から振り返ると、すでにいくつかの問題を抱えていました。
まず、テレオペ部署でRPAを導入した際の担当者はすでに退職していました。
そのため、
- なぜそのようなフローになっているのか
- どのように構築したのか
- 運用上の注意点は何か
といったノウハウが十分に引き継がれていませんでした。
つまり、
「RPA導入実績がある」
ように見えて、実際には知見が組織に蓄積されていなかったのです。
情報システム部もRPA導入経験者ではなかった
また、RPA導入を推進していた情報システム部も、
「各部署が自分たちで業務改善できるようにする」
という考え方を前提としていました。
もちろん、これは間違った考え方ではありません。
しかし実際には、
- 情報システム部内にRPA導入経験者がいない
- どこでつまずくのか想像できない
- フロー設計時の注意点がわからない
という状況でした。
つまり、
誰も「失敗しやすいポイント」を知らないまま導入が始まった
状態でした。
実際にフローを作り始めると想像以上に難しかった
実際にITスキルの低い担当者が返金業務の自動化を進めてみると、さまざまな問題が発生しました。
例えば、
住所の表記ゆれ
全角・半角が混在していたり、長いマンション名が存在したりして、印刷レイアウトが崩れてしまう。
入力漏れ
返金リストの一部が未入力のままになっている。
想定外のデータ形式
同じ項目でも入力方法が統一されていない。
フォルダ名からの日付取得
ファイル保存ルールが変わると処理が止まる。
エラー発生時の原因調査
どこで失敗したのか特定しづらい。
結局、人間による確認が必要だった
さらに難しかったのは、
「本当に正しく処理できたのか」
を確認することでした。
仮にRPAが正常終了したとしても、
- 振込データ
- 返金明細書
- 宛名用紙
の内容は最終的に人間が確認する必要があります。
すると、
最初から目で確認しながら作った方が安心できる
という状況になってしまいました。
RPAベンダーによるフォローが機能しなかった
さらに想定外だったことは、
頼りにしていたRPAベンダーによるフォローがうまくいかなかった
ことでした。
返金業務では、個人情報を扱うためPC画面を直接RPAベンダーに共有できません。
RPAのフロー構築でつまずいた際にベンダーに相談しても、
- なにでつまずいたのかがわからない
- PC画面の状況を口頭で説明してもうまく伝わらない
- 説明されたとおりに設計しても失敗する
といった状況で、RPAのスキルを現場の実務に合わせてうまく活用できませんでした。
最終的にRPA導入は断念した
結果として、この返金業務のRPA化は正式導入には至りませんでした。
しかし、この経験を通じて感じたのは、
RPAが悪かったわけではない
ということです。
RPAには、
- プログラミング知識が不要
- 小規模な自動化に向いている
- 現場主導で改善できる
という大きなメリットがあります。
一方で、
- 例外処理が多い業務
- データ品質が安定していない業務
- 保守担当者がいない環境
では、思ったような効果を得られないこともあります。
今振り返ると感じること
当時は、
「RPAで自動化する」
ことが目的になっていました。
しかし本来は、
「どのように運用すれば、人間の負担を減らせるか」
を考えるべきだったのかもしれません。
そして、
技術よりも先に、業務そのものを理解することが重要だった
ということを、後になって強く感じました。
おわりに
今回紹介した内容は、決して特別な失敗談ではありません。
おそらく、多くの会社で似たような経験があるのではないかと思います。
次回は、返金業務の中でも特に苦戦した、
「住所データの扱い」
について紹介したいと思います。
「住所を2行にきれいに収める」
という、一見簡単そうに見える問題が、実は想像以上に奥深いものでした。