複数のベンダーのRPAツールは、シンプルなワークステーションロボットから複雑な企業用ソフトウェアへと急速に進化しました。しかし、多くの組織では、選出したベンダーがITとビジネスアーキテクチャの要件を満たすことができず、RPA技術の認知度はなかなか上がりませんでした。ITアーキテクチャ: アーキテクチャ基準に適合するための新しい技術がIT部門に必要であるといった、一般的な認識があります。技術の例としては、オープンで拡張ができるもの、安定していて十分に文書化されているもの、一般的なスキルセット、また堅固なセキュリティコンプライアンスがあります。これはRPAツールにも当てはまります。ビジネスプロセスアーキテクチャ（BPA）: 選出されたRPAツールには、あらゆる重要なビジネスプロセスにわたり自動化する能力があることが不可欠です。仮想環境においてなのか、OCRを使用しているのか、コグニティブインテリジェンスを必要としているのかなどです。BPAでは、これらの重要なプロセスを関係性と相互依存性もあわせて定義、また文書化し、ベンダー選定基準をまとめるための包括的なフレームワークを作成します。

POCのポイントは、RPA技術が実現可能か確認することではありません。POCの重要な目的とは、ビジネスケースの仮定をテストして最善の実装モデルを検証し、RPAインテグレーションと技術パートナーの評価をすることです。しかし、いまだ多くの組織が、RPA機能の確認をPOCの目的としてしまっています。この間違いが、POCが意味を成さず、すぐに実施できず、RPAが勢いを失う原因となるのです。意味を成さない理由は、数ある堅固なビジネスケースがすでにこの技術が機能することを証明しているためです。すぐに実施できない理由は、RPAを確証するPOCでは、特定の組織において機能するかどうかの洞察は得られないためです。RPAが勢いを失う理由は、明らかな次のステップがないためです。POCは、ジャーニーにおけるさらに決定的なパイロットとなるような基礎を作るよう、そしてパイロットに進むための承認に必要となる答えと確証を得られるよう考案されるべきなのです。

RPAパイプラインの管理が緩いと、複雑なプロセスの自動化しか候補に残らなくなることがよくあります。おそらくこれは、「RPAは何でもできる」といった過信によるもの、もしくは、よりシンプルな節約の機会よりも高度に複雑化した問題を選ぶといった主観的判断によるものであるかもしれません。どちらの場合でも、規律された優先順位を放棄してしまうのは間違いです。少なくともRPA実装の最初の満一年は、最低1FTEを削減する見込みがあるか実証するため、選択されたプロセスの複雑性を低度、あるいは中度までに制限しておくとよいでしょう。

収穫逓減の現実を見落とし、完全に自動化されたエンドtoエンドプロセスの考えに縛られてしまう組織があります。複雑なステップを自動化することに集中しすぎて、再設計してこれらのステップを排除するといった考えを見落としてしまっています。RPAが低コストで、既存システムを活かせる可能性が高いという性質を持つことを覚えておくのは大切です。他の自動化技術と違い、プロセスステップの部分的な自動化のみで高いROIを獲得することができます。ただ、プロセスに自動化を拡張しすぎてしまうと、実装経費が大幅に増加するためROIの低下につながることがあります。大抵の場合、ロボットを複雑化したルールに設定するよりも、プロセスを最適化する方が賢明な方法だと言えるでしょう。