En se basant sur une enquête auprès de 150 entreprises, toutes tailles confondues, et où les PME/PMI (de moins de 500 salariés) constituent 70 % de l’échantillon, Robert Canonne et Jean-Louis Damret publient les résultats suivants :
– pour 60 % des entreprises, le délai de déploiement de l’ERP a été de 7 à 24 mois. Seul 10 % de ces entreprises ont eu un délai inférieur,
– les coûts sont détaillés dans le tableau suivant1 (tab. 4.1). D’après les auteurs, 20 % des coûts représente l’achat des licences, et 10 % représente l’achat d’équipement. Le reste
1
Il est nécessaire de préciser aux lecteurs que malheureusement ces chiffres ne sont pas croisés avec la taille de l’entreprise, donc le nombre d’utilisateurs du système.
46 CHAPITRE 4. GESTION DES PROJETS ERP Dépenses engagées (Millions euros) Fréq.
moins de 0,29 Me 28,00 % de 0,3 à 0,74 Me 20,00 % de 0,75 à 1,5 Me 18,67 % de 1,6 à 7,4 Me 25,33 % de 7,5 à 15 Me 2,67 % de 16 à 30 Me 1,33 % de 31 à 45 Me 4,00 %
Tab. 4.1 – Dépenses engagées
est imputable aux coûts internes de personnel, et aux coûts de services de conseil et d’assistance.
De nombreuses études montrent que le nombre d’échecs dans le déploiement d’un ERP est très important. En 1995, une étude réalisée par le Standish Group (CHAOS chronicle1) estime à 69 % le taux d’échec de ces projets. En 2002, l’étude de Robbins-Gioia LLC2 précise que 51 % des implantations d’ERP sont des échecs.
Les principales causes d’échecs sont de deux ordres :
– difficultés liées au projet : dérive sur les coûts humains engendrés par l’allongement des délais de réalisation,
– difficultés liées à la culture de changement : incompréhension dans l’utilisation et le fonctionnement du système et par conséquent refus de la part des utilisateurs.
La dérive sur les coûts peut avoir deux raisons, l’une concernant une sous-évaluation de la complexité du projet et l’autre un manque de compétences des parties prenantes. C’est pour cela qu’il est très important de travailler sur le périmètre fonctionnel du futur système et sur la composition des équipes projet (Redouane El Amrani, 2003).
La satisfaction des utilisateurs (Imen Maaloul et Lassaâd Mezghani, 2003) est un critère important à surveiller dans la mise en œuvre d’un nouveau système. L’implantation d’un nouveau système engendre des difficultés aussi bien individuelles qu’organisationnelles. Ces réticences se concrétisent par un échec dans l’appropriation de l’outil par les utilisateurs. Il est clair que ces causes sont des caractéristiques fortes d’échecs des projets SI en général, et ERP en particulier. L’échec se constate rapidement alors que le succès se constate plutôt lentement.
La mesure du succès est plus difficile à mettre en place. Tout d’abord, parce que très peu d’entreprises mettent en place des indicateurs pour mesurer le retour sur investissement (ROI). Ces métriques doivent mesurer les résultats de l’entreprise et la performance du système dans le temps. En outre, le succès dans le déploiement d’un outil à court terme n’assure pas automatiquement un succès et une amélioration de la pérennité de l’entreprise, et de sa gestion, à long terme.
4.2.1 La décomposition d’un projet ERP en tâches
Il y deux étapes importantes dans un projet ERP (fig. 4.1) : la sélection de l’ERP et son déploiement.
1
http://www.standishgroup.com/chaos
La sélection de l’ERP est une étape préliminaire au déploiement qui peut se décomposer en quatre macro tâches :
– étude d’opportunités décrivant l’existant, les objectifs du projet, les bénéfices attendus, les enjeux et les facteurs clé de succès, les risques et les contraintes,
– expression du besoin se traduisant par un cahier des charges fonctionnel qui explique le périmètre fonctionnel, fournit la cartographie des flux, les règles de gestion et décrit les processus,
– constitution d’une liste d’éditeurs, qualifiés par rapport à leurs références et au degré d’adéquation avec le besoin, qui sont soumis à des jeux de tests,
– classement de ces éditeurs en fonction de leurs réponses et d’une liste de critères tech- niques et financiers, puis négociation de la solution choisie avec la tête de liste pour préparer le déploiement.
À ce stade de prospection et pour des raisons de charge de travail, il est rarement question de rentrer dans le détail des processus et les jeux de tests ne poussent pas les progiciels dans leur retranchement. Si le cahier des charges fonctionnel explique ce que veut l’entreprise, la réponse de l’éditeur traduit ce que peut faire le progiciel par ses processus standard. La mesure de l’adéquation entre demande et réponse est alors difficile, car la tentation de modifier le besoin initial pour coller au standard est forte. Cette tentation est d’autant plus forte que bon nombre de projets ont un objectif implicite de réorganisation des processus de gestion (Robert Canonne et Jean-Louis Damret, 2002).
Seconde étape importante, le déploiement de l’ERP peut être décrit en cinq macro tâches : le lancement, la conception détaillée de la solution, la réalisation de la solution, l’intégration et le passage en production (Jean-Luc Deixonne, 2001). Jean-Louis Tomas détaille douze tâches qui peuvent être considérées comme une décomposition plus poussée des macro tâches précédentes :
– la planification : plan de communication, besoins d’interfaces, plan des risques majeurs, (lancement),
– l’analyse opérationnelle : définir les processus opérationnels, documenter, former les uti- lisateurs et décideurs du projet, (conception détaillée),
– la formation des équipes projet (lancement),
– la configuration de l’ERP : adéquation entre les processus et les modules implantés, (réalisation),
– le prototypage : vérification d’un fonctionnement correcte, (réalisation), – la simulation en taille réelle, (réalisation),
– la fermeture des TFP (Trous Fonctionnels Potentiels) : développement de spécifique, si nécessaire, pour répondre à des besoins de l’entreprise, nullement ou incomplètement couverts par l’ERP, (réalisation),
– les modifications spécifiques, (réalisation), – la connexion avec l’existant, (intégration), – la documentation utilisateur, (réalisation),
– la préparation de mise en production (passage en production), – le déploiement (passage en production),
L’outil est choisi, c’est donc le temps de la juste adéquation entre le logiciel et l’organisation. 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. 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. Les jeux de tests
48 CHAPITRE 4. GESTION DES PROJETS ERP
Fig. 4.1 – WBS d’un projet ERP
sont multipliés, notamment parce que le souci de validation grandit avec l’approche du jalon de mise en production du progiciel. Si une fonction recherchée n’est pas proposée en standard et que l’organisation veut en disposer, le trou fonctionnel est comblé par un développement spécifique. La réalisation de certaines tâches est conditionnée au résultat de tâches qui les précèdent.
4.2.2 L’organisation des équipes du projet
Nous retrouvons les acteurs suivants :
– les éditeurs qui fournissent des solutions logicielles,
– les intégrateurs qui assurent la mise en adéquation du logiciel au client, – le client final, ou ses conseils.
La maîtrise d’œuvre (MOE formée par l’éditeur et l’intégrateur) est responsable de la construc- tion, du déploiement et de la maintenance du Système d’Information. La maîtrise d’ouvrage (MOA client et conseil) garantit l’alignement entre la stratégie, les processus et les Systèmes d’Information. Elle est constituée d’un niveau stratégique, porteur de la vision métier, et d’un niveau opérationnel, capable d’en assurer la traduction en vision Système d’Information (Alain Berdugo et al., 2002). Les principales activités de ces deux parties peuvent être décrites de la manière suivante :
– pour la Maîtrise d’Œuvre :
– elle apporte et forme la MOA sur les nouvelles technologies ;
– elle traduit les besoins exprimés par la MOA en proposant des solutions logicielles adaptées ;
– elle maintient et exploite les solutions déployées ; – pour la Maîtrise d’OuvrAge :
– elle dirige le projet afin de le mener à bien ;
– elle représente les utilisateurs et détermine des principales fonctions à déployer ; – elle suit la réalisation et l’intégration du Système d’Information pour vérifier que
Dans le contexte de PME/PMI, avec des moyens humains et financiers généralement limités, la relation entre le client MOA et l’éditeur de solution logicielle est souvent très directe. Il est rare, dans ces projets ERP, de faire intervenir un intégrateur entre ces deux parties, principalement à cause du surcoût. Donc c’est généralement à l’éditeur d’assumer pour partie le rôle d’intégrateur, situation où il est à la fois juge et partie.
L’expression du besoin dans la phase de sélection et la conception détaillée dans la phase de déploiement sont des tâches où MOE et MOA sont en contact et doivent établir les attendus de la mission.
Le déroulement du projet peut s’accompagner de difficultés, dès ces phases initiales :
– difficulté dans l’expression du besoin par la maîtrise d’ouvrage (MOA) se soldant par un cahier des charges fonctionnel incomplet voire incohérent,
– difficulté, corrélée à la précédente, dans l’expression d’une offre en adéquation avec le cahier des charges par la maîtrise d’œuvre (MOE) avec le risque de déployer une solution non adaptée.
Ces difficultés initiales peuvent se trouver amplifiées dans le cycle de vie du projet du fait de l’instabilité dans la position adoptée par l’une ou l’autre des parties, et de la durée assez longue des projets. Par exemple, la MOA peut introduire des changements dans l’organisation, dans les missions, dans les processus de gestion, ou même introduire des nouvelles contraintes liées à la modification de son environnement. De son côté, la MOE peut faire évoluer ses versions sur le plan fonctionnel ou sur le plan technique, elle peut aussi changer son interlocuteur. Il est donc nécessaire d’établir un dialogue constructif entre MOA et MOE dès le début du projet, mais le référentiel initial qui concrétisera les résultats constructifs de ce dialogue pourra être adapté au gré des variations introduites par les interlocuteurs tout au long du projet. Pour supporter le dialogue, la mise en place de méthodes adaptées, dans un langage accessible à tous, est primordiale.