I LA RÉFÉRENCE TECHNIQUE ON-LINE DES PROFESSIONNELS DE … · développer des savoir-faire ou des...

ITLA RÉFÉRENCE TECHNIQUE ON-LINE DES PROFESSIONNELS DE L'INFORMATIQUE

n°87

Bim

estr

iel -

sep

tem

bre

/oct

ob

re 2

010

Projets BPM : les questions clés à se poser

Le moteur de règles au cœur de l’agilité du SI

Vers une qualification fonctionnelle efficace des applications SAP

Une charte pour réussir la mise en œuvre de vos processus SI

Le MDM multidomaine : une vision à 360°

Cycle de vied'une opération d'Outsourcing

Suivi de proje

t Contrôle des coûts

Transfert de connaissances

Fin de

contrat Appels d'offres

Rece

tte te

chni

que

EditeurPress & Communication FranceUne filiale du groupe CAST3, rue Marcel Allégot92190 Meudon - FRANCETél. : 01 46 90 21 21Fax. : 01 46 90 21 20http://www.it-expertise.comEmail : [email protected]

Rédacteur en chefJosé DizEmail : [email protected]

Directeur de publicationAurélie MagniezEmail : [email protected]

Abonnements/PublicitéEmail : [email protected]

Conception GraphiqueNicolas HerlemEmail : [email protected]

ParutionIT-expert - (ISSN 1961-9855) est un journal édité 6 fois par an, par P&C France, sarl de presse au capital de 60 976,61 e.

AvertissementTous droits réservés. Toute reproduction intégrale ou partielle des pages publiées dans la présente publication sans l’autori-sation écrite de l’éditeur est interdite, sauf dans les cas prévus par les articles 40 et 41 de la loi du 11 mars 1957. © 1996 P&C France. Toutes les marques citées sont des marques déposées.Les vues et opinions présentées dans cette publication sont exprimées par les auteurs à titre personnel et sont sous leur entière et unique responsabilité. Toute opinion, conseil, autre renseignement ou contenu exprimés n’engagent pas la responsabilité de Press & Communication.

Abonnements01 46 90 21 21

Vous pouvez vous abonner gratuitement sur http://www.it-expertise.com/

ITLA RÉFÉRENCE TECHNIQUE ON-LINE DES PROFESSIONNELS DE L'INFORMATIQUERéseau social ? Tu parles !

Ah les réseaux sociaux… Merveilleux vocable marketing : comment refuser le social, le groupe ? Hors Facebook point de salut ! Il faudrait même que toute entreprise en déploie pour attirer les jeunes talents (qui apprécient aussi les baladeurs MP3.). Ils réclament surtout du travail ! Pour d’autres, ils favorisent une communication subitement har-monieuse !? Les réseaux sociaux professionnels seraient plus pertinents. Et pour qui ?…

En revanche, exposer l’image de l’entreprise via ces outils peut s’avérer nuisible. Et les exemples se multiplient. Sans parler des confusions entre vies personnelle et professionnelle qui posent déjà problème… Par ailleurs, afficher ses meilleurs éléments dans un espace public semble une pratique bien étrange pour conserver des talents. Enfin, comment des cadres surchargés trouvent-ils le temps de mettre en ligne plusieurs photos par jour et de deviser si longuement ! Et nous resterions les employés les plus productifs d’Europe ? Quels gisements inexploités…

La technologie, toujours intéressante, n’est pas en cause. Il s’agit plutôt de la vacuité qui absorbe autant de temps et d’argent pour si peu dans les entreprises. Souvent via le conseil de seniors qui n’utilisent même pas ces outils… On a connu ces engouements avec les pages Web, puis avec les blogs en entreprise… Heureusement, les employés ont chaque fois constaté le peu d’intérêt de ces gadgets chronophages. À bon entendeur…

José DizRédacteur en Chef

édito

4 IT-expert n°87 - septembre/octobre 2010

5IT-expert n°87 - septembre/octobre 2010

IT-expert n°87 - septembre/octobre 2010

6 DossierProjets BPM : les questions clés à se poserLes entreprises ont pris conscience de l’intérêt d’identifier et de maîtriser leurs

processus métier. Quelques considérations s’imposent avant de s’aventurer dans de

tels projets. Jean Cadeau, spécialiste de ses questions, propose son éclairage sur un

chemin parsemé d’embuches.

12 TechniqueLe moteur de règles au cœur de l’agilité du SIL’efficacité des SI repose de plus en plus sur des moteurs de règles (d’accès, métiers,

de gestion…). À l’heure de l’automatisation et de la virtualisation, Guilhem Delebecque

(architecte-urbaniste chez Sopra) explique le fonctionnement et l’intérêt de ces

technologies pour le système informatique.

16 Actualités InternationalesLes informations marquantes d’éditeurs, de marchés, d’organisme de standardisation, de débats en cours et de tendances.

20 Comment ça marche ?Vers une qualification fonctionnelle efficace des applications SAP « La phase de qualification constitue une étape critique pour la maîtrise du risque

fonctionnel et la satisfaction des utilisateurs » expliquent les auteurs du dossier. Après

l’exposé des enjeux de qualification, ils démontrent comment cette étape majeure

influence la qualité, la réactivité et la réduction des coûts.

28 Quoi de neuf docteur ?Une charte pour réussir la mise en œuvre de vos processus SI Déployer des applications, réduire les coûts, optimiser les processus… De nombreux

défis pour les DSI chargées aussi de conduire le changement. Plan qualité, Cobit, ITIL,

CMMi… quelles que soient les pratiques des « chartes » apparaissent au sein des DSI

pour favoriser l’appropriation des processus. Explications et mode d’emploi.

35 LivresLean Management - Mieux, plus vite, avec les mêmes personnes de Pierre Pierrazzi

et Le management de la continuité d’activité d’Emmanuel Besluau.

36 Rubrique à brac Le MDM multidomaine : une vision à 360°La qualité des données devient enfin la préoccupation majeure des DSI. Comment

travailler correctement sans une information fiable ? Directeur technique chez Informatica

France, Bruno Labidoire retrace l’évolution des solutions jusqu’au MDM multidomaine.

Un article à lire et à relire avant de choisir.

Sommaire


Les projets visant à dématérialiser la gestion des documents et des processus métiers deviennent de plus en plus fréquents

dans les entreprises. Les motivations sont multiples : faciliter le travail collaboratif, le partage et la circulation des

informations ou documents, réduire les coûts, améliorer la productivité et le pilotage des processus métiers, ou encore assurer

une traçabilité de bout en bout des tâches effectuées, en vue de respecter les réglementations.

Quels paramètres prendre à compte avant de se lancer dans un projet d’automatisation des processus métiers, afin d’en

garantir le succès et son évolutivité dans le temps ? Quelles sont les limites des développements spécifiques ? Dans quelles

situations est-il préférable de capitaliser sur l’expertise de solutions de Business Process Management intégrées ?

Projets BPM : les questions clés à se poser

Dossier


L’interaction au cœur de système

La plupart des processus métier informatisés de l’entreprise s’effectue essentiellement au travers de multiples interactions entre les utilisateurs et les systèmes d’information de l’entreprise. Toute la valeur ajoutée des solutions de BPM réside dans leur capacité à distribuer et orchestrer les tâches de plusieurs individus autour d’un document, d’une succession d’actions, de la résolution d’un problème client, etc.

Un second facteur de complexité se superpose à cette orchestration : la variété des finalités. En effet, les processus humains peuvent être classés en trois catégories : les processus d’approbation, de collaboration structurée et de gestion des événements ou exceptions. La catégorie des processus d’approbation est illustrée par les workflows documentaires (docflows), lesquels orchestrent l’intervention des utilisateurs autour d’un document qui doit être publié, en interne ou à l’externe. Seconde catégorie, les processus de collaboration structurée permettent d’organiser les interventions successives ou conjointes d’un grand nombre de personnes ; par exemple, pour traduire une notice technique sensible en plusieurs langues. Enfin, la famille des processus humains s’intéresse à la gestion des exceptions, au reporting et aux mécanismes de contrôle.

Refléter et s’adapter à la réalité de l’entreprise

Dans la réalité, les frontières entre les différentes catégories de processus humains ne sont évidemment pas aussi tranchées. Aussi spécifique soit-il, aussi réduit que soit son périmètre, un processus métier n’est en effet jamais isolé. Il participe nécessairement à l’accomplissement d’une stratégie d’entreprise, lorsqu’il n’est pas lui-même l’une des étapes d’un autre processus métier plus général. Selon son caractère critique pour l’activité de l’entreprise ou son image, un processus de validation de documents nécessitera la mise en œuvre de processus connexes, tels que la redistribution automatisée des demandes de validation en cas d’indisponibilité d’un collaborateur clé. Par définition ou par nature, un processus humain automatisé ne peut être que le reflet exact de l’activité humaine en entreprise, constituée d’un maillage complexe de communications et d’interactions qui ne sont pas toujours formalisées ni envisagées dans leur ensemble. Bref : dans tout projet BPM, la difficulté pour l’entreprise consiste ainsi à prévoir tous les cas de figure.

Analyser le besoin :processus simples ou complexes ?

Avant de se lancer, il est donc indispensable de réaliser une analyse des besoins. Il s’agit d’abord de définir le périmètre d’utilisation envisagé : groupe de travail, service ou direction opérationnelle tout entière, par exemple. Il est nécessaire ensuite de mesurer la capacité globale de l’entreprise à formaliser sous une forme communicable ses connaissances métiers, à développer des savoir-faire ou des procédures reproductibles, à cadrer l’usage et la diffusion des technologies auprès de

ses utilisateurs, etc. Ensuite, il lui faudra évaluer le niveau de complexité, le degré de criticité et d’intégration au système d’information des processus à automatiser.

Enfin, les responsables devront identifier les fonctionnalités de gestion, de contrôle et de traçabilité jugées indispensables par les utilisateurs métiers et par la direction informatique. Cette analyse permettra notamment de déterminer à partir de quel niveau de complexité des processus il est plus rentable de mettre en œuvre une solution intégrée de gestion des processus.

Optimiser les processus : une question de temps

Une fois l’analyse du besoin réalisée, la première problématique à prendre en compte est le facteur temps. Non seulement les besoins de gestion des processus métier sont susceptibles d’évoluer avec l’organisation de l’entreprise ; mais surtout, ils s’inscrivent dans une dynamique d’évolution intrinsèque. Ainsi, avec l’expérience, l’entreprise découvre que le processus de validation de documents mis en place peut être amélioré pour être plus efficace, ou qu’il nécessite des sous-processus de contrôle, de gestion des exceptions, de collaboration structurée, etc. Bien souvent, ces besoins n’apparaissent qu’à l’usage et sous la forme d’un dysfonctionnement du processus initial. Par exemple, c’est au moment où l’absence d’un collaborateur clé bloque un processus de validation que l’entreprise découvre qu’elle ne dispose pas de procédure définie de ré-attribution des tâches ou de gestion de la présence.

Disposer de tableaux de bord

Encore faut-il avoir la capacité à détecter le dysfonctionnement du processus, en disposant sous une forme ou une autre d’un tableau de bord permettant d’identifier l’étape qui pose problème et d’adopter une stratégie de repli (sous-processus de gestion d’exception, bascule sur une procédure manuelle, etc.). Seconde problématique clé du BPM, le besoin de traçabilité est d’autant plus aigu qu’il s’agit de processus humains. C’est-à-dire de processus sur l’exécution desquels les individus, responsables de projets, de services ou de groupes de travail, doivent nécessairement rendre des comptes. La mise en place d’un circuit de validation de document, pour reprendre notre exemple, n’a d’intérêt qu’à partir du moment où l’on peut s’assurer que les tâches nécessaires à la validation (vérifications de chiffres, relecture) ont bien été effectuées et que le service ou le collaborateur concerné engage sa responsabilité sur le résultat sous une forme traçable (email de confirmation, soumission d’un formulaire web, etc.).

L’importance de la question de la traçabilité des processus est également liée au caractère plus ou moins critique du processus concerné pour l’activité de l’entreprise. Un retard subi dans la validation de la réponse à un appel d’offres, par exemple, n’aura pas la même conséquence sur la pérennité de l’activité qu’un dysfonctionnement affectant le processus de validation de notes internes.


BPM : les questions clés à se poser

Un projet d’informatisation des processus métiers doit s’envisager dans sa globalité et son évolutivité dans le temps. Avant de se lancer, il est donc indispensable de pouvoir répondre aux questions suivantes :

1/ La modélisation du processus• Quel est le périmètre de mon projet ?• Mon processus est-il critique pour l’entreprise ? • Mon processus se décompose-t-il en sous-processus ou

à l’inverse, est-il un sous processus d’un processus plus global ?

• De combien d’étapes se compose mon processus ? • Combien de personnes interviennent dans mon processus ? • Mon processus comprend-il des tâches qui doivent

être effectuées de manière synchronisée, distribuées en parallèle ou en boucle ?

• Mon processus fait-il appel à des applications tierces (annuaire, formulaires, portail, ERP, CRM, GED, bases de données, etc.) ? Si oui, quels sont les composants, données, etc. qui peuvent être réutilisés ? Quel niveau d’intégration faut-il prévoir avec le SI existant ?

• Mon processus risque-t-il de faire « boule de neige » (dans un autre département de l’entreprise, pour d’autres finalités) ? Si oui, vais-je de nouveau procéder à des développements spécifiques ou est-il préférable que je m’appuie sur un moteur de workflow ?

• Quels vont être les délais et les coûts de mise en œuvre ?

2/ Le cycle de vie du processus et sa gestion quotidienne• Puis-je modifier facilement mon processus ? Exemples :

ajout ou suppression d’une étape ou d’une tâche, modifications des règles d’assignation, etc.

• Quels vont être les délais et les coûts inhérents à l’évolution/optimisation de mon processus ?

• Puis-je revenir en arrière en cas de modification finalement non conforme aux besoins des opérationnels ?

• Ai-je besoin de centraliser la gestion des processus et de leurs différentes versions, des utilisateurs et/ou des groupes d’utilisateurs ?

• Comment identifier l’étape qui pose problème ?• Comment alerter automatiquement les décideurs métiers en

cas d’erreur ou de blocage ?• Les responsables ont-ils la possibilité de réattribuer

automatiquement ou manuellement les tâches en cas d’absence de personnes impliquées dans le processus ?

• Faut-il gérer des règles d’accès ou de sécurité différentes en fonction des profils d’utilisateurs ?

3/ Le reporting et l’optimisation du processus • Les responsables ont-ils besoin d’avoir une vision

d’ensemble sur le déroulement d’un processus ? • Le processus est-il utilisé ? Est-il exécuté dans les temps ? • Quelles sont les personnes/tâches qui freinent le

processus ?• Comment puis-je optimiser mon processus ?• Suis-je capable d’avoir une traçabilité complète sur

l’ensemble des actions qui ont été réalisées ?


Tenir compte du cycle de vie du processus

Parce qu’il reflète une activité humaine, un processus automatisé n’est non seulement jamais isolé d’autres processus connexes, mais surtout jamais figé dans le temps. Difficile à percevoir au premier abord, la problématique la plus importante de mise en œuvre de processus automatisés tient dans la gestion de leur cycle de vie. Aussi simple soit-il, un processus métier automatisé résulte en effet déjà d’une interaction humaine complexe et vivante.

Au minimum, quatre catégories de personnes ont à faire avec un processus automatisé durant son cycle de vie : son ou ses concepteurs, l’administrateur chargé de son déploiement et de sa maintenance, le décideur opérationnel ou le responsable de service qui supervise les instances du processus, les collaborateurs qui interagissent avec ces instances.

Pour chaque processus automatisé déployé se posent ainsi les inévitables problématiques de gestion du cycle de vie communes à toutes les applications d’entreprise, telles que la gestion des versions et du changement, les mises à jour de maintenance effectuées par l’administrateur, la détection des erreurs, la mesure régulière des performances et de l’adéquation au besoin, etc. Les solutions BPM intégrées automatisent l’ensemble de ces mécanismes, par simples paramétrages.

Centraliser la gestion de l’ensemble des processus

Si les besoins exprimés varient d’une entreprise à l’autre, l’un des résultats constants de ce type de projets débouche sur la nécessité d’une gestion centralisée de l’ensemble des processus métiers automatisés, des outils avec lesquels ils sont mis en œuvre et des utilisateurs autorisés à les activer, les utiliser, les modifier, etc. Ainsi, quelque soit le périmètre et le degré de complexité du processus métier à mettre en œuvre, l’entreprise reste confrontée aux problématiques de gestion des utilisateurs et de la sécurité d’accès aux données, du déploiement, du changement, etc.

Là encore, ces fonctionnalités sont proposées en standard dans la plupart des solutions BPM du marché.

OPTIMIZE DESIGNASSEM

BLE

EXECUTEM

ONIT

OR


Assurer la reproductibilité

Dans tout projet de BPM, quelle que soit son envergure, la reproductibilité de tout ou partie des processus métiers automatisés s’avère également indispensable pour augmenter l’agilité, réduire les délais et les coûts de mise en œuvre. Même les processus les plus simples de validation de documents n’échappent pas à cette règle. Pourtant, une reproduction à l’identique peut paraître complexe. De même, la réutilisation de règles de gestion des exceptions, de réassignation des tâches ou d’alerte automatique peut se révéler génératrice de coûts cachés significatifs. Par exemple lorsqu’il s’agit de répercuter dans une multitude de processus automatisés la modification d’une même condition d’assignation de tâche (par exemple, la notification automatique de la direction financière lorsqu’une demande d’achat dépasse 10 000 euros). Ce manque de reproductibilité expose non seulement l’entreprise à une augmentation de sa charge de développement informatique, mais aussi à une inflation de tâches administratives répétitives et sans réelle valeur ajoutée. À l’inverse, les solutions intégrées de BPM, parce qu’elles disposent d’une administration centralisée, permettent d’automatiser les mises à jour multisites des workflows, des règles d’affectation, des conditions de réassignations de tâches, des droits des utilisateurs, etc. Elles intègrent également une gestion des versions pour éviter les régressions et permettre l’évolutivité des processus.

Capitaliser sur l’existant

Avant de se lancer dans un projet BPM, l’entreprise gagnera aussi à réaliser un état des lieux afin de déterminer quels applications, données, composants d’infrastructure, processus ou développements existants pourront être exploités pour modéliser, exécuter et piloter les nouvelles applications de gestion des processus. Cette approche permet de concevoir des workflows générant automatiquement des interactions et des communications entre les applications et les systèmes, à la manière des architectures orientées service (SOA) ou encore des architectures orientées ressources (ROA). Une démarche qui réduit le délai de création des applications de gestion des processus et les risques d’erreur tout en améliorant l’agilité au changement.

Favoriser la collaboration entre le métier et l’informatique

Dernier facteur à prendre en compte : la collaboration entre les équipes métiers et l’informatique. Les équipes opérationnelles réclament à la DSI de mieux appréhender les enjeux de leur métier, et de mettre en place des outils simples, ergonomiques et évolutifs, de proposer des procédures reproductibles et des composants réutilisables leur facilitant l’accès aux informations. Hier très nette, la frontière traditionnelle entre utilisateurs métiers et techniciens spécialisés est aujourd’hui plus perméable, autorisant une collaboration fluide des deux catégories d’utilisateurs. Dans son choix d’une solution de BPM, l’entreprise aura tout intérêt à intégrer cette nouvelle dimension pour favoriser la réutilisation des outils existants et la collaboration entre les utilisateurs fonctionnels et les techniciens. n

Jean Cadeau,Directeur technique

Bénéficiant d’une expérience d’une dizaine d’années dans le domaine du workflow

et du Business Process Management (BPM), Jean Cadeau est devenu directeur

technique de la filiale Française de l’éditeur K2 en 2006.

K2 propose une suite logicielle complète de BPM qui permet de modéliser, exécuter

et piloter les processus de travail en s’appuyant sur les applications bureautiques

et serveurs Microsoft déployées au sein des entreprises (MS Office, SharePoint,

Biztalk, Exchange, InfoPath, Active Directory…). Reposant sur des standards

technologiques, les applications workflow réalisées avec la plateforme K2 s’intègrent

aisément au système d’information (ERP, CRM, GED, SGBD, portail, etc.), permettant

aux entreprises de dégager plus de valeur ajoutée de leurs investissements

informatiques existants. Les solutions de K2 sont déployées au sein de plus de

2500 entreprises, dans plus de 40 pays.

Site web : www.k2france.com

INSCRIVEZ-VOUS GRATUITEMENTSur le site : http://www.idc.fr/infomanagement2010 - Code Invitation “ITX”

ou contactez Edith Tricheux : Tel. 01 56 26 26 91 – [email protected]

avec :

L’information, génératrice de valeur, est devenue en quelques années une des préoccupations majeures des entreprises. Désormais considérée comme une matière première stratégique, l’information devient une économie à part entière, l’économie de la connaissance. Sous toutes ses formes, qu’elle soit structurée ou non-structurée, l’information interagit aussi bien avec l’interne qu’avec les clients et les partenaires de l’entreprise.

Au programme :

• Comment valoriser mes informations non-structurées ?

• Comment optimiser la gestion de mes documents interactifs ?

• Comment structurer cette information tout en la protégeant ?

• Comment garantir la “fraîcheur” des informations et des contenus ?

• Comment optimiser l’output management et sécuriser les informations et les contenus ?

Profitez de l’expertise de Véronique Mesguich, Directrice de l’Infothèque, Pôle Universitaire Léonard de Vinci–Paris.

Venez découvrir les éléments de réponse à travers la vision des analystes d’IDC, des experts majeurs du marché et des retours d’expérience des utilisateurs.

Inscrivez-vous à la prochaine conférence IDC :

« Information & ContentManagement 2010 »

Valorisez le capital informationnel de l’entrepriseà l’heure de l’Economie de la Connaissance

Mercredi 13 octobre 2010Centre d’Affaires Paris-Trocadéro, Paris 16éme

IDC, cabinet leader de conseil, et d’études dans les technologies de l’information.

Sponsor Platinum

Sponsor Gold

Sponsor Bronze

CFF21S_AV1_Info Mgt_A4.indd 1 06/09/2010 14:54:24


Quelles sont les règles de gestion exécutées dans mon

système d’information ? Comment puis-je m’assurer que

ce sont les bonnes qui sont exécutées et qu’elles le sont à bon

escient ? Est-ce que mes règles de gestion sont bien cohérentes pour

l’ensemble de mon système d’information ? Ces questions fleurissent de

plus en plus chez les grands comptes.

La première étape consiste à examiner attentivement des

systèmes puisque, le plus souvent, la documentation

reste incohérente avec ce qui est réellement exécuté,

hors mise à jour en maintenance ou changements de

dernière minute en phase de développement. Passé

ce stade, une réponse à ces contraintes de traçabilité

passe par une brique logicielle souvent ignorée pour

diverses raisons : le moteur de règles.

Le moteur de règles au cœur de l’agilité du SI

Technique


permettre d’implémenter des règles sous une forme simple, mais qui prendra corps au fil du temps lors des différentes évolutions de l’expression de ces règles.

Dans le cadre de règles de gestion à cycle de vie plus long, le moteur de règles peut également prendre une importance conséquente, non pas dans leur complexité de mise en œuvre, mais dans le délai de déploiement. Ce phénomène est courant dans le monde de l’assurance. Les conditions d’applications d’un nouveau type de produit peuvent être annoncées très tôt dans le temps sans pour autant en connaitre les détails. Ainsi les développements pourront se préparer sur la base des éléments généraux et être affinés juste après la mise en application. Ce phénomène a pu être observé lors de la mise en place des dispositifs PERP (Plan d’épargne retraite populaire) et PERE (Plan épargne retraite entreprise) par exemple. La mise en place et les différentes versions des contraintes réglementaires (Bale, Solvency, etc.) peuvent également être une source d’utilisation des moteurs de règles.

Enfin, l’utilisation même basique d’un moteur de règles peut simplifier les algorithmes de traitement. Récemment, pour une problématique autour de la délégation de rôle pour une application m’a amené, en changeant de point de vue, à simplifier énormément l’algorithme d’implémentation (4 classes et 3 règles à la place de parcours d’arbres de responsabilités). Bien entendu, une problématique simple comme celle-ci ne justifie pas la mise en place d’une brique logicielle telle qu’un moteur de règles. C’est parce que le moteur de règles est présent que l’on change le point de vue.

Fonctionnement d’un moteur de règles

Les règles métiers sont décrites sous la forme de règles simples : SI <fait> ALORS <Conclusion>.

Il n’existe pas de clause <SINON>, mais une règle exprimant les faits contraires. Cette expression permet de créer un réseau de Pétri ou des réseaux neuronaux dont le plus usité est l’algorithme de ReTe. Ces réseaux permettent un parcours des règles très rapide en fonction des faits insérés dans le moteur et se basent sur les classes d’objets utilisées dans chaque règle. Une particularité qui rend ces moteurs très peu sensibles au nombre de règles et à leur complexité, mais très sensibles au nombre de types d’objets impliqués dans les règles, donc à la complexité du modèle métier. (cf. exemple simplifié de l’algorithme de RETE page 14).

Ces règles métiers sont décrites selon une grammaire spécifique. Il s’agit en fait d’un nouveau langage à apprendre, qui exploite les objets faisant partie du modèle métier manipulé dans le moteur. On trouve dans cette grammaire une gamme d’opérations assez large permettant la corrélation de faits en opérations unitaires ou en opérations ensemblistes. Aujourd’hui, ces opérations peuvent également prendre en compte les contextes temporels pour des opérations de type CEP (Complexe Event Processing), une approche par horodatage des faits et leurs corrélations.

En quoi consiste le moteur de règles ?

Un moteur de règles est avant tout un moteur d’exécution qui prend des règles d’un côté, des faits de l’autre et qui les rapproche pour obtenir un résultat correspondant aux attentes exprimées dans les règles.Concrètement, cela se traduit sous différentes formes : • Lesrèglespeuventégalementêtrereprésentéessous

la forme de tables de décisions rapprochant des faits, souvent numériques ou codifiés, pour obtenir un résultat. Une obligation toutefois : la table est déterministe. Et l’ensemble des règles doit couvrir tous les cas. L’inconvénient réside dans le caractère simpliste des tables de décisions, car aucune opération complexe ne peut être envisagée.

• Lesrèglespeuventêtreimplémentéessousformede triggers ou de programmes en PL/SQL sur des bases de données permettant de réaliser des rapprochements de faits. On reste toutefois dans le domaine de la programmation et de l’interprétation, domaine pour lequel le rétro-engineering est nécessaire pour comprendre ce qui est réellement exécuté.

• Lesrèglespeuventêtrereprésentéespardesfichiers de descriptions répondant à un langage évolué. Cette approche nécessite, comme tout langage, un apprentissage de sa grammaire, ou une traduction implicite. Ce type de moteur est généralement lié à un langage objet pour faciliter les manipulations du modèle métier. L’inconvénient demeure bien entendu le respect de ce langage ainsi que la construction en mémoire des objets pour être manipulés. Ceci peut s’avérer handicapant sur des volumétries importantes.

Cet article étudiera plus particulièrement ce dernier type de moteur, plus flexible, plus agile et plus à même de répondre aux questionnements évoqués précédemment.

Quelques excellentes raisons pour l’utiliser

Les raisons pour lesquelles l’utilisation des moteurs de règles s’avère utile sont variées.

Du point de vue du métier (directions opérationnelles), la définition des règles se rapproche d’une expression naturelle. Ce sont d’ailleurs parfois ces mêmes métiers qui peuvent mettre à jour le moteur en production. L’utilisation du moteur de règles apporte donc de la rapidité dans la mise à jour des règles. Cela s’avère très important dans les mises à jour à circuit très court, comme dans la grande distribution. Lorsque le supermarché voisin annonce une promotion très intéressante, le responsable d’un autre supermarché doit rapidement proposer quelque chose d’équivalent, au risque de perdre une clientèle importante.

Du point de vue du chef de projet informatique, le moteur de règles revêt également un aspect sécuritaire. En effet, lorsque les clients (internes ou externes) expriment leurs besoins, ils le font parfois en écrivant simplement sur un post-it, rendant ainsi le chiffrage des développements informatiques beaucoup plus coûteux puisqu’il est nécessaire de se lancer sur un ensemble de règles de gestion hasardeuses. Le moteur de règles peut alors


Une fois les règles rédigées, le moteur de règles construit l’arbre de ReTe qui constituera alors la base de génération du code associé. En effet, la majeure partie des moteurs de règles génèrent un code exécutable correspondant aux règles. Ce code est exécuté par le système accueillant le moteur de règles. La traduction s‘effectue majoritairement lors de l’interprétation du fichier de règles par le moteur. Le temps d’interprétation et de traduction varie selon le nombre de règles à insérer dans le moteur. Il ne reste alors qu’à insérer les faits, des instances d’objets, les données réelles, dans le moteur et à admirer le résultat.

Le résultat peut être obtenu de différentes manières :• parmodificationdesfaitsinsérés,commelamodificationde

l’état d’objets, l’ajout ou le retrait de valeurs, etc.• parcréationdenouveauxobjets.

Intégration d’un moteur de règles dans le SI

L’utilisation des moteurs de règles se démocratise. D’autant plus que depuis l’avènement des architectures SOA (Service Oriented Architecture), il devient aisé de déléguer à une brique logicielle complexe des calculs, sans pour autant avoir l’impression de perdre la maitrise de l’applicatif.

Les moteurs de workflow sont naturellement câblés pour faire appel aux moteurs de règles pour les étapes de décisions ou d’affectation de tâches. Les projections sur des processus courts que sont les moteurs d’exécution BPEL (Business Process Execution Language) font de même, et naturellement les EAI (Entreprise Application Integration) et autres ESB (Entreprise Service Bus) ont suivis le mouvement. Il est donc simple dans ces architectures d’utiliser un moteur de règles : un peu de code, une interface, un SLA (Service Level Agreement) et l’exposition d’un WSDL (WebService Definition Language) plus tard le calcul est envisageable via l’utilisation d’un Web Service.

Il ne faut toutefois pas confondre moteur de règles au sens de l’exécution et moteur de règles au sens du référentiel de règles. En effet il existe plusieurs options pour partager les règles entre applications.

Dans la figure 1 sont présentés deux exemples de référence pour lesquels les applications (en bas) ne connaissent pas l’existence du moteur. Alors, elles fonctionnent en simple client du fournisseur de service. Dans le cas n° 1, le moteur d’exécution et le référentiel de règles sont intégrés dans le même fournisseur de services. Dans le cas N° 2, le référentiel de règles est géré de manière distincte du moteur d’exécution.

Cette séparation des concepts permet de faire vivre l’application d’exécution du moteur et de gestion de règles avec des cycles de vie différents. Elle permet également de mettre en œuvre une véritable politique de mise à jour des règles avec des interfaces spécialisées pour des utilisateurs finaux.

Class

Attributs&

Values

Links

Result Rule 1 Rule 2 Rule 3 Rule 4

&

& sum

A.x=2 A.x=1 B.k>0

C.g<0 C.h>3

C.f="test"

B.n=10

A B C D Dans l’exemple ci-contre, les classes sont A, B C et D. Les conditions sur ces classes s’appliquent pour chaque feuille du parcours. Des liens permettent de relier les conditions les unes avec les autres, le résultat est la suite logique de l’aboutissement d’un parcours de l’arbre.

Comme exprimé ici, lors de l’insertion d’un objet il est très facile de savoir quelles sont les feuilles qui sont activées ou non. La simple identification de la classe de l’objet permet de restreindre la partie de l’arbre qui sera appliquée à terme. Les conditions ne faisant qu’affiner la restriction.

Exemple simplifié de l’algorithme de RETE

1

SOA (EAI/ESB)

2


Dans le même esprit, on peut aussi mettre les règles à disposition de l’ensemble des applications du système d’information comme indiqué en figure 2. Le Référentiel de règles (2) met à disposition les règles du système d’information. Les applications peuvent alors faire appel à un moteur de règles centralisé (1). Et chaque application peut également faire appel au référentiel pour exécuter ou stocker les règles. Cette dernière approche sera très prisée pour les applications fonctionnant en mode déconnecté. En effet, les règles sont à la fois synchronisées entre le référentiel centralisé et le référentiel local. En revanche, l’exécution est effectuée par l’application en mode offline. Les cas d’utilisation les plus rependus étant ceux des applications de pricing ou de simulation pour les représentants se déplaçant en dehors de leur entreprise.

Démultiplier la puissance des moteurs de règles

L’une des principales caractéristiques des moteurs de règles tient dans leur capacité de déployer ou de modifier des règles à chaud. De ce fait, les utilisateurs métier sont capables de modifier les règles directement en production en utilisant des applications spécialisées. Ceci permet de réduire de manière drastique les délais de mise en production de nouvelles règles ou de modifier les règles avec une très grande réactivité. Ces modifications permettent également de définir les règles dans les moteurs d’exécution de processus, BPEL ou workflow, pour chaque décision.

Aujourd’hui, il est possible de coupler le moteur de règles avec des ETL (Extract, Transform and Load), outils de transports du monde BI (Business Intelligence), rendant possible la transformation des données sur base de règles avant le rechargement en base.

Même s’il n’est pas encore possible de stoker la totalité des règles de l’entreprise dans les moteurs d’exécution de règles, on peut référencer une grande partie des règles « cœur de métier », partagées dans l’ensemble de l’entreprise. Cette manière de procéder est d’ailleurs compatible avec les bonnes pratiques de l’urbanisation des systèmes. En effet, les règles peuvent être structurées dans le référentiel, ou stockées dans plusieurs référentiels en fonction des zones/quartiers définis.

Les référentiels de règles peuvent d’ailleurs être synchronisés avec les référentiels documentaires d’entreprises, les cartographies métier et/ou applicatives rendant ainsi possible la capitalisation.

L’entreprise peut donc mettre en place des architectures simples, progressives et novatrices rendant possible la capitalisation sur le système d’information. La réponse aux questions : « Quelles règles de gestion sont exécutées dans mon système d’information ? Comment puis-je m’assurer que ce sont les bonnes règles de gestion qui sont exécutées ? Est-ce que mes règles de gestion sont bien cohérentes dans l’ensemble de mon système d’information ? » peut donc être positive, et exacte. n

Guilhem Delebecque,Architecte - Urbaniste

Acteur majeur du conseil et des services informatiques, Sopra Group a réalisé

en 2009 un chiffre d’affaires de 1,1 milliard d’euros pour 12 000 employés. Son

périmètre de compétences s’étend depuis la réflexion stratégique en amont,

jusqu’à la conduite de grands projets d’intégration de systèmes et à l’outsourcing

applicatif. Le Groupe poursuit le déploiement mondial de son activité d’intégration

d’applications et de gestion des processus métiers à travers sa filiale Axway, leader

mondial des « Collaborative Business Solutions ».

Site web : www.sopragroup.com

1

3 4

SOA (EAI/ESB)

2


Actualitésinternationales

IBM rachète Netezza pour 1,7 milliard de dollars

Comment résister à un chèque de 1,7 milliards de dollars ? Une question que le dirigeants de Netezza n’ont pas dû se poser longtemps. En effet, ce spécialiste du datawarehouse (qui a lancé sa première offre en 2004) compte à peine 500 employés pour 200 millions de chiffre d’affaires en 2009. Une somme qui équivaut donc à plus de 8 fois ce résultat !

Positionné sur l’entrée de gamme des serveurs de datamining, Netezza propose des appliances (matériel et logiciel dédiés) à moins de 200 000 dollars, soit bien plus abordables que les solutions de type Teradata. Répondant aux besoins en pleine explosion des fournisseurs d’énergie ou les opérateurs de télécommunications (entre autres) souhaitant améliorer leur marketing (segmentation, recoupements, etc.), Netezza s’est fait une place sur le marché aux côtés des Teradata, HP, IBM ou Oracle.

Même si la transaction doit encore être validée par le vote des actionnaires, l’issue semble jouée d’avance. En effet, une offre à 27 dollars représente un bonus d’environ 15% pour une société à peine adolescente, qui tout de même table sur une croissance annuelle de 20%. Entre SPSS (acquise en juillet 2009) et Cognos (rachetée en 2007), reste à savoir comment cette offre pourra s’intégrer dans le portefeuille d’IBM… n

Solaris 11 : l’OS de prédilection pour progiciels Oracle et Fusion Middleware

Après le rachat de Sun, Oracle transformait Solaris en logiciel payant en mars 2010. L’éditeur précisait que les nouveautés d’Oracle Solaris ne seraient pas intégrées à Open Solaris, sonnant le glas de la communauté libre Solaris autodissoute en août dernier.

Solaris 11, annoncé pour 2011 sera le fruit de nombreuses innovations : 2 700 projets, 400 inventions, 20 millions d’heures de développement, 60 millions d’heures de tests, 11 000 applications, etc. Au menu des nouveautés : rapidité et simplicité du déploiement et des mises à jour, images physiques ou virtuelles de configurations combinant Solaris et des logiciels Oracle, récupération des systèmes améliorée et reboot en quelques dizaines de secondes au lieu des quelques dizaines de minutes.

Mais surtout, la démarche stratégique d’Oracle a consisté à faire travailler en commun les équipes en charge des systèmes, les responsables des serveurs et les spécialistes des applications pour obtenir la meilleure configuration du marché avec Oracle Fusion Middleware 11 g, Java, et les applicatifs Oracle. Une bonne manière de réaliser des ventes groupées ou de se placer avantageusement sur le marché des appliances physiques ou virtuelles en détenant tous les morceaux du puzzle. « Hardware and Software Together » serait devenu la nouvelle devise de la maison Oracle. n

Solaris 11 : Une feuille de route ambitieuse et jouant l’intimité avec les serveurs


Actualités internationales

Free Mobile : vers la guerre de l’itinérance 3G ?

Les opérateurs de téléphonie mobiles installés dans l’Hexagone (Orange, SFR et Bouygues) ont vu d’un très mauvais œil l’octroi de la quatrième licence mobile à Free Mobile fin 2009. L’Arcep (autorité de régulation des communications électroniques et des postes) souligne que l’accès aux réseaux des trois opérateurs en place concerne l’itinérance 2G, et que Free a obligation de lancer son offre de téléphonie mobile début 2012. Le régulateur estime qu’il revient à ce dernier de négocier avec les opérateurs en place. « Il est pratiquement sûr qu’un opérateur finira par considérer qu’il a tout intérêt à accorder l’itinérance 3G à Free » a affirmé Jean-Ludovic Silicani, président de l’Arcep, avant de lancer : « La situation débouchera sur un accord contractuel ou la puissance publique devra intervenir ».

Pendant la présentation des résultats semestriels du groupe Iliad-Free en septembre, son directeur général Maxime Lombardini a parlé d’une « situation de

blocage dans les discussions sur l’itinérance 3G avec les trois opérateurs. Free reçoit toujours une fin de non-recevoir ».

Sans contrainte légale pour les opérateurs mobiles d’étudier la demande de Free Mobile, la situation pourrait ne pas évoluer. Maxime Lombardini se montre portant optimiste et pense décrocher un accord d’itinérance 3G avec un opérateur avant fin 2010, contractuellement ou par une requête en contentieux. Et l’Arcep a confirmé qu’en cas de blocage, « il appartiendra à Free de saisir le Conseil de la Concurrence ou l’Arcep ». Cette dernière a effectivement compétence pour régler un différent sur l’accès entre Free et un opérateur qui refuserait l’itinérance 3G. Faudra-t-il en arriver là ? n

Naissance de la Fédération des professionnels des tests d’intrusion

Les tests d’intrusion restent l’un des moyens les plus efficaces pour mesurer le niveau de sécurité d’un système d’information. Outre la mauvaise réputation qui a longtemps accompagné les plus compétents de ces experts, il devenait urgent de clarifier les choses et de définir de bonnes pratiques.

La Fédération des professionnels des tests d’intrusion (FPTI), association française à but non lucratif, a pour objectif de réunir les professionnels de la sécurité informatique spécialisés dans le secteur des tests d’intrusion. Objectif : créer une certification pour les professionnels réalisant des tests d’intrusion.

En parallèle, une charte est en cours de finalisation, et servira de base à la certification. Le président de la FPTI, Laurent Dupuy affirme : « Au sein de la fédération, nous croyons à la diversité des talents. Chaque spécialiste en sécurité informatique peut s’exprimer sans couleur ou appartenance à une entreprise commerciale pour contribuer à mettre en place des règles qui participeront à la protection des entreprises françaises et des citoyens ».

Sur son site web, la FPTI propose des informations sur les logiciels d’intrusion, et de très nombreux ouvrages de référence que ses membres peuvent consulter à volonté.

Pour la rentrée, la FPTI a initié trois groupes de travail : les tests d’intrusion informatique ; la virtualisation (« définir des scénarios de durcissement des plates-formes de virtualisation tout en garantissant la possibilité de construire des plates-formes virtuelles complètes allant des dispositifs de filtrage aux moyens de supervision de la sécurité informatique ») ; et l’ultramobilité et les risques d’intrusion dans les smartphones. n

http://www.fpti.asso.fr


HP supplante Dell et s’offre 3PAR pour 2,4 milliards de dollars

La saga de l’été et de la rentrée fut sans aucun doute le combat acharné entre Dell et HP pour s’emparer de 3PAR, spécialiste californien du stockage à la demande.

Le 16 août, Dell frappe fort en proposant 18 dollars par action pour racheter 3PAR, alors que le dernier cours ne s’élève qu’à 9,65 dollars. Soit une prime de 87% ! Mais voilà que le 23 août, HP surenchérit à 24 dollars par action, soit 33,3% de mieux que le prix proposé par Dell. Et ce dernier réplique le 26 en proposant 24,30 dollars. Enfin, le 02 septembre, HP porte le prix à 33 dollars par action en numéraire, soit une valorisation de 3PAR avoisinant les 2,4 milliards de dollars. Et 3PAR publie sur-le-champ un communiqué affirmant que son conseil d’administration a jugé la nouvelle offre de HP supérieure à la proposition non encore publique de Dell à 32 dollars. Dell renonce et annonce mettre fin à son contrat avec 3PAR qui prévoyait de lui donner la priorité s’il s’alignait sur une offre rivale. Au final, les actionnaires de 3PAR réalisent une excellente opération en une petite quinzaine !

La bataille pour racheter ce constructeur/éditeur illustre la consolidation du marché du stockage dont le dernier rebondissement avait vu EMC souffler DataDomain à NetApp l’an passé pour 2,1 milliards de dollars. n

VMware rachèterait Suse Linux à Novell

Émotion dans le landernau informatique. Le 17 septembre, un article du New York Times révèle que Novell serait en discussion avancée avec au moins deux fournisseurs, dont VMWare, pour une reprise de ses activités en plusieurs lots.

En déficit depuis trois années consécutives, Novell pourrait logiquement chercher à revendre. Et si le quotidien américain évoque VMware et Attachmate, on se souvient qu’il y a six mois, le fonds d’investissement Elliot Associates avait proposé près de deux milliards de dollars, offre rejetée par Novell qui mentionnait rester à l’écoute de toute proposition.

L’évocation de VMware reprenant Linux Suse agite autant les analystes, parce que Novell a noué divers partenariats avec Microsoft, ennemi juré de ce premier. Tous les ingrédients sont donc réunis pour secouer le cocotier… en respectant le client, cela va de soi. Et toute cette agitation n’empêche nullement Novell de poursuivre sereinement ses activités et d’annoncer sa toute nouvelle solution d’administration d’environnement de Cloud : Novell Cloud Manager. Cette offre œcuménique permet de concevoir et de gérer des environnements cloud en utilisant les principaux hyperviseurs, systèmes d’exploitation et serveurs du marché. Histoire de mettre tout le monde d’accord. n

Hadopi : bientôt les premières sanctions ?

Mi-septembre, la Hadopi (Haute Autorité pour la diffusion des œuvres et la protection des droits sur Internet) a demandé aux fournisseurs d’accès Internet (FAI) d’identifier 800 abonnés dont la connexion est soupçonnée d’avoir permis le téléchargement illégal de fichiers. Et les premiers e-mails d’avertissement devraient partir dès le 27 septembre.

Les FAI ont bien reçu les demandes d’identification de leurs abonnés via les adresses IP, et disposent d’un délai de 8 jours pour fournir les informations sur les abonnés. La Hadopi aurait déjà reçu les identifications, et les abonnés suspectés devraient rapidement recevoir un premier avertissement. A suivre… n


Actualités internationales

Le progiciel se porte bien : 232 milliards en 2010

Le marché du logiciel d’entreprise retrouve de belles couleurs selon le cabinet américain Gartner qui estime son chiffre d’affaires mondial 2010 à 232 milliards de dollars, soit une hausse de 4,5% par rapport à 2009. Mieux encore, il atteindrait 246,6 milliards de dollars en 2011, et 297 milliards de dollars en 2014, avec un taux moyen de croissance annuelle de 6% sur cinq ans.

Néanmoins, Gartner annonce de fortes disparités selon les zones géographiques. Des régions émergentes, comme l’Asie-Pacifique et l’Amérique du Sud, devraient davantage investir sur ces solutions sur cette période. De même, le marché des progiciels en Amérique du Nord devrait atteindre 110,8 milliards de dollars en 2010, soit + 8,5% par rapport à 2009.

En zone EMEA, les revenus de ce marché resteront limités à 64,5 milliards de dollars, soit un repli de 3,4% par rapport à 2009. Néanmoins, il repartira à la hausse, pour se stabiliser à 76,2 milliards de dollars en 2014. L’Asie-Pacifique (hors Japon) devrait être favorable à ce segment avec une forte hausse de 13%, soit 22 milliards de dollars en 2010, contre 19,5 milliards de dollars en 2009. n

+ 29% pour l’e-commerce français

Selon une étude de la Fevad (Fédération du e-commerce et de la vente à distance) réalisée auprès de plus de 70 000 sites marchands, les ventes sur internet ont progressé de 29% sur la période du premier semestre 2010. Sur les 6 mois, le chiffre d’affaires réalisé par ces acteurs s’élève 14,5 milliards d’euros, soit une progression de 29% par rapport au premier trimestre 2009.La Fevad estime même que le chiffre d’affaire du e-commerce français devrait franchir la barre des 32 milliards d’euros en 2010. Une belle performance comparée aux 25 milliards amassés en 2009.

Il est vrai que le nombre de sites marchands a progressé en 12 mois, passant de 54 200 à plus de 70 200, soit 16 000 nouveaux e-marchands. La fédération constate aussi une augmentation de 17% du nombre de cyberacheteurs français.

Une tendance que l’explosion de la téléphonie mobile et la baisse des forfaits Internet vraiment illimités (en temps et en volume) devraient encore accentuer. Que de papier économisé si cette tendance faisait reculer les éditions et envois de lourds catalogues papier ! n

Classement Sites Internet Visiteurs uniques

1 eBay 11 194

2 PriceMinister 10 738

3 La Redoute 10 110

4 Amazon 9 295

5 Cdiscount 8 382

6 3 Suisses 8 231

7 Fnac 8 141

8 Voyages-sncf.com 6 964

9 Carrefour 6 298

10 Vente-privee.com 6 109

11 Pixmania 6 036

12 Rue du Commerce 5 137

13 La Maison de Valerie 4 473

14 Spartoo 4 432

15 Brandalley.com 4 029

Les sites e-commerce français les plus visités au 1er trimestre 2010 (en milliers de visiteurs) - Source : Médiamétrie/NetRatings pour la Fevad


Les progiciels de gestion intégrés (PGI) en général, et SAP en particulier, constituent aujourd’hui des éléments structurants

des grands systèmes d’information. Choisis pour leur richesse fonctionnelle, ils disposent de qualités indiscutables de

robustesse, de fiabilité et d’agilité, et permettent une mise en œuvre rapide de type « boîte noire » dans les domaines métier

concernés, sans avoir à investir sur leur fonctionnement interne.

Vers une qualification fonctionnelle efficace des applications SAP


Comment ça marche ?

Comme pour l’ensemble des applications du SI, la phase de qualification constitue une étape critique pour la maîtrise du risque fonctionnel et la satisfaction des utilisateurs. Cependant, les activités de qualification présentent un contexte particulier lié aux phases spécifiques du cycle de mise en œuvre des PGI :• Lesphasesdeconfigurationduprogicieletd’intégrationavec

les autres composantes du SI exigent le test de processus métier élémentaires, ainsi que les processus de bout en bout permettant de qualifier l’intégration en maitrisant les risques fonctionnels ;

• Lesphasesdemontéedeversionsoud’évolutionduprogicielexigent de garantir la non-régression fonctionnelle au travers de tests adaptés à cet objectif tenant compte du niveau de risque associé aux processus métier concernés.

Les activités de test notamment fonctionnel, critiques pour sécuriser la mise en production et la gestion des paliers d’évolution, restent complexes à maîtriser en termes de couverture des processus métier, et constituent une part importante de la mise en œuvre et de la maintenance des PGI (cf. référence [1]).

Comment la modélisation des processus métier peut-elle constituer le support opérationnel pour la génération et la maintenance du référentiel de tests de progiciels, avec la mise en œuvre de techniques de génération automatique de tests, de gestion du référentiel de tests et d’automatisation ? Il s’agit ainsi de mettre en œuvre une démarche d’industrialisation du test fonctionnel (cf. référence [2]), appliquée aux PGI. Elle doit permettre de réduire les coûts et de maîtriser les risques lors de la qualification dans le contexte spécifique des grands progiciels type SAP ou PeopleSoft.

Cette approche peut s’appliquer aux applications SAP, dont la complexité et le caractère critique au sein du SI impliquent la mise en œuvre d’un processus rigoureux pour la qualification tant en phase de déploiement que d’évolution ou de migration. L’approche s’appuie sur la réutilisation de modèles génériques de processus métier, adaptés aux exigences fonctionnelles spécifiques du projet. La traçabilité de cette modélisation avec le référentiel des processus métiers et exigences (documentation Blueprint SAP) et des éléments d’architecture de SolMan, permet de capitaliser pour la qualification fonctionnelle. Cette approche permet ainsi de faire le lien entre les phases de développement (configuration, développement spécifique, intégration), de maintenance et de migration pour un suivi continu du référentiel de tests, exploitable notamment en test de non-régression.

Les enjeux de la qualification fonctionnelle SAP

Il existe trois grandes typologies de projets SAP :• Implémentation/intégrationSAP• DéploiementSAP• MontéedeversionSAP

Le projet d’Implémentation consiste à mettre en œuvre l’ERP SAP au sein du système d’information de l’entreprise. Quant

au projet de déploiement, il consiste à créer un ensemble de processus qui sera partagé par toute l’entreprise (entités dans un même pays, dans différents pays et filiales). Un ensemble cohérent de processus est créé et adapté à chaque filiale ou entité pour prendre en compte les dispositions légales en vigueur dans le pays où s’effectue le déploiement. Un projet de montée de version consiste à faire évoluer la version de SAP installée vers la dernière version proposée par l’éditeur.

Un projet d’application de correctifs (support packages ou Enhancement packages) sera organisé de la même manière qu’une montée de version. Toutefois, il nécessitera moins d’efforts de tests. En effet, la couverture des tests est alors focalisée sur les transactions et les processus métier critiques impactés.

Sur un projet d’Implémentation, les tests viseront à s’assurer de la cohérence de chaque processus, mais aussi de leur cohérence entre eux. Par exemple, lors de la réception de marchandise, on va s’assurer que le magasinier valide bien le bordereau de livraison, incrémente bien le stock et dépose les articles au bon endroit. De plus, le testeur devra s’assurer que les divers éléments comptables ont bien été créés.

Figure 1 : Coût du test dans un projet d’intégration SAP

Qualité, réactivité et réduction des coûtsUn projet d’implémentation SAP est nécessairement stratégique pour l’entreprise puisqu’il vient s’intégrer au cœur du système d’information et des différents métiers de l’entreprise. Les budgets généralement constatés pour les tests d’une première mise en place sont de l’ordre de 30 à 45 % (ils peuvent atteindre les 50 % dans certains cas). Toute industrialisation de cette phase impacte les délais de livraison et la qualité lors de la mise en production. Elle permet aussi de réduire les coûts des tests lors des maintenances et évolutions. Une anomalie détectée en production coûte, en coût de correction, 7 fois plus cher que ce même défaut détecté et corrigé lors des tests fonctionnels. À cela s’ajoutent les coûts potentiels engendrés par cette anomalie sur l’activité de l’entreprise qui peuvent s’avérer bien plus élevés.

Sur un projet de déploiement, en plus des tests liés à un projet d’Implémentation, il faut aussi tester tous les ajustements réalisés pour chaque déploiement dans chaque entité ou filiale. Il est donc important de pouvoir capitaliser sur un patrimoine de test des processus métier « communs» ou « Core Model » puis de les décliner selon les besoins.


Avoir des scénarii de tests bien rodés ou des tests exécutés automatiquement est donc primordial pour garantir la réouverture du système à l’heure planifiée.

Une équipe dédiée aux testsLa grande majorité des projets SAP ne sont pas menés par une équipe dédiée aux tests, qui sont confiés à des experts fonctionnels qui les conçoivent et les exécutent. Si cette approche favorise l’implication, elle délègue à des utilisateurs des tests qui ne sont pas leur fonction première. Souvent peu exhaustifs, les tests ne traitent dans le meilleur des cas que les cas passant. Et ils ne font que confirmer que ce qui a été réalisé répond bien aux attentes de l’expert fonctionnel, mais pas nécessairement à ce qu’a exprimé le métier en amont lors des phases de conception générale et détaillée.

C’est pourquoi, pour renforcer la phase de qualification, les grands comptes, utilisateurs SAP, confient de plus en plus les tests fonctionnels à une équipe dédiée (intégrateur Tierce Recette Applicative ou équipe interne). Le fait de confier les tests fonctionnels à une équipe tierce, dédiée à cette fonction, permet de concevoir des tests en réponse aux besoins et exigences demandées par le métier lors de la conception.

Ainsi, comme l’illustre la figure 3, la maîtrise de la qualité et de la productivité des phases de test constitue un enjeu majeur pour la réussite des projets SAP.

Figure 2 : Coût du test d’un projet de migration

Sur un projet de montée de version, l’enjeu principal se situe autour des tests de non-régression. La montée de version SAP est souvent de nature technique : on installe la nouvelle version de l’ERP en touchant au minimum aux processus existants. Il s’agit alors de réaliser rapidement des livraisons en s’appuyant sur les nouvelles fonctionnalités de l’ERP. Sur ce type de projet, on constate que près de 80 % du budget d’implémentation est consacré aux tests. La montée de version de l’environnement de production doit être réalisée dans un délai relativement court (de 24 à 72 h maximum) qui pose donc des contraintes très fortes sur le processus de test. La pertinence et la couverture de tests en amont doivent être excellentes pour éviter toute mauvaise surprise en production. Le temps imparti pour les tests sur la production se résume en général à quelques heures.

Figure 3 : Les enjeux du test SAP


La qualification SAP fondée sur la captation des processus et des règles métier

Les processus métier sont au cœur de l’activité de qualification SAP : l’objectif de l’activité de test consiste à assurer que les processus métier critiques sont correctement implémentés et maintenus au fil du temps et des évolutions.

La modélisation des processus métier, dans des notations telles que le standard BPMN - Business Process Modeling Notation - va permettre de formaliser et de structurer ces connaissances pour la production et la maintenance du référentiel de tests.

C’est ce principe de capitalisation sur des modélisations métier qui est mis en œuvre dans les approches de génération automatique de tests. Ces approches, telles qu’illustrées par la figure 4, permettent d’assurer l’alignement du référentiel de tests avec les besoins métier en pilotant la production des tests à partir de ces modélisations (Processus et règles métiers) et en automatisant la gestion de la traçabilité entre les besoins métier et les tests.

Figure 4 : Schéma de principe de la génération de tests à partir de modélisation métier

Les éléments de modélisation exploités pour la génération de tests (voir figure 5) se situent à trois niveaux :• LamodélisationdesProcessusmétier,typiquementrepré-

sentés en BPMN - Business Process Modeling Notation ;• LamodélisationdesDomainesetEntitésmétier,typiquement

représentés en UML - Unified Modeling Notation, au travers d’un diagramme de classes.

• LamodélisationdesRèglesmétier(lesrèglesdedécisionàtester), typiquement représentées en UML par des annotations en OCL - Object Constraint Language.

Figure 5 : Éléments de modélisation exploités pour la génération de tests

Ces éléments de modélisation, représentant les exigences et comportements attendus de l’application testée, sont exploités au sein d’un processus outillé de génération de tests (cf. figure 6) qui assure les fonctions suivantes :• Productionautomatiséedescasde testcouvrant les

processus et règles métier. Les cas de test générés intègrent la description des pas de test, des paramètres et données d’entrées et les résultats attendus pour l’établissement du verdict ;

• Traçabilitéautomatiséedepuislesexigencesjusqu’auxtests;• Intégrationdelachaîneoutilléeaveclesoutilsdemanagement

de tests de type HP Quality Center et IBM Rational Quality Manager ;

• Productiondesscriptspourl’automatisationdel’exécutiondes tests.

Figure 6 : Processus de génération de tests


Figure 8 : Vue globale des processus SD

Figure 9 : Vue détaillée du traitement des commandes en inter-entreprises(cross Company Sales Order Process)

À partir du modèle générique, des modifications sont apportées au niveau des processus génériques en BPMN, pour correspondre au processus de commande de l’entreprise. Ces modifications portent dans notre cas sur le déroulement lui-même du processus, ainsi que sur l’utilisation de transactions spécifiques. Le processus de l’entreprise étant beaucoup plus détaillé que le processus standard, on a également ajouté des niveaux de profondeur hiérarchique dans le modèle.

Figure 10 : Modèle de processus spécifique de l’entreprise

La lecture d’un processus exprimé en BPMN reste simple : les rectangles avec un engrenage dans le coin supérieur gauche représentent des tâches effectuées sur SAP, qui représenteront des étapes dans le déroulement des tests. Les rectangles munis d’un simple signe « + » indiquent la présence d’un sous-processus, permettant ainsi une vision hiérarchisée du

Dans le contexte spécifique du test SAP, ce processus se décline en exploitant des modèles de processus génériques, conformes aux baselines des modules SAP, et constituant un point d’entrée pour le projet de test, en phase avec les éléments du référentiel SAP Solman (Blueprints, documentation…). Cette capitalisation sur une modélisation générique est illustrée en figure 7.

Figure 7 : Utilisation de modèles génériques de processus métier SAP

Pour chaque module, un ensemble de processus est proposé par SAP sous forme documentaire (Baselines). Cet ensemble représente le mode d’utilisation conseillé des transactions pour un processus efficace. En cohérence avec ces descriptifs, des modèles BPMN ont été réalisés. Par la suite, on désignera ces modèles sous le nom de modèles génériques.La première tâche de l’analyste de test consiste à identifier les différences entre les processus standard et ceux spécifiés par les experts métier. La modification des modèles génériques permet alors un dialogue détaillé avec les experts et simultanément la constitution du canevas des tests à venir. Sa deuxième tâche consiste à décrire, au niveau du modèle UML pour le test, les règles métier spécifiques qui feront l’objet de tests, et les objets métier impliqués dans la vérification de ces règles.

Cet ensemble, processus métier et modèle UML spécifiques, permettra de calculer un ensemble complet des tests nécessaires à la qualification des développements produits, et à publier ces tests dans le référentiel de test pour exécution.

Illustration sur un exemple de module SAP Sales & Delivery

Le module SD propose un ensemble de processus standard. Nous allons modifier, afin de répondre à la demande de l’expert métier chargé du cycle de vente, sa partie inter-entreprise. Le contenu initial du modèle générique utilisé se présente de la manière suivante, hiérarchisé par thématiques :


déroulement. Les flèches représentent des enchainements de tâches et les losanges contenant le signe « x » des parcours alternatifs possibles dans ses enchainements selon un choix qui sera dépendant des données et des objectifs de test.

La simplicité de lecture à ce niveau garantit une compréhension commune entre expert métier et analyste de test. Bien souvent, la lecture même approfondie d’une spécification textuelle ne suffit pas à éviter les erreurs d’interprétation, et sera cause de pertes de temps considérables par la suite si des allers-retours sont nécessaires lors de l’écriture manuelle des tests, entre l’expert métier et l’analyste de test. La modélisation ne le protègera pas de ces mêmes erreurs d’interprétation, mais ces erreurs seront identifiées beaucoup plus tôt dans le cycle de définition du référentiel de test, et auront donc un coût très inférieur.

De plus, on constate souvent que cette modélisation constitue un patrimoine de valeur tant pour le test que pour le métier, et dont l’alignement avec l’application est garanti par la production des tests qui en découlent.

Suite à cette modélisation de processus, l’analyste de test procèdera peu à peu à la prise en compte des règles métier dans son modèle comportemental, décrit en UML. Ce modèle décrit d’une part les classes métier qui participent au test, d’autre part les règles elles-mêmes, utilisant les données contenues dans les instances de ces classes.

Figure 11 : Classes participantes

Le système SAP sous test (ou SUT), sera associé à un ensemble d’objets courants (PurchaseOrder, SalesOrder, etc. dans la figure ci-dessus) qui eux-mêmes posséderont des relations entre eux et des attributs valorisés en fonction du déroulement du test et des données introduites par le testeur lors de l’exécution. Ce sont ces objets et valeurs d’attributs qui seront utilisés pour contrôler le respect des règles métier.

Les règles métier sont également représentées dans le modèle UML, en utilisant le langage OCL, langage standard associé à la notation UML.

Figure 12 : Exemple de règle métier

L’écriture de la règle métier ci-dessus permet d’exprimer plusieurs choses : • Lesconditionsdanslesquelless’appliquecetterègle(ici,s’il

s’agit d’un centre de profit fermé),• Lesconséquencesde l’applicationdecetterègle (ici,

un message est affiché à l’écran indiquant le problème détecté),

• Laréférencepermettantdecontrôlerquecetterègleesteffectivement testée, identifiée dans l’exemple par une exigence (---@REQ) qui alimentera le référentiel de test lors de sa construction.

Figure 13 : Un test calculé dans Test Designer

L’interface de Test Designer sert à l’analyste de test pour contrôler l’évolution de son modèle, vérifier que toutes les règles métier sont atteintes par des tests et garantir la couverture des exigences. Une règle métier peut être détectée comme non atteignable, soit parce que cette règle a été mal codée dans le modèle, soit parce que les spécifications sont contradictoires. Dans ce dernier cas, l’analyste de test pourra remonter l’information à l’expert métier pour correction de la spécification. De cette manière, des erreurs coûteuses en développement, déploiement et opérationnel pourront être évitées au plus tôt.

L’analyste de test dispose, à tout moment, de la capacité à publier dans son référentiel de test les tests calculés ainsi que les liens de traçabilité avec les exigences conformes à ce qui a été indiqué dans les règles métier.

Figure 14 : Exigences dans HP Quality Center et liens de traçabilité

Comment ça marche ?


Figure 15 : Déroulement du test dans HP Quality Center pour le test manuel

Uniquement à partir des éléments provenant du modèle, la publication fournira un déroulement complet du test (étapes valorisées et résultats attendus), pour une exécution manuelle et si besoin pour une exécution automatique après création des scripts ou composants d’automatisation. L’exécution des tests ainsi publiés sera prise en charge de manière classique par les testeurs.

Synthèse et conclusion

L’approche décrite dans cet article :• constitueunaccélérateurdemiseenœuvredesprojetsSAP,

ainsi que de leur déploiement,• estàenvisagerpourtoutenouvelleimplémentationdeprojets

SAP ou de migration de version,• représenteunexcellentmoyend’urbaniserleréférentielde

tests, et la mise en œuvre de la traçabilité entre les exigences métiers et les cas de tests pour les systèmes SAP existants en maintenance,

• répondauxprincipauxobjectifs:réductiondesdélaisetdescoûts, accroissement de la qualité. n

Mohamed Bedouani, Corinne Jazé, Gaël Frèrebeau,Atos Origin

Atos Origin, l’un des principaux acteurs internationaux dans les services

informatiques, fournit des services transactionnels de haute technologie, des

solutions de conseil, d’intégration de systèmes et d’infogérance qui permettent

d’améliorer la performance de ses clients dans le monde entier. Atos Origin

réalise un chiffre d’affaires annuel de 5,1 milliards d’euros avec un effectif de

49 000 personnes. Atos Origin est le partenaire informatique mondial des Jeux

Olympiques et compte parmi ses clients de grands comptes internationaux

dans tous les secteurs d’activité. Le Groupe est coté sur le marché Eurolist de

Paris et exerce ses activités sous les noms d’Atos Origin, Atos Worldline, Atos

WorldGrid et Atos Consulting.

Site web : www.atosorigin.com

Arnaud Bouzy, Bruno Legeard, Geoffrey Potoczny,Smartesting

Fondée en 2003, Smartesting est un éditeur logiciel indépendant spécialisé dans

l’industrialisation du test fonctionnel. Smartesting est présent en Europe et en

Inde auprès des grands comptes et des intégrateurs pour fournir une solution

de génération de tests visant l’optimisation des centres de test. Cette solution

est intégrée et certifiée pour les outils de gestion de tests tels que HP Quality

Center ou IBM Rational Quality Manager. Elle garantit de produire et maintenir

au fil du temps le référentiel de tests à partir de modélisations métier intégrant

les processus, règles et entités métier.

Site web : www.smartesting.com

Références[1] « Vers une professionnalisation des tests au service de la rentabilité des entreprises »

M. Bedouani, T. Lallemand, P. Cogoluègnes - IT-expert N°72, pp 16, Mars/Avril 2008.[2] « Industrialiser le test fonctionnel - Des exigences métier au référentiel de tests automatisés »

B. Legeard, F. Bouquet, N. Pickaert - DUNOD 2009.

C o n f e r e n C e Idc G r e e n :L’IT AU SERVICE DE L’EFFICACITE/EFFICIENCE ENERGETIQUE AU DELA DES EFFETS DE MODE, QUELS VERITABLES ENJEUX, QUELLES

MESURES CONCRETES, QUELS BILANS?

Le décalage peut paraître important entre la vague marketing autour du Green IT depuis quelques années et les mesures concrètes prises par l’entreprise. Il n’en demeure pas moins que la problématique du développement durable reste incontournable dans les objectifs et les politiques de fonctionnement des entreprises en France, en Europe et dans le monde entier.

Si l’un des enjeux des NTIC est d’accompagner l’évolution des mentalités et la transformation des entreprises vers une performance à la fois économique, environnementale et durable, à très court terme, la capacité de la DSI à réduire sa propre empreinte carbone constitue néanmoins un premier pas non négligeable.

Idc vous donne rendez-vous jeudi 18 novembre 2010 (9h–14h)

Participez à la conférence Idc Green le 18 novembre 2010, à Paris pour:

dresser le bilan et faire le point sur les différents projets mis en place à ce jour. •analyser ensemble quelles sont les bonnes pratiques, quels sont les leviers opérationnels et •

technologies à votre disposition. étudier quels sont les méthodologies, les indicateurs et les outils de mesure disponibles à cet effet.•

PROGRAMME dETAILLE ET INScRIPTION GRATUITE :

http://www.idc.fr/green10

code invitation « ITX »

OU cONTAcTEZ EdITH TRIcHEUX : [email protected] - tel. : 01.56.26.26.91

Au programme :

Quelles sont les normes à suivre en matière d’efficacité énergétique ?•La mutualisation des besoins constitue-t-elle une réelle économie ?•Le nouvel espace de travail est une réponse efficace, mais comment le •

définir ?Déchets, transports, stocks: de bons exemples dupliquables?•Quels indicateurs définir pour réaliser quelle analyse, quel contrôle ?•Une démarche pragmatique, à défaut de suffire, peut-elle consister en •

une approche pas à pas ? Quelles seraient les prochaines étapes de la route vers le Green IT ?

Avec le retour d’expérience de : Philippe ROUAULT, dSI, FranceTélévision

René-Yves LABRANcHE, dSI, Ville de chelles et de la communauté d’Agglomération Marne et chantereine

Michel JUVIN, Group Information Security Officer, LAFARGE

Conférence organisée par

en partenariat avec

IDC, cabinet leader de conseil, et d’études dans les technologies

de l’information.

CFF23_AV_A4_GreenIT.indd 1 13/09/2010 17:16:19


Au fil des années, les DSI se sont vues de plus en plus « challengées » (gains de productivité, contrôle interne, attentes

accrues de ses clients…), questionnées (sur les référentiels normatifs, les nouveaux standards, les indicateurs de

performances…), etc. Ces phénomènes ont amené les DSI à évoluer et à se transformer. Au cœur des moyens leur permettant

de répondre efficacement à ces exigences de transformation se trouve la refonte de leur organisation et de leur processus. Ces

derniers peuvent, ou non, s’appuyer sur les référentiels et bonnes pratiques de type COBIT, ITIL, CMMi…, mais dans tous les

cas se posent les questions, pour ceux qui ont en charge de mener à bien ces projets de transformation, de l’adhésion à ces

changements et de la réussite de leur mise en œuvre. Les « chartes » sont de plus en plus couramment utilisées au sein des

DSI pour favoriser l’appropriation des processus.

Une charte pour réussir la mise en œuvre de vos processus SI

Quoi de neuf Docteur ?


La refonte des processus englobe de multiples acteurs

La refonte des processus SI devient une nécessité pour améliorer la qualité des services rendus et l’efficacité globale de la fonction informatique au sein de l’entreprise. Cette refonte impose un travail non négligeable qui démarre par l’identification, la définition et la formalisation de processus.

Les DSI sont alors souvent confrontées aux difficultés suivantes : • Commentchoisirlanouvellearchitecturedeprocessus?• Quellessontlesfrontièresentrelesprocessusexistantsetlesprocessusfuturs?• Commenttrouverunéquilibreentrelacontinuitéculturelleetlaruptureinévitablequiconsisteà

intégrer de nouvelles pratiques ? Quelles formalisations ? • Quelsacteursimpliquer?…

Il est intéressant d’adopter une démarche de construction commune avec les équipes, non seulement internes à la DSI mais aussi clientes et partenaires, qui mettront le nouveau processus en œuvre. Associer ces différents acteurs à la définition du processus, aux relectures et aux validations des descriptions permet d’amorcer l’appropriation des processus par chacun d’entre eux.

Conduire le changement

Les différents écueils de la conception et de la réalisation des nouveaux processus surmontés, la partie est loin d’être gagnée. En effet, comme pour tout projet, la réussite d’un projet de refonte des processus se mesure à son utilisation. Il s’agit d’un réel projet de transformation de la DSI, qui se doit d’être accompagné comme tel.

Indépendamment du besoin et de la justification de celui-ci, il est souvent difficile de faire adhérer tous les intéressés et surtout de mettre en œuvre ces nouveaux processus. Le respect de processus partagés et des contraintes associées sont en effet trop souvent perçus comme des leviers d’audit ou de contrôle ainsi que comme une charge de travail supplémentaire.

Verbatim des commentaires lors de la mise en place de nouveaux processus :On entend souvent dans les couloirs, « Encore de la théorie ! J’ai réussi à faire ça avant ! J’connais mon métier ! », ou encore « C’est trop lourd ! Quelle perte de temps ! Ce n’est pas comme ça qu’on va être réactif ! », et puis « Ils sont bien gentils, mais je fais comment moi opérationnellement ? ».


Le défi consiste donc à changer la perception des différents acteurs et faire en sorte que les processus soient compris comme des outils d’assistance et de conseil favorisant la réussite de leurs activités en optimisant coûts, délais et qualité.

Comment faire pour relever ce défi ? Existe-t-il des outils qui facilitent le déploiement et la mise en œuvre d’un processus ? La conduite du changement menée autour du projet sera une activité centrale. Autour de cet axe, un levier de communication consiste à rédiger et diffuser une « Charte synthétique » du processus, sorte de mémento du processus.

La « charte synthétique » : une réponse simple et efficace

Dans ces contextes de mise en œuvre de nouveaux processus, la charte est le document synthétique présentant les principes essentiels du processus de manière simple et conviviale. À titre de com-paraison, en droit, une charte se définit comme « Un écrit solennel où sont consignés des droits et /ou des grands principes ». Dans cette même logique, la charte doit permettre à son destinataire de trouver l’ensemble des informations nécessaires dont il aura besoin quotidiennement et de manière opérationnelle.

Nous observons que cette « charte » est le plus souvent utilisée pour accompagner la mise en place du nouveau processus de conduite de projet. Elle est aussi utilisée pour faciliter le déploiement d’autres processus, comme : • Lagestiondeschangements(ouanciennementlamaintenancedanslevocabulaireITIL);• LaGouvernanceSIdel’entreprise;• L’urbanismeduSIet/oul’architectured’entreprise(etmodalitésd’application);• LagestiondesréférentielsdesdonnéesSI;• …

Cette « charte » peut couvrir un processus ou concerner un groupe de processus. Dans tous les cas, elle émane d’un souhait de pédagogie à large diffusion.

Créer sa propre charte…

Avant de se lancer dans la réalisation d’une charte, il est essentiel d’être au clair sur les objectifs recherchés et de partager ceux-ci avec le management de la DSI et les sponsors de la refonte des processus. • Quesouhaitepartagerlesponsoravecseséquipes?• Ya-t-ilunevolontéd’homogénéiserlevocabulaireutilisé,dedisposerdephasesetdelivrables

communs ? • Quelleestlamaturitévisée?• Quelleestlaformalisationsouhaitée?• Unprocessus,uneméthode,debonnespratiques,unoutillage…?• Quelssontlesrésultatsescomptés?…

Répondre à l’ensemble de ces questions est fondamental pour l’équipe Projet. Ainsi, la charte sera adaptée au contexte et aux enjeux particuliers de la DSI.

On constate souvent que les chartes synthétiques répondent à des objectifs communs comme :• Produireundocumentàvocationdecommunicationlarge,àdestinationdesinternesdelaDSI,des

clients de la DSI, voire de ses sous-traitants ;• Partagerunminimumcommunetfaireconvergerl’ensembledesentitéspartiesprenantes;• Obtenirlamobilisationdumanagementpourfaciliterlamiseenœuvredesprocessusetlesfaire

adhérer, permettant ainsi de faciliter l’adhésion de l’ensemble des acteurs de leur service ;• Obtenirl’adhésiondesacteurspourunemiseenœuvredunouveauprocessusparl’ensembledes

nouveaux projets ;• Mettreenavantlesbonnespratiquesissuesdesréférentiels(CMMi,COBIT,ITIL)oudesexpériences

des acteurs internes.


Même si des questions communes se posent pour la réalisation de toute charte (Quels objectifs ? Quel format ? Quel contenu ? Quel niveau de maille ?…), les réponses doivent quant à elles être spécifiques et adaptées à chaque contexte. Elles doivent ainsi notamment tenir compte de :• Latransformationsouhaitée• Lacibleàatteindre• L’organisationenplaceet/oufuture• Laculturedel’entreprise• Lesacteursimpactésetleurréactionfaceauchangement

Une charte réussie est incarnée par un document « sur mesure », adapté à un contexte donné.

… tout en retenant de bons principes mis en œuvre ailleurs

Pour réussir sa charte synthétique, au-delà des objectifs clairement identifiés, il est important de ne pas minimiser l’importance de la conduite du changement dans ce projet plus global de refonte de processus qui représente une réelle transformation pour la DSI et ses clients et partenaires.

Avant d’initier les travaux de réalisation d’une charte, il est recommandé de :• PenserlarefonteduprocessusavanttoutcommeunprojetdetransformationpourlaDSIetdonc

ne pas minimiser le volume de la conduite du changement ;• Impliquertrèstôtlesdifférentsacteursdansladémarcheàtraversunecoconstructiondemanière

à prendre en compte les réelles attentes et minimiser les déceptions potentielles ;• Impliquerets’appuyersurlemanagementafind’avoirdesrelaispourlaconduiteduchangement

qui portent la volonté et l’importance des processus DSI ;• Raisonnerentermesdecibleetdetrajectoire,c’est-à-diredéfiniruncycled’améliorationscontinues

et faire évoluer le processus au fil des revues ;• Nepaspenserquelachartesuffit!Eneffet,lacharten’estquelasynthèsed’uneanalyseetrefonte

plus importante.

Forme et contenu : deux questions essentielles

Un des enjeux majeurs et une des premières difficultés consiste à définir « la bonne maille ». Ce bon niveau de maille découle des objectifs et donc des messages à faire passer. Par exemple, un outil de clarification des rôles et des responsabilités simple et efficace comme une matrice RACI (Responsible, Accountable, Consulted, Informed) a-t-il sa place dans une charte synthétique ? Ou peut-être en faut-il une version adaptée, simplifiée ? Ou tout simplement, n’est-ce pas sa place ?

Il n’existe aucune réponse standardisée, il s’agit de revenir à l’essence même du projet de transformation, à ses attentes : Quel est le besoin ? Quels sont les objectifs du processus ? Sur quoi les personnes concernées par le processus attendent-elles des réponses ? Si un des axes essentiels de la refonte des processus est justement la clarification des rôles et des responsabilités de chacun ; si les équipes opérationnelles sont demandeuses de mieux comprendre qui fait quoi, qui valide quoi… alors la précision d’un RACI (bien que faiblement « sexy ») devra être intégrée à la charte. Inversement, si chacun connaît clairement son rôle, alors peut-être vaudra-t-il mieux axer les messages sur d’autres sujets.

Cet exemple du RACI montre encore une fois qu’en matière de réalisation de charte il n’existe pas de réponses toutes faites et que pour être une réussite la charte doit être adaptée à son contexte et à des objectifs propres. Cependant, si nombre de questions trouvent leurs réponses au sein de la DSI qui les pose, l’expérience montre que certains principes directeurs demeurent.


Ce qu’il faut garder à l’esprit pour réaliser sa charte…

Penser communication…La charte doit attirer le lecteur et faciliter sa compréhension du processus. Pour cela et afin de mettre en valeur les éléments clés, des codes couleur ainsi que des formats particuliers peuvent être définis. Ils permettront aux lecteurs de se repérer tout au long de la charte et de trouver les informations qu’ils recherchent en « un coup d’œil ». La compréhension peut aussi être facilitée en réalisant une présentation en « entonnoir » qui offre une vision d’ensemble du processus et le met en perspective par rapport à l’organisation. Pour cela, il peut être intéressant par exemple de positionner le processus dans la cartographie générale et de mettre en avant les articulations entre ces derniers.

Pour que la charte attire l’œil du lecteur et facilite sa compré-hension, soyez ludique !

Être synthétique et précis…La charte étant un outil de communication à large diffusion, il est important de communiquer efficacement en restant synthétique. L’utilisation de schémas ou de tableaux simplifiés, mais précis facilite la lecture en « un coup d’œil ». L’utilisation d’une forme facile d’accès pour tous est recommandée. Par exemple, il peut être intéressant pour le lecteur de lui offrir un résumé synthétique, très précis et visuel de chacune des phases en portant les messages clés et l’esprit du processus. Le lecteur sera aussi souvent intéressé par son rôle à jouer au sein du processus, ses responsabilités, etc.

Penser la charte comme un outil de « teasing »…La charte attire le lecteur… elle lui donne envie d’aller plus loin et de lire le détail du processus. Pour inciter le lecteur, des liens vers les autres documents ou vers d’autres sources d’information peuvent être insérés.

Pour inciter le lecteur à aller plus loin, favorisez une communication sur « l’esprit » du processus, plutôt que sur la « lettre ». D’autres éléments peuvent aussi être pris en considération pour faciliter ou inciter à la lecture de la charte, comme un édito du DSI, crédibilisant les travaux réalisés et « leurs donnant du poids », ou le mode de diffusion de la charte.


Diffuser la charte : une étape-clé de la transformation

La charte réalisée, se pose alors la question de sa diffusion. Pour qu’elle soit utile et atteigne son objectif de « facilitateur de transformation », elle doit être lue et donc communiquée et accessible aux utilisateurs. Trois questions essentielles se posent alors autour de sa diffusion : Quel format ? Quel canal ? À quel moment ?• Enformatpapier,laremisedelachartepeutsefaireenmainproprepourchaqueacteur,enréunion

spécifique ou de service, en dépose sur les bureaux, etc.• Enformatélectronique,lachartepeutêtreenvoyéeparemail,déposéesurunebasedocumentaire

ou à l’aide d’outils collaboratifs, etc.

Dans la mesure du possible, pour accroître son impact, il est préférable :• Deremettrelacharteenmainpropre;• D’associerladiffusiondelacharteàunévénementliéauprocessus(réuniondeprésentation,réunion

de service…).

De même, cette diffusion peut se réaliser en plusieurs vagues successives. Tout d’abord, en amont du déploiement, la charte est transmise aux managers. Cette diffusion pré-déploiement leur permet de s’approprier le processus en amont de leurs équipes. Ils deviennent ainsi des « référents » à même d’accompagner leurs équipes sur leurs travaux.

La diffusion aux acteurs opérationnels, touchés directement par la mise en œuvre du nouveau processus, se fait au moment du déploiement. La distribution peut, par exemple, avoir lieu au moment des sessions de sensibilisation ou de formation au processus.

Enfin, la charte pourra être distribuée à chaque nouvel arrivant du service dans son kit d’accueil. De façon plus large, la charte est très utile comme outil de communication et de transformation de la DSI auprès de ses clients/MOA et de ses contributeurs (sous traitants ou fournisseurs)

Une charte, mais pas uniquement…

Quelles que soient les modalités de diffusion, il est essentiel de ne pas oublier que la charte s’inscrit dans une dynamique de conduite du changement plus large. Elle ne saurait à elle seule tout porter, même si elle est souvent la clé de voute de la réussite de cette conduite du changement et donc de la mise en œuvre du processus. Ainsi les bonnes pratiques de conduite du changement ne doivent pas être oubliées.

Enfin, pour faciliter encore l’adhésion et la mise en œuvre du processus, d’autres « outils » peuvent venir en complément de la charte, comme :• Unefeuillederoutededéploiement,regroupantlesactionsàréaliserpréalablementàlamiseen

œuvre du processus pour en garantir la bonne application (actions à réaliser par les équipes de Management, actions à demander aux équipes opérationnelles par les managers…) ;

• Basedocumentaire,présentantparexemplelesdifférentslivrablesduprocessussousformedeplan type et/ou de guide de rédaction ;

• Uneéquipesupport;• UneFAQ;• Unespaceauseind’unoutilcollaboratif;• …

Exemples de critères à prendre en compte pour la diffusion :

•Lenombredepersonnesciblées•L’accèsauxciblesvisées,dépendant: - des « des cibles visées » - de la « géographie » : multi-sites ? International ? - des média de diffusion disponibles en interne

et réellement utilisés•Le«formatdefichier»delacharte - possibilité de pdf ?•Délaisdereprographieéventuels•Lescoûts•…


Un document de référence

La charte synthétique est un outil de communication efficace qui vise à devenir « la » référence de l’ensemble des acteurs du processus concerné. Il s’agit d’un outil qui en aucun cas ne peut se substituer à un processus détaillé.

La charte permet de mobiliser les acteurs clés et contribue fortement à la réussite du projet de transformation de la DSI, mais s’inscrit aussi dans la durée en facilitant l’intégration de nouveaux arrivants. Pour ce faire, il est nécessaire que les messages clés y soient synthétisés et que les informations sur chacune des étapes du processus soient très précises sans être totalement détaillées.

La charte est donc un outil « sur-mesure » réalisé pour une organisation en fonction de son contexte.Vous saurez si votre charte est une réussite si elle est présente sur les différents bureaux, non seulement en interne de la DSI, mais aussi des clients. Elle devient le document de référence, le recours à la description du processus détaillé permettant de répondre à des questions plus rares. n

Quelques facteurs clés de succès :

• Pensercommunication,êtresynthétique,maisprécis• Êtreludiqueets’appuyersurl’équipedecommunicationenplace• Communiquersur«l’esprit»duprocessusetnonpassurledétail• Utiliserlachartecommeunoutildeconduiteduchangementparmid’autres• Impliquerlemanagementgrâceàlachartedanslaprisededécisionetlamiseenœuvre

du processus • Êtreconscientquelachartenesesubstituepasàladéfinitionduprocessusdétaillé

mais le synthétise et sert de mémento en communiquant sur les messages clés• Essayeraumaximumdedistribuerlacharteauformatpapier,voiredelaremettre

en main propre.

Éric Brouillaud, Éloïse Montaulieu,Manager responsable Consultante de l’activité « charte synthétique »

Éric Brouillaud a conduit différentes missions ayant trait à l’optimisation et la diffusion des processus SI dans les DSI, et rédaction de chartes sur différents processus.

Éloïse Montaulieu a réalisé différentes missions de conduite du changement et réalisé plusieurs chartes synthétiques sur des processus de DSI comme la conduite de

projet ou la maintenance.

Acteur majeur du conseil en management, organisation et SI, ORESYS est une société indépendante de 250 consultants basés à Paris, Lyon et Bruxelles. Spécialisée dans

les projets de transformation, ORESYS aide ses clients à piloter leurs activités, améliorer leur performance et mettre en œuvre leurs projets de transformation. ORESYS

intervient sur toutes les dimensions : métiers, organisation, processus, système d’information, accompagnement du changement. ORESYS intervient de manière soutenue

pour aider les DSI à transformer leur organisation et leurs processus, ou à transformer l’entreprise.

Site web : www.oresys.eu

Livres


Lean Management… l’informatique conviviale

Surprenant de traiter de sujets comme : « les voies d’amélioration du fonctionnement de l’entreprise par le biais de l’informatique. Pour travailler mieux et plus vite, avec les mêmes personnes et à budget constant », ou le lean management. Une fois passée la première surprise, le lecteur suit cette aventure narrée à la première personne avec de nombreux dialogues parfois conflictuels et souvent amusants par leur réalisme… Également pédagogique, l’ouvrage propose des concepts et des approches habillement distillés (et parfois illustrés). Si pour les besoins de la démonstration le scénario est parfois très optimiste, le lecteur y trouvera pourtant son compte. Après l’accompagnement d’un coach / consultant qui le fait accoucher de ses idées et l’aide à les structurer, l’auteur endosse ce rôle envers ses pairs et sa hiérarchie. Les états d’âme du héros et les réactions des personnages donnent au récit un air de vérité savoureux. Pierre Pierrazzi, membre fondateur et directeur technique d’Octo Technology, connait bien ce terrain… miné.

À découvrir aussi pour lire ou contribuer : http://informatique-conviviale.eyrolles.com

Lean Management - Mieux, plus vite, avec les mêmes personnesPierre PierrazziÉditeur : Éditions d’Organisation166 pages - environ 20 E

Le management de la continuité d’activité

Le système d’information est devenu le centre nerveux de la plupart des entreprises. Cependant, la mesure de la disponibilité des applications se résume encore parfois au temps de fonctionnement des ressources matérielles. La mise en place d’un PCA (plan de continuité de l’activité) permet de mener une politique proactive en anticipant, plutôt que de subir des ravages sans disposer de plan de secours. Cet ouvrage propose une démarche organisationnelle et technique détaillée et exposée de manière pédagogique. Le lecteur y trouvera certainement de nombreuses idées pour étayer ses réflexions et son discours pour justifier de tels projets, indispensables.

Consultant associé chez Duquesnes, l’auteur conseille de grandes entreprises sur la continuité de service, les bonnes pratiques de production de service (ITIL, sécurité…), etc. Dans ce livre, il offre de nombreux tableaux et rapports réutilisables et très pratiques.

Le management de la continuité d’activité Emmanuel BesluauÉditeur : Eyrolles254 pages - environ 39 E


Le MDM multidomaine : une vision à 360°

Rubrique à brac


e Master Data Management ou MDM est sous le feu des projecteurs depuis le début de cette année 2010 avec plusieurs annonces des principaux acteurs informatiques concernant leur expertise renforcée dans ce domaine.

Cet intérêt pour le MDM n’a cessé de croître depuis 2009 et les entreprises l’ont pour la plupart dans leurs radars. D’après une étude indépendante, 40 % des entreprises prévoyaient en 2009 de mettre en œuvre un logiciel de MDM ou d’étendre l’utilisation de leur logiciel existant (« Trends 2009: Master Data Management », Forrester Research, October 2009). Un autre analyste de premier plan prévoit qu’en 2010 les ventes de logiciels d’infrastructure MDM atteindront 1 milliard de dollars, soit 50 % du marché total des logiciels de MDM, avec une croissance de 20 %.

Le MDM permet d’avoir une vue complète et unifiée des éléments métiers fondamentaux communément appelés données de référence, telles que les données sur les clients, les employés, les citoyens, les fournisseurs, les organisations, les sites et les produits. Les initiatives MDM réussies se traduisent par des gains d’efficacité opérationnelle, une amélioration de la fidélité client et une gestion facilitée de la conformité. Il n’est donc pas étonnant dans le contexte économique actuel que le MDM soit devenu une priorité.

Est-ce urgent d’investir dans le MDM ? Le cas de l’intégration des données client est l’un des plus explicites pour comprendre quels sont les enjeux d’un tel investissement et en quoi il devient incontournable. Côté mise en œuvre, les entreprises ont le choix entre une approche par application ou par plate-forme. Aussi, nous vous proposons de comparer les deux pour déterminer la plus avantageuse.

Dépasser les limites de l’intégration de données clients

Les pionniers de l’intégration de données client (Customer Data Integration ou CDI) visaient un objectif unique : améliorer les opérations orientées clients, telles que le marketing, les ventes, l’offre de services et la facturation, en fournissant une vue unique du client. Nombre d’entreprises ont ainsi opté pour la technologie de CDI qui leur permettait de rapprocher les données clients incohérentes, inexactes et incomplètes qui existaient dans différents formats et dans divers systèmes au sein de l’entreprise. Les autres données métiers critiques – comme les comptes, les produits, les contrats, les partenaires distributeurs et les employés – étant considérées comme inutiles, elles étaient laissées pour compte.

Bien que la vue unique du client offre des avantages certains, nombre d’entreprises ont compris avec le recul que leurs projets de CDI restreignaient considérablement la valeur métier. Les opportunités et les besoins métiers se limitent rarement à une dimension unique – par exemple au client seul ; ils sont généralement reliés – clients, comptes, foyers, employés et relations entre ces éléments – et requièrent donc une solution de gestion des données de référence (MDM) multidomaine.

Les limites de la CDI

Imaginons Banque Tradition, une société de services financiers offrant aux particuliers et aux PME une large gamme de services bancaires, d’investissement et de confiance. Son projet de CDI lui a permis de bénéficier d’une vue unique des clients en offrant aux équipes orientées clients le moyen de savoir si elles interagissaient avec un particulier, comme John Quincy Jones, ou une petite entreprise, comme Jones Consulting. Toutefois, le système de CDI représentait une solution limitée du fait qu’il n’offre pas au personnel orienté clients de visibilité sur les relations entre ses clients, ses entreprises (par exemple un employeur ou une filiale) et ses comptes. Les conseillers financiers et les prestataires de services, par exemple, ne pouvaient pas savoir que le client commercial John Jones, propriétaire de Jones Consulting, était la même personne que le particulier investisseur John Jones. Ils ignoraient donc qu’il possédait à la fois un compte chèques entreprise et un compte de courtage particulier. Deux problèmes majeurs en ont résulté :• lesprestatairesdeservicesnepouvantpasapprécierla

juste valeur du client, ils ne lui ont pas offert le bon niveau de service, compromettant ainsi sa fidélité ;

• lesconseillersfinanciersnepouvantpasfaired’offresincitatives ou croisées pertinentes visant à augmenter la part de marché du client, la banque a perdu des revenus.

Le MDM multidomaine pour exploiter les opportunités

Même si la vue unique des clients constitue une première étape importante, la valeur métier qu’elle génère est purement incrémentale. L’optimisation de la valeur métier requiert des étapes supplémentaires. L’étape suivante consiste à activer la vue des clients à 360° – en associant la vue unique des clients à l’ensemble de leurs comptes ou de leurs produits à l’échelle de l’entreprise. La dernière et la plus lucrative des étapes consiste à offrir une vue des clients élargie – affichant l’ensemble des relations pertinentes entre le client et sa famille, son travail et les employés de banque, en plus d’associer la vue unique du client à l’ensemble de ses comptes ou de ses produits. Voir figure ci-dessous.

L’évolution d’une vue unique des clients en vue à 360°, puis vue en élargie

Vue élargie du client

Vue uniquedu client

Vue du client à 360°

Vue unique du client + Produits et services+ Relations pertinentes avec la famille,le travail et les employés

Vue unique du client+ Produits et services

Une vue complète,exacte et cohérentedes données clients

Relationsdu foyer

Épouse

Enfant 1

Enfant 2

Père

Mère

Enfant 3

Relationsextérieuresau foyer

Relationsavecles employés

Agent de change

Analyste financier

Relationsprofessionnelles

J.Q.Jones

J.QuincyJones

ProduitA

A

D

B

F

B

E

B

B

H

B

G

B

I

ProduitB

ProduitC

ProduitD

J. Jones JonathanJones

JonathanQuincy Jones


Imaginons désormais Banque Avenir, concurrent de Banque Tradition avec le même modèle métier. L’équipe de Banque Avenir a compris que pour optimiser la valeur métier, la solution devait aller au-delà de la simple identification et correction des clients commerciaux et particuliers pour s’étendre en vue à 360°, puis en vue élargie.

L’équipe informatique était parfaitement consciente que les problèmes et les opportunités métiers de Banque Tradition étaient multidimensionnels et touchaient à des données allant au-delà des données clients. C’est pourquoi l’équipe a utilisé une plate-forme de MDM multidomaine prenant en charge différents types de données. Bien que partageant le même objectif que Banque Tradition, c’est-à-dire l’amélioration des opérations orientées clients, la valeur métier générée par la solution de MDM multidomaine de Banque Avenir était bien supérieure. Les équipes orientées clients ont gagné en visibilité sur les relations, au sein du foyer comme à l’extérieur – elles pouvaient afficher les relations que le client entretenait avec son époux/épouse, ses enfants et ses parents, ainsi que l’ensemble des activités commerciales et des entreprises auxquelles il était associé. En outre, elles pouvaient afficher l’ensemble des produits partagés et individuels et identifier les employés de banque, tels que les conseillers financiers ou les agents de change, qui travaillaient avec le client de façon rapprochée.

De ce fait, l’équipe de Banque Avenir a triplé sa valeur métier :1. Amélioration de la rentabilité et de la fidélisation des clients :

les prestataires de services ont pu mesurer avec exactitude la valeur de chaque client et aligner les niveaux de services sur cette valeur.

2. Augmentation des revenus : les conseillers financiers ont pu proposer des offres de ventes croisées ou incitatives pertinentes et augmenter ainsi la part de marché de chaque client.

3. Augmentation de la rapidité et de la flexibilité : l’équipe informatique a pu s’adapter en toute flexibilité à l’évolution des besoins métiers et supporter ainsi les impératifs stratégiques.

Ce scénario financier n’est qu’un exemple parmi d’autres. Les entreprises d’autres secteurs, comme l’industrie, les biens de consommation courante, l’industrie high-tech, les médias, l’énergie, la santé, l’industrie pharmaceutique et l’administration ont migré avec succès de la CDI au MDM dans l’optique de générer une forte valeur métier au profit de leurs entreprises. Un géant de la pharmacie dont le déploiement a été primé en est la parfaite illustration : il est parvenu à étendre son initiative de CDI au-delà des données clients pour y inclure les contrats, les entreprises, les canaux de distribution et la tarification.

Extrêmement efficace, le système qu’il a créé utilise les relations de différents types de données pour :• Traiterlespaiements,lesremboursementsetlesconflitsde

façon plus précise.• Créerdesindicateursdeperformanceetdesrapportsfiables.• Mieuxseconformeràlaréglementation,parexempleàlaLoi

Sarbanes-Oxley qui nécessite le contrôle des données.• Augmenterlesniveauxdeservicesgrâceàlaprévention

des erreurs, l’exactitude des commandes, la ponctualité des paiements et l’amélioration des expériences de bout en bout.

• S’adapterplusrapidementàl’évolutiondumarché.• Accélérerl’introductiondenouveauxproduitsdanslescanaux

de vente.• Optimiserlarecherchedenouveauxclientsetlanégociation

de nouveaux contrats.• Améliorerledélaiderésolutiondeséventuelsproblèmes.• Gérerlesdonnéesetrésoudreleserreursliéesàlasignaturede

contrats, aux finances et à la chaîne logistique, en mobilisant moins de ressources.

• Réduireletauxd’échecs,deconflitsnonrésolusetdedéductions.

De la CDI vers le MDM en 5 étapes clés

Le MDM multidomaine vient parfaire la CDI en offrant une solution allant au-delà de la simple vue unique du client. La migration de la CDI vers le MDM s’opère en cinq étapes :1. Identification du besoin métier dans sa globalité – Les

conséquences du manque de fiabilité des données touchent généralement plusieurs domaines de l’activité. La correction des données clients ne résoudra pas le besoin métier. Identifiez les composants du besoin métier dans sa globalité.

2. Prise en compte des utilisateurs métiers – même si l’équipe informatique implémente une solution permettant de résoudre un problème de données, ce sont les équipes métiers qui utilisent les données. Faites-les participer au processus de recherche permettant de déterminer les types de données et les relations entre données à prendre en compte pour résoudre définitivement le problème.

3. Création d’une vue unique du client – Rapprochez les données incomplètes, incohérentes et dupliquées enregistrées dans différents formats et dans divers systèmes au sein de l’entreprise.

4. Vue du client à 360° – Intégrez à la vue unique du client les comptes associés au sein de l’entreprise.

5. Vue élargie du client – Élargissez la vue du client à 360° en y ajoutant les relations familiales, professionnelles et celles qu’entretient le client vis-à-vis des employés de banque, données importantes jusqu’à présent inexploitées.

Rubrique à brac


Certaines entreprises ayant sélectionné uniquement une solution de CDI n’ont pas pu dépasser la troisième étape, limitant ainsi leurs avantages commerciaux. A contrario, d’autres entreprises ont investi dans le MDM multidomaine, ce qui leur a permis de se hisser jusqu’aux étapes quatre et cinq et de profiter de leur aspect lucratif. Ces visionnaires ont surmonté les restrictions qui leur étaient imposées par leurs initiatives de CDI et généré une valeur métier importante au profit de leur entreprise, notamment une augmentation des avantages, des revenus, de la flexibilité et de la rapidité. En suivant les traces de ces visionnaires, une société se met sur la bonne voie pour profiter de l’initiative de MDM multidomaine étendue.

MDM multidomaine : application ou plate-forme ?

En matière de MDM multidomaine, deux approches sont possibles : une approche par application et une approche s’appuyant sur une plate-forme MDM. Toutes deux peuvent résoudre les problèmes métiers qui résultent de l’utilisation de données inexactes, incomplètes et incohérentes. Cependant, comme nous l’avons constaté, les problématiques métiers sont complexes et peuvent être liées, ce qui demande une approche englobant toutes les données clés – clients, comptes, ménages, salariés… – et les relations entre ces données.

Une approche MDM par application a une faible portée parce qu’elle ne peut résoudre que le besoin métier pour lequel elle a été conçue. Et ce, même si d’autres processus métiers font appel au même type de données. Cette approche aboutit à la création de silos MDM. L’approche fondée sur une plate-forme MDM ouvre des perspectives plus larges en permettant de résoudre d’autres besoins métiers à l’aide d’une même plate-forme. Quelles sont les implications de ces deux approches et les bonnes pratiques pour réussir une initiative de MDM multidomaine ?

Éviter le piège des silos de MDM

Certaines technologies proposées sur le marché de la gestion des données de référence (MDM) sont à l’origine d’une idée fausse, selon laquelle les solutions de MDM seraient conçues

pour ne traiter qu’un unique besoin métier à la fois. En vérité, il en est tout autrement. Le principe fondateur de la gestion des données de référence est de résoudre plusieurs problèmes métiers complexes, quels que soient les départements, services, divisions ou régions concernés, en évitant de créer une solution de MDM différente pour chaque besoin métier.

Le génie et la valeur de la gestion des données de référence résident justement dans sa capacité à traiter un besoin métier particulier, puis à s’adapter afin de résoudre les autres problèmes métiers. Bon nombre d’entreprises en sont conscientes et tirent profit de leurs investissements en matière de MDM multidomaine pour résoudre de nombreux besoins métiers, tels que l’optimisation de la pénétration et de la couverture de comptes, l’amélioration de leurs prestations de service, le lancement efficace de nouveaux produits, une précision accrue en matière de reporting et une amélioration en termes de conformité. Malheureusement, certaines entreprises se laissent prendre au piège et continuent d’accroître leur nombre de silos au lieu de le réduire.

Étude comparée des deux approches

L’application ou la plateforme de MDM permettent toutes deux de traiter un besoin métier urgent généré par des données incohérentes, incomplètes ou inexactes. Cependant, l’approche applicative manque d’envergure, car elle se cantonne à résoudre le besoin métier pour lequel elle a été conçue. De par son modèle de données, sa logique métier ou sa fonctionnalité prédéfinis, ainsi que son interface graphique spécifique, elle ne permet pas la prise en charge d’autres besoins métiers. Cette démarche est comparable à l’achat clé en main d’une application d’automatisation des forces de vente (SFA) pour gérer le système de vente ou d’une application d’achat pour gérer les commandes de matériel directement ou indirectement liées à la chaîne logistique. L’aspect paradoxal de cette approche réside dans l’augmentation du nombre de silos de données et des dépassements budgétaires qu’elle entraîne inexorablement. Puisqu’elle se base sur l’application plutôt que sur les données, nous disons de cette approche qu’« elle est contraire au bon sens ». Voir figure ci-dessous.

Approche « contraire au bon sens »

Approche « fidèle au bon sens »

Logique métier

Interface utilisateur

Modèle de données

Illustration de la différence entre approche de MDM par application, « contraire au bon sens », et approche de MDM par plate-forme, « fidèle au bon sens »


La plate-forme de MDM diffère par sa portée plus vaste. La même plate-forme de MDM est ainsi en mesure de résoudre d’autres besoins métiers. Cette approche engendre un meilleur retour sur investissement, car l’investissement en matière de technologie de MDM peut s’adapter et s’atteler à la résolution d’autres besoins métiers au sein d’une division, ainsi que des besoins métiers d’autres divisions, services ou régions. La gestion des données de référence par plate-forme est indépendante des modèles de données et des domaines. Elle permet aux organisations de bénéficier d’une certaine flexibilité dans la définition de leur propre modèle de données, de générer une logique et une fonctionnalité basées sur ce modèle et de prendre en charge la configuration de l’interface graphique en fonction de ladite fonctionnalité. Cette approche réduit le coût total de possession et accélère le processus de rentabilisation. Puisque cette approche s’appuie sur les données, nous disons qu’« elle est fidèle au bon sens ».

Le MDM par plate-forme en vue de l’amélioration des processus d’une chaîne logistique

Par exemple, un fabricant comptant parmi les entreprises du Fortune 50 décide de tirer parti d’une approche de MDM par plate-forme afin d’améliorer les processus de sa chaîne logistique en matière d’achats et de ventes – notamment pour accroître l’efficacité des achats de matériels directs et indirects et pour améliorer la distribution des produits. Ces besoins métiers complexes impliquent la gestion des données de référence relatives aux fournisseurs, aux clients, aux matériels et aux produits. La mise en œuvre d’une solution d’intégration de données clients (CDI) ou de gestion des informations Produits (PIM) ne permet de résoudre qu’une seule dimension de ces besoins métiers. Ce type d’approche de MDM par application empêche l’entreprise de tirer parti de son investissement technologique afin de traiter d’autres besoins métiers qui mettent en jeu les mêmes types de données.

Implications liées à l’approche par application ou « contraire au bon sens »

Imaginez que ce groupe informatique adopte une approche de MDM par application ou contraire au bon sens. Ils auront résolu le besoin métier urgent de la conformité, mais son approche ne lui permet pas de traiter les autres besoins qui ne manqueront pas de survenir. Exemple parmi les plus courants : six mois après le passage au nouveau système, l’équipe des opérations de la division des produits pharmaceutiques identifie un besoin métier – les doublons et autres erreurs et incohérences des données de

la chaîne logistique commencent à affecter ses calendriers de production. Bien entendu, la gestion des données de référence est la solution idéale au besoin. Malheureusement, la logique métier, l’interface graphique et le modèle de données utilisés par la première solution de MDM, apportée au besoin de conformité en matière de reporting, ne permet pas de résoudre ce nouveau problème. Étant donné que la première solution de MDM a été conçue spécifiquement pour traiter un aspect métier unique – les détails propres aux processus de conformité et de contact des médecins – selon l’approche de MDM par application, cette initiative de gestion des données de référence ne peut pas être adaptée afin de résoudre le nouveau besoin métier. Par conséquent, la division des produits pharmaceutiques se voit contrainte à la création d’une solution de MDM entièrement nouvelle et distincte pour résoudre le besoin relatif aux données de la chaîne logistique. En fin de compte, l’entreprise dispose de deux silos de MDM et se trouve confrontée au même problème qu’elle cherche à régler depuis le début. Voir Figure 3.

Exemple d’une entreprise multinationale du secteur pharmaceutique

Pour mieux illustrer la différence entre ces deux approches, penchons-nous sur un autre besoin métier auquel est confrontée une entreprise multinationale du secteur pharmaceutique, dont l’activité est organisée en plusieurs divisions : produits pharmaceutiques conventionnels, médicaments en vente libre, biotechnologies et appareils médicaux. La division des produits pharmaceutiques conventionnels, qui met au point des médicaments pour des maladies graves parmi les plus répandues, telles que le cancer, le Sida et les infections bactériennes, se trouve confrontée à de sérieux problèmes de conformité en matière de reporting. Ces problèmes découlent de la présence de nombreux doublons dans les systèmes archaïques utilisés par sa force de vente pour le suivi des actions commerciales, notamment auprès des médecins, des hôpitaux et des pharmaciens. La direction et les responsables informatiques de cette division décident donc de traiter ce problème par le biais d’une initiative de gestion des données de référence qui débouche sur la création d’une base de référence des médecins. Cette dernière doit nettoyer, normaliser et consolider les informations issues de plusieurs sources, puis les renvoyer aux systèmes de force de vente utilisés par la division. En disposant de données plus précises sur les médecins contactés, la division est mieux à même de générer des rapports de conformité précis en temps voulu.

Rubrique à brac


Implications liées à l’approche par plate-forme ou « fidèle au bon sens »

Imaginez à présent que la division des produits pharmaceutiques opte pour l’approche de MDM par plate-forme ou fidèle au bon sens. Dans ce cas, le modèle de données est le premier critère à prendre en compte – en établissant un guide détaillé concernant les sources des données structurées, l’organisation de ces données par les différents systèmes, les applications qui les exploitent, quand elles les exploitent, etc. Une fois cette étape primordiale accomplie, il est possible de configurer l’interface graphique de façon à gérer les données en fonction de la logique métier dictée par le problème. En optant pour cette approche de MDM par plate-forme, l’équipe informatique peut facilement étendre le système afin de traiter tout problème métier susceptible de survenir par la suite. Cette approche ne fonctionne pas seulement pour les besoins rencontrés au sein de la division, mais aussi pour les besoins métiers auxquels sont confrontés les autres divisions, services, régions, voire l’ensemble de l’entreprise.

Par exemple, l’entreprise peut optimiser la chaîne logistique pour son activité pharmaceutique principale, permettre à l’équipe achats d’améliorer la gestion des contrats passés par la division des appareils médicaux et permettre aux équipes marketing et commerciale d’améliorer les ventes croisées et incitatives au sein de l’entreprise. Grâce à sa flexibilité, l’approche de MDM par plate-forme permet de créer une solution de MDM multidomaine des plus polyvalentes, en offrant aux utilisateurs de partir de n’importe quel domaine, et non plus uniquement du client ou du produit. Ainsi, il est possible de tirer parti de ce même investissement technologique pour traiter tout autre type de besoin métier susceptible de survenir.

Les promesses de la plate-forme

L’un des avantages majeurs de la gestion des données de référence multidomaine est la suppression des erreurs et des conflits de données inhérents à tant d’entreprises et, à terme, l’élimination des systèmes et magasins de données redondants. Cependant, de tels avantages demeurent inaccessibles aux entreprises ayant recours à l’approche de MDM par application. Le fait est que cette approche incite souvent les entreprises à se doter de différentes applications de MDM pour résoudre différents besoins, ce qui entraîne la création des silos de données que la gestion des données de référence est justement censée supprimer. C’est pourquoi, partir de la logique métier pour progresser vers l’interface graphique, puis le modèle de données, va à l’encontre de la marche à suivre ou s’avère contraire au bon sens.

Approche de MDMpar application 1

1

2

3

1 2 1 2 3

Approche de MDMpar plate-forme

Figure 3

En adoptant une approche de MDM par applications, les équipes informatiques résolvent le problème métier immédiat, mais finissent par devoir mettre en place de nouvelles applications de MDM individuelles pour traiter séparément chaque besoin métier. Au contraire, opter pour une approche de MDM par plate-forme permet aux équipes informatiques de résoudre tout besoin métier immédiat, tout en les préparant à résoudre les besoins métiers à venir en exploitant au mieux le temps, les ressources et le budget investis.


L’adoption d’une approche MDM multidomaine basée sur une plate-forme unique procure les avantages suivants :• Progressionduchiffred’affairesetmeilleurstauxd’acquisition

et de rétention des clients grâce à l’alignement du niveau de service sur la mesure exacte de la valeur du client.

• Identificationdenouvellesopportunitéscommercialesgrâceà une vue étendue du client, prenant en compte les produits, les services et la qualité de la relation.

• Efficacitéopérationnellerenforcéeparl’identificationdesconflits existants entre les membres du réseau des partenaires commerciaux et les équipes de vente directe.

• Gouvernance,gestiondurisqueetconformitérenforcéesgrâce à l’amélioration du suivi, de la transparence et des possibilités d’audit des données financières.

• Accélérationduretoursurinvestissementdesfusions-acquisitions grâce à la consolidation rapide des données permettant d’avoir une vue et une compréhension globales de l’entreprise résultant de la fusion.

• Améliorationdesdécisionsàtouslesniveauxdel’entreprisegrâce à l’utilisation de données exactes, fiables et actualisées dans tous les processus.

• Productivitéaccruedesanalystesmétiersenleurdonnantles moyens d’analyser efficacement les performances via l’application de leur choix.

Le bon sens près de chez vous…

La gestion des données de référence multidomaine est par nature horizontale. Elle optimise les données qui sont nécessaires à la résolution de nombreux problèmes métiers et auxquelles de nombreuses applications métiers ont accès. Mener à bien une initiative de gestion des données de référence multidomaine implique un certain détachement par rapport à la méthode habituelle de résolution des besoins métiers des groupes informatiques – c’est-à-dire le recours à des applications de

planification des ressources d’entreprise (ERP), de gestion de la relation client (CRM) ou, encore, de gestion de la chaîne logistique (SCM) pour résoudre un seul besoin métier.

En adoptant l’approche MDM par plate-forme, celle qui est fidèle au bon sens, les départements informatiques sont en mesure de traiter rapidement un besoin métier tout en se réservant la possibilité de résoudre d’autres besoins métiers à l’aide d’une seule et même plate-forme. Ils peuvent ainsi réduire le coût total de possession et accélérer le processus de rentabilisation, et c’est bien là que résident tout l’intérêt et la valeur des solutions de MDM. n

Bruno Labidoire,Directeur technique

Informatica Corporation (NASDAQ : INFA) est le leader mondial des fournisseurs

indépendants de logiciels d’intégration de données. Partout dans le monde, des

entreprises acquièrent un avantage concurrentiel dans l’économie globale de

l’information d’aujourd’hui grâce à des données pertinentes, fiables et disponibles

en temps voulu pour faire face à leurs impératifs économiques. Plus de 4 100

entreprises dans le monde s’appuient sur les solutions Informatica pour accéder,

intégrer et fiabiliser leur capital d’information, que les données résident au sein

de l’entreprise, en dehors ou dans le Cloud.

Site web : www.informatica.com/fr

I LA RÉFÉRENCE TECHNIQUE ON-LINE DES PROFESSIONNELS DE … · développer des savoir-faire ou des...

Documents

Transcript of I LA RÉFÉRENCE TECHNIQUE ON-LINE DES PROFESSIONNELS DE … · développer des savoir-faire ou des...