Pas d’automatisation sans analyse préalable
A force de se focaliser sur les composantes technologiques du management des processus, on aurait tendance à faire passer au second plan les processus métier. Certes, et l’évolution des discours marketing en la matière est éloquente depuis un ou deux ans, il est de bon ton de souligner qu’une solution de BPM doit s’appuyer sur les processus métier, que l’urbanisation du SI doit intégrer une cartographie des fonctions métier. La terminologie "modélisation des processus métier" est ainsi apparue dans la plupart des présentations des dernières manifestations consacrées au BPM.

Mais la finalité de cette modélisation reste le plus souvent l’automatisation (l’intégration) dudit processus.

Si l’on cherche à faire les choses dans l’ordre, ce qui devrait être le cas de l’entreprise susceptible de mettre en place ce type de solution, l’automatisation, qui est un des axes d’optimisation du processus (parmi d’autres) devrait faire suite à une analyse préalable des processus métier.

C’est précisément l’objectif premier des référentiels d’entreprise (Enterprise Architecture) que de fournir ces éléments d’appréciation au sein d’un contexte global que les modules de modélisation des outils d’orchestration (BPM), quels qu’ils soient, sont loin de couvrir.

Analyse des processus d’un côté, modélisation en vue d’automatiser de l’autre, nous sommes face à deux catégories d’outil : Enterprise Architecture d’un côté, Business Process Management de l’autre, si l’on retient l’acception anglo-saxonne quelque peu restrictive de ce terme.

On peut regretter la nécessité de devoir se doter d’outils différents pour couvrir les besoins d’analyse et d’automatisation mais force est de constater que les profils d’utilisateurs (plus métier d’un côté, plus techniciens de l’autre) et même la granularité - le niveau de détails - des modèles (plus fine côté technique) diffèrent. Il faut bien entendu pouvoir s’assurer de la cohérence des modèles techniques par rapport aux modèles métier mais la nécessité de les faire cohabiter au sein d’un même outil et même de les représenter de manière identique (partage d’une même notation) ne va pas de soi.

Tout chantier d’intégration de processus devrait donc intégrer une première phase d’analyse organisationnelle qui, d’une part, justifiera le périmètre à automatiser, d’autre part prendra en compte les aspects non informatiques de l’optimisation (impact sur l’organisation, adaptation des procédures, risques réduits mais aussi induits par le nouveau chantier, définition des indicateurs de performance,…).

Quelles informations gérer au sein du référentiel ?
Au départ, une plateforme d’architecture d’entreprise se présente comme une boîte à outils : c’est un ensemble de moyens, qui permet de construire, reste à savoir quoi et comment.

Le contenu du référentiel pouvant prendre des formes très diverses, il importe dès la phase de lancement du projet de délimiter avec précision ses objectifs et son périmètre. La variété potentielle du contenu découle d’une part des multiples prismes du processus, d’autre part des finalités du projet. Le premier point concerne la nature des informations que l’on veut gérer au sein du référentiel, le second le niveau de détail requis.

La vision – relativement répandue - du "modèle unique"attaché à un processus ne résiste guère à l’épreuve du terrain. En réalité, le modèle est une vision simplifiée d’une réalité complexe et protéiforme : le niveau de détail de la formalisation dépend directement de l’usage qui est fait du modèle.

Prenons l’exemple d’un processus " traiter une commande à l’export » auquel on attache trois objectifs - qui le plus souvent ne seront pas adressés en parallèle - : industrialiser la production de procédures, analyser les coûts, et automatiser sa mise en œuvre. Le niveau de détail sera relativement fin pour la production de procédure, plus macro pour l’analyse de coût (faute de disposer d’éléments de mesure plus fins) et plus détaillé pour les besoins informatiques (règles de synchronisation, finesse des éléments en entrée et sortie…).

Le même processus est décrit via trois modèles correspondant à ces trois objectifs au sein du même référentiel : non seulement ce n’est pas aberrant mais c’est même souhaitable. Le fait que ces trois modèles cohabitent au sein du même référentiel leur permet de partager les éléments qu’ils ont en commun. Au niveau supérieur, ces modèles seront rattachés au même processus.

En fonction de leur profil, les intervenants accéderont à l’un ou l’autre des modèles dans l’outil ou sur le référentiel Intranet. On peut même imaginer qu’ils ne partagent pas les mêmes règles de représentation, les modèles métier (organisation et costing) partageant une notation métier que le modèle informatique ne retiendra pas. Le modèle peut parfaitement être représenté sous divers aspects sans être démultiplié pour autant et sans que cela pose de problème de cohérence, la représentation graphique n’étant que la partie visible d’une réalité.

L’étendue des données possibles rejoint les multiples visions que l’on peut avoir d’un même processus : vu sous l’angle organisationnel, on s’intéressera aux tâches et rôles des différents acteurs, mais on peut tout aussi bien y rajouter les logiciels utilisés à chaque étape (vue applicative), les informations manipulées, les risques opérationnels associés, la contribution aux objectifs stratégiques de l’entreprise, les indicateurs de performance, les compétences requises…

Bref, il est rare que l’on soit intéressé par toutes ces informations,et que l’on puisse matériellement mener de front les analyses permettant de couvrir simultanément tous ces aspects. Finalement un modèle ayant malgré tout cette vocation universelle serait trop encombré pour rester un instrument de travail pratique. Il est donc nécessaire de définir les objectifs du projet et d’en déduire la nature des informations à intégrer dans le référentiel. Compte tenu de l’outil de modélisation choisi, cette liste sera déclinée en un ensemble de modèles, objets, relations et attributs à gérer, formalisé dans un document incontournable du projet, la convention de modélisation.

Quel que soit l’objectif visé, la modélisation n’est pas une fin en soi. C’est particulièrement vrai dans le cas d’un projet d’optimisation où elle se situe très en amont. A partir de ce point de référence, on pourra simuler des alternatives, identifier des ruptures de charge organisationnelle ou informatique et éventuellement délimiter le périmètre du projet d’automatisation. Dans une optique d’optimisation, on s’assure ainsi que toutes les pistes d’amélioration sont explorées et non pas seulement celles fournies par le SI. Car ce n’est pas tout d’automatiser, encore faut-il automatiser un processus efficient. Et pour cela, avoir une vue d’ensemble de l’impact des améliorations envisagées sur les processus amont ou aval, mesurer les risques minorés par, ou au contraire, inhérents au processus cible est indispensable. Pour autant, si cette étape met en évidence la nécessité d’améliorer l’automatisation du processus, il s’agit d’assurer un bon passage de témoin avec la phase informatique du projet.

Assurer la coordination avec la maîtrise d’œuvre
Les outils d’orchestration de processus disposent tous d’un module de modélisation. Dans la présentation faite de ces outils, il est fréquent de le faire apparaître comme l’espace de travail à l’usage des utilisateurs métier pour définir leur besoin en prélude à l’automatisation de celui-ci.

Si ce module doit servir de réceptacle au référentiel d’entreprise, il lui manquera probablement des fonctions d’analyse (comparaison, simulation, analyses d’impact) ainsi que la capacité à réaliser les autres cartographies (SI, risques,…). L’idéal est de se servir de ce module comme réceptacle d’un modèle défini dans l’outil d’architecture d’entreprise. Le modèle importé sera alors complété par les éléments techniques nécessaires à son automatisation, notamment les points de connexion avec les bases de données et applications.

Dès lors que la cohabitation de deux outils spécialisés apparaît nécessaire, la question de l’échange d’informations entre ces outils se pose. Dans ce domaine, force est de reconnaître que l’interopérabilité des outils est… améliorable, même si avec l’avènement de BPEL, ce point progresse. En cas d’incompatibilité et compte tenu de ce qui a été dit précédemment sur les niveaux de détail distincts des deux modèles, on se résoudra à initier le modèle technique dans l’outil d’orchestration alors que le modèle métier sera dans l’outil d’architecture d’entreprise. Mais on perd la cohérence sur les éléments qu’ils partagent, qui est un point clé de réduction des risques de distorsion entre maîtrise d’ouvrage et maîtrise d’œuvre.

Un usage qui va s’étendre rapidement
Certes la notion de référentiel d’entreprise fait encore peur. La variété des apports potentiels d’un tel outil ne facilite pas sa perception par les entreprises. Comme pour tout type de projet, les success stories les plus convaincantes côtoient des échecs retentissants. Dans ce domaine aussi, la réussite du projet tient autant à l’outil choisi qu’à la méthode appliquée.

L’étude BPMS sur la réalité du marché français (mars 2005) a - entre autres – comparé les projets de mise en place de référentiel aux autres types de projet menés en matière de gestion des processus. : ils devancent d’une courte tête, en proportion, les projets de type plus technique (orchestration, urbanisation), répondent le plus souvent aux objectifs assignés et concernent potentiellement tous les secteurs d’activité.

C’est un fait, les projets d’architecture d’entreprise se multiplient, même si c’est à des rythmes et avec des ambitions très variables d’une organisation à l’autre. La France, dans ce domaine comme dans d’autres, a pris le train avec un certain retard sur ses voisins anglo-saxons. Mais elle tente de le rattraper et, progressivement, l’idée fait son chemin qu’une analyse métier complète préalable à un projet d’automatisation n’est ni une perte de temps ni un gaspillage de ressources mais au contraire un facteur clé de succès.