Quand la définition de votre processus est erronée

Le constat

L'audit lit les intervalles enregistrés pour chaque étape de l'organisation. Pour chaque étape, il indique le nombre d'intervalles mesurés, le temps médian en minutes dans l'étape, les heures de SLA définies pour cette étape et le nombre d'intervalles ayant dépassé cette durée. Les étapes sont classées de la plus lente à la plus rapide, de sorte que le premier constat est celui qui importe le plus.

Le constat est énoncé en langage clair dans la proposition : l'étape a pris un certain nombre de minutes en valeur médiane et a été dépassée un certain nombre de fois. Il n'y a pas de score à interpréter ; chaque nombre de la phrase est un décompte ou une valeur médiane calculée sur des lignes que vous pouvez ouvrir.

La proposition

Pour une étape avec un SLA, la proposition consiste à transférer ces heures vers l'étape désignée par l'audit. Pour une étape sans aucun SLA, la proposition est de la mesurer avant d'en définir un, car une valeur fixée sans historique est précisément ce que cette fonctionnalité cherche à éviter.

La proposition est enregistrée sous forme de ligne de proposition, à l'image d'une automatisation générée à partir d'une phrase : décrite en langage clair, simulée et inactive jusqu'à ce qu'une personne la valide. Générer la proposition ne coûte rien et ne fait appel à aucun modèle ; il s'agit d'un simple calcul arithmétique sur des intervalles.

La simulation

Avant que vous ne preniez une décision, l'audit applique la règle proposée sur les 30 derniers jours et indique ce qui se serait passé. Il compte les dépassements avec la règle actuelle et ceux avec la règle proposée, puis répartit la différence en trois indicateurs : les vrais positifs (les dépassements détectés par les deux règles), les faux positifs (ceux que la règle proposée ajouterait) et les faux négatifs (ceux qu'elle cesserait de détecter).

C'est autour de cette idée que le plan de cette fonctionnalité a été conçu : autant de dépassements réels détectés au lieu de tant de fausses alertes. Si la règle proposée détecte moins de problèmes réels qu'elle ne supprime de fausses alertes, vous pouvez le constater avant qu'elle ne modifie quoi que ce soit.

• Dépassements avant : avec le SLA actuel.
• Dépassements après : avec le placement proposé.
• Vrais positifs, faux positifs, faux négatifs : la différence, qualifiée.

La validation modifie le modèle, et uniquement le modèle

Lorsque vous validez, les heures de SLA corrigées sont appliquées à l'étape désignée dans vos modèles de workflow, et le résumé indique combien de modèles ont été modifiés. À partir de ce moment, chaque nouveau projet de ce type démarre avec les heures corrigées. Rien ne change sur les tableaux en cours, et le résumé le précise explicitement.

C'est la partie sûre et réversible. La modification d'un modèle affecte des projets qui n'existent pas encore ; elle ne peut pas faire passer en dépassement aujourd'hui une tâche qui était dans les temps hier.

Les tableaux en cours, audités un par un

Après validation, l'écran de review liste les projets en cours dont l'étape active utilise encore les anciennes heures, avec le nom du projet, les heures actuelles et proposées, ainsi que le nombre de tâches ouvertes dans cette étape. Vous choisissez ceux à mettre à jour. En mettre un à jour modifie l'étape de ce projet et génère un événement d'audit ; n'en mettre aucun à jour est un choix valide.

L'écriture sur une étape active est restreinte : elle modifie les heures de SLA, le nom, la couleur ou les rôles, et refuse de changer la clé ou le type d'une étape tant que des tâches y sont associées, car modifier le type d'une étape en cours de tâche change la nécessité ou non d'une validation.

L'historique n'est pas réécrit. Chaque intervalle enregistré conserve les heures de SLA qui étaient en vigueur à son ouverture, de sorte qu'un audit lancé le mois prochain analysera toujours le mois dernier selon la règle du mois dernier.

Pourquoi ce n'est pas automatique partout

La conception la plus évidente consisterait à proposer un clic unique pour corriger le modèle et chaque tableau en cours. C'est une erreur, et le registre des décisions de cette fonctionnalité explique pourquoi : modifier un SLA sur un tableau actif requalifie ce que le produit a déjà validé. Une tâche qui respectait son délai de 48 heures se retrouve en dépassement, une relance qui ne s'est jamais déclenchée semble avoir été manquée, et un client à qui l'on avait dit que le projet était sur la bonne voie se retrouve face à une contradiction du produit.

C'est pourquoi la propagation est progressive, optionnelle, par projet, avec une ligne d'audit pour chacun. Une organisation qui souhaite que ses tableaux en cours s'alignent automatiquement sur le modèle ne peut pas disposer d'un tel paramètre, et ce refus est délibéré.