既存のオートメーションを使用する

このワークフローを使用すると、既存の RPA ボットを再構築するのではなく、調整された 1 つのエンドツーエンドのプロセスに織り込むことができます。

このワークフローは、動作中のオートメーションがすでにあり、それぞれが単独で重要な仕事をしていて、Cartographer でそれらを可視性、制御、SLA を備えた 1 つの調整されたエンドツーエンドのプロセスに織り込む場合に使用します。このような状況は、信頼できるボットであり、それらを接続するプロセスがないという「オートメーションの島」の状況です。目標は、機能するものを再利用し、ボット間の手動接着剤のみを置き換え、アセットが到達できない場所にのみ新しい機能を追加することです。

開始する前に

アセットの収集

Cartographer は、オートメーションについて聞くだけでなく、オートメーションを読み取ることができるときに最高の設計をします。再利用するボットごとに、以下を含む説明を用意します。

• 機能とトリガー (スケジュール、キュー、手動、または API)
• 入力と出力 — ファイル形式、キュー アイテム構造、読み書きする正確なフィールド
• どのシステムにどのように触れるか (画面/UI と API) によって再利用可能かどうかが決まります
• 例外の処理方法とその所有者
• ビジネス クリティカルなか、コンプライアンスのスコープ (SoX など) か

各アセットに安定した参照 (CoE コードなど) を与え、Cartographer に終始そのコードで参照するよう依頼します。この 1 つの習慣により、現在の状態の地図、将来のデザイン、最終的な文書はすべて同じ現実を指し示します。

業務プロセスを設定する

プロジェクトの指示で、再利用の意図を明確に記述します。たとえば、「再利用したい既存の RPA ボットがいくつかあります。現在のプロセスを文書化し、既存のアセットを追跡し、それらを再利用する将来のエンドツーエンドのオーケストレーションを設計し、手動の接着剤のみを置き換えます」ここで明確にすることは、Cartographerを制約された再利用優先モードにする理由です。

ワークフロー

アセットから現在の状態をキャプチャする

「現在のプロセスの文書化を開始します。既存の資産を追跡し、再利用してください。」Cartographer はアセットの説明を読み取り、プロセス マップ、各ボットが使用するシステムとデータ、それらの間のハンドオフ、問題点のリストなど、現状の全体像を構築します。将来の設計について話し合う前に、現在の状態マップは、すべてが遡るアンカーです。

各アセットが実際にどのように適合するかを修正する

Cartographer は、資産がどのように接続されているかについて最善の推測を行いますが、推測が間違っている可能性があります。たとえば、「その承認ボットは別の下流プロセスです。手数料には触れません。」Cartographer はマップを再描画し、修正されたアセットを破棄するのではなく、再利用できるようにしておきます。

将来のパイプラインに属するアセットを決定する

どのアセットをどこで再利用するかを Cartographer に指示します。アセットが現在独立していても再利用できます — 「その承認ボットを将来の自動化パイプラインの一部にしたいです。どこに置くかを勧めてください。」全体的な目標を記述します (例: 「制御が不可欠な場合を除き、人間による評価を最小限に抑えてエンドツーエンドで自動化」)。地図製作者は、アセットの実際の入力と出力から推論し、再構築せずにアセットを接続する配置を見つけます。

チェーンされた資産間のデータ契約の確認

あるボットが別のボットにフィードする場合、上流のアセットの出力が実際に下流のアセットの入力 (フィールド名、形式、構造) を満たしていることを確認します。ここでの不一致は、つなぎ合わせられたパイプラインにおけるサイレント障害の最も一般的な原因です。

すべてのユニットにオートメーション モードを割り当てる

Cartographer はオートメーション ユニット (1 つのボット、または 1 つのナチュラル クラスター) を提案し、それぞれにモードを選択するように求めます (「 オートメーション モードの割り当て」をご覧ください)。包括的なデフォルトではなく、仕事の性質によって選択してください。既存のボットは完全に自動化されたタスクとして実行され続け、人間のタッチポイントは実際のコントロールが必要な場所にのみ存在し、新しいエージェントユニットはボットが本当に到達できない場所にのみ表示されます。

詳細の前に将来の形状を確認する

Cartographer は、将来のプロセスの形状 (たとえば、「自動化された 5 人、人間によるレビューが 1 人、エージェントが 2 人 - 何を変更する必要があるか?」)、待機します。このチェックポイントは重要です: 詳細を書き込んだ後に形状を変更すると、作業が破棄されます。地図を確認し、調整してから確認します — 何気ない「良さそうですね」は承認として扱われるので、慎重に行ってください。

ヒント:

データを渡す質問を強制します。ディスポジション テーブルを明示的に要求し、ノード間でデータがどのように移動するかを説明するように Cartographer に依頼します。例: 「PDD を生成し、既存の各資産で何が起こったかに関する廃棄テーブルを含めます。また、各 RPA の通信方法の潜在的な違いを考慮して、ノードからノードへのデータの受け渡し方法も示します。ギャップがあれば指摘してください。」

コントロール、例外、未解決の判断を確認する

図形を確認すると、Cartographer は詳細 (ビジネス ルール、例外処理、利点、および意図的に推測しなかった未解決の意思決定のリスト) を書き込みます (承認許容度のしきい値、承認者のチャネル、トリガー メカニズムなど)。その未解決の決定リストをアクションリストとして扱います — 各項目は、ビルドチームが答える必要がある実際の選択です。

プロセス ドキュメントを生成する

設計が確定したら、CartographerにPDDの生成を依頼します。再利用シナリオの場合、ドキュメントには、再利用された資産のインベントリ、それぞれの再利用の決定、それらの間のデータ契約、現在の状態から将来の状態へのマップ、およびそこに到達するための段階的な計画など、最初から作成されたPDD以上のものが含まれている必要があります。

ヒントとよくある落とし穴

• アセットを説明するだけでなく、アセットにフィードします。デザインの良し悪しは、Cartographer が読み取ることができるアセットの詳細と同じくらいです。
• 最初に再利用し、次に追加します。動作するボットを再構築することに抵抗します。オーケストレーションで包み込み、周りの接着剤だけを置き換えます。
• 意図を自由に変えることができます — それは適応します。セッションの途中で資産を再分類または再配置すると、Cartographer は新しい意図に基づいて設計を再作成します。
• サイレントなリプラットフォームに注意してください。再利用すると、ある記録システムから別の記録システムにデータが移動される場合は、それを詳細ではなく、承認が必要な決定として扱います。
• 共有アセットを再利用できることを確認します。一元管理されるボットまたはサードパーティのボットの場合は、そのボットを構築する前に、所有チームが同意し、キャパシティがあることを確認してください。
• ステージングされたパスについて考えてみましょう。既存のボットをオーケストレーションし、接着剤を交換することは、それ自体が貴重な最初の段階であり、その後、人間のタッチポイントとモダナイゼーションが続きます。

次のステップ

• 現状 (AS-IS) のドキュメント — クリーン スタート ワークフローで共有される、[発見] と [現行のままの面接の仕組みを定義]
• TO-BE設計とPDD生成 — 自動化モードとPDD生成をクリーンスタートワークフローと共有
• SDD の生成 — 確認済みの PDD からのビルド対応仕様