Comment mener à bien une transformation de 3 à 6 mois sans épuiser votre équipe opérationnelle
Un guide pratique sur la gestion du changement et la transformation numérique destiné aux prestataires de services B2B de la région DACH qui mettent en œuvre un déploiement informatique parallèlement à leurs activités courantes
Table des matières
La plupart des guides de gestion du changement consacrés à la transformation numérique s’adressent aux grandes entreprises : équipes RH dédiées au changement, responsables du changement certifiés et budget alloué à des programmes d’adoption structurés. Un prestataire de services B2B de taille moyenne fonctionne différemment. Dans une entreprise de cette taille, les rares personnes qui comprennent le cœur du processus opérationnel sont généralement celles-là mêmes qui le font fonctionner au quotidien. Leur demander de concevoir le nouveau système tout en assumant l'intégralité de leur charge de travail constitue la principale difficulté, et la plupart des guides n'abordent jamais cette question.
C'est là la tension structurelle au cœur de toute transformation opérationnelle dans la fourchette de chiffre d'affaires comprise entre 10 et 50 millions d'euros. Pour les PME de cette taille, le problème de la gestion du changement ne réside ni dans une résistance culturelle ni dans une question de leadership. Il s'agit d'un problème de planification de la charge de travail. L’équipe ne peut pas interrompre l’activité pour mettre en place le nouveau système, et le système ne peut pas être mis en place sans l’équipe. (La raison pour laquelle les équipes internes ne parviennent souvent pas à mettre en place seules un système opérationnel central est une question à part entière, que nous abordons dans le guide « Développement en interne vs agence ».) Les pages suivantes décrivent comment une mise en œuvre bien structurée résout cette contradiction dans la pratique.
Pourquoi les équipes opérationnelles s'épuisent plus vite que les autres services lors du déploiement d'un système informatique
Chaque service subit des perturbations au cours d'une transformation numérique. Les équipes opérationnelles sont confrontées à une combinaison spécifique d'exigences qui les rend plus susceptibles de souffrir d'épuisement qu'ailleurs, et ce pour deux raisons structurelles.
Premièrement : les entreprises de cette envergure, axées sur l’opérationnel, disposent rarement d’une marge de manœuvre dans leurs processus clés. Elles fonctionnent délibérément selon un modèle « lean », avec peu de redondance au niveau des effectifs dans les rôles qui assurent le fonctionnement quotidien de l’entreprise, de sorte qu’il n’existe aucune réserve permettant de prendre en charge un projet de plusieurs mois en plus du travail habituel. Le contexte général aggrave encore la situation. L’enquête « Workforce Change Survey » de Gartner a révélé qu’en 2022, un salarié moyen a connu environ dix changements organisationnels planifiés, contre deux en 2016, tandis que la disposition à de s’adapter aux changements a chuté de 74 % à 43 % au cours de la même période. Une transformation ne touche pas une équipe reposée. Elle touche une équipe qui gère déjà plus de changements qu’elle n’en a connu depuis des années. Harvard Business Review
Deuxièmement : les collaborateurs opérationnels sont précisément les personnes dont les connaissances sont les plus indispensables lors de la mise en œuvre. Ceux qui comprennent comment fonctionnent réellement les exceptions tarifaires, quels accords clients dérogent au processus standard et pourquoi certaines commandes sont traitées manuellement plutôt que par le système constituent à la fois la contribution la plus précieuse pour la nouvelle conception et le maillon le plus irremplaçable qui assure le bon fonctionnement du processus actuel. Assumer ces deux rôles simultanément est le moyen le plus rapide de s’épuiser et constitue une cause fréquente d’échec de la mise en œuvre dans les entreprises de cette taille.
Les trois décisions qui déterminent si l'équipe est épuisée
Avant même d'organiser le premier atelier ou d'écrire la moindre ligne de code, la direction doit prendre explicitement trois décisions. Il ne s'agit pas de décisions relatives aux processus, mais d'engagements structurels qui détermineront la suite des événements.
Décision n° 1 : Un responsable interne, pas un comité. Toute transformation nécessite un seul responsable interne, désigné nommément du côté du client : ni comité de pilotage, ni groupe de projet, ni l'équipe opérationnelle dans son ensemble. Une personne qui soit l’interlocutrice principale du partenaire de mise en œuvre, qui participe à la réunion de coordination hebdomadaire, qui valide les décisions de conception et qui soit responsable de l’adhésion en interne. Une responsabilité partagée transforme chaque décision en une tâche de coordination et mobilise bien plus de temps de l’équipe que nécessaire.
Décision n° 2 : Le temps de cette personne doit être formellement protégé. Nommer une responsable interne tout en lui laissant l'entière responsabilité de sa charge de travail opérationnelle n'est pas une solution. La direction doit retirer de son domaine de compétence des tâches concrètes pendant toute la durée de la mise en œuvre, et ce de manière visible, afin que l’équipe comprenne que l’entreprise procède à un véritable ajustement pour le projet et n’alourdit pas discrètement la charge de travail de quelqu’un.
Décision n° 3 : Les tests sont effectués à partir de commandes réelles, et non de scénarios fictifs. L'approche standard consiste à créer des cas de test hypothétiques et à y soumettre le système. Cela produit des résultats rassurants, mais qui s'avèrent erronés dès la première exception réelle. Les tests doivent utiliser des types de commandes réels issus de l'exploitation courante, y compris les exceptions qui surviennent deux à trois fois par mois. Avant le début des tests, le responsable interne définit cinq à dix types de commandes : les cas standard et les exceptions les plus fréquentes. Il s’agit d’une tâche de deux heures qui permet d’éviter des semaines de gestion de crise après la mise en service.
Voici comment organiser ces 3 à 6 mois : ce que fait l'équipe d'exploitation et à quel moment
La pire erreur à commettre lors d'une transformation numérique est d'impliquer pleinement l'équipe opérationnelle tout au long de la phase de mise en œuvre. Lorsque la date de mise en service arrive, l'équipe est déjà épuisée avant même que la partie la plus difficile ne commence. L'alternative consiste en une implication par phases : forte au début, lors de l'acquisition des connaissances ; réduite pendant la phase de développement ; puis à nouveau intensive pendant les tests.
| Phase | Période | Participation de l'équipe d'exploitation |
|---|---|---|
| Audit stratégique et conception des processus | Semaines 1 à 4 | Ce n'est qu'une contribution. C'est le partenaire qui dirige. L'équipe apporte son soutien et répond aux questions. Elle n'assume aucune responsabilité quant au résultat. |
| Phase de compilation | Semaines 5 à 14 | Un responsable interne. Une réunion hebdomadaire d'une heure. Pas de comités. Pas de réunions avec l'ensemble de l'équipe. |
| Tests parallèles avec des commandes réelles | Semaines 15 à 18 | Offre à durée limitée. De 2 à 4 heures par semaine et par testeur. Scénarios structurés inspirés de types de missions réels. |
| Mise en service par étapes | À partir de la 19e semaine | Une migration à la fois. Une transition difficile avec un plan de secours. Pas de fonctionnement parallèle à long terme. |
| Stabilisation après la mise en service | Semaines 20 à 28 | L'équipe est entièrement responsable du système. Les partenaires sont joignables en cas de problème. Aucune nouvelle fonctionnalité n'est prévue avant au moins 6 semaines. |
Le principe fondamental : la participation de l'équipe opérationnelle doit être maximale au début, lorsque ses connaissances sont intégrées à la conception, puis à nouveau pendant la phase de test. Pendant la phase de développement proprement dite, cette participation doit être minimale et limitée dans le temps. Les personnes chargées d’assurer le bon fonctionnement de l’exploitation ne devraient pas, durant cette phase, avoir d’obligations liées au projet allant au-delà de la réunion hebdomadaire de coordination des responsables internes.
Le piège du multitâche : la cause la plus fréquente de l'épuisement
La décision la plus courante qui transforme un déploiement gérable en une véritable épreuve est la suivante : « Nous exploitons les deux systèmes en parallèle jusqu’à ce que nous ayons confiance dans le nouveau. » Cela semble prudent. Dans la pratique des systèmes ERP, il s’agit toutefois du modèle de transition le plus gourmand en ressources qui soit, et la charge de travail qu’il engendre est bien documentée : l’exploitation simultanée des deux systèmes implique une double saisie des données et la fatigue des collaborateurs qui en découle. Xserpconsulting
Concrètement, cela signifie que l'équipe traite chaque commande deux fois. Le gestionnaire expérimenté saisit une commande dans l'ancien système, car il lui fait confiance, puis la saisit à nouveau dans le nouveau, parce qu'on le lui a demandé. Ceux qui s'occupent des devis saisissent d'abord les informations dans le tableau, puis les saisissent à nouveau dans le nouvel système. En l'espace de deux semaines, ce fonctionnement en parallèle a effectivement doublé la charge de travail des personnes qui, de toute façon, assument déjà la plus grande partie de la charge.
Prenons un cas typique. Un prestataire de services B2B exploite en parallèle son ancien processus de devis et un nouveau système de devis pendant plusieurs semaines après la mise en service, « jusqu’à ce que tout le monde soit à l’aise ». La responsable de la planification la plus expérimentée, qui est de toute façon la personne la plus sollicitée de l’équipe, doit désormais faire deux fois le travail. Sous cette charge de travail, le risque réel n’est pas une panne du système, mais un départ, et les connaissances qui s’en vont avec cette personne sont précisément celles sur lesquelles reposait le projet. Ce n’est pas un scénario hypothétique : la pratique en matière d’ERP met régulièrement en évidence la double saisie, la fatigue des collaborateurs et la perte d’une personne clé en plein milieu du projet comme des schémas d’échec typiques des longues phases de fonctionnement en parallèle ; c’est pourquoi les approches par phases raccourcissent délibérément la période pendant laquelle une seule personne est surchargée. XserpconsultingTechTarget
L'alternative consiste en une transition radicale accompagnée d'un plan de secours spécifique. Le jour de la mise en service, le nouveau système est opérationnel. S'il ne parvient pas à traiter un type de commande particulier, seul ce type de commande revient provisoirement à l'ancien processus ; le problème est consigné et résolu, tandis que tout le reste reste en production. Supposons que, le premier jour, le nouveau système ne soit pas encore en mesure de traiter un cas particulier. Ce type de commande est traité via l’ancien processus pendant un à deux jours, le problème est résolu, et le reste de l’activité ne revient jamais à l’ancien système. Au lieu d’un fonctionnement en parallèle pendant des semaines sur l’ensemble des commandes, vous n’avez qu’un à deux jours de gestion des exceptions pour une seule commande. Cette approche est plus contraignante pendant les 72 premières heures, mais nettement moins au cours des semaines suivantes.
Comment savoir, avant de vous lancer, si votre équipe est capable de mener à bien la transformation
Avant de fixer une date pour le premier atelier, vérifiez trois indicateurs. Ils vous permettront de savoir si l'équipe est en mesure d'assumer cette charge supplémentaire ou s'il faut d'abord libérer de la capacité.
Premièrement : existe-t-il une procédure documentée pour assurer la suppléance du responsable clé du processus, qui est généralement le service de planification ou le service des offres ? Si le processus n'existe que dans l'esprit d'une seule personne, celle-ci se retrouve doublement sollicitée lors de la mise en œuvre, et le projet est compromis dès le départ.
Deuxièmement : cette personne travaille-t-elle déjà régulièrement au-delà de ses horaires normaux ? Une équipe qui ne dispose d'aucune marge de manœuvre ne peut pas prendre en charge des tâches supplémentaires telles que la documentation des connaissances et les tests sans que la qualité des opérations courantes n'en pâtisse.
Troisièmement : les exceptions, les tarifs spéciaux et les accords avec les clients sont-ils aujourd'hui gérés au cas par cas, sur la base de l'expérience, plutôt que selon une règle documentée ? C'est précisément ce savoir-faire que le nouveau système doit intégrer, et ce sont précisément ces personnes qu'il est le plus difficile de décharger de leurs tâches habituelles.
Si ces trois éléments indiquent une surcharge de travail, la première étape ne consiste pas à lancer le projet, mais à alléger la charge de travail de la personne responsable en interne. Concrètement, cela signifie désigner un remplaçant qui prendra en charge, pendant la durée du projet, les tâches courantes du responsable, telles que la planification quotidienne ou la validation des devis, non pas de manière permanente, mais uniquement pendant la phase de mise en œuvre. Cette redistribution mobilise des capacités à court terme, et c’est précisément pour cette raison qu’il s’agit d’une décision relevant de la direction et non de l’équipe. Ce n’est qu’ensuite que la transformation peut commencer.
Ce qu'il faut faire maintenant
Si vous prévoyez une transformation opérationnelle parallèlement à l'activité courante, prenez d'abord les trois décisions suivantes : désigner un responsable interne, lui accorder du temps officiellement réservé à cette tâche et réaliser des tests à partir de commandes réelles plutôt que de scénarios fictifs. Organisez la participation de l'équipe opérationnelle de manière à ce qu'elle soit importante au début et pendant la phase de test, et minimale pendant la mise en place. Et évitez le piège du fonctionnement en parallèle : une transition radicale accompagnée d’un plan de repli clair sollicite davantage l’équipe au cours des 72 premières heures, mais nettement moins au cours des semaines suivantes.
La question de savoir si l'investissement est rentable est une question à part entière, et elle doit être abordée avant le déploiement, et non pendant celui-ci. Notre guide sur le retour sur investissement des logiciels sur mesure explique comment élaborer un dossier d'investissement solide à partir de vos propres données d'exploitation, avant même qu'un partenaire n'écrive la moindre ligne de code.
Si vous souhaitez disposer de cette clarté avant de vous lancer : l'audit stratégique appleute analyse votre processus opérationnel, identifie les principaux postes de coûts et fournit un chiffre représentant les coûts réels, ainsi qu'une délimitation du périmètre et une estimation de la durée d'amortissement. Il s'agit d'une mission autonome à prix fixe qui aboutit à un document que vous pourrez présenter en toute confiance à votre directeur financier ou à votre direction. Si les chiffres ne justifient pas l'investissement, nous vous le dirons également.
Prenez rendez-vous avec notre équipe pour une consultation gratuite et sans engagement.
Prenez rendez-vous avec notre équipe pour une consultation gratuite et sans engagement.
FR 
DE 
EN 
ES