L’implantation ERP : 4 choses à savoir avant de débuter

Dernière modification le 15 mai 2024 à 13:51.

Temps estimé pour la lecture de cet article : 17 min

L’implantation ERP est un projet mobilisateur pour toute organisation, de la PME à la grande entreprise.  Bien que l’ampleur d’une telle aventure peut varier sensiblement, en fonction de la taille de l’entreprise, son secteur d’activité et ses localisations géographiques, elle se révèle marquante pour toutes les entreprises qui y passent.

Dans ce billet, j’entends démystifier les projets d’implantation ERP.  Nous discuterons rapidement de la portée de ces projets (inclusions, exclusions, etc.) et des grandes phases.  Ensuite, je vous présenterai certaines activités de gestion que je considère critiques dans ces projets.  Enfin, je ferai un survol des différentes stratégies de déploiement possibles lors d’une implantation ERP.

Portée habituelle d’une implantation ERP

Par définition, un ERP couvre un spectre très large des fonctions de l’entreprise: finances, inventaire, approvisionnement, distribution, ressources humaines, fabrication, etc.

Dans les projets d’implantation ERP, on dote donc l’entreprise d’un système qui permettra de supporter la majorité des processus d’affaires de l’organisation.

Inclusions

On inclus habituellement les éléments suivants dans la portée de toute implantation ERP :

• La mise en place de l’infrastructure requise pour supporter l’ERP, que celui-ci soit hébergé dans l’entreprise ou dans un centre de données externe ou en mode infonuagique.
• L’installation et la configuration de l’ERP, incluant la configuration de documents standards comme les factures, bons de commandes, etc.
• La gestion de changement: documentation des processus futurs et des procédures.
• La mise en place d’interfaces entre l’ERP et des systèmes connexes (par exemple, un CRM ou un système manufacturier)
• La formation des utilisateurs ou d’une partie de ceux-ci, dans une approche « Train the trainer« .
• La mise en route ou mise en production de l’ERP.
• Soutien post-implantation: C’est une pratique répandue de fournir un certain soutien post-implantation – que celui-ci soit sur site ou hors site – pour un certain temps après la mise en production.  On considère ces coûts comme faisant partie du projet même.
• Les lignes d’affaires investissement du temps dans le projet.  Comme ils sont plus que matériels, on impute aux projets les coûts de leurs efforts.
• Évidemment, on impute aussi les coûts de la main-d’oeuvre T.I. (interne ou externe).
  
  

Exclusions

Typiquement, on va également considérer les éléments suivants comme exclus:

• La sélection du logiciel ERP : Elle précède en effet l’implantation.
• Sauf exception, on considère toute personnalisation de l’ERP hors portée (out of scope).
• Le développement de rapports de gestion l’est également.  Les ERP viennent avec des rapports prédéfinis qui répondent à la majorité des besoins.  Par défaut, on considère le développement des rapports hors portée, à moins que certains rapports soient critiques pour les opérations de l’organisation.
• Une entreprise va également exclure de portée du projet toute unité organisationnelle ou ligne de produits sur le point d’être vendue ou démantelée.

Maintenant qu’on a fait un survol de ce qui est normalement inclus dans ces projets, quelle est l’approche utilisée pour implanter un ERP ? Quelles sont les grandes phases d’implantation ?

Grandes phases

Il existe autant de méthodologies de gestion de projet d’ERP qu’il y a de progiciels commerciaux dans ce secteur.  Je vous présente ici néanmoins les grandes phases de ces projets, le tout étant basé sur mon expérience dans de nombreux projets d’implantation ERP.

Initiation

La phase d’initiation ou planification de l’implantation ERP est celle qui consiste à mettre en place la structure permettant la réalisation du projet.

On définira et documentera avec beaucoup de détails la portée de l’implantation: inclusions, exclusions, etc.  Ceci couvrira l’ensemble des aspects: lignes d’affaires, processus d’affaires, unités organisationnelles, localisations géographiques, etc.

On déterminera également l’équipe de projet, de même que les représentants affaires impliqués.  On va définir le nombre de comités (comité directeur, comité de demandes de changement, etc.) et leurs compositions respectives.

Enfin, on définit et documente également l’approche du projet dans le plan de projet.  Celle-ci inclura notamment un plan de travail détaillé, incluant le séquencement des tâches.

Blueprint

Durant cette phase, on fait une revue détaillée des besoins d’affaires actuels et une ébauche de la solution future.

Durant cette phase, on raffine également le plan de travail pour la phase de construction.  Il arrive en effet que des hypothèses soient utilisés lors de la phase d’initiation.  Durant le blueprint, les choses se précisent et on définit le travail à accomplir, de même que l’approche pour y arriver.

Le blueprint nécessite la tenue de multiples ateliers de travail entre les consultants fonctionnels de l’ERP et les représentants des unités d’affaires.

Le blueprint résulte  normalement sur une documentation plutôt étoffée définissant l’ensemble des besoins couverts et l’ébauche des solutions identifiées durant les ateliers de travail.  À la fin de celui-ci, on nage un peu moins dans le flou et on a le sentiment qu’on est plutôt aligné vers la solution finale.

Construction

La phase de construction consiste à entreprendre la configuration de l’ERP en fonction des décisions prises durant la phase précédente (blueprint).  On organise des ateliers supplémentaires afin d’obtenir un degré de précision supérieur à celui du blueprint.

La phase de construction implique évidemment plusieurs expertises différentes et il y a quand même certaines dépendances entre les spécialités.  Habituellement, on va débuter par le coeur du système, les modules financiers.  Puis, on mettra en branle la construction des autres modules progressivement, en fonction des dépendances.

C’est également lors de cette phase qu’on procèdera aux activités de configuration et développement de la couche ESB (ou Enterprise System Bus).  Celle-ci est la couche permettant l’intégration entre le système d’entreprise (ERP) et les systèmes connexes.

La phase de construction est habituellement la plus longue dans ce type de projet.  Elle débute en principe après le blueprint mais il arrive qu’on réaliser parfois un fast track pour compresser le calendrier du projet.

Tests, assurance-qualité et ajustements pour notre implantation ERP

La phase de tests, assurance-qualité et ajustements consiste évidemment à tester la solution construite jusqu’à sa pleine acceptation/approbation par les unités d’affaires impliqués.

Il existe différents types de tests, on peut résumer les plus répandus aux tests unitaires, tests intégrés et tests d’acceptation.

Tests unitaires

Les tests unitaires consistent à mettre sous essai les fonctions configurées et/ou personnalisées, mais de façon unitaire.  On réalise donc un test mais à un niveau plutôt atomique.

Par exemple, on pourrait tester que la configuration d’un terme de paiement de 30 jours est bien prise en charge par le module de compte à payer.

Les consultants spécialisés assignés au projet d’implantation ERP réalisent normalement les tests unitaires.

Tests intégrés ou tests de systèmes

L’objectif des tests intégrés est de vérifier les éléments construits au niveau de l’interaction entre ceux-ci.  On testera donc différentes fonctions ensemble, lesquelles auront été normalement testées préalablement de façon unitaire, plus tôt dans le projet d’implantation ERP.

C’est notamment lors de cette phase qu’on testera la couche ESB, qui est celle permettant de connecter les systèmes connexes à l’ERP de l’entreprise.

Tout comme pour les tests unitaires, les membres de l’équipe de projet réalisent normalement ces types d’essais.

Tests d’acceptation

Les tests d’acceptation consistent à s’assurer que le système configuré répond aux besoins d’affaires en testant différents scénarios se produisant dans des situations réelles.  En préparation à cette phase, les lignes d’affaires travaillent de concert avec l’équipe de projet pour préparer de nombreux scénarios de tests.

Durant la phase de tests d’acceptation, on identifiera des problèmes ou parfois même des demandes de changement.  Tout un travail de priorisation sera effectué pour savoir ce qui est requis pour la mise en production (bloquant) et ce qui est prioritaire par la suite ou encore ce qui est accessoire (le fameux nice to have ou bells and whistles).

Les représentants des lignes d’affaires impliquées dans le projet sont responsables des tests d’acceptation.  Ce sont eux qui signifient, en bout de ligne, leur approbation finale pour procéder au déploiement.

Déploiement

Le déploiement est l’aboutissement de tous les efforts précédents, il consiste à mettre en route le système d’entreprise (ERP). Cette activité est prise en charge par votre consultant en implantation ERP.

La préparation du déploiement est une activité également critique.  La résultante est un document qu’on nomme « Cut-over plan » ou Plan de mise en production.  Il contient l’ensemble des tâches détaillées requises pour la mise en production.  On y retrouve notamment les dépendances au niveau des tâches, l’heure et la date planifiée, de même que la durée estimée de chacune des tâches.

Le Cut-over leader joue le rôle de chef d’orchestre durant la mise en production et s’assure que l’ensemble des tâches sont exécutées selon le plan.  Le chef de projet assume souvent ce rôle mais tout dépendant de l’envergure, il peut être assigné à une autre personne.

La formation des utilisateurs fait également partie de la phase de déploiement, bien que certaines activités puissent commencer plus tôt (par exemple, avant les tests d’acceptation pour les utilisateurs impliqués durant ceux-ci).

Pour des informations supplémentaires concernant les phases des projets ERP, n’hésitez pas à consulter ce billet concernant la méthodologie ASAP, sur le site de Simplilearn.

Un aperçu des activités critiques lors d’une implantation ERP

Peu importe la taille de l’organisation et le secteur commercial/industriel concerné, un certain nombre d’activités de gestion de projet sont critiques lors de ce type de projet.  Je vous en présente rapidement quatre.

Gestion des risques

On définit le risque dans un projet T.I. comme le fait qu’un événement plus ou moins prévisible se produise.  Le risque affecte le respect des objectifs fixés, tant au niveau du coût, du temps et/ou la qualité.

L’activité de gestion des risques est continue dans un projet.  Normalement, on intègre à même le plan de projets une section concernant la gestion des risques.  Il n’est pas rare qu’on juge opportun de même préparer un plan de gestion des risques, afin de donner toute son importance à cette activité.

En cours de projet, on intègre normalement un volet de gestion des risques dans le rapport d’avancement hebdomadaire préparé par le chef de projet.

On documentera au minimum les éléments suivants pour chaque risque:

• Description du risque: Quel est le risque ? A quoi est-il relié ?
• Conséquences: Quelles sont les conséquences du risque sur la conduite du projet ?
• Mitigation: Comment peut-on gérér ou minimiser les conséquences du risque ?

La gestion du risque est une activité critique et bien que ce sont souvent les mêmes risques qui reviennent (par exemple, la disponibilité des ressources), en minimiser l’importance peut nous jouer des tours importants.

Gestion des enjeux (issue)

La gestion des issue ou gestion des enjeux consiste à s’occuper des besoins d’affaires ou techniques qui ne sont pas couverts par la solution qui a été définie jusqu’à ce jour dans le projet.  Elle peut résulter, au final, à des changements à la configuration de l’ERP, une personnalisation de l’ERP, une révision du processus d’affaires ou encore, elle peut ne pas être résolue dans la phase courante du projet.

La gestion des enjeux consiste donc à rendre visibles ces écarts et à en assurer la prise en charge par la personne appropriée jusqu’à sa résolution complète.

Il n’est pas rare de voir la liste des enjeux s’allonger rapidement dans certains projets.  Le chef de projet donnera une priorité à leurs résolutions à travers des rencontres régulières (par exemple, à tous les jours) où les enjeux seront discutés, évalués puis pris en charge.

Contrôle de la portée et la gestion des changements

La portée ou scope délimite le périmètre de ce qui est inclus dans le projet d’implantation ERP : inclusions, exclusions, etc.  Habituellement, on décrit la portée sous plusieurs aspects: l’aspect fonctionnel (les fonctions de l’entreprise couvertes par l’implantation), l’aspect organisationnel (les emplacements de l’entreprise inclut), etc.

On définit la portée au tout début du projet d’implantation ERP, dans le plan de projet.  Les différentes parties prenantes impliquées approuvent son contenu.

Le chef de projet est garant de la portée du projet d’implantation ERP.  Le gestionnaire de projet, avec le support de l’équipe de projet, identifie tout écart à cette portée et le soumet celui-ci au processus de gestion des demandes de changement.

On documentera formellement chaque demande de changement et on la soumettra pour approbation par le comité directeur du projet ou un comité spécialement formé à cette fin.  Habituellement, on forme ce comité de représentants des unités d’affaires mais également de personnel T.I.  Le comité directeur va autoriser ou non chaque demande de changement et approuver un budget supplémentaire le cas échéant.

Gestion des personnalisations de l’ERP

On qualifie de personnalisations (customization) les modifications apportées à l’ERP autrement que par la configuration de paramètres ou de rapports.  Elles nécessitent habituellement une activité de programmation réalisée par un consultant technique spécialisé dans le langage – souvent propriétaire – de l’ERP.

Les consultants fonctionnels dans le projet d’implantation ERP vont identifier que des personnalisations sont requises.

Il est important de gérer rigoureusement les demandes de personnalisation et leur réalisation.  Vous pouvez d’ailleurs consulter ce billet que j’ai écrit au sujet de l’implantation vanille des ERP (c’est-à-dire sans personnalisation).

Stratégies de déploiement

Il existe de multiples stratégies de déploiement lors de d’une implantation ERP.  Nous allons ici en couvrir quatre, les plus répandues.

Le « Big Bang »: On y va le tout pour le tout!

L’approche du Big Bang à faire un déploiement de l’ensemble des fonctions ciblées, sur l’ensemble des unités d’affaires et à tous les emplacements géographiques.

C’est l’approche qui comporte le niveau de risque le plus élevé pour l’organisation.  En effet, le changement de système affectant l’ensemble des lignes d’affaires, emplacements géographiques et fonctions de l’entreprise peut introduire des secousses sismiques importantes!

L’avantage de cette approche d’implantation ERP est qu’elle est moins coûteuse d’un point de vue projet car on concentre toutes les activités sur une certaine période de temps et on a une économie de coûts au niveau des coûts fixes du projet.

Le principal désavantage de cette approche est qu’elle peut créer des projets qui ne se terminent jamais, qui s’étirent en durée, tant le déploiement peut parfois être complexe.

Le déploiement organisationnel progressif (ou pilote)

Le déploiement organisationnel progressif consiste à déployer l’ensemble des modules, mais sur une partie de l’entreprise.  Par exemple, on pourrait déployer l’ensemble des fonctions finance pour toute l’organisation, mais limiter les fonctions de ventes et distribution à une usine.

Le principal avantage de cette approche d’implantation ERP est qu’on limite les risques opérationnels à une partie de l’organisation.

D’autre part, on pourra tirer de nombreuses leçons de cette expérience et apporter des correctifs avant le prochain déploiement.  On pourrait déterminer que le nombre d’agents de changement sur site suivant la mise en production est insuffisant.

Le déploiement fonctionnel progressif

Dans cette approche, on planifie le projet en vagues successives.  On déploiera les modules fonctionnels par groupes fonctionnels logiques.

Par exemple, on pourrait débuter par les fonctions finance, puis poursuivre par l’inventaire, la distribution et l’approvisionnement.  Enfin, on pourrait compléter par deux autres vagues: les fonctions manufacturières et ensuite les fonctions RH.

Ce type de déploiement limite les risques organisationnels pour l’entreprise lors de l’implantation ERP.  En effet, on concentre les perturbations organisationnelles sur certaines parties de l’entreprise.

L’utilisation de deux ERP en parallèle

Certaines organisations vont même aller jusqu’à utiliser deux ERP en parallèle pour une durée limitée (par exemple, un mois).  On doit réaliser une double saisie des informations car on utilise les deux ERP en même temps.

On choisit cette approche habituellement car il y a un risque élevé à l’utilisation du nouveau système.  Cela peut se produire notamment avec les ERP largement développés sur mesure et peu testés par l’organisation.  On la choisit également quand le niveau de confiance est faible.

Il arrive aussi fréquemment que les contraintes d’interfaces de systèmes ne peuvent permettre l’utilisation de deux systèmes en parallèle.  Par exemple, on pourrait dire que le logiciel CRM ne peut être connecté à deux systèmes en même temps.

Aujourd’hui, on utilise rarement cette approche.  La plupart des organisations vont en effet préférer utiliser le pilote à la place pour atténuer les risques.

Conclusion: L’implantation ERP, une aventure de haut niveau!

Dans ce billet, j’ai vulgarisé un certain nombre de concepts relatifs aux projets d’implantation ERP.  Après un tour d’horizon de la portée de ces mandats, je vous ai présenté les phases habituelles de ces projets.

Je vous ai présenté certaines activités de gestion critiques de ces projets.  Cependant, on doit aussi réaliser d’autres activités pour assurer le succès quant au fameux triangle de performance (qualité, coût et délai).

Enfin, peu importe la stratégie de déploiement retenue, les mises en production sont l’aboutissement d’une aventure de haut niveau!

Vous préparez un projet ERP et aimeriez en savoir plus ? Téléchargez notre eBook « Comment réussir votre projet ERP 🎯 ». Il vous sera d’une aide importante pour assurer la réussite de votre projet.

Références

Ce billet s’inscrit dans la série vouée à la gestion de projet TI pour les nuls.  L’implantation ERP étant un projet de type applicatif, je vous invite donc à consulter le billet sur les projets applicatifs.

Un des billets pour lequel j’ai eu beaucoup d’amusement lors de sa rédaction est celui sur le mythe de la documentation lors d’implantations ERP.

J’ai utilisé plusieurs références lors de la préparation de ce billet.  Voici les plus importantes:

• Basic Understanding on ASAP Methodology for beginners, sur le blogue de SAP.
• Gestion de projet informatique: comment prendre en compte le risque ?, sur le site de Ivision.
• Enterprise System Bus sur Wikipédia.
• Comment choisir la bonne stratégie de mise en oeuvre pour votre ERP, par ThinkMax Consulting.
• Les 4 stratégies possibles de déploiement d’un logiciel ERP, par Akuito.