Comment suivre les changements dans un processus

Comment suivre les modifications dans un processus : le journal des modifications de QueryChart nomme la personne qui a modifié une règle de décision ou un seuil, la valeur précédente du champ et sa valeur actuelle, afin que personne ne…

Suivre les modifications dans un processus signifie conserver une trace exacte du champ modifié, de la personne qui l'a modifié et de la valeur qu'il a remplacée, et pas seulement de l'existence d'une nouvelle version.

En bref

  • Une modification du seuil d'une ligne de décision (deuxième approbateur requis au-dessus de 5 000 $ et au-dessus de 10 000 $) devient une entrée du journal des modifications indiquant qui l'a modifiée et quelle valeur elle a remplacée.
  • Chaque modification est attribuée : acteur, champ, valeur précédente, valeur actuelle et horodatage, et pas seulement "graphique mis à jour".
  • Comparer les versions donne une différence plus complète lorsqu'il y a plus de déplacements entre deux révisions que ce qu'une seule entrée du journal des modifications couvre.
  • La restauration d'une ancienne version annule complètement la modification, plutôt que de demander à quelqu'un de se souvenir et de retaper la règle précédente.
  • Suivre une modification est différent du contrôle d'une modification : il s'agit de l'enregistrement laissé par une modification, et non de la porte d'approbation indiquant si elle doit se produire.

Qui a déplacé le seuil et quand

Un propriétaire de processus augmente le montant en dollars d'une ligne de décision de 5 000 $ à 10 000 $ : un champ, une modification, enregistré en quelques secondes. Trois semaines plus tard, une facture de 7 000 $ est réglée sans deuxième approbateur, et la question n'est pas de savoir si la règle a changé mais qui l'a modifiée, quand et quel était réellement l'ancien numéro. Personne n’a écrit cela en dehors du graphique lui-même, car c’est dans le graphique que réside la règle.

QueryChart conserve cet enregistrement automatiquement. Chaque modification d'un graphique (une décision réétiquetée, une branche déplacée, un seuil modifié) écrit une entrée nommant la personne qui l'a effectuée, le champ qu'elle a touché, sa valeur précédente et sa valeur actuelle. Ouvrez le journal des modifications sur la modification ci-dessus et il indique exactement cela : le seuil a été modifié par une personne nommée, de 5 000 $ à 10 000 $, à une heure enregistrée. Personne ne tient à la main un journal des modifications séparé et personne n'a besoin de se fier à un souvenir de ce que disait la règle. Le mécanisme est entièrement couvert dans /features/version-control.

Suivre un changement n’est pas la même chose que le contrôler. Cette page concerne l'enregistrement que QueryChart conserve une fois qu'un processus a été modifié : un fait, après coup. Le contrôle des modifications est le processus de décision qui détermine si une modification doit avoir lieu, généralement avec une demande et une étape de révision ; ce mécanicien est construit chez /fr/guides/comment-creer-un-processus-de-controle-des-changements. Et si le document en discussion est une procédure écrite plutôt qu'un arbre de décision, le même journal des modifications s'applique mais la procédure pas à pas se lit différemment ; voir /fr/guides/comment-suivre-les-modifications-dans-une-sop pour cette version.

Comment cela fonctionne

  1. Ouvrir le journal des modifications après une modification

    Chaque sauvegarde écrit une nouvelle version et le journal des modifications les répertorie dans l'ordre. Ouvrez-le depuis le panneau historique du graphique pour voir quelle version a changé et qui l'a enregistrée : vous n'avez pas besoin de savoir à l'avance qu'un seuil a changé.

  2. Lire l'entrée : acteur, champ, valeur précédente, valeur actuelle

    Cliquez sur une version et son entrée nomme la personne qui l'a modifiée, le champ qu'elle a touché (l'étiquette d'une ligne, la condition d'une branche, une affectation de voie) et la valeur qu'elle détenait auparavant par rapport à la valeur qu'elle détient maintenant. C'est toute la réponse à la question de savoir qui a modifié le seuil de deuxième approbateur et ce qu'il disait, sans ouvrir un seul fil de discussion.

  3. Utilisez Comparer les versions lorsqu'une entrée ne représente pas toute l'histoire

    L'entrée d'une seule modification est précise mais étroite. Lorsque plusieurs lignes se déplacent entre la version à laquelle vous faites confiance et celle devant vous, ouvrez plutôt Comparer les versions et lisez les deux côte à côte, le même mécanisme, élargi à chaque champ qui diffère.

  4. Restaurer la version précédente si la modification doit être annulée

    Si un seuil relevé s’avère erroné plutôt qu’intentionnel, restaurez la version qui l’a précédé. La restauration remplace purement et simplement le graphique actuel par cette révision, plutôt que de demander à quelqu'un de retaper l'ancienne règle de mémoire.

  5. Nommez la règle, pas seulement la branche, pour que la différence reste lisible

    Écrivez l'étiquette d'une ligne de décision et ses étiquettes de branche autour du déclencheur réel : "Deuxième approbateur requis ?" a répondu « Obligatoire » ou « Non requis », plutôt qu'un simple oui ou non. Une entrée du journal des modifications qui nomme un champ étiqueté est bien plus utile qu'une entrée qui indique qu'une boîte sans étiquette a été déplacée.

Erreurs à éviter

  • Poursuivre une règle modifiée via le chat et la mémoire

    Sans journal des modifications, un seuil élevé est reconstruit à partir des messages Slack et des souvenirs de l'ancien numéro, et les deux sont rarement d'accord. Chaque modification au niveau du champ est déjà attribuée et datée : la reconstruction QueryChart est conçue pour rendre inutile.

  • Confondre un montage enregistré avec un montage approuvé

    Une entrée du journal des modifications prouve qu'un seuil a été modifié et qui l'a modifié : elle ne prouve pas que quelqu'un ait signé le nouveau numéro. Si une règle comme celle-ci est censée être révisée avant de prendre effet, cette porte appartient au processus lui-même, du type construit chez /fr/templates/processus-de-controle-des-changements, et non au seul historique des versions.

  • En supposant que la piste d'audit soit déjà active

    L'historique des versions intégré de QueryChart (journal des modifications, comparaison des versions et restauration) est gratuit et actif sur chaque graphique sans configuration. Une piste d'audit chaînée par hachage mappée aux contrôles ISO 27001, SOC 2 ou HIPAA est une fonctionnalité distincte et payante qu'une organisation active délibérément ; ce n'est pas quelque chose que tous les graphiques contiennent par défaut simplement parce que les modifications sont suivies.

Questions fréquentes

Qu'enregistre exactement le journal des modifications lorsqu'un processus change ?

Pour chaque modification, une entrée nommant la personne qui l'a effectuée, le champ qu'elle a modifié (l'étiquette d'une ligne, une condition de branche, une affectation de voie) et la valeur de ce champ avant la modification par rapport à sa valeur après. L'augmentation du seuil de deuxième approbateur de 5 000 $ à 10 000 $ produit une entrée qui dit précisément cela, attribuée et horodatée, sans que personne ne maintienne un journal séparé. Le mécanisme est entièrement couvert dans /features/version-control.

Le suivi des modifications du processus est-il la même chose que le contrôle des modifications ?

Non. Le suivi d'une modification est l'enregistrement que QueryChart conserve automatiquement après une modification : qui, quel champ, ancienne valeur, nouvelle valeur. Le contrôle des modifications est le processus de décision qui détermine si une modification doit avoir lieu, généralement avec une demande, une étape de révision et un chemin de restauration. Les deux sont importants, mais ils répondent à des questions différentes ; la mécanique du second est chez /fr/guides/comment-creer-un-processus-de-controle-des-changements.

En quoi est-ce différent du suivi des modifications dans une SOP ?

Le journal des modifications lui-même est identique (même acteur, champ et valeurs avant/après) car un arbre de décision et une procédure écrite sont tous deux des graphiques sous le même historique de versions. La différence réside dans ce qui est généralement modifié : un processus comme celui-ci modifie les conditions de branchement et le routage, tandis qu'une SOP modifie plus souvent le texte et la responsabilité de l'étape. Voir /fr/guides/comment-suivre-les-modifications-dans-une-sop pour cette version de la même fonctionnalité.

Puis-je voir tout ce qui a changé entre deux versions, pas seulement une modification ?

Oui : ouvrez Comparer les versions plutôt qu'une seule entrée du journal des modifications, et il place deux révisions côte à côte avec chaque champ différent marqué. C’est l’outil d’une règle qui a dérivé sur plusieurs petites modifications plutôt que sur une seule évidente.

La restauration d'une ancienne version supprime-t-elle la modification qui a modifié le seuil ?

Non. La restauration rend une ancienne version à nouveau actuelle, mais la version dans laquelle le seuil a changé existe toujours dans l'historique du graphique : son entrée du journal des modifications n'est pas effacée, donc l'enregistrement de qui l'a augmenté et quand survit à la restauration.

Plus dans Guides de cartographie des processus

Browse all Guides sur la gouvernance des processus, la conformité et les audits