Comment intégrer des Progiciels dans une architecture d’entreprise ?

Le CEISAR organise une présentation sur ce thème, le mardi 14 juin à 18 heures dans les locaux du groupe AXA : 25 avenue Matignon, 75008 PARIS.

Le livre blanc, sera dévoilé à cette occasion...
Si vous souhaitez participer à cet évènement, n'hésitez pas à vous inscrire à l'adresse :

contact@ceisar.org

 à l'attention de M.

Pierre-Frédéric Rouberties
Center of Excellence in EnterprISe ARchitecture
Ecole Centrale Paris
www.ceisar.org


Extrait du livre blanc qui sera diffuser, à cette occasion
Les Entreprises font de plus en plus appel à des Progiciels, non seulement pour des besoins de Commodité, mais aussi pour des besoins Verticaux propres à leur secteur d’activité. Mais un assemblage de Progiciels indépendants pose des problèmes considérables de coexistence : duplication d’informations, usage hétérogène, synchronisation des évolutions de chacun, ressaisies d’information, difficultés à monter des offres mixtes…
- Quelles sont les recommandations qui peuvent être faites pour aboutir à une architecture de progiciels harmonieuse ?
- Que rôle le Cloud peut-il jouer ?
- Quelles sont les bonnes pratiques pour mettre en œuvre un Progiciel ?
- Quelles précautions doit-on prendre pour les versions successives du progiciel ?
- Comment réduire les couts d’installation de progiciel ?
- Comment faire évoluer le progiciel une fois qu’il est en place ?
....

Le CEISAR remercie tout particulièrement les acteurs suivants Pour leur contribution active à la fabrication de ce livre blanc :

• Afdel : Loïc Rivière et Stéphanie Jullien
• Air France : Laurent Mondemé, Francis Bailly
• Amadeus : Stéphane Tabary
• Axa : Hervé le Hen, Luc Morin
• Cegid : Florence Desprets, Jean-Louis Decosse
• Club des Pilotes de Processus : Didier Lejeal, Henri Chelli, Henri-Paul Soulodre, Pierre Dautet, Michel Verdun
• Conseils-Plus : Pierre Hugot
• ITN : Alain Dubois
• Logica : Emmanuel Pesenti
• Oracle : Didier Medal
• OR System : Anis Bada
• Renault (RCI Banque): Olivier Chagnou
• SAP : Thierry Pierre
• SFEIR : Didier Girard
• Stallergènes : Jean-Pierre Bouillaguet, Jacques Lelièvre
• Total : Bruno Bosquette
• W4 : François Bonnet
• Weave : Julien Soyer
• Wyde : Laurent Pytel

Système Informatique ou Système d’Information ?

Je discutais, samedi dernier, avec une personne de mes connaissances, « Project Manager Officer » de son état. Nous accompagnions nos enfants au conservatoire, pour la leçon de violon hebdomadaire. La discussion s’engage sur une de nos préoccupations communes du moment : Le projet X à quelques 4 milliard d’€ et des brouettes.
Au bout de 5 minutes, je demande à mon interlocuteur : - « Mais que signifie cet acronyme S.I. prononcé depuis le début, à plusieurs reprises ? La réponse quasi-automatique fut « Système d’Information, voyons » est pourtant, les mots employés dans un contexte non technique était: Machines, Serveurs, Protocole, Agents intelligents, Logiciels embarqués, allant jusqu’à une esquisse de mise en œuvre… Génial, … Oui mais … De quoi parle-t-on ? Système Informatique ou Système d’Information ?

Au risque d’enfoncer des portes ouvertes, Mes pairs urbanistes et autres architectes d’entreprise me pardonneront de me livrer, ici, à un exercice de pédagogie sur notre profession et les moyens, utilisés. N’est-ce pas là d’ailleurs, la véritable vocation de ce blog ?

Nous parlons probablement des deux, mais avec une imprécision flagrante liées au contexte, au projet, et aux limites des postures de chacun. L’architecte d’entreprise (appelé encore Urbaniste, ou Architecte fonctionnel) est au Système d’Information ce que les architectes techniques, les architectes applicatifs, et autre super architectes logiciels, sont au Système Informatique. C’est là, une première différence palpable entre les deux systèmes.

L’I.T. (Système informatique) est l’ensemble des actifs matériels et logiciels de l’entreprise ayant pour vocation à automatiser le traitement de l’information. C’est la partie visible à laquelle tout le monde pense quand on parle de projets et d’infrastructures informatiques. On y inscrit également la R&D, l’innovation technique, et toutes les techniques d’optimisation. Pour résumer, le logiciel, le serveur qui va bien et les écrans...

Le S.I. (Système d’information) est l’ensemble des actifs de l’I.T. (matériels et logiciels, forcement référencé quelque part) mais comprend aussi et surtout, les actifs humains et immatériels, les procédés, procédures, et processus, d’industrialisation, sur lesquels on les affecte, les informations de niveau sémantique, organisationnelle, et de structure, dites « Amont ».

Question : À quelle famille d’actif, peut-on associer la flotte de véhicule bleue d’EDF ?
La réponse est très simple, au premier abord, mais mérite d’être nuancée. Elle n’intervient à priori pas dans l’automatisation de tel ou tel service déployé, Son usage est manuel, et elle n'interagit à priori qu'avec son chauffeur ; donc on peut facilement comprendre que l’actif en question ne sera pas manager par une direction informatique. Est-ce pour autant un actif du Système d’Information ?

Analysons :
- Existe-t-il un ou plusieurs documents référençant ma camionnette bleue ?
- Ces documents montrent-ils une interaction avec un acteur identifié de l’organisation ?
- Peut-on trouver un premier niveau de formalisme d’un procédé ou mieux d’un processus d’entreprise intégrant ma camionnette bleue et son chauffeur ?
Une réponse négative à ces questions et fin de l’histoire : le véhicule est réduit à un actif comptable à amortir, et c’est sa seule existence dans le S.I.
Une réponse positive à ces questions permettrait d’induire que la camionnette est bien une ressource saillante dans le Système d’Information, en plus du système comptable, et contribue, dans une ou plusieurs tâches identifiées, à produire de la valeur.
- Puis au détour d’un autre processus métiers lui, parfaitement modélisé, on se rend compte, qu’un message entrant fait acte du nom du chauffeur, de la plaque d’immatriculation du véhicule, de la durée d’intervention et du kilométrage. Tiens Tiens, Ma fameuse camionnette bleue serait elle un objet métier, prompt à faciliter ma compréhension des processus et de leur interaction et/ou à automatiser un système futur ?
- Puis la direction générale, dans un communiqué historique, affirme son intention de réduire les coûts d’intervention, en prévoyant mieux les révisions ateliers des véhicules bleus. Là le faisceau d’information permet clairement de le considérer comme un objet métier, et donc un actif du SI, qui risque de prendre de plus en plus d’importance dans les processus à venir.

- 10 ans plus tard, le petit véhicule bleu, n’est plus bleu. Il n’a plus de chauffeur, il est truffé de logiciels dont une partie est stratégiquement développée en interne, et l’autre par un prestataire prestigieux. Il interagit en temps réel avec une base centrale de données, à l’aide d’un protocole non connu 10 ans plus tôt. Sa promotion dans plusieurs processus métiers, a été un facteur concurrentiel de développement déterminant, permettant de rendre l’activité non seulement durable dans le temps, mais rentable. Et oui, L’architecte d’entreprise est un homo économicus, du développement durable…
- Le suivi et la modélisation du SI a permis 5 ans auparavant, de faire une fusion acquisition gagnante avec cette société si brillante dans le développement de logiciels embarqué, comblant le vide fonctionnel que l’architecte d’entreprise avait détecté suite aux intentions de la DG.
- La DG (qui n’est pas frileuse) avait anticipée cela 10 ans plus tôt avec l’aide de son architecte d’entreprise.
- Les moyens utilisés pour « bâtir »sont tout simplement « la modélisation ». Cette discipline, empruntée à l’ingénierie des systèmes, et aux techniques de modélisation « objet » permet d’allier formalisme et rigueur, dans les différentes projections, transformation, et dérivation de modèle opéré pour bâtir un ouvrage stable dans le temps. Les procédés et les réflexes de modélisation sémantique, par exemple, sont sensiblement, les mêmes que ceux de la modélisation des données : Ce sont les objets eux-mêmes, qui diffèrent, ainsi que leurs dépendances. Si l’on comprend la différence entre Mathématiques et Physique appliquée, Alors par transposition respectivement sur SI et I.T., ou sur Concepts et data, les différences sont semblables…

Conclusions partielles :

- Le S.I. offre un outil, à moyen et long terme, pour se projeter, dans l’avenir, en captant la stratégie de l’entreprise, en la projetant et en la décomposant afin de faciliter l’alignement de solutions économiquement viables et durables.
- L’I.T. est une image fidèle du système informatique opérationnel, actuel, lui-même une réponse concrète et économique, des visions stratégiques précédentes, et dont la responsabilité des managers et de rendre son usage aussi fluide, agile, et utile que possible… et la tâche n’est pas simple.
- Le mode projet devrait intervenir sur une vision à maturité du SI de demain, de façon à permettre la transition. Un projet peut donc être considéré comme une transition entre l’IT d’aujourd’hui et l’IT de demain, avec une date de début, une date de fin et un objectif « SMARTE »
- Tout actif matériel a vocation à abonder le SI. L’adéquation économique et technique en fera peut être un actif de l’I.T. dans la vision stratégique, puis concrétisé dans un projet.
- Il est de plus en plus évident que l’adéquation économique anticipée doit prendre immédiatement en compte la composante énergétique comme la future grosse contrainte qui nous attend ; Le seul problème dans cette affaire, est que « tous les dirigeants aujourd’hui naviguent à vue »

Voici donc exposé, sous forme ludique, la différence fondamentale entre une démarche SI et son pendant I.T. Les frictions qu’il existe parfois entre les deux mondes à vocation plus complémentaire que concurrente, en découlent directement, les uns étant taxé de « philosophe aux théories fumeuses », les autres, de tekkos aux cheveux long et aux idées courtes.
Ma position personnel en tant qu’architecte d’entreprise est la suivante : Le respect et l’écoute des uns et des autres est une composante fondamentale pour agir consensuellement, chacun à sa place :
- Collègues et Amis Architectes, chaque fois que votre interlocuteur, vous dira : « Euh c’est trop technique », il est probable qu’en réalité, il n’ait rien compris à ce que vous lui disiez, et pour garder la tête haute, il botte en touche.
- Collègues et Amis MOA, chaque fois que votre interlocuteur, vous dira : « Euh, Pourquoi vos besoins ressemblent-ils à des spécifications détaillées », c’est que probablement vous ne travaillez pas avec des architectes d’entreprise, challengeant ce qu’il y a de meilleur en vous : La vision d’avenir et la compréhension des métiers. Pas la solution.

Je continue de penser que pour être innovant et riche, l’architecte technique a fondamentalement besoin d’une vision mature et de besoins clairement exprimés, par les urbanistes et les MOA. L’innovation, a besoins de garder son âme d’enfant, car un enfant est détaché des contraintes et des habitudes dont certaines devront être remises à plat. Les architectes d’entreprise, même si là n’est pas leur vocation, savent aussi écrire une requête SQL optimisé, connaissent la différence entre une variable, statique et d’instance, un pointeur et une référence. Ils savent développer dans leur langage favori, mais ils sont plus utiles encore à faire ceci.

BRMS : L'intérêt

Du décideur qui impose au plus 2% de risque pour l’année en cours, ou 15% de pénétration de marché, à l’attaché commercial, qui applique consciencieusement les préconisations d'un processus métier devenu Intelligent, tout le monde est concerné par le Business Rule Management.

Le "Business Rules Management" est le bras armé, le levier "tactique", du décideur qui trouve l'opportunité enfin de naviguer autrement qu'à vue dans son écosystème que la concurrence tisonne.
A partir d'une vision gagnante aussi appelé "Stratégie" le décideur verra son beau discourt suivi au plus prés, par ses équipes opérationnelles, auxquelles il assigne le devoir de résultat et le sens de la marche. La mise en œuvre, donc, de la stratégie d'entreprise, est largement assurée par une solution automatisée de gestion des règles métiers: Le BRMS... Mais comment est-ce possible ?

Comment fait-on pour qu’une décision commerciale, une décision de limitation de risque, ou une décision de crise, soit mise en production et appliquée uniformément sur toute la juridiction concernée (France, Internationale), en seulement 2 jours, test compris ?
On met en place une organisation du type « BRM »

Comment fait-on pour suivre scrupuleusement des objectifs à long terme, énoncés par la DG, et expliqué les écarts, de façon certaine (en moyenne)?
On met en place une organisation du type « BRM»
Appelons cela, de l’agilité opérationnelle, piloté par les lignes métiers.

Chaque fois que l'on peut identifier dans un processus, les caractéristiques suivantes, alors il faut sérieusement regarder de près une solution de type BRMS:

1. Je dispose de beaucoup de règles métier.
2. Elles sont complexes.
3. Elles sont fréquemment modifiées.
   

Leur mise en place, en particulier dans les domaines du crédit, de la finance, de l'assurance, ou des télécom, peut s'envisager sereinement dès lors que :

1. L’organisation opérationnelle sépare distinctement expert métier et cellule technique.
2. La définition des rôles d’expert est claire,
   
3. et la stratification des domaines de règles, est précise,

Alors les conditions seront réunies, pour simplifier la mise en œuvre.


Cela permet d'avoir une démarche durable avec :

1. des gains concurrentiels de développement économiques induits,
2. de l’agilité structurelle pour l’application d’une politique économique (Arbitrage Risque vs gain de part de marché)
3. une organisation spécialisée, capitalisant sur ces règles métiers,
4. la nécessité de les pérenniser au-delà du stockage en matière grise.

BRMS : La troisième dimension

La Gestion automatisée des Règles Métier, (Nos amis anglophones parlent de Business Rules Management Solution) est l'un des axes fort qu’il reste à explorer par les grands acteurs du marché, pour poursuivre l’indispensable quête d’agilité de leur SI. Après le BPM et le MDM place au BRM.

Le BRMS puise fondamentalement ses racines dans la mouvance des Systèmes Experts exploités avec un succès très relatif en France et dans le monde, à partir des années 1995, sur fond d’Intelligence Artificielle. Mais le BRMS, c’est beaucoup plus qu’un moteur d’inférence et ses services techniques (compilation du langage pseudo naturelle en expertise formelle, génération du code de la dite expertise, …) Le BRMS dispose d’un véritable référentiel de connaissances où se greffent une multitude de service transverses profitables aux métiers. De plus, il définit clairement la granularité de réutilisation des règles qui n’existaient pas dans les SE. (Les architectes d’entreprise le savent bien, dans notre métier, tout ou presque, est question de granularité). En outre, le BRMS automatise la chaîne transverse, d’industrialisation des règles entre les acteurs IT et métiers avec une meilleure synergie entre les équipes.

Sur le schéma ci-dessus, on distingue en bleu un macro processus composé de sous processus métier en chaîne. En transverse (marron) on représente les expertises distinctes prompts à paramétrer un processus. Un processus peut disposer de plusieurs expertises possibles. Les règles d’une expertise sont mutualisées au sein d’un référentiel.

Le BRMS simplifie donc, les processus, ré-agence les procédures, aux bénéfices des métiers et des MOA. Sans gouvernance globale de la règle, motivée par des sponsors du métier, les bienfaits d’une gestion automatique à la portée des métiers, ne viendront pas.
Enfin on peut dire que le BRMS est le retour d’une bonne idée. Et que les cabinets de conseils sont en train de prendre en compte, cet ultime axe d’agilité pour peaufiner leur offre actuelle de gouvernance.

Aujourd’hui mon constat sur l’adoption des BRMS est le suivant :
1. Les entreprises françaises qui depuis 15 ans gagnent avec leur SGRM ne sont pas très nombreuses. Quand elles réussissent à mettre en place cette technologie, elles ne s’en vantent pas « Vivons heureux, Vivons cachés » pour ne pas risquer d’attiser la concurrence, sur cette excellente solution. Les Systèmes Experts et autre moteurs à règles de calcul ont été pour ses entreprises, un facteur concurrentiel de développement très important. Elles devraient pouvoir passer au BRMS sans trop de difficultés, d’un point de vue technique. Reste l’optimisation de leur processus métier encore parfois trop teintés de technicités informatiques.
2. La technologie est là. Elle est mure, elle fonctionne très bien, et les éditeurs ont du talent à revendre. Les solutions packagées, proposées sur le marché sont diverses, et se distinguent soit par l’abondance de services intégrés, soit sur des aspects très spécialisés dans le domaine des sciences et de la défense. Tantôt la solution se présente comme une offre globale, et parfois comme un système pointu accompagnant l’expert dans son travail.
3. Les majors du conseil et de la gouvernance des SI, anticipent tous l’explosion des solutions BRMS, dans les 2 à 3 prochaines années.
4. Les entreprises qui ont investi et gagné hier, avec leur système expert propriétaire, sauront-elles rester leader, en regardant entre autre les évolutions considérables que les BRMS modernes apportent par rapport aux moteurs de règles d’hier. (Voir le billet sur la DSI en équation)
5. Par ailleurs, on distingue aussi dans le paysage, des entreprises qui ont essayé et qui ont échoué. Celles-ci ne s’en vantent pas non plus. Elles se contentent d’affirmer à tort : « On a déjà essayé, ça ne marche pas ???

Avant toute chose, il faut tordre le coup à ce type de réponse, qui malheureusement a contribué à faire prendre tant de retard, dans un pays où l’intelligence n’est pourtant pas qu’artificielle. Les deux raisons que j’ai pu constatées pour justifier cet état de fait sont :
- D’une part, la frilosité des décideurs touchés par le syndrome de St Thomas. « On attend de voir pour y croire » Du coup on se contente de demander à l’IT de faire des POC pour « Analyser le potentiel de la solution » Humm Potentiel de quoi et Solution à quel besoins ? C’était mal parti ; Cela ne pouvait pas aboutir. Les acteurs bénéficiaires et contributeurs ont été mal identifiés dès le départ.
- D’autre part, l’offre des éditeurs de solutions, bien qu’excellentes, a eu du mal à trouver son marché. Vendre des licences de logiciel n’est pas suffisant. Cette grande assurance qui a acheté un produit BRMS en pointe, qui est resté au placard, cette autre banque de détails, qui a mis en œuvre une solution BRMS sur un pricer et qui court toujours derrière son ROI, faute de s’être trompé de cible.
Il faut l’accompagnement d’un acteur d’expérience, et neutre, pour comprendre les besoins, les challenger, et améliorer la configuration organisationnelle des métiers, avant de s’engager sur la solution. C’est le rôle des cabinets de conseil. De plus si le BRM est en lisse pour émerger enfin, Cela vient du fait que les efforts se soient d’abord portés sur la cartographie des processus métiers (BPM), et la gestion des données de référence (MDM).

Place désormais aux BRM.
Alors… Ou en êtes vous dans vos règles métiers, et est-ce que ça « Rule » pour vous ?

BRMS : L'ordre d'un Système Expert

En informatique de gestion l'expérience prouve que la grande majorité des problèmes d'aide à la décision peuvent être résolus à l'aide d'un moteur à règles de calcul d'ordre 0+.
Il s'agit d'un très bon compromis permettant d'allier facilité de maintenance, et suffisance du raisonnement.

Mais, que signifie ordre 0+ ?

Commençons par expliquer ce qu'est un SE d'ordre 0.
Les plus simples des systèmes experts s'appuient sur la logique des propositions (dite aussi « logique d'ordre 0 »). Dans cette logique, on n'utilise que des propositions booléennes. Pour des déductions du monde réel, on obtient un système expert très verbeux, et peu paramétrable.
Par exemple, "Age=36 ans" représente un et un seul mot insécable qui est vrai ou faux.
Soit A la proposition : "Le client a 36 ans. Pour exprimer dans un règle d'octroi par exemple, le fait que tous les clients ayant entre 18 et 78 ans, sont éligibles il faudra écrire une règle de quelques 60 clause séparée de OU logiques. Chaque proposition est initialisée à FAUX, et il suffit qu'une des 60 propositions, soit valorisée à VRAI pour que la règle soit VRAIE. Pas très passionnant :-) ...

Les SE d'ordre 0+.
C'est là que l'on appréhende maintenant l'intérêt d'un système logique d'ordre 0+ dans lequel il est possible de paramétrer des propositions logiques. La logique d'ordre 0+ contient des opérateurs de comparaison (>, <, =, >=, <= et <>), des valeurs comparables, des constantes, des énumérations permettant de définir l'ensemble de définition d'une variable.
Ainsi la règle d'octroi précédente devient : SI AGE > 18 ET AGE <=78

Et les SE d'ordre 1.
D'autres systèmes experts s'appuient sur la logique des prédicats du premier ordre (dite aussi « logique d'ordre 1 »). Cette logique fait intervenir des quantificateurs de type "POUT TOUT x" ou encore "QUELQUE SOIT x" x étant une variable prédicative de classe X.
Un raisonnement en logique d'ordre 1 permet de faire des miracles de déduction. Cependant un système expert de 500 règles (de taille moyenne) est difficile à maintenir par la dite population NI INFORMATICIENNE, NI MATHÉMATICIENNE.

En effet en logique d'ordre 1, Gödel démontra en 1931 deux résultats mathématiques :
• Il se peut que dans certains cas, on puisse démontrer une chose et son contraire (théorème d'inconsistance).
• Il existe des vérités mathématiques qu'il est impossible de démontrer (théorème d'incomplétude).