RPAで変革を後押し

上記の各例では、ビジネス主導の戦略の一部としてRPAを実装した場合の成功例を示していますが、実際には各種のプロセスを分析して自動化が最も効果的である作業を特定するには時間がかかります。

またRPAを導入した企業の半数⁴で、あまり輝かしい成果が出ていません。具体的には、RPAで期待されたROIが全く実現できていないか、初期段階では成功しても継続的かつエンタープライズ全体の最適化までは発展していないの、いずれかの状態になっています。

この結果だけを見ると、これはソフトウェアの問題ではないか、と思われるかもしれません。しかしほとんどすべての場合、問題はRPAのソリューションにあるのではなく、その導入方法にあるのです。

特にRPAは簡単に導入できることから、一部の部門で従業員を忙殺している業務や、ボトルネックや非効率性の原因となっている特定のタスクの自動化だけに活用されるという傾向があります。

例えば、取引先から支払い遅延の苦情を受けている企業を想像してみてください。書面の請求書に記されたデータを手作業で入力することに時間がかかっているようで、これが苦情の理由であると考えられます。そのため金融部門はRPAを使用して、スキャンした請求書の内容をSaaS財務システムに入力するボットを構築することになりました。

ボットは順調に機能していますが、調達から支払いまで（P2P）のリード・タイムには改善が見られません。しばらくすると、ボットを構築した担当者が移動になります。誰もボットを更新する方法が分からないという状況になり、その後SaaSベンダーが財務システムを更新した時にボットはお払い箱になってしまいます。

RPAの実装が失敗に終わる可能性のあるさまざまな状況を、分かりやすい例でご説明します。

プロセスの一部のみにRPAを実装:P2PやO2Cのプロセスは、現代の企業でも最高レベルの複雑なプロセスです。両プロセスとも複数の部門と外部の利害関係者が関わっている上に、両プロセス自体に独立した固有の作業が数多く紐づけされて構成されているためです。プロセスの一部を改善すれば多少の効果はあるかもしれませんが、プロセス全体にボトルネックが散在している場合、全体としてはほとんどまったく改善は見られないでしょう。またプロセスの一部に対して個別の修正を行うと、上流や下流で新たな問題や障害を生み出してしまう場合もあります。

不適切なプロセスに自動化を適用:上記の例のプロセスでは、書面で請求書が送られてきていました。請求書はまずその企業宛に郵送され、次にメール室で分類され、お客様窓口に届けられ、さらに整頓されていない机の上でしばらく行方不明になり、ようやく経理に届いた、という経緯だったのかもしれません。このような請求書からデータを抽出する作業を自動化しても、全体的なP2Pサイクルはほとんど加速されません。自動化を図る前に、プロセス全体を見直す必要があります。

不明瞭なKPI:どの企業のリーダーも社内に問題があることは認識していますが、どのような改善が必要かについては具体的に考えていないものです。望ましい成果と測定可能なKPIを特定しないまま、ひと目でわかる非効率なプロセスだけにRPAを絆創膏のように貼り付けているだけなのです。全体のプロセスを俯瞰して検討すれば、非効率なプロセスをすべて特定し、その修正手順を決定し、各修正によるROIを計算してからRPAを効果的に導入できます。

場当たり的なツールの使用で自動化が持続不可能に:上記の例のボットは、ITに詳しい財務担当者がローコードのRPAツールを使用して構築しました。社員はそのボットの使いやすさを大変気に入りましたが、ボットの開発に関する知識は担当者の移動とともに失われました。これではいずれボットは壊れてしまうでしょうし、せっかくのRPAを他の非効率な作業に活用する機会も失われることになります。

継続的なガバナンスの不在:上記の例のボットは包括的な自動化戦略の一部としてではなく場当たり的に構築して導入されたため、ボットをモニターする担当者（およびモニタリング・システム）が不在の状態で、財務システムを更新しただけでボットが壊れることになるとは誰も予測できませんでした。