Le fonctionnement d’un système et donc d’une organisation/entreprise n’est en fait que l’exécution répétitive d’un ensemble de processus ayant pour objectif de transformer des éléments d’entrée (inputs) en en éléments de sortie (outputs) tout en créant de la valeur ajoutée (apportant de la plus-value).
La bonne compréhension du fonctionnement d’une organisation (et donc également tout désir d’amélioration et de changement) passe donc par une cartographie de ses processus. A ce sujet la consultation de la norme ISO 9001:2015 mérite toute votre attention et fera l’objet d’un de mes prochains articles => https://www.iso.org/fr/news/2015/09/Ref2002.html.
Que ce soit donc en gestion de projet, en gestion de l’information, en gestion des risques ou en gestion du changement (voir même en communication interne), très souvent, la première action sera la consultation (si elle existe déjà) ou la réalisation (si elle n’existe pas encore :-)) de la cartographie des processus de l’existant (« as is »). Cela est nécessaire afin de bien maîtriser (« control ») la « base » que l’on désire améliorer ou sur la quelle on va construire (en route vers le « to be »). Mais le but ne doit pas être de s’accrocher à tout prix à ce que l’on connaît bien de bien comprendre et maîtriser existant afin de construire la suite en toute connaissance de cause.
La base : le processus …
Un processus est défini comme un ensemble d’activités corrélées ou interactives qui mettent en œuvre des ressources afin de transformer des éléments d’entrée en éléments de sortie. Un élément de sortie d’un processus constitue souvent l’élément d’entrée du processus suivant.
Par exemple, pour un processus de fabrication :
-
- les « données d’entrée » sont la matière première
- les « données de sortie » sont les produits fabriqués
- les « activités » sont les étapes de la transformation des produits
- les « ressources » sont les hommes, les machines, les instructions, etc…
Les familles de processus …
Décrire le fonctionnement d’une organisation de façon globale implique de faire la différenciation des processus la constituant en trois familles complémentaires.
- Les processus de réalisation (ou processus « métier »).
Processus contribuant directement à la réalisation du produit ou du service, depuis la détection du besoin du client à sa satisfaction. Ils correspondent au cœur de métier de l’organisme. ils correspondent à la case « Mission » de la fameuse trilogie : Vision – Mission – Valeurs (voir un de mes autres articles).
Exemples : recherche et développement, conception, fabrication, livraison …
- Les processus de support (ou processus de soutien).
- Les processus de management (ou processus de direction). Processus qui contribuent à la détermination de la stratégie, des politiques (générale et particulières) et qui permettent la mise en œuvre des autres processus ainsi que leur pilotage.
Exemple : détermination des objectifs annuels, réunions de suivi périodiques, organisation interne des services, politique de sourcing, …
Mais par où commencer ?
La première action est de lister les processus de base (de premier niveau !) de l’organisation et de les classer par familles. Ces processus de base constituent les Macro-processus de votre organisation/entreprise.
Ensuite, avant de se lancer à corps perdu dans une description détaillée et une décomposition en tâches et sous-tâches, il y a lieu de décrire chacun des processus identifiés de façon synthétique. Pour ce faire, on utilisera, par processus, un diagramme « Tortue » (ou « Turtle Diagram » ou diagramme de « Crosby »).
Cette analyse macroscopique et globale permettra de mettre en avant et en lumière les éléments importants composant le macro-processus étudié.
Le Diagramme Tortue (Turtle Diagram ou encore Diagramme de Crosby).
Voici une version personnalisée ou je mes suis permis d’ajouter quelques éléments que j’estime essentiels (En blanc dans le schéma ci-dessous) .
A savoir :
- l’objectif ou les objectifs opérationnels de ce macro-processus qui permettent de définir les actions devant être faites pour pouvoir considérer que la transformation sous-jacente au macro-processus se déroule bien et de façon performante. Cette évaluation de la performance se fera sur base des indicateurs définis dans la case « Measurements » (Mesures de la performance).
- Les ayants droit et parties prenantes qui permet de lister les entités et personnes pouvant avoir une influence significative sur le déroulement du macro-processus
- le propriétaire du macro-processus qui permet de définir celui qui est en charge de sa description, de son exécution et de son évolution du macro-processus.
Et la suite …
Chaque processus fera ensuite l’objet d’une description microscopique ou l’on détaillera les différents sous-processus et les différentes activités le composant ainsi que les différents acteurs y intervenant.
Afin d’être affinée et précisée, cette description se fera ensuite sur plusieurs niveaux de manière à mettre en évidence les tâches et les activités sous-jacentes.
Pour ce faire, on utilisera (par Ex) la notation BPMN (Business Process Model and Notation) qui est un langage normalisé de représentation des processus métiers;
On évitera néanmoins de trop multiplier les niveaux sinon le résultat final devient relativement inexploitable. Une bonne pratique dit de se limiter à maximum 03/04 niveaux.
Mais cela devient une autre histoire 🙂 …
Très bon article. Très utile. Merci d’avoir pris de votre temps pour éditer ce contenu.
En se basant sur la version 2015 de la norme, je m’attendais à voir apparaître quelque part, la notion de risque. Pourriez-vous développer s’il vous plaît? Il est vrai que vous avez parlé de « mesurer ». Mais ce serait super utile de mieux mettre le lien » risque-mesure » en exergue.
Bonjour,
Vous avez raison … mais le titre de l’article est « … par ou commencer … ».
La suite est effectivement de faire une description plus en détails avec, par exemple, le langage et la méthodologie BPMN.
Mais aussi de procéder à une analyse des risques dont le traitement nécessitera des mesures (qui ne seront pas nécessairement celles déjà reprises dans le « turtle diagram ») et surtout des actions de traitement.
Néanmoins Merci pour votre réaction 😉
La norme ne parle pas d’emblée de risques, mais bien d’enjeux, ‘issues’ en anglais, dans l’analyse du contexte. Et c’est à propos. La révision de la norme avait pour objectif d’être applicable aux petites entités, comme par exemple un cabinet de notaire de quelques personnes. Pour les PME, une gestion des risques formalisée, avec registre de risques, appétance etc serait un frein à la certification (il y a une dimension économique), et qui plus est, il y a moyen d’assurer un service de qualité aux parties prenantes en se passant de cette formalisation dans bien des cas. La norme est basée sur les risques -risk-based- au sens où elle exige sans le dire explicitement que la partie identification soit formalisée dès l’analyse du contexte jusqu’à la politique denregistrement et de traitement des non conformités. Dans l’analyse du contexte interne intervient la considération des activités, et cela commence par la simple description des processus. L’article d’Eric porte donc sur une étape préalable à l’analyse des risques. Didactiquement, il vaut ieux lasser un lapse de temps et un peu de pratique entre la description du portefeuille des capacités -processus – activités et l’inventairedu portefeuille des risques et celui des assurances.