Changements de mise à niveau dans Automation Co-Pilot pour utilisateurs professionnels à partir d\'Automation 360 v.21 ou des versions ultérieures

À partir de la version d\'Automation 360 v.21 et dans les versions ultérieures, la façon dont les équipes travaillent dans Automation Co-Pilot pour utilisateurs professionnels dans l\'interface Web a été modifiée. La gestion des équipes avancée aide désormais les responsables métier à définir la manière dont une demande peut être créée. Ils peuvent également préciser qui peut consulter ou supprimer les demandes.

Pour s\'assurer qu\'il n\'y a pas de discontinuité dans le comportement existant pour les utilisateurs qui disposaient d\'un accès, quel qu\'il soit, à un processus, ou qui avaient créé des demandes à partir d\'un processus (indépendamment de l\'affectation d\'équipe existante), les conditions suivantes doivent être maintenues :

  • L\'accès de l\'utilisateur à la création d\'une demande pour un processus spécifique est conservé.
  • L\'accès de l\'utilisateur à la visualisation des demandes d\'un processus, quelle que soit l\'équipe dont il fait partie, est également conservé.

Quels sont les changements pour les équipes existantes ?

Pour maintenir l\'accès aux équipes et processus actuels, les équipes conservent :

  • Les processus existants qui leur ont été attribués.
  • Les membres affectés à l\'équipe.
  • Le type d\'équipe, qui est configuré sur partagé. Cela permet à tous les membres de l\'équipe de visualiser les processus et les demandes migrés.
  • Les membres de l\'équipe ont l\'un des rôles suivants :
    • Co-Pilot Manager ou Administrateur Co-Pilot a le rôle d\'administrateur
    • Utilisateur Co-Pilot a le rôle de membre

Pour maintenir l\'accès actuel aux demandes, de nouvelles équipes sont créées pour chaque processus et la nouvelle équipe dispose des éléments suivants :

  • Les processus existants attribués à l\'équipe sont nommés « Équipes migrées pour le processus X » où X est l\'ID de processus. Cela permet de référencer les processus migrés. Des équipes sont créées pour les processus existants portant ce nom.
  • Les utilisateurs qui avaient précédemment accès au processus sont affectés à cette équipe, sans tenir compte de leur affectation existante, et l\'équipe est affectée au processus.
  • Le type d\'équipe, qui est configuré sur partagé.
  • Les membres de l\'équipe ont l\'un des rôles suivants :
    • Administrateur Co-Pilot
    • Co-Pilot Manager
    • Utilisateur Co-Pilot

Auparavant, le Co-Pilot Manager pouvait créer des demandes sans attribuer les processus aux équipes. Après la mise à jour, il doit créer des équipes et demander au Administrateur Co-Pilot d\'affecter ses équipes à un processus afin de créer de nouvelles demandes.

Important : Une fois le processus de migration et la création de l\'équipe migrée terminés, vous pourrez sélectionner deux processus dans la création de la demande (un pour chaque équipe). Les deux processus auront des comportements différents concernant la visibilité de la demande.

Exemple

Le scénario suivant permet d\'illustrer le fonctionnement de la mise à jour.

Prenons l\'exemple d\'un processus nommé Clôture du prêt, avec l\'ID de processus 47. Georges a un rôle Administrateur Co-Pilot dans la Control Room.

Avant la mise à jour

Deux équipes, l\'équipe RH et l\'équipe IT, ont accès au processus Clôture du prêt. La structure de ces équipes est indiquée dans le tableau ci-dessous.

RH IT
Nom d\'utilisateur Rôle Control Room Nom d\'utilisateur Rôle Control Room
Bob Co-Pilot Manager Grace Co-Pilot Manager
Carol Utilisateur Co-Pilot Steve Utilisateur Co-Pilot
Debby Utilisateur Co-Pilot Debby Utilisateur Co-Pilot
Le comportement avant la mise à jour était le suivant :
  • Les utilisateurs de l\'équipe RH pouvaient voir les demandes créées dans l\'équipe IT et vice versa.
  • Bob et Grace pouvaient attribuer les processus qui avaient été précédemment attribués par Georges à l\'équipe RH et IT respectivement.
  • Bob pouvait gérer l\'équipe RH et, de la même manière, Grace pouvait gérer l\'équipe IT, par exemple en ajoutant des membres, en attribuant des processus, en renommant l\'équipe, etc.

Après la mise à jour

Les deux équipes initiales (RH et IT) restent en place et une nouvelle équipe (appelée Équipe migrée pour le processus 47) a été créée pendant la mise à niveau. La structure des trois équipes est indiquée dans le tableau ci-dessous :
RH IT Équipe migrée pour le processus 47
Nom d\'utilisateur Rôle de l\'équipe Rôle Control Room Nom d\'utilisateur Rôle de l\'équipe Rôle Control Room Nom d\'utilisateur Rôle de l\'équipe Rôle Control Room
Bob Administrateur Co-Pilot Manager Grace Administrateur Co-Pilot Manager Bob Administrateur Responsable de Copilote d\'automatisation
Carol Membre Utilisateur Co-Pilot Steve Membre Utilisateur Co-Pilot Carol Membre Utilisateur Copilote d\'automatisation
Debby Membre Utilisateur Co-Pilot Debby Membre Utilisateur Co-Pilot Debby Membre Utilisateur Copilote d\'automatisation
Utilisateur Co-Pilot Grace Administrateur Responsable de Copilote d\'automatisation
Steve Membre Utilisateur Copilote d\'automatisation
Le comportement des équipes depuis la mise à jour est le suivant :
  • Les membres de l\'équipe RH ne peuvent plus voir les demandes créées dans l\'équipe IT et vice versa.
  • Comme Debby fait partie des équipes RH et IT, elle peut créer des demandes dans les deux équipes. Lors de la création de la demande, l\'utilisateur peut voir deux cartes de processus différentes.
  • Les anciennes demandes créées au sein des équipes RH et IT sont traitées comme si elles avaient été créées au sein de l\'équipe commune nommée Équipe migrée pour le processus 47, à laquelle n\'est attribué que le processus Clôture du prêt (47).
  • Les membres des équipes RH et IT font tous partie de l\'Équipe migrée pour le processus 47 et peuvent donc accéder aux anciennes demandes. La suppression de l\'Équipe migrée pour le processus 47 supprime les demandes qui lui sont associées, de sorte que l\'accès aux anciennes demandes est supprimé et ne peut être restauré.
  • Les membres de l\'équipe RH ou IT peuvent créer des demandes au sein de l\'Équipe migrée pour le processus 47 et ces demandes sont visibles par tous les membres de l\'équipe RH et IT.
  • Bob et Grace peuvent gérer l\'équipe RH et l\'équipe IT respectivement, et gérer conjointement l\'Équipe migrée pour le processus 47. Cela signifie qu\'ils peuvent ajouter des membres à l\'équipe, renommer l\'équipe, retirer des membres de l\'équipe, etc.
  • Bob et Grace ne peuvent désormais visualiser que les processus attribués à leurs équipes par Georges.
Important : Pendant la mise à jour, des problèmes d\'affectation des administrateurs d\'équipe peuvent survenir par intermittence, le créateur de l\'équipe se voyant attribuer à tort le rôle de membre au lieu du rôle d\'administrateur d\'équipe, ou d\'autres membres de l\'équipe se voyant attribuer le rôle d\'administrateur d\'équipe au lieu du rôle de membre. Depuis la mise à jour, l\'Administrateur Co-Pilot doit toujours vérifier l\'affectation de l\'administrateur d\'équipe.

L\'exemple suivant explique le problème de l\'affectation de l\'administrateur d\'équipe :

Avant la mise à jour : Bob crée l\'équipe RH et a le rôle Co-Pilot Manager. Carol, Debby, Grace et Steve sont membres de l\'équipe et ont des rôles Utilisateur Co-Pilot.

Après la mise à jour : Bob se voit attribuer le rôle d\'administrateur d\'équipe avec Carol. Debby, Grace et Steve se voient attribuer les rôles de membres de l\'équipe. Dans ce cas, Carol se voit attribuer à tort le rôle d\'administrateur au lieu du rôle de membre. L\'Administrateur Co-Pilot doit vérifier l\'affectation de l\'administrateur d\'équipe et changer le rôle de Carol en membre de l\'équipe.