Processus, procédure et mode opératoire

Comprendre l’enjeu et le périmètre

Les distinguer permet de documenter au bon niveau et de modifier l’organisation sans réécrire inutilement chaque consigne technique.

Décrire les entrées, sorties, acteurs et décisions du processus, puis les règles de la procédure et les gestes du mode opératoire.

Passer à l’action

• Partir du résultat et des exceptions du processus
• Identifier les décisions et contrôles nécessaires
• Rédiger les instructions détaillées uniquement pour les tâches qui en ont besoin

Suivez une information plutôt qu'un organigramme : qui la crée, qui la transforme, qui la valide et qui s'en sert pour agir ? Les ruptures apparaissent souvent entre deux services, alors que chaque application semble fonctionner correctement prise isolément.

Responsabilités et moyens

Le propriétaire du processus répond du résultat, les responsables de contrôle définissent les règles, et les opérationnels valident la faisabilité.

Inclure le temps d’observation, de simplification, de rédaction, de formation et de maintien des consignes.

Produire et vérifier

Livrable utile

Un modèle de processus, les règles de validation associées et les instructions d’exécution utiles aux opérateurs.

Preuve à rechercher

Confier un cas représentatif à une personne habilitée qui n’a pas rédigé la documentation et observer les ambiguïtés.

Indicateur à interpréter

Suivre les reprises de dossier et les erreurs liées à une règle incomprise, en distinguant défaut documentaire et défaut de formation.

Un schéma est une hypothèse de fonctionnement. Demandez à un utilisateur de raconter un dossier réel, y compris une exception et un retour en arrière. Notez les outils informels et les personnes indispensables plutôt que de les faire disparaître du dessin.

Arbitrages et dépendances

Une procédure très détaillée peut masquer l’absence de responsable du résultat ou des cas d’exception non traités.

Les outils, habilitations, référentiels de données et règles de validation doivent rester cohérents avec le processus décrit.

La bonne unité de raisonnement est le service rendu. Remplacer un logiciel sans traiter une validation ambiguë ou une information manquante peut déplacer le problème. Distinguez donc ce qui relève de l'organisation, de la donnée et de la technique avant de choisir une réponse.