Merci Laleh pour le partage de ce visuel très clair et très synthétique qui permet de rappeler les fondamentaux !

Un bel article.

J'irai un peu plus loin. Le management par les processus est plus qu'une méthodologie, c'est une réelle manière de manager une organisation car il nécéssite une réelle décision de la DG, une évolution de l'organisation à travers la nomination de pilotes de processus, une gouvernance spécifique par la mise en place des diférentes instances de pilotage des processus, une manière de travailler entre les hiérarchiques et les pilotes de processus et une évolution de la culture de l'organisation qui doit être orientée client et emprunte de coopération.

Au final, manager par les processus conduit à lier l'exécution opérationelle (à travers les processus), à la stratégie.

Merci Michel pour ce complément. Plus que le lien entre l'exécution opérationnelle (à travers les processus), et la stratégie (qui peut également se faire avec des business units), je pense que l'enjeu majeur du management par les processus est en effet la coopération, avec un focus sur les interfaces, en alignement avec la vision stratégique. Cela permet d'être dans une vision transversale des besoins et exigences et de "rendre fluide" la chaîne de valeur. 

Le management par les processus se construit en analysant les flux qui, au travers de différentes activités,  conduisent à livrer au client externe les produits ou services attendus. Sa visualisation permet de comprendre comment la valeur ajoutée de l’entreprise se construit, via les entrées et sorties de chacune des étapes. Cette approche n’est donc transverse que par rapport aux métiers et non par rapport au flux dont il est le reflet. Et c’est bien là, dans ce nouveau regard que réside sont intérêt.

Cela donne une bonne vision de qui est client ou fournisseur interne de qui, et donc permet de remettre les choses à leur place dans les rapports entre entités métiers. Le bureau d’études n’est que le fournisseur de la fabrication....

Cette visualisation du flux est indispensable effectivement pour bien définir les périmètres des différentes autorités et rendre efficient l’organisme.

Merci Michel sur ce complément sur l'analyse des flux. En effet, cette démarche transverse ne l'est que par rapport aux métiers et non par rapport au flux. Mais le management transverse, à travers un pilotage fonctionnel, reste un ART difficile à maîtriser pour certaines organisations car cela peut bouleverser la structuration des "pouvoirs"!

Analyser l'existant est une option, qui fonctionne parce que les processus, qu'on les ait décrits ou pas, existent quoi qu'il arrive. Une autre option est de se donner la chance de réfléchir à ce qui devrait être, plutôt qu'à ce qui est. Et cette deuxième voie exige la participation de la DG, qui est la seule à avoir l'autorité pour modifier les limites à l'intérieur de l'organisation. Et je ne pense pas que "cela [puisse] bouleverser la structuration des "pouvoirs"" : je suis certain que cela doit bouleverser la structuration des pouvoirs.

Et surtout, l'approche processus rend (intellectuellement) possible l'analyse des interfaces entre les processus. Car c'est au niveau des interfaces (des interactions) que se situent les dysfonctionnements : le BE a "bien" conçu le produit (plus de 2 ans d'aller-retours avec le marketing, avec un grand niveau de confidentialité), mais personne ne l'avait averti que l'usine avait, depuis un an déjà, prévu de supprimer un silo de stockage pour agrandir l'entrepôt (indispensable, vu que la direction industrielle a prévu de rapatrier sur le site les fabrications autrefois sous-traitées. Résultat : lorsqu'il s'est agi d'organiser les essais industriels préalables au lancement, il a fallu en catastrophe revoir la formulation des anciens produits pour qu'on puisse continuer à les fabriquer avec une référence matière première de moins (eh oui, un silo de moins, c'est une matière première de moins). Chacun a "bien" travaillé, et pourtant !

Tout à fait d’accord, ce qui prime dans l'approche processus c'est la circulation des flux (informations, matières) réels ou souhaités, et leurs transformations. Le découpage en processus crée des relations fournisseur/client qui doivent d’une part contribuer aux besoins du client externe et répondre aux besoins du client direct. C’est bien une décision de la direction qui s’appuie sur la cohérence des activités regroupées et l'existence de sorties à la fois abouties et vérifiables car, in fine, il faudra bien que le client du processus évalue et accepte la sortie livrée.

La sortie du processus « concevoir le produit » doit donc être un design qui réponde à la fois aux besoins fonctionnels attendus et aux besoins de réalisation, tant physique qu’économique. Ce processus a certes besoin des compétences du BE, mais aussi de celles qui connaissent les fonctions attendues et de celles qui vont réaliser le produit. Ne pas inclure méthodes et fabrication comme participants à ce processus est effectivement une erreur qui se payera plus tard.

C'est pour cela qu'il est dangereux de nommer un processus par un métier « Bureau d’études », désignation ramenant à la compétence prédominante, et qu'il est recommandé de l'appeler avec un verbe d'action et un complément rappelant la finalité principale « concevoir le produit ».

L’approche processus met en avant les flux et interfaces entre des ensembles d’activités qui utilisent des compétences ; elle est complémentaire de l'approche métiers, généralement supportée par l'organigramme hiérarchique qui elle gère les compétences.

Merci @hubert et @Michel. La méthodologie pour diagnostiquer les processus est en effet une étape fondamentale pour avoir les acteurs multidisciplinaires concernés autour de la table et construire avec eux les flux et leurs intitulés en ne retombant pas sur l'organisation déjà en place! Très bonne idée d'intituler avec un verbe d'action et son complément un processus pour clarifier "le territoire transverse" qui est en train d'être "designé". Cette étape est un réel projet de transformation, impulsée par la Direction Générale.

Attention toutefois à plusieurs dérives possibles dans l'interprétation du management par les processus !

1) Assimiler l'approche processus à une vision systématiquement et totalement transverse de l'organisation de l'entreprise n'est généralement pas réaliste dans la vraie vie.

Exemple. Le processus que l'on appelle aujourd'hui SI (Systèmes d'Information) est transverse par nature car l'informatique est utilisée par tous les collaborateurs de l'entreprise. Cependant le processus repose presque toujours sur le "noyau dur" qu'est le "service informatique". Difficile de faire autrement… Pourtant notre équipe informatique doit être capable de dialoguer avec tous les utilisateurs (ce qui n'est hélas pas toujours le cas). L'approche processus est donc absolument nécessaire pour aller au-delà du "silo", au-delà des "frontières" de la seule équipe informatique. Cependant, celle-ci reste l'acteur "central". Ajoutons qu'en pratique le pilote de ce processus sera généralement le responsable SI.

Petite interrogation à ajouter : la précision donnée en début de schéma "la description d'activités de processus transverses permet de les automatiser (...)" est-elle toujours une réalité ? Sujet à débat...

2) Le management par les processus ne doit surtout pas être une notion trop "intellectualisée", trop "conceptualisée" car on perd vite tout le monde. Donc attention avec la "modélisation", "l'analyse de flux", "l'automatisation des workflows", les savantes cartographies…

Ces concepts sont à consommer avec très grande modération. Pourquoi ? Parce que le réel ne se laisse pas si facilement théoriser et que l'on aboutit vite à des "usines à gaz" qui ne contribuent pas souvent à améliorer la qualité de façon perceptible sur le terrain. Parce que c'est le meilleur moyen de passer pour un responsable qualité "hors sol" et de créer chez la majorité des collaborateurs une franche hostilité à l'encontre de la notion de système de management de la qualité. Profitons-en d'ailleurs pour dénoncer l'abus de terminologies souvent obscures et très "frangliches" telles que "workflow", "process owner", "business process model"…

Conclusion : le management par les processus est une approche particulièrement efficace à condition qu'elle parte du monde réel vécu par les collaborateurs, permettant d'enfin traiter des risques (problèmes) et des opportunités sans devoir être bloqué par des frontières imposées par l'organigramme fonctionnel. Ne serait-ce pas l'esprit de la norme ISO 9001 ? Et si nous revenions à ses fondamentaux ?

Bien d'accord avec Jean-Marc : un processus ne peut pas être transverse, car cela impliquerait que son pilote soit la direction générale : personne d'autre ne possède l'autorité sur tout le monde.

En revanche, l'ensemble des processus constitue une chaîne ininterrompue de couples "client/fournisseur", chaque processus (ou sous-processus) se retrouvant "dans la peau"  du fournisseur et du client. C'est cette chaîne qui donne une vision transversale de l'organisation.

Bien d'accord avec l'excès de modélisation, n'en déplaise aux vaillants rédacteurs du BPMCBOK. Seul bémol : comme c'est aux interfaces que se concentrent es dysfonctionnements, il faut bien en parler. Je suis preneur de tout vocable moins jargonnesque.

Merci Jean-Marc et Hubert. Sans être une stakhanoviste de la transversalité, ni dans l'excès de modélisation, lors de mes expériences, les deux valeurs ajoutées des démarches processus que j'ai vécues véritablement dans la mise en oeuvre restent dans cette vision transversale, non hiérarchique, et le travail de clarification des interfaces. Un des exemples simples et qui revient souvent se trouve dans les achats. Si chaque activité est en silo, personne ne peut, dans l'organisation, avoir une vue transverse de la demande jusqu'aux paiements des fournisseurs et prestataires. Autre exemple dans les produits qui utilisent les systèmes d'information dans leur conception, pour mieux coordonner la contribution des SI avec les concepteurs, les méthodes que l'on observe aujourd'hui sont les démarches produit avec les OKR vont dans le sens de cette transversalité et de la collaboration fonctionnelle. D'accord avec vous qu'il faut garder un équilibre et ne pas aller vers l'excès de modélisation cependant.

D'accord mais l'exemple donné des achats montre bien qu'il faut un "acteur central" qui aura une vue d'ensemble comme le service achat. Ceci sans fonctionner en "silo" c'est à dire en prenant réellement en compte la participation de tous les acteurs concernés (approche processus).

Cette notion d'acteur central est vitale car sinon les collaborateurs se perdent vite dans les méandres d'un fonctionnement peu lisible où tout est dilué. Ce que je constate hélas souvent dans des entreprises pourtant certifiées qui ont généré une énième couche de bureaucratisation démotivante.

Totalement d'accord avec vous Jean-Marc. Hélas, parfois dans les organisations et notamment parfois à la recherche d'une certification, cette mission de pilotage transverse n'est pas suffisamment étudiée, ni prise au sérieux. Le "pilotage" des processus est un élément stratégique pour ne pas retomber, comme vous le mentionnez, dans de la bureaucratisation.

Je ne partage pas l'idée qu'un processus ne peut être transverse. Il l'est par nature.

C'est d'ailleurs sa raison d'être car, si les processus qui vont du client au client (en tant que bénéficiaire de la prestation), n'englobent pas toutes les actions exécutées par des entités différentes, on continue de travailler en silos, chacun dans sa boîte.

On dit que ce serait la DG qui devrait être en charge de cette transversalité. Pour ma part ce n'est pas réaliste. Il convient en revanche de désigner des pilotes de processus, qui pour un domaine quelconque auront cette responsabilité transversale. Pour être très pratique, le pilote de processus doit être issu de l'entité qui est la plus intéressée pour faire évoluer les processus de ce domaine. Pour reprendre des propos précédents, les processus SI doivent être pilotés par une persoone de la DSI.

Un pilote de processus, pour prendre en compte les objectifs des diverses entités traversées par les processus dont il a la responsabilité, devra travailler avec un représentant de chacune d'elles.

Ceci n'est pas intellectuel, mais pratique et concret

@Michel :

Relisons ensemble l'ISO 9001. La clause 4.4.1 e stipule que "L’organisme doit déterminer les processus nécessaires au système de management de la qualité et leur application dans tout l’organisme et doit attribuer les responsabilités et autorités pour ces processus;".

La norme prévoit également, au 4.4.1 b : "L’organisme doit déterminer les processus nécessaires au système de management de la qualité et leur application dans tout l’organisme et doit déterminer la séquence et l’interaction de ces processus;"

Imaginons à présent un processus transversal, du genre "Mettre sur le marché des produits innovants". Ce processus fait intervenir :

• le marketing (qui écoute le client)
• la R&D (qui conçoit le produit)
• les achats (il y aura de nouvelles pièces ou de nouvelles matières)
• la qualité (il faudra contrôler ces nouveaux éléments)
• les méthodes (il va falloir aider la production)
• la production (on doit bien fabriquer)
• la logistique (si ça se trouve, le produit innovant va nécessiter des conditions de stockage ou de transport particulières)
• les commerciaux (qui vont vendre le produit)
• le contrôle de gestion (qui va suivre les coûts)
• les RH (qui vont gérer les embauches ou les formations associées)
• le SI (il y a de nouvelles données dans l'ERP)

Les questions sont donc, si l'on souhaite se conformer aux exigences de l'ISO 9001 :

1. qui a l'autorité sur le processus ?
2. avec quels autres processus celui-ci est-il interfacé ?

@Michel,

Vous dites "Je ne partage pas l'idée qu'un processus ne peut être transverse. Il l'est par nature".

En raisonnant "hors processus" pris au sens de la norme ISO 9001 cela devrait déjà être une réalité de fonctionnement au niveau de l'organigramme "traditionnel" basé sur les grandes "activités" de l'entreprise.

Reprenons l'exemple donné par Hubert. Une direction commerciale d'entreprise, même hors ISO 9001, devrait déjà travailler avec le marketing, la R&D, la qualité, les méthodes, etc.

Revenons-en à la logique fondamentale de l'approche processus, c’est-à-dire aux points suivants :

1) Le constat qui a prévalu à l'élaboration de la notion de processus était le suivant : certains risques et opportunités n'étaient en réalité pas traités ou insuffisamment abordés en raison de "frontières" trop rigides attribuées à chaque service ou département.

2) L'approche processus vise à donner un droit de suite plus "officiel", légitimé par la démarche qualité, aux animateurs des processus. Ce qui les autorise à intervenir dans un cadre élargi afin de ne pas laisser de "trous dans la raquette".

De la transversalité, oui mais sans forcément remettre en question toute l'organisation de l'entreprise qui repose déjà, généralement, sur une forme de rationalité tout à fait défendable.

Le risque qui doit absolument être évité est la complexification qui rend illisible le fonctionnement de l'entreprise aux yeux de ses collaborateurs. Je me fais l'écho de toutes ces personnes que j'ai rencontrées lors de mes missions et dont les propos sont les suivants : "Avec le projet qualité on nous avait dit qu'on allait casser les silos, tout décloisonner, travailler par processus, apprendre à fonctionner en mode matriciel. Nous, on n'y comprend toujours pas grand-chose mais bonjour les dégâts ! On ne sait plus vraiment qui sont nos vrais responsables ni quelles sont nos vraies priorités. C'est confus et on passe maintenant notre vie en réunions où il ne se passe pas grand chose de concret."

Il convient donc d'éviter de surinterpréter les exigences de la norme ISO 9001 en risquant de développer un fonctionnement "bis" totalement transverse et parallèle aux activités déjà présentes par services ou directions dans l'organigramme "traditionnel". La norme n'exige nullement cela. Voir notamment : ISO 9001 (4.4 Système de management de la qualité et ses processus) et ISO 9000 (3.4 Termes relatifs au processus).

L'exemple que j'ai pris vient d'une entreprise réelle. Le pilote de ce processus était le directeur commercial; qui se désolait de ne pas avoir autorité sur les autres acteurs, et qui avouait qu'il continuait à travailler comme avant : il s'occupait des commerciaux, et laissait les autres se réunir autant qu'ils en avaient besoin, pour se coordonner. Le DG haussait les épaules et le responsable qualité disait "oui, peut-être, mais au moins c'est un vrai processus transversal !"

L'approche processus était donc un trompe-l'œil, un déguisement, un système en carton-pâte, un village Potemkine, tout ce que vous voudrez, sauf un système de management en bonne et due forme.

Et c'est désolant.

Quelques commentaires au regard des diverses réactions.

C'est bien de prendre la norme ISO 9001 comme référence pour l'approche processus, mais le fascicule de documentation FDX 50 176, qui la rend opérationnelle, montre que l'approche processus n'a pas que la qualité comme finalité, mais répond aux différents enjeux stratégiques d'une organisation comme la maitrise des risques, le RSE, la productivité, le développment commercial, ....

Connaître ses processus, c'est connaître son fonctionnement pour agir là où c'est le plus pertinent.

Pour répondre au commentaire d'Hubert, ce serait, au sein de la direction commerciale qu'il conviendrait de nommer le pilote de processus. Mais ce dernier ne peut avoir autorité sur les autres fonctions que si la DG, engagée dans une approche processus, le valide au sein de l'organisation.

Manager par les processus n'est pas une fin en soit, mais un moyen pertinent de nos jours. C'est une décision de niveau DG.

Pour les aider dans cette réflexion, France Processus que j'anime à écrit un Manifesto sur l'Approche Processus Renouvelée que chacun pourra retrouver sur notre site www.franceprocessus.org

A votre écoute

Extrait de ce "manifesto" : L'dentification des processus ressort du cadre d’action. Elle est en résonance avec le principe de transversalité qui implique, sous la conduite d’un porteur de l’intérêt commun dûment mandaté, la contribution de l’ensemble des acteurs concernés à la définition de l’objectif partagé.

Je crois que nous sommes d'accord : les processus sont "en résonnance" avec le principe de transversalité. Et il faut les définir à un niveau compatible avec les limites d'action du "mandat". Un processus totalement transversal ne peut pas fonctionner si le pilote n'a pas reçu un mandat explicite pour piloter, c'est à dire pour prendre des décisions opérationnelles.

Dans mon exemple, j'ai peur que le directeur commercial ne soit impuissant à réagir si le responsable de production refuse de mener les essais industriels au motif que les essais en question ont un impact négatif sur son compte de résultat (la R&D va mobiliser les ressources de l'usine, sans pour autant produire quoi que ce soit de commercialisable). Ou si les méthodes décident que ce projet n'est pas prioritaire de leur côté. Ou si les achats décident qu'on ne pourra pas étendre le panel de fournisseur et qu'il faudra acheter chez un des fournisseurs actuels, alors que la R&D milite pour un nouveau fournisseur, etc.

C'est pour cela qu'il existe des instances comme les Comités de Pilotage, où ces blocages sont arbitrés. Ce sont des pilotes de processus "métier" qui échangent pour trouver une solution qui permette d'atteindre l'objectif stratégique, quitte à tordre de manière temporaire telle ou telle règle (d'affectation des couts par exemple).

Laissons de côté le terme transverse qui suscite plus de questions et controverses qu'il n'apporte de clarté. En fait, il y a deux approches, deux visions différentes :

• une approche métiers qui est une logique de compétences pour effectuer une activité,
• une approche processus qui est une logique de flux, de circulation et transformation des infos et objets ; une vision style SIPOC du "Lean".

À quoi conduisent-elles ?

• Imaginer un organisme uniquement piloter suivant les métiers, si compétences et outils associés seront probablement bien optimisés, vous l'avez tous dit, cela va créer des silos et coincer aux niveaux des interfaces et de l'optimisation globale. Pas très efficient.
• Imaginez maintenant un organisme uniquement piloter par les processus, c'est à dire où chaque produit ou prestation de service est piloté par une ligne de produit dédiée indépendante des autres, même si produits/services sont parfois poches. Qu'obtenez-vous ? un flux optimisé pour chaque produit avec d'énormes redondances et particularités au niveau des moyens et des compétences des personnes exerçant le même type d'activité. Pas très efficient non plus.

Que choisir ?
Ces deux façons de regarder sont, l'une que l'autre, aussi pertinentes qu’incomplètes. Pour être efficient, pour obtenir un équilibre dans les améliorations, il faut regarder selon ces deux axes : métier et flux et surtout ne pas les opposer, ils sont complémentaires.

Après votre organisation hiérarchique, celle qui gère les collaborateurs, peut suivre l'une ou l'autre des logiques, de toute façon il lui faudra un contre poids pour l'équilibrer.

Comment faire pour convaincre. S'il est vrai que la vision organisation métier est souvent plus connue car vécue, la vision processus devient simple si on explique :

• que l’on est tous à la fois client interne et fournisseur interne, soit la notion de SIPOC (fournisseur, entrées, processus, sortie, client) ;
• que, pour optimiser le fonctionnement, il ne suffit pas d'optimiser la façon de faire l'activité, il faut aussi optimiser cette chaine SIPOC (capacité des fournisseurs, correspondance des entrées et des sorties aux attentes des clients internes) ;
• et qu’ enfin, pour pas qu'une amélioration locale ne crée ailleurs des dysfonctionnements plus importants, il faudra aussi faire une analyse d'ensemble (systémique).

Pour éviter les confusions chez les collaborateurs, il convient aussi de bien dissocier les deux visions donc de ne pas nommer un processus par un métier ou une fonction, mais par une activité : verbe à l'infinitif "concevoir le produit" plutôt que « Bureau d'études », « mettre à disposition des systèmes d'information » plutôt que « Systèmes d'information » même si la compétence principale, outre l'écoute de ses clients et fournisseurs, reste bien sûr centrée sur le métier principal, bureau d’études ou services informatiques.

Quel socle théorique à cette double approche? Il est contenu dans la phrase de Jean-Louis Le Moigne "Pour résoudre un problème complexe, au lieu de chercher à le simplifier ou de chercher des solutions compliquées, commencer par complexifier votre regard et votre représentation du problème". Piloter un organisme, dès qu'il atteint une certaine taille, est un problème complexe et donc ni la vision unique tronquant la réalité ni les solutions usine à gaz ne marchent, croiser les points de vue permet de parvenir à un équilibre efficient.

@Michel. Même si ces idées sont intéressantes, je pense que là on risque de perdre tout le monde, à commencer par les collaborateurs. Et c'est hélas ce qui se passe dans nombre d'entreprises et d'organismes où l'ISO 9001 devient injustement un "repoussoir". A titre perso, j'avoue ne pas être un adepte de la formule "commencer par complexifier son regard". Je préfère la formule de Boileau "Ce qui se conçoit bien s'énonce clairement et les mots pour le dire arrivent aisément".

Pourquoi ne pas expliquer beaucoup plus simplement la notion de processus ?

Dans la réalité le découpage par processus s'appuie, la plupart du temps, sur les noyaux durs que sont les "services" de l'entreprise (organigramme). Cependant, pour agir efficacement en termes d'amélioration de la qualité il est nécessaire de pouvoir travailler sur un ensemble complet et cohérent d'activités (dont des flux), souvent au delà des frontières de chaque "service" avec des aspects parfois transversaux. L'approche processus offre justement cette vision élargie, plus efficiente.

D'accord avec Jean-Marc :

1) complexifier le regard n'est pas ce que je ferais spontanément.

2) l'approche processus consiste (pour moi) à identifier et à maîtriser les interfaces entre des pôles d'activités, et mettant en évidence la continuité des liens client-fournisseur. 

On obtient alors une vision transversale (ou continue, mais transversale me va bien) de l'organisation, et une facilité à aligner les objectifs (d'accord avec Michel : "concevoir des produits" est préférable à "bureau d'études").

Rassurez-vous Jean-Marc, ce que j'exposais concernait la construction de la cartographie (l’enchainement) des processus ;  ce n’était pas présenté pour être livré tel quel à tous les acteurs.
La formation des acteurs à l'utilisation des processus, c'est autre chose. Mais attention de ne pas les sous-estimer, aux risques de créer du désengagement, un rejet de la fonction qualité et de la culture associée. 
J’ai formé beaucoup d’acteurs au concept de processus et ça marche en prenant en exemple leurs propres activités et en exposant la finalité. Pas de problème avec entrées, fournisseurs, sorties, clients, ensembles d'activités et, associés à ces dernières, compétences pluridisciplinaires, méthodes et moyens. Pour les perdre, un moyen très simple, utiliser sans différentiation de sens processus et services ou les appeler par le même nom.

Je base la construction des cartographies sur les flux de l’organisme, alors dire que « le découpage par processus s'appuie, la plupart du temps, sur les noyaux durs que sont les services de l'entreprise (organigramme) » me parait une inversion. La vision flux amène à des enchainements d'activités et le découpage en processus est réalisé là où les sorties/entrées sont stables et vérifiables, donc transférables d'une autorité à une autre. Certes, l'analyse ultérieures des compétences nécessaires montre souvent une prédominance de certaines compétences mais c'est un constat, pas une construction sur laquelle on s’appuie, c’est ce qui différencie les deux approches .
Bien sûr ces dernières lignes sont à l'usage des qualiticiens et non à celui des acteurs.

Quant à la citation de Le Moigne, elle ne contredit pas celle de Boileau à laquelle on pourrait rajouter « un beau dessin vos mieux qu’un long discours » donc complexifier son regard c'est :

/

Merci pour vos échanges et réactions. Nous voyons bien que l'approche processus n'est pas uniquement un sujet de conformité à la norme ISO 9001 mais avant tout une décision stratégique de la direction générale pour avoir une représentation des flux "à valeur ajoutée" de son organisme. La nomination des pilotes, propriétaires ou comité de pilotage de chaque processus reste également une décision stratégique. Malheureusement, cela n'est pas suffisamment "pris au sérieux" parfois. En effet, comme je le vois dans vos commentaires, si le pilote ou le comité de pilotage n'a pas de légitimité transversale avec un mandat clair et des dispositifs de pilotage (instances, outils, modes de reporting, ...) réfléchis et validés par la direction générale, la démarche ne fonctionnera pas. Cela pose également la place ou la légitimité de la fonction qualité au sein d'un organisme. Si cette fonction n'a pas une autorité légitimée par la direction, si elle n'a pas suffisamment de vue de hauteur et de méthodologie pour coordonner ce type de projet pour "dessiner" les flux AVEC les acteurs concernés, nous allons retomber dans les dérives d'un système qui va chercher à se conformer en créant cette fois des processus à la place des procédures des anciennes version d'ISO 9001 et qui n'auront aucun sens ni pour l'organisme ni pour les acteurs. La démarche processus est donc avant tout une volonté stratégique d'une direction générale pour piloter autrement!

@Michel,

Mais pourquoi sans cesse vouloir opposer "activités" et "flux" ? En pratique, en entreprise, toute activité intègre les flux s’y rapportant. Exemples : les achats, la production, etc. Donc il s’agit généralement d’un faux débat.

En quoi définir des processus en s’appuyant sur les grandes activités de l’entreprise serait une "inversion" ? L’approche processus permet justement de sortir du seul périmètre trop limitatif des services... Franchement, à quel moment la norme interdirait-elle ou déconseillerait-t-elle de s’appuyer d’abord sur les réalités de fonctionnement de l’entreprise ? Ce n’est tout de même pas "par hasard" que chaque entreprise ou organisme a développé un organigramme plus ou moins basé sur ses activités réelles…  

Or, en entreprise et surtout en qualité, on cherche avant tout le pragmatisme. Ce, dans un contexte où le bien le plus précieux de tous est le temps (sous-effectifs chroniques).

Là, entre nos deux visions, il s’agit d’un débat sans fin mais en observant le terrain la plupart des entreprises ont tranché. De fait, la grande majorité des entreprises appuient leur découpage en processus sur tel ou tel service "noyau dur". Feraient-t-elles toutes fausse route ? Personnellement je ne le crois pas.