Evolution du système d information par l implantation d un Progiciel de Gestion Intégrée

Evolution du système d information par l implantation d un Progiciel de Gestion Intégrée Systématiser la mise en correspondance entre le système et l organisation Iyad Zoukar, Camille Salinesi, Colette Rolland Centre de Recherche en Informatique - Université Paris 1 Panthéon Sorbonne 90 rue de Tolbiac 75013 Paris France iyad.zoukar@malix.univ-paris1.fr, {camille,rolland}@univ-paris1.fr RESUME : Assurer l'adéquation entre les besoins de l organisation et les fonctionnalités du Système d Information (SI) est une question fondamentale qui se pose principalement dans le cadre d évolution du SI. C est en particulier le cas quand une organisation fait évoluer son SI par l installation d un Progiciel de Gestion Intégrée (PGI). L une des causes importantes de l'inadéquation résulte de la disparité des langages utilisés par les divers intervenants d intégration de PGI. Notre approche pour résoudre ce problème est de matérialiser la relation de correspondance entre les fonctionnalités du nouveau système incluant le PGI et les processus métier de l organisation. En posant l'hypothèse qu un formalisme abstrait à base de buts peut être employé pour trouver cette correspondance, nous avons développé à la SNCF une méthode qui aide à analyser les exigences du métier relatives à l installation d un PGI. Cet article présente des éléments de cette méthode et les questions qui ont été soulevées lors de son application dans un projet d installation d un PGI pour supporter les processus logistiques à la SNCF. ABSTRACT: Ensuring the adequacy between Information System (IS) functionalities and business requirements is still an issue that needs to be addressed in the domain of IS evolution. It s specially the case when an organization evolves its IS by adapting an Enterprise Resource Planning (ERP). One important cause of inadequacy results from the gap between the languages used by ERP implementers and the other stakeholders. Our approach to this issue is to materialize the relationship between the functionalities of the new system including the ERP and the business processes that it supports. Based on the assumption that an abstract goal-based formalism can be used to achieve this, we have developed at SNCF a method that helps eliciting ERP implementation requirements together with business adaptation requirements. This paper outlines this method and the issues that were met while using it in an SNCF project in which an ERP is being implemented to support the Supply Chain processes. Mots-clés : Evolution du SI, Ingénierie des besoins, PGI, Processus métier, Carte. Keywords: IS Evolution, Requirement Engineering, ERP, Business Processes, Map. 1

1. Introduction Assurer l adéquation entre un système d information de type PGI et les besoins et exigences d une organisation demeure un problème de fond qui doit être résolu si l on veut que les PGI fournissent les avantages attendus. Une des raisons majeures de l inadéquation résulte de la différence de langages utilisés par les différentes parties impliquées dans un projet d intégration des PGI (l éditeur de progiciel, les intégrateurs, les experts métier et les utilisateurs, etc.). Notre travail à la SNCF consiste à développer une méthode qui aide à assurer la mise en adéquation de PeopleSoft, que l entreprise est en train de mettre en place, aux besoins de la chaîne logistique de l entreprise. Généralement, dans ce type de projet et comme le montre la Figure 1, le travail est guidé par les fonctionnalités du PGI. Pourtant, ces fonctionnalités sont exprimées à un bas niveau d abstraction avec beaucoup de détails comme les transactions à réaliser, les opérations à exécuter ou les données à gérer, et se focalisent sur une vision locale des processus concernés par le PGI ; au contraire, les gestionnaires de l organisation ont une vision globale et pensent en terme de buts ou résultats à atteindre. L organisation a des difficultés à s adapter au langage des experts en PGI, et par conséquent, ces personnes ne voient pas comment le nouveau système peut répondre à leurs exigences. Ceci expose le projet au risque d échec (Standish 1995) (Esteves et al., 2003), (Davenport, 1998), (Davenport, 2000). Organisation Besoins et exigences Approche guidée par les besoins de l entreprise Systéme PGI Descriptions Expression à haut niveau Orientée objectif et stratégie Vision globale Approche guidée par le PGI Description à bas niveau Orientée fonction Vision locale Figure 1. L organisation et le système - deux approches différentes Deux approches sont possibles pour rapprocher ces deux parties : - Une approche guidée par les besoins de l organisation : cette approche est classique et souhaitée par tous les acteurs métier de l entreprise afin d installer un système qui répondrait exactement à leurs besoins. - Une approche guidée par les fonctionnalités du PGI : cette approche est souhaitée par l éditeur et les intégrateurs qui souhaitent installer les fonctions standard du PGI par simple paramétrage et configuration sans être obligés de redévelopper des fonctions particulières pour prendre en compte les spécificités de l organisation. 2

Nous ne préconisons pas une et une seule de ces deux approches. Nous pensons qu il faut suivre les deux approches de manière combinée. C est donc un équilibre entre les deux approches qu il faut rechercher. En fonction de l organisation, de sa taille, de sa culture et de son secteur d activité, l équilibre peut être plus ou moins proche du système ou de l organisation. Pour trouver cet équilibre, on doit mettre en relation les besoins de l organisation et les solutions proposées par le PGI. Cette tâche n est pas simple du fait que les deux entités n expriment pas leurs exigences de la même façon ni au même niveau d abstraction. Comme le montre la Figure 2, les experts du métier de l organisation expriment leurs besoins au niveau intentionnel, alors que les experts techniques en PGI expriment les fonctionnalités du PGI au niveau opérationnel. On a besoin de rapprocher ces deux parties et de les faire communiquer au même niveau. Notre proposition est de ramener les deux parties à communiquer au niveau intentionnel. Cette façon est naturelle pour les gens du métier qui préfèrent exprimer leurs souhaits en terme d objectifs et de moyens pour les réaliser. Par contre, ce n est pas le cas des intégrateurs de PGI qui pensent en termes opérationnels comme les fonctions, les transactions ou les données. Disposant de leur propre modèle d entreprise, les experts en PGI essayent de forcer l organisation à s adapter aux processus proposés par le PGI. En fait, cela pose un problème majeur : la quantité de détails est énorme et les maîtriser devient une activité très coûteuse en temps et ressources. En plus ce n est pas naturel pour les gens du métier dans l organisation de penser en termes des processus du PGI. C est pourquoi une activité d abstraction est donc nécessaire pour extraire les buts et stratégies qui sont cachés derrière ces objets opérationnels. Le niveau intentionnel oblige les experts techniques à aller à l essentiel en faisant abstraction des détails opérationnels et techniques. On peut alors procéder à la mise en correspondance des buts et stratégies de l entreprise et ceux proposés par le PGI. Après avoir trouvé cette correspondance, on peut répercuter au niveau opérationnel les points communs. Niveau Intentionnel Entreprise Objectifs Matching PGI Objectifs Abstraction Abstraction Opérationalisation Opérationalisation Niveau Opérationnel Entreprise Processus Alignement PGI Modèle d entreprise Fonctionnalités Modules Figure 2. Les niveaux intentionnel et opérationnel 3

Notre approche pour répondre à la problématique de l alignement est de matérialiser la relation entre le système (le PGI) et l organisation par un modèle unique, appelé modèle de la Carte ou Map (Rolland et al., 2000)(Rolland et al., 2001). La section suivante présente un cadre méthodologique général d évolution du SI. La section 3 introduit la notion de carte. Le processus de mise en correspondance est détaillé en section 4. Nous illustrons la méthode présentée sur le projet SNCF en section 5. Enfin, la section 6 propose une discussion à partir de travaux similaires et notre agenda de recherche ainsi qu une conclusion. 2. Cadre méthodologique de l évolution du SI Jarke (Jarke et al., 1993) a proposé un cadre pour l évolution du SI présenté dans la Figure 3. Nous avons étendu ce cadre par une typologie d évolutions (Salinesi et al., 2003). Ce cadre méthodologique introduit quatre types de modèles : Existant MM Correspondance Existant MFS Processus du changement MM Correspondance MFS MM: Modèle Métier MFS: Modèle des Fonctionnalités du Système Figure 3. Cadre méthodologique général pour l évolution du SI - Modèle métier de l existant (Existant MM) 1 : représente les processus métier actuellement en place dans l organisation. - Modèle des fonctionnalités existantes du système (Existant MFS) 1 : représente les différentes fonctionnalités disponibles dans l actuel système informatique de l organisation. - Modèle métier de la cible ( MM) 1 : représente les processus métier cible que l organisation aimerait avoir après l évolution de son SI. - Modèle des fonctionnalités cibles du système ( MFS) 1 : représente les fonctionnalités du système informatique après l évolution du SI de l organisation. 1 Les termes anglais utilisés dans la littérature sont : Existant MM = As-Is Business Model (BM) ; MM = To-Be BM Existant MFS = System Functionality Model (SFM) ; MFS = To-Be SFM 4

Le cas étudié dans cet article correspond au type présenté à la Figure 4. Il correspond au paramétrage d une famille de produits. Pour prendre en compte ce type d évolution, on a adapté les modèles proposés par Jarke dans le cadre général. Les quatre modèles proposés dans ce cas sont : Souhaité MM MM Possible MFS Processus de mise en correspondance correspondance MFS MM: Modèle Métier MFS: Modèle des Fonctionnalités du Système Figure 4. Cadre méthodologique spécifique pour l évolution du SI de type paramétrage d une famille de produits - Modèle métier souhaité (Souhaité MM) 2 : représente les processus métier que l organisation souhaite mettre en place en implantant un PGI. - Modèle des fonctionnalités possibles du système (Possible MFS) 2 : représente les différentes fonctionnalités fournies par le PGI. - Modèle métier de la cible ( MM) : représente les processus métier de l organisation une fois que le PGI a été installé (après le projet). - Modèle des fonctionnalités cibles du système ( MFS) : montre les spécifications du PGI après la fin du projet, c est-à-dire après le paramétrage du PGI et les développements des fonctions spécifiques. Un processus de mise en correspondance entre les deux premiers modèles est nécessaire pour produire les deux derniers modèles ainsi que pour assurer leur adéquation, c est-à-dire s assurer que les fonctions du système répondent aux besoins et exigences de l organisation. Nous appelons cette adéquation par correspondance. Au niveau de l organisation, cela implique une adaptation des processus métier. Au niveau système, cela nécessite le paramétrage et la configuration du PGI et des autres SI. La situation à la SNCF est un peu plus complexe. En fait, différents formalismes sont utilisés pour établir les quatre modèles précédents. Dans la Figure 5, nous proposons une adaptation du cadre méthodologique pour la SNCF. On a introduit un cinquième modèle (Existant MM) qui représente le modèle métier de l existant avant la mise en place du PGI car la SNCF souhaite s assurer que le futur sera au moins équivalent au présent. 2 Les termes anglais utilisés dans la littérature sont : Souhaité MM = As-Wished BM ; Possible MFS = Might-Be MFS 5

A la SNCF, chacun des cinq modèles précédents est construit en utilisant un formalisme différent. Par exemple, le Souhaité MM est modélisé en utilisant les processus Mega, alors que le Possible MFS est modélisé en utilisant les Réseaux de Petri ; l Existant MM utilise un formalisme interne à l entreprise, etc. En outre, chacun des modèles a été développé ou sera développé par une partie différente de l équipe projet, et chaque membre de l équipe n est pas forcément familier avec les différents formalismes utilisés dans le projet. Existant Souhaité Formalisme SNCF MM MM Possible MM MM Carte utilise Carte Écarts Correspondance Processus de Mise en correspondance & Carte Intégrée Carte Similarités Correspondance Formalisme PGI Existant MFS Souhaité MFS MFS MFS Possible MM: Modèle Métier MFS: Modèle des Fonctionnalités du Système Figure 5. Cadre méthodologique spécifique pour la SNCF Notre proposition est d utiliser le formalisme de la «Carte de processus» (Map) pour représenter les modèles Existant MM, Souhaité MM et Possible MFS. Ceci correspond aux exigences de l équipe projet de ne pas influencer ou remplacer le développement des modèles existants. On remarque que le travail supplémentaire nécessaire pour développer les différentes cartes était utile puisqu il permet de synthétiser les modèles traités en termes abstraits et de supprimer les détails encombrants. D ailleurs, un travail similaire, si ce n est pas plus important, serait nécessaire si nous voulions établir les modèles Existant MFS, Souhaité MFS et Possible MM. Le processus de mise en correspondance concerne essentiellement deux familles de modèles (cartes) : les cartes du Souhaité MM et les cartes du Possible MFS. Deux techniques d ingénierie peuvent être utilisées pour pourvoir réaliser cette mise en correspondance : les écarts et les similarités. Les Similarités sont mieux adaptées dans le contexte de l évolution du SI par la mise en place d un PGI (Salinesi et al., 2004). 6

3. Modèle But-Stratégie Map Dans cette section on introduit les concepts clés du modèle de la carte qui seront utilisés dans la construction des différentes familles de cartes mentionnées dans la section précédente. Une description détaillée du modèle de la carte peut être trouvée dans (Rolland et al., 2000) (Rolland et al., 2001) et (Nurcan et al., 2004). Le model de la Carte (Map) est un modèle de processus exprimé au niveau intentionnel. Il fournit un système de représentation qui repose sur un ordonnancement non-déterministe de buts et de stratégies. La Figure 6 présente les concepts clés de la carte et leurs relations en utilisant la notation UML. La Figure 7 montre un exemple d une carte dans le cadre de la planification de production à la SNCF. Chemin Segment Paquet Carte * * * 2..* Section 0..1 Affiné par 1 1 1 1 But source A pour source Stratégie A pour cible But cible But Figure 6. Le méta-modèle de la carte Une carte est composée d une ou de plusieurs sections. Une section est une agrégation de deux types de buts (le but source et le but cible) et d une stratégie. La carte est représentée par un graphe orienté et étiqueté. Les buts sont représentés par les nœuds et les stratégies par les arcs reliant ces nœuds. La nature orientée de la carte est due au fait qu une stratégie indique le flux du but source au but cible. Un but est un objectif que l on peut atteindre par l exécution d un ou plusieurs processus. Par exemple, Etablir le plan multi-sourcing et Définir le plan d entreprise sont deux buts dans le domaine de la planification de production dans une entreprise industrielle. En plus, chaque carte possède deux buts particuliers, Démarrer et Arrêter, pour commencer et terminer l exécution de la carte. Une stratégie est une approche, une manière ou un moyen pour réaliser un but. Dans notre exemple, nous pouvons définir le plan de production Par produit ou Par unité de production. Une section est un triplet composé d un but source, d un but cible et d une stratégie. Une section exprime la réalisation du but cible en utilisant la stratégie une fois que le but source a été réalisé. Par exemple, l agrégation du but source Définir le plan d entreprise, du but cible Etablir le plan multi-sourcing et de la stratégie Par 7

Planning Solvers définit la section < Définir le plan d entreprise, Etablir le plan multi-sourcing, Par Planning Solvers>. Ici Par Planning Solvers caractérise le flux du but source Définir le plan d entreprise au but cible Etablir le plan multi-sourcing et la manière de réaliser la cible. Stratégies C1.Par unité Démarrer de gestion C5.Par réseaux de d approvisionnement C9.Révision/Maintenance C2.Par produit C6.Planification multi-site C3.Planification en ligne C7.Par Planning Solvers Définir le plan d entreprise Établir le plan multi-sourcing C8.Par simulation «What-If» C4.Révision/Maintenance C11.Par produit C12.Révision/Maintenance C10.Par unité de production Buts Définir la plan de production Multi-segment C14.Par consommation des prévisions Arrêter C13.Par validation Figure 7. Un exemple de carte de planification de la production dans PeopleSoft Le graphe de la carte montre les relations de précédence/succession entre les différentes sections. Pour qu une section S 1 succède à une autre section S 2, son but source I S1 doit être le but cible I C2 de l autre section S 2. Dans notre exemple, considérons que nous voulons définir le plan de production pour une unité de production. La carte de la Figure 7 indique clairement que l on ne peut pas faire cela si le plan multi-sourcing n a pas été établi au préalable. Donc, on peut dire qu il y a une relation de précédence/succession entre la section <Définir le plan d entreprise, Etablir le plan multi-sourcing, Par Planning Solvers > et la section < Etablir le plan multi-sourcing, Définir le plan de production, Par unité de production>. Multi-segment : dans une carte, il est possible de réaliser un but cible à partir d un but source en utilisant plusieurs manières. Chacune de ces manières est exprimée comme une section dans la carte. Cette topologie est appelé multi-segment. Quand les différentes stratégies composant un multi-segment sont mutuellement exclusives, on parle d un Paquet. Dans notre exemple, et à partir du plan multisourcing, le plan de production peut être défini Par produit et/ou Par unité de production. Multi-chemin : Dans une carte, il est possible de réaliser un but en utilisant différentes combinaisons de sections. En d autres termes, un but donné peut être réalisé en suivant plusieurs chemins dans le graphe. Par exemple, pour Définir le plan de production, il existe plusieurs possibilités : 8

- Définir le plan d entreprise par produit, puis établir le plan multi-sourcing en utilisant une simulation de type «what-if», ensuite définir le plan de production par produit. - Définir le plan d entreprise par unité de gestion, puis établir le plan multi-sourcing en utilisant une planification multi-site, ensuite définir le plan de production par unité de production. - Définir le plan de production par la stratégie de révision et de maintenance. Etc Niveau n Niveau n+1 Démarrer C10.2.Par atelier C10.1.Par unité de production Planifier l adéquation charge/capacité C10.3.Pour les commandes Établir le plan multi-sourcing C10.Par unité de production Définir la plan de production C10.4.Par atelier C10.6.Par réactualisation mensuelle C10.5.Pour les prévisions C10.7.Pour les commandes C10.8.Pour les prévisions Déterminer les PDP prévisionnels C10.10.Pour les moyens de transport C10.9.Pour les moyens de réception Déterminer les PDP fermes C10.11.Par transmission aux unités de production Planifier les besoins de livraison C10.12.Par transmission aux unités de production Arrêter C10.13.Par validation Figure 8. Affinement de la section C10 Relation d affinement : La Figure 6 montre qu une section de la carte peut être affinée par une autre carte complète par la relation d affinement. Cela permettra de décrire une section à un niveau d abstraction donné n, par une carte à un niveau d abstraction moins élevé n+1. Ce mécanisme permettra de modéliser les exigences à plusieurs niveaux de détails. Par exemple, dans la carte de la Figure 7, on peut affiner la section C10 <Etablir le plan multi-sourcing, Définir le plan de production, Par unité de production> par la carte de la Figure 8. Cette carte est plus opérationnelle que la carte principale dont une section a été affinée. Des sections de cette nouvelle carte peuvent elles aussi êtres affinées par de nouvelles cartes et ainsi de suite 4. Processus de mise en correspondance Pour conduire les projets d installation de PGI, il existe plusieurs méthodes comme ASAP (Khan, 2002) ou ARIS (Scheer et al., 2002). Mais ces méthodes se concentrent sur la gestion de projet et ne fournissent que peu d outils d ingénierie nécessaires pour répondre à la problématique de mise en correspondance. Comme 9

un certain nombre d auteurs (Maiden et al., 1998) et (Finkelstein et al. 2002), nous pensons que les méthodes d ingénierie sont toujours nécessaires pour guider le processus d analyse des exigences dans les projets de type PGI. Pour cette raison, nous avons développé un modèle de processus. Ce modèle a été construit de façon itérative et des améliorations sont apportées tout au long du projet. Comme le montre la Figure 9, notre méthode possède deux activités principales : la construction des modèles Existant, Souhaité et Possible et la construction des modèles s. En fait, les modèles s peuvent être construits au fur et à mesure par un processus de mise en correspondance dirigé par l Existant, le Souhaité ou le Possible. Les modèles Existant, Souhaité et Possible peuvent être abstraits par des cartes et améliorés à partir des modèles s par une rétroaction. Chacune de ces approches nécessite une manière différente de travail, mais des techniques de similarités peuvent être utilisées dans les différents cas. Processus de mise en correspondance Existant Souhaité Possible Dirigé par L Existant Dirigé par le Souhaité Dirigé par le Possible Rétroaction Figure 9. Processus d analyse des exigences dans un projet PGI Le processus de construction de l ensemble des modèles Existant, Souhaité, Possible et est décrit dans le Tableau 1. Cette description affinée montre que : - la construction des modèles Existant, Souhaité ou Possible est entrelacée ; - chaque type de carte est construit en utilisant des démarches spécifiques ; - la construction d un type de modèles informe sur la construction des autres types. Le processus de mise en correspondance est au cœur du modèle présenté dans la Figure 9. Il se résume au passage entre la Construction des modèles Existant, Souhaité et Possible et la Construction des modèles s. Le produit de ce processus est la famille des cartes du modèle qui représentent les exigences de l organisation et du PGI. Ces cartes servent ensuite de point d entrée au processus d installation du PGI. La majorité des buts et stratégies des cartes du modèle sont obtenus à partir des cartes du PGI qui correspondent aux besoins exprimés dans les cartes du modèle Souhaité. D autres buts et stratégies qui ne sont pas inclus dans les cartes du PGI mais figurent dans celles du modèle Souhaité peuvent être considérés en proposant de faire des développements spécifiques. Dans ce cas, les cartes du modèle aident à identifier et spécifier ces développements 10

spécifiques. Par contre, tous les buts et stratégies du PGI peuvent ne pas être repris dans les cartes du modèle. Ceux-ci correspondent aux fonctionnalités du PGI dont l organisation n a pas besoin. Activité A partir de démarche utilisée Construire l'existant page blanche To-Down retro analyse Rétroaction page blanche To-Down Dirigé par les écarts Existant Non-régression Construire le Souhaité par les contraintes par les meilleurs pratiques métier par les dysfonctionnements Possible par réutilisatin des meilleurs pratiques du PGI Rétroaction page blanche abstraction Construire le Possible Souhaité dirigé par le projet Rétroaction page blanche Directement Construire la Existant Mise en correspondance dirigée par l'existant Souhaité Mise en correspondance dirigée par le Souhaité Possible Mise en correspondance dirigée par le Possible Tableau 1. Le processus de construction de chacun des quatre modèles La construction des cartes du modèle peut être dirigée par les cartes du modèle Possible, les cartes du modèle Existant ou les cartes du modèle Souhaité. Dans chacun de ces cas, nous considérons les buts et les stratégies situés entre le but Démarrer et le but Arrêter et nous décidons : (i) si elles correspondent aux exigences à incorporer dans les cartes du modèle ; (ii) si des adaptations sont nécessaires avant des les intégrer dans les cartes du modèle ; (iii) ou si on ne les prend pas en compte dans les cartes du modèle. Nous pensons que l approche dirigée par les cartes du PGI est la plus utilisée dans les projets d implantation de PGI surtout dans les petites et moyennes entreprises, dans la mesure où le concept de PGI est de pouvoir proposer des outils supportant les meilleurs pratiques métier du marché. Par contre, les approches dirigées par l Existant ou le Souhaité, puisqu elles partent des besoins spécifiques, limitent les possibilités de mise en correspondance. Cette dernière approche est très pertinente dans le cas où l organisation détiendrait des processus métier spécifiques grâce auxquels l organisation possède un avantage concurrentiel sur les autres acteurs de son marché. C est souvent le cas des grandes entreprises. La mise en correspondance étant un processus proactif, des affinements de l ensemble des modèles sont possibles à tout moment du processus en suivant la démarche rétroactive dès que la construction des cartes du modèle a commencé. Finalement, et pour que la mise en correspondance soit valide, les exigences exprimées à travers les cartes du modèle Souhaité doivent être vérifiées. 11

5. Exemple : le cas de la SNCF Nous travaillons avec la SNCF depuis deux ans. Nos recherches concernent un projet d implantation d un PGI (PeopleSoft). Ce projet a été choisi pour servir de pilote à l étude menée. Ce projet présente beaucoup d aspects intéressants pour conduire une étude de recherche. Les aspects les plus importants sont : - un très grand projet industriel ; - une organisation très complexe qui fait intervenir des acteurs très variés ; - il concerne la problématique de l étude ; - le projet utilise une méthode propre pour la modélisation et la gestion de projet ce qui va nous permettre de procéder à une comparaison ; - les solutions techniques envisagées dans le projet présentent un intérêt pour nos recherches dans le cadre de l évolution du SI. L objectif du projet est de participer à l'optimisation des processus d'approvisionnement. Son périmètre couvre l ensemble de la problématique de l approvisionnement depuis l expression des besoins par l utilisateur jusqu à la réception et la facturation. Les acteurs concernés par ce projet sont très variés : des unités de production, de stockage, des achats, du contrôle et des utilisateurs du matériel. La solution informatique envisagée dans le projet concerne un PGI qui permettra de piloter, d optimiser et de maîtriser en terme de coût et de qualité la chaîne d approvisionnement. Le développement de modules de GPAO (Gestion de la Production Assistée par Ordinateur) pour les unités de production sur la base de le PGI permettent d optimiser et de mieux maîtriser les coûts de production. Activité A partir de démarche utilisée page blanche To-Down retro analyse Rétroaction page blanche To-Down Dirigé par les écarts Existant Non-régression par les contraintes par les meilleurs pratiques métier par les dysfonctionnements Construire les cartes de l'existant Construire les Cartes du Souhaité Construire les cartes du Possible Possible page blanche Souhaité par réutilisatin des meilleurs pratiques du PGI Rétroaction abstraction dirigé par le projet Rétroaction Tableau 2. Les différentes démarches utilisées dans le projet SNCF pour la construction des cartes Dans le projet SNCF, nous avons adapté le cadre méthodologique général pour prendre en compte les spécificités du projet (voir Figure 5). Le processus d analyse présenté dans la Figure 9 a été exécuté partiellement, surtout la première partie concernant la construction des modèles Existant, Souhaité et Possible qui est détaillée dans le Tableau 1. Dans cette application, les modèles correspondent aux cartes, et le Possible concerne le PGI PeopleSoft. Un certain nombre de démarches a été utilisé pour la construction des trois familles de cartes. Dans le Tableau 2, les démarches qui n ont pas été utilisées sont représentées en fond gris. Le contexte du 12

projet SNCF impose l utilisation de certaines démarches. Mais dans le cas général, toutes ces démarches peuvent être utilisées afin de construire les différentes familles de cartes. Le domaine du projet SNCF étant très large, nous avons essayé de suivre l avancement du projet et de respecter les étapes préconisées par l équipe projet. Cette contrainte nous a conduit à suivre un ordre prédéfini dans la construction des cartes. Les cartes de l Existant ont été construites pour l ensemble des macros processus. Après leur validation, les cartes du modèle Souhaité ont à leur tour été dessinées et validées avant de commencer l établissement des cartes de PeopleSoft en fonction de certains processus de la cible, c est pourquoi nous avons choisi la démarche Dirigé par le projet pour la construction des cartes du modèle Possible. Vu la complexité des processus concernés, on a adapté l approche top-down, et on s est limité à quelques niveaux d affinement (entre 4 et 5). Le but étant de se concentrer sur l essentiel du métier et de ne pas se noyer dans les détails opérationnels. Démarrer 1 Stratégie prévisionnelle 2 Stratégie ferme Analyser les besoins 3 Stratégie d arbitrage 4 Stratégie de Stock Gérer les ressources 5 Stratégie de Production 8 Stratégie de livraison 6 Stratégie de retour du matériel 7 Stratégie d achat Servir le client 10 Stratégie comptable 9 Stratégie comptable 11 Stratégie de litige récupération Arrêter 12 Par litige Existant Démarrer 1 Stratégie prévisionnelle Démarrer 1-Stratégie prévisionnelle 5 Stratégie d achat 5-Stratégie d achat 2 Stratégie ferme 6 Stratégie de Stock 2-Stratégie ferme 6-Stratégie de Stock Gérer les besoins 7 Stratégie de Production Servir le client Gérer les besoins 7-Stratégie de Production Servir le client 3 Stratégie du catalogue 8 Stratégie de livraison 3-Stratégie du catalogue 8-Stratégie de livraison 4 Stratégie de planification 9 Stratégie de retour du matériel 10 Stratégie comptable 4-Stratégie de planification 9-Stratégie de retour du matériel 10-Stratégie comptable 11 Stratégie de litige 11-Stratégie de litige Arrêter Arrêter Souhaité Possible Figure 10. La carte de plus haut niveau des modèles Existant, Souhaité et Possible La Figure 10 montre un aperçu sur les cartes de plus haut niveau des trois familles : l Existant, le Souhaité et le Possible. 13

Des affinements de ces 3 cartes ont donné lieu à un grand nombre de cartes. Les cartes du PGI sont beaucoup plus nombreuses et plus riches en stratégies dans la mesure où un PGI propose des solutions génériques à paramétrer en fonction de l entreprise. Établir le PIC 1-À partir des grandes orientations prévisionnelles Démarrer 3-Par simulation 2-Par révision tous les 6 mois Choisir le plan multi-sourcing 5-Pour le centre de stockage 4-Pour les unités de production Déterminer le PDP Déterminer les plans d appro 6-Par consommation par les commandes fermes 7-Par consommation par des DA Arrêter Figure 11. Un exemple de carte du modèle Souhaité 1-Par planification collaborative 2-Par planification en ligne 7-Stratégie de révision 8-Stratégie de maintenance Démarrer 18-Stratégie de révision 3-Par unité de gestion 4-Par produit 5-Par contrainte 6-Par Work Center 14-Stratégie de révision Déterminer les plans de production 9-Par simulation what-if 17-Pour les unités de production 10-Planification multi-site 16-Par produit 29-Par validation Établir le PIC 11-Par la disponibilité de production 12-Par réseau de sourcing Choisir le plan multi-sourcing 26-Par validation 20-Par équilibrage entre l inventaire et la planification pour le réappro de matériel 30-Par validation 13-Par planning slovers 15-Stratégie de maintenance 21-Par produit 22-Pour le centre de stockage Déterminer les plans d appro 19-Stratégie de maintenance 28-Par consommation des prévisions 27-Par transfert des ordres de production planifiées Arrêter 31- Par consommation des prévisions 25-Par validation 24-Stratégie de maintenance 23-Stratégie de révision Figure 12. Un exemple de carte du modèle Possible 14

Les Figures 11 et 12 montrent un exemple de comparaison des cartes à un niveau donné (niveau 2). Nous avons sélectionné deux cartes, la première concerne le Souhaité (Figure 11) tandis que la deuxième décrit le Possible (Figure 12). On remarque très clairement que la carte du PGI est beaucoup plus riche que celle du Souhaité. Cependant, il existe des stratégies dans la carte de la cible comme Par révision tous les 6 mois qui n ont pas de correspondant dans la carte du PGI, ce qui nécessitera des développements spécifiques dans le nouveau système à mettre en place. 6. Discussions Ce papier a présenté un cadre méthodologique que nous sommes en train d expérimenter dans le contexte de l évolution du SI par l implantation d un système de type PGI à la SNCF. Malgré le grand nombre de projets d installation des PGI dans des entreprises de différentes tailles (Joseph et al. 1998), les recherches académiques concernant les problématiques liées aux aspects d ingénierie restent limitées (Borell et al., 2000). Les discussions avec des membres d équipes d autres projets d installation de PGI ont montré que notre approche est appropriée dans ce genre de projet, et que beaucoup de décideurs adoptent des PGI sans explorer la mise en correspondance entre leurs besoins et les fonctionnalités proposées dans le PGI en question. En fait, l un des plus importants facteurs d achat d un PGI est que ce genre de systèmes propose les meilleurs pratiques métier. De plus, comme l idée est d adopter ces pratiques métier en installant le PGI, l évaluation des coûts et de la valeur ajoutée de leur adoption à travers un processus de mise en correspondance avec les exigences métier est souvent oublié (Robey et al., 2002). Deux familles d approches ont été développées pour traiter le problème de mise en correspondance : l approche du management et l approche du système. Dans l approche du management, les recherches visent à définir l impact de l installation de PGI sur la culture d entreprise (Krumbholz et al. 2000), sur l organisation (Robey et al., 2002) ou sur les processus métier (Esteves et al., 2002). Dans l approche système, l objectif était de guider l identification et la sélection du PGI le plus approprié (Ncube et al., 2000), et d analyser les besoins pour proposer le meilleur paramétrage du PGI (Finkelstein et al., 2002). Notre approche (Salinesi et al., 2003), (Zoukar et al., 2004a), (Zoukar et al., 2004b) est à mi-chemin entre ces deux familles. L hypothèse essentielle est que, dans un projet d installation d un PGI, la question du changement organisationnel et celle de l ingénierie du système sont entrelacées. Par conséquent, la mise en correspondance du PGI et des exigences de l organisation ne devrait pas être dirigée ni par le management ni par les fonctionnalités du système, mais par les deux en même temps. 15

Des discussions ont été entreprises pour choisir parmi les solutions alternatives résultant du processus de mise en correspondance. On a constaté que ces décisions ont été prises en utilisant un certain nombre de critères tels que le pourcentage des développements spécifiques, la non-régression, les coûts, les délais de mise en place, les compétences nécessaires, les marges de négociation, la valeur ajoutée, etc. Il s'est avéré pendant les discussions que nous avons eues avec l équipe projet que non seulement ces critères n'ont pas le même poids, mais également le poids de chaque critère pouvait changer selon le contexte. L'analyse de profit peut être supportée par des techniques telles que l'aide à la Décision Multicritères (Roy et al., 1993), ou l AHP (Analytic Hierarchy Process) (Saaty 1988). Cependant, ces techniques ne tiennent pas compte du fait que les poids de critères peuvent changer, et donc elles ne sont pas appropriées quand un grand nombre d exigences est traité. Des techniques plus avancées sont donc nécessaires. Nos recherches courantes et futures incluent donc : - Le développement d'un processus méthodologique pour guider la découverte des exigences par les écarts et les similarités ; - La formalisation d'un processus de mise en correspondance dans un contexte de personnalisation des composants ; - L évaluation de la méthode proposée. Bibliographie Borell A., Hedman J. CVA Based Framework for ERP Requirement Specification. Procs. of IRIS 23. Laboratorium for Interaction Technology, University of Trollhattan Uddevalla, 2000. Davenport T.H. Putting the Enterprise into the Enterprise System. Harvard Business Review.(76:4), pp. 121-131, 1998. Davenport T.H. Mission Critical: Realizing the Promise of Enterprise Systems. Harvard Business. School Press, MA, 2000. Esteves J., Pastor J., Casanovas J. Monitoring Business Process Redesign in ERP Implementation Projects. Americas Conference on Information Systems, Dallas, 2002. Esteves J., Pastor J. Strategic and Tactical Critical Success Factors Behavior Along the ERP Implementation Phases. The European Conference on Information Technology Evaluation (ECITE), Madrid (Spain), September 2003 Finkelstein A., Bush D. Requirements Elicitation for Complex Safety Related Systems. Procs London Communication Symposium. London, UK, Sept. 2002 Jarke M., Pohl K. Establishing visions in context: towrd a model of requirements processe. In Procs 12 th International Conference Information System. Orlando, FI, 1993. Joseph T., Swanson E.B. The Package Alternative in Systems Replacement: Evidence for Innovation Convergence, in Information Systems Innovation and Diffusion: Issues and Direction. Larsen & McGuire (eds.), IDEA-Group, Hershey, PA, pp. 375-389, 1998. 16

Khan A.H. Implementing SAP with an ASAP Methodology Focus. Paperback (0595233988), July 2002.0595233988 Krumbholz M., Maiden N.A.M. How Culture might impact on the Implementation of Enterprise Resource Planning Packages. Procs of CAISE'00, Springer Verlag, Ref. HCID00/04, 2000. Maiden N.A.M., Ncube C. Acquiring COTS Software Selection Requirements. IEEE Software March/April 1998, pp. 46-54, 1998. Ncube C., Maiden N.A.M. COTS Software Selection: The Need to Make Tradeoffs Between System Requirements, Architectures and COTS/Components. Procs of the COTS*2000 Workshop for ACSE*2000, Limerick, Ireland, ref. HCID00/02, 2000. Nurcan S., Etien A., Kaabi R. Zoukar I. A Strategy Driven Business Process Modeling Approach. Special issue of the Business Process Management Journal on "Goal-oriented Business Process Modeling", Emerald. To appear. 2004. Robey D., Ross J.W., Boudreau M-C. Learning to Implement Enterprise Systems: An Exploratory Study of the Dialectics of Change. Journal of Management Information Systems, Summer 2002 Rolland C., Prakash N. Bridging the Gap Between Organisational Needs and ERP Functionality. In Requirements Engineering Journal, 5(2000). Rolland C., Prakash N. Matching ERP System Functionality to Customer Requirements. The 5 th IEEE International Symposium on Requirements Engineering, Toronto, Canada. 2001. Roy B., Bouyssou D. Decision-Aid, An Elementary Introduction with Emphasis on Multiple Criteria. Journal of Information Science and Technology, 2(2), pp 109-123. 1993 Saaty T.L. The Analytic Hierarchy Process. University of Pittsburgh, 1988. Scheer A.W., Jost W., Abolhassan F. Business Process Excellence: Aris in Practice. Springer Verlag, Berlin. (2002). Salinesi C., Rolland C. Fitting Business Models to Software Functionality : Exploring the Fitness Relationship. Procs of the 15 th Conference on Advanced Information Systems Engineering, (CAISE'03), Springer Verlag (pub), 2003. Salinesi C., Etien A. Zoukar I. A Systematic Approach to Express IS Evolution Requirements Using Gap Modelling and Similarity Modelling Techniques. Procs of the 16th Conference on Advanced Information Systems Engineering (CAISE'04), Riga, Latvia. June 2004. The Standish Group. Chaos. Standish Group Internal Report. www.standishgroup.com/ sample_research/chaos_1994_1.php, 1995. Zoukar I, Salinesi C. Engineering the Fitness Relationship between an ERP and the Supply Chain Process at SNCF. IRMA' 2004, 15 th International Conference of the Information Resource Management Association, New Orleans, Louisiana, USA. May 2004 Zoukar I, Salinesi C. Matching ERP Functionalities with the Logistic Requirements of French railways - A Similarity Approach. ICEIS' 2004, 6 th International Conference on Enterprise Information Systems. Porto, Portugal, April 2004. 17