9.4 Exemple
9.4.2 Gestion de projet dans le déploiement d’un ERP
Nous connaissons la décomposition structurelle du travail en une arbre de tâches dans un projet ERP (§ 4.2.1). Nous avons présenté les deux principales étapes d’un tel projet, chacune des étapes étant composée de plusieurs macro tâches. Cette organisation peut être résumée à l’aide du schéma suivant (fig. 9.11) décrivant à la fois l’organisation et l’enchaînement de ces tâches.
Fig. 9.11 – Macro tâche d’un projet ERP
Notre conduite de projet propose un enchaînement un peu différent des différentes tâches, principalement dans la sélection de l’ERP. Nous estimons que les grilles de sélection, fournis par le CXP ou le CETIM, ne permettent pas de mettre l’accent sur les besoins de l’entreprise et sur l’implication des fonctionnalités non couvertes de la solution logicielle. De plus, c’est l’éditeur qui répond aux questions, tandis que la MOA (Maîtrise d’OuvrAge) doit miser sur la
bonne foi de ce dernier pour les points qui ne sont pas pris en compte par le jeu de tests, puis appliquer des pondérations entre les réponses pour réaliser son classement des propositions. Cette démarche souffre d’un manque d’accès à la définition technique de chaque outil pour permettre de juger la cohérence de la réponse.
La communication, pour être efficace, doit permettre au client d’aller lui-même puiser, en utilisant un modèle, les réponses aux questions qu’il se pose à travers une représentation formelle des capacités du progiciel, d’où le recours à un modèle de référence appréhendé comme un modèle de Systèmes d’Information.
Le problème qui se pose alors au client réside dans l’utilisation d’un formalisme qu’il ne maîtrise pas forcément. Nous avons vu dans les précédents chapitres qu’il existe bon nombre de formalismes de représentation pour la modélisation d’entreprise comme pour la modélisation de solutions logicielles. La faisabilité du bon déroulement de notre conduite de projet est donc conditionnée par la réduction des formalismes de modélisation employés et par la mise à disposition d’un maximum d’informations, via le modèle de la solution logicielle, de la part des éditeurs.
Il est donc nécessaire, dans un premier temps, lors de l’étape de sélection, de proposer au client des éléments de représentation de haut niveau, compréhensibles sans être nécessairement un informaticien. Ces éléments permettent, par un mécanisme de spécialisation, de définir le périmètre fonctionnel, d’identifier les principaux processus de l’organisation, ainsi que les objets métiers jouant un rôle dans la solution logicielle (classes candidates). Une seconde passe, basée sur un mécanisme d’extension, permet de voir s’il existe des manques dans la solution déployée.
Dans un deuxième temps, lors de l’étape de déploiement, l’analyse se veut plus détaillée que dans l’étape de sélection. Le problème de la méthode reste pourtant quasiment le même. En effet, il s’agit toujours d’exprimer un besoin et de trouver les solutions dans le progiciel en proposant un bon paramétrage des fonctions standard. Nous allons donc pouvoir utiliser des éléments du formalisme UML de plus bas niveau. Pour aider le client à modéliser ses besoins, il est nécessaire de mettre en place une équipe projet. Du côté du client, nous retrouvons les personnes en charge d’exprimer ces besoins, de caractériser les processus de l’entreprise, de montrer l’organisation de celle-ci, et du côté de l’éditeur (principalement pour les PME/PMI), nous retrouvons des chefs de projet, ayant des connaissances aussi bien en génie industriel qu’en génie logiciel, capable d’assimiler ces informations et de les transformer afin de réaliser le modèle de la solution finale. C’est le chef de projet qui aura la maîtrise de la modélisation des besoins détaillés du client et qui aura la charge de faire valider les résultats par le client. Nous proposons donc deux itérations dans l’utilisation de notre cadre de référence. La première itération permettra de mettre en concurrence les différents modèles des solutions logicielles et de choisir l’ERP adéquat. Lors de la deuxième itération, il s’agira de détailler plus précisément le modèle par rapport à l’organisation de l’entreprise.
9.4.2.1 Sélection de l’ERP
Nous proposons donc d’utiliser notre cadre de référence pour la sélection de l’ERP. Lors de cette première itération, nous utilisons les mécanismes de spécialisation et d’extension pour adapter le modèle d’entreprise au fonctionnement de l’entreprise cible par rapport à son savoir-faire (automobile, électronique, ...) et à son mode de gestion (à la commande, à l’affaire, MRP, SCM, ...). Pour accélérer l’application des mécanismes, nous utilisons une base de connaissances fournissant des parties de modèles. Ces modèles sont définis pour le niveau partiel de la dimension de généricité.
152 CHAPITRE 9. CADRE DE RÉFÉRENCE
9.4.2.1.1 Première phase
La première phase (fig. 9.12) représente le premier mécanisme de spécialisation pour obtenir le modèle de l’entreprise cible (modèle entreprise particulier) à partir :
– soit des concepts de modélisation d’entreprise, – soit des modèles partiels spécifiques à un métier.
Afin d’accélérer la conduite du projet de déploiement, nous proposons une base de connais- sance fournissant un ensemble de référentiels représentant des modèles d’entreprise suivant son savoir-faire et son mode de gestion.
Nous proposons d’utiliser les grilles GRAI pour présenter les différentes typologies d’entre- prise. Cette base est utilisée par l’intégrateur pour obtenir, comme le dit Boutin, l’existant de l’entreprise, le modèle AS-IS.
Fig. 9.12 – Conduite de projet « Première phase »
Cette démarche doit permettre de mettre en concurrence deux éditeurs (ERP1 et ERP2) de solutions logicielles distinctes. L’obtention du modèle particulier de l’entreprise doit permettre d’obtenir le taux de couverture de la solution logicielle d’un éditeur par rapport au modèle obtenu. Le travail sur les spécifications métiers est fait une fois pour tous les niveaux de spécifications, un niveau par éditeur.
9.4.2.1.2 Deuxième phase
Le déroulement complet de cette deuxième phase est soumis à certaines conditions. Le mé- canisme d’extension n’est nécessaire que dans le cas où il y a eu découverte d’un besoin non
couvert (TFP) par une fonctionnalité de la solution logicielle. Le client a alors deux possibili- tés :
– ignorer ce trou fonctionnel et adapter son organisation,
– demander à l’éditeur ou l’intégrateur de développer un spécifique relatif à son besoin. Le développement de spécifique a bien entendu un impact sur la solution logicielle. Nous reviendrons plus tard sur ce point (§ 9.6). Pour l’éditeur, le développement de spécifique est un avantage concurrentiel. À partir de ce constat, suivant le taux de correspondance de la solution logicielle avec les attentes de l’entreprise, le client a déjà la possibilité d’éliminer des éditeurs trop éloignés de la solution attendue (Choix de l’ERP). Pour les autres éditeurs, il est possible de mettre en place le mécanisme d’extension afin d’effectuer l’analyse des développements spécifiques à réaliser. L’utilisation d’une base de connaissances par les chefs de projet permet de voir si ce type de développement spécifique n’a pas déjà été réalisé. Cette base peut également être utilisée comme outil d’aide dans l’analyse du spécifique (étude des coûts et des ressources que cela implique pour tenir des délais de mise en œuvre).
Fig. 9.13 – Conduite de projet « Deuxième phase »
Dans la deuxième phase de cette conduite de projet, nous avons fait le choix d’utiliser le méca- nisme d’extension jusqu’au niveau générique de la dimension de généricité. Nous présenterons dans la section 9.6. le fait qu’il soit possible d’atteindre d’autres niveaux avec ce mécanisme. Dans un second temps, le développement de spécifique doit servir à l’éditeur de la solution logicielle. En effet, l’éditeur doit remettre en cause son modèle métier et le modèle de référence de la solution logicielle. Si lors du déploiement de l’ERP, on s’aperçoit qu’il est nécessaire de réaliser un développement spécifique, cela veut dire qu’il existe un manque dans ces modèles. La fonctionnalité découverte a certainement une utilité pour cette catégorie d’entreprise. Il
154 CHAPITRE 9. CADRE DE RÉFÉRENCE
s’agit d’une phase classique de retour d’expérience et de capitalisation de connaissances sur chaque projet ERP, même si l’éditeur n’est pas retenu par le client lors de l’étape de sélection.
9.4.2.2 Déploiement
L’outil est choisi, c’est donc le temps de la juste adéquation entre le logiciel et l’organisation. Nous pouvons donc réaliser une deuxième itération de notre conduite de projet dans l’objectif :
– d’analyser les besoins de manière plus détaillée que dans l’étape de sélection,
– d’exprimer ces besoins et de trouver les solutions dans le progiciel en proposant le bon paramétrage des fonctions standard,
– de multiplier les jeux de tests dans un souci de validation, avant la mise en production du Système d’Information,
– de combler les trous fonctionnels, sachant que le choix du client de développer ou non un spécifique, en connaissance de cause, va impacter le coût et le délai, mais également sur la maintenance en exploitation (ou évolutive - mise à jour du produit) de son système. Quel niveau de granularité atteindre dans la spécification détaillée des besoins de l’entreprise ? Cette question est délicate et elle doit être discutée avec le client lors des différentes analyses. Un élément de réponse se situe dans le choix, par l’entreprise, d’utiliser des processus standard de la solution logicielle. Dans ce contexte, il n’y a pas d’intérêt à détailler ce processus, nous pouvons donc rester à un niveau macroscopique. Par contre, si, pour l’entreprise, le processus choisi est critique dans l’atteinte des performances, c’est-à-dire qu’il touche son cœur de métier, alors il est nécessaire de descendre à un niveau de détail supérieur sur tout ou partie de ce processus. Le modèle doit donc permettre de conjuguer plusieurs niveaux de granularité en fonction de l’importance relative des processus, au gré du client, en prenant en compte, même s’il est aidé par l’équipe projet, des difficultés probables d’appropriation de la modélisation. Dans le même ordre d’idée, nous devons aussi nous intéresser au niveau de détail des objets de l’entreprise. Dans la précédente étape (sélection de l’ERP), nous parlions d’objets de l’entre- prise comme des classes candidates représentant des objets réels tels qu’un bon de livraison, une commande, une fiche produit... Il est possible que le client souhaite adapter ces objets métiers à son organisation. Il est donc nécessaire de proposer au client de pouvoir spécifier, modifier ou paramétrer ces objets métiers. Mais comme pour l’analyse détaillée des processus, nous devons adapter le formalisme utilisé afin qu’il soit compréhensible.