Le BPM, une vraie fabrique d'applications
par mail
l'article
Circulation de documents, validation de tâches, intégration de données, orchestration de services… Le BPM, ou gestion de processus, recouvre des réalités bien différentes selon le contexte dans lequel il est mis en œuvre. Les réalisations de CHD (cabinet d'expertise comptable), de Sivoa (Syndicat de la vallée de l'Orge aval), et de Calyon (banque de financement et d'investissement du groupe Crédit Agricole) reflètent cette diversité.
Les deux premières concernent l'automatisation de flux documentaires. Elles reposent sur des interactions humaines et sont à ranger dans le monde de la bureautique. La dernière engage des traitements de données qui sollicitent les services du middleware. Mais qu'ils flirtent avec le document ou l'infrastructure, ces projets BPM s'appuient tous sur un moteur d'orchestration et des workflows associés.
L'utilisation : de la gestion du courrier aux flux bancaires
Pour CHD et le Sivoa, le BPM est une histoire de courrier. Chez le Syndicat de la vallée de l'Orge aval, Workey, le workflow de C-Log, automatise les procédures d'envois postaux de documents, “ de la soumission du courrier par son créateur à son impression, en passant par deux phases de validation ”, dit Christian Pitet, informaticien du syndicat. Chaque étape du processus nécessitant le remplissage d'un formulaire. Workey s'appuie sur l'infrastructure Lotus du Sivoa : à partir de la modélisation des flux, il génère des bases Domino qui stockent les entités du workflow (rôles, état, actions…). Lors de l'exécution, ces ressources sont exploitées par le moteur d'orchestration de Lotus.
Courrier toujours chez CHD, mais courrier de masse. Le cabinet d'expertise comptable exploite le BPM d'Opalis pour infogérer le traitement de la paie de ses clients. “ 50 de ses collaborateurs éditent ainsi près de 17 000 bulletins par mois, rapporte Stéphane Canivet, DSI de CHD. Le workflow intervient en amont et en aval des traitements. ” Le client envoie à CHD ses variables de paie par messagerie. Une fois formatées dans un tableau Excel, Opalis les récupère dans la boîte aux lettres, les stocke dans le dossier client approprié, puis alerte l'opérateur par messagerie. La fiche de paie qui résulte du traitement est alors éditée en PDF, puis placée dans une corbeille. Ici s'achève le travail de l'opérateur, le BMP prenant en charge les tâches de routage du bulletin. Opalis archive le document dans l'application de GED et l'envoie au client par courrier électronique, dans un message personnalisé. Il peut aussi être dirigé vers l'imprimante si le client souhaite recevoir un courrier postal.
Pour Calyon, en revanche, le BPM est exploité au cœur d'un processus métier : la réconciliation de valeur. “ Celle-ci garantit que l'établissement financier et ses courtiers partagent la même image des transactions passées. Autrement dit, que les valeurs des achats et des ventes de titres sont identiques de part et d'autre ”, précise Philippe Meyer, responsable informatique Equity Derivative chez Calyon. Ce processus repose sur l'orchestration de plusieurs types de services, véhiculés par l'ESB de Websphere. Les uns fournissent un accès à des référentiels (titres et clients), les autres exposent l'application de réconciliation en tant que telle (qui rapproche notamment des valeurs agrégées et de données de détail). C'est le serveur IBM Websphere Process Server qui automatise l'extraction de données et leur envoi vers l'application de réconciliation.
La mise en œuvre : une modélisation isolée de l'orchestration
Le design de processus constitue l'étape préalable à la mise en production d'un moteur de BPM, qu'il orchestre des flux documentaires ou des services. Souvent dévolue aux équipes métier, elle se traduit par une modélisation des flux faisant interagir des rôles, des actions, et des tâches. Cette cartographie s'effectue à l'aide de diagrammes sur une feuille blanche, d'un document bureautique, ou d'un outil de cartographie dédié.
Comment l'exploiter ensuite dans le BPM ? Telle est la question encore non (ou mal) résolue de la gestion de processus. Dans l'idéal, elle devrait pouvoir être interprétée et traduite par l'environnement de design technique du moteur d'orchestration. Reste que selon la nature des processus, de la cartographie, et du moteur BPM en présence dans l'entreprise, ce passage de relais est plus ou moins bien assuré. Chez CHD, ce pont a été effectué manuellement. Le processus de gestion des courriers de l'expert-comptable a beau être simple, sa modélisation dans Opalis n'aurait pas été intelligible par les métiers. CHD s'est donc tourné vers Visio pour modéliser ses flux de courrier. “ Nous devions présenter un document servant de référence pour nos 12 plates-formes de paies ”, explique Stéphane Canivet. Il s'est ensuite appuyé sur la cartographie réalisée sous Visio pour paramétrer le moteur d'Opalis. Une opération effectuée “ à la souris ”.
De son côté, Calyon a résolu la problématique du passage de relais entre cartographie métier et modélisation technique de façon radicale : en se passant de cartographie. En octobre 2006, lorsqu'il s'équipe d'IBM Websphere Process Server, Philippe Meyer réalise que des modifications opérées dans le fichier BPEL (consommé par Process Server) ne peuvent pas être répercutées dans l'outil de cartographie. “ Depuis décembre dernier, Big Blue garantit cette remontée d'information dans une nouvelle version de Process Server. Mais nous ne voulions pas délaisser un outil que nous commencions à maîtriser. ” En absence de cartographie, la modélisation des processus a été effectuée en BPEL. Cette représentation technique ne semble pas affecter les maîtrises d'ouvrage, aidées par les maîtrises d'œuvre dans le design de ces processus. “ D'un point de vue métier, cette modélisation est certes polluée par des données techniques, mais nous avons la garantie d'une parfaite adéquation entre ce qui est ici modélisé, et ce qui est véritablement orchestré derrière. ”
Le Sivoa, lui aussi, a renoncé à la cartographie métier. La modélisation du processus d'envoi de courrier s'est effectuée dans l'atelier de développement de C-Log. A ce stade, il s'agissait de définir, pour chaque type de document, toutes les conditions nécessaires au changement d'état du courrier. Parallèlement à ce design des flux, Christian Pitet a conçu les interfaces utilisateurs correspondantes, en l'occurrence des formulaires sous Lotus. Principal enjeu : définir les champs et restreindre leur remplissage à des conditions telles que l'état et la nature du document, la date, l'étape du workflow et les rôles, entre autres. “ Pour chaque étape du workflow, nous avons organisé des réunions avec les utilisateurs afin de valider les formulaires associés. La démarche était itérative, car les ajustements sur l'orchestration du processus entraînent nécessairement des modifications au niveau des formulaires, et vise versa ”, explique Christian Pitet.
Les gains : un moteur de composition d'applications
Dans le monde documentaire, le retour sur investissement est aisé à chiffrer. Chez CHD, il a été atteint en huit mois. Les gains portent essentiellement sur l'automatisation des impressions des bulletins ou leur envoi par mail. “ Selon nos calculs, nos collaborateurs ont économisé 25 % de leur temps avec le workflow ”, précise Stéphane Canivet. CHD entend maintenant capitaliser sur les travaux menés lors de ce premier processus pour couvrir d'autres activités. “ Nous réutiliserons les flux liés à l'archivage des impressions ou à la génération automatique d'e-mails. Ils serviront pour la réalisation du bilan ou pour la gestion des comptes. Deux processus que nous déploierons dans Opalis d'ici à 2008 ”, prévoit Stéphane Canivet.
Même type de capitalisation pour Sivoa. “ Workey nous a coûté le prix d'un outil de gestion des courriers. Mais il nous a aidés à développer d'autres applications ”, rapporte Christian Pitet. Outre le courrier, Workey est en effet exploité, depuis quelques mois, pour la gestion des actes administratifs du syndicat. Troisième application prévue : la gestion des congés, des frais de déplacements, et des ordres de mission.
Calyon, pour sa part, se montre plus réservé. Son usage du BPM a beau toucher directement un processus métier, il reste très circonscrit. Car la grande majorité des services exposés par le système d'information de Calyon n'a pas vocation à être orchestrée. Mais plutôt à servir de socle pour le développement de nouvelles applications, telles que le pricing ou la mesure du risque, par exemple. “ Je n'attends pas un bénéfice extrêmement fort du BPM, reconnaît Philippe Meyer. Il est très séduisant de pouvoir modifier rapidement des processus informatiques. Mais il faut tenir compte de l'impact de ces modifications sur les métiers. Certes, certains fonctionnels avancés comprennent le langage BPEL et la modélisation technique associée. Mais nous gagnerions à manipuler un langage de plus haut niveau pour associer un maximum d'utilisateurs. ”
Les écueils : la restitution est rarement appropriée
Les offres de BPM sont souvent livrées avec des outils de design, voire avec leur propre outil de restitution. Mais ils correspondent rarement aux besoins ciblés des utilisateurs. Chez Sivoa, l'outil de conception de formulaires de C-Log s'est révélé bien trop lourd à utiliser. Il autorise, certes, un contrôle très pointu des champs en fonction d'une multitude de paramètres. Mais les données saisies pour la validation du courrier ou des actes administratifs sont peu critiques. Elles ne méritent pas l'apposition d'un tel cadenas sur les champs. Résultat, le syndicat édite désormais ses formulaires Lotus directement dans Lotus…
Illustration inverse chez Calyon, où les interfaces fournies avec Process Server étaient trop pauvres. Philippe Meyer voulait y voir figurer des champs et des informations supplémentaires. L'établissement financier a donc renoncé au frontal d'IBM et a développé sa propre interface web, via une API fournie par IBM.
Mais au-delà des frontaux, le déploiement du BPM en entreprise est freiné par sa délicate acceptation dans l'entreprise. Stéphane Canivet, de CHD, le reconnaît : “ il est difficile d'adopter un outil qui, sous prétexte d'un gain de productivité, vous impose de réaliser de nouvelles tâches. ”.
Les 3 entreprises étudiées
Activité : cabinet d'audit et d'expertise comptable.
Siège : Soissons (Aisne).
Effectif : 500 collaborateurs.
CA 2007 : 34,8 M d'euros.
Problème à résoudre : CHD reçoit des variables de paie de ses clients pour éditer leur bulletin de salaire (17 000 par mois). Il souhaitait automatiser ces flux documentaires : de la réception de ces variables, à l'envoi par mail ou par courrier des bulletins édités.
Solution déployée : Integration Server d'Opalis, déployé par 2Sl-Systems. Budget : 6 000 euros (8 licences et déploiement).
Activité : entretien des berges et gestion hydraulique de la rivière Orge.
Siège : Viry-Châtillon (Essonne).
Effectif : 88 personnes.
Problème à résoudre : l'émission de courrier nécessite un circuit de validation interne qui fait intervenir cinq rôles. Un processus qui, jusqu'à présent, était réalisé manuellement.
Solution déployée : Workey, le workflow de C-Log. Il exploite le moteur et les formulaires de Lotus, la plate-forme de travail de groupe utilisée par le Sivoa. Budget : moins de 10 000 euros ht pour 50 utilisateurs.
Activité : banque de financement et d'investissement du groupe Crédit Agricole.
Siège : Paris.
Effectif : 13 000 personnes.
CA 2006 : 588 M d'euros.
Problème à résoudre : orchestrer l'infrastructure SOA de la banque. Dans un premier temps, pour le processus de réconciliation de valeur. Ce dernier était jusque-là automatisé par un EAI d'ancienne génération (Crossworld), que Calyon avait enrichi avec Java.
Solution déployée : Websphere Process Server d'IBM. Il orchestre des services d'accès à des référentiels de valeurs et de clients dans le cadre d'une réconciliation de données.
Orchestrer les documents et gérer les flux de données
Le BPM au sens workflow humain, ou documentaire, a un impact sur le travail des utilisateurs. En automatisant certaines de leurs tâches, sans réelle valeur ajoutée, il implique un recentrage de leur activité au profit d'une meilleure productivité. Ce bouleversement, souvent mal vécu par les opérationnels, constitue le principal frein au développement de ce genre d'outil.
Une fois maîtrisés par leur concepteur, les outils de BPM documentaire ou humain couvrent tous les processus documentaires de l'entreprise. Précisément ceux qui ne relèvent pas de la production : validation de courriers, gestion des congés et des notes de frais… C'est du moins l'intention des entreprises qui entendent capitaliser sur les efforts qu'elles ont menés pour déployer leur premier processus.
Exploiter un BPM centré sur l'intégration de données revient, la plupart du temps, à s'appuyer sur les couches sous-jacentes d'un midleware – un ESB (bus d'entreprise) par exemple. Cela est surtout vrai pour les offres des grands éditeurs d'infrastructure. Cette intégration facilite le design des flux de données directement à partir du BPM. Ou encore l'exploitation, par ce dernier, de services conçus et exposés depuis le serveur d'applications.
Le design du processus et la conception de l'interface utilisateur constituent les phases sensibles du projet. Le premier parce qu'il doit être réalisé dans un environnement exploitable par le fonctionnel, repris dans un second temps par les techniciens. Or, la synchronisation de ce passage de relais est souvent perfectible dans les outils du marché. La seconde, la couche de restitution que les éditeurs attellent à leur BPM, s'avère souvent trop pauvre. D'où le recours à des développements spécifiques.
Christian Pitet (Sivoa) : “ un workflow plutôt qu'un outil de gestion de courriers dédié ”
“ Avant de nous doter de notre solution de BPM, un logiciel maison avait été déployé sous Lotus pour gérer les envois de courriers. Mais la lenteur de ses temps de réponse le rendait quasi inexploitable. Les applications de gestion de courriers que nous avons alors étudiées étaient soit trop complexes, soit trop pauvres – elles n'acceptaient pas plusieurs niveaux de validation. Nous nous sommes donc rabattus sur les solutions de workflow. Pour nous, C-Log offrait l'avantage d'exploiter l'infrastructure Notes que nous possédions. Les autres éditeurs disposaient de leur propre moteur de workflow. Depuis, nous utilisons aussi C-Log pour la gestion des actes administratifs. ”
Stéphane Canivet (CHD) : “ des développements spécifiques indispensables ”
“ Nous avons enrichi notre worflow documentaire de trois développements maison. Le premier visait à bâtir dans l'intranet un environnement de tableaux de bord pour le suivi des échanges de courriers. Il s'agissait d'historier l'activité du BPM, de connaître à tout moment les variables de paie reçues, ainsi que les bulletins envoyés et archivés. Nous avons également conçu un système de nommage, autorisant l'insertion des références du client ou du collaborateur dans le nom des bulletins de paie. Enfin, nous avons développé une interface web pour administrer la base clients SQL (activation ou désactivation d'un client, ajout de nouveaux modèles de documents…). ”
Philippe Meyer (Calyon) : “ envisager le dialogue entre le BPM d'intégration de données et le workflow documentaire ”
“ Parallèlement à Websphere Process Server, nous utilisons un workflow documentaire. S'appuyant sur l'association du portail Sharepoint et du moteur d'orchestration K2, il nous sert à élaborer et à valider des produits financiers. Process Server est exploité uniquement dans le cadre de la réconciliation de données ; à terme, il pourrait couvrir les processus de vente. Les deux types de BPM gagneraient alors à être intégrés. En cas d'échec d'une vente par exemple, Process Server seraient capable d'alerter Sharepoint/K2 du besoin de stopper, ou de modifier, le processus de conception du produit. ”
2 questions à… : Marc Boullier, directeur technique de Vistali
Les deux types de BPM sont-ils amenés à fusionner ?
“ C'est ce que nous prédisions il y a un an. Nous pensions, qu'à terme, un seul moteur de BPM pourrait non seulement guider les utilisateurs dans leurs procédures, mais aussi orchestrer les services techniques au niveau applicatif. Mais cette vision est difficilement réalisable. Car ces deux environnements répondent à des logiques et à des cycles de vie bien distincts. A titre d'exemple, le langage BPEL, utilisé par tous les grands de l'infrastructure, est parfaitement adapté pour les appels aux services techniques, mais répond mal aux interactions humaines. ”
En quoi, alors, se complètent-ils ?
“ Le BPM d'infrastructure, axé sur la motorisation des échanges interapplicatifs, agrège des services techniques pour présenter des services métier exploitables par le BPM au sens workflow. Adossé à l'infrastructure, le workflow profitera de l'actuelle vague SOA à travers, notamment, des applications composites. Plusieurs acteurs, dont IBM, BEA et Tibco, disposent de ces deux types de BPM. ”
