Migration des tableurs vers un ERP : le plan en 30 jours qui va vraiment au bout

Tous les dirigeants à qui je parle finissent par prononcer la même phrase. Nous savons que les tableurs ne suffisent plus. Puis rien ne se passe pendant encore un an, parce qu'une migration ressemble à un projet qui mange un trimestre entier, et personne n'a un trimestre de libre.

Ça n'a pas à se passer comme ça. Une migration des tableurs vers un ERP n'est lente que si vous essayez de tout déplacer d'un coup. Migrez correctement un seul processus et le reste suit sur sa lancée. Voici la version en trente jours qui va vraiment au bout, et vous pouvez lancer la première étape cet après-midi.

Choisissez le processus qui vous coûte de l'argent quand il casse

Ne commencez pas par l'organigramme ou la liste des modules. Commencez là où l'argent fuit. Pour la plupart des PME, c'est l'un de ces trois endroits : les prospects jamais relancés, les devis qui ne deviennent jamais des factures, ou les chiffres de stock auxquels personne ne se fie.

Choisissez-en un. Un seul. Si vous hésitez, demandez quel tableur quelqu'un ouvre chaque matin sans exception. C'est le fichier qui tient l'entreprise, et c'est celui à migrer en premier.

Ce n'est pas une question de rangement. Un système qui règle quelque chose de douloureux dès la deuxième semaine est utilisé. Un système qui arrive complet au bout de six mois est ignoré, parce qu'entre-temps chacun a construit un contournement, et ce contournement, c'est un tableur.

Écrivez ce qui se passe réellement avant de toucher au moindre logiciel

Prenez une heure avec la personne qui fait réellement tourner ce processus, pas avec celle qui possède l'entreprise. Demandez-lui de suivre un vrai dossier du début à la fin pendant que vous notez les étapes en langage simple.

Vous cherchez trois choses. Les étapes par lesquelles passe un dossier, les champs que quelqu'un utilise vraiment pour prendre une décision, et les moments où une personne doit être prévenue qu'il s'est passé quelque chose. C'est dans ce dernier point que se cache la valeur. L'essentiel de la douleur d'un processus manuel ne vient pas de la saisie, il vient du fait que personne ne sait qu'un problème est survenu avant qu'il soit déjà trop tard.

Vous découvrirez que le processus compte bien moins d'étapes réelles que le tableur ne le laisse croire, et qu'une poignée de colonnes seulement sont des champs de décision. Le reste, ce sont des notes, des codes couleur et une chose ajoutée il y a des années par un ancien salarié que personne n'a osé supprimer.

Importez moins de données que vous ne le voudriez

C'est ici que les migrations meurent. Quelqu'un décide que tout l'historique doit suivre, puis passe trois semaines à nettoyer des années de noms d'entreprises incohérents et perd l'envie de continuer.

Ma règle est simple. Reprenez tout ce qui est actuellement ouvert, plus les données de référence dont vous avez besoin pour travailler : clients, produits, fournisseurs. Tout ce qui est clos va dans un seul fichier d'archive, stocké et consultable, pas importé. Si vous avez vraiment besoin d'un dossier clos d'il y a trois ans, vous le retrouvez dans l'archive en trente secondes. C'est un échange honnête contre trois semaines de votre vie.

Nettoyez les données de référence avant de les importer, jamais après. Dédoublonnez la liste clients, corrigez le pays et la devise, mettez chaque numéro de téléphone au format international pour qu'un logiciel de numérotation ou une intégration WhatsApp puisse l'utiliser plus tard. Des données sales qui arrivent dans un nouveau système ne deviennent pas plus propres, elles sont juste copiées.

Faites tourner les deux pendant deux semaines et laissez le tableur perdre

Le fonctionnement en parallèle fait peur parce qu'il ressemble à du travail en double. Faites-le quand même, et gardez-le court. Deux semaines, un processus, aucune exception.

Le but n'est pas la sécurité. Le but, c'est que pendant ces deux semaines vous découvrirez les quatre ou cinq petites choses que personne n'a mentionnées lors du passage en revue. La remise que quelqu'un applique à la main. Le client facturé sous une autre raison sociale. La validation qui se fait oralement dans un couloir.

Corrigez chacune dans le système au fur et à mesure. Au bout de deux semaines, le système fait tout ce que faisait le tableur, plus ce que le tableur n'a jamais pu faire, et l'équipe a déjà cessé d'ouvrir l'ancien fichier parce que le nouveau est plus rapide. C'est à ce moment qu'une migration est vraiment gagnée, et cela vient de l'usage quotidien, pas d'une session de formation.

Mettez la date d'arrêt par écrit

Choisissez une date, envoyez-la par e-mail et nommez la personne responsable du processus après cette date. Sans cela, vous obtenez un hybride permanent où la moitié de l'équipe utilise le système et l'autre moitié garde une copie privée, et un hybride est pire que les deux options, parce que plus rien n'est fiable.

À la date d'arrêt, placez le tableur dans un dossier en lecture seule. Ne le supprimez pas. Personne ne doit avoir l'impression qu'on lui a retiré son filet de sécurité, il faut juste arrêter de le modifier.

Les trois erreurs qui coulent la plupart des migrations

La première, c'est d'acheter sur la liste des fonctionnalités. Tous les systèmes font de belles démos. Ce qui compte, c'est de savoir si votre processus réel s'y adapte sans personnalisation lourde, et c'est exactement pour cela qu'on écrit d'abord le processus, puis qu'on fait la démo sur ses propres étapes avec ses propres données. Une démo sur la société exemple de l'éditeur ne vous dit rien de votre entreprise.

La deuxième, c'est l'absence de responsable. Un système sans responsable nommé retourne aux tableurs en un trimestre. Le responsable n'a pas besoin d'être technique, il doit tenir à ce que les données soient justes et avoir l'autorité de demander à quelqu'un de corriger un dossier.

La troisième, c'est de traiter la formation comme un événement. Une heure de formation collective n'apprend presque rien. Dix minutes avec chaque personne, dans son propre travail réel, pendant sa première semaine, apprennent tout, parce qu'elle découvre les deux écrans dans lesquels elle va vivre plutôt que tout le produit.

Attendez avant les tableaux de bord

Un reporting construit sur deux semaines d'usage réel et propre est honnête. Un reporting construit sur un historique importé est généralement un beau graphique montrant à quel point l'ancien tableur était mal tenu. Accordez-lui un mois d'usage réel, puis construisez les trois chiffres que le dirigeant regarde vraiment, et arrêtez-vous là. Un tableau de bord que personne ne lit est un coût, pas un atout.

Ce qu'il faut faire aujourd'hui

Ouvrez le tableur que quelqu'un touche chaque matin. Écrivez ses vraies étapes et ses champs de décision sur une seule page. Séparez les données entre dossiers ouverts et historique clos, et mettez l'historique dans une archive que vous n'importerez pas. Puis réservez une heure avec la personne qui fait tourner le processus et suivez un dossier de bout en bout.

C'est le premier jour, et c'est l'étape que presque tout le monde saute, c'est exactement pour cela que leur migration prend six mois au lieu de trente jours.

Si vous préférez que ce soit construit une fois et bien construit, sur votre propre domaine, avec votre logo et votre propre processus à l'intérieur, c'est ce que nous faisons chez Talent Alliance Hub. Dites-moi quel tableur vous fait le plus souffrir et je vous dirai honnêtement si c'est un chantier de trente jours. Nous contacter.

À lire aussi

Si cet article vous a été utile, vous aimerez peut-être aussi ce que coûte réellement une implémentation ERP, la facturation électronique aux EAU pour les PME et ce qu'il faut corriger avant juillet 2027 et ce que coûte réellement la mise en place d'un CRM pour une petite entreprise.