Génération de tâches manuelles

Un workflow visuel permet de créer des tâches manuelles à réaliser par des groupes ou des individus. Une tâche manuelle est créée à partir d'un modèle dédié, qui enregistre les tâches dans un dossier spécifique. Les tâches peuvent être attribuées à un groupe et un membre du groupe peut ensuite se les attribuer à lui-même.

Il est possible de visualiser uniquement les tâches manuelles sans créer de fiche de données proprement dite. Décochez ensuite l'option « Créer une tâche » si vous souhaitez uniquement visualiser et documenter une tâche manuelle sans créer de fiche de données distincte.

Le concepteur du workflow doit définir le nom de la tâche manuelle, un court objet descriptif de la tâche et la condition de ce qui doit être modifié pour terminer la tâche.

Configuration manuelle des tâches :

Par défaut, une nouvelle carte de données est créée pour chaque tâche lors de l'exécution du workflow. Par conséquent, la configuration manuelle de la tâche doit définir le modèle selon lequel la carte de données doit être créée. Le moteur de workflow visuel proposera uniquement les modèles pour les tâches de workflow incluant la classe système obligatoire « Informations sur la tâche ».

Il est également nécessaire de définir le dossier dans lequel la fiche de données de la tâche sera enregistrée. N'oubliez pas qu'un même modèle peut créer des fiches de données dans plusieurs dossiers différents, par exemple pour des groupes de services situés à différents endroits.

Le statut de la fiche de données de tâche peut également être défini via l'activité Tâche manuelle. Généralement, la tâche manuelle est initialement définie sur « Ouverte » ou « Attribuée », mais cette configuration est personnalisable.

La tâche manuelle peut être assignée à un groupe de personnes, à une personne dédiée ou à une personne référencée, mais pas à plusieurs simultanément. Vous pouvez d'abord choisir un groupe de soutien, puis une personne dédiée parmi ce groupe.

Il est recommandé de créer des vues prêtes pour les tâches de workflow dans l'espace de travail d'Efecte Service Management.

Création de modèles de tâches de workflow

Une fiche de données de tâche manuelle est créée selon une définition de modèle correspondante. La configuration par défaut d'Efecte Service Management inclut au moins un modèle de tâche de workflow. D'autres modèles de tâche de workflow peuvent être créés de toutes pièces dans n'importe quel module. Il est obligatoire d'ajouter la classe système « Informations sur la tâche » à tout nouveau modèle de tâche de workflow, sinon le workflow ne le reconnaîtra pas. N'oubliez pas que le modèle doit être lié à un dossier pour être visible dans la configuration de la tâche manuelle.

Modèle de tâche de flux de travail :

Activités de définition de valeur

L’une des activités les plus simples d’un flux de travail consiste à définir une nouvelle valeur pour n’importe quel attribut du modèle correspondant ou d’un attribut référencé.

Tous les nœuds de workflow doivent avoir un nom. Ils peuvent également être accompagnés d'une description plus détaillée expliquant leur fonction et leur objectif.

Bien qu'il soit possible de mettre à jour la valeur d'un attribut dans de nombreuses autres activités, suite à l'activité elle-même, comme les approbations ou les conditions, l'activité « Définir une valeur » peut également être utilisée à cette fin. Utiliser l'activité « Définir une valeur » peut être utile pour mettre à jour la valeur d'un attribut afin d'améliorer la transparence sur les événements et les moments.

Le concepteur de workflow peut définir une nouvelle valeur pour un ou plusieurs attributs du workflow.

Configuration de la valeur définie :

Lors de la définition des valeurs des attributs de type multi-valeurs, le concepteur du workflow peut choisir si la valeur doit être définie sur la valeur configurée, si la valeur doit être ajoutée aux valeurs existantes ou si la valeur doit être supprimée des valeurs existantes.

Il est également possible d'ajouter ou de supprimer des valeurs aux attributs qui autorisent plusieurs valeurs.

Définir la configuration à valeurs multiples :

Conditions si/alors

Les conditions Si/Alors divisent la séquence de workflow en deux branches distinctes, basées sur une condition unique ou une combinaison de plusieurs conditions. Elles sont idéales pour modéliser différents comportements de processus selon les conditions. Lorsque l'élément de condition Si/Alors devient actif, la condition est immédiatement vérifiée et une décision est prise en fonction des valeurs actuelles de la base de données.

Le nom de la condition Si/Alors doit être descriptif de l'élément.

Condition Si/Alors avec plusieurs conditions :

En fonction du résultat de l'évaluation de la condition, le workflow se divise en branches distinctes. Avant de poursuivre le workflow sur les différentes branches, l'élément de condition « Si/Alors » peut définir de nouvelles valeurs pour les attributs du modèle afin d'automatiser les processus. Différentes valeurs peuvent être définies si la condition est remplie (Alors) ou non (Sinon).

Approbations

L'activité Approbations permet de communiquer avec les parties prenantes d'un problème. Son objectif est de décider si le problème traité par le workflow est approuvé ou rejeté. Une approbation ou un rejet peut également résulter de la révision d'une activité de modification ou d'un article de la base de connaissances.

Les approbations peuvent être effectuées avec Efecte Service Management ou via le portail libre-service Efecte.

Approbations de groupe

Le moteur de workflow peut traiter les approbations par une seule personne ou par un groupe de personnes. Un groupe peut être composé de personnes dédiées enregistrées dans les données de l'organisation ESM, de personnes liées au modèle, ou d'une combinaison des deux.

Si l’approbation de groupe est utilisée, la décision d’approbation peut être de deux types :

• Décidez quand le premier approbateur prend la décision.
• Décidez lorsque tous les approbateurs ont pris une décision.

Dans les deux cas, si un approbateur rejette le problème à approuver, l'approbation du groupe entier est arrêtée et le flux de travail continue conformément à la branche des problèmes rejetés.

Approbations avec Efecte Service Management

En cas d'approbation dans Efecte Service Management, une notification d'approbation sera envoyée aux approbateurs, qui pourront suivre un lien intégré pour accéder directement à la vue d'approbation du problème concerné.

Les approbations via ESM peuvent être envoyées à :

• Approbateurs dédiés et fixes connus de l'ESM.
• Approbateurs associés, sélectionnés dynamiquement, tels que les responsables du gestionnaire.

Configuration d'approbation pour les approbations dans ESM :

Le lien vers la fiche de données du modèle d'approbation doit être ajouté manuellement au corps du message de la notification d'approbation. Il s'agit de l'élément principal de la liste des attributs suggérés. Le lien et le texte de l'hyperlien sont personnalisables dans les paramètres du workflow de la plateforme. Le lien du message sera au format HTML formel et s'affichera par défaut sous la forme « Accéder à l'approbation ». Ce texte peut être modifié dans les paramètres de la plateforme/Paramètres du workflow.

Les approbations sont stockées par défaut dans un dossier du modèle « Approbations ». Les utilisateurs peuvent créer des vues pour les consulter. Les approbations horodatées sont en lecture seule pour les utilisateurs normaux. Les utilisateurs disposant de droits d'administration peuvent modifier manuellement la valeur de l'horodatage. Cependant, cela créera une entrée dans le journal de sécurité à des fins d'audit.

Configuration des approbations avec ESM

Les étapes de configuration suivantes sont déjà implémentées dans la configuration de base des nouveaux déploiements ESM. Les mises à niveau ou améliorations des installations existantes doivent inclure les étapes suivantes si les approbations doivent être activées via l'interface utilisateur ESM.

Un nouveau modèle d'approbation dédié doit être créé dans le module Organisation. Vous pouvez l'importer.

Modèle d'approbation :

Un nouveau rôle d'approbateur doit être créé afin d'attribuer des autorisations utilisateur élevées pour l'approbation du problème concerné. Le rôle d'approbateur doit disposer des autorisations de lecture et de mise à jour sur le dossier « Approbations » et le modèle d'approbation.

Le modèle de référence ReferredEntityViewer doit être défini sur le modèle Person.

Définition de la référence pour le modèle Approbateur sur le modèle Personne :

Attribution des droits de lecture et de mise à jour au dossier Approbations :

Attribuez une autorisation utilisateur élevée au modèle Approbations afin de garantir que l'utilisateur approprié dispose des autorisations nécessaires pour prendre une décision d'approbation (mettre à jour l'attribut de décision d'approbation).

Configuration du modèle d'approbation avec des autorisations utilisateur élevées :

Utilisateur ESM attaché à la carte de données de la personne :

Approbations via le portail libre-service d'Efecte

Les demandes de service peuvent également être approuvées via le portail libre-service d'Efecte (ESS). La demande d'approbation sera envoyée au portail libre-service pour traitement. Le portail vérifiera ensuite si un délégué (remplaçant) est actif pour l'approbateur et enverra une notification par courriel à l'approbateur ou à son délégué.

L'analyseur visuel de workflow (VWA) prend en charge l'envoi de demandes d'approbation à plusieurs portails Efecte Self-Service. Vous pouvez définir le jeton et l'URL du portail d'approbation par nœud d'approbation :

Configuration d'approbation de groupe pour les approbations dans le portail libre-service :

L'automatisation visuelle du workflow génère un tampon d'approbation pour la décision une fois informée et poursuit le workflow en conséquence. Une fois la décision prise par l'approbateur, le portail libre-service communique le résultat à ESM, y compris le nom de l'approbateur, qui peut être différent de celui du demandeur en raison de la fonction de délégation. ESM génère ensuite un tampon d'approbation pour la décision et poursuit le workflow en conséquence. Le modèle de message de notification de l'approbateur est défini par le portail libre-service.

Lorsque les approbations sont gérées via ESS, les concepteurs de flux de travail peuvent choisir d'envoyer les approbations à une seule personne :

• Approbateurs dédiés et fixes connus de l'ESM.
• Approbateurs associés, sélectionnés dynamiquement, tels que les responsables du gestionnaire ou les responsables du centre de coûts associés.

Pour les approbations de demandes de service via ESS, la configuration d'approbation de l'offre de service dans ESS doit être configurée sur « Défini par Efecte Service Management ».

Configuration d'approbation pour les approbations dans la vue d'administration ESS :

Minuteries

Les temporisateurs du moteur de workflow créent des délais afin de se synchroniser avec les processus métier. ESM prend en charge deux types de temporisateurs : un qui bloque le workflow pendant une durée déterminée et un autre qui le bloque jusqu'à une date fixe et récurrente, comme chaque lundi.

Configuration du nœud de minuterie avec intervalle d'attente absolu :

Le moteur de workflow passe à l'étape suivante uniquement une fois les minuteries écoulées.

Configuration du nœud de minuterie avec heure de réveil fixe et récurrente :

La minuterie peut également être configurée par rapport à n’importe quel attribut de date dans le modèle.

Configuration du nœud de minuterie déclenchée 2 jours avant un attribut sélectionné :

Conditions d'attente

La fonctionnalité « Attendre les conditions » permet de suspendre le workflow jusqu'à ce qu'une ou plusieurs conditions soient remplies. La configuration de la condition est identique à celle de la condition « Si/Alors ». Alors que le nœud « Si/Alors » vérifie immédiatement si une condition est remplie, le nœud « Attendre les conditions » attend qu'une condition soit remplie et ne progresse qu'après.

Configuration de la condition d'attente :

Notifications par e-mail

Le nœud de notification par e-mail permet de communiquer avec toutes les parties prenantes lors de l'exécution d'un workflow. Les notifications par e-mail peuvent être ajoutées à n'importe quel endroit du workflow. Les concepteurs de workflows peuvent définir si les e-mails sont envoyés au format HTML ou texte brut. Il est également possible de configurer le passage au nœud suivant du workflow.

Configuration des notifications par e-mail :

L'objet et le corps du message peuvent inclure des valeurs ajoutées dynamiquement par le modèle afin de rendre le contenu du message plus pertinent. L'ajout de contenu dynamique s'effectue en insérant le code de l'attribut entouré d'un signe $.

Les administrateurs peuvent vérifier depuis l'onglet Maintenance dans la file d'attente des messages si et quand les e-mails sont envoyés.

Nœud d'exécution de script

Il est possible d'exécuter des scripts Python pendant la séquence de workflow en tant qu'activité dédiée. La définition du script suit les scripts déjà programmables pour des attributs individuels sous forme d'expressions dans ESM. Pour plus d'informations sur la création d'expressions, veuillez consulter le uid du gestionnaire d'attributs de l'interface d'administration.

Les scripts de Visual Workflow Automation peuvent manipuler les valeurs des attributs du modèle sur lequel le workflow s'exécute, mais pas celles des autres modèles. Le script permet aux concepteurs de workflows d'effectuer des calculs mathématiques à l'aide d'opérandes tels que +, -, / et *, ainsi que de crochets. Les scripts peuvent également générer des nombres aléatoires, calculer la différence entre deux dates/heures, ou calculer des sommes ou des moyennes de plusieurs valeurs.

Nœud de script calculant un numéro de loterie aléatoire :

Il est primordial de définir la condition de « passage à autre chose » pour le nœud d'exécution du script, qui configure le moment où le workflow doit considérer le script comme exécuté et poursuivre son exécution. Il est également judicieux d'utiliser la condition de fin de workflow si le script annule le workflow de manière inattendue.

Nouvelle génération de cartes de données

L'automatisation visuelle des workflows permet de créer de nouveaux problèmes lors du traitement d'un problème. Ceci est particulièrement utile lorsque des problèmes sont liés ou qu'un problème doit en déclencher un autre automatiquement. Dans la gestion des incidents, il est par exemple courant de créer une nouvelle demande de changement ou un nouveau problème si l'incident ne peut être résolu facilement.

Nouveau nœud de génération de carte de données créant un nouveau problème à partir du modèle de modification :

Un autre cas d'utilisation consiste à créer des cycles de révision pour des actifs tels que des applications d'entreprise ou des contrats. Une fois le workflow de révision terminé, la solution attend six mois avant de déclencher la création d'un autre incident de révision, ce qui relance le workflow de la révision suivante. Les champs de ce nouvel incident peuvent facilement être définis via la configuration ou mappés aux valeurs de l'incident qui déclenche sa création.

Retour en arrière

La fonction de retour arrière permet aux concepteurs de workflows de revenir à une activité précédente de la séquence si une condition spécifique est remplie. Elle réinitialise de nombreuses activités situées entre le nœud de retour arrière et l'activité à laquelle le workflow revient :

• Les approbations précédentes sont annulées et une nouvelle demande d’approbation est créée.
• Les minuteries sont réinitialisées.
• Les tâches manuelles sont réinitialisées à l'état annulé.

Configuration du nœud de restauration pour un flux de travail d'incident simple :

La restauration ne peut pas réinitialiser ou annuler des activités à partir de nœuds tels que :

• Activités d'orchestration.
• Notifications par e-mail.
• Nouveau nœud de création de carte de données.

Ces activités ne doivent pas figurer dans la séquence de flux de travail du chemin de restauration.

La restauration doit toujours pointer vers une séquence du workflow qui a déjà été exécutée avant la restauration, c'est-à-dire qu'il n'est pas autorisé de passer à une autre branche d'une condition If/Then.

Pour éviter la création de boucles pouvant entraîner de graves problèmes de performances du système, la séquence de flux de travail entre le nœud de restauration et l'activité de redémarrage doit inclure une activité de retardement telle que :

• Minuteur.
• Approbation.
• Condition d'attente.
• Tâche manuelle (si le nœud n'est pas marqué instantanément comme terminé lors de la restauration).

Le nœud de restauration inclut un paramètre permettant de définir le nombre de restaurations autorisées pour un même incident. Le concepteur du workflow peut ajuster cette valeur de 1 à 20. Une fois toutes les itérations autorisées exécutées, le workflow se poursuit au nœud de restauration, même si les conditions de restauration sont remplies. Si le workflow se déplace vers un nœud de restauration déjà exécuté trop souvent, il se terminera avec une erreur.

Configuration du nœud final

Les nœuds finaux constituent l'étape finale de chaque séquence de workflow. Un workflow doit comporter au moins un nœud final. Un workflow peut également en comporter plusieurs pour définir différents résultats.

Configuration du nœud final :

Chaque nœud final possède un nom qui doit être spécifié pour décrire le résultat du workflow. Le statut du problème doit également être défini sur la valeur correspondant au résultat. Il est également possible de définir automatiquement la valeur d'un attribut du modèle pour refléter l'état final du workflow.