Analyser des processus avec le logigramme
Nous avons vu dans un article précédent comment et pourquoi utiliser un ordinogramme pour décrire ou analyser un processus (LIEN). Une des difficultés de l’analyse réside essentiellement dans le fait que les processus « traversent » souvent différents éléments de l’entreprise (services, interlocuteurs…), en dessinant des flux qui peuvent nécessiter une autre façon de faire pour les représenter, comme le logigramme ou flugramme.
- L'ordinogramme (ou flowchart de programmation) est orienté système / traitement technique : il décrit l'enchaînement logique d'un algorithme, les calculs et les flux de données exécutés par une machine.
- Le logigramme (ou flowchart organisationnel / flugramme) est orienté processus / acteur : il décrit le parcours d'une tâche ou d'un dossier à travers différentes étapes ou acteurs.
Dans une démarche de résolution de problèmes, il peut être utilisé à la fois à l'étape de formulation du problème et à la fois à l'étape de recherche des causes.
A noter que si vous avez à traiter des problématiques de robinets, de flux de matière ou d'information, c'st probablement l'outil qu'il vous faut.
Objectifs
Dans un processus, décrire le parcours d'une tâche ou d'un dossier à travers différents services, en mettant en lumière qui fait quoi, les documents utilisés et les règles de gestion métier.
Déroulement
Concevoir un logigramme n'est pas compliqué. Il y a trois étapes simples à considérer :
- Rédaction d’un organigramme séquentiel le long duquel on identifie les acteurs concernés
- Construction d’une grille dont les bandes verticales correspondent aux différents acteurs
- Réécriture de l’ordinogramme en disposant ses cases dans les différentes colonnes du logigramme
Points de vigilance
- Le flou des rôles (« Qui fait quoi ? ») : Oublier de rattacher clairement les actions à des acteurs ou des services identifiés (les « couloirs » ou swimlanes sont indispensables).
- La confusion de niveau (Macro vs Micro) : Mélanger des étapes globales de validation et des micro-actions bureaucratiques dans un même niveau de lecture.
- L'impasse sur les boucles de reprise : Oublier de représenter les cas de rejet (ex. : dossier incomplet renvoyé à l'émetteur), ce qui rend le schéma irréaliste face à la complexité du terrain.
- L'excès de formalisme graphique : Vouloir utiliser des dizaines de symboles ésotériques incompréhensibles pour les opérationnels non initiés.
- Le document « placard » obsolète : Dessiner un processus théorique idéal au bureau (« le "dossier tel qu'on aimerait qu'il soit" ») au lieu de cartographier la réalité du terrain.
Quelques mots sur l'origine de la méthode
Le logigramme est le cousin organisationnel de l'ordinogramme. Issu de la même lignée que les diagrammes de processus industriels des Gilbreth (années 1920), il s'est émancipé du monde strictement informatique dans les années 1960-1970 avec l'essor du management par la qualité (normes ISO 9000) et du reengineering des processus métier (BPR).
Son objectif n'est plus de concevoir du code informatique, mais de cartographier la circulation des informations, des documents et des responsabilités entre les acteurs d'une organisation.
A lire aussi sur pragma-tic
- La résolution de problèmes est-elle une des méthodes de la gestion du temps ? (article chapeau de la série - méthodologie)
- Vous résolvez déjà des problèmes sans le savoir (article 2 de la série)
- Résoudre des problèmes : des ressentis aux faits (et des mots au dessin) (article 3 de la série)
- Du diagnostic à la décision : remonter aux causes racines et arbitrer les solutions (article 4 de la série)
- Résolution de problèmes - le kit de survie du béotien
Autres sources et références
- En savoir plus : Le logigramme sur Wikipedia
Aucun commentaire:
Enregistrer un commentaire