Les trente premiers jours après la bascule : ce qui casse

La sixième partie portait sur le rapport : comment il cesse d'être un fichier que l'on assemble en deux jours pour devenir une vue que l'on ouvre sur l'instant présent. Cela complète le tableau que nous avons construit en six parties : quand un tableur cesse d'être la réponse, quel fichier fait réellement tourner l'entreprise, le nettoyage des données avant leur transfert, l'ordre dans lequel les choses migrent, qui voit quoi, et la fin du rapport fait à la main.

Reste la partie qui décide si tout cela porte ses fruits : le premier mois en production. Et voici une chose que sait quiconque a mené un tel projet. La plupart des migrations n'échouent pas pendant la construction. Elles échouent dans les premières semaines d'utilisation. Le système fonctionne, les données sont là, les écrans sont corrects, et pourtant le vrai travail glisse discrètement vers l'ancien fichier. Cette partie explique pourquoi cela se produit et propose un plan pour l'éviter.

La résistance n'est pas de l'entêtement, c'est un calcul de risque

La première chose que vous rencontrez en première semaine, c'est l'hésitation de l'équipe. L'erreur courante pour un dirigeant est d'y voir une résistance au changement ou de la paresse et d'y répondre par la pression. Ce n'est généralement ni l'un ni l'autre.

L'employé qui ouvrait un fichier et terminait la tâche en deux minutes a désormais besoin de dix pour apprendre le parcours à travers le même écran. De son point de vue, il paie aujourd'hui le coût d'un bénéfice dont on lui a parlé mais qu'il ne voit pas encore, et il répond devant son responsable de la production du jour, pas de la réussite du projet. L'hésitation est parfaitement rationnelle.

Elle s'intensifie lorsque le propriétaire de l'ancien fichier est quelqu'un dont la position dans l'entreprise s'est construite sur sa connaissance de ce fichier. Celui qui était la référence unique d'un fichier peut craindre que le système rende son rôle superflu. Ignorer cette crainte ne la fait pas disparaître ; cela la fait passer dans la clandestinité. Mieux vaut l'aborder de front : donner à cette personne un rôle déclaré dans le nouveau dispositif, celui de responsable de la qualité des données de son domaine, afin qu'elle passe du statut de gardienne d'un fichier à celui de référence pour les données elles-mêmes.

Le véritable changement du premier mois, c'est que le travail est devenu visible. Quand les données vivaient dans un fichier, une saisie tardive était invisible. Dans un système, qui a enregistré quoi et quand est consigné. C'est rassurant pour quiconque travaille de manière régulière et inconfortable pour quiconque est habitué à la souplesse, et il vaut mieux le dire ouvertement lors de la première réunion que de le découvrir au bout de deux semaines.

Le retour discret à l'ancien fichier

Le plus dangereux au cours du premier mois ne se produit pas bruyamment. Personne ne s'oppose au système en réunion, mais une copie de l'ancien fichier reste ouverte sur l'ordinateur de quelqu'un, qui y saisit les données parce que c'est plus rapide, avec l'intention de les reporter dans le système en fin de semaine. En général, il ne le fait pas.

Cela produit le pire résultat possible : deux sources de vérité au lieu d'une. Avant le projet, vous aviez un seul fichier imprécis que tout le monde reconnaissait comme référence. Vous avez maintenant un système incomplet et un fichier incomplet, et personne ne sait lequel est le plus récent. Vous êtes dans une situation pire qu'au départ, et c'est l'un des schémas abordés dans Pourquoi les projets ERP échouent et comment faire réussir le vôtre.

Les signaux apparaissent tôt si vous les cherchez : un chiffre cité en réunion qui n'existe pas dans le système, un fichier partagé dans la messagerie de l'équipe deux semaines après le lancement, un employé qui demande à exporter les données pour travailler dessus à l'extérieur et ne les rapporte jamais. Ne traitez aucun de ces signaux en blâmant la personne. Posez une seule question : qu'est-ce que le fichier lui apportait que le système ne lui apporte pas ? La réponse est généralement une étape manquante, un champ absent ou un parcours plus long que nécessaire, autant de choses qui se corrigent en quelques jours une fois qu'on les connaît.

Les lacunes qui apparaissent après la bascule, pas avant

Aussi bien que vous ayez nettoyé les données au préalable, comme l'a exposé la troisième partie, des lacunes apparaîtront qui ne pouvaient être découvertes qu'à la première transaction réelle. La logique est simple : le fichier tolérait le vide, si bien qu'une cellule vide restait vide et que rien ne vous empêchait d'émettre la facture. Le système exige le champ parce qu'une étape ultérieure en dépend.

Voici ce qui apparaît généralement à ce stade :

• Des fiches de tiers incomplètes. Un client enregistré sous son seul nom, sans numéro fiscal, sans adresse ni contact documenté, autant d'informations que l'on demandait oralement au besoin.
• Des soldes d'ouverture qui ne concordent pas. Le chiffre d'ouverture d'un client ou d'un article ne correspond pas à ce qu'indique l'ancien fichier, et l'écart apparaît sur le premier relevé.
• Des états qui n'ont jamais été classés. Une commande en attente, un paiement partiel, un retour jamais clôturé. Dans le fichier, c'était une note dans la marge ; dans un système, il leur faut un état défini.
• Des unités et des prix multiples. Un article vendu au carton et acheté à l'unité, tarifé différemment selon la catégorie de client, le tout conservé dans la tête du responsable commercial plutôt que par écrit.
• Des exceptions sans règle derrière elles. Un client bénéficiant depuis des années de conditions particulières sans aucun document, si bien que personne ne sait comment le paramétrer dans le système ni qui a le pouvoir de l'approuver.

Rien de tout cela ne prouve que la migration a échoué. C'en est le premier véritable bénéfice : le système a révélé ce que le fichier cachait. Mais le traitement exige de la discipline. Consignez chaque point sur une liste unique et déclarée, avec la personne qui détient la réponse et une date de clôture. Traitez chaque cas séparément dans une conversation à part, et il reviendra le mois suivant sous une autre forme.

Une formation donnée une seule fois ne suffit pas

Le schéma le plus répété dans les projets en difficulté est la formation dispensée en une seule séance le jour du lancement, à laquelle tout le monde assiste, et qui parcourt l'ensemble du système de bout en bout. Chacun retourne ensuite à son poste en ayant oublié l'essentiel, parce qu'il l'a entendu avant d'en avoir besoin.

L'alternative qui fonctionne repose sur trois principes :

• Former au rôle, pas au système. Le comptable n'a pas besoin des écrans de l'entrepôt et le responsable commercial n'a pas besoin des réglages de permissions. Chaque équipe apprend le parcours qu'elle empruntera chaque jour, plus court et bien plus ciblé.
• Répéter après une semaine d'utilisation. C'est la deuxième séance qui rapporte vraiment, car les questions qui y sont posées sont réelles, tirées du travail quotidien plutôt qu'hypothétiques. Et les questions qui reviennent d'une équipe à l'autre vous indiquent précisément où un écran manque de clarté.
• Documenter avec des images, pas de la prose. Une page par rôle avec les étapes dans l'ordre et des captures d'écran, affichée ou envoyée. La plupart des questions après le lancement sont des questions de mémoire, pas de compréhension.

Il vous faut aussi, au sein de chaque équipe, une personne que l'on sollicite en premier, car un employé demande à un collègue avant d'ouvrir un ticket d'assistance. Ce rôle informel réduit le temps de réponse plus que n'importe quel canal d'assistance externe. Ce type de conduite du changement n'est pas propre à l'abandon des tableurs, et nous l'avons abordé dans le cadre des phases de mise en œuvre dans Comment réussir la mise en œuvre d'un ERP.

Le regard d'Origami

Nous considérons le jour du lancement comme le milieu d'un projet, et non comme sa fin. Un système ne s'enracine pas dans une entreprise du seul fait qu'il fonctionne ; il s'enracine lorsqu'il devient le chemin le plus court pour accomplir le travail de la journée. Chaque jour où l'ancien parcours reste plus rapide que le nouveau est un jour qui travaille discrètement contre le projet.

C'est pourquoi, au cours du premier mois, nous tenons une liste déclarée d'observations avec des dates de clôture, et nous mesurons l'utilisation réelle plutôt que les impressions : qui se connecte, quelles transactions sont enregistrées au moment où elles ont lieu, et où un écran bloque les gens. C'est ce que nous appliquons lorsque nous construisons des systèmes sur mesure dans le cadre de nos services, car corriger un petit blocage dès sa première semaine coûte une heure, alors que le corriger au bout de deux mois coûte la confiance de toute une équipe.

Un plan sur trente jours

Voici un plan que vous pouvez appliquer tel quel, et sa caractéristique la plus importante est que chaque étape a une fin déclarée :

• Jours 1-7 : fonctionnement en parallèle borné. Le travail est enregistré à la fois dans le système et dans l'ancien fichier pour une seule raison : la comparaison. En fin de semaine, prenez un petit échantillon, comparez les deux chiffres et consignez chaque écart selon sa cause plutôt que selon son ampleur.
• Jour 8 : l'ancien fichier passe en lecture seule. C'est l'étape la plus importante du plan. Le fichier reste consultable et personne n'y écrit plus. Sans date de clôture déclarée, le fonctionnement en parallèle se poursuit indéfiniment, et il se termine toujours par la victoire de l'ancien fichier, parce qu'il est plus facile.
• Jours 8-14 : deuxième formation et comblement des lacunes. Une courte séance par équipe sur les questions qui se sont réellement posées, et la clôture des cinq premiers points de la liste des lacunes.
• Jours 15-21 : mesurer l'utilisation. Vérifiez qui utilise réellement le système et qui ne l'utilise pas, et pour chaque transaction enregistrée en retard, demandez pourquoi. Ce que vous apprenez est un signal sur la clarté du parcours, pas sur la discipline individuelle.
• Jours 22-30 : stabiliser et faire le point. Clôturez les observations restantes, produisez le premier rapport mensuel à partir du seul système, et réunissez les chefs d'équipe pendant une demi-heure pour identifier ce qui se passe encore en dehors du système et pourquoi.

La mesure honnête du succès n'est ni la satisfaction de l'équipe dans une enquête ni le nombre d'écrans utilisés. C'est un moment unique : quelqu'un cesse d'ouvrir l'ancien fichier sans qu'on le lui demande. À ce stade, le système n'est plus un projet que vous pilotez : c'est la manière dont l'entreprise fonctionne.

Clôture de la série

Au fil de sept parties, nous avons parcouru tout le chemin : les signaux qu'un tableur a dépassé ses limites, l'inventaire qui vous indique quel fichier est réellement votre système, le nettoyage des données, l'ordre dans lequel les choses migrent, la définition des permissions, la transformation du rapport fait à la main en vue en temps réel, et enfin la traversée du premier mois.

La conclusion à retenir est la suivante. Excel est un excellent outil, et le problème n'a jamais été l'outil mais ce qu'on lui demandait de porter. Passer à un système relève moins d'une mise à niveau technique que de la décision que les données de l'entreprise appartiennent à l'entreprise plutôt qu'à un fichier ou à une personne. Et cela commence par un petit pas : ouvrez le fichier qui fait tourner votre entreprise aujourd'hui et demandez-vous qui le met à jour, quand, et ce qui se passe en son absence.

Sources

• Autorité saoudienne des données et de l'intelligence artificielle (SDAIA) — la loi sur la protection des données personnelles (PDPL) et les obligations relatives aux données une fois qu'elles migrent vers de nouveaux systèmes.
• Autorité de la zakat, des impôts et des douanes (ZATCA) — exigences de facturation électronique, conservation et production des documents sur demande.
• Ministère des Ressources humaines et du Développement social — dispositions régissant les dossiers des employés et la conservation de leurs données.
• Ministère du Commerce — dispositions régissant les livres et registres commerciaux des établissements.
• Autorité générale des petites et moyennes entreprises (Monsha'at) — programmes permettant aux établissements d'adopter des outils de gestion et de transformation numérique.