Intégration d un ERP guidée par les modèles

Intégration d un ERP guidée par les modèles (Model Driven ERP Implementation) Projet ISNet 89 Octobre 2005 Contributeurs : Gil Gaillard & Philippe Dugerdil (HEG) o Partie théorique & implantation Adonix Yan Betriset (HEVs) o Etude d implantation SAP Rapport de fin de projet. Haute école de gestion Informatique de gestion 7, rte de Drize CH-1227 Genève Suisse +41 22 388 17 00 www.hesge.ch/heg

Résumé De nos jours, les progiciels de gestion intégré ou ERP 1 proposent une réponse efficace aux besoins standards de gestion informatisée des entreprises. Par rapport à un développement spécifique, un ERP propose l implantation de processus métiers standards qu il s agit de configurer pour les besoins propres de l entreprise. Il y a deux avantages principaux. Le premier est qu une solution ERP est souvent de meilleure qualité que les logiciels développés spécifiquement. En effet, l ERP ayant été installé chez de nombreux clients, les problèmes de jeunesse auront souvent disparu. Ensuite les processus métiers préconfigurés représentent un certain standard. Cependant, la configuration d un ERP est une tâche délicate. Il s agit en effet de savoir quels sont les processus préconfigurés proposés, comment ils sont organisés, avant de se lancer dans la configuration spécifique. Du point de vue technique, ces systèmes sont souvent très complexes et la maîtrise de leur architecture interne se révèle souvent difficile pour les informaticiens de l entreprise cliente La mise en place d une configuration d ERP passe par la description des processus métier désirés par l entreprise et l analyse d adéquation des processus standards de l ERP vis-à-vis de ces besoins. Les processus sont en général décrits de manière graphique dans un standard de représentation. Ensuite vient la paramétrisation de ces processus sur l ERP, tâche consistant à traduire une représentation de haut niveau en opérations techniques de bas niveau. Il s agit bien entendu de s assurer que le paramétrage suit fidèlement les processus métiers exprimés graphiquement. Aujourd hui cette opération est majoritairement faite à la main. Cependant, une nouvelle approche dans le développement de logiciels préconisée par l OMG 2, connue sous le nom de MDA 3, pourrait apporter une nouvelle dimension à l étape de paramétrage des progiciels. En effet, l approche MDA propose qu à partir de la modélisation de haut niveau d un système informatique, l environnement prenne en charge la génération de l implantation correspondante pour une plateforme spécifique. Le but de ce projet est d étudier la possibilité de mettre en œuvre cette approche dans le cadre de la paramétrisation d une ERP et de fournir un prototype en démontrant la faisabilité. Ce dernier a été développé dans l environnement IBM/Rational XDE qui met à disposition des outils spécifiques de mise en oeuvre de MDA. Notre prototype a été validé sur la base de l ERP Adonix X3 utilisé à la HEG pour l enseignement de l intégration de progiciels. Une tentative d utilisation de notre outil pour SAP R/3 a également été menée. De multiples difficultés se sont présentées, aussi bien du coté des éditeurs sous forme de rétention d information, que du coté techniques sous forme de bugs de l environnement. Le rapport en fait également état. 1 Enterprise Resource Planning: un système d information intégré qui supporte les processus standards d une enterprise. 2 Object Management Group : communauté permettant le développement des standards des concepts orientés objet. 3 Model Driven Architecture : l approche MDA permet, par le biais de modèles à différents niveaux d abstraction, de séparer la problématique des contraintes techniques 2

Table des matières 1 MODÈLE THÉORIQUE... 7 1.1 INTRODUCTION... 7 1.2 ETAT DE L ART... 8 1.3 MDA... 9 1.4 MDA ET LA CONFIGURATION DES ERP... 10 1.5 BUT DU PROJET... 11 1.6 PRINCIPE DE L APPROCHE... 11 1.7 LES ÉTAPES DE L APPROCHE... 12 1.7.1 Metamodèle des ressources... 12 1.7.2 Métamodèle du CIM... 12 1.7.3 Métamodèle du PIM... 13 1.7.4 Métamodèle du PSM... 13 1.7.5 Métamodèle des processus métier... 14 1.7.6 Métamodèle des activités... 14 1.7.7 Règles métier... 15 1.7.8 Profil UML... 15 1.7.8.1 Elements de modélisation... 15 1.7.8.2 Règles de transformation du CIM en PIM... 17 1.7.8.3 Règles de transformation du PIM en PSM... 18 1.8 IMPLÉMENTATION DU PROTOTYPE... 20 1.8.1 MDA Toolkit... 21 1.8.2 Profils UML... 22 1.8.2.1 Profil du CIM... 22 1.8.2.2 Profil du PIM... 24 1.8.2.3 Profil du PSM... 25 1.8.3 Transformations... 26 1.8.3.1 Remise à zéro... 26 1.8.3.2 CIM en PIM... 26 1.8.3.3 Validation... 26 1.8.3.4 Transformation... 26 1.8.3.5 La vérification... 27 1.8.3.5.1 PIM en PSM... 27 1.8.3.5.2 La validation... 27 1.8.3.5.3 La transformation... 27 1.8.3.5.4 La vérification... 28 2 ADONIX COMME PLATEFORME SPÉCIFIQUE... 29 2.1 INTRODUCTION... 29 2.2 SCÉNARIO... 29 2.3 PROCESSUS DE COMMANDE... 31 2.4 SCÉNARIO DE SAISIE DE COMMANDE SOUS ADONIX... 34 2.5 CONFIGURATION DES ÉCRANS... 37 2.6 RECHERCHE D INFORMATION... 38 2.7 FICHIER DE MAPPING... 39 2.8 VALIDATION DES ÉCRANS... 40 2.9 ETAPES DU PARAMÉTRAGE... 40 2.10 EXEMPLE... 40 3 SAP R/3 COMME PLATEFORME SPÉCIFIQUE... 47 3.1 INTRODUCTION... 47 3

3.2 SCÉNARIO... 48 3.3 PROCESSUS DE COMMANDE... 48 3.4 SCÉNARIO DE SAISIE DE COMMANDE SOUS SAP... 49 3.5 CONFIGURATION DES ÉCRANS... 51 3.6 RECHERCHE D INFORMATION... 52 3.6.1 Architecture du système... 52 3.6.2 Recherche des tables de paramétrage d écrans... 53 3.6.3 Alternatives... 54 3.7 REMARQUES FINALES SUR NOTRE EXPÉRIMENTATION SAP... 55 4 CONCLUSION... 56 5 ANNEXES... 58 5.1 MANIPULATIONS XDE... 58 5.1.1 Mise à jour des profils de notre projet dans XDE et plugin de transformation... 58 5.2 INSTALLATION ET GÉNÉRATION DE PLUGIN SOUS ECLIPSE... 59 6 RÉFÉRENCES... 60 4

Table des figures Figure 1 : Métamodèle des ressources... 12 Figure 2: Métamodèle des entités métier du CIM... 13 Figure 3 : Métamodèle du PSM... 14 Figure 4: Métamodèle des processus métier... 14 Figure 5: Métamodèle des activités... 15 Figure 6: Stéréotype des processus métier... 15 Figure 7: Processus génériques... 16 Figure 8: Stéréotypes des domaines et des processus génériques... 16 Figure 9: Stéréotypes de but, personne et information... 17 Figure 10: Processus métier et entités métier... 17 Figure 11: Stéréotypes des trois activités métier du prototype... 19 Figure 12: Diagramme des activités métier... 19 Figure 13: Approche MDA adaptée à la configuration d un ERP... 20 Figure 14: Prototype implémenté dans Rational XDE... 21 Figure 15: Stéréotypes des processus métier actif et inactif avec leurs définitions... 22 Figure 16: Sélection de l état actif/inactif du processus générique Commande... 22 Figure 17: Profil des éléments pour la transformation du CIM en PIM... 23 Figure 18 : Profil des entités du CIM... 24 Figure 19: Propriétés de l activité Saisie client... 24 Figure 20 : Profil des éléments pour la transformation du PIM en PSM... 25 Figure 21 : Profil du PSM... 25 Figure 22: Modèle de données des ventes d Adonix... 29 Figure 23 : Modules proposés par Adonix X3... 30 Figure 24 : Modules proposés par SAP R/3 v.4.7 et MS Navision 4.0... 30 Figure 25 : La page d accueil d Adonix X3... 31 Figure 26 : Les domaines du prototype... 31 Figure 27 : Le menu des ventes... 32 Figure 28 : Processus génériques inclus dans le domaine ventes... 32 Figure 29 : Le menu Commandes... 33 Figure 30 : Modèles des processus métier... 33 Figure 31 : Sélection du type de commande... 34 Figure 32: Ecran d une saisie de commande normale... 34 Figure 33: Onglet «Gestion» de la fenêtre «Saisie de commande»... 35 Figure 34: Onglet «Livraison» de la fenêtre «Saisie de commande»... 35 Figure 35: Onglet «Facturation» de la fenêtre «Saisie de commande»... 36 Figure 36: Onglet «Lignes» de la fenêtre «Saisie de commande»... 36 Figure 37: Modèle des activités de la saisie d une commande sur Adonix X3... 37 Figure 38 : Données du champ client commande... 38 Figure 39: Paramétrage du champ client commande... 38 Figure 40: La table AMSKZON contenant les propriétés du champ client commande... 39 Figure 41 : Etapes du paramétrage... 40 Figure 42: CIM dans son état initial... 41 Figure 43: La propriété du processus Etablir un devis est mise à false... 41 Figure 44: Plugin CIMtoPIM dans la barre de menu... 42 Figure 45: Sélection des modèles impliqués dans la transformation CIM to PIM... 42 Figure 46: PIM actualisé après la transformation avec le devis désactivé... 42 Figure 47: Modèle des processus actualisé après la transformation... 43 Figure 48: Sélection des propriétés de l activité «saisie de la livraison»... 43 Figure 49: Fenêtre des propriétés dans Rational XDE... 44 Figure 50: le plugin PIMtoPSM dans la barre de menu... 44 Figure 51: sélection des modèles impliqués dans la transformation PIM to PSM... 44 5

Figure 52: modèle des activités actualisé après la transformation... 45 Figure 53: une partie de l entité «Livraison» dans le PSM actuel... 45 Figure 54: Onglet des livraisons avec suppression du champ Transporteur... 46 Figure 55: Revenus total par régions au second trimestre 2005 (Mios EUR)... 47 Figure 56: Revenus total par type de solution au second trimestre 2005 (Mios EUR)... 48 Figure 57 : Arborescence des opérations et écrans... 49 Figure 58 : Ecran initial des commandes client... 49 Figure 59 : Saisie des informations de la commande... 50 Figure 60 : Calcul de la date de mise a disposition... 50 Figure 61 : Flux de documents... 51 Figure 62 : Ecran de configuration de workflow... 52 Figure 63 : Accès aux informations techniques d un champ... 53 Figure 64 : Outil de développement ABAP... 53 Figure 65 : Outil de configuration GuiXT... 55 Figure 66 : Propriétés du profil... 58 Figure 67 : Exportation d un ficher JAR... 59 6

1 Modèle théorique Gil Gaillard & Philippe Dugerdil 1.1 Introduction En raison de la pression croissante sur les coûts et la standardisation du domaine IT des entreprises, un nombre de plus en plus important de compagnies choissent un système ERP comme colonne vertébrale de leur système informatique. Autrefois l apanage des multinationales, le phénomène atteint également les PME [Van00]. La preuve n est plus à faire que les ERPs sont une alternative viable au développement d applications spécifiques pour des besoins informatiques standards et que la qualité est souvent supérieure en termes d implémentation de processus métiers [Har02]. Si l ERP est devenu une véritable alternative aux développements spécifiques, il s accompagne souvent d une forte dépendance de l entreprise par rapport l éditeur du progiciel. L intégration d un ERP est une tâche complexe et il est rare que le département informatique d une société cliente en maîtrise tous les détails. En réalité, lorsque d importantes modifications doivent être effectuées au sein d un tel système, une aide de la part des consultants mandatés par l éditeur est fréquemment requise. Cette situation peut provoquer chez le chef d entreprise un sentiment de perte de contrôle de son système informatique. Une possibilité pour atténuer ce problème est de fournir aux décideurs un modèle du système en adéquation avec leur niveau de compréhension et d expertise : une représentation graphique des processus métier implantés. La difficulté de cette approche est d assurer que ce modèle reflète fidèlement l implantation. Dans le cadre de ce projet, nous proposons d exploiter l approche MDA afin de permettre la configuration d un progiciel au travers de modèles des processus métier à implanter. Cependant, l outil de modélisation ainsi que le langage graphique utilisé ne doivent pas devenir eux-mêmes une source de dépendance pour l entreprise. Par conséquent, nous avons choisi le standard UML comme langage de modélisation accompagné de ses mécanismes d extensions (profils) permettant de définir les éléments de représentation des processus métier. Ainsi, nous avons adopté l extension d UML pour la modélisation métier proposée par Eriksson et Penker [Erik00]. Cette dernière est très proche du standard BPMN largement utilisé pour la modélisation métier [BPM03]. Elle apporte un complément nécessaire au profil de modélisation métier publié par IBM [Jon04]. Nous avons exploité ce profil au moyen d un outil de modélisation extensible : XDE de IBM/Rational. Mais encore une fois, pour que cette approche soit pertinente, il faut s assurer que la modélisation corresponde à l implémentation. C est là qu intervient l approche MDA de l OMG [MDA03, Fra03]: l idée est de générer la configuration à partir des modèles. Nous avons donc étudié la possibilité d utiliser l approche MDA pour établir un outil de configuration semi-automatique d ERP. A partir d un modèle des processus métier, l outil va modifier ce modèle pour graduellement l amener à un niveau de détail permettant la mise à jour des bases de données contenant les paramètres de l ERP. NB : ce document ne contient pas d information sur la définition d un processus métier ni sur leur structure et conventions de représentation graphique. Le lecteur intéressé est invité à consulter [Erik00, Sha01, BPM03]. De même, l approche MDA n est pas décrite en détail. Une bonne introduction peut être trouvée dans [FRA03] et une information complète sur le site de l OMG (www.omg.org). 7

1.2 Etat de l art Partant du fait que le non alignement entre les besoins des entreprises et la configuration des systèmes est l un des principaux facteurs d échec de la mise en place des ERP [Vog02] et que les langages de paramétrage propriétaires sont souvent compliqués à maîtriser, quelques tentatives ont été faites pour remplacer ces derniers par des langages graphiques standards. Depuis quelques temps, le besoin de développer les modèles des processus métier pour la configuration des ERP est reconnue [Gul00]. Depuis le milieu des années 80, Jacobson [Jac85] a proposé d appliquer la modélisation objet et les cas d utilisation à la modélisation métier. Il a alors décrit les principaux stéréotypes d objets métier, qui sont encore en usage aujourd hui. Plus tard, l utilisation d UML en tant que langage de modélisation a été largement documentée par les consultants de Rational [Ng02, Bak01, Heu01]. L application des concepts orientés objet n a en revanche été appliqué pour l intégrations de système ERP que récemment. Par exemple Arinze et Anandarajan [Ari03] proposent un framework orienté objet afin de faciliter la définition des paramètres d un ERP. Cependant, leur approche n a pas réellement augmenté le niveau conceptuel de la modélisation. Elle a tout au plus remplacé les paramètres de langage propriétaire par des représentations orientées objet. Il faut toutefois relever que la modélisation métier n était pas leur motivation première. La modélisation des processus métier pour les ERP dans un format indépendant a été proposée par Sheer [Sch00] qui a développé un produit commercial ARIS [IDS03]. Cependant, cette approche introduit à son tour une dépendance, pas celle liée à l éditeur de l ERP mais à l outil de modélisation. L application de l approche MDA de l OMG pour modéliser l entreprise et ses processus a été largement étudiée par Wegman [Weg03]. Ce modèle n a, en revanche, pas été appliqué au développement de systèmes informatiques et encore moins à la configuration des ERP. Linvald et Østerbye ont récemment proposé d utiliser l UML pour configurer les ERP [Lin02]. Toutefois, leur démarche se concentre sur l aspect visuel d UML et ne propose pas de méthodologie ni d application de l approche MDA. D un autre côté Rolland et Prakash ont proposé d utiliser UML afin de modéliser les besoins fonctionnels d un système informatique d une entreprise et de comparer ce système à un ERP [Rol01]. Ce travail est resté au stade des spécifications et ne traite pas la problématique du paramétrage d un ERP. Finalement, il est à noter que l avantage d employer un langage de modélisation unique, à savoir UML, pour modéliser aussi bien les éléments métier que système a été soulevé par Heberling et al. [Heb02]. Leur travail ne mentionne cependant pas l application d UML pour la configuration des ERP. 8

1.3 MDA L idée centrale, lors de la création de l approche MDA, était de fournir un cadre méthodologique et architectural de développement et d intégration de systèmes qui assure la pérennisation des architectures métiers de l entreprise en les découplant des préoccupations technologiques. Elle définit une approche orientée modèle, dans laquelle les représentations métier indépendantes de toute plateforme technologique sont graduellement enrichies pour permettre, en fin de processus, une génération de code pour une plateforme cible spécifique. Basée sur trois modèles, l approche MDA insiste sur les mécanismes de transformation entre ces modèles. Le premier modèle, le CIM (Computational Independent Model) ou modèle du domaine, décrit les exigences du système et la situation dans laquelle le système sera utilisé. Il correspond à la modélisation du système d information de l entreprise sans parler encore de système informatique. Le CIM place le système dans son contexte opérationnel et permet de représenter ce que le système devrait réellement assurer comme services. Les exigences décrites dans les modèles CIM doivent pourvoir à la construction d autres modèles qui les implémentent et inversement. Le deuxième modèle, le PIM (Platform Independent Model) est un modèle de haut niveau d abstraction qui reste indépendant de la plateforme. Il représente les différentes entités fonctionnelles d un système d information informatisé avec leurs interactions, exprimées uniquement en termes de logique d entreprise. Ainsi, il décrit le système en masquant les détails de son utilisation sur une plateforme technique particulière. Le dernier modèle, le PSM (Platform Specific Model) est, quant à lui, dépendant de la plateforme. Il sert essentiellement de base à la génération de code pour un environnement d exécution donné. Le PSM est une représentation de l implémentation dans une technologie particulière. Un PSM doit donc être généré pour chaque plateforme technologique spécifique. Dans la littérature, les premières applications de l approche MDA s adressaient aux middleware et à leurs services. Nombre d ouvrages dans la littérature fournissent des exemples concernant CORBA et autres EJB [Hub02]. Le MOF (Meta-Object Facility) [MOF02], les profils [Rum04] et l OCL (Object Constraint Language) [OCL03] sont souvent utilisés pour mettre en œuvre l approche MDA. Concernant le premier, il est extrêmement puissant pour exprimer des métamodèles. Sa mise en œuvre est toutefois délicate pour le non spécialiste. Les profils représentent une extension de la symbolique UML pour une utilisation ou un domaine particuliers. Un profil contient un ensemble de symboles et contraintes supplémentaires ainsi que leur sémantique. La mise en oeuvre d un profil est plus facilement maîtrisable par un non spécialiste. L OCL, quand a lui, est largement utilisé pour exprimer les contraintes au niveau des modèles UML ainsi que les transformations MDA. Ce dernier aspect permet de donner à l approche MDA une indépendance par rapport à l environnement de développement. Il faut finalement relever que la volonté de maîtriser la complexité et de pérenniser les analyses de haut niveau via MDA a, dans la littérature, été trop souvent reléguée au second plan, derrière la problématique de la transformation de modèles. Conscients que cette dernière représente le plus gros du travail, certains auteurs se sont focalisés sur ces mécanismes sans les situer dans une démarche globale. Il est à ce propos symptomatique que nombres de références ne citent même plus le CIM comme modèle intégrant du MDA. Il est considéré comme une première documentation, la transformation du PIM au PSM retenant toutes les attentions. 9

1.4 MDA et la configuration des ERP Une des motivations de l approche MDA de l OMG est de promouvoir l indépendance par rapport à une plateforme donnée pendant la conception des systèmes informatiques. En effet, l architecte ou le développeur vont concentrer leurs efforts sur la problématique et les besoins de leur application indépendamment de la plateforme cible et laisseront à l environnement de développement le soin de s adapter aux contraintes inhérentes à la plateforme choisie. Le modèle le plus haut dans la hiérarchie de conception, le CIM (Computational Independant Model) s adresse au domaine métier [MDA03]. Il est parfois appelé modèle du domaine et en inclut les entités et les concepts principaux. Ensuite, en ajoutant la connaissance des processus métiers communs aux ERP, le PIM (Platform Independant Model) peut être à son tour établi. Bien que la technologie propre à un ERP ne doive pas être prise en compte à ce stade de l approche, il est important de garder à l esprit que la finalité est la configuration d un ERP et non le développement d une application dans son intégralité. Ceci est en concordance avec les observations d Almeida et al. [Alm04] qui stipule que le PIM doit refléter les capacités et le potentiel de la plateforme cible. Finalement, le PSM (Platform Spécific Model) est un modèle obtenu en ajoutant au PIM la connaissance des activités qui implantent chaque processus métier de l ERP cible. Comme ces modèles ainsi que les transformations sont décrits en UML, standard de facto pour les ingénieurs informaticiens, cette approche a l avantage de ne nécessiter pour eux aucune formation sur un nouveau langage de développement. D ailleurs, notre outil peut être implémenté sur toute plateforme supportant le framework MDA. Pour notre part, nous avons choisi XDE de IBM/Rational. L approche MDA a été initialement pensée pour définir et concevoir des développements spécifiques d applications. Dans le cas traditionnel d utilisation de l approche MDA, la dernière étape est la génération du code pour la plateforme spécifique. Cependant, dans un ERP, le système est déjà conçu. En quelque sorte, il s agit d une boîte à outil contenant des composants (visuels et non visuels) à activer, désactiver ou étendre selon la configuration des processus métiers désirés. C est pourquoi l intégration d un ERP diffère d un développement d application dans l approche MDA : la dernière phase d une application de MDA pour ERP représente la génération de paramètres. Il n y a donc pas de génération de composants, mais seulement une activation ou désactivation d éléments préexistant. Ainsi, la notion de transformation de modèle de MDA est remplacée dans notre cas par la notion de sélection ou de suppression d éléments de modèles prédéfinis. Bien entendu, les éléments supprimés ne le sont pas physiquement dans l ERP car ils sont nécessaires à son intégrité. Ils sont simplement rendus inactifs. Finalement, il est clair que certaines situation de paramétrage d ERP exigent de créer du code afin, par exemple, d étendre certaines fonctionnalités. Cette problématique n est pas couverte dans le cadre du présent travail. Cependant, il est envisageable de la traiter par le biais du langage OCL qui permet d exprimer des contraintes sur les modèles. Cette démarche constituerait le prolongement naturel de la présente recherche. 10

1.5 But du projet Étudier la faisabilité d une méthode légère (selon [Koe03]) de configuration d ERP. Afin d y parvenir, un premier prototype contenant les modèles théoriques et les mécanismes de transformation sera développé. Après une première série de tests, les interactions avec deux éditeurs de progiciels recentreront notre travail sur les problèmes pratiques et permettront d affiner notre approche. 1.6 Principe de l approche Le projet se base sur la transformation de modèles d entités métier qui correspondent à celles supportées par tout ERP. Ainsi, le concept de transformation MDA que nous mettons en œuvre se traduit par une évolution et un enrichissement de l information liée aux entités métiers. Dans l étape finale, lors de la génération des paramètres de la configuration, un mapping est effectué entre les noms des entités et attributs compréhensibles par l utilisateur vers les termes techniques propres à chaque ERP. Dans le cadre de ce projet, les trois modèles CIM, PIM et PSM représentent des entités métier. L originalité de notre démarche est que les transformations entre modèles s expriment elle-mêmes par des modèles. Notre approche considère que l ERP possède initialement la potentialité de couvrir un large éventail de processus. Ainsi, l utilisateur va configurer son processus métier en supprimant les activités et informations qui lui sont inutiles. Il s agit donc en quelque sorte d un paramétrage par suppression plutôt que par ajout. Au départ, l utilisateur dispose d un modèle générique des entités métier dans lequel il peut sélectionner les entités à désactiver en fonction de ses besoins. Par défaut, les entités sont toutes «actives» c est à dire participent potentiellement à l implantation finale. Par exemple s il ne veut pas saisir d information sur le fournisseur pour une commande, il va désactiver l entité fournisseur. Dans ce cas tous les champs associés aux attributs du fournisseur seront supprimés des écrans de l ERP. Le modèle initial des entités métier dans lequel l utilisateur a sélectionné les entités à désactiver représente le CIM. Pour transformer le modèle des entités métier du CIM en modèle PIM, l utilisateur lance une propagation de propriétés 4 par l intermédiaire d un processus métier qu il aura choisi parmi un ensemble prédéfini. A ce niveau les processus métiers sont définis de manière suffisamment générale pour être semblables quelque soit l ERP considéré. Un processus métier «consomme» des entités métier et en génère au travers de ses différentes tâches. Si une entité métier consommée par une tâche est désactivée, la tâche elle-même est alors désactivée ainsi que toutes les entités produites par la tâche. De plus, l utilisateur a la possibilité d agir sur la transformation elle-même en désactivant une tâche du processus choisi. Il s agit, dans ce cas, d une tâche qu il ne souhaite pas voir exécutée dans le cadre de son processus au niveau de l ERP. Cette opération a pour conséquence que les entités produites par la tâche seront désactivées également. Ces opérations de propagation de propriétés d entités sont menées de proche en proche sur l ensemble du modèle des entités. A cette étape de la transformation, les règles métier et les diverses contraintes, écrites en OCL, peuvent être ajoutées sur le modèles des entités (PIM) et des processus (transformation) 5. Le modèle des processus contient aussi la représentation des responsables et intervenants au niveau des tâches qui peut être exploitée pour définir des profils utilisateurs. 4 Il s agit de propager la désactivation de composants, via leur propriété status, comme nous le verrons plus loin. 5 Cette étape ne fait pas partie du présent travail mais en constituerait une extension naturelle. 11

Pour transformer le modèle des entités métier de PIM en PSM l utilisateur va appliquer au PIM un modèle d activités représentant la réalisation de chaque tâche dans le cadre d un ERP particulier. Cette application a deux conséquences : 1. Premièrement, en désactivant sélectivement certaines activités d une tâche, la désactivation va se propager aux entités générées par l activité et ensuite aux activités qui consomment cette ressource. 2. Deuxièmement, chaque activité étant propre à un ERP particulier, nous avons la possibilité d enrichir l information sur chaque attribut d entité au travers de la sélection d une propriété de l activité. Par exemple, si la propriété d une activité «saisir adresse client» possède la valeur «obligatoire» ou «optionnelle», cette information va être propagée à l entité manipulée et ses attributs. Une fois le modèle d entités PSM créé, il s agit d effectuer le mapping avec les entités réelles de l ERP cible et de mettre à jour les tables de la base de données. Pour cela un fichier de mapping fournit une correspondance entre chaque attribut d entité et ses propriétés et leurs localisations dans la base de données de l ERP. Il est alors possible de générer des requêtes de mise à jour de cette base de données. 1.7 Les étapes de l approche Premièrement, les trois modèles (CIM, PIM et PSM) sont décrits théoriquement par leurs métamodèles. Dans une deuxième partie, les deux modèles (processus métier et activités) utilisés pour les transformations sont expliqués. 1.7.1 Metamodèle des ressources De manière générale les processus utilisent, consomment, manipulent et produisent des ressources. Leur métamodèle peut s exprimer de la manière suivante [Erik00] : 1.7.2 Métamodèle du CIM Figure 1 : Métamodèle des ressources Le CIM est constitué d entités métier qui peuvent être actives ou inactives selon la sélection de l utilisateur. Cette sélection s exprime directement sur l entité au travers d une propriété ( status ). En suivant [Erik00] nous considérons les entités consommées et produites par les processus comme des ressources physiques (une ressource de type «information» représente une source de connaissances nécessaire à la réalisation d une tâche. Elle n est pas à proprement parler «consommée» par le processus). 12

Resource Thing Property 1 enables/disables 1 Physical Figure 2: Métamodèle des entités métier du CIM 1.7.3 Métamodèle du PIM Le métamodèle du PIM est identique à celui du CIM (fig. 2). 1.7.4 Métamodèle du PSM Le métamodèle du PSM diffère de celui du PIM par la suppression de la propriété au niveau de l entité et par l ajout d une propriété à chaque attribut des entités métier. Dans le PSM, l information d activation est donc représentée au niveau des attributs. Toutefois, il n est pas question de permettre à l utilisateur de modifier le status individuel d une propriété 6. Les manipulations d activation restent globalement au niveau de l entité, mais les valeurs sont physiquement enregistrées au niveau des attributs. De plus le type de la propriété des attributs n est plus booléen comme pour l entité mais le type «String» permettant un plus large éventail de valeurs. Ces dernières dépendront des activités qui manipulent les entités. Finalement, chaque entité et chaque attribut est accompagné d un mapping vers la base de données du système final. A partir de ces informations (localisation des données dans la base de l ERP et valeur de ces données) il sera possible de générer des scripts SQL de mise à jour de la base de données de l ERP. 6 Notre approche perdrait alors un peu de son intérêt car cela reviendrait au même que de paramétrer le système de manière traditionnelle, champ par champ. 13

Resource Thing Property Physical maps to 1 1 qualifies 1 * Attribute LocationIdentification 1 maps to {inv:self.locationidentification <> self.physical.locationidentification} Figure 3 : Métamodèle du PSM 1.7.5 Métamodèle des processus métier La figure 3 exprime le métamodèle des processus métiers, ce dernier est partiellement repris de [Erik00]. La différence est la présence de la propriété qui permet de représenter l activation ou la désactivation du processus métier lui-même. Il est ainsi possible de désactiver globalement tout un processus (ou une tâche, considérée comme un sousprocessus). Figure 4: Métamodèle des processus métier 1.7.6 Métamodèle des activités Le modèle des activités est spécifique à l ERP cible. Il intervient dans la seconde transformation, celle du PIM au PSM avec un rôle similaire à celui du modèle des processus métier dans la transformation CIM vers PIM. Le métamodèle de la figure 5 en définit la 14

structure. Les activités possèdent une propriété permettant de les désactiver sélectivement, selon les désirs des utilisateurs. Figure 5: Métamodèle des activités Un modèle d activité représente les étapes de la réalisation d un processus métier donné sur un ERP particulier. Il y a donc autant de modèles d activités, pour un processus donné, qu il y a d ERP cibles différents. 1.7.7 Règles métier Sans les règles métier, les processus de transformations de modèles MDA se limitent à des activations ou désactivations d éléments. Cependant, dans le cadre limité de notre démonstration de faisabilité de l implémentation d un ERP au travers de modèles, les règles métier ne sont pas incluses 7. 1.7.8 Profil UML Pour étendre le langage UML afin d inclure les différents définitions utiles au projet, nous avons définit un profil UML basé sur la version 1.5 du langage. Notre profil inclut de nouveau stéréotypes et propriétés (tagged values) [UML03]. Les propriétés servent à contenir et propager l information nécessaire aux transformations du MDA. En particulier cela permet d indiquer si un élément d un modèles est actif ou non. 1.7.8.1 Elements de modélisation Processus métier (stéréotype): représente un ensemble d activités effectué par une ou plusieurs personnes. Il peut être constitué de sous processus, ou tâches, selon une décomposition hiérarchique. L élément de décomposition du plus bas niveau est donc l activité. Du point de vue profil UML, le processus métier est conçu comme une extension de la métaclasse Activité (fig. 6). Les entités métier vont être associées aux processus et activités qui les manipulent. «MetaClass» Activity Business Process + «TagDefinition» status : Boolean Figure 6: Stéréotype des processus métier 7 Comme nous l avons déjà soulevé, une extension de ce travail incluant les règles métier via une spécification OCL semble parfaitement envisageable. En particulier, plusieurs compilateurs OCL vers un langage cible de haut niveau sont disponibles (par exemple vers Java [Loe03]). A l aide de cette technologie, il serait possible de générer le langage de paramétrage propriétaire a chaque ERP cible. Le problème principal étant, comme nous aurons amplement l occasion de le voir, la localisation de ces règles et contraintes au niveau de la base de données de l ERP cible. 15

Domaine (stéréotype): représente un segment ou une catégorie de métiers tels que la comptabilité, la production, les ressources humaines, les ventes et les fournisseurs. Le rôle du stéréotype «domaine» est de regrouper les éléments des modèles, essentiellement des processus et des entités métier. C est pourquoi le domaine est une extension de la métaclasse Package (fig. 7). Sa propriété est une valeur booléenne agissant comme un indicateur de l état de l élément. Lorsque l utilisateur désactive un domaine au moyen de cette propriété, tous les éléments contenus dans ce domaine sont désactivés au moyen de leurs propriétés respectives. Processus générique (stéréotype): représente un regroupement de processus semblables, présents dans plusieurs domaines. Par exemple, le processus livraison peut être inclus dans les domaines : production, achats et ventes (Fig. 7). Processus générique Production : livraison Vente : livraison Figure 7: Processus génériques En conséquence, la livraison contient des activités dans plusieurs domaines. Le processus générique est une extension de la métaclasse Package (fig. 8). De manière identique à celle du domaine, une propriété booléenne indique si le processus générique est actif. Cet état s applique aussi à tous les éléments contenus dans ce processus générique, c est à dire à l ensemble des domaines concernés. Domain «MetaClass» Package + «TagDefinition» status : Boolean Generic Process + «TagDefinition» status : Boolean Figure 8: Stéréotypes des domaines et des processus génériques Contrainte métier : représente une limitation spécifique, une valeur initiale, un message ou une contrainte temporelle pour un processus métier. Elle est exprimée en OCL. Personne (stéréotype): représente une ressource humaine associée à un processus métier. C est une extension de la métaclasse Classe (fig. 8). Cet élément de modélisation peut être exploité pour définir des profils utilisateurs pour les ERP. 16

But et information (stéréotypes): représentent le but d un processus métier [Erik00, Sha01] et l information (connaissances requises) qui peuvent être liés à ce processus. A ce stade du projet, ces éléments sont utilisés à des fins de documentation uniquement. Ce sont des extensions de la métaclasse Classe (fig. 9). Ces éléments sont associés au processus métier correspondant (le symbole en forme de losange représente la ressource «information») (fig. 10). Goal + «TagDefinition» status : Boolean «MetaClass» Class People + «TagDefinition» status : Boolean Information + «TagDefinition» status : Boolean Figure 9: Stéréotypes de but, personne et information Figure 10: Processus métier et entités métier 1.7.8.2 Règles de transformation du CIM en PIM Une transformation de modèle représente essentiellement une propagation de valeur d activation d entité métier. Ainsi pour transformer le modèle des entités métier de leur état 17

«CIM» à leur état «PIM» l utilisateur va lancer une propagation de la valeur de la propriété d activation de chaque entité, par l intermédiaire d un processus métier dans lequel ces entités sont impliquées. Les règles de propagation de l activation sont: 1. Intégrité d association : si une entité métier du CIM est inactive et qu une autre entité y est associée via une association de cardinalité 1 avec elle (c'est-à-dire que la seconde entité est toujours associée à l entité désactivée), la seconde entité doit être inactivée à son tour 2. Intégrité d héritage : si une entité générique (classe) est inactive, ses spécialisations (sous-classes) le sont également 3. Si un processus métier (ou une tâche à l intérieur du processus) «consomme» une entité métier désactivée alors, le processus (ou la tâche) est désactivée à son tour 8. 4. Si un processus métier (ou une tâche à l intérieur du processus) est désactivée alors toutes les entités produites par le processus (ou de la tâche) sont désactivées 9. 5. Si un domaine ou un processus générique est désactivé, tous les éléments inclus sont à leur tour désactivés. La désactivation d un processus ou d une tâche peut être la conséquence de la règle (1) cidessus ou d une désactivation directe par l utilisateur. Dans ce dernier cas, l utilisateur n agit donc plus sur le modèle mais en quelque sorte sur la transformation. 1.7.8.3 Règles de transformation du PIM en PSM Pour transformer le modèle des entités métier de leur état «PIM» à leur état «PSM» l utilisateur va lancer une propagation de la valeur de la propriété d activation de chaque entité par l intermédiaire des activités métier dans lesquelles l entité est impliquée. Ces activités métiers, qui sont des extensions de la métaclasse activité (fig. 11 et 12), représentent la réalisation des processus métier (ou des tâches) dans le cadre de l ERP cible. Dans notre prototype, une activité métier peut être de type «saisie», «validation» ou «sélection». Chacune d entre elles peut contenir des informations spécifiques exprimées au moyen de propriétés. Par exemple, la propriété «status» de l activité métier de type «saisie» peut prendre les valeurs suivantes : «optionnel», «obligatoire», «affiché» ou «inutilisé». Durant la transformation PIM vers PSM, la propriété d état (status) des entités est supprimée au profit de l ajout d une propriété de type String à chacun de leurs attributs. En effet, le PSM est un modèle qui doit nous permettre de générer le code SQL nécessaire à la mise à jour de l ERP. Cette mise à jour se base principalement sur l état des attributs d une entité plutôt que sur l entité elle-même. Par exemple, dans le cas du paramétrage d un écran, il s agit de présenter ou non certains champs qui sont des attributs d entités. En conséquence, la propagation de valeur de propriétés ne se fait plus au niveau des entités mais de chacun de leurs attributs. Les règles de propagation de valeur de propriétés sont: 1. La valeur de la propriété d état d une entité du PIM est copiée dans la propriété de chaque attribut de l entité PSM correspondante. 2. Si une activité «consomme» une entité désactivée (ou dont l ensemble des attributs est désactivé), alors cette activité est désactivée à son tour. Dans ce cas, la propriété de l activité ne peut pas recevoir d autre valeur. 3. Si une activité est désactivée, alors la désactivation est propagée aux attributs des entités produites par l activité 10. 8 En effet, partant du principe que l entité est nécessaire au déroulement du processus, si elle est absente alors le processus ne peut pas fonctionner. 9 Si la fabrication d une entité est arrêtée elle ne peut évidemment pas être utilisée. 18

4. Si l utilisateur sélectionne une valeur particulière pour la propriété d une activité, cette valeur est propagée aux attributs des entités produites par l activité. Par exemple, si la valeur de la propriété d une activité «saisir adresse client» est «obligatoire», cette information est propagée aux attributs de l entité manipulée (l entité «client»). Cette valeur, à la différence de la désactivation, n est pas propagée au delà de l entité concernée. Une fois le modèle d entités PSM mis à jour, le système peut exploiter l information de mapping des attributs et leurs propriétés ainsi que la valeur de ces attributs et propriétés pour générer des requêtes de mise à jour de la base de données. Cette dernière étape n est pas à proprement parler une transformation. C est plutôt l équivalent de la génération de code dans le cadre d un développement traditionnel. Bien que cette étape soit conceptuellement simple, le problème essentiel est de construire le mapping en localisant les éléments dans la base de données de l ERP. Pour cela, le recours à l éditeur de l ERP ou à des consultants est indispensable. Ce travail nous a créé de grandes difficultés comme nous le verrons par la suite. Finalement, les contraintes supplémentaires exprimées en OCL peuvent être traduits en enregistrement dans la base de données cible au moyen de scripts SQL. Ce travail n a toutefois pas été réalisée dans le cadre du présent projet. Entering + «TagDefinition» status : Boolean «MetaClass» Activity Validating + «TagDefinition» status : Boolean Selection + «TagDefinition» status : Boolean Figure 11: Stéréotypes des trois activités métier du prototype Figure 12: Diagramme des activités métier La figure 13 représente l architecture complète de notre système de transformation. On voit que les modèles transformés sont constitués exclusivement d entités et que les transformations s expriment également sous forme de modèles. 10 Dans ce cas, la désactivation n est plus représentée par la valeur booléenne false, mais par l une des chaînes de caractères prédéfinies représentant la désactivation. Notre prototype fait ainsi usage de la valeur unused. 19

Figure 13: Approche MDA adaptée à la configuration d un ERP 1.8 Implémentation du prototype Le prototype de notre système a été réalisé dans l environnement de développement IBM/Rational XDE à l aide du MDA toolkit (fig. 14). Notre extension est implémentée sous la forme d un plugin Eclipse écrit en Java. La plateforme spécifique choisie pour le développement du prototype est Adonix X3. Une tentative a également été menée pour appliquer notre démarche à SAP, comme nous le verrons dans le chapitre correspondant. 20