Optimiser un processus : par où commencer ?

« Améliorer notre efficacité » ne suffit pas pour décider du travail à faire. Reformulez le problème autour d’un résultat : une demande attend son approbation, un dossier revient incomplet ou une équipe ignore si elle peut commencer. Précisez qui subit cette difficulté et comment elle se manifeste.

Définissez un début et une fin. Par exemple, de la réception d’une demande d’achat à la décision communiquée au demandeur. Les activités voisines restent visibles, mais elles ne deviennent pas automatiquement le périmètre de votre premier chantier.

Réunissez une personne qui déclenche la demande, une personne qui la traite et celle qui reçoit le résultat. Parcourez ensemble des cas récents, en retirant les renseignements inutiles à l’exercice. Dessinez les étapes et les décisions dans leur ordre réel. Une flèche suffit : le premier objectif est de comprendre le parcours.

Distinguez ce que vous avez observé, ce que l’équipe suppose et ce qui reste à vérifier. Le NIST présente notamment l’autoévaluation comme une manière de repérer des lacunes ou des informations contradictoires pour orienter des actions. La démarche pratique proposée ici est notre adaptation éditoriale à un processus délimité, pas une évaluation Baldrige.

Baldrige Improvement Tools

Séparez le temps passé à travailler du temps passé à attendre. Notez aussi les retours pour correction. Une demande traitée rapidement par chaque intervenant peut néanmoins traverser plusieurs périodes d’attente. Accélérer la saisie ne répondrait alors qu’à une partie du problème.

Choisissez un indicateur principal et un contrôle de qualité. Pour des dossiers incomplets, cela pourrait être la proportion de dossiers retournés, avec une vérification que les dossiers acceptés contiennent bien les éléments nécessaires. Conservez le volume observé et les types de demandes : une comparaison sans contexte serait difficile à interpréter.

Dans cette situation entièrement fictive, l’administration renvoie des demandes parce que la date souhaitée et le responsable du budget manquent. Le demandeur croit que l’administration trouvera ces informations ; l’administration attend qu’on les lui fournisse. Aucun logiciel n’est défaillant dans ce scénario.

L’équipe propose une fiche de demande avec ces deux informations et un responsable de vérification à l’entrée. Elle essaie ce fonctionnement sur un périmètre convenu, puis examine les retours et les exceptions. Aucun gain chiffré n’est présumé : il faut observer si la fiche réduit les reprises sans simplement déplacer le travail vers les demandeurs.

Remplissez cette fiche avec l’équipe avant de modifier le fonctionnement. Si une réponse manque, transformez-la en question à vérifier plutôt qu’en hypothèse cachée.

• Parcours : quel événement déclenche le travail et quel résultat le termine ?
• Irritant : quelle difficulté est observable dans les dossiers examinés ?
• Hypothèse : pourquoi ce blocage se produit-il ?
• Changement : quelle règle, information ou responsabilité allons-nous modifier ?
• Vérification : quel indicateur et quel contrôle de qualité allons-nous suivre ?
• Responsable : qui accompagne l’essai et qui décidera de sa suite ?

À la fin de l’essai, comparez les situations réellement comparables et discutez des cas qui contredisent votre hypothèse. Documentez aussi les effets sur les autres équipes. Une amélioration locale n’est utile que si elle reste compatible avec le résultat attendu du parcours.

Vous pourrez conserver le changement, le modifier ou l’abandonner. Si le problème vient ensuite d’un transfert répétitif entre des outils, un cadrage d’automatisation devient pertinent. La cartographie et les observations fourniront alors une base concrète pour définir ce projet.