多くのRPAプロジェクトを見てきて失敗に繋がる様々なパターンが見えてきました。失敗とは言えないまでも、RPAは明らかに業務効率化の効果が出せるツールにもかかわらず、時間ばかりを浪費して一向に前に進まない例や定量効果を上層部に説明出来ずに中断してしまう例など、こちらでは同じような失敗に陥らない為の失敗RPAプロジェクトの共通点をご紹介しています。
RPAツールに関する多くの誤解
RPAツールに関しては各ベンダーによるプロモーションの効果もあり、多くの誤解や幻想が生まれているようですので、ここで改めてRPAツールに関する認識を確認しておきたいと思います。
「RPAツールは簡単」という誤解
確かにRPAツールはソフトウエアとしてその使い方が難しいものではありませんが、その「導入が簡単」との誤解があるようです。「ツールとしての使い方が簡単」と「導入が簡単」は全く違います。
また、RPAはツールとしてもこれまでに無かったカテゴリーのツールであるため、最初にRPAツールを起動して初見で使いこなせる人はまずいません。
そもそも、どう動くのが正しい姿なのかイメージ出来ていない方が殆どかと思いますので、「どこからどう触って良いのか全く想像が出来ない」と感じる方が多いのも当然です。
「プログラミング不要」の誤解
これに関しても大きな誤解があり、確かにプログラムを殆ど書かずにRPAのフローを作成することは可能なのですが、プログラムを書ける必要はあります。
プログラムを書かなくていい ≠ プログラムを書けなくていい
処理の流れをフローとして記述するとしても、それはあくまでプログラムフローをコードではなくフローで書くと言うことなのです。そこにはプログラムを実際に記述する場合の条件分岐や繰返し処理、変数の扱いなどの基本的な理解やデバッグしていくスキルが必要となります。
実際にプログラムを記述しないだけで、プログラムを書ける必要はあるのです。また、予め揃っている機能部品では不十分な場合もあり、その様な場合はやはり実際にプログラムを記述していく必要があります。
その意味でサーバーやネットワーク環境、メールシステムの設定などの基本的なITの知識がないと、実運用としてジョブに設定し時間起動したり、引数を渡してサブルーチンを呼び出すなどフローの構造にも制約を受けると考えられます。
「繰返し単純作業であれば何でも出来る」の誤解
これは誤解と言うか、限界はあるもののある程度は出来るのは出来るのですが、ここにも落とし穴があり、
出来る ≠ 向く
と考えるべきです。
特に、RPAに複雑な判断ロジックを組込むのはお勧めしません。なぜなら、その実装方法が下図のようにプログラムで記述する判断ロジックと同じように順次判断処理として記述するため、可視性が極めて悪く、恐らくそのまま実運用すればロジックミスによる業務への影響や保守の問題が多発するものと考えられます。
可視性（保守性）が高いとは言えない
上記でもご説明しましたが、RPAツールではプログラムを記述する代わりに処理フローを書くことで処理させたい業務の流れを教え込んでいきます。それは、業務フローのレベルではなく、あくまでプログラムを記述するレベルのフローなのです。
従って、プログラムをある程度記述したことがあって、読み解ける方であれば容易に理解できる（むしろ楽）かと思いますが、一般の業務ユーザーが何の前提知識もなく理解し、作成・保守していけるものではありません。
RPAツールに複雑な判断（分岐）が入るフローを作成することも可能ですが、恐らくメンテナンス不能になるでしょう。
失敗RPAプロジェクトの共通点
◆ 十分な体制・計画を持たずに初めてしまう
このパターンは結構多いように思います。しっかりとしたプロジェクト体制を組んで計画的に進めていくわけでもなく、RPAツールだけを購入してIT部門の一部でなんとなく（ひっそりと）やっている感じです。
IT部門内にもRPAツールによって自動化出来る業務は多々あるかとは思いますが、やはり業務部門を巻き込んでPC繰返し雑務を自動化することで大きな効率化効果が得られるでしょう。
また、IT部門の担当がひっそりと（片手間で）やっているため通常業務に追われ、十分な時間をRPA実装に割けないまま期間だけが過ぎてしまうパターンとなり非常にもったいない状況です。
◆ トレーニングも受けずに最初から独学で進めようとする
RPAツールは使い方自体が難しいものではありませんが、何も教えてもらわずに最初から使い方を探って使いこなせるようになるには結構な時間を要すると考えられます。そこには時間軸の概念が抜けていて、RPAは明らかにROIを出せるツールであるにも関わらず最初のツールの使い方の習得に無駄な時間を浪費し、投資効果の回収が遅れるだけの結果となってしまっています。
やはり最初はだれかにツールの基本的な使い方やフローの作成方法を教えてもらい、折角購入したRPAツールのライセンス期間を無駄にせず効果を享受するほうが遥かに費用低減につながると考えるべきです。
◆ 明確な目標・目的を持たずなんとなく始めてしまったため、「出来た分だけ」の効果に留まる
これも上記につながる点ですが、しっかりとしたプロジェクト体制で計画的に進めるのではなく、RPAツールのライセンスだけを購入して「なんとなく」やっている感じです。
明確に上層部にコミットした目標・目的もないため、「出来た分だけ」の自動化になってしまい、いつの間にか「あのRPAツールは使えない」などと結論付けられ自然消滅でしょうか。
◆ 業務整理が出来ない
この失敗パターンが一番多い様に思いますが、「RPAツールの使い方が難しくない」が「RPAツールの導入が簡単」にいつの間にかすり替わり、ツールの使い方、シナリオ作成に終始してしまいます。
ERPなどもそうなのですが、やはり導入過程で関連部署との業務分担などの業務整理を行う必要があり、これがないままでは効率化効果も限定的になってしまい、狭い範囲の小さなRPAロボットが大量に出来てしまう結果となってしまいます。
そして、どこで、いつ、どの様なRPAロボットが動いている（動くべき）なのか管理・メンテナンス不能な状態に陥ってしまうのです。
◆ 現場の業務ユーザーを十分巻き込めない
業務ユーザーへの趣旨や目的、その後の組織・業務分担、そして会社が本人に求めているの役割、処遇などに関するしっかりとした説明がないまま、十分業務ユーザを巻き込めずに進めた為に陥る失敗です。
業務ユーザにとっては、自分の仕事をロボットに奪われるのではないか、と疑心暗鬼になり自分の仕事の流れを抱え込んでしまいがちです。こうなってしまうと感情的な縺れもありなかなか前に進まず、効率化効果も得られない結果となってしまいます。
自動化したい業務を実際に行っている業務部門ユーザの協力は絶対に必要です。こうなってしまう前に、誤解を招かないようにRPAによって自動化した後の組織や業務・役割分担などに関して協議し、納得感のある進め方をする必要があります。
◆ 周辺部署を巻き込めずこじんまりと手元だけの自動化に終始してしまう
RPAツールによって業務を自動化し、大きな業務効率化の効果を享受しようとすると、どうしても現状の組織割りの中に閉じてRPAフローを作成するだけでは限界があります。
やはり、自部門が担っている業務の上流・下流、もしくは組織横断（関連会社の同じ部門）など広範囲で業務を整理し、自動化していくことで大きな業務効率化の効果が期待できます。
◆ 導入効果を定量的に出せていない
これは、プロジェクト当初から計画的に（定量）効果を算定する考え方が無かったため、業務の自動化は出来たが結局「どの程度効率化されたのか」の説明が出来ない結果となってしまうと言うことです。
やはり、RPA導入の意思決定をしたほうとしては結果がどうだったのか、どの程度業務が効率化されたのか知りたいのは当然です。その説明がないまま、「より大々的に全社規模でRPAを展開する」となる会社はないでしょう。
仕事としてやっているい以上は目標をたてて、達成する。そしてその結果説明責任が伴うのは当然でしょう。
まとめ：結局、失敗の原因はプロジェクトの進め方の問題
これまで、RPAプロジェクトに関して失敗に陥る典型的なパターンをご紹介してきましたが、結局総合すると、やはりプロジェクトは対象が何であれ計画が最も重要となります。その計画には、重要な要素として、プロジェクト体制やアプローチ、目的・目標など当然と言えば当然のことが予め決められている必要があります。
また、どの様な変革プロジェクトでもそうなのですが１回失敗すると、同じテーマやリーダーで再チャレンジする場合のハードルが格段に上がってしまう点も忘れてはいけません。やはりどの様なプロジェクトも当初の計画が成否の８割を占めるのです。
