Comment créer un système de documentation des processus

En bref

• Commencez par un inventaire, pas un document : une ligne par processus, un propriétaire, une date d'échéance.
• Construire le méta-processus avant le premier document : création, approbation, publication, formation, retrait.
• Dans une bibliothèque, le document moyen passe la moitié de son intervalle de révision obsolète.
• Un changement arrivé en production avant sa cartographie est un défaut de documentation avec une date.
• Une révision qui n’a rien changé doit encore au registre une entrée datée, ou l’exactitude ressemble à de la négligence.

Le système est le méta-processus, pas le modèle

N’importe quelle organisation peut produire cinquante documents de processus, et plusieurs l’ont fait deux fois. Ce qu'un système de documentation décide, ce n'est pas la façon dont ils sont rédigés mais ce qu'ils seront vrais dans deux ans. L'arithmétique est méchante. Si rien que le calendrier impose une nouvelle révision, un changement effectué la semaine suivant une révision annuelle passe inaperçu pendant la majeure partie de l'année, et dans une bibliothèque, le document moyen passe la moitié de son intervalle de révision à décrire un travail qui a été déplacé. Un modèle de création n’a aucune incidence sur ce chiffre.

Le premier artefact n’est donc pas un document. Il s'agit d'un inventaire : chaque processus exécuté par l'organisation, une ligne chacune, avec une personne nommée responsable de sa description, du niveau auquel il est documenté et d'un intervalle de révision. Vient ensuite le méta-processus : le parcours par lequel les documents de processus sont créés, approuvés, publiés, formés et retirés. Sans cela, chaque document est conservé par quiconque s'en souvient, et la règle d'un processus qui a changé avant sa carte n'est jamais écrite.

Ce qui s’ensuit est ce méta-processus lui-même plutôt que l’un des processus qu’il régit. « Confirmer le propriétaire responsable de la politique » constitue la deuxième ligne, avant le début de toute analyse. La sortie « Aucun changement » de « Modification de la politique requise ? » atteint « Revue enregistrée, nouvelle date fixée » : une critique qui n'a rien réécrit et qui a quand même déplacé la date, ce qui est l'entrée qu'une bibliothèque vieillissante n'a jamais. Et « Redraft » renvoie la décision d'approbation à « Draft the revision in tracked changes ».

Comment cela fonctionne

1. Rédiger l'inventaire des processus avant toute cartographie

   Répertoriez chaque processus exécuté par l'organisation, sur une ligne chacun, avec une personne nommée responsable de sa description, le niveau auquel il doit être documenté et son importance. Attendez-vous à ce que la liste soit plus courte que prévu et que la colonne de propriété soit l'argument. Rien d'autre ne peut être construit tant que cette colonne présente des lacunes.

2. Définissez chaque intervalle de révision à partir du taux de changement

   Prenons l’intervalle à partir de la fréquence à laquelle le processus a réellement évolué au cours des deux dernières années plutôt que d’un défaut de politique : trois changements rapportent six mois, aucun changement en cinq ans n’en rapporte deux. Enregistrez l'intervalle, la prochaine date d'échéance et le niveau documenté dans l'inventaire, afin qu'aucun des trois ne soit réargumenté à chaque révision.

3. Construisez d'abord le méta-processus sous forme de graphique

   Avant de documenter un processus réel, divisez votre propre parcours de documentation en lignes : ce qui déclenche une révision, qui confirme le propriétaire, qui est consulté, qui approuve, comment il est publié et formé. Tapez les étapes dans la colonne de texte de la zone de texte et joignez-les par numéro de ligne dans la colonne Ligne vers. Chaque document ultérieur en hérite.

4. Mettez le niveau d'approbation sur le graphique en tant que décision

   La ligne de routage prend la décision dans la colonne Forme, avec les niveaux écrits dans le texte de la ligne par rapport aux numéros dans la ligne vers, de sorte que l'itinéraire d'une révision soit connu avant le début de la rédaction. Utilisez la colonne Voie horizontale pour la phase et la colonne Voie verticale pour le propriétaire, de sorte que le diagramme montre qu'un bureau politique et un organisme d'approbation diffèrent.

5. Dessinez la boucle de reformulation sous forme de numéro arrière

   Une approbation qui renvoie un travail est un numéro de ligne pointant vers une ligne précédente, et non une flèche que quelqu'un ajoute au dessin par la suite. Étant donné que la colonne Ligne vers contient des données, cette boucle survit à l'insertion d'une étape au-dessus d'elle. Un diagramme montrant uniquement un mouvement vers l'avant décrit un organisme d'approbation qui n'a jamais été en désaccord.

6. Auditer la bibliothèque par rapport à ses propres dates

   Chaque trimestre compte quatre chiffres : les documents ayant dépassé leur date de révision, les documents sans propriétaire nommé, les documents dont le processus a changé avant sa carte et les révisions enregistrées sans changement. Le dernier est la santé. Réservez le prochain décompte dans l'inventaire avant de clôturer celui-ci, car un décompte sans prochaine date expire et la bibliothèque recommence à se dégrader.

Erreurs à éviter

• Exécuter la documentation en tant que projet

  Le projet livre la bibliothèque, se dissout et le déclin commence la semaine de sa fermeture. La documentation est une fonction permanente avec un propriétaire et une ligne budgétaire, ou bien c'est un instantané d'un trimestre qui vieillit mal.

• Adresser le rappel à un service

  « Détenu par les opérations » signifie que la date d'échéance n'est livrée nulle part. Un service n'a pas d'agenda et pas de boîte de réception qui répond, donc le rappel est généré, adressé à une fonction, et lu par personne en particulier.

• Examiner uniquement ce qui est en rayon

  Un cycle de révision peut agir sur la liste dont il dispose, de sorte que les processus sans aucun document sont ceux qui ne font jamais surface. Construisez l'inventaire à partir du travail effectué par l'organisation, et non à partir du dossier de documents qui existe.

• Redocumentation des semaines après le changement

  Un processus qui a changé en mars et a été redocumenté en mai a été erroné pendant huit semaines, et rien dans la bibliothèque ne l'indique. Enregistrez l'intervalle avec les dates ; le modèle sur ces intervalles montre où le système fuit.

Questions fréquentes

Qu'est-ce qu'un système de documentation de processus ?

C'est l'ensemble de règles et de rôles qui maintiennent un corps de documentation de processus vrai, distinct des documents eux-mêmes : un inventaire avec un propriétaire nommé par processus, le niveau auquel chacun est documenté, un intervalle de révision dont les dates d'échéance parviennent à ces propriétaires, un taux mesuré auquel la bibliothèque prend du retard sur le travail et un itinéraire pour créer, approuver, publier et retirer un document. Le modèle compte le moins. Le test est ce que dit le registre à propos d'un document que personne n'a touché depuis trois ans.

Que doit contenir un inventaire de processus ?

Une ligne par processus : le nom du processus, le propriétaire en tant que personne plutôt qu'équipe, le niveau auquel il est documenté, son caractère critique, l'emplacement de la version actuelle et les dates de sa dernière révision et de sa prochaine échéance. Deux autres colonnes gagnent rapidement leur place : les systèmes dans lesquels le processus s'exécute, qui vous indique ce qu'une migration invalidera, et la clause qu'il existe pour satisfaire, qui vous indique ce qu'un auditeur demandera à voir. L’inventaire vient en premier parce que chaque décision ultérieure est une interrogation à son encontre.

À qui appartient un système de documentation des processus ?

Une seule personne, et non celle qui possède le plus de documents. Le propriétaire du système détient l'inventaire, le méta-processus et le registre des dates de révision ; chaque propriétaire de document détient le contenu. La fusion des deux produit l'échec familier où chaque révision fait la queue derrière la seule personne qui comprend le système, et la file d'attente est signalée comme un problème de ressources plutôt que de conception. Une demi-journée par semaine transporte une bibliothèque de cinquante processus, à condition que les rappels soient automatiques et que chaque propriétaire ait un nom.

Où doit résider la documentation du processus ?

C'est pourquoi l'emplacement est une colonne, et non une décision prise une seule fois pour l'ensemble de la bibliothèque. Un système de gestion de la qualité, un wiki et un lecteur partagé peuvent chacun contenir une version actuelle ; aucun d'entre eux ne peut vous dire quels processus n'ont pas de version actuelle. Le test n'est donc pas de savoir quelle plate-forme, mais de savoir si chaque ligne du registre indique l'endroit où ses lecteurs sont envoyés et si leur arrivée à cet endroit produit la révision revendiquée par le registre. Un processus sans ligne est invisible pour tout choix de plateforme.