documenter correctement, il faut un système unifié de gestion de la documentation. En
fait, ce n’est pas du tout nécessaire. On peut parfaitement disposer de deux, voire trois
dispositifs de gestion de documentation. Par exemple, certains services préféreront
publier leurs procédures sur l’Intranet. D’autres services préféreront reposer sur un
système de gestion de la documentation (soit géré en local, soit géré dans le cloud).
Enfin, d’autres placeront tout simplement leurs documents dans des partages réseau. En
fait, peu importe comment les documents sont publiés, du moment que les personnes
concernées savent où les trouver et que la documentation n’est accessible que par les
personnes ayant réellement besoin de la connaître.
Une deuxième idée reçue consiste à croire que les procédures doivent être des documents
détaillés. Ce n’est pas le cas. Une procédure doit décrire les différentes étapes du
processus, mais il n’est pas nécessaire d’entrer dans les détails de l’exécution. En
revanche, si un processus est particulièrement sensible et si très peu de gens savent
l’opérer, il est possible de compléter la procédure par des modes opératoires détaillés,
décrivant très précisément les commandes à taper, les messages affichés et les cases à
cocher. Cependant, cela reste marginal.
Maintenant que ces deux idées reçues sont corrigées, il reste à attirer l’attention sur une
grande erreur souvent commise. Les procédures sont généralement rédigées juste au
moment de la mise en place des processus et décrivent ce que leur auteur croit (ou
souhaiterait) savoir effectif. Concrètement, les rédacteurs de procédures ont tendance à
formaliser des processus idéaux vers lesquels ils souhaiteraient tendre, au lieu de coller
strictement à la réalité. Or, la réalité est que les processus tardent toujours quelques mois
avant de se stabiliser dans leur mode opératoire. Il est donc préférable de formaliser les
processus une fois qu’ils sont stabilisés.
La difficulté dans la rédaction de procédures est de trouver le bon niveau de granularité.
Un niveau trop général masquera des étapes importantes. Un niveau trop précis rendra la
compréhension d’ensemble plus difficile. L’expérience montre qu’une procédure bien
rédigée n’occupe en volume que trois à huit pages pour les plus complexes. Au-delà, on
est plus dans le registre du mode opératoire que dans la procédure.
Le contenu de la procédure est simple. Il suffit d’expliquer clairement qui fait quoi,
quand, et en générant quelle trace. L’idéal est de faire rédiger la procédure par un
qualiticien ou par un consultant externe sachant bien rédiger. Il est rare que les opérateurs
de processus sachent bien formaliser les procédures qu’ils exécutent (à chacun son
métier). Concrètement, l’idéal est que le rédacteur observe le processus et se le fasse
expliquer par l’opérateur. Ceci lui permet de formaliser la procédure et de la faire valider
par l’opérateur. Après prise en compte des corrections, la procédure peut être validée puis
publiée.
Comme les processus sont des systèmes en évolution constante, il est fortement
recommandé de procéder à une revue annuelle de toutes les procédures, afin de vérifier
qu’elles collent toujours strictement à la réalité.
Remarque
Les annexes de la troisième partie de cet ouvrage proposent des exemples très variés de procédures.
fait, ce n’est pas du tout nécessaire. On peut parfaitement disposer de deux, voire trois
dispositifs de gestion de documentation. Par exemple, certains services préféreront
publier leurs procédures sur l’Intranet. D’autres services préféreront reposer sur un
système de gestion de la documentation (soit géré en local, soit géré dans le cloud).
Enfin, d’autres placeront tout simplement leurs documents dans des partages réseau. En
fait, peu importe comment les documents sont publiés, du moment que les personnes
concernées savent où les trouver et que la documentation n’est accessible que par les
personnes ayant réellement besoin de la connaître.
Une deuxième idée reçue consiste à croire que les procédures doivent être des documents
détaillés. Ce n’est pas le cas. Une procédure doit décrire les différentes étapes du
processus, mais il n’est pas nécessaire d’entrer dans les détails de l’exécution. En
revanche, si un processus est particulièrement sensible et si très peu de gens savent
l’opérer, il est possible de compléter la procédure par des modes opératoires détaillés,
décrivant très précisément les commandes à taper, les messages affichés et les cases à
cocher. Cependant, cela reste marginal.
Maintenant que ces deux idées reçues sont corrigées, il reste à attirer l’attention sur une
grande erreur souvent commise. Les procédures sont généralement rédigées juste au
moment de la mise en place des processus et décrivent ce que leur auteur croit (ou
souhaiterait) savoir effectif. Concrètement, les rédacteurs de procédures ont tendance à
formaliser des processus idéaux vers lesquels ils souhaiteraient tendre, au lieu de coller
strictement à la réalité. Or, la réalité est que les processus tardent toujours quelques mois
avant de se stabiliser dans leur mode opératoire. Il est donc préférable de formaliser les
processus une fois qu’ils sont stabilisés.
La difficulté dans la rédaction de procédures est de trouver le bon niveau de granularité.
Un niveau trop général masquera des étapes importantes. Un niveau trop précis rendra la
compréhension d’ensemble plus difficile. L’expérience montre qu’une procédure bien
rédigée n’occupe en volume que trois à huit pages pour les plus complexes. Au-delà, on
est plus dans le registre du mode opératoire que dans la procédure.
Le contenu de la procédure est simple. Il suffit d’expliquer clairement qui fait quoi,
quand, et en générant quelle trace. L’idéal est de faire rédiger la procédure par un
qualiticien ou par un consultant externe sachant bien rédiger. Il est rare que les opérateurs
de processus sachent bien formaliser les procédures qu’ils exécutent (à chacun son
métier). Concrètement, l’idéal est que le rédacteur observe le processus et se le fasse
expliquer par l’opérateur. Ceci lui permet de formaliser la procédure et de la faire valider
par l’opérateur. Après prise en compte des corrections, la procédure peut être validée puis
publiée.
Comme les processus sont des systèmes en évolution constante, il est fortement
recommandé de procéder à une revue annuelle de toutes les procédures, afin de vérifier
qu’elles collent toujours strictement à la réalité.
Remarque
Les annexes de la troisième partie de cet ouvrage proposent des exemples très variés de procédures.