À 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 for Business Users 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 Co-Pilot Admin a le rôle d\'administrateur
    • Co-Pilot User 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 :
    • Co-Pilot Admin
    • Co-Pilot Manager
    • Co-Pilot User

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 Co-Pilot Admin 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 Co-Pilot Admin 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 Co-Pilot User Steve Co-Pilot User
Debby Co-Pilot User Debby Co-Pilot User
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 Automation Co-Pilot
Carol Membre Co-Pilot User Steve Membre Co-Pilot User Carol Membre Utilisateur Automation Co-Pilot
Debby Membre Co-Pilot User Debby Membre Co-Pilot User Debby Membre Utilisateur Automation Co-Pilot
Co-Pilot User Grace Administrateur Responsable de Automation Co-Pilot
Steve Membre Utilisateur Automation Co-Pilot
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\'Co-Pilot Admin 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 Co-Pilot User.

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\'Co-Pilot Admin doit vérifier l\'affectation de l\'administrateur d\'équipe et changer le rôle de Carol en membre de l\'équipe.