Ce que nous avons appris en déployant des ERP : ce qui a marché et les erreurs que nous ne répéterons pas

Avant de créer MKA, notre équipe a développé des logiciels et déployé des ERP dans des entreprises industrielles, des sociétés commerciales, des entreprises de services et des institutions publiques. Certains projets se sont très bien passés. D’autres ont coûté plus que prévu. Nous avons appris des deux, et voici la liste honnête.

Les erreurs que nous avons vues (et que nous évitons aujourd’hui)

1. Commencer par le logiciel plutôt que par le processus

L’erreur la plus coûteuse : installer le système et « adapter l’entreprise ensuite ». Si personne n’a défini comment un achat est approuvé ni qui débloque une commande à crédit, le système ne fait qu’automatiser le désordre. Aujourd’hui : le projet commence par une revue des processus et une liste de décisions que l’entreprise doit prendre avant toute configuration.

2. Tout personnaliser

Chaque demande du type « que cet écran fasse aussi ceci » ajoute du code qu’il faut ensuite maintenir, tester et migrer. Nous avons vu des systèmes tellement personnalisés qu’ils ne pouvaient plus être mis à jour. Aujourd’hui : nous essayons d’abord de résoudre par la configuration (listes de prix, circuits d’approbation, modèles, droits). Nous ne développons du code spécifique que lorsque la règle de gestion l’exige vraiment.

3. Migrer « tout l’historique » sans le nettoyer

Charger dix ans de données sales, c’est importer dix ans de problèmes : clients en double, produits avec trois codes, soldes qui ne se rapprochent pas. Aujourd’hui : nous définissons ce qui est migré (données de base nettoyées, soldes d’ouverture validés, historique uniquement lorsqu’il apporte de la valeur) et rapprochons les soldes avec la comptabilité avant la mise en production.

4. Démarrer avec un stock mal compté

Le stock d’ouverture est le fondement du kardex (la fiche de stock) et du coût. S’il démarre faux, tout ce qui suit porte l’erreur. Aujourd’hui : la mise en production inclut un inventaire physique planifié, avec lots et emplacements lorsque c’est pertinent, et une valorisation revue avec l’équipe comptable.

5. Former tout le monde et personne

Une formation générale de deux jours pour toute l’entreprise est oubliée en une semaine. Aujourd’hui : nous formons dans chaque service des utilisateurs clés, qui connaissent le système en profondeur et accompagnent leurs équipes, et nous formons par rôle à partir de cas réels de leur travail quotidien.

6. Démarrer dans toutes les succursales à la fois

Un « big bang » multiplie les incidents précisément au moment où l’équipe a le moins de temps pour les traiter. Aujourd’hui : nous préférons un pilote dans une succursale ou un service, nous le stabilisons et ce n’est qu’ensuite que nous étendons le déploiement.

7. Traiter la réglementation comme un détail

En Bolivie, la facturation, les livres légaux et la paie obéissent à des règles strictes, et elles évoluent (la Ley 1733 en est l’exemple le plus récent). Un système qui ne suit pas expose à des amendes et à des reprises de travail. Aujourd’hui : les règles fiscales et sociales font partie du produit, paramétrées et avec des dates d’effet.

Ce que nous répétons à chaque projet

• Un sponsor de la direction. Les décisions de processus sont prises par une personne qui a l’autorité, pas par le fournisseur.
• Des phases aux livrables clairs. Démarrage, planification, exécution et contrôle, et clôture. Chaque phase comporte un rapport d’avancement et un détail chiffré de l’investissement.
• Des livraisons courtes. Nous travaillons par sprints de deux à quatre semaines : l’entreprise voit régulièrement quelque chose de concret fonctionner, pas seulement à la fin du projet.
• Des tests avant la mise en production. Chaque règle importante a son test automatisé, et les utilisateurs clés valident avec leurs propres cas.
• Des indicateurs dès le premier jour. Nous définissons ce qui sera mesuré (délai de clôture, écarts d’inventaire, délai moyen de recouvrement) pour savoir si le système a réellement amélioré l’activité.
• Un accompagnement après la mise en production. La première clôture mensuelle sur le nouveau système soulève toujours des questions ; être présent ce mois-là fait la différence.

En résumé

Un ERP n’échoue pas à cause du logiciel : il échoue à cause de décisions non prises, de données sales et d’utilisateurs qui ne s’approprient jamais le système.

C’est pourquoi aujourd’hui, à chaque déploiement de MKA, nous suivons notre propre méthodologie de mise en œuvre, fondée sur le PMBOK, et partons de la réglementation bolivienne déjà intégrée.