Automation 360 v.21 以降のバージョンからのビジネス ユーザー向け Automation Co-Pilot の変更点の更新

Automation 360 v.21 以降のバージョンでは、Web インターフェースにおける Automation Co-Pilot for Business Users でのチームの作業の方法が変更されています。高度なチーム管理により、ビジネス マネージャーはリクエストを作成する方法を定義できるようになりました。さらに、リクエストを表示または削除できるユーザーを指定することもできます。

プロセスへの何らかのアクセス権を持っていたユーザーや、プロセスからリクエストを作成したユーザー (既存のチーム割り当てに関係なく) の既存の動作に不連続性をなくすため、次の条件が維持されます。

  • 特定のプロセスに対するリクエストを作成するためのユーザー アクセス権は保持されます。
  • ユーザーが所属していたチームに関係なく、あるプロセスからリクエストを表示するためのユーザー アクセス権も保持されます。

既存のチームの変更点

プロセスへの現在のアクセス権や現在のチームを維持するため、既存のチームは以下の状態が維持されます。

  • チームに割り当てられている既存のプロセス。
  • チームに割り当てられている同じメンバー。
  • チーム タイプは共有に設定されます。これにより、チームの全メンバーが移行されたプロセスやリクエストを表示できるようになります。
  • チームのメンバーは、以下のいずれかのチーム ロールを持ちます。
    • Co-Pilot マネージャーまたは Co-Pilot 管理者は管理者ロールを持っている
    • Co-Pilot ユーザー はメンバー ロールを持っている

現在のリクエストへのアクセスを維持するため、プロセスごとに新しいチームが作成され、新しいチームは次のようになります。

  • チームに割り当てられた既存のプロセスは、「プロセス X 用に移行されたチーム」という名前になります (X はプロセス ID)。これは、移行されたプロセスを参照するのに役立ちます。この名前を持つ既存のプロセスに対してチームが作成されます。
  • 以前からそのプロセスへのアクセス権を持っていたユーザーは、既存のチーム割り当てに関係なくこのチームに割り当てられ、このチームはそのプロセスに割り当てられます。
  • チーム タイプは共有に設定されます。
  • チームのメンバーは、以下のいずれかのチーム ロールを持ちます。
    • Co-Pilot 管理者
    • Co-Pilot マネージャー
    • Co-Pilot ユーザー

以前は、Co-Pilot マネージャーはプロセスをチームに割り当てることなくリクエストを作成することができました。更新後は、新しいリクエストを作成するには、マネージャーはチームを作成し、Co-Pilot 管理者にチームをプロセスに割り当てるように依頼する必要があります。

重要: 移行処理と移行済みチームの作成後、リクエストの作成で、2 つのプロセス (各チームに 1 つずつ) を選択します。この 2 つのプロセスは、リクエストの可視性に関して異なる動作を実行します。

例

次のシナリオは、更新の仕組みを説明するのに役立ちます。

プロセス ID が 47 の「Loan Closing」という名前のプロセスを考えてみましょう。Georges は、Control Room の Co-Pilot 管理者ロールを持っています。

更新前

Loan Closing プロセスには、HR と IT の 2 つのチームがアクセスでき、以下の表に示すようなチーム構造となっています。

HR IT 部門
ユーザー名 Control Room ロール ユーザー名 Control Room ロール
Bob Co-Pilot マネージャー Grace Co-Pilot マネージャー
Carol Co-Pilot ユーザー Steve Co-Pilot ユーザー
Debby Co-Pilot ユーザー Debby Co-Pilot ユーザー
更新前の動作は以下のとおりです。
  • HR チームのユーザーは、IT チームで作成されたリクエストを表示できます。その逆も同様です。
  • Bob と Grace は、Georges からすでに割り当てられているプロセスを、それぞれ HR チームと IT チームに割り当てることができます。
  • Bob は HR チームを管理し、同様に Grace は IT チームを管理することができます (メンバーの追加、プロセスの割り当て、チームの名前変更など)。

更新後

2 つの初期チーム (HR と IT) はそのまま残り、さらに 1 つの新しいチーム (名前は「プロセス 47 用に移行されたチーム」) が更新中に作成されます。全 3 チームのチーム構造は以下の表のとおりです。
HR IT 部門 プロセス 47 用に移行されたチーム
ユーザー名 チーム ロール Control Room ロール ユーザー名 チーム ロール Control Room ロール ユーザー名 チーム ロール Control Room ロール
Bob 管理者 Co-Pilot マネージャー Grace 管理者 Co-Pilot マネージャー Bob 管理者 Automation Co-Pilot マネージャー
Carol メンバー Co-Pilot ユーザー Steve メンバー Co-Pilot ユーザー Carol メンバー Automation Co-Pilot ユーザー
Debby メンバー Co-Pilot ユーザー Debby メンバー Co-Pilot ユーザー Debby メンバー Automation Co-Pilot ユーザー
Co-Pilot ユーザー Grace 管理者 Automation Co-Pilot マネージャー
Steve メンバー Automation Co-Pilot ユーザー
更新後のチームの動作は以下のとおりです。
  • HR チームのメンバーは、IT チームで作成されたリクエストを表示できなくなります。その逆もできなくなります。
  • Debby は HR チームと IT チームの両方に所属しているため、このユーザーは両方のチームでリクエストを作成することができます。リクエスト作成時は、2 種類のプロセス カードがユーザーに表示されます。
  • HR チームと IT チーム内で作成された古いリクエストは、Loan Closing プロセス (47) のみ割り当てられた「プロセス 47 用に移行されたチーム」という共通チーム内で作成されたものとして扱われます。
  • HR チームと IT チームのメンバー全員は「プロセス 47 用に移行されたチーム」に属しているため、古いリクエストにアクセスすることができます。チーム「プロセス 47 用に移行されたチーム」を削除すると、それに関連付けられたリクエストが削除されるため、古いリクエストのアクセス権が削除され、復元できません。
  • HR チームや IT チームのメンバーは、「プロセス 47 用に移行されたチーム」内でリクエストを作成でき、それらのリクエストは HR チームと IT チームのメンバー全員が表示できます。
  • Bob と Grace は、それぞれ HR チームと IT チームを管理でき、「プロセス 47 用に移行されたチーム」を共同で管理することもできます。つまり、チームへのメンバーの追加、チームの名前変更、チームからのメンバーの削除などを行うことができます。
  • Bob と Grace は、Georges によって自分のチームに割り当てられたプロセスのみ表示できるようになります。
Important: 更新中、チームの作成者にチーム管理者ではなくメンバー ロールが誤って割り当てられたり、他のチーム メンバーにメンバー ロールではなくチーム管理者ロールが割り当てられたりなど、チーム管理者の割り当てに関する問題が断続的に発生する場合があります。更新後、必ず Co-Pilot 管理者がチーム管理者の割り当てを確認する必要があります。

次の例では、チーム管理者の割り当て問題について説明します。

更新前: Bob は HR チームを作成し、Co-Pilot マネージャー ロールを持っています。チーム メンバーは Carol、Debby、Grace、Steve であり、Co-Pilot ユーザー ロールを持っています。

更新後: Bob には、Carol とともにチーム管理者の役割が割り当てられています。Debby、Grace、Steve にはチーム メンバー ロールが割り当てられています。この場合、Carol にメンバー ロールではなく管理者ロールが誤って割り当てられています。Co-Pilot 管理者は、チーム管理者の割り当てを確認し、Carol のロールをチーム メンバーに変更する必要があります。