Comment standardiser un processus métier

En bref

• Cartographiez les variantes avant de concevoir la norme.
• Séparez les différences requises des différences habituelles ; seul le deuxième type peut être supprimé librement.
• Standardisez également l’exception : une solution de contournement non documentée devient le véritable processus.
• Une version documentée, approuvée, avec les différences enregistrées sous forme de variantes nommées.
• Une norme que personne ne peut suivre sous pression n’est pas une norme.

La variation n’est pas la même chose que le désaccord

La normalisation part généralement d’une observation réelle (trois sites exécutent le même processus de trois manières et les chiffres diffèrent) puis échoue pour une raison spécifique : elle traite toutes les variations comme du gaspillage. Une partie l’est. Il s'agit en partie d'un site avec un régulateur différent, d'un contrat client différent ou d'une véritable contrainte que la norme briserait. Déployer un processus sans séparer ces deux types de différences est la manière dont une norme est publiée, ignorée et contournée en silence.

La première tâche ne consiste donc pas à concevoir la norme, mais à cartographier les variantes côte à côte. Une fois comparées aux mêmes étapes, les différences se répartissent en trois piles : les éléments qui doivent réellement différer, les éléments qui diffèrent en raison d'une contrainte locale qui pourrait être supprimée, et les éléments qui diffèrent parce que quelqu'un l'a configuré de cette façon en 2019. La troisième pile est généralement la plus grande, et c'est la seule qui standardise gratuitement.

L'exemple ci-dessous est un processus de demande d'achat, l'un des processus les plus sujets aux variations dans toute organisation multisite : tout le monde soumet des demandes d'achat, et chacun a un seuil différent, un itinéraire d'urgence différent et une opinion différente sur ce que les achats doivent voir. Il contient une branche accélérée explicite, qui constitue le bon moyen de standardiser une exception plutôt que de prétendre qu'elle ne se produit pas.

Comment cela fonctionne

1. Mappez chaque variante telle qu'elle est réellement exécutée

   Un tableau par site ou par équipe, tiré des personnes qui effectuent le travail et non du document de procédure locale. Les variantes documentées à partir de documents semblent toutes identiques, car tout le monde a copié le même modèle : les différences résident dans la pratique.

2. Alignez les variantes sur une colonne vertébrale commune

   Identifiez les étapes partagées par chaque version et comparez chaque variante à celles-ci. La comparaison est ce qui transforme le sentiment général selon lequel « nous faisons tous les choses différemment » en une liste spécifique de différences, ce qui constitue une conversation beaucoup plus courte et moins controversée.

3. Triez chaque différence en obligatoire, contrainte ou habituelle

   Requis signifie qu’un régulateur, un contrat ou une loi le rend nécessaire. Contraint signifie qu'un système ou une ressource locale le force pour le moment. Habituel signifie que personne ne se souvient pourquoi. Demandez au site propriétaire de justifier chacun d'eux : l'exercice de tri résout généralement la moitié des différences sans décision de personne.

4. Concevoir la norme autour des différences requises

   Créez un flux avec des branches de variantes explicites où la différence est réelle. Une norme qui ignore une exigence légale dans une région sera brisée dans cette région et discréditera l’ensemble de l’exercice ailleurs.

5. Documenter l'itinéraire d'exception

   Chaque processus a un chemin urgent. Dessinez-le, mettez-y des critères, nommez qui l'autorise et exigez que la justification soit enregistrée, comme le fait l'exemple avec sa branche accélérée. Les routes d'exception non documentées se développent jusqu'à devenir le processus.

6. Publier une version approuvée et examiner la variation

   Conservez un seul tableau approuvé avec les variantes qui y sont nommées et examinez après quelques mois la divergence qui sera apparue. La normalisation n'est pas un projet qui se termine ; c'est une version qui doit être maintenue, et le premier signe d'échec est un site avec sa propre copie mise à jour.

Erreurs à éviter

• Standardiser à partir des documents

  Les procédures locales sont généralement des copies du même original. La variation réside dans ce que font les gens, et seules les interviews et l’observation feront surface.

• Traiter toute variation comme un déchet

  Certaines différences sont nécessaires. Les supprimer produit une norme qu’un site ne peut pas légalement suivre et que tout le monde cesse de faire confiance.

• Ignorer l'itinéraire urgent

  Refuser de documenter l’exception ne la supprime pas. Il supprime les critères et le bilan, ce qui est le pire des deux.

• Publication sans version

  Une norme sans version actuelle approuvée devient plusieurs normes en un an, chacune étant éditée localement et chacune étant considérée comme la seule.

Questions fréquentes

Comment standardiser un processus sur plusieurs sites ?

Cartographiez la manière dont chaque site l'exécute réellement, comparez les variantes par rapport à une colonne vertébrale commune, puis triez chaque différence en obligatoire, contrainte ou habituelle. Concevez la norme autour des différences requises et supprimez les différences habituelles. L’ordre compte : les équipes acceptent une norme qui tient visiblement compte de leurs véritables contraintes et rejettent celle qui semble avoir été conçue ailleurs et imposée, quelle que soit la qualité de la conception.

Quelle est la différence entre normalisation et centralisation ?

La normalisation signifie que tout le monde suit le même processus ; la centralisation signifie qu’une équipe le fait pour tout le monde. Il s’agit de choix indépendants et souvent confus, ce qui rend la conversation plus difficile qu’elle ne devrait l’être. Vous pouvez standardiser un processus que chaque site continue d'exécuter localement, et c'est souvent la meilleure première chose à faire : il capture l'essentiel des avantages en termes de cohérence sans interruption ni perte de connaissances locales.

Comment gérer un site qui a réellement besoin de se différencier ?

Insérez la différence dans la norme sous la forme d'une branche de variante nommée plutôt que d'accorder une exemption. Une branche reste visible, est révisée avec le reste du processus et peut être supprimée lorsque la contrainte sous-jacente disparaît. Une exemption est invisible, non révisée et permanente, et elle invite également tous les autres sites à en demander une.

Comment empêcher le retour en arrière d’un processus standardisé ?

Une version approuvée que les utilisateurs peuvent atteindre, un propriétaire nommé et une vérification périodique des divergences. La dérive n’est généralement pas une rébellion ; il s'agit d'une solution locale à un problème réel qui n'a jamais été réintégré dans la norme. Donnez aux sites un itinéraire pour proposer des changements et agir en conséquence, sinon ils effectueront le changement localement et la norme deviendra un document sur le passé.