Le management du digital
Rechercher

Jean-Michel Detavernier, DSI adjoint de la Smabtp : « Notre patrimoine informatique sera constitué à plus de 65 % de référentiels et de règles. »

Si la SOA est indispensable pour mener une refonte de système d’information, elle n’est pas suffisante. Une méthode d’entreprise s’avère indispensable pour la modélisation des besoins. Précurseur dans cette approche, avec la méthodologie Praxeme, le groupe d’assurances Smabtp a entièrement refondu son système d’information.

BPSI Pourquoi avez-vous entièrement refondu votre système d’information ?

Jean-Michel Detavernier Le groupe Smabtp gère des contrats avec des clients de taille variée, allant des artisans du bâtiment jusqu’aux clients du BTP, qui traitent des opérations portant sur plusieurs millions d’euros. Mais, historiquement, le système d’information était structuré en silos fonctionnels selon le principe « une chaîne de traitement par produit ». Il était donc indispensable de faire évoluer le système d’information, ne serait-ce que pour des questions de réactivité métier et d’optimisation de la maintenance. En 2001, la direction générale de la Smabtp a ainsi décidé la refonte du système d’information, après un essai infructueux avec un progiciel. L’objectif était de s’aligner sur les décisions stratégiques, reflets des attentes des clients, par exemple pour proposer des services de tarification, d’établissement et de gestion des contrats, ainsi que pour le recouvrement des primes et la gestion des sinistres. Il s’agissait d’un chantier sur plusieurs années, ce qui supposait de faire cohabiter les anciens et les nouveaux systèmes informatiques, qu’ils soient internes ou externes. Cette cohabitation a été rendue possible en mettant en place des infrastructures d’échanges de données entre ces différents systèmes.

BPSI Quelle démarche avez-vous retenue ?

Jean-Michel Detavernier Nous avons privilégié une démarche d’urbanisation et de SOA. La première phase a consisté à adopter une approche de type « bottom-up », avec cette urbanisation du SI et l’installation des logiciels d’infrastructure et de communication entre « domaines fonctionnels ». Nous avons également mis en évidence les services technico-fonctionnels tels que l’éditique, le workflow, le moteur de règles, les EAI (Enterprise Application Integration) et l’outil de présentation. Les échanges entre les domaines s’effectuent avec des flux normalisés à travers un outil d’EAI, avec des messages XML. Nous avons ainsi isolé un domaine fonctionnel critique correspondant à une valeur ajoutée stratégique pour l’entreprise : la production de contrats qui, à l’époque, pouvait prendre jusqu’à trois jours pour une offre nouvelle, du fait de l’enchaînement des tâches et des traitements batchs qui étaient imposés par le système. En outre, UML a été adopté comme outil de modélisation et XML pour les échanges entre domaines. Cette phase permet de mettre en place l’infrastructure et, également, de délivrer de la valeur métier en fluidifiant les processus autour de plusieurs SI (y compris ceux des partenaires). Plus précisément, les avantages métiers de cette première étape résident dans la suppression des doubles saisies entre les différentes applications, une amélioration des échanges entre partenaires, une meilleure fluidité des processus, une éditique mieux adaptée aux processus de travail et une présentation davantage intégrée des applications au niveau du poste de travail. Très rapidement, les utilisateurs ont demandé à améliorer le portail pour les gestionnaires de contrats, afin de présenter, de façon harmonisée, les données provenant des différents systèmes d’information, l’objectif restant d’atteindre une vision unifiée du client et de ses différents dossiers (contrats, sinistres, recouvrement...).

Cette première phase a également eu d’autres avantages. D’abord, elle a permis d’occuper le terrain vis-à-vis de la maîtrise d’ouvrage. Ainsi, huit mois après le lancement du projet, nous avons pu livrer un nouveau contrat d’assurance. Cette période a également permis la formation du personnel en place aux grands standards (UML, XML, urbanisation, services réutilisables). Côté outillage, la mise en place de l’infrastructure nécessaire (EAI, ESB...), l’utilisation d’outils d’agilité de type MDM (Master Data Management) et BRMS (pour exposer les paramètres et les règles directement aux utilisateurs) a permis la création d’une structure flexible qui transforme les existants informatiques en services réutilisables, liés ensemble par des messages. Dans le cas d’applications nouvelles comme la gestion des règlements (traitements des sinistres), qui a été complètement redéfinie en 2003 avec une approche UML/SOA et Java, les développements tirent profit du socle mis en place autour des règles, de l’EAI, de l’éditique et de la mise en place d’un MDM générique capable de traiter toutes les données de référence et de paramétrage au-delà de la configuration des produits déjà en place. Le MDM utilisé est celui de la société Orchestra Networks, EBX. Platform.

Cela dit, cette première phase nous a appris que les services existants ne sont pas nativement réutilisables ! Ainsi, les services fournissent les capacités d’accès aux applications « legacy » ou aux ERP, les applications et données de l’entreprise sont accessibles au travers d’un ensemble de services, et les données sont également accessibles par l’ESB ou l’EAI, mais, en termes de réutilisation, est-ce que ces services peuvent s’adapter facilement à différents contextes (pays, langue, législation, processus, structure, organisation, profils d’utilisateurs, produit, client, partenaires...) ? Quel est le prix des aménagements des programmes ? Comment séparer ce qui est dynamique de ce qui est statique ? En toute logique, l’étape suivante consiste à créer des nouveaux services métiers nativement agiles. Ces questions ont été traitées d’abord avec une SOA de surface (voir encadré page 4) non intrusive sur l’existant. Dans ce cas, on reste très dépendant de la qualité de son patrimoine informatique et il n’y a pas de changement réel dans la manière d’accéder aux fonctions du système d’information. Il s’agit de créer des services au-dessus des systèmes existants, ce qui procure un premier niveau d’intégration... mais avec certaines limitations ! On peut en identifier trois : d’abord, une rupture ergonomique dans la réutilisation de différents services d’un contexte à l’autre (cas du revamping simple), ensuite, un coût de changement des applicatifs existants et, enfin, un coût du réhabillage si l’on crée de nouveaux connecteurs.

Il est toutefois possible d’améliorer l’agilité des services existants par l’externalisation des règles métiers dans un outil de type BRMS (Business Rules Management System), en l’occurrence JRules d’Ilog, ainsi que par l’externalisation et la centralisation des paramètres dans l’outil de MDM. Par exemple, nous avons profité de l’introduction du nouveau système de gestion des contrats pour externaliser les règles de gestion dans le système de gestion de règles d’Ilog, passage rendu possible par un travail en amont sur l’échange de messages en XML avec l’outil EAI. Concrètement, les interactions entre l’applicatif de gestion des contrats et le moteur de règles se traitent par des messages XML qui découplent les deux systèmes. La deuxième étape a correspondu à une reconception d’une partie conséquente du système d’information. D’une part, avec une approche technologique (modification de l’infrastructure et des programmes, intégration du moteur de règles, du MDM et du BPM dans architecture existante, révision de quelques processus). D’autre part, avec une approche métier : définition d’une méthodologie de conception, approche MDA (Model Driven Architecture), prise en compte dès la conception de l’externalisation des paramètres et des règles. La MDA (nous avons utilisé l’atelier de développement Objecteering) et le framework jouent un rôle considérable dans la mesure où le framework capitalise l’expertise technique, les choix techniques sont isolés, peuvent évoluer indépendamment des modèles logiques et les développeurs sont dispensés de connaissances techniques approfondies. L’approche retenue est la méthode Praxeme, méthodologie d’entreprise qui regroupe les procédés nécessaires à la conception d’une architecture de services.

BPSI à quoi sert d’utiliser un moteur de règles ?

Jean-Michel Detavernier Les objectifs sont multiples. Il s’agit d’abord de simplifier l’écriture de programmes comportant de nombreuses règles simples et/ou quelques règles complexes, de traduire en français des règles informatiques. Ensuite, avec une documentation native des règles de gestion, l’analyse d’impact devient plus simple, ainsi que l’auditabilité. Les charges et les délais de mise en œuvre des demandes de la maîtrise d’ouvrage s’en trouvent diminués. Enfin, on bénéficie d’une augmentation de la réutilisation des composants (un jeu de règles par partenaire pour le même composant informatique), ainsi que d’une centralisation des règles métiers (référence unique des règles, cycle de vie des règles indépendant de l’interface graphique). L’exécution des règles est pilotée par les données. Quatre ans après le démarrage, nous gérons 2 000 règles avec 350 tables de paramétrage. Concrètement, après quatre années d’enrichissement du référentiel de règles, la maintenance des programmes et les règles constituent le vecteur principal de connaissance du fonctionnement du SI. Nous avons investi pour externaliser les règles métiers et le paramétrage des actes de gestion, à partir du code existant et pour tout nouveau projet. à terme, le patrimoine informatique sera constitué à plus de 65 % de référentiels et de règles, contre moins de 10 % lorsque nous avons démarré. Cela suppose d’accompagner ce changement, non seulement au sein de la DSI, mais également dans les directions métiers, pour communiquer sur le fonctionnement du système d’information. Nous avons développé un framework qui facilite et rend systématique la création et la maintenance des services de règles. Il concerne les points suivants : gestion des flux, appel des services de règles, architecture interne du serveur de règles, mécanismes de tests unitaires interactifs et automatiques côté serveur, gestion normalisée des erreurs... Ce framework a été utilisé dans le développement des services de règles pour Gestion Souscripteurs et pour le benchmark JRules, dans le cadre du pilote.

BPSI Quelles sont les prérequis pour l’utilisation d’un moteur de règles ?

Jean-Michel Detavernier L’intégration du moteur de règles dans une application nécessite plusieurs éléments : la définition d’une interface d’invocation des règles, l’alimentation des données à passer au moteur de règles et le traitement des résultats produits par l’exécution des règles. Lorsque les règles s’appuient sur un flux XML, il faut générer et relire ce flux. En termes de compétences, l’intégration de moteurs de règles dans une application nécessite une bonne connaissance de l’architecture fonctionnelle et technique de l’application, du modèle de données de l’application, la capacité à produire et à relire du flux XML le cas échéant et une bonne connaissance des technologies d’intégration éventuellement utilisées, MQSI (MQSeries Integrator) par exemple. Concernant les tests des règles, la validation des règles s’effectue au niveau fonctionnel et des performances, ainsi qu’à travers la définition de jeux de tests qui spécifient les données en entrée, les règles à invoquer et les résultats attendus. Au-delà des jeux de tests proprement dits, les tests des règles nécessitent également le développement de l’application de tests. Concernant la gestion de projet, il s’agit de favoriser une approche pragmatique à travers le découpage du projet en phases relativement courtes (un à trois mois), chacune avec ses objectifs en termes de cas d’utilisation, de règles à mettre en œuvre, d’architecture d’exécution et de tests de validation. De même, je conseille de former une équipe projet dont les profils couvrent les compétences requises pour la mise en œuvre des étapes, de favoriser une bonne communication entre les parties prenantes du projet et de contrôler de façon continue la progression de la réalisation de chacune des étapes.

BPSI Quel bilan tirez-vous aujourd’hui ?

Jean-Michel Detavernier Grâce à la nouvelle architecture, le métier de l’entreprise a fortement évolué au quotidien : les temps de traitement d’un contrat ont fortement été diminués. Les possibilités de gestion des contrats et des sinistres ont été améliorées, intégrant parfois des services externes de façon transparente. Le résultat est que la satisfaction des utilisateurs, sociétaires et partenaires de la Smabtp s’est accrue, au fil des étapes de cette refonte. En outre, et ce bénéfice n’est pas le moindre, les générations futures d’informaticiens hériteront d’un outil et d’une manière de faire qui simplifiera l’appropriation des connaissances. En effet, la complexité technique étant réduite à sa plus simple expression, le système d’information pourra continuer à évoluer de façon parallèle au métier de l’entreprise. L’une de nos chances est que nous n’avons pas eu besoin de « vendre » cette refonte à la direction générale, qui nous a fait entièrement confiance. C’est le grand challenge pour les DSI : convaincre leur direction générale. Nous travaillons d’ailleurs, au sein de la communauté S-IT-A (Sustainable IT Architecture), pour formaliser les meilleurs arguments utilisables par les DSI...

Les éléments de la chaîne d’agilité ACMS (Agility Chain Management System)
MDM
Master Data Management
BRMS
Business Rules Management System
BPM
Business Process Management
  • Rationalise la gestion des données de référence et des paramètres.
  • Permet la mise en place de modèles de paramétrage des services afin de contextualiser leur exécution.
  • Les règles exploitent les données de référence et les paramètres.
  • Les pré- et post-conditions des services organisationnels sont situées dans le système de gestion de règles.
  • Les processus utilisent les règles pour la conduite des étapes.
  • Les services orchestrés sont contextualisés par le MDM et le BRMS.

Pour en savoir plus :

www.praxeme.org

Le Système d’information durable, la refonte progressive du SI avec SOA, par Pierre Bonnet, Jean-Michel Detavernier, Dominique Vauquier, Hermès Lavoisier, 2008, 313 pages.

Best Practices propose des publications payantes.
Comparez nos différentes offres d'abonnement.

La rédaction

La rédaction

La rédaction de Best Practices fédère les meilleurs experts sur le management des systèmes d’information.

Nos Ouvrages

  • Symposiums Gartner Rétrospective 2017-2021

    Les équipes de Best Practices assistent chaque année au Symposium organisé par le cabinet Gartner qui présente des études, ses analyses et ses opinions sur l’évolution des technologies, du digital et des systèmes d’information.

  • Benchmark Digital&Business - numéro 157

    Ce numéro de Benchmark Digital & Business regroupe l’essentiel des chiffres et des tendances présentés lors du Symposium Gartner 2021, qui s’est déroulé en novembre, à distance.

  • Benchmark Digital&Business - numéro 156

    Ce numéro de Benchmark Digital & Business regroupe l’essentiel des chiffres et des tendances présentés lors du Symposium Gartner 2021, qui s’est déroulé en novembre, à distance.

A ne pas manquer

  • Comment rater...
sa Data Integration

    Pour rater son intégration de données, rien de plus simple. C’est à la portée de toutes les entreprises ! Il suffit de suivre nos treize commandements et d’oublier la gouvernance, la qualité, la sécurité et les enjeux métiers.

  • Comment rater...
sa génération de leads

    Il existe un lien étroit entre le dynamisme commercial d'un éditeur de logiciels ou d'un intégrateur et la qualité des leads dont disposent les commerciaux pour maintenir leur performance. Mais il est très facile de ruiner votre performance commerciale.

  • Comment rater...
sa stratégie Big Data

    Une stratégie Big Data ne s'improvise pas. Quoique... Ce nouveau titre de la collection "Comment rater..." propose les douze commandements pour tous ceux qui veulent vraiment rater leur stratégie Big Data.

Best Practices

Informations

REMARQUE ! Ce site utilise des cookies et autres technologies similaires.

Si vous ne changez pas les paramètres de votre navigateur, vous êtes d'accord. En savoir plus

J'ai compris