Qu’est-ce qu’un BPMS ? Comprendre la gestion des processus métier

Un BPMS, ou système de gestion des processus métier, modélise et exécute des processus définis, puis suit leur déroulement. Il est conçu pour orchestrer l’exécution : il impose un enchaînement d’étapes, attribue les tâches et consigne les opérations réalisées. Mais sa vision reste limitée à la partie du travail qui lui est confiée : il ne peut exécuter ni suivre le reste.

Ce guide explique le rôle d’un BPMS, les cinq composantes que vous achetez réellement et les limites de ce type de système. Il compare ensuite les logiciels d’exécution à la Process Intelligence, qui laisse volontairement l’exécution aux nombreux systèmes qui la maîtrisent déjà et rassemble leurs données dans un espace commun, accessible à vos équipes et à vos outils d’IA.

Que signifie BPMS ?

BPMS signifie Business Process Management System. Certains fournisseurs emploient plutôt l’expression Business Process Management Suite. Dans les deux cas, cette catégorie désigne des logiciels qui permettent de définir un processus, d’y acheminer le travail et d’en surveiller l’exécution.

Le BPM, ou gestion des processus métier, consiste à comprendre, concevoir, mesurer et améliorer la façon dont le travail est réalisé. Un BPMS est un type de logiciel qui peut soutenir cette démarche. Vous pouvez pratiquer le BPM sans acheter de BPMS, et l’achat d’un BPMS ne garantit pas une bonne gestion des processus.

Cette catégorie a évolué au fil du temps. Elle a commencé avec les moteurs de flux de travail, puis s’est élargie à des suites intégrant la modélisation, les formulaires et la surveillance. Elle comprend aujourd’hui des plateformes low-code qui permettent aux équipes de créer des applications complètes pour les processus. Cette diversité explique pourquoi les fournisseurs ne donnent pas tous la même définition d’un BPMS. Lorsque vous évaluez un logiciel de gestion des processus métier, ne vous arrêtez pas à son appellation. Posez-vous plutôt quatre questions : permet-il de modéliser et d’exécuter le processus, de le relier aux autres systèmes concernés et de suivre ses instances ?

Quelles sont les cinq composantes d’un BPMS ?

Les produits regroupent ces fonctionnalités de différentes façons, mais un système de gestion des processus métier comprend généralement cinq composantes :

1. Un outil de modélisation. Vous définissez le processus, souvent en BPMN 2.0. Un modèle peut décrire le flux et, dans un système exécutable, servir de base à son exécution. Consultez la page sur l’outil de modélisation BPMN pour en savoir plus sur la conception de modèles de processus.
2. Un moteur d’exécution. Le moteur crée des instances de processus, évalue les conditions, attribue les tâches, déclenche les minuteurs et signale les retards.
3. Des formulaires, des règles et des rôles. Ils déterminent les informations que les personnes fournissent, les tâches qui leur sont présentées et les règles qui régissent l’étape suivante.
4. Des intégrations. Le système échange des données avec des applications telles que les ERP et les CRM, les entrepôts de données et les passerelles API. La mise en place des intégrations peut représenter une part importante du projet.
5. Des fonctions de surveillance et un référentiel. Les Dashboards affichent l’état des instances en cours. Un référentiel vous aide à gérer les versions des processus et à contrôler les modifications.

Un moteur de flux de travail n’est qu’une composante de l’ensemble. Un BPMS associe ce moteur aux outils et aux contrôles nécessaires pour définir, prendre en charge et surveiller un processus plus large.

Qu’apporte un BPMS par rapport à un document décrivant un processus ?

Un document décrit comment le travail devrait se dérouler. Un BPMS peut acheminer et suivre le travail selon des règles configurées. Par exemple, il peut :

• Signaler une tâche en attente depuis une durée définie.
• Acheminer une instance pour approbation lorsqu’elle atteint un seuil configuré.
• Consigner le parcours suivi par chaque instance.
• Vous permettre de modifier un flux par configuration, sans changer plusieurs applications connexes.

Ces fonctionnalités sont utiles lorsque vous avez besoin d’un acheminement cohérent, de responsabilités clairement attribuées et d’une visibilité sur les instances gérées par le système. Elles ne garantissent pas que toutes les étapes du processus réel se déroulent dans le BPMS. Si votre principal besoin est de documenter un processus ou de comprendre son fonctionnement actuel, un logiciel d’exécution n’est peut-être pas le meilleur point de départ.

Quelles sont les différences entre un BPMS, un moteur de flux de travail, la RPA, le Process Mining et la Process Intelligence ?

Ces cinq technologies répondent à différents besoins de gestion des processus. Le tableau ci-dessous indique le rôle de chacune et les questions auxquelles elle peut vous aider à répondre.

La RPA et un BPMS abordent différemment l’évolution des processus. La RPA automatise des tâches dans le processus existant. Un BPMS exécute un processus que vous avez défini, ce qui peut modifier l’acheminement du travail. Avant d’automatiser une tâche, vérifiez si une refonte du processus permettrait de la supprimer. Découvrez comment repérer les possibilités d’automatisation grâce au Process Mining.

Le Process Mining et un BPMS répondent également à des questions différentes. Le Process Mining analyse les données d’événements pour montrer comment le travail circule réellement dans vos systèmes. Un BPMS exécute un flux conçu et rend compte des instances qu’il gère. Cette distinction est importante lorsque vous devez vérifier si le modèle correspond au travail réel.

La dernière ligne du tableau présente la Process Intelligence, qui relie les autres solutions. Elle laisse l’exécution au système le mieux adapté, lit les traces de chaque système et conserve un modèle unique du processus auquel les résultats de tous les systèmes sont comparés. Un BPMS rend compte de ses propres instances ; la Process Intelligence rend compte du processus dans son ensemble, y compris du travail qu’aucune plateforme ne gère à elle seule.

Pourquoi un seul BPMS ne peut-il pas exécuter tous les processus ?

Un BPMS semble répondre aux besoins de gestion des processus, jusqu’à ce que l’on compte les systèmes qu’il ne contrôle pas. Un processus réel passe par un ERP, un CRM, un outil de gestion des tickets, un portail fournisseur, un tableur et plusieurs boîtes de réception. La plateforme exécute la partie modélisée en son sein, tandis que le reste du travail se poursuit ailleurs.

Avant d’acheter, il est utile de connaître trois conséquences de cette limite.

Vous créez des flux de travail sur mesure au lieu de réutiliser des standards. Un BPMS est une boîte à outils. Chaque processus devient donc un projet : vous modélisez votre propre variante, nommez vos étapes et entretenez votre version d’un flux que des milliers d’autres organisations utilisent également. Les modèles de référence standard du secteur, par exemple pour le cycle de la commande au paiement, le cycle des achats au paiement ou la gestion des incidents, sont recréés dans chaque plateforme au lieu d’être réutilisés. Deux services utilisant le même système peuvent ainsi finir par avoir des versions différentes d’un même processus.

Les plateformes axées sur l’exécution perdent de vue l’ensemble. Un BPMS est évalué en fonction de ce qu’il exécute ; les flux qu’il gère concentrent donc l’attention et le budget. Les processus qu’il ne prend pas en charge, ceux qui traversent plusieurs équipes, systèmes et pays, sont souvent ceux dont personne n’est responsable. Accélérer l’exécution ne revient pas à comprendre le fonctionnement de l’organisation.

Un BPMS a toujours ses limites et finit par accumuler ses propres exceptions. Chaque processus comporte des exceptions : une commande urgente, un client VIP, un fournisseur qui n’accepte que les e-mails. Dans un BPMS, chaque exception devient une branche supplémentaire à configurer, un formulaire de plus, une intégration supplémentaire et un nouveau flux de travail à maintenir. La plateforme, censée standardiser le travail, se remplit peu à peu de cas particuliers que seule son équipe maîtrise.

Cela ne fait pas d’un BPMS un mauvais outil. En revanche, il ne peut pas constituer à lui seul la source de référence de vos processus.

L’écart est particulièrement marqué dans la gestion des processus métier liés à l’informatique : une même activité peut passer par une file de tickets, un calendrier des changements et plusieurs applications, sans qu’aucun logiciel de gestion des processus métier ne couvre l’ensemble.

Faut-il conserver un BPMS que vous utilisez à peine ?

De nombreuses organisations ont acheté un BPMS pour son moteur d’exécution, sans jamais s’en servir. Le déploiement a pris plus de temps que prévu, un partenaire a configuré les premiers flux et les équipes ont continué à travailler dans les systèmes qu’elles utilisaient déjà. Il reste un outil de modélisation sous licence, ouvert par quelques personnes pour dessiner des diagrammes, et une facture de maintenance pour un environnement d’exécution que personne ne lance.

C’est le moment de distinguer les deux fonctions réunies dans la plateforme. Le moteur de flux de travail devait exécuter le travail ; le référentiel de modèles devait conserver les connaissances sur les processus. Si seule la deuxième fonction est utilisée, vous payez une plateforme d’exécution pour faire office d’outil de documentation : une solution lourde, technique et coûteuse pour documenter vos processus.

Si la plupart de ces constats s’appliquent, vous demandez à la plateforme d’exécution de gérer des connaissances pour lesquelles elle n’a jamais été conçue. La solution n’est pas d’ajouter un environnement d’exécution. Il s’agit de centraliser ces connaissances dans un outil conçu pour cela : un espace unique pour tous vos processus, relié aux données de chaque système et accessible aux personnes comme aux assistants IA qui en ont besoin, sans environnement d’exécution à gérer.

Conservez le BPMS pour les processus qu’il exécute réellement. Transférez les connaissances sur les processus dans un espace où elles pourront évoluer sans attendre une nouvelle version.

En quoi la Process Intelligence diffère-t-elle d’un BPMS ?

Cette différence est un choix délibéré, pas une fonctionnalité manquante. La Process Intelligence ne prend pas en charge l’exécution, car de nombreux outils peuvent s’en charger et la plateforme que vous possédez n’est que rarement la mieux adaptée. RPA, agents IA, système de gestion des flux de travail, flux de travail intégrés à l’ERP ou équipes qui réalisent simplement le travail : chacun peut être le bon choix dans un contexte différent. L’outil d’exécution doit être choisi pour cette seule fonction.

En revanche, les connaissances ne peuvent pas être dispersées entre cinq systèmes. Si chaque outil d’exécution conserve sa propre représentation du processus, personne ne peut dire en quoi consiste le processus, quelle variante un client a réellement suivie ni quelle étape automatiser ensuite. Centraliser les connaissances sur les processus, pour les équipes qui réalisent le travail comme pour les assistants IA auxquels elles font désormais appel, compte davantage que d’exécuter le travail.

C’est là que réside l’avantage des données. Un BPMS rend compte de ses propres instances ; une plateforme de Process Intelligence relie les données d’événements de tous les systèmes et donne ainsi une vue d’ensemble, y compris du travail que le BPMS n’a jamais vu. Elle peut alors héberger le modèle de référence auquel le BPMS, l’ERP et les outils d’automatisation sont tous comparés.

Pourquoi le Process Mining est-il nécessaire pour ancrer le modèle dans la réalité ?

Un BPMS peut rendre compte des instances qui s’exécutent en son sein. Cela ne signifie pas qu’il recense tous les parcours suivis par les équipes pour mener le processus à bien. Trois lacunes sont fréquentes :

• Le travail se déroule en dehors du moteur. Une personne traite une exception par e-mail, puis met le système à jour. L’instance peut sembler conforme, alors que le travail a pris plus de temps que ne le laisse penser le modèle.
• Le même résultat est obtenu dans d’autres systèmes. Les équipes peuvent utiliser un ERP, un tableur ou un portail fournisseur. Si ces activités ne sont jamais enregistrées dans le BPMS, ses Dashboards ne peuvent pas montrer le processus dans son ensemble.
• Le modèle prend du retard. Un processus peut être exact au moment de sa publication, puis évoluer à mesure que les équipes adoptent des variantes locales. Si la mise à jour du modèle prend du temps, ces variantes peuvent perdurer.

On obtient alors un modèle bien géré qui ne reflète plus la façon dont les équipes travaillent. Le Process Mining permet de le confronter à nouveau à la réalité : il lit les données d’événements déjà enregistrées par vos systèmes et reconstitue les parcours réellement suivis, y compris ceux que personne n’a modélisés.

La vérification de conformité compare un modèle de processus aux données d’événements pour faire apparaître les écarts entre le fonctionnement prévu et l’exécution réelle. De son côté, le Process Mining révèle les variantes, les retards et les reprises présents dans vos propres données. Pourquoi la modélisation des processus et le Process Mining vont de pair explique pourquoi ces deux aspects, ce que vous prévoyez et ce qui s’est réellement passé, ne doivent jamais être dissociés.

Pourquoi avons-nous décidé de ne pas développer de fonction d’exécution ?

C’est une question légitime pour une plateforme de processus : si vous pouvez modéliser un processus et observer son déroulement, pourquoi ne pas aussi l’exécuter ? Les BPMS existent parce que la réponse semble évidente : pourquoi pas ? Nous avons choisi une autre voie, par décision et non par omission.

Concrètement, ProcessMind ne vous demande jamais de lui confier les clés de vos flux de travail. Les systèmes que vous utilisez continuent d’exécuter le travail, tandis que les connaissances sur ce qu’ils exécutent sont centralisées et tenues à jour. Si vous remplacez ensuite un outil d’exécution, par exemple un robot RPA par un agent IA ou un ancien flux de travail par un nouveau, le modèle, l’historique et les mesures restent en place. Pourquoi nous avons créé ProcessMind présente les autres raisons qui ont guidé ce choix.

Comment ProcessMind s’intègre-t-il à un BPMS ?

ProcessMind n’est pas un BPMS et n’exécute pas le travail. Votre BPMS, votre ERP ou votre plateforme d’automatisation reste chargé d’exécuter les processus. C’est précisément le principe : conserver le meilleur outil d’exécution pour chaque processus et réunir au même endroit les connaissances sur l’ensemble de ces processus.

C’est ce que fait la Process Intelligence en pratique :

• Avant de construire : analysez les données d’événements des systèmes concernés pour repérer les parcours réels, les variantes et les exceptions. Modélisez le processus cible en BPMN 2.0, puis utilisez la simulation des processus pour tester un changement avant que quiconque ne configure un flux de travail.
• Après la mise en place : poursuivez l’analyse pour vérifier si l’exécution correspond toujours à la conception et repérer les solutions de contournement locales qui sont discrètement devenues la norme.

Le BPMS exécute le travail. La Process Intelligence aide à déterminer ce qui mérite d’être exécuté et à vérifier si le résultat correspond au processus réellement suivi par les équipes.

Quand choisir un BPMS, la RPA ou la Process Intelligence ?

Le bon point de départ dépend de ce que vous savez déjà et du problème que vous cherchez à résoudre.

Commencez par la Process Intelligence si :

• Les équipes ne s’accordent pas sur le fonctionnement actuel du processus.
• Le processus traverse plusieurs systèmes et une partie du travail peut se dérouler en dehors du flux de travail principal.
• Vous savez que le processus est lent, mais vous ignorez pourquoi.
• Vous possédez un BPMS dont le moteur de flux de travail reste inutilisé et souhaitez conserver les connaissances sur les processus dans un espace utile.

Envisagez un BPMS si :

• Le processus est compris et suffisamment stable pour être standardisé.
• Le travail passe d’une équipe à l’autre et les transferts nécessitent des règles d’affectation ou des responsabilités plus claires.
• Vous devez faire respecter des règles et gérer des changements sans intervenir dans plusieurs applications à la fois.

Envisagez la RPA si :

• Le processus est stable et répétitif.
• La tâche est assez fréquente pour justifier son automatisation.
• Les applications ne peuvent pas être modifiées et l’étape peut être automatisée à partir de leurs interfaces.

Deux réflexes permettent de garder le bon ordre : mesurez le processus avant d’acheter un logiciel d’exécution, puis vérifiez si une refonte permettrait de supprimer la tâche avant de l’automatiser.

Comment évaluer un BPMS avant de l’acheter ?

Commencez par un processus clairement nommé et placé sous la responsabilité d’une personne : de la commande à l’encaissement, des achats au paiement, intégration ou traitement des incidents. Évitez d’évaluer un domaine général comme les « opérations » sans préciser le processus concerné. Suivez ensuite quatre étapes.

1. Repérez les données d’événements

   Repérez les systèmes qui enregistrent le processus et vérifiez que leurs traces contiennent un identifiant de cas, une activité et un horodatage. Les outils de gestion des processus métier décrivent le déroulement prévu ; le journal d’événements permet de vérifier ce qui s’est réellement passé.

2. Comparez la conception au déroulement réel

   Recherchez les parcours, les retards et les exceptions que le modèle ne montre pas. Tester le BPMS le mieux adapté à partir de vos propres données est plus utile qu’un tableau comparatif des fonctionnalités : vous verrez quelles parties du processus il prendrait réellement en charge.

3. Déterminez ce que les constats indiquent

   La solution peut être un BPMS, une refonte du processus, la modification d’une étape ou aucune intervention. Laissez les constats guider le choix de l’outil, et non l’inverse.

4. Continuez à mesurer après la mise en place

   La plateforme peut rendre compte des tâches qu’elle exécute. Les données d’événements issues de l’ensemble de vos systèmes permettent de vérifier si le processus correspond toujours au travail réel une fois le flux de travail en place.

Si le processus traverse des systèmes auxquels le BPMS n’est pas connecté, les premières mesures le feront apparaître. C’est cette comparaison qui permet de décider s’il vaut la peine d’investir dans l’exécution.