« As is », « fit-gap »… le jargon de l’ERP enfin décrypté

As is / To be

On l’entend dans : « Pouvez-vous nous présenter l’As Is afin que nous définissions votre To Be ? »

Concrètement, cela veut dire : « Connaissez-vous le fonctionnement de départ de votre entreprise et savez-vous précisément comment vous souhaiteriez que nous vous aidions à fonctionner demain ? »

La bonne pratique : Chaque ERP possède son périmètre de couverture fonctionnelle, son interface et sa dimension généraliste ou sectorielle. Afin de trouver chaussure à son pied et d’optimiser cette phase de recherche, une entreprise en quête d’ERP doit donc bien connaître son point de départ et les objectifs qu’elle souhaitera achever avec ce nouvel outil. Un travail en amont est donc nécessaire afin de ne pas sélectionner la solution la plus séduisante mais bien la plus adéquate. Cette analyse permettra également de mesurer le changement impliqué en termes humain, culturel et organisationnel.

Must have / Should have / Could have / Won't have

On l’entend dans : « Commençons par traiter ce sujet n°1, must have ; ce dont vous me parlez là, c’est clairement du nice to have. »

Concrètement, cela veut dire : « Concentrons-nous d’abord sur le sujet n°1 que vous avez défini comme prioritaire, le deuxième sujet mentionné n’est ni bloquant ni important. »

La bonne pratique : Cette catégorisation des besoins répond à deux problématiques fondamentales : l’aide à la décision durant la sélection de l’ERP et l’aide à l’atteinte des objectifs fixés tout au long de son implémentation. Afin de garder le cap et de ne pas se laisser distraire en chemin par les multiples fonctionnalités de l’ERP, l’entreprise doit s’efforcer de rigoureusement prioriser les fonctionnalités qu’elle souhaite. Pour cela, elle partira toujours de son objectif (le fameux to be) pour définir ce que la solution doit contenir (must have), devrait contenir (should have), pourrait contenir (could have ou nice to have), et ce qui ne fait pas clairement partie du périmètre (won’t have).

Fit-gap

On l’entend dans : « Je suis content, les ateliers de fit-gap ont été rassurants. »

Concrètement, cela veut dire : « Les ateliers durant lesquels nous devions étudier l’écart entre notre processus cible et ce que la solution nous permettra de faire ont été constructifs. »

La bonne pratique : Si l’ERP a de multiples fonctionnalités, il a néanmoins le défaut d’être rigide. Mettre en place un ERP, c’est orchestrer la rencontre entre les processus souhaités d’une entreprise et le fonctionnement d’un logiciel : l’entreprise peut choisir d’épouser entièrement la façon de faire du logiciel (simple techniquement, difficile humainement), de tordre la logique du logiciel de multiples façons afin qu’il s’adapte à son processus (difficile techniquement, plus simple humainement), ou de faire des compromis entre l’humain et le technique (moyennement difficile pour les deux). Cette rencontre, c’est l’objectif des ateliers de fit-gap, qui ont lieu pendant la phase de conception. C’est pendant ces ateliers que l’entreprise et son intégrateur vont s’accorder sur le niveau de personnalisation de la solution, c’est-à-dire des écarts à combler entre le logiciel de base et le logiciel qui sera livré à la fin… et sur le type d’accompagnement au changement adapté.

Pilote vs. big bang

On l’entend dans : « Est-ce qu’on planifie un démarrage avec un pilote ou directement en big bang ? »

Concrètement, cela veut dire : « Lançons-nous l’ERP pour un petit groupe, par exemple un site ou un service, ou pour tous les utilisateurs d’un coup ? »

La bonne pratique : Ce choix est très dépendant des contraintes actuelles et des risques en cas de perturbation du fonctionnement des services ou des sites concernés. Il n’y a pas de recette miracle, il faut étudier les impacts budgétaires des deux possibilités :

• L’utilisation des sites pilotes peut-être un peu plus coûteuse en apparence mais permet une meilleure appropriation de la solution, l’utilisation du vécu du site pilote permet de mieux planifier les déploiements sur les autres entités.
•  Le big bang, quant à lui, peut répondre à des problématiques de fin de maintenance de la solution en place ou d’un besoin urgent de se structurer avec une nouvelle solution.

L’accompagnement des équipes devra être calibré en fonction de la modalité retenue.

Go live

L’utilisation qu’en fait le consultant : « Le go live est dans 3 semaines, il va falloir répondre présent. »

Concrètement, cela veut dire : « Dans 3 semaines nous mettrons la solution en production, il faudra être prêt à la fois pour répondre aux questions, pour aider les utilisateurs à prendre en main la solution et pour corriger rapidement les éventuelles anomalies qui surviendraient »

La bonne pratique : Le grand jour est arrivé, c’est l’achèvement de semaines ou de mois de travail pour l’ensemble des acteurs du projet. S’il doit bien se préparer en amont par la formation de tous les utilisateurs, une reprise des données et un plan de bascule précis, il faut surtout communiquer positivement autour de cet évènement. Cela doit être vécu comme un challenge pour les équipes impliquées et comme un évènement apportant une nouvelle dynamique à l’ensemble des personnes de l’entreprise.

Il y a d'autres types de mots que l'on aimerait entendre plus souvent

Ils ne font partie du jargon de l’ERP, pourtant, on aimerait les entendre plus souvent, d’autant plus que ce sont eux qui occupent les discussions des collaborateurs et utilisateurs finaux.

L’émotion ?

Elle est omniprésente dans un projet ERP : les utilisateurs finaux peuvent craindre de changer d’outils, de ne pas savoir combien de temps prendra la montée en compétences nécessaire, de voir certaines tâches qu’ils aimaient réaliser disparaître, de perdre la responsabilité de leur périmètre…. D’autres enfin, peuvent se réjouir. L’émotion, cœur de la décision, est un sujet central à aborder pour engager les collaborateurs dans l’utilisation du nouvel outil.

Le changement ?

L’ERP peut questionner voire bouleverser des aspects profondément culturels, métier, organisationnels. C’est néanmoins souvent le dernier point évoqué : on s’occupe des urgences techniques d’abord – il y a le feu – et s’inquiète seulement ensuite du changement. Or le changement et son accompagnement devraient occuper les différents acteurs de l’ERP dès le début de la transformation. En effet, comme pour tout projet, un ERP est comme il naît : dans l’urgence et la douleur ou accompagné et en douceur.

La reconnaissance ?

A l’issue du projet, prendre le temps de remercier les équipes est essentiel. Travailler à la conception et à la mise en place d’un ERP est un travail de longue haleine. Le parcours est long et semé d’embûches et certains utilisateurs finaux peuvent avoir été perturbés par le changement de leurs habitudes. Alors en tant que sponsors, directeurs, mais aussi en tant qu’utilisateurs finaux, il faudra penser à remercier l’équipe pour le travail fourni. Car après quelques mois tous réaliseront que cette solution et ce changement, finalement, n’étaient pas si mal... voire très bien !

Consulter le replay du webinaire « Faire adopter un projet ERP » (11 mars 2021)