Comment documenter un processus métier
Comment documenter un processus pour qu'il reste vrai : nommez un propriétaire par étape, enregistrez les règles de décision, placez le document sous contrôle et approbation de version et fixez une date de révision. Avec un exemple vivant.
Documenter un processus signifie capturer ce qui se passe, qui est responsable de chaque étape et quelles sont les règles de décision, sous une forme comportant une version actuelle, un propriétaire nommé et une date de révision.
En bref
- Une version actuelle, identifiable comme actuelle. Tout le reste est une copie.
- Chaque étape nomme un rôle responsable ; chaque décision énonce sa règle et son seuil.
- Dites où aboutissent les preuves : quel système, quel enregistrement, quel enregistrement.
- L'approbation avec une signature et une date est ce qui transforme un document en document contrôlé.
- Fixez une date de révision et révisez en cas de problème.
Pourquoi la documentation des processus n'est plus fiable
Presque toutes les organisations disposent d’une documentation sur les processus. On y fait très peu confiance, et la raison en est rarement l'écriture. C'est que personne ne peut dire quelle copie est actuelle. Une procédure se présente sous la forme d'un fichier Word dans un lecteur partagé, d'un diagramme dans le diaporama de quelqu'un et d'une page wiki mise à jour il y a dix-huit mois, et chacun des trois a raison sur quelque chose de différent. Le travail de documentation d’un processus ne consiste qu’à moitié à l’écrire ; l'autre moitié consiste à rendre une version identifiable comme étant celle convenue.
Le test du contenu est simple : quelqu’un qui n’a jamais fait ce travail pourrait-il l’exécuter, et un étranger pourrait-il dire s’il a été suivi ? Cela signifie que chaque étape nomme un propriétaire, chaque décision énonce sa règle et son seuil plutôt que de dire « le cas échéant », et chaque étape qui produit un enregistrement indique où va l'enregistrement. "Vérifiez les coordonnées bancaires" est un sentiment. "Appelez le vendeur au numéro indiqué sur le contrat signé, jamais au numéro figurant sur la facture, et notez qui l'a vérifié et quand" est un contrôle.
L'exemple ci-dessous est un processus d'intégration d'un fournisseur. Lisez le texte de la procédure sous le canevas à côté du diagramme : ils sont générés à partir des mêmes lignes, c'est là l'essentiel. Lorsque le schéma et la procédure écrite sont deux documents, ils divergent, et la divergence est invisible jusqu'à ce qu'un auditeur les mette côte à côte.
Comment cela fonctionne
Décidez à quoi sert le document
Former un nouvel arrivant, satisfaire un auditeur et régler des disputes entre équipes nécessitent différents niveaux de détail. Notez celui que vous faites, car cela détermine la quantité qui entre. Essayer de servir les trois à la fois produit un document trop long pour s'entraîner et trop vague pour faire un audit.
Capturez le flux avant la prose
Construisez d'abord le processus sous forme de graphique : les étapes sous forme de lignes, les connexions par numéro de ligne, une voie de propriétaire par étape. Le diagramme force les lacunes à apparaître : une étape sans propriétaire, une branche sans étiquette et une exception manquante sont toutes visibles dans un graphique et faciles à masquer dans un paragraphe.
Donnez à chaque étape un propriétaire et à chaque décision une règle
Mettez le rôle responsable dans l'étape et la règle de décision dans son commentaire : le seuil, les critères, qui peut accorder une exception. Remplacez « le cas échéant » et « en temps opportun » par des chiffres partout où vous le pouvez, et lorsque vous ne pouvez vraiment pas, nommez qui décide.
Dites où atterrissent les preuves
Pour chaque étape qui produit un enregistrement (un agrément, un contrat signé, une inscription dans un registre), notez quel système le détient et sous quel nom. C'est la différence entre la documentation qui survit à un audit pas à pas et la documentation qui génère une demande de suivi.
Faites-le approuver, pas seulement publié
Acheminez le graphique terminé via le flux de travail d'approbation de QueryChart afin que la version actuelle comporte un réviseur, une signature et une date. C’est ce qui en fait un document contrôlé plutôt qu’un fichier : une version approuvée, un historique des modifications immuable et aucune ambiguïté quant à la copie que les gens devraient lire.
Définir une date de révision et un déclencheur
Choisissez une cadence (annuelle est courante, semestrielle pour tout ce qui change souvent) et ajoutez une règle selon laquelle le processus est examiné après tout incident, constatation d'audit ou modification du système qui le touche. La documentation se détériore silencieusement, et une date sur la page constitue la défense la moins coûteuse contre elle.
Erreurs à éviter
Deux documents, un processus
Un diagramme dans un dossier et une procédure écrite dans un autre divergeront, et personne ne le remarquera jusqu'à ce qu'ils soient comparés sous pression. Conservez une source et générez les vues à partir de celle-ci.
"Le cas échéant"
De vagues qualificatifs déplacent la décision du document vers la personne qui est en service. C’est le contraire de documenter un processus. Écrivez le seuil ou écrivez qui décide.
Aucun propriétaire nommé
Un document que tout le monde peut modifier et que personne ne possède est un document que personne ne met à jour. Un nom, sur la page.
Version par nom de fichier
process_v3_FINAL_updated2.docx n'est pas un contrôle de version ; c'est un exercice d'archéologie. Utilisez un système capable de vous indiquer quelle version est approuvée et ce qui a changé entre les révisions.
Questions fréquentes
Quelle est la différence entre un document de processus et une SOP ?
Un document de processus décrit le déroulement du travail, généralement entre plusieurs rôles : séquence, décisions, transferts. Une SOP est une instruction pour effectuer une tâche, écrite pour la personne qui l'effectue, et comprend souvent des détails qu'une carte de processus ne contiendrait pas : captures d'écran, valeurs exactes des champs, notes de sécurité. En pratique, ils s'associent : la cartographie du processus montre comment les SOP se connectent, et chaque SOP en développe une étape.
Dans quelle mesure la documentation du processus doit-elle être détaillée pour un audit ?
Suffisamment détaillé pour qu'un auditeur puisse choisir un cas réel, suivre votre document et trouver les preuves là où le document indique qu'elles se trouveront. Cela signifie des propriétaires nommés, des critères de décision énoncés et un emplacement pour chaque enregistrement. Ce que recherchent les auditeurs n'est pas la longueur mais la cohérence : un processus documenté, des preuves qu'il a été suivi et un dossier d'approbation montrant que la version documentée est la version actuelle.
Qui doit rédiger la documentation du processus ?
Quelqu'un qui ne fait pas le travail, travaillant à partir d'entretiens avec les gens qui le font. Les praticiens sautent les étapes qui sont devenues automatiques pour eux, qui sont exactement celles dont un nouvel arrivant a besoin. Rédigez-le en tant qu'étranger, puis faites-le corriger par les praticiens : les corrections sont rapides, et ce qu'ils ajoutent, c'est la connaissance tacite qui n'en fait jamais une première ébauche.
À quelle fréquence la documentation du processus doit-elle être révisée ?
Sur une cadence fixe et sur des déclencheurs spécifiques. La référence commune est annuelle, et semestrielle pour les processus à fort changement. Les déclencheurs sont plus importants : un examen après un incident, un résultat d'audit, une migration du système ou une réorganisation qui déplace un propriétaire de voie. La plupart des déclins surviennent à cause de changements non examinés et non à cause du passage du temps.