ロボティック・オペレーティング・モデル（ROM）がRPA成功に不可欠な理由

「RPAに携わるすべての人が『良い』プロセスを知っているわけではありません。ビジネスメリットがほぼなく、後で問題を引き起こす複雑なロジックで開発されているケースもあります。」

Benjamin Franklinが「予防の一オンスは治療の一ポンドに値る」と言ったとき、彼は具体的にロボティック・プロセス・オートメーション（RPA）とロボティック・オペレーティング・モデル（ROM）の重要性を指していたわけではありません。しかし、まさにその通りだったかもしれません。

RPAは、エラーを発見してから修正するのではなく、完全なジャーニーを最初から定義して実装するのが最適です。

Blue PrismのROMはまさにこの目的で設立され、7つの柱で構成されています：

• ビジョン
• 組織
• ガバナンスとパイプライン
• デリバリー手法
• サービスモデル
• 人材
• テクノロジー

各柱には、RPAソリューションを導入する際に考慮すべき様々な事項が含まれています。

Blue Prism ROMへの準拠は、RPA卓越性センター（CoE）が停滞するのではなく、有機的に繁栄し成長することを保証します。これがRPAを容易にスケーラブルにし、企業が歩ける前に走ろうとするのを防ぎます。

ビジョン

まず、RPA導入の戦略と目的を検討する必要があります。データ品質の向上、コスト削減、より迅速かつ正確なレスポンスによるユーザー体験の向上を目指しているのでしょうか？
理由が何であれ、RPA戦略が全社戦略とどう整合するかを理解することが重要です。こうすれば、スケールする準備ができたとき、すでに支援を得られています。

ビジョンを確立したら、外へ出て声を上げましょう！ 組織のトップからの賛同を確保し、それがポジティブな形で下方へ浸透しているか確認します。

組織目標に対する感染力のある情熱を持つRPA責任者を見つけ、ロードショー、ワークショップ、その他の施策で全社の人々を巻き込みます。RPAチャンピオンも好意を広め、更なる自動化機会を特定できます。

適切な人材を早期に巻き込めば巻き込むほど良いのです！

組織

次のステップは、組織モデルの計画です。RPAをビジネスのどこに位置づけ、成長計画はどうなっていますか？ 集中型アプローチは組織全体をカバーします。既存のCoEに組み込むのが有益な場合もあります。しかし、デリバリーチームが限られているなら、ビジネスのあらゆる隅々から「自分たちのプロセスを自動化してほしい」とノックされることになるので、期待値を管理する必要があります！

連合型アプローチは、RPA機能が特定の機能内にありながら、ビジネス全体にスケールし、中央チームが標準とベストプラクティスを管理するものです。組織全体にデリバリーポッドを作り、それぞれが自分の自動化プロセスの特定とデリバリーを担当し、CoEによってガバナンスされることで実現されます。

事業部門型アプローチは最も推奨されません。複数のRPA機能が組織全体で別々に運営され、別々のインフラ、別々のガバナンス、別々のチームを持つためです。コスト効率が悪く、真のスケールを妨げます。

ガバナンスとパイプライン

RPAに携わるすべての人が「良い」プロセスを知っているわけではありません。ビジネスメリットがほぼなく、後で問題を引き起こす複雑なロジックで開発されているケースもあります。

何が真に「良い」プロセスかを明確にすることが重要です。二値ロジック、高度にトランザクショナルで信頼性の高いターゲットアプリケーションなどは、注目すべきポイントの一部です。

「良い」の定義が明確になれば、ガバナンスを通じてプロセスを特定できます。こうすれば、適切な質問を適切な聴衆に投げかけられます。

例えば、自動化に理想的に見えるプロセスを見つけても、ガバナンスボードのIT担当者から「ターゲットアプリケーションの予定パッチが2ヶ月後にある」と知らされるかもしれません。パッチが適用されるまで、要素を再スパイし、プロセスを保留する必要があります。

ガバナンスボードで議論される他のトピックには、需要創出、すなわちビジネス内でRPAへの需要をどう生み出すかがあります。従業員への適切なプロセス特定インセンティブ、社内コミュニケーション、エンゲージメントのためのワークショップ開催などが推奨される手法です。

デリバリー手法

これらのプロセスを特定したら、どう自動化ソリューションとしてデリバリーするのでしょうか？

定義フェーズで情報を誤って取得（または取得し忘れ）ると壊滅的な影響を及ぼすため、プロセス情報を取得するには知識豊富なSME（サブジェクトマターエキスパート）が必要です。適切な聴衆でプロセスウォークスルーを行うことも価値があります。

開発者にBlue Prismでできるだけ早くソリューションを自動化させたくなるものです。しかし長期的には、もう少し時間をかけておけばよかったと後悔することになります。

まず、「To-Be」プロセスを文書化します。ロボットプロセスは人間プロセスとどう異なるか？ Blue Prismで構築するためのブループリントは何か？

このソリューションに必要なビジネスオブジェクトを概説し、環境内に既存のオブジェクトと比較します。これにより、再利用可能なオブジェクトライブラリが拡充するにつれ、開発時間を前倒しできます。「To-Be」がビジネスと合意され、設計責任者/リード開発者が提案ブループリントを承認し、必要なピアレビューを実施したら、開発を開始できます。

テストでサインオフし、ビジネスが満足していることを確認します。テストとリリースフェーズでは他にも重要な成果物があり、それらを怠らないことが極めて重要です！

サービスモデル

プロセスが本番環境に入ったら、適切なサポート体制を整える必要があります。

ロボットがビジネス紹介を運用チームに手動入力のために戻していませんか？ 開発者がロボットの予期せぬ動作に備えて待機していますか？ ロボットリソースの損失を防ぐための災害復旧計画はありますか？

避けなければならないのは、不十分なサービスモデルによってロボットリソースを失うことです。

人材

すべての優れたチームは、最初から将来の成功を計画します。開発者が経験不足なら、避けられないRPAのペインポイントに対処できません。高品質なリード開発者の任命は必須ですが、現在の市場ではこうした人材を見つけるのは極めて困難です。

開発者は、Blue Prism開発とプロセス分析の両方で最高水準にトレーニングされる必要があります。これにより、ハイブリッドな役割を遂行できるようになり、経験豊富なコンサルタントから現場サポートを受けながら業務を進められます。

開発チームが成長し続けるにつれ、設計責任者を任命して標準を維持し、コントロールルームモニターを配置して本番ロボットを管理すべきです。

最後に、いつ採用が必要かを計画します。これにより、デリバリーチームの継続性と品質を維持できます。

テクノロジー

7番目の柱は、どの技術的アプローチを取るかに関する考慮事項です。仮想マシンのセットアップ、将来のスケーリングのためのライセンスプロビジョニング、災害復旧などを検討し、クラウドベースのソリューションとオンプレミスホストの選択も行います。

よくある問題は、共通イメージに対して仮想マシンを構築しないことです。これにより、Surface Automationなどの開発手法が失敗するリスクが大きくなります。

各柱を正しく理解することが、あらゆるRPAソリューションの成功に不可欠です。

Robiquityプリンシパル・コンサルタント、Rob Dawson著