Bien gérer son changement d’ERP

Effectuer un changement d’ERP est sans doute le projet d’une décennie en entreprise. C’est un projet impactant pour l’organisation, pour les salariés. Et ceci quel que soit la taille de l’entreprise. Il ne faut pas penser que plus l’entreprise est petite, plus ce changement sera facile. La taille de l’entreprise joue surtout sur le temps de ce changement.

 Une grosse entreprise aura l’ensemble de type de ressource interne pour mener le projet, des chefs de projet, un service informatique et du personnel métier dédié. Elle aura la connaissance parfaite technique de l’ERP actuel ou la pression nécessaire auprès de l’éditeur pour avoir les informations nécessaires.

Une plus petite n’aura pas forcément tout ça. Pas de service informatique, des difficultés à avoir un chef de projet interne, pas forcément de maîtrise de l’ERP actuel, un temps à donner par les salariés métier plus difficile à trouver. Du coup, elle devra d’autant plus s’impliquer pour trouver les bons partenaires.

Il ne faut pas non plus tomber dans le piège qu’il s’agit d’un projet purement informatique. Au contraire, même si en effet la part informatique est importante, l’impact va bien au-delà et va impacter l’ensemble des métiers et de l’organisation de l’entreprise.

1 Préparation

1.1 Pourquoi change-t-on d’ERP ?

L’ERP est le maillon central de l’organisation de vos flux d’entreprise. Il doit donc être adapté à votre fonctionnement. Une entreprise évolue ainsi que les éditeurs d’ERP, c’est pourquoi il peut devenir essentiel de devoir changer d’outils. Voici les raisons principales qui peuvent vous amener à changer.

• Votre logiciel n’est plus maintenu par l’éditeur. C’est une des raisons principales de changement d’ERP.En effet si vous avez un ERP datant de plus de 10 ans, les systèmes d’exploitation, les langages de programmation, les bases de données ont bien évolué. Ceci pousse l’éditeur à proposé une version plus moderne et qui rend votre ERP obsolète.
• La progression de votre entreprise. Votre entreprise a commencé avec 5 personnes et un CA de 100k€, à l’époque vous avez choisi un ERP dimensionné pour cela. Aujourd’hui vous êtes 50 pour un CA de 5M€ et vous vous sentez à l’étroit dans votre ERP, celui-ci ne supporte plus la quantité de données.
• La diversification des flux. Vous avez commencéavec des flux de vente et achat simple et comme le point ci-dessus vous avez choisi un ERP dimensionné pour cela. Maintenant vous décidez d’ajouter de la logistique, du transport et une complexité de tarif plus importante. Votre ERP ne répond plus à ces nouveaux flux.

1.2 Définir ses flux actuels

Avant de se lancer dans la recherche du nouvel ERP, la première chose à faire afin de gagner du temps sur la suite, est de bien définir ses flux actuels. De les écrire via des diagrammes de la manière la plus précise possible avec le rôle de chacun et même les écrans utilisés.

Cela permet plusieurs choses.

D’abord de prendre un vrai recule sur ses pratiques. En effet lorsqu’on est plongé dans le quotidien, on ne se rend plus compte que nos pratiques ne sont peut-être pas optimales.

Ensuite cela permet de se rendre compte d’améliorations ou de changements possibles.

Enfin, cela va permettre d’avoir un support pour la constitution d’un cahier des charges pour la recherche du nouvel ERP.

1.3 Choisir son nouvel ERP

Lorsque vous avez bien identifié les flux de l’entreprise il faut alors définir un cahier des charges. Celui-ci doit contenir l’ensemble des besoins basés sur les flux.

Ce cahier des charges doit définir un besoin fonctionnel et non technique. C’est-à-dire qu’il doit définir ce que l’on veut et non comment on le veut. En effet, vous allez avoir devant vous, par la suite, des ERP proposant une solution de faire d’une manière ou une autre. Le but étant de trouver la manière qui vous va le mieux et non d’imposer votre manière de faire (si vous voulez éviter des coûts exponentiels de développement).

Le moment est venu de définir une liste d’ERP potentiel. Le choix est très vaste. Des outils sur internet vous permette de définir une liste en fonction du nombre de salarié, du chiffre d’affaires, de votre domaine… La liste étant faite, vous devez rentrer en contact avec chaque éditeur ou intégrateur des ERP choisis afin de soumettre votre cahier des charges en demandant la part standard, la part de développement et du coup le coût global.

1.4 Définir une date prévisionnelle de démarrage

Définir une date est essentielle. Même si au départ tout est flou. Ce démarrage peut être caller à la fin d’un exercice comptable ou sur une date d’inventaire. Cela permet de caler un planning de projet.

Même si tout le monde est conscient qu’il y a un risque de dépassement, il faut toujours être ambitieux pour mettre une pression (mesurée) sur les prestataires et sur ces équipes internes.

1.5 Définir son équipe

En parallèle du choix de l’ERP, il va falloir définir l’ordre de marche interne du projet. En effet un projet de cette envergure nécessite un temps d’implication non négligeable de plusieurs salariés. Il va falloir définir les rôles suivants :

• Le directeur projet ou sponsor : C’est lui qui doit arbitrer les décisions contractuelles, financières et stratégiques sur conseil du chef de projet.
• Un chef de projet : C’est celui qui va devoir définir et respecter le planning du projet et savoir impliquer les bonnes personnes au bon moment.
• Les key user : C’est un rôle principal et le plus critique d’un point de vue management. Ces personnes sont les référents métiers, ce sont les personnes à qui on va demander d’effectuer leur travail journalier et en plus de s’impliquer dans la définition et le test du nouvel ERP. Dans les plus grandes entreprises, on va pouvoir embaucher du personnel pour pallier cela, mais dans de plus petites structures il s’agira de trouver les meilleures actions managériales pour bien impliquer ces personnes.
• Un chef de projet ou responsable technique : Cette personne aura la responsabilité de tout le côté technique de reprise de données, d’interfaçage, de BI …
• Les utilisateurs : C’est l’ensemble des salariés qui devront utiliser l’ERP. Pour eux il faudra essentiellement bien les informer sur l’avancé du projet par la conduite du changement et bien les former pour le démarrage en production

Il ne faut surtout pas négliger le temps que chaque personne devra passer sur le projet, sous peine de dévier des objectifs de date de démarrages ou de perte la motivation des salariés.

1.6 Le budget

A ce niveau il est encore difficile de définir le budget. Ce qu’il faut savoir, c’est surtout que le coût ne représentera pas uniquement l’achat ou l’abonnement au logiciel. Le coût va également représenter l’ensemble du travail des salariés impliqués dans le projet. Le coût va également représenter l’ensemble des actions techniques de reprises de données, interfaçage, BI qui sont loin d’être négligeables.

2 Mise en œuvre

2.1 Analyse d’adéquation

Voilà, l’ERP a été choisi, on rentre maintenant dans le vif du sujet. La première étape primordiale va être de s’assurer avec l’intégrateur qu’en effet, l’ERP répond bien à l’ensemble des flux ou alors que des développements complémentaires sont nécessaires pour s’adapter à différents points.

Pour cela des réunions doivent être organisées avec les key user et l’intégrateur jusqu’à ce que tout soit clair pour chaque parti.

La finalité sera un document d’adéquation de l’intégrateur et un devis des développements complémentaires au besoin.

A noter ici qu’il est très difficile, lors d’une analyse d’adéquation, de s’adapter à la nouvelle solution et de ne pas demander de s’approcher de ce que l’on connait. C’est le rôle du chef de projet d’avoir ce recul. Les key user métiers vont vouloir se rapprocher de ce qu’il font tous les jours. Il faut bien avoir en tête que chaque demande spécifique aura un coût.

Cette analyse d’adéquation doit également permettre de donner tous les éléments pour la partie technique, à savoir comment importer les données dans l’ERP, comment gérer les éventuelles interfaces avec d’autres application …

2.2 Budget, planning et évaluation des risques

A partir de ce moment, le chef de projet a tous les éléments en main pour définir précisément un budget et un planning projet.

Ce planning doit bien prendre en compte le temps laissé à disposition pour chaque personne ayant un rôle dans le projet. Il ne faut surtout pas penser que les key user sont disponibles à 100% et quand on le souhaite. Ce temps mis à disposition doit être défini avec le directeur projet, le chef de projet et le key user.

Maintenant vous pouvez également évaluer les risques du projet et définir les actions s’ils se produisent. Les risques peuvent être de l’ordre du budget, de la disponibilité des personnes impliqués, d’une hausse d’acticité … Bref, même si on ne peut pas tout anticiper (épidémie, catastrophe naturelle …) plus on pense à tout, plus on peut réagir rapidement.

2.3 Conduite du changement

Le changement d’un logiciel en entreprise apporte forcément un changement de méthode de travail auprès des salariés et l’obligation d’apprendre un nouveau logiciel. Cela peut être mal vu par les salariés. C’est pourquoi il faut apporter une méthode de conduite vers ce changement.

 Il n’y a pas de méthode prédéfinie puisque cela passe par l’identité, l’ambiance, la politique de l’entreprise. Evidement si l’entreprise possède un service RH, c’est lui qui sera le plus à même de définir la stratégie.

On peut citer quelques possibilités.

• Une enquête d’opinion pour connaître le ressenti des salariés sur le projet
• La mise en place d’une newsletter, permettant d’informer les salariés sur l’avancement du projet.
• L’implication des salariés sur des choix précis sur l’ERP.

Sur le dernier point, attention, il ne faut pas demander aux futurs utilisateurs ce qu’ils veulent dan l’ERP, puisque à partir du moment ou ils auront indiqués une volonté, ils ne comprendront pas que ça n’y soit pas au final. Il faut les impliquer dans des choix précis. Par exemple si vous apportez un système de gestion d’entrepôt avec du matériel, vous pouvez demander aux concernés, en leur proposant du matériel, de choisir celui qui leur conviendrais le mieux, en disant bien que la majorité l’emportera.

2.4 Reprise de données

Nous abordons maintenant la partie technique. Et elle est primordiale pour le projet. Il va s’agir dans un premier temps de valider que les données de l’ERP actuel sont bien accessibles et transférables vers l’ERP futur.

La complexité de ce travail va surtout résider sur l’accessibilité aux données de l’ERP actuel si vous n’en avez pas la maîtrise. En effet, vous quittez un éditeur et il ne sera pas forcément disposer à vous aider pour récupérer vos données. Il faut donc bien vérifier que vous pouvez reprendre vos données, soit par un accès direct à la base de données, soit par un outil de requête du logiciel, soit par des exports excel ou csv du logiciel.

Ce n’est pas tout. Vous avez maintenant récupéré des données venant d’un logiciel et il va falloir les importer vers un autre. Les logiques des ERP ne sont pas les mêmes, les codes utilisés non plus, bref il va falloir faire un travail de correspondance assez chronophage pour transformer l’ensemble de vos données vers le format attendu du nouvel ERP. D’autant que ce travail devra être au maximum automatisé puisqu’il devra être fait plusieurs fois pour s’assurer du bon fonctionnement et du temps nécessaire. La dernière fois se faisant juste avant le démarrage pour avoir l’ensemble des dernières données.

2.5 Interfaçage

L’interfaçage consiste au partage des données entre divers logiciel. Si ce besoin a été identifié, on se retrouve dans les problématiques du paragraphe précédent, à savoir récupérer les données souhaitées, les transformer et les transmettre au logiciel qui doit les réceptionner.

Comme pour la reprise des données, ces temps sont importants et donc vont apporter un coût non négligeable au projet, il est important de bien prendre cela en considération, d’autant si vous n’avez pas de service informatique et que vous devez faire appel à un prestataire.

2.6 Formation des key user

Le logiciel est prêt et les données ont pu être reprises, il faut maintenant former les key user pour les préparer à leur tâche à venir. Cette formation est normalement faite par l’intégrateur.

2.7 Tests et recette

Nous arrivons à une phase critique et qui est peut-être la plus difficile à estimer en termes de temps. Les key user et le chef de projet vont avoir la tâche de tester l’ensemble des flux attendus.

C’est le moment ou les key user vont devoir donner un temps non négligeable.

Pour aborder le mieux cette phase, il faudra que le chef de projet ai rédigé un cahier de test pour guider les key user.

Il est conseiller de mettre en place une salle dédiée pour ces tests en présence du chef de projet afin que les personnes ne soient pas dérangés et partagés entre leurs tâches quotidiennes et leur tâche de test … puisqu’on sait laquelle passera devant.

L’ensemble des anomalies détectées doivent être documentées avec description, copie d’écran et enregistrée dans l’outil qui aura été défini entre l’intégrateur et vous. Plus l’anomalie sera bien expliquée, plus elle pourra être rapidement corrigée.

Cette phase peut être laborieuse avec plusieurs allers-retours. Vous testez et trouvez des erreurs, les erreurs sont corrigées, vous devez revenir tester … C’est le moment où il ne faut pas perdre les key user.

3 Démarrage

3.1 Formation des utilisateurs finaux

Les tests ont été validés, il est maintenant venu le temps former les utilisateurs finaux. Cette formation doit se faire peut de temps avant le démarrage, entre 1 mois et 15 jours. Plus d’1 mois et ils oublieront, moins de 15 jours et vous n’aurez pas le temps de vous retourner en cas d’anomalie à nouveau trouvée lors des formations.

Il est conseillé de former les utilisateurs finaux par les key user. Ils connaissent leur équipe, leur métier et sauront le plus à même de gérer cette tâche que ça soit pour le métier mais aussi pour la conduite du changement.

3.2 Démarrage à blanc

Cette étape n’est pas nécessaire mais fortement conseillé. Il s’agit d’impliquer un nombre de personne conséquente, voire toute l’entreprise pour faire un test de démarrage. Le but étant de reproduire précisément les actions qui seront faites lors du vrai démarrage et détecter les dernières anomalies.

Cette étape est délicate à organiser puisqu’il s’agit, en gros, d’arrêter le fonctionnement de l’entreprise le temps de ce démarrage à blanc.

Suivant les impacts et le temps prévu pour le démarrage réel ce démarrage à blanc ne peut consister qu’en la partie technique. S’assurer que les données sont bien reprises, que l’interfaçage fonctionne et que les flux principaux sont ok. Ceci nécessite moins de personnes impliquées.

Cela doit également permettre de définir le temps nécessaire à l’intégration des données. Suivant la taille des données et les logicielles, cette action peut nécessiter 1 jour voir plus.

3.3 Démarrage

Enfin nous y somme, les tests sont ok, la reprise est ok, l’interfaçage est ok, les utilisateurs sont formés. Le go live a é té donné.

Le démarrage va commencer par s’assurer que l’ensemble des données ont bien été intégrées.

Ensuite les flux vont commencer… Et des anomalie ou oublie vont nécessairement apparaitre. Les key user ont la tâche d’expliquer aux utilisateurs si ça n’est qu’un oubli ou, s’il s’agit d’une anomalie, de la remonter comme lors de la phase de test vers le key user.

Le démarrage est souvent stressant pour tout le monde. Il est bon que le directeur passe un message positif avant afin de motiver tout le monde.

Bon courage