ホワイトペーパー
ビジネス リーダー向けロボティック
プロセス オートメーション (RPA) 移行ガイド
RPA に移行する理由、タイミング、方法を包括的に検討するためのホワイトペーパー
¹ Footnote example, title and release date aligned to the bottom with Footnote style applied
概要:
このテクニカル ホワイトペーパーでは、エンタープライズ RPA への移行における定義、計画、デプロイ、管理の 作業で考慮すべき事項を概説します。
執筆者:
Cognizant Intelligent Automation Practice (英語) (IPA) 担当 (協力: マイクロソフト)
•
Abhinav Kolhe (テクノロジ リーダー)•
V. Gopikrishna (Microsoft Power Platform アーキテクト)•
Prabu Tecklur Konati (チーフ アーキテクト)•
Sankara Narayanan Govindarajan (チーフ アーキテクト)•
Jagannathan Rangarajan (チーフ アーキテクト)技術協力:
Rakesh Krishnan、Akansha Gawade、Kent Weare
01 /
04 概要
02 /
05 進化を続ける RPA の状況
03 /
05 移行の考え方と移行を阻む要素
04 /
07 Power Automate に移行すべき理由
05 /
10 RPA 移行ツールキット
11
I. 定義、調査、評価16
移行のビジネス ケースの作成16
プログラムのスポンサーにビジネス ケースを提示して承認を得る17
II. 計画20 III. 準備状況 24 IV. コンバージョン 29 V. 管理とガバナンス
06 /
32 まとめ
33
参考資料概要
ほとんどの新しいテクノロジと同様に、RPA の導入でも、大きな投資効果が期待できるのは間違いありませ ん。しかし、その実現にあたっては、適切なテクノロジを選択し、自動化するプロセスを洗い出し、最適なアー キテクチャで実装を行う必要がありますが、それらを実行に移す段階になると、ビジネス リーダーは不安を覚 えるようになります。RPA を早期に導入した企業は、以下のような課題に直面しているように見受けられま す。
•
大量のコードを記述してデプロイするため、絶えずデバッグの作業が発生している•
チェンジ マネジメントやガバナンスに手間がかかる•
生産性面の成果がまちまちで、大きく変動する•
事業部門ごとに実装環境がサイロ化している•
技術の中身がはっきりしない•
クラウドへの移行準備の足並みが揃わないこの結果、多くの企業では、RPA 戦略の見直しが避けられない状況になっています。現在、市場には 150 を超える RPA 製品が出回っており、提供される生産性や設計品質、手法のレベルはさまざまであるため、ビ ジネス リーダーは、技術面の複雑な点を必ず理解しておかなくてはなりません。
RPA の成熟度に関して Gartner が最近公表した予測によれば、「社内での利用の足並みが揃わないこと や拡張性の欠如が原因で、2021 年には、40% の企業が RPA の導入を後悔するようになる」と言いま す。
近い将来、RPA 製品は、デスクトップ環境全体で戦術レベルのメリットを実現する製品と、大規模な企業 でより戦略的なトランスフォーメーションを実現する製品に大枠で分かれるものと予想されます。RPA プロジェ クトの拡大を目指す組織が、ビジネス主導の設計原則を提供するテクノロジへと順次引き寄せられていくの は間違いありません。これは、ノーコードやローコードの環境を実現するプラットフォームを意味します。加えて、
一元化された RPA プラットフォームを使用したコラボレーション アプローチでは、人が行う作業とデジタルの作 業の連携が強化されるため、自動化の取り組みを組織全体で推進、共有、拡大できます。
このホワイトペーパーでは、既に RPA の導入を進めているビジネス リーダーやテクノロジ リーダーの皆様に包括 的なガイドを提供します。従来の PRA から新たな時代の最新のローコード/ノーコード プラットフォームへと移行 するための手法とフレームワークの概要をわかりやすくご説明します。テクノロジのより適切な利用方法、利害 関係者からスムーズに賛同を得る方法、自動化による成果を最適化して ROI を効果的に高める方法など
をご理解いただけます。既存のプラットフォームからの移行ではなく、ゼロから新規の RPA を実装する場合に も、このホワイトペーパーの内容が役に立ちます。
RPA の導入中や導入後によく直面するいくつかの課題が存在します。ビジネス リーダーやテクノロジ リーダー の皆様がこれらの課題を十分に理解し、認識できるようサポートすることが、このドキュメントの 1 番の目的で す。また、より高度な RPA プラットフォームへの移行を検討するにあたり、移行する「理由」と「タイミング」をこ のドキュメントを根拠に熟慮できるようになっています。さらに重要な点として、より高度な RPA ソリューション や RPA プロバイダーへの移行が必要であると判断した後、その実施方法を導いてくれる包括的なツールキッ トについても説明します。
このホワイトペーパーの RPA 移行ツールキットのセクションでは、移行に関して判断する際に考慮すべき要素 のほか、移行時に選択できる数多くの戦略や手法もご理解いただけます。また、移行を成功に導く業界の ベスト プラクティスもいくつかご紹介しています。
進化を続ける RPA の状況
他の自動化製品と同様に、ロボティック プロセス オートメーション (RPA) は急激な進化を続けており、市場に は毎年新たな参入者が見られます。従来のプロセス トランスフォーメーションのアプローチと比較した場合、RPA は、スピーディーかつ予測可能なかたちでプロセスを自動化できるという点で決定的な手法となっています。
しかも、新世代の RPA プロバイダーでは、以下のようにさらに多くのことが可能になっています。
•
ノーコード/ローコードのプラットフォームやアプリケーションを利用した、より容易な実装•
既存のレガシ プラットフォームとの統合をサポート•
クラウドと UI の自動化の組み合わせ•
シチズン デベロッパーによる自動化で導入がより容易に•
最も重要な点として、コストやライセンスの構造が適切に統合されており、成⾧に合わせて規模を拡張 できる移行の考え方と移行を阻む要素
既に RPA 製品に投資をしていて、前述のような課題に直面している場合は、このタイミングで見直しを図 り、既存の環境から新しい環境への容易な移行を支援してくれるスマートでコスト効率の高いソリューションを 探すべきです。日々の業務フローに支障が出ず、コストが大きく増加しないソリューションが理想ですが、それ を見つけるのは口で言うほど簡単ではありません。それでも、プロセスの生産性向上を目指して最適な自動 化の方法を探し続けるのであれば、移行を検討する必要があるでしょう。
ここからは、移行を判断する際によく直面するいくつかの課題についてと、新世代の RPA 製品への移行に 役立つ強力なビジネス ケースを作成する方法について解説します。
1.
設備投資の回収RPA 製品を既に導入済みの組織では、そのプロジェクトの一部に設備投資のコストを割り当てているはずで す。既存の RPA 製品が更新やサポート終了の時期を迎える場合は、新世代の RPA 製品を導入するまた とないチャンスです。そうでない場合は、新世代の RPA 製品の導入で追加の設備投資コストが発生するこ とになります。このケースでは、短期的にコスト効率よく大幅な利益をもたらす RPA ツールか、すぐに効果を発 揮して設備投資をすばやく回収できる RPA ツールを見つけることが重要になります。
2. プログラムの管理とガバナンス
新しい RPA プロバイダーに切り替える際は、IT 部門も事業部門も、プログラムや時間やリソースを管理しな ければならず、それには多くの時間がかかります。新世代の RPA ツールでは、ローコードやノーコードの開発が 可能であるため、利用の敷居が低く、シチズン デベロッパーでも簡単にプロセスを自動化できます。ソリューシ ョンには UI ベースやクラウド ベースのオプションも用意されているため、RPA の実装効率が優れており、成熟 度や適合性の高い実装が実現します。
3. 平行運用に伴うコストの発生
RPA 製品を別の RPA 製品に切り替える際、日々の業務プロセスに支障が出るのを最低限に抑えるため に、製品を平行して運用する期間が必ず発生することになります。つまり、障害のリスクや切り替えに関連す るリスクを低減できるよう、新旧両方のプラットフォームを維持するためのコストが一定期間かかります。特に、
ミッションクリティカルなボットの場合は、平行運用が欠かせません。ただし、どのボットでも必ず平行運用が 必要になるとは限りません。また、移行プロジェクト チームは、稼働環境で平行運用する時期をアプリケーシ ョン評価チェックリスト (移行ツールキットのセクションで説明) に基づいて判断する必要があります。さらに、利 用ベースの RPA サービスを新規にセットアップすると、平行運用のコストを抑えることができます。こうすれば、
新世代の RPA プラットフォームについては、利用分だけのコストを支払えば済むようになります。
4. 運用とトレーニングの負荷
既に実装済みのプロセスを新しいシステムにマッピングしたり、運用上必要なトレーニングをチームで再度実施 したり、さまざまな面でチェンジ マネジメントを実施したりするのは非常に煩わしく、RPA プラットフォームの切り 替えの妨げになります。通常、事業部門や運用チームに移行の必要性を理解してもらうには非常に困難が 伴うため、チェンジ マネジメントがより重要になります。実際、任意の単一のプラットフォームにすべての環境を 移して統合し、新世代の機能を利用できるようにするには、CTO/CIO レベルの戦略的判断が必要になりま す。
たとえば、Office や Windows などのマイクロソフト製品に既に投資をしている場合は、一定の範囲で Power Automate の機能が利用できるようになっているため、すぐに自動化のプロジェクトを始められます。
また、運用チームが自ら問題に対処できるようにする場合、ローコードやノーコードに対応した環境であればシチ ズン デベロッパーが簡単にツールを導入できるので、開発のコストを抑えられます。
5. マイクロソフト製品の利用の有無
現在マイクロソフトのクラウド サービスを利用していない場合、Power Automate への移行には意味がある のでしょうか。Power Automate に移行した場合、そのメリットを十分得られるのでしょうか。そもそもそうした お客様は移行が可能なのでしょうか。
•
マイクロソフトのクラウド サービスを利用していない場合は、Amazon S3 や Amazon Redshift などのプ レミアム コネクタを利用して、Power Automate によるプロセスの統合を行えます。Google Cloud Platform や Terraform など、コネクタが提供されないケースでは、カスタムのコネクタを作成することが できます。マイクロソフトの「あらゆるシステムとの連携」を目指す哲学が、クラウドを横断したエコシステム の実現に寄与しています。•
既に Microsoft Azure を利用している場合は、追加コストなしで、Power Automate と 25 以上の Azure サービスをネイティブに直接統合できます。これらのサービスは、エンドツーエンド (E2E) の自動化シ ナリオで特に重要になります。大規模企業にとっては、Office 関連の自動化シナリオや Azure AD など とのネイティブの統合がシームレスでより安全なものになるため、とりわけ重要です。また、反復型のアプロ ーチで Azure を導入する際の最初のステップにもなります。Power Automate に移行すべき理由
Forrester と Gartner は、2021 年の最近のレポートで Microsoft Power Automate の登場を大きく取り 上げており、それ以降、市場におけるリーダーとして存在感を現しています。厳密に言えば、マイクロソフトがこ の分野に参入したのはこれが最初ではありません。2016 年にマイクロソフトは Microsoft Flow を発表して います。しかし、転機が訪れたのは、2019 年に Power Automate を発表したときです。洗練された新しい 機能を多数搭載した Power Automate のおかげで、マイクロソフトは、市場で一定の地位を確立していた 他のブランドと互角に戦えるようになったのです。さらに、マイクロソフトは Softomotive を買収し、そのソリュ ーションを Power Automate と統合しました。これにより、Power Automate は、あらゆる自動化のニーズ に対応できる E2E ソリューションになりました。
Forrester はレポートで、マイクロソフトに関して次のように述べています。
「ソフトウェア最大手の同社のビジョンは、最も包括的な SaaS ベースのイン テリジェント オートメーション ソリューションを提供することです。Power Automate はクラウド ネイティブのローコード オートメーション プラットフォー ムであり、UI ベースの自動化と API ベースの自動化を AI によって統合し ます」
RPA の TAM (獲得可能な最大市場規模) は 2023 年までに 40 億ドルを超えるものと予想されます。同 時に、Power Automate の RPA は市場に破壊的な変革をもたらしています。Power Automate は、プロ 開発者もシチズン デベロッパーもコードを記述することなく UI を通じて自動化を実現できる生産性ツールだか らです。
RPA プラットフォームの投資を変更するにあたって、Power Automate を検討すべき明確な理由を以下に 示します。
1.
大規模な自動化•
組織全体で効率的に自動化の規模を拡大できます。組織のエンド ユーザー、プロ開発者、IT チームの だれもが、オンプレミスとクラウドベースのアプリとサービスでワークフローを簡単に自動化できます。•
Power Automate ではシチズン デベロッパーによる自動化が可能ですが、従来のツールはもとより、現 行の他のほとんどのツールでも不可能です。2. シームレスで安全な統合
•
どのレベルでも安全な統合が可能です。ユーザーは、セキュリティとコンプライアンスが確保された方法で、自動化されたワークフローを安心して構築できるため、高いスキルを持つ IT 担当者は、さらに複雑なガバ
ナンスのタスクに注力できます。
•
シチズン デベロッパーが UI 機能でワークフローを作成できることは、組織のほぼすべての従業員が利用で きるハンズオン ツールである Power Automate の大きなメリットです。3. 生産性向上を促進
•
使いやすいローコードやノーコードのツール、テンプレート、コネクタによって、時間のかかる反復的な手動のタ スクを最小限に抑えられるので、チームが戦略的なタスクにより時間を割けるようになります。•
組織全体で Power Automate の機能を利用できる環境をコストをかけずに簡単に実現して、シチズン デベロッパーが Office で提供される機能を活用して開発を行えるようになります。Office で提供される 以外の機能が必要なときは、自動化センター オブ エクセレンス (CoE) 担当者がフェデレーション モデルの 作業で開発できます。•
フローはわずかな学習ですぐに開発できます。ドラッグ アンド ドロップで視覚的に操作できる 4GL (第4世 代言語) により、フローの構成が簡素化されます。この言語は、ノーコードやローコードのスイートを強化しま す。また、Microsoft Power Automate には、プロ開発者のために、コードを使った開発を容易にするオ プションも用意されています。Power Automate は間違いなく組織のだれもが容易に利用できる、ユー ザーを選ばないプラットフォームです。4. インテリジェントな自動化
•
AI で強化された自動化ワークフローで効率を高めます。自動化されたワークフローとビジネス プロセスを AI と組み合わせることにより、働き方を合理化できます。•
Power Automate の AI Builder の機能では、ビジネス プロセスの最適化を想定した AI モデルをポイン トやクリックの操作で構築できます。コーディングもデータ サイエンスのスキルも不要です。カスタムのモデル を構築することもできれば、一般的な業務シナリオで利用できる事前構築済みのモデルを選択すること も可能です。5. クラウドでもオンプレミスでも完全な自動化を実現
•
Power Automate は、あらゆるユーザーに最適な自動化戦略を実現する、完成された自動化ソリュー ションです。•
マイクロソフトのエコシステムとの緊密な統合により、ネイティブでの連携を容易にし、自動化を加速化し ます。6. 戦略に沿った自動化
•
どんな組織にとっても、取り組みにかかるコストは考慮すべき大きな要素です。Office や Windows にネ イティブで実装されている Power Automate の機能を活用すれば、シチズン デベロッパーは日々の業務 を簡単に自動化できます。また、追加の機能が必要になった場合も、従来の RPA 製品では利用でき ない優れた機能を、コストを抑えて利用できます。•
既に RPA を実装している多くのお客様が、インフラストラクチャや開発規模の大小にかかわらず、多額の 投資を回収できないでいます。Power Automate であれば、最初からそうしたインフラストラクチャ コスト の発生を防ぐことができます。•
サービス全体の一元的なガバナンス機能が組み込まれた Power Automate は、ローコード製品を重視 する Power Platform の強力なソリューション ファミリの 1 つであり、関連するサービス製品とスムーズに 連携します。Power Automate では、リレーショナル構造を持つネイティブのデータ ソースとしてDataverse を利用できます。チャットボットは、Power Virtual Agent で簡単に構築できます。機能アプ リは Power Apps ですぐにレンダリングが可能です。レポート機能は、Power BI によって提供されます。
RPA 移行ツールキット
どのタイプの移行でも、ROI の検証のために定量化でき、持続性のある成果を確立するために、詳細かつ 体系的なアプローチを取ることが必要です。
以降のセクションでは、RPA を Power Automate に移行する際に推奨されるアプローチを説明します。移 行プロセスのある段階から別の段階へ移る際に注意すべき重要なポイントを理解できる、包括的なガイドに なっています。
I. 定義、調査、評価
1.
移行の目標を定義するにあたっての主な考慮事項上の「Power Automate に移行すべき理由」セクションでは、移行に着手し、ビジネス ケースを作成するた めに自動化 CoE 担当者が考慮すべき事項とそれに対する見解を示しました。これらを先行指標として利 用すれば、以下の問いの答えが得られ、Power Automate への移行の作業を批判的に評価することがで きます。
•
明確な動機: なぜ Power Automate を導入するのか?•
ビジネス成果の定義: Power Automate の導入によってどのような成果を期待するのか?•
ビジネスの観点から見た評価: ビジネスの観点では、何をもって移行が成功したと判断するのか?移行や導入の業務に携わるチームのメンバーは、上記 3 つの戦略的な問いに対し、明確な答えを示すこと ができなければなりません。導入計画の背後にあるさまざまな指標を明確に理解していることも必要です。プ ロジェクトに携わるすべてのチーム メンバーは、プロジェクトの全体像を理解していなければなりません。
Power Automate への移行の動機を明確にする別の方法として、以下の組織的なイベントを根拠にするこ ともできます。
ビジネス イベント 検討事項
プラットフォームを変更してコストを削減する必要がある 新しい RPA ツールの導入がコストに与える影響
組織の合併、買収、資産の売却 ベンダーの数や技術的な複雑さの抑制
最近、Office 365 へ移行した ネイティブのクラウド サービスの活用や導入。クラウドへのフット プリントの統合
機能不足で、無人の自動化を超える自動化の拡張が できない
クラウド ネイティブの自動化プラットフォームの使用を通じた、
フロント オフィスからバック オフィスまでを対象とする複雑な 自動化の導入
規制の変更に対応 新たな技術機能の準備
既に Azure を使用しているか、ワークロードを増やす予定 25 以上のネイティブの Azure サービスをフル活用、ロード コードを使用
動機とビジネス成果を明確にすれば、移行の目標を戦略的に定義できます。それによって強力なビジネス ケースを作成できるようになり、経営層から移行の承認を得やすくなります。
次のステップでは、自動化された既存のプロセスの状況を調査および評価し、要件をまとめ、ギャップを追跡 して解消し、テクノロジ コネクタを設定して、計画の立案に役立てます。すべての側面を適切に評価できれ ば、サイロ化やアイランド化の状態を回避でき、移行戦略の妨げとなる要素を排除できます。
以下に推奨するアプローチを示します。このアプローチでは、適切な移行戦略を立案できるよう、現行のデジ タル オートメーション環境を評価するためのガイダンスとフレームワークを提供します。調査と評価のフレームワー クについて説明する前に、移行に関するより広範なフレームワークについて確認しておきましょう。多くの人が実 行する可能性の高い移行ステップを以下に示します。
自動化の資産を把握するには、既存の環境に対して一連の評価を行い、その後、次のことを実施します。
•
移行と計画のリコメンデーションを作成•
ビルドと移行•
テストとリリース•
高度なケアとサポート体制を構築調査と評価のフレームワークにおける重要な考慮事項は以下のとおりです。
1.
アプリケーションの評価2. インフラと環境の評価
3. セキュリティの評価
1.
アプリケーションの評価:目的は、自動化の範囲内となるアプリケーションのタイプとその特性を詳細に把握することです。考慮すべき パラメーターは以下のとおりです。
パラメーター 価値 影響とソリューション オプション ターゲットとなる
アプリケーション の種類
Web ベース ターゲットのアプリと、新しい Edge、Chrome、Firefox との互換性を評価します。必 要に応じて、一部のアプリが IE 11 で動作するように調整します。これにより、Power Automate へのスムーズな移行を実現できます。
グリーン ターミナル すべてのグリーン ターミナル エミュレーターを記載したリストを作成し、Power Automate との互換性を検証します。
ERP (Salesforce、
Workday など)
多くの場合、ERP の自動化は UI ベースで脆弱であり、障害が発生しやすくなりま す。Power Automate には、450 以上のさまざまなコネクタが用意されており、UI の 自動化を排除できます。既成の API を通じて、コネクタ ベースの信頼性の高い自動 化に置き換えます。
自社開発のイントラ ネット アプリケーション
これらのアプリのために Web サービスで公開できるかどうかを検討します。または、⾧
期的に価値をもたらし、API ベースの自動化を活用できるカスタム コネクタを作成で きるかどうかを検討します。不可能な場合は、Power Automate で提供される既定 の UI フローを利用します。
オンプレミスのリソース (ドライブ、データベース)
ネットワーク ファイルやローカル ファイルなどに関しては、ファイル システム コネクタを使っ て Power Automate クラウドにデータを移動することを検討します。
ServiceNow や Remedy などのチケット /サービス システム
今日では多くの自動化が UI ベースで脆弱であり、障害が発生しやすくなっています。
Power Automate にはさまざまなコネクタが用意されているため、UI を排除し、コネ クタ ベースの信頼性のある自動化に置き換えられます。
Office 365、Exchange Online、SharePoint Online、MS Teams
Power Automate には、Office 製品と緊密に統合され、シームレスに機能する多様 なコネクタが用意されています。
SAP SAP 向けには、コネクタと UI による自動化の両方が既に提供されています。SAP の オペレーションの一部は API からアクセスできないため、それについては、Power Automate Desktop の UI 自動化を活用して自動化することを検討します。
Citrix アプリ Power Automate では、画像認識に基づいてネイティブで Citrix の自動化を実施 できます。
データベース 標準で提供される Power Automate DB コネクタ (SQL、Oracle、DB2、Azure、
AWS など) を利用します。
シック クライアント 使用しているシック クライアントが Windows 10 で認定されているかどうか、また、
Windows 10 で動作するかどうかを評価します。認定されていない/動作しない場 合、Power Automate を利用する準備を進める前に、前提条件として Windows 10 や Windows 2016 の環境への移行が必須です。
分析用のビジネス データ Azure サービスや PaaS オプションを利用して、分析用のビジネス データを保存します。
これは、詳細な評価を行う際やボットの移行チェックリストを作成する際、また、すべてのパラメーターについて 追加の考慮事項における見落としを防ぐという意味で重要です。
2. インフラストラクチャの評価
次に重要になるのが、自動化の範囲となるインフラストラクチャと環境の把握です。考慮すべきパラメーターは 以下のとおりです。
パラメーター 価値 影響とソリューション オプション
ライセンス ボットのライセンス 今日、従来の非 UI ベースの自動化では、企業はライセンス、ソフトウェア、ハードウェアへ の投資が必要になります。Power Automate のクラウド フローでは、非 UI ベースの自 動化を構築および管理する信頼性の高いクラウド環境が提供されるため、コストを大幅 に削減できます。
ボット環境 ボット デザイナー ランタイムは、クラウド フローのためのオプションで、デスクトップ フローや UI フローでのみ必 要です。Power Automate により、仮想マシンのコストを大幅に最適化できます。
ボットのランタイム 多くの場合、ERP の自動化は UI ベースで脆弱であり、障害が発生しやすくなります。
Power Automate には、450 以上のさまざまなコネクタが用意されており、UI の自動 化を排除できます。既成の API を通じて、コネクタ ベースの信頼性の高い自動化に置 き換えます。
オーケストレーション ルームまたは コントロール ルーム
Power Automate では、クラウドベースのオーケストレーション機能が組み込みで提供さ れるという大きなメリットがあります。ハードウェアやソフトウェア、ロード バランサー、データベ ースを別途用意する必要がありません。
リソース オンプレミスのリソース Power Automate のいくつかのコンポーネントはクラウド ネイティブであるため、オンプレミ スのリソースをどのようにして使うのか疑問に思われることがあります。Power Automate には、共有ドライブやオンプレミスのデータベースと接続するゲートウェイをインストールするオ プションがあります。ゲートウェイをインストールできない場合は、マシンとマシン グループを 構成して、Power Automate クラウドに直接接続し、デスクトップ フローを実行します。
Remedy などの チケット/サービス システム
現時点では多くの自動化が UI ベースで脆弱であり、障害が発生しやすくなっています。
Power Automate にはさまざまなコネクタが用意されているため、UI を排除し、コネクタ ベースの信頼性のある自動化に置き換えられます。
高可用性と ディザスター リカバリー
高可用性と ディザスター リカバリー の要件
Azure を基盤とする Power Automate では、きわめて高い稼働率が保証されるため 高可用性とディザスター リカバリーのコストや要件を排除できます。デスクトップ フローで 使用する仮想マシンの稼働時間を確保するプランは必要ですが、コントロール ルームや データベースなどのためにプラットフォーム レベルの高可用性やディザスター リカバリーを用 意する必要はありません。
ログ 保持 既定の 28 日を超えてログを保持する場合は、代替のクラウド ストレージの準備が必要 になることがあります。詳細なログの分析が必要なときには必須です。
デプロイ Power Automate クラウドとデスクトップ
Power Automate のクラウド フローにはさまざまなメリットがありますが、これを使用する 場合、ネットワーク チームはオンプレミスのアプリにアクセスするためのポートをオープンにす る必要があります。この点を考慮してから、既存の特定のボットをクラウド フローに移すよ うにします。大規模企業の場合は、従来の自動化環境に残っている既存のインベントリ のクラウドやデスクトップのフローが混在する可能性が高くなります。すべてのフローを稼働 環境に移す際は、Power Platform の管理におけるアプリケーション ライフサイクル管理 (ALM) のベスト プラクティスに従うようにします。ベースラインの監視やガバナンスの機能も 利用できます。これらの機能は拡張が可能です。
3. セキュリティの評価
最後に、自動化の範囲となるセキュリティの要件を評価する必要があります。考慮すべきパラメーターは以下 のとおりです。
パラメーター 価値 影響とソリューション オプション
ロールベース セキュリティ
マルチテナント セキュリティ
AAD グループを使用して、組織の事業部門へのアクセスを許可する自動化 を構成します。AAD に加えた変更は、Power Automate にシームレスに反 映されます。
アプリの資格情報 またはサードパーティの ソリューション
Azure Key Vault、Web サービスベースの CyberArk、またはサードパーティの 同等の Vault に移動します。
仮想マシンの 資格情報
仮想マシンの資格情報の構成には、フローのスケジューリングと実行を行うオ ンプレミスのゲートウェイを使用できます。
データ 個人情報 (PII) Power Automate のクラウド フローで置き換える予定の既存のボットが PII にアクセスしている場合は、利用するオプションを慎重に評価し、PII のセキュ リティが確保されるようにするか、デスクトップ フローを使用するようにします。
アプリの認証 認証 (COTS、ERP、またはカスタムの) クラウド アプリで Power Automate コネク タを使用する場合は、Power Automate がサポートしている、SAML、
OAauth、AAD などの認証メカニズムでこれらのアプリを認証します。
多要素認証 (MFA) Power Automate Desktop で MFA を使用する場合は、MFA API で カスタム コネクタやカスタム ユーティリティを作成します。
移行のビジネス ケースの作成
評価結果の準備が整ったら、最高自動化責任者 (CAO) や自動化 CoE 担当者は、ビジネス ケースを作 成する必要があります。ビジネス ケースでは、既存環境の技術面と財務面のタイムラインを記載し、再投資 でモダン化の見込みがあるポイントをリスト化します。ビジネス ケースには、技術面を考慮した予算計画も記 載し、その内容はビジネス成果に沿ったものにする必要があります。
移行のビジネス ケースの重要な要素には、以下のようなものがあります。
•
自動化の範囲: 環境面、技術面、財務面の対象範囲•
ベースラインの財務データ：今日の運用コスト•
予測: 現状と将来の運用コスト•
予測: 移行タイムラインと運用コストプログラムのスポンサーにビジネス ケースを提示して承認を得る
ビジネス ケースは、組織の目標やビジネス成果に合わせてカスタマイズする必要があります。利害関係者と 戦略を共有した後、質問に答え、疑問を解消します。答えるのが難しい質問も考えられるため、質問される 内容をあらかじめ想定し、事前に答えを準備しておくようにします。最高自動化責任者 (CAO)、最高技術 責任者 (CTO)、最高デジタル責任者 (CDO)、最高情報責任者 (CIO)、最高財務責任者 (CFO)、財務 チームについて、それぞれが抱く共通の目標、行動を促す要因、期待する成果を検討し、すべての利害関 係者から承認を得ます。
II. 計画
移行のビジネス ケースが承認されたら、実施に向けた詳細な計画の立案が必要になります。詳細なタイムラ インを設定し、リソースを割り当て、担当者とその責務を決定すると共に、作業の進め方とその評価方法を 取り決めます。以下に説明する手法では、Power Automate Desktop のセットアップを完了させておらず、
別の RPA ツールを既に使用していることを想定しています。また、自動化 CoE 担当者も存在するものとして います。
このチェックリストを活用して、効果的な移行計画を立案しましょう。
移行に必要な手順を検討する
評価結果に基づき、複雑さを生む要因を分析し、既存のボットを Power Automate に移行するう えで必要な作業を見積もります。個々の移行プロセスの難易度を「低」、「中」、「高」に分類する必 要があります。Power Automate の利用を踏まえてこの基準を定義する最良の方法は、クラウド フロ ー、デスクトップ フロー、および AI Builder とカスタム コネクタの組み合わせに関して実施した概念実 証 (PoC) の結果を利用することです。
移行プロセスを段階別に順を追って計画する
複雑さに応じて移行プロセスを段階化し、ビジネスの継続性に生じる影響を最低限に抑えます。経 験上、「フェイル ファスト」の手法を取り入れた (段階別の) 反復的なアプローチが、移行のリスクを効 果的に抑えられます。前の段階で学習したことを次の段階に活かすようにすることで、常に移行がスム ーズになります。
Power Automate のための開発フレームワークを設計する
コマンドのミスマッチの問題や、クエリとコネクタの使用方法など、新旧の RPA プラットフォームのフレー ムワークに関して設計上考慮すべき事項を定義し、移行のフレームワークの作成に役立てます。Power Automate Desktop 用の定型テンプレートを作成するために定義された開発フレームワークは、コーデ ィングをする際のベスト プラクティス ドキュメントとして利用できます。
Power Automate の環境をセットアップする
セットアップのために、環境全体を対象にアーキテクチャを定義し、開発環境、テスト環境、稼働環境 のセットアップの計画を行います。マルチテナントを念頭に置き、既存の Active Directory グループを 使用して計画を行います。アクセス、テスト データ、コンバージョンのためのマシンのリクエストを行いま す。必要なネットワーク セキュリティ グループ/アプリケーション セキュリティ グループのポリシーもすべて定 義する必要があります。
トレーニング支援
CoE チームが製品を使えるようにします。管理者やビジネス ユーザー、自動化の開発者、機能コンサル タント、ソリューション アーキテクトなどの役職を対象にする必要があります。こちらのマイクロソフトのラー ニング モジュールのリンクを参考にしてください。「RPA in a Day」は、ハンズオン アプローチの重要なトレ ーニング モジュールです。以下の表には、トレーニングの対象となる役職とモジュール、習得するスキルに ついて考え方をまとめています。
移行中の役割と責務
Power Automate の運用モデルを定義し、プロジェクト チームのメンバーの役割と責務を明確化しま す。ここで対象になるのは、自動化担当チームだけではありません。移行が完了した結果として、ビジネ ス ユーザーがどの程度デジタルの生産性向上に貢献したのかが、移行の重要な成功基準になるため です。事業部門/管理部門の生産性レベルも、移行作業に関連する追加の KPI/OKR として扱う必 要があります。移行の ROI の有効性を高めるために、ビジネス ユーザーのデータも活用し、そのデータを RACI を構成する要素としても扱います。
ライセンス戦略
マイクロソフトのアカウント担当者やパートナーのサポートを受けながら、組織に最も適したライセンス戦 略を策定します。利用できるオプションは数多くあり、料金に関しては、最適な戦略を把握するのが 非常に簡単です。Power Automate は他の製品に含まれている場合があるため、現在のマイクロソ フト クラウドのライセンス体系を確認することが重要です。これを理解すれば、移行の取り組みの一部 を早期に始められる可能性があります。詳細はこちらのリンクを参照してください。
設計と戦略では、組織レベルでの設計を行い、
分析情報を集め、プラットフォームの機能を評価し、
アクセラレータやガバナンスの機能を提供します。
リーダーシップ、ベスト プラクティス、リサーチ、
サポート、トレーニングを提供するエンティティです。
さまざまな分野のノウハウやリソースを活用して、
世界トップ レベルのパフォーマンスと価値を実現し、
維持します。
センター オブ エクセレンス
設計と戦略
計画段階で特に考慮すべきことの 1 つは、Power Platform 用の CoE 担当者を新たに設けるべきか、ある いは、既存の RPA の CoE 担当者に Power Automate の業務も任せるべきかを判断することです。CoE の目的はイノベーションと改善の推進にあります。組織の中で中心的なチームの役割を果たし、地理的およ び組織的な分断を解消します。
マイクロソフトの CoE スターター キットは、Power Automate への移行の戦略策定に役立つコンポーネントと ツールのコレクションを提供します。このスターター キットには、「ローコード アプリ、エージェント、分析など」の観 点で、Microsoft Power Platform 環境全体を調査できるツールも多数用意されています。
自動化では、ロー コードとプロ コード のソリューションや アクセラレータを 開発します。
アプリとエージェント では、Power Apps、Power Virtual Agent、
Accelerator を 開発します。
管理では、アクセス、
ライセンス、仮想マシ ンなどを管理します。
また、CoE キットや監 査項目、ゲートウェイ などの監視を行うほ か、セキュリティやコン プライアンスのチェック も実施します。
自動化、アプリ、エ ージェント、デプロイに 関するソリューション をサポートし、問題を 解決します。
ユーザーや事業部門の トレーニング、問題解 決の支援、シチズン ベロッパーのアイデアの 評価を行います。
自動化 管理 サポート シチズン
アドボケイト アプリと
エージェント
III. 準備状況
Power Automate 環境のセットアップは重要度の高いプロセスであり、このプロセスを早期に完了すること が、移行プログラム全体の成功には欠かせません。そのためには、(IT 部門、インフラ部門、情報セキュリティ 部門、マイクロソフト管理チーム、クラウド運用部門をはじめとする) 組織内部における利害関係者間のコラ ボレーションが不可欠です。しかし多くの場合、ほとんどの組織が利害関係者から十分な賛同が得られてい ないまま準備に取り掛かっています。自動化の移行においては、準備状況という要素が比較的新しい概念 であることを考えると、このトピックスに関するベスト プラクティスはあまり多く見つからないでしょう。その場合は まず、マイクロソフトや認定システム インテグレーション パートナーのサポートを受けながら、準備を進めることを お勧めします。
Power Automate のセットアップやセットアップ関連の手順については、このホワイトペーパーでは扱いません (プラットフォームの管理とガバナンスの詳細についてはこちら (英語) を参照)。ただし、考慮を必要とするいくつ かの事項については以下に示します。
•
環境のセットアップと実装を実施する中心チームを明確にします。•
Power Automate の環境とガバナンスを把握します。Power Platform のツール ファミリから Power Automate などのコンポーネントへフル アクセスできる、Power Platform サービス管理者のロールを割り 当てます。•
テナントと環境の戦略を立案します。新規の環境や稼働環境を作成する権限を管理者だけに与えるほ か、組織内の ALM ツールで新しい環境をリクエストするプロセスを自動化します。戦略の対象 環境 2、3、4
部門 人事、財務、運用
アプリケーション 開発、UAT、稼働環境
•
組織用の Power Platform ブループリント (デジタル ワーカー アカウント、ライセンス、VM ファーム、ゲート ウェイ) を定義します。•
データ損失防止 (DLP) ポリシーを設定します。•
アプリケーションのリスク、ユーザーのリスク、デバイスのリスク、データのリスクに対処できるよう、さまざまな レベルのセキュリティ コントロールを理解して実装します。•
コンプライアンスに関する組織の認定戦略を定義します。具体的には、特定のニーズで認定された環境 の取得を検討します。医療機関であれば HIPAA 認定に準拠し、電力事業者であれば NERC に準拠 する必要があります。また、コンプライアンス チームには、利用が認定されているプラットフォームの使用を 義務付けます (詳細はこちらを参照)。•
標準の分析およびログ機能を活用して、監視ポリシーを実装します。•
プラットフォームの監視と管理を容易にする CoE キットを実装します (スターター キットの詳細はこちらを 参照)。•
新しいユーザーを歓迎し、チャンピオンを特定します。•
自動化 CoE 担当を新設する、または、現行の CoE の業務を拡大して、RPA ユーザーの有機的な成⾧に投資しながらガバナンスとコントロールを維持して、プラットフォームの導入を促進します。
•
ガバナンス、開発、メンテナンスを対象とする、アプリケーションの ALM を設定します。ALM には、要件 管理、ソフトウェア アーキテクチャ、開発、テスト、メンテナンス、チェンジ マネジメント、継続的インテグレーション、プロジェクト管理、デプロイ、リリース管理などの統制も含まれます。詳細はこちらを参照してくださ い。その目的は、シチズン デベロッパーやプロのコード開発者など、自動化プラットフォームの使用を検討し ているあらゆるタイプのユーザーが健全な ALM プラクティスを使用できるようにすることによって、そのプラク ティスを一般化することにあります。
•
DevOps パイプラインを設定し、手動での作業を自動化された ALM に移行します。まず、自動化とカス タマイズのコンポーネントが含まれている開発環境からソリューションをエクスポートし、それをアンパックして ソース コントロール システムにコンポーネントを保存します。次に、Azure パイプラインを使用してコンポーネ ントを管理し、目的の環境にコンポーネントをデプロイしてテストします。最後に、稼働環境にデプロイし て、ユーザーが利用できるようにします。プラットフォームの環境構造が有効になったら、一連の概念実証 (POC) を行うことで、プラットフォームのコン ポーネントの信頼性が強化され、修正の必要性を判断しやすくなります。POC を活用する際のポイントを以 下に示します。
•
デスクトップ フローをカバーするシンプルなユース ケースから検証を始めます。•
デスクトップ フローとクラウド フローをカバーするユース ケースを使用します。•
ユース ケースを拡張し、AI Builder のコンポーネントを取り込みます。•
さらに、承認フローを追加します。このフローでは (MS Teams 経由で) ユーザー間で情報を共有する必要 があります。•
(自社開発アプリケーションの検証のために) カスタム コネクタを追加して、上記のシナリオからさらに検証 の範囲を広げます。上記の作業が完了すると、既存の実装環境を分類し、評価フェーズの結果として作成したビジネス部門の 準備状況のマトリックスを再検証する方法のイメージが明確になります。この内容に基づき、(次のセクション で説明する) 移行プロジェクト計画について、適用の可否を再検証します。POC から得られた情報には、ビ ジネス プロセス レベルで移行のタイムラインを調整する際に役立つ情報があります。
IV. コンバージョン
Power Automate 環境のセットアップが完了し、環境を管理する自動化 CoE 担当者を設置したら、移行 を開始します。個々のプロセスの評価 (このドキュメントの評価セクションを参照) から得られた情報と POC の結果を活用すれば、自社の組織に最も適した移行プランを立案できます。大枠で捉えると、移行の作業 は 2 つに分類できます。
一般的には、Power Automate をデスクトップ オートメーション ツールとして使用して、現行のプロセスをその まま新しいプラットフォームに移す動きが見られます。これは悪くないアプローチですが、実はもっと良い方法が あります。Power Automate が提供する機能を最大限に活かせるように、プロセスの再設計を検討してみ ましょう。機能を適切に活用すれば、ライセンスの利用を最適化できます。また、さまざまなコネクタを使用し ながら、既存の API やデータベースなどを統合すれば、ROI を大幅に高めることもできます。プロセスの再設 計や新機能の有無にかかわらず、既存の自動化を置き換えることの根拠や正当性を確立しましょう。
つまり、現状維持の移行アプローチなら最も早く自動化を実現できますが、最適な結果を出せる最もスマー トな方法ではありません。一方、ハイブリッドの移行アプローチでは、望ましくないパターンの排除を目指してい るため、より適切な結果が得られます。
利用できる移行戦略のタイプ
現状維持の移行アプローチでは、事前構築済みの移行ツールを使用します。このツールの既存のオプションは 以下のとおりです。自社で実装するか、パートナーに実装を依頼します。
•
Softomotive マイグレーター: Softomotive 製品のプロセス マイグレーター•
サードパーティのマイグレーター: ISV や SI は上記のツールの拡張版を使用して、顧客のサードパーティ ソフ トウェア向けのカスタムのマイグレーターを構築できます。たとえば、RPA Bot Migration Assistant (英 語) を利用できます。詳細は、RPA の実装パートナーまたはマイクロソフトの営業担当者にお問い合わせ ください。現状維持のアプローチやハイブリッド アプローチのプロセスの評価に役立つさまざまな設計パターンを確認して いきましょう。
現行のプロセス/
ユース ケース 現状維持のアプローチ ハイブリッド アプローチ**
メールに添付された Excel シートをダウン ロードし、そのプロセス のビジネス オーナーに 通知を送信する。
PAD の Excel、Mail、Outlook のパ ッケージを使用して、Windows VM で実行するものと似たプロセスを作成 する。
クラウド フローで Power Automate のテンプレート「Save Outlook.com のメールの添付ファイルを OneDrive に 保存する」を使用して、通知を送信する。
メールを分類して、
適切な SME に転送 する。
PAD を使用して、Windows VM で実行するものと似たプロセスを 作成する。
クラウド フローで Power Automate テンプレート「AI Builder を使用してメールのメッセージを分類する」を 使用して、メールを適切な SME に転送する。
承認プロセスの自動化 (承認のリクエストから 応答まで)
PAD を使用して Windows VM で 実行するものと似たプロセスを作成 し、複数の API エンドポイントと統 合する。
Power Automate の「承認コネクタ」または「MS Teams コネクタ」を使用して承認者に通知を送信し、
承認者がワークステーションやモバイル デバイスから Outlook アプリや Power Automate アプリを使用して 応答できるようにする。
メールの添付ファイル を読み、内容に沿っ て請求処理を行う。
a) PAD で Outlook のクライアントベ
ースのメール抽出機能を使用する (他のオプションで、Exchange Web サービスも利用可能)。b) PAD の OCR パッケージ、AI
Builder、または、AzureCognitive コネクタを使用可能。
c) Chrome で Web ページを開き、請
求アプリケーションにログインし、デー タを入力し、ログアウトする。d) Outlook クライアントを使用して メールを送信する。
クラウド フローで処理を書き換える (または、カスタム コネクタで、クラウド フローとデスクトップ フローを組み 合わせる)
a)
クラウド フローで、Power Automate の「Outlook コネクタ」を使用する。b) AI Builder を使用して、添付ファイルからデータを
抽出する。c) 請求アプリケーションの API が利用できる場合は、
請求処理のカスタム コネクタを作成する。
d) カスタム コネクタを利用できない場合は、請求処理
の部分でデスクトップ フローを使用する。Salesforce でオンボ ーディング リクエスト の有無を確認し、
ServiceNow で タスクを割り当て、
Teams でリマインダ ーを送信する。
a) PAD の表示の自動化を使用し
て、Salesforce ポータルに移動する (API が無効の場合を想定)b) PAD の表示の自動化機能を使
用して、ServiceNow でタスクを 割り当てる。
c) API の統合を使用して、Teams で
リマインダーを送信する。クラウド フローで処理を書き換える。
a) Power Automate の「Salesforce コネクタ」を使用
して、保留中のリクエストを抽出する。b) 「ServiceNow コネクタ」を使用して、タスクやチケット
を作成する。c) 「Microsoft Teams」コネクタを使用して、ビジネス
ユーザーにリマインダーを送信する。現行のプロセス/
ユース ケース 現状維持のアプローチ ハイブリッド アプローチ**
OCR を使用して、
PDF ドキュメントから 情報を抽出する。
参照番号を抽出し、
管理システムを検索 し、現在のステータス を返信する。
a) フロー #1 PAD (Power Automate
Desktop) で、Outlook クライアン トを使用してメールを読み、共有ド ライブに添付ファイルをダウンロード する。b) フロー #2 OCR プラットフォームで
ファイルを選択して処理し、Ops ユーザーで OCR プラットフォームの 検証ステーションにログインし、抽 出されたコンテンツを承認する。c) フロー #3 PAD で、抽出されたコン
テンツを選択し、SOR にログインして 参照番号を検索し、注文ステータ スをメールで送信する。クラウド、デスクトップ、カスタムのコネクタを組み合わせて フローとして使用する。
クラウド フロー #1 Azure Cloud OCR/AI Builder を使 用して、参照番号を抽出する。
PAD フロー #2 管理システムを検索して、メールを送信す る。
倉庫や作業場所/
現場からプロセスを トリガーする – ソフトウェアまたは ハードウェア ベースの トリガー
該当なし
a) デバイスが利用可能でオンラインのときに、ソフトウェア
ベースのトリガーを使用する。b) Power Automate Mobile アプリ (ソフトウェア) の
Power Automate のボタン フローを使用する。c) IoT ボタンを使用して、Power Automate フローを
トリガーする (デバイスが利用不可でハードウェアが 必要な場合)アクション - クラウド/デスクトップ/ビジネス プロセスの フローを呼び出す。
** 上記のユース ケースは、可能性の高い結果を想定した一般的な例であり、実際の実装では、組織の IT 環境に基づくカスタムの要件よって結果が変わる 可能性があります。
以下の表は、既存のプロセスを変更する際の参考資料として利用できます。コンポーネントの列は、同じプロ セス内で移行アプローチを検討する際に適用可能なフローのタイプを示しています。これを利用して、移行によ るライセンス コストを抑え、プロセス全体の ROI を最大化できるようにします。根拠の列は、コンポーネントの 選択が正しいことを裏付ける情報です。
コンポーネント 説明 根拠
クラウド フロー
•
コネクタが利用可能な場合•
API を使用してカスタム コネクタを作成できる場合•
プロセスで UI での操作が義務付けられていない•
ライセンス•
仮想マシン•
現行のインフラストラクチャ、運用コスト デスクトップ フロー
•
コネクタが利用不可の場合•
関係するすべてのシステムが、API や DB を利用できない レガシ システム•
UI ベースの操作がプロセスで義務付けられている•
ライセンスビジネス プロセス フロー
•
プロセスで複数の段階、承認、監査ログ、状態の調整が 必要な場合。例: SAP Arriba、ServiceNow Workflow を使用して実装された任意のフロー•
ライセンス•
仮想マシン•
現行のインフラストラクチャ、運用コスト ボタン フロー
•
工場や倉庫で、ユーザーがモバイル/IoT 対応の物理ボタンを使用している
•
操作やアラートをすばやく実行•
アクセスが容易•
コンプライアンス•
時間の遵守 人が関与する承認プロセス
•
プロセスで人やボットによるコラボレーションが必要な場合 に、Teams のチャネルで「人が関与する」承認メカニズムを 検討•
ライセンス コスト•
アクセスが容易•
監査証跡の一元化ハイブリッド アプローチを使用して既存のプロセスを再設計することで、Power Automate への移行を最適 化できます。コンバージョンのフェーズでは、リリース計画のセッションにすべての利害関係者が出席するようにし ます。既存のプラットフォームから新しいプラットフォームへ実際にボットをコンバージョンする際は、組織の BOT SDLC (B/RDLC – ボット/ロボティック開発サイクル) アプローチに従います。ほとんどの組織は、分割/段階別 の反復的な移行アプローチを好みます。手順は以下のとおりです。
Power Automate での開発 (クラウド、デスクトップ、ビジネス プロセス フロー、ボタン フロー)
•
開発中にフローを設計しながら、アーキテクチャのベスト プラクティスを習得します。詳細は、Power Apps および Automate アーキテクチャ シリーズ | Microsoft Power Apps (英語) を確認してください。単体テスト、統合テスト
•
開発したソリューションをテスト ケース シナリオに照らしてチェックします。ユーザー受け入れテスト
•
関与するビジネス/SME チームと共にソリューションを検証します。署名
•
適切なプロセスを使用して、ユーザーや利害関係者から署名を取得します。ドキュメント化
