Dans une étude du 5 décembre 1997, l’institut Gartner Group identifiait les "neuf raisons pour lesquelles les directions des systèmes d’information (DSI) ne font pas de BPM." A l’époque, BPM signifiait Business Process Modeling et non Management. C’est aujourd'hui de l’histoire ancienne, et nous assistons maintenant au rapprochement entre éditeurs d’outils de modélisation et fournisseurs de solutions «Business Process Management».
Howard Smith (CSC) et Peter Fingar, coauteurs de l’ouvrage «Business Process Management : The Third Wave», reviennent ici sur chacune des raisons évoquées à l’époque pour nous projeter dans le futur du BPM.

1- "Les directions métiers ne veulent pas faire l’effort"
2- "Nous avons essayé les AGL et n’en sommes pas satisfaits"
3- "Nous n’avons pas le temps"
4- "Les directions métiers nous disent ce qu’elles veulent, nous ne leur posons pas de question"
5- «Nous n’arrivons pas à maintenir en phase les modèles métier et technologique»
6- "Les métiers changent trop vite pour qu’on puisse les modéliser"
7- "La modélisation des applications n’est-elle pas suffisante ?"
8- "Le prototypage n’est-il pas suffisant ?"
9- "Le Business Process Modeling apporte plus de problèmes que d’avantages"

Le BPM, un nouveau type de management ?




Raison numéro 1 : "Les directions métiers ne veulent pas faire l’effort"
Beaucoup d’entreprises pensaient que la modélisation des processus devait être pilotée par la DSI avec la participation des responsables opérationnels, pour faciliter un processus d’ingénierie de plus en plus complexe. Il va sans dire que certaines directions rechignaient à s’investir. A l’inverse, les actions de Business Process Management sont maintenant conçues comme des projets pilotés par les métiers, sans qu’il soit besoin de faire appel à la DSI pour transformer les modèles de processus métiers en processus exécutables.

Raison numéro 2- "Nous avons essayé les AGL et n’en sommes pas satisfaits"
Les lacunes des outils d’atelier de génie logiciel (AGL), qui ont conduit à une sorte de "paralysie par excès d’analyse", sont maintenant bien connues. Les AGL ont représenté une étape intermédiaire permettant d’automatiser la cartographie des besoins métiers et des paramètres de conception pour aboutir aux objets, artéfacts, composants logiciels, interfaces, etc. Le BPM représente un nouveau type d’outil, orienté non plus «objets» mais «processus». Comme sa finalité est d’exprimer le fonctionnement métier, le BPM n’exige pas les mêmes étapes de traduction que les AGL et autres approches de développement unifiées. Il fournit directement les briques nécessaires pour l’élaboration d’un modèle métier et de traitements complexes, sans les développements logiciels traditionnels.

Raison numéro 3- "Nous n’avons pas le temps"
Lorsque les projets étaient pilotés par la DSI, le Business Process Modeling était souvent perçu comme une étape superflue dans le processus d’ingéniérie du logiciel. Son utilisation était généralement incompatible avec des calendriers serrés, encore alourdis dès 1997 par la perspective du passage à l’an 2000. En revanche, les outils orientés «processus» de la troisième génération représentent la plus rapide des méthodologies de développement jamais offertes aux entreprises. Le modèle «processus» est le système, le système est le métier. Le BPM permet de modéliser non seulement les processus informatisés, mais aussi les processus manuels, abstraits ou du monde réel, ce qui ouvre la voie à l’élaboration de modèles numériques complets de l’entreprise, intégrant les processus de gestion, les processus abstraits, les processus de capitalisation des connaissances et d’apprentissage. Il n’existe donc plus de distinction entre ceux-ci et les processus traditionnellement assimilés à des applications. Les modèles sont juste des modèles et peuvent intégrer toutes sortes d’éléments et d’intervenants.

Raison numéro 4- "Les directions métiers nous disent ce qu’elles veulent, nous ne leur posons pas de question"
Le Business Process Modeling a souvent été présenté comme le moyen de combler le fossé entre les opérations et la DSI, grâce à une combinaison de "push" (dévolu à l’informatique) et de "pull" (dévolu aux opérations). C’était oublier que les directions métiers perçoivent souvent les services informatiques comme de simples centres de coûts, et sont peu disposées à tolérer ce genre d’intervention. Tout en cherchant également à combler le fossé entre métier et technologie, le Business Process Management se fonde sur une stratégie radicalement différente. Au lieu d’essayer d’inverser le sens naturel de la chaîne de commandement, le Business Process Management crée une relation de symbiose entre les directions métiers et la DSI. En fournissant un langage commun pour décrire les processus, le BPM permet de tirer les informaticiens vers une réflexion stratégique, et les invite à contribuer à l’innovation métier grâce à leur expérience des systèmes.

Raison numéro 5- «Nous n’arrivons pas à maintenir en phase les modèles métier et technologique»
A l’origine, le Business Process Modeling était utilisé pour le développement de modèles servant uniquement à définir les besoins pour les développements logiciels. La définition des besoins constitue le début d’un processus de développement, comportant de nombreuses étapes : analyse, conception, codification, recette, mise en œuvre. Ce même processus génère des écarts entre les modèles métier et technologique, qu’il devient pratiquement impossible d’aligner à cause de l’extrême complexité et de la multiplicité des relations entre les besoins et les artéfacts techniques associés (composants logiciels, fichiers, interfaces, etc). Pour avoir tiré les leçons du développement logiciel, le Business Process Management repose sur une architecture préconisant un seul modèle partagé et préservé tout au long de la vie du processus. Au lieu de reposer sur des mécanismes d’évolution multiples, le Business Process Management offre aux analystes métiers, aux ingénieurs logiciels, aux partenaires et aux clients de nombreux axes d’approche d’un même modèle.

Raison numéro 6- "Les métiers changent trop vite pour qu’on puisse les modéliser"
L’inaptitude du Business Process Modeling à capter en temps réel les changements métiers a été mise en lumière par deux facteurs principaux : en premier lieu, la nécessité de synchroniser les modèles métier et technologique ; en deuxième lieu, l’approche globale généralement adoptée dans les projets de modélisation des processus. Comme le Business Process Management repose sur un seul modèle partagé par les directions métiers et informatique, les processus métiers sont plus rapidement et plus facilement adaptés aux évolutions requises par le marché. De plus, le Business Process Management, bien qu’appelant une approche «top-down», n’oblige pas à modéliser l’ensemble de l’entreprise. Cette approche pragmatique de la modélisation est l’un des facteurs clés de succès des projets de BPM.

Raison numéro 7- "La modélisation des applications n’est-elle pas suffisante ?"
Le Business Process Modeling est souvent entré en conflit avec d’autres techniques de modélisation conçues pour le développement et la maintenance des applications, notamment l’ULM (Unified Modeling Language). Le Business Process Management permet de construire et de perfectionner les processus métiers. L’UML et d’autres méthodes de modélisation continueront à jouer un rôle important dans le développement des applications, mais une fois ces applications intégrées dans le modèle métier, aucun développement supplémentaire n’est requis pour construire et maintenir les processus métiers. Il suffit d’intégrer une seule fois les applications, puis de créer, concevoir, déployer, piloter, les processus métiers n’importe où, n’importe quand et aussi souvent qu’on le veut.

Raison numéro 8- "Le prototypage n’est-il pas suffisant ?"
Parce que le Business Process Modeling a été vendu aux directions informatiques plutôt qu’aux directions métiers, le processus métier a souvent été confondu avec le processus technique et il a couramment été représenté en terme d’artéfacts techniques : procédures système, flux d’écrans, etc. On en a conclu que le Business Process Modeling n’était qu’un nouveau mot pour désigner le prototypage des applications. Pourtant, ce n’est pas pour rien que «Business Process Management» contient les termes «business process». En effet, il s’agit d’une méthodologie qui attache une grande importance à la dimension «métier» («business») des processus. Bien que les procédures systèmes et les flux d’interactions entre utilisateurs d’écran puisent toujours être captés au niveau le plus bas de la conception du processus, ceci ne concerne que l’aspect «interactions» d’un processus métier de niveau plus élevé, préalablement défini par les analystes métiers. Les processus ont une existence propre, vivent au rythme du monde changeant qui les entoure, alors que les prototypes ne sont que des prototypes. Les processus, situés précisément à l’intersection des activités manuelles et automatisées, sont aujourd’hui capables d’ajuster leurs propres interfaces utilisateurs. Quand les processus changent, l’interface change automatiquement.

Raison numéro 9- "Le Business Process Modeling apporte plus de problèmes que d’avantages"
Pour toutes les raisons citées plus haut, beaucoup d’entreprises sont arrivées à la conclusion que le Business Process Modeling posait trop de problèmes à la mise en place. Cela n’est pas surprenant dans la mesure où cette technologie a été vendue à la mauvaise cible et, de ce fait, a causé toutes sortes de tensions et de conflits, tant à l’intérieur des services qu’entre les directions métiers et informatique. Mais la perception des entreprises est en train de changer, de même que celle des éditeurs. Ceux-ci jouent maintenant un rôle clé en offrant des outils de modélisation sophistiqués qui viennent coiffer les systèmes de gestion des processus.

Le BPM, un nouveau type de management
Au départ, la plupart des outils de modélisation actuels étaient des outils destinés aux informaticiens pour le développement des applications. Avec la vague du Business Process Reengineering, les DSI ont demandé aux éditeurs des outils de modélisation orientés «business» pour compléter ceux destinés à la modélisation des applications. La réponse des éditeurs a été de proposer des outils permettant d’élaborer des modèles d’entreprise ou de processus, ainsi qu’un dictionnaire de données pour relier ces nouveaux outils aux outils de développements logiciels. Toutefois, l’existence de paradigmes de modélisation concurrents a rapidement conduit certains éditeurs vers une nouvelle étape : la synthèse et la convergence de tous les axes d’analyse. Les éditeurs d’outils de modélisation de processus, qui ont toujours clamé que le processus est roi, ont commencé à cibler les directions métiers au lieu des DSI, préparant ainsi le terrain pour l’adoption du BPM par les responsables opérationnels, en collaboration avec l’informatique (NDLR : en France, la situation s’est encore plus complexifiée avec la traditionnelle séparation maîtrise d’ouvrage/maîtrise d’œuvre, laquelle a atteint depuis longtemps ses limites). A présent, l’ancien dictionnaire de données intégré dans l’environnement de modélisation de processus a été remplacé par un dictionnaire des processus, et les anciennes données ont cédé la place aux données de processus. Comme les adeptes du workflow, les éditeurs d’outils «Process Modeling» ont été des novateurs et les pionniers du «Process Management», introduisant ainsi un nouveau type de management.