La documentation des processus transforme la connaissance « de terrain » en connaissance organisationnelle. Avec Trupeer, vous pouvez gagner des heures sur la capture de la façon dont le travail est réellement effectué en commençant par un modèle de documentation de processus gratuit, en le personnalisant avec vos directives de marque, puis en transformant des documents de processus écrits en parcours vidéo clairs que les équipes utilisent vraiment.

Qu’est-ce qu’un modèle de documentation de processus ?

La documentation de processus est le relevé écrit de la manière dont le travail est réellement effectué : les étapes, qui les exécute, dans quel ordre, avec quelles entrées, et à quoi ressemble le résultat final.

Un modèle de documentation de processus est la structure réutilisable pour le capturer. Les champs d’en-tête, le format des étapes et les informations qui rendent un document utilisable par quelqu’un qui n’a pas encore réalisé le travail.

Chaque modèle que vous trouverez propose à peu près la même chose : un objectif, un périmètre, une liste d’étapes numérotées avec des responsables, et un endroit pour insérer un organigramme. Cette structure est correcte. Ce qu’elle produit, en revanche, c’est un document décrivant la version du processus où tout se déroule comme prévu, c’est-à-dire la version dont personne n’a besoin pour obtenir de l’aide.

Pourquoi la voie « normale » est la partie dont personne n’avait besoin

Demandez à quelqu’un de documenter un processus et il décrira comment il fonctionne. C’est la réponse naturelle à la question, mais c’est un contenu erroné.

La personne qui lira le document peut généralement gérer le cas standard en une semaine. Elle regarde quelqu’un le faire deux fois, elle s’y met, et tout va bien. Ce qu’elle ne peut pas faire, en revanche, c’est gérer l’ordre avec un numéro de bon de commande manquant, le client dont le prix ne correspond pas au contrat, la pièce qui a été arrêtée, le compte qui vient juste de dépasser sa limite de crédit.

Ces situations ne sont pas rares. Dans la plupart des processus opérationnels, elles représentent la majorité du travail en temps, même si elles sont minoritaires en volume, car chacune prend plusieurs fois plus de temps qu’un cas « propre ».

Ce sont aussi les contenus les plus difficiles à rédiger, pour une raison qui vaut la peine d’être comprise. La personne qui documente le processus a géré chaque exception des centaines de fois et, depuis longtemps, a cessé de les percevoir comme des décisions. Quand on lui demande comment le processus fonctionne, elle décrit honnêtement et précisément la voie « normale », parce que c’est ce que la question invite à faire.

Ainsi, le document finit par couvrir la partie qui n’avait pas besoin d’être documentée, et en omettant la partie qui était la raison même de l’exercice.

Comment personnaliser ce modèle dans Trupeer

Étape 1 : Ouvrir la section Modèles

Accédez à la section Modèles depuis la navigation principale.

Étape 2 : Sélectionner et ouvrir un modèle

Cliquez sur n’importe quel modèle avec lequel vous souhaitez travailler pour l’ouvrir.

Étape 3 : Développer l’affichage du modèle

Si nécessaire, développez l’affichage du modèle pour voir clairement la mise en page complète et les détails.

Étape 4 : Modifier le modèle

Cliquez sur Modifier pour commencer à apporter des changements au modèle sélectionné.

Dans l’éditeur, vous pouvez :

• Ajouter de nouvelles sections

• Définir ou mettre à jour des règles de mise en forme

• Ajouter un logo et ajuster sa position ainsi que les paramètres associés

Étape 5 : Enregistrer votre modèle personnalisé

Une fois tous les changements nécessaires effectués, cliquez sur Enregistrer pour stocker le modèle mis à jour comme le vôtre.

Étape 6 : Prévisualiser et affiner le modèle

Lorsque vous souhaitez voir à quoi ressemble votre modèle personnalisé, ouvrez la Prévisualisation.

Depuis l’écran de prévisualisation, vous pouvez continuer à effectuer des ajustements directement si nécessaire, afin de garantir que le modèle s’affiche exactement comme vous le souhaitez.

Avec un modèle de documentation de processus, vous pouvez :

• Gagner du temps sur la documentation : évitez la page blanche grâce à une structure conçue pour tout type de processus métier.

• Capturer la connaissance « de terrain » : documentez la manière dont le travail est réellement effectué — pour que la connaissance reste disponible même lorsque les personnes partent.

• Rester conforme à votre marque : appliquez votre logo, vos polices et vos couleurs à l’aide du kit de marque de Trupeer — parfait pour les documents de processus interfonctionnels.

• Créer des SOP à partir des documents de processus : utilisez notre créateur de SOP IA pour transformer chaque étape en une instruction de travail détaillée.

• Identifier les améliorations : documenter un processus est la première étape pour l’améliorer — le modèle rend les inefficacités visibles.

• Atteindre des équipes à l’échelle mondiale : traduisez la documentation de processus en 65+ langues en un clic.

Comment calculer votre taux d’exception avant d’écrire

Avant d’écrire quoi que ce soit, découvrez quelle proportion du travail réel suit la voie standard. Cela prend un après-midi et change ce que vous allez rédiger.

Prélevez un échantillon des occurrences récentes du processus. Trente suffisent pour être indicatif ; deux cents sont mieux si les données sont faciles à obtenir. Des échantillons consécutifs plutôt que sélectionnés, car les échantillons sélectionnés sont toujours plus « propres » que la réalité.

Pour chacune, posez une seule question : est-ce que cela s’est déroulé directement, ou bien quelque chose a dû être décidé, relancé, corrigé ou escaladé ?

Ensuite, regroupez celles qui n’ont pas suivi la voie standard et comptez-les.

Deux chiffres ressortent. La proportion des cas « propres », qui vous indique la part du travail qu’un document de voie « normale » couvrirait. Et la liste classée des types d’exception, qui détermine l’ordre dans lequel vous devez écrire.

La plupart des équipes sont surprises par les deux. Un processus que tout le monde décrit comme simple s’avère, dans la pratique, fonctionner « proprement » sur un tiers ou la moitié des occurrences, et les trois principaux types d’exception représentent généralement la majeure partie du reste. Ces trois exceptions méritent plus d’attention rédactionnelle que les quatorze étapes standard réunies.

La ligne « et si ce n’est pas le cas » dont chaque étape a besoin

La version la plus légère de cette discipline ne coûte presque rien et peut s’appliquer à un document que vous avez déjà.

Prenez chaque étape. Chacune implique une condition remplie : le champ est renseigné, le prix correspond, le stock existe, l’approbation est en place. Sous chaque étape, écrivez une ligne commençant par « et si ce n’est pas le cas ».

Étape : vérifier que le numéro de bon de commande est présent et au format du client. Et si ce n’est pas le cas : demandez-le au demandeur par email à l’aide du modèle, mettez la commande dans la file d’attente en attente, et ne poursuivez pas l’allocation.

Cette seule ligne fait trois choses. Elle met en évidence l’exception, qui est souvent la première fois que quelqu’un la consigne par écrit. Elle impose une décision sur ce qui doit se passer, et il s’avère fréquemment que ce n’est pas encore convenu. Enfin, elle indique au lecteur quoi faire à la place, au lieu de le laisser inventer quelque chose ou interrompre quelqu’un.

Lorsque la réponse « et si ce n’est pas le cas » dépasse environ deux lignes, elle doit figurer dans une section distincte dédiée aux exceptions, avec ses propres règles de décision, et l’étape doit simplement y renvoyer. Lorsque la réponse est vraiment « demander à un superviseur », dites-le explicitement et nommez le rôle, car une escalade non indiquée est ce qui provoque les interruptions que vous essayiez d’éliminer.

Modèle de documentation de processus gratuit : la structure à copier

Copiez depuis ici.

En-tête. Nom du processus, formulé comme un résultat plutôt que comme un département. Responsable, en tant que rôle. Date de dernière vérification, c’est-à-dire quand quelqu’un a exécuté le processus pour la dernière fois à partir de ce document. Version. Fréquence et volume estimés.

Ce que produit ce processus. Le résultat final, décrit de façon à ce qu’un lecteur puisse savoir quand il l’a obtenu.

Déclencheur et périmètre. Ce qui le démarre, ce qui le termine, et ce qui se trouve immédiatement de part et d’autre, mais que ce document ne couvre pas. Les périmètres sont l’endroit d’où proviennent les documents dupliqués et contradictoires.

Qui est impliqué. Des rôles plutôt que des noms, avec ce dont chacun est responsable.

Entrées et systèmes. Ce qui doit exister avant de commencer, et quels systèmes ainsi que quels accès sont nécessaires.

Étapes. Numérotées, une action par ligne, avec le résultat attendu et une ligne et si ce n’est pas le cas sous chaque étape.

Exceptions. La liste classée issue de votre échantillon, chacune avec la condition, la règle de décision, qui peut autoriser, et ce qui se passe ensuite. Cette section finit généralement plus longue que les étapes, et c’est normal.

Ce que ce processus ne couvre pas. Indiquez-le explicitement, avec un renvoi vers l’endroit où ces cas sont traités.

Indicateurs. Durée habituelle, volume, et proportion des cas « propres ». Ce dernier chiffre vaut la peine d’être suivi, car il évolue lorsque le processus change.

Copiez jusqu’ici. Les deux ajouts à un modèle conventionnel sont les lignes et si ce n’est pas le cas et la section dédiée aux exceptions. Le reste, vous le trouverez dans n’importe quelle structure correcte.

Que faut-il inclure dans un modèle de documentation de processus

L’en-tête, le périmètre, les rôles, les étapes et les exceptions ci-dessus. Trois champs valent la peine d’être protégés contre toute personne qui voudrait réduire le document.

Dernière vérification, pas dernière mise à jour. Modifier la formulation n’est pas la même chose que confirmer que le processus fonctionne toujours de cette manière. Une date qui signifie que quelqu’un a observé le processus en action vaut plusieurs dates qui signifient seulement que quelqu’un a corrigé une faute de frappe.

Le périmètre. La plupart des documents dupliqués existent parce que deux équipes ont documenté des tranches qui se chevauchent du même processus sans s’être mises d’accord sur l’endroit où chacune s’arrêtait.

Le taux de cas « propres ». C’est le seul indicateur qui vous dit si le document décrit le travail réel ou une version idéalisée.

Trois choses valent la peine d’être exclues. Les captures d’écran d’interfaces qui changent, car elles rendent le document obsolète plus vite que les mots. Les explications sur la raison d’être du processus, qui relèvent d’une politique. Et les détails sur les systèmes qui se trouvent dans votre documentation informatique et doivent être référencés plutôt que reformulés.

Le distributeur dont le document couvrait 31 % des commandes

Pellowe Trading, un distributeur « business to business », a documenté son traitement des commandes lorsque deux coordinateurs expérimentés ont démissionné à moins d’un mois d’intervalle.

La documentation était exhaustive selon n’importe quelle norme habituelle. Quatorze étapes, un organigramme, des captures d’écran, vingt-deux pages, validées avant le départ des deux coordinateurs.

Deux remplaçants ont été recrutés. En six semaines, le carnet de commandes est passé d’environ quarante commandes à environ trois cent dix, et la clôture comptable a glissé de neuf jours.

L’enquête a porté sur deux cents commandes consécutives et a vérifié combien avaient suivi les quatorze étapes documentées sans écart.

Soixante-trois. Les cent trente-sept autres avaient rencontré au moins une exception.

Classées, ces exceptions étaient : un numéro de bon de commande client manquant ou mal formaté, quarante et une fois. Un prix sur la commande ne correspondant pas à la liste des prix du contrat, vingt-neuf fois. Une pièce arrêtée nécessitant un substitut, vingt-deux fois. Une limite de crédit dépassée, dix-huit fois. Une adresse de livraison non enregistrée sur le compte, quatorze fois. Une livraison fractionnée demandée, treize fois.

Aucune des six n’apparaissait dans les vingt-deux pages.

Les deux coordinateurs qui partaient avaient chacun géré ces situations plusieurs fois par semaine pendant des années. Aucun n’en avait soulevé une pendant la passation, et aucun ne retenait quoi que ce soit. On leur avait demandé comment fonctionne le processus de commande, et ils avaient répondu correctement.

Le carnet de commandes a nécessité onze semaines et un renfort temporaire pour être résorbé. Deux clients ont modifié leurs comptes. L’équipe finance a estimé le coût de portage lié au retard de facturation, plus la marge perdue, à environ soixante-quatre mille livres.

La réécriture a pris quatre jours. Quatorze étapes identiques, chacune avec une ligne « et si ce n’est pas le cas », plus une section distincte dédiée aux exceptions couvrant les six cas nommés, avec les règles de décision réelles : qui peut autoriser une dérogation de prix et jusqu’à quelle valeur, la règle de substitution et qui l’approuve, ainsi que le chemin d’escalade en cas de dépassement de la limite de crédit.

Le document a été rédigé par les deux nouveaux coordinateurs et une personne de la finance, à partir de l’échantillon de deux cents commandes plutôt que de la mémoire de quelqu’un. Ce détail comptait, car les personnes qui auraient pu le rédiger à partir de leur mémoire étaient parties, et l’échantillon s’est avéré être une meilleure source que ce qu’elles auraient pu fournir.

Six mois plus tard, le temps médian de traitement des exceptions par commande était passé de vingt-deux minutes à sept, le carnet de commandes restait stable sous cinquante, et un nouvel échantillon de deux cents commandes a montré que 84 % pouvaient être résolus à partir du document sans escalader vers qui que ce soit.

Comment créer une documentation de processus, étape par étape

Commencez par prélever l’échantillon et compter les exceptions. Tout le reste est plus simple une fois que vous savez ce que vous documentez réellement.

Observez le processus en cours d’exécution, deux fois, par des personnes différentes si possible. Deux personnes qui exécutent différemment le même processus documenté constituent déjà un résultat en soi.

Rédigez le périmètre et le résultat avant les étapes, car ce sont eux qui empêchent le document de s’étendre.

Rédigez les étapes à partir de ce que vous avez observé, plutôt que de ce que le processus est censé être. Là où cela diffère, notez la différence au lieu de la lisser, car la différence est généralement soit une amélioration à adopter, soit un problème à corriger.

Ajoutez la ligne « et si ce n’est pas le cas » à chaque étape. Attendez-vous à ce que cela prenne plus de temps que la rédaction des étapes.

Rédigez ensuite la section dédiée aux exceptions à partir de votre liste classée, du haut vers le bas, et arrêtez-vous lorsque vous avez couvert celles qui représentent la majeure partie du volume. Une couverture parfaite n’est pas l’objectif et elle n’est pas atteignable.

Puis, faites exécuter une occurrence réelle à partir du document par quelqu’un qui n’a pas fait le travail, pendant que vous observez et ne dites rien. Chaque question qu’il pose est un défaut, et les questions se regroupent dans les exceptions.

Les effets d’une mauvaise documentation de processus

Le coût visible, c’est le temps d’onboarding, et c’est le plus faible d’entre eux.

Les coûts les plus importants sont plus silencieux. Les interruptions : les personnes qui connaissent le processus passent leur semaine à être sollicitées, ce qui est invisible car cela n’apparaît jamais comme un ticket. L’incohérence : deux personnes produisent des résultats différents à partir de la même entrée, et personne ne s’en rend compte avant qu’un client ne compare. Le risque lié à une personne clé : le processus ne peut pas fonctionner quand une personne est absente, et cela reste caché jusqu’à ce que ce soit le cas.

Et la dérive décisionnelle. Lorsque le document ne dit pas quoi faire, les gens décident par eux-mêmes, raisonnablement, et les décisions divergent au fil du temps jusqu’à ce qu’il n’y ait plus un seul processus à documenter.

Le schéma commun aux quatre cas est que la mauvaise documentation ne provoque pas des pannes. Elle entraîne une dégradation lente, attribuée à la charge de travail, aux effectifs ou aux problèmes de système, ce qui explique pourquoi elle est rarement corrigée par les personnes qui la subissent.

Qu’est-ce qui fait un bon modèle de documentation de processus ?

Trois choses, et aucune n’est la mise en page.

Il demande les exceptions. Un modèle avec un tableau d’étapes et rien d’autre produira à chaque fois un document de voie « normale », parce que c’est ce qu’il invite à faire.

Il inclut un champ « dernière vérification » plutôt que « dernière mise à jour », ce qui change la signification de la maintenance.

Et il impose une déclaration de périmètre, afin que le même processus ne soit pas documenté trois fois par trois équipes avec des limites différentes.

Au-delà de cela, le format compte bien moins que ce que suggèrent la plupart des comparaisons de modèles. Un document simple qui couvre les exceptions vaut mieux qu’un document élégant qui ne les couvre pas.

Formats de documentation de processus : texte, organigramme ou checklist

Trois formats, et le choix doit suivre la forme du travail plutôt que les préférences.

Étapes numérotées convient aux processus linéaires avec un début et une fin connus et peu de branches. La plupart des processus administratifs et opérationnels s’y prêtent, et c’est ce que suppose le modèle ci-dessus.

Organigramme ou swimlane convient aux processus qui se ramifient réellement, ou qui traversent plusieurs rôles avec des passations entre eux. La swimlane a sa place en particulier lorsque la question « à qui appartient ce morceau ? » revient sans cesse. C’est un mauvais contenant pour le détail, donc associez-la à la version texte plutôt que de la remplacer.

Checklist convient aux processus où l’exhaustivité compte plus que l’ordre, et elle fonctionne bien comme artefact complémentaire plutôt que comme document principal.

Règle utile : si votre processus comporte plus d’environ trois vrais points de décision, dessinez-le autant que vous l’écrivez. S’il en comporte moins, l’organigramme n’est qu’une décoration et la liste numérotée est le document.

Document de processus, SOP ou instruction de travail : lequel est-ce ?

Trois termes, utilisés de manière interchangeable, avec une distinction réelle en dessous.

Documentation de processus décrit la façon dont le travail circule, souvent entre plusieurs rôles, et c’est un format descriptif. Il répond à la question « comment cela se fait ici ».

Une SOP est normative et prescriptive. Elle indique la manière approuvée d’exécuter une tâche, elle est contrôlée, et s’en écarter constitue une déviation. Notre modèle de SOP couvre la structure.

Une instruction de travail est le niveau le plus granulaire : elle couvre une seule opération à un seul poste par un seul rôle, et dans les environnements réglementés ou de fabrication, c’est un document contrôlé, ce que couvre notre modèle d’instructions de travail pour la fabrication.

Le test pratique, c’est la conséquence. Si s’écarter du document revient simplement à travailler autrement, il s’agit d’une documentation de processus. Si s’en écarter constitue une non-conformité, c’est une SOP ou une instruction de travail, et cela nécessite un contrôle de version, une approbation et un cycle de revue que la documentation de processus ne requiert pas.

Lorsque le processus était dans la tête d’une seule personne et que cette personne part, l’exercice de documentation est en réalité une passation, et notre SOP de transfert de connaissances explique comment le faire correctement, y compris pourquoi demander à quelqu’un comment fonctionne son travail produit la voie « normale ».

Puis-je obtenir un modèle de documentation de processus dans Word ou Excel ?

Word ou Google Docs pour le document. Les étapes avec et si ce n’est pas le cas et la section dédiée aux exceptions sont du texte structuré, et ils se lisent mieux dans un document que dans des cellules.

Excel pour deux artefacts complémentaires. Le journal des exceptions, c’est-à-dire votre échantillon avec une ligne par occurrence et le type d’exception enregistré, ce qui produit la liste classée et peut être relancé plus tard pour voir si quelque chose a changé. Et le registre de processus, qui liste chaque processus documenté avec son responsable, la date de dernière vérification et le taux de cas « propres », c’est ainsi que vous gérez une bibliothèque de ces documents.

PowerPoint convient à l’organigramme ou à la vue swimlane si vous présentez le processus, et non au document lui-même.

PDF pour la version publiée une fois qu’elle a été vérifiée, exportée depuis la copie en cours.

Comment documenter un processus sans l’écrire

Le contenu des exceptions est la partie qui n’est jamais rédigée, et la raison est le temps, pas la réticence. Quelqu’un doit s’asseoir avec la personne qui sait, capturer ce qu’elle fait, puis passer une soirée à transformer des notes en quelque chose de lisible.

L’enregistrement supprime une grande partie de cela. Trupeer AI transforme un enregistrement d’écran en une procédure écrite avec les étapes et les écrans déjà capturés, de sorte que la personne qui connaît le processus l’exécute une fois plutôt que de le décrire.

Le bon réflexe consiste à enregistrer les exceptions plutôt que le cas standard. La prochaine fois qu’un écart de prix ou un bon de commande manquant survient, faites enregistrer par la personne qui le traite la manière dont elle le gère. Six enregistrements sur deux semaines couvrent la majeure partie de ce qu’une année d’essais pour l’écrire ne couvrirait pas.

Enregistrez-le. Marquez-le. Traduisez-le. Trupeer-le.

Le résultat devient des guides et des documents dans votre base de connaissances avec une identité visuelle cohérente, le créateur de SOP couvre les procédures qui doivent être contrôlées, et notre modèle d’aide-mémoire couvre la référence courte pour l’étape que les gens continuent de faire mal. Les instructions de configuration se trouvent dans le guide de configuration du modèle de document.

Questions fréquentes

Existe-t-il un modèle gratuit de documentation de processus dans Word ?

La structure ci-dessus se colle directement dans Word ou Google Docs, y compris les lignes et si ce n’est pas le cas et la section dédiée aux exceptions que les modèles standard omettent. Il n’y a pas de téléchargement verrouillé et pas de formulaire. Ajoutez la section dédiée aux exceptions avant d’écrire les étapes, car rédiger d’abord les étapes a tendance à consommer l’effort disponible.

Existe-t-il un modèle gratuit de documentation de processus dans Excel ?

Excel convient au journal des exceptions et au registre de processus plutôt qu’au document. Le journal contient une ligne par occurrence échantillonnée avec le type d’exception, ce qui produit votre liste classée. Le registre liste chaque processus avec son responsable, la date de dernière vérification et le taux de cas « propres », ce qui vous permet de savoir quels documents sont devenus obsolètes.

Existe-t-il un modèle gratuit de documentation de processus en PDF ?

Exportez une fois que le document a été vérifié par quelqu’un qui exécute le processus à partir de celui-ci, et conservez la version de travail modifiable. Les exceptions sont ajoutées en continu au fur et à mesure qu’elles apparaissent, donc un document figé devient obsolète plus vite que la plupart.

Existe-t-il un modèle de documentation de processus dans PowerPoint ?

Utilisez des diapositives pour l’organigramme ou la vue swimlane lorsque vous présentez un processus à des personnes qui doivent le comprendre plutôt que l’exécuter. C’est le mauvais contenant pour le détail, donc construisez-le à partir du document plutôt qu’à la place.

Existe-t-il un modèle de processus étape par étape dans Word ?

C’est la section des étapes de la structure ci-dessus : des actions numérotées, une par ligne, chacune avec son résultat attendu et une ligne et si ce n’est pas le cas. Limitez-vous à environ douze étapes avant d’envisager qu’il s’agit de deux processus, et mettez tout ce qui dépasse deux lignes dans la section dédiée aux exceptions.

Quelle doit être la longueur d’un document de processus ?

Quelle que soit la longueur nécessaire pour les exceptions, ce qui signifie généralement que les étapes tiennent sur une page ou deux et que la section dédiée aux exceptions est plus longue. Les documents constitués uniquement d’étapes et sans exceptions ont tendance à être courts et inutilisés. Évaluez la longueur en fonction de la capacité d’une personne nouvellement formée à réaliser une occurrence réelle à partir du document, et non en fonction du nombre de pages.

Qui doit rédiger la documentation de processus ?

Toute personne qui exécute le processus, en travaillant à partir d’un échantillon d’occurrences réelles plutôt que de la mémoire. L’exemple travaillé ci-dessus l’illustre : deux personnes avec des années d’expérience ont documenté leur propre processus de manière exhaustive et ont omis toutes les exceptions, non par négligence, mais parce que la question qui leur a été posée les invitait à décrire la voie « normale ».

À quelle fréquence faut-il revoir la documentation de processus ?

En fonction des déclencheurs, plutôt que d’un calendrier. Lorsque le système change, lorsqu’un nouveau type d’exception apparaît deux fois, lorsque la personne qui est responsable du processus part, et lorsque le taux de cas « propres » évolue. Reprélever vingt occurrences une fois par an prend une heure et vous en apprend plus qu’une relecture planifiée.