Voici la confusion que je rencontre sans cesse dans les tickets de support et les appels d’onboarding : quelqu’un dit vouloir mettre en place une gestion des processus métier (BPM), alors qu’il veut en réalité acheter un outil. Ou il vient de terminer un projet de documentation des processus et pense que le BPM est terminé. Ou il a automatisé quelques workflows et appelle désormais cela du BPM parce que cela semble plus stratégique.
Aucune de ces choses n’est véritablement erronée. Mais aucune n’est non plus du BPM.
Le BPM est une discipline. Il suit un cycle de vie. Il fonctionne en continu. L’outil n’est qu’une partie d’une étape. La documentation n’est qu’un livrable. L’automatisation n’est qu’une méthode d’exécution. Aucun de ces éléments, pris isolément, ne constitue le BPM.
Cette distinction compte énormément en pratique. Les équipes qui confondent le BPM avec un projet logiciel se retrouvent généralement avec un système que personne ne maintient, des tableaux de bord auxquels personne ne fait confiance et un processus « amélioré » à deux reprises, mais qui échoue toujours de la même manière chaque trimestre. Les équipes qui le traitent comme une discipline obtiennent des bénéfices cumulatifs : chaque cycle rend le suivant moins coûteux et plus rapide.
Cet article explique ce qu’est réellement le BPM, à quoi ressemble son cycle de vie en pratique, où il s’applique et où il ne s’applique pas, ainsi que les moyens de déterminer si une mise en œuvre est durable.
Ce que les équipes découvrent généralement six mois trop tard
- Le BPM est une discipline, pas un outil ni un projet ponctuel
- Il cible des processus répétables de bout en bout, et non chaque tâche
- Le cycle de vie est circulaire : l’optimisation revient vers la conception
- L’automatisation est une méthode d’exécution au sein du BPM, pas un synonyme
- Sans responsabilités définies et sans KPI, rien ne s’améliore de manière mesurable
Ce que signifie réellement la gestion des processus métier (BPM)
Le BPM est une méthodologie de gestion destinée à découvrir, modéliser, analyser, mesurer, améliorer et optimiser les processus métier. Il ne concerne pas un seul processus. Ce n’est pas un examen ponctuel. C’est la discipline continue qui consiste à gérer la manière dont le travail circule dans une organisation, de bout en bout, avec une gouvernance et des mesures associées.
Le BPM Institute le présente comme une discipline couvrant les personnes, les processus et la technologie, qui exige non seulement des outils, mais aussi une culture, des structures de responsabilité et des métriques définies. Le cadrage de type Gartner, tel que synthétisé par Generis, le décrit de façon similaire : une approche systématique visant à améliorer les workflows d’une organisation afin qu’elle puisse s’adapter à l’évolution des conditions du marché.
Deux éléments de ces définitions méritent d’être retenus. Premièrement, il s’agit d’une démarche systématique, et non ad hoc. Deuxièmement, il est question d’adaptation, ce qui implique un cycle continu plutôt qu’un état finalisé.
Une gestion efficace des processus métier s’applique spécifiquement aux activités opérationnelles répétitives, continues et prévisibles. Toutes les tâches métier ne sont pas concernées. Un projet ponctuel ne bénéficie pas d’un cycle BPM. En revanche, un processus récurrent de bon de commande, un flux d’onboarding des employés ou un parcours d’escalade du support client en bénéficient. C’est la répétition qui rend la discipline précieuse : vous pouvez mesurer le même processus dans le temps, comparer les cycles et savoir réellement s’il s’est amélioré.
Le BPM n’est pas une méthodologie de gestion de projet. Il ne s’arrête pas au lancement. La discipline inclut ce qui se produit après la mise en production du processus : le suivi des performances, la détection des dérives, l’identification des goulots d’étranglement et le retour vers une nouvelle conception.
C’est sur ce dernier point que la plupart des mises en œuvre BPM échouent discrètement. Le lancement a lieu. Le tableau de bord est mis en place. L’équipe passe à autre chose. Et le processus qu’elle a « amélioré » commence à se dégrader en quelques mois, sans que personne ne soit chargé de le remarquer.
Les 3 types de gestion des processus métier
Tous les processus ne se dégradent pas de la même façon, ce qui signifie que toutes les approches BPM ne se ressemblent pas. Les trois types reconnus correspondent à ce qui fait réellement avancer le processus : les systèmes, les personnes ou les documents. Savoir à quel type vous avez affaire change la manière de le modéliser, ce qui le fragilise et ce que le suivi vous révèle réellement.
La plupart des processus réels combinent des éléments des trois types. Mais le type dominant détermine l’emplacement des modes de défaillance.
BPM centré sur l’intégration
Le BPM centré sur l’intégration gère les processus qui s’exécutent principalement par des transferts de système à système, avec une intervention humaine minimale pendant l’exécution. Les règles métier déterminent le routage : si un enregistrement répond à la condition A, il est envoyé vers le système B. Les personnes qui l’ont conçu ne se trouvent plus sur le chemin critique une fois le processus en production.
Ce type est rapide et cohérent lorsqu’il fonctionne. Ses modes de défaillance sont techniques : jetons d’authentification expirés, modifications de schéma dans l’un des systèmes connectés, limites de débit que personne n’avait anticipées à grande échelle. Lorsqu’ils surviennent, ces problèmes échouent souvent silencieusement. Le tableau de bord indique que les exécutions se déroulent. Le système en aval ne contient pas les enregistrements. Et l’équipe ne l’apprend que deux semaines plus tard, lorsqu’une personne demande où sont passées les données.
BPM centré sur les personnes
Le BPM centré sur les personnes couvre les processus dans lesquels l’approbation, le jugement ou la coordination maintiennent les personnes sur le chemin critique. Un workflow d’approbation des dépenses, un cycle de révision de contenu, une séquence de validation de contrat : tous dépendent de personnes qui prennent des décisions à des étapes précises. Les utilisateurs métier constituent le mécanisme, et pas seulement les destinataires finaux.
Ce type échoue différemment. Il s’agit rarement d’une défaillance technique. C’est une personne absente, une étape d’approbation ignorée « juste cette fois-ci », puis devenue une pratique standard, ou un transfert qui existe dans le modèle mais pas dans l’agenda de qui que ce soit. Le BPM centré sur les personnes nécessite des responsabilités claires et des SLA à chaque étape. Sans cela, le modèle de processus documente ce qui devrait se produire, tandis que le travail réel le contourne.
BPM centré sur les documents
Le BPM centré sur les documents organise le travail autour d’un document qui passe par des étapes de révision, d’approbation et de conformité. Il est courant dans les services juridiques, la finance, la fabrication réglementée et la santé, partout où le document lui-même est l’unité de travail et où son état — brouillon, approuvé, publié, archivé — a une signification juridique ou opérationnelle.
La gestion des risques en est le moteur principal. Le processus existe pour créer une preuve vérifiable que les bonnes personnes ont examiné la bonne version au bon moment. Lorsque ce type de BPM est mal mis en œuvre, les documents circulent, mais la piste est incomplète. L’approbation a eu lieu dans l’e-mail de quelqu’un. La version envoyée en production n’est pas celle qui a été révisée. Les organisations soumises à de fortes exigences de conformité découvrent cela lors des audits, ce qui n’est pas le moment idéal pour l’apprendre.
Le cycle de vie du BPM : la responsabilité réelle de chaque étape
Le cycle de vie du BPM est le mécanisme qui fait du BPM une discipline plutôt qu’un projet. Cinq étapes. Elles s’exécutent dans l’ordre. Puis elles recommencent. L’optimisation à la fin réalimente la conception au début, et le cycle se répète tant que le processus existe.
Cette circularité constitue l’affirmation mécanique centrale du BPM. C’est aussi la partie que la plupart des mises en œuvre gèrent mal. Les équipes traitent le cycle de vie comme une séquence ponctuelle : elles le conçoivent, le modélisent, le déploient et considèrent le travail comme terminé. L’étape de suivi est ignorée ou confiée à un tableau de bord que personne ne consulte. L’optimisation n’a jamais lieu, car aucune boucle formelle ne ramène vers la conception. Elles se retrouvent alors avec un processus documenté qui s’éloigne progressivement de la réalité, alors que tout le monde suppose qu’il fonctionne toujours comme prévu.
Conception et découverte des processus
Avant toute modélisation, quelqu’un doit déterminer quels processus existent réellement. La conception et la découverte des processus constituent l’étape pendant laquelle vous identifiez les workflows en cours, leurs responsables, ce qu’ils sont censés faire et ce qu’ils font réellement. La cartographie des processus révèle souvent à ce stade que la version officielle et la version réelle sont deux documents différents.
C’est en sautant cette étape que la plupart des mises en œuvre BPM stagnent. Les équipes passent directement à la modélisation de leur version préférée du processus, ce qui signifie qu’elles optimisent une fiction. L’analyse des processus pendant la découverte met en évidence les goulots d’étranglement, les lacunes de transfert et les contournements non documentés que le diagramme officiel du processus n’a jamais mentionnés. Vous ne pouvez pas améliorer un processus que vous n’avez pas décrit avec précision.
Modélisation des processus
La modélisation consiste à définir de manière structurée, généralement visuelle, l’état actuel et l’état cible. Un bon modèle de processus montre non seulement le flux, mais aussi les points de décision, les acteurs à chaque étape, les exceptions et les indicateurs clés de performance que vous utiliserez pour mesurer si la version améliorée est réellement meilleure.
Le BPM Institute indique clairement que la modélisation comprend la définition des métriques et des KPI en même temps que la structure du processus. Ce n’est pas une étape distincte. Si vous modélisez le flux sans définir ce que signifie « mieux », vous avez un diagramme, pas un modèle de processus métier. Sans critères de mesure, la modélisation des processus métier n’est que de la documentation. Avec ces critères, elle devient la base d’un véritable cycle d’amélioration.
Exécution et mise en œuvre
L’exécution est l’étape où le processus modélisé est déployé : via un logiciel, une politique, des outils de workflow ou une combinaison de ces éléments. C’est l’étape qui tend à absorber le plus d’attention, le plus de budget et le plus de temps. C’est aussi celle où les équipes confondent le plus souvent la mise en œuvre du BPM avec la fin du BPM.
Ce n’est pas le cas. L’exécution est la troisième étape sur cinq d’un cycle circulaire. Les outils BPM choisis ici doivent prendre en charge les étapes de suivi et d’optimisation qui suivent, et pas seulement le déploiement lui-même. Un processus exécuté mais jamais suivi est un projet ponctuel portant une étiquette BPM. Le processus de mise en œuvre compte. Ce qui vient ensuite compte également.
C’est également à ce stade que Latenode apparaît souvent dans les projets que j’observe. Les équipes l’utilisent pour relier le processus modélisé aux systèmes qui le font fonctionner, en transformant les reconceptions de workflow en automatisations exécutables sans avoir besoin d’une couche d’intégration distincte pour chaque transfert. Le RAG intégré, le nœud JavaScript et plus de 5 500 intégrations permettent même d’orienter vers des flux utilisables une documentation de processus comportant des entrées non structurées — PDF, notes dispersées, fichiers SOP hérités. Une condition préalable demeure : la chaîne d’approbation et la responsabilité du processus doivent être définies avant de créer le workflow. L’outil ne prendra pas ces décisions à votre place.
Suivi et mesure
Le suivi est ce qui transforme le BPM d’un événement de lancement en une discipline continue. Une fois qu’un processus s’exécute, vous avez besoin d’une visibilité continue sur ses performances : temps de cycle, taux d’erreur, taux d’achèvement des étapes, retards de transfert et fréquence des exceptions. Ce sont les signaux qui vous indiquent si le processus se comporte comme il a été conçu.
L’intelligence des processus n’est pas facultative à ce stade. L’étude BPM 2025 du BOC Group a révélé que 21 % des organisations ne collectent que des données brutes, 14 % s’appuient sur l’analytique descriptive et seulement 11 % utilisent des approches de diagnostic telles que le process mining. Cela signifie qu’environ 85 % des organisations fonctionnent avec une intelligence des processus limitée ou inexistante. Elles savent que quelque chose est lent. Elles ne savent pas précisément où. Elles n’ont aucune méthode structurée pour le découvrir.
Le temps de cycle est la mesure de départ. Il vous indique combien de temps prend réellement un parcours de bout en bout dans le processus. Tout le reste — les ralentissements, les défaillances, les réorientations — repose sur cette référence.
Optimisation des processus
L’optimisation est l’étape qui boucle le cycle. Les données de suivi révèlent ce qui ne fonctionne pas suffisamment bien. L’optimisation des processus utilise ces données pour identifier des améliorations précises : repenser une étape, redistribuer les responsabilités, modifier un seuil, ajouter un nœud d’automatisation. Puis le cycle recommence avec une conception révisée.
Il ne s’agit pas d’une phase de nettoyage. Il s’agit d’améliorer les processus métier sur la base de preuves plutôt que d’hypothèses. Les équipes qui obtiennent le plus de valeur cumulative du BPM sont celles qui considèrent la boucle entre optimisation et conception comme un travail trimestriel normal, et non comme une initiative exceptionnelle. Le cycle devient plus rapide, car chaque passage s’appuie sur des données d’exécution réelles plutôt que sur des conditions estimées. C’est le mécanisme. C’est ce qui rend la discipline digne d’être maintenue.
Où le BPM s’intègre dans une organisation réelle — et où il ne s’intègre pas
Le BPM cible l’ensemble du réseau de workflows, et non des corrections départementales isolées. Cette portée est intentionnelle. Un processus qui couvre les ventes, le juridique et la finance ne peut pas être amélioré en optimisant uniquement la partie ventes. Les transferts sont là où le travail se bloque, et ils restent invisibles lorsque vous ne regardez que votre propre étape.
En pratique, le BPM est particulièrement utile pour quatre types d’équipes travaillant sur quatre types de problèmes :
Les équipes opérationnelles qui réduisent les retards et les erreurs. Si un processus récurrent est systématiquement en retard, génère des reprises ou crée un volume de demandes de support, le BPM lui apporte un cycle d’amélioration structuré avec des critères de mesure. C’est le point d’entrée le plus courant.
Les équipes d’amélioration et de standardisation des processus. Les organisations qui se développent sur plusieurs bureaux, régions ou gammes de produits ont besoin de standardiser leurs processus avant que les variations ne deviennent ingérables. Le BPM fournit pour cela la structure de modélisation et de gouvernance.
Les équipes IT et d’automatisation qui relient la refonte aux systèmes. Une refonte de processus qui n’est jamais intégrée aux outils n’est qu’un exercice sur tableau blanc. Les équipes IT et les analystes métier qui appliquent le BPM font le lien entre la manière dont le travail devrait circuler et la manière dont les systèmes l’exécutent réellement. Latenode intervient ici comme couche d’exécution : une équipe opérationnelle d’une entreprise de taille moyenne peut, par exemple, prendre un processus repensé d’onboarding des fournisseurs et le transformer en workflow qui achemine les approbations, vérifie les champs obligatoires, notifie les parties prenantes et journalise chaque étape, sans mobiliser une ressource d’ingénierie dédiée au projet. Une amélioration des processus métier appliquée via des outils plutôt que par la seule documentation.
Les organisations soumises à de fortes exigences de conformité qui améliorent la traçabilité. La conformité reste un important facteur de valeur pour la documentation des processus, citée par 57 % des organisations dans l’étude BPM 2025 du BOC Group. Lorsqu’un processus nécessite une piste vérifiable, la structure de gouvernance du BPM constitue le mécanisme pratique pour la créer.
Mais le BPM présente des limites importantes. Il s’applique aux activités répétitives, continues et prévisibles. Un processus précis qui s’exécute selon un cycle défini, avec des entrées et sorties cohérentes, constitue un bon candidat au BPM. Un projet ponctuel, un processus de travail créatif ou une tâche contextuelle qui change de forme à chaque fois n’en est pas un. Appliquer la charge organisationnelle du BPM à des processus qui ne se répètent pas produit de la documentation et du travail de gouvernance sans bénéfice cumulatif. Les résultats métier générés par le BPM ne se matérialisent que lorsque le processus s’exécute assez souvent pour permettre de mesurer l’amélioration d’un cycle à l’autre.
Le BPM ne s’applique pas non plus automatiquement à chaque objectif métier. Commencer par le mauvais processus — trop complexe sur le plan politique, trop variable ou trop lié à une réorganisation imminente — est l’une des façons les plus fiables de bloquer une initiative avant qu’elle ne produise quoi que ce soit de mesurable.
Les bénéfices de la gestion des processus métier qui méritent d’être mesurés
Les affirmations génériques selon lesquelles le BPM améliore l’efficacité ne sont pas fausses. Elles sont simplement inutiles sans les conditions opérationnelles qui les rendent réelles. Chaque bénéfice ci-dessous exige un élément précis. Lorsque cette condition manque, le bénéfice ne se matérialise pas ou ne peut pas être vérifié.
Réduction des retards et des erreurs de traitement
Le BPM réduit les retards lorsque la phase de découverte a correctement cartographié les zones où le processus ralentit réellement, et non celles où le modèle indique qu’il devrait ralentir. Si la refonte repose sur le flux officiel plutôt que sur des données d’exécution observées, les retards se déplacent au lieu de disparaître.
Travail standardisé entre les équipes et les sites
Un BPM efficace crée de la cohérence dans la manière dont le travail est réalisé par différentes personnes et dans différents contextes. Ce bénéfice est réel lorsque le processus standardisé est effectivement suivi, ce qui exige une documentation accessible et une responsabilisation claire. Si la norme n’existe que dans un outil de modélisation que les équipes de terrain n’ouvrent jamais, vous avez un document standardisé, pas un processus standardisé.
Performances mesurables par rapport à des KPI définis
Le BPM crée l’infrastructure nécessaire pour savoir si un processus fonctionne bien. Cela ne fonctionne que lorsque les KPI sont définis lors de la phase de modélisation, avant le début de l’exécution. Les programmes de processus métier qui définissent leurs métriques après le déploiement ont tendance à mesurer ce qui est facile à compter plutôt que ce qui compte réellement.
Traçabilité et responsabilisation améliorées
Chaque étape a un responsable, chaque décision possède un enregistrement, chaque exception est journalisée. Dans les contextes soumis à de fortes contraintes de conformité, c’est la valeur principale. La condition : les responsables de processus doivent être désignés et vérifiables dès la phase de conception. Une traçabilité construite a posteriori couvre certaines lacunes, mais pas celles qui apparaissent lors des audits.
Réduction du coût par cycle de processus au fil du temps
C’est là que la réussite du BPM produit des effets cumulatifs. Chaque cycle d’optimisation réduit les frictions, ce qui diminue le coût par exécution. La condition est le cycle de vie circulaire : sans la boucle qui va du suivi à l’optimisation puis revient à la conception, les coûts plafonnent après l’amélioration initiale au lieu de continuer à baisser.
Agilité métier améliorée lorsque les processus changent
Un processus modélisé, documenté et suivi est plus rapide à repenser qu’un processus non documenté. L’organisation sait ce qui existe, qui en est responsable et quelle est la référence de performance actuelle. Lorsque les conditions changent, la refonte démarre à partir d’une carte réelle plutôt que de la mémoire institutionnelle. Ce bénéfice exige que le modèle de processus reste à jour. Des modèles reflétant l’état d’il y a 18 mois produisent des cycles de refonte plus lents, et non plus rapides.
🤔 Attendez.
Aucun de ces bénéfices ne se matérialise si les responsables de processus et les critères de mesure ne sont pas définis au début de l’exécution. Un BPM sans gouvernance n’est que de la documentation. L’étude BPM 2025 a révélé qu’environ 15 % seulement des organisations ont atteint une maturité BPM avancée — et l’écart entre une documentation de base et un BPM opérationnel dépend généralement du fait que les responsabilités et les KPI ont été définis avant le déploiement, et non après.
BPM vs automatisation des processus métier : pourquoi la confusion revient sans cesse dans le support
L’automatisation des processus métier est si souvent traitée comme un synonyme de BPM que je ne suis plus surpris lorsqu’une personne emploie les deux termes dans la même phrase pour désigner la même chose. Ils ne désignent pas la même chose.
Le BPM est la discipline. L’automatisation des processus métier est une méthode d’exécution au sein de cette discipline. Vous pouvez mettre en œuvre le BPM sans aucune automatisation, en utilisant une documentation des politiques, de la formation et des structures de responsabilité des processus. Vous pouvez faire fonctionner des automatisations sans BPM, et de nombreuses équipes le font, ce qui explique la plupart des histoires de type « nous avons automatisé la mauvaise chose ». Lorsqu’une automatisation fonctionne sans la couche de gouvernance apportée par le BPM, elle fait évoluer des processus défaillants, et non de bons processus.
L’automatisation robotisée des processus (RPA) crée davantage de confusion dans ce domaine. La RPA automatise des séquences de tâches précises, souvent au niveau de l’interface utilisateur, sans repenser le processus sous-jacent. Il s’agit d’une catégorie d’outils. Le BPM est la discipline de gestion qui vous indiquerait si l’automatisation de cette séquence de tâches résout réellement le bon problème.
La gestion de projet constitue un autre point de confusion. La gestion de projet traite un travail unique et limité dans le temps, avec des états de début et de fin définis : créer un produit, mener une campagne, migrer un système. Le BPM gère des processus opérationnels répétables qui existent indéfiniment. Un déploiement logiciel est un projet. Le pipeline de déploiement qui gère tous les futurs déploiements via un processus cohérent est un candidat au BPM.
Les outils de process mining complètent le tableau, mais ne remplacent pas la discipline. Ils font émerger les données d’exécution et révèlent comment les processus fonctionnent réellement par rapport à leur modélisation. C’est une entrée précieuse pour les étapes de suivi et d’optimisation du cycle de vie BPM. Mais les outils de process mining ne gouvernent pas le processus, ne prennent pas en charge les étapes et ne définissent pas les métriques. La discipline le fait. L’outil produit des rapports à ce sujet.
Salesforce présente le BPM comme couvrant l’ensemble du réseau de workflows — et non des automatisations individuelles ou des outils départementaux isolés, mais le système connecté de processus qui fait circuler le travail dans une organisation. Cette portée explique pourquoi la définition est importante. Une équipe qui pense que le BPM signifie « nous avons automatisé certaines choses » l’appliquera de manière limitée et passera à côté des problèmes systémiques qui n’apparaissent que lorsqu’on observe l’ensemble du réseau.
Ce qu’un système BPM doit réellement faire avant que vous lui fassiez confiance
L’idée reçue que je rencontre le plus souvent est la suivante : les équipes choisissent un logiciel BPM avant d’avoir défini ce que ce logiciel doit prendre en charge. Elles évaluent l’outil isolément, achètent sur la base de la démonstration, puis découvrent six mois plus tard qu’elles ont mesuré l’adoption du logiciel plutôt que la performance du processus. Le système BPM n’est pas la discipline. Il soutient la discipline.
Avant de choisir une solution BPM, appliquez cette liste de contrôle à chaque plateforme que vous évaluez :
Prise en charge de la découverte et de la documentation des processus
La plateforme BPM doit pouvoir capturer les processus tels qu’ils existent réellement, et pas seulement tels qu’ils sont officiellement documentés. Si elle ne gère que des entrées structurées et des flux de processus propres, elle ne fera pas apparaître les contournements informels qui vous font perdre du temps.
Modélisation visuelle avec définition des KPI
Les outils de modélisation sont courants. Les outils de modélisation qui exigent de définir des métriques de performance en parallèle de la structure du processus le sont moins. Choisissez un système BPM qui ne vous permet pas de finaliser un modèle sans indiquer ce que signifie « mieux ».
Couche d’exécution connectée aux workflows réels
Le modèle doit être relié au travail réel. Cela peut passer par l’automatisation des workflows, le routage de documents, l’attribution des tâches ou les chaînes d’approbation. Un outil qui modélise parfaitement mais ne peut pas intervenir dans l’exécution quotidienne produit des diagrammes précis que personne ne respecte.
Tableaux de bord de suivi dotés de signaux exploitables
Les tableaux de bord doivent afficher le temps de cycle, le nombre d’erreurs, les taux d’achèvement des étapes et les exceptions, et pas seulement « le workflow s’est exécuté avec succès ». La distinction entre le statut d’exécution et la qualité du résultat est celle que la plupart des tableaux de bord ignorent discrètement. Une exécution au vert qui produit un mauvais résultat n’est pas une exécution réussie du processus.
Collaboration et attribution des responsabilités
Lorsque plusieurs départements interviennent dans un processus, les plateformes BPM doivent rendre les responsabilités visibles. Qui est responsable de chaque étape, qui examine les exceptions et qui est responsable du cycle d’amélioration ? Sans cela, vous obtenez des modèles de processus auxquels tout le monde fait référence et que personne ne maintient.
Lorsque vous choisissez une solution BPM selon ces critères, vous n’évaluez pas seulement un produit logiciel. Vous vérifiez si l’outil peut prendre en charge la discipline. Les décisions de gouvernance, les définitions de KPI, les attributions de responsabilités : rien de cela ne vient de l’outil. C’est vous qui les apportez. L’outil les rend soit plus faciles, soit plus difficiles à maintenir.
💡 La partie contre-intuitive :
Les organisations qui mettent en œuvre un logiciel BPM avant de définir les responsables de processus et les KPI finissent généralement par mesurer l’adoption de l’outil, et non la performance du processus. Elles peuvent vous dire combien d’utilisateurs se sont connectés à la plateforme. Elles ne peuvent pas vous dire si le processus s’est amélioré. La discipline doit précéder le logiciel, et non le suivre.
Ce qui fait réussir ou échouer une mise en œuvre BPM
Une chose mérite d’être précisée d’emblée : le BPM ne nécessite pas de ressources à l’échelle d’une grande entreprise. L’idée reçue selon laquelle la mise en œuvre de la gestion des processus métier n’est viable que pour les grandes organisations disposant d’équipes dédiées aux processus a poussé de nombreuses petites et moyennes entreprises vers des solutions ad hoc, alors qu’une approche disciplinée les aurait mieux servies. Le cycle de vie s’adapte à l’échelle. Le périmètre doit être réaliste, mais la discipline elle-même ne nécessite pas une équipe de dix personnes.
Elle exige toutefois un petit ensemble de conditions. Lorsque ces conditions sont présentes au lancement, les mises en œuvre BPM ont tendance à durer. Lorsqu’elles sont absentes, même des initiatives BPM bien financées et bien équipées produisent de la documentation et pas grand-chose d’autre.
Définir d’abord le bon périmètre de processus
La raison la plus fréquente pour laquelle les projets BPM stagnent avant de produire quoi que ce soit de mesurable est le choix du processus. Les équipes commencent par le processus le plus visible, le plus sensible politiquement ou le plus complexe de l’organisation. C’est compréhensible : c’est celui qui frustre tout le monde. Mais c’est aussi celui qui implique le plus de parties prenantes, le plus d’exceptions et le plus de désaccords sur ce que signifie simplement « fonctionner ».
Le BPM fonctionne sur les activités répétitives, continues et prévisibles. Le projet BPM qui produit un résultat dès le premier cycle est celui qui commence par un processus exécuté au moins chaque semaine, avec un début et une fin définissables, et qui ne change pas de forme à chaque exécution. C’est ce processus qu’il faut instrumenter en premier. Développez les capacités et la crédibilité sur un processus réellement maîtrisable avant de vous attaquer au plus difficile. Le plan de processus ne doit pas nécessairement commencer en tête de la liste des priorités. Il doit commencer là où la réussite est suffisamment atteignable pour prouver que le cycle fonctionne.
Un nouveau processus récemment défini est parfois plus simple à délimiter qu’un processus profondément ancré, précisément parce qu’il n’a pas encore accumulé de contournements. Si vous créez un nouveau flux d’onboarding, vous pouvez concevoir la structure BPM dès le départ. C’est en réalité plus facile que d’ajouter une gouvernance à un processus qui fonctionne de manière informelle depuis trois ans.
Gouvernance, responsabilité et mesure avant le lancement
Un BPM sans responsabilité définie produit de la documentation. Le processus est modélisé, l’outil est configuré, puis rien ne s’améliore parce que personne ne vérifie s’il s’améliore. L’élément manquant est presque toujours la gouvernance : qui est responsable du processus, qui examine les données de suivi et qui a la responsabilité de lancer le prochain cycle d’optimisation.
L’amélioration des processus exige une personne responsable de l’écart entre la performance actuelle et la performance cible. Pas un comité. Pas « l’équipe ». Une personne nommée, avec un critère de mesure, qui consulte les données selon un calendrier défini. Sans cela, le cycle de vie s’arrête à l’exécution et n’atteint jamais l’optimisation.
Une gestion efficace du changement compte également ici, et pas dans un sens abstrait. Les personnes qui exécutent le processus doivent comprendre pourquoi il a changé et en quoi leur travail diffère. Une gestion efficace du changement lors du lancement d’un BPM consiste moins à organiser des campagnes de communication qu’à rendre le nouveau processus plus facile à suivre que l’ancien contournement. Si le nouveau processus demande plus d’efforts que la version informelle qu’il remplace, les personnes le contourneront. Ce n’est pas de la résistance. C’est du bon sens.
L’amélioration continue comme véritable état final
Le signal indiquant que le BPM fonctionne n’est pas un lancement réussi. C’est le deuxième cycle d’optimisation.
Une initiative BPM réussie produit un changement mesurable lors du premier cycle, puis utilise ce changement comme référence pour le suivant. La boucle entre optimisation et conception du cycle de vie signifie que la discipline devient moins coûteuse et plus précise avec le temps : chaque passage est éclairé par des données d’exécution réelles plutôt que par des estimations initiales. Les équipes qui mettent en œuvre le BPM comme une initiative ponctuelle, déclarent leur réussite après le premier déploiement puis passent à autre chose n’atteignent jamais cette étape. La valeur reste théorique.
Si vous évaluez si une initiative BPM fonctionne réellement, la question à poser est la suivante : qu’est-ce que les données de suivi ont changé dans le cycle de conception suivant ? Si la réponse est « rien pour l’instant », le cycle de vie ne fonctionne pas. Vous avez un processus exécuté, pas un processus géré. L’avenir des programmes BPM qui préservent leur valeur tient au fait que la réponse à cette question s’enrichit à chaque cycle, et non qu’elle reste identique.
C’est là que les progrès les plus utiles d’une initiative BPM apparaissent réellement.
