Automatiser sans remplacer son ERP : comment s'y prendre

Quand un dirigeant veut automatiser son pricing, ses offres ou son catalogue, la même idée revient souvent : « Il faudrait d'abord changer d'ERP. » Parfois c'est vrai. La plupart du temps, c'est une façon de repousser le problème.

Chez un distributeur de câbles que nous avons suivi, l'ERP est resté en place. On a construit autour de lui une base produit, un moteur de calcul des prix et un module de génération d'offres, tous synchronisés avec l'existant. Le résultat est visible dans la démonstration en vidéo. Voici comment on raisonne ce type de projet.

Pourquoi ne pas simplement changer d'ERP ?

Parce qu'un changement d'ERP touche tout en même temps : migration des données, reparamétrage des flux, formation de chaque service, période de double fonctionnement. Les commandes, les stocks, la facturation et la comptabilité sont concernés d'un coup, alors qu'aucun d'eux n'était le problème.

Souvent, l'ERP fait correctement son travail. Il enregistre les commandes, suit les stocks, sort les factures. Ce qui manque est autour : un calcul que l'ERP ne sait pas faire, un processus qui vit dans des tableurs, un catalogue trop détaillé pour sa fiche article. Changer d'ERP pour obtenir un moteur de pricing, c'est refaire toute la plomberie de la maison pour ajouter un robinet.

Construire à côté de l'ERP : comment ça marche ?

Le principe tient en une phrase : le nouvel outil fait ce que l'ERP ne fait pas, et lit dans l'ERP ce que l'ERP fait bien.

Techniquement, plusieurs façons de brancher les deux existent, selon ce que votre ERP accepte : une API, des exports et imports planifiés, un connecteur fourni par l'éditeur, ou une base intermédiaire. Le choix dépend moins de la technique que de la fréquence dont vous avez besoin et de la fiabilité de chaque option.

Chez notre client, l'ERP renvoie chaque jour les stocks et les prix d'achat à la plateforme. Dans l'autre sens, un produit créé dans la plateforme est aussi créé dans l'ERP. Personne ne saisit deux fois. Et comme la plateforme porte le catalogue, elle reste utilisable même si l'ERP est indisponible. Le partage des rôles entre base produit et ERP est détaillé dans l'article sur le PIM et l'ERP.

Les questions à poser avant de brancher quoi que ce soit

Ce sont les questions qu'on pose en audit, et les réponses changent souvent l'architecture.

1. Votre ERP expose-t-il une API, ou seulement des exports de fichiers ? Qui chez vous, ou chez votre intégrateur, peut le confirmer ?
2. Pour chaque donnée échangée, quel système est maître ? Deux systèmes qui modifient le même champ finissent toujours par se contredire.
3. De quelle fraîcheur avez-vous besoin ? Une synchronisation quotidienne suffit pour préparer des offres. Elle ne suffit pas pour afficher un stock en temps réel.
4. Que se passe-t-il quand la synchronisation échoue ? Qui est prévenu, et qu'est-ce qui continue de fonctionner ?
5. Qui maintient l'intégration quand l'éditeur met à jour l'ERP ?

Si personne ne sait répondre à la première question, commencez par là. C'est elle qui décide de ce qui est possible.

Éviter le big bang : livrer par lots

La méthode qu'on applique est toujours la même : un audit du fonctionnement réel, un cadrage écrit de ce qu'on construit, puis un premier lot utilisable qui automatise et centralise une partie du processus. Le client s'en sert, remonte ses retours, on ajuste, puis on attaque le lot suivant.

Ce découpage a deux avantages. Le premier est évident : on limite le risque, parce qu'une erreur de conception se voit sur un lot, pas sur l'ensemble. Le second compte davantage à mes yeux : les équipes utilisent l'outil tôt, et leurs retours arrivent pendant qu'on peut encore changer les choses. Le contenu du premier lot est un sujet en soi, traité dans l'article sur le MVP d'un projet d'automatisation.

Pourquoi les équipes abandonnent un nouvel outil

Un outil techniquement réussi peut échouer pour des raisons très simples. Les trois qu'on rencontre le plus :

• La double saisie. Si l'équipe doit entrer la même information dans l'ERP et dans le nouvel outil, elle en abandonnera un, et ce ne sera pas l'ERP.
• Des données pas à jour. Un outil dont le stock a trois jours de retard n'inspire pas confiance, et chacun retourne vérifier dans l'ERP ou dans son fichier.
• La perte brutale des habitudes. Retirer Excel du jour au lendemain à des équipes qui y travaillent depuis des années, c'est se les mettre à dos.

Chez notre client, chaque point a eu sa réponse. La synchronisation évite la double saisie et garde stocks et prix d'achat à jour. L'import et l'export Excel ont été conservés, et les offres sortent au format Excel que les clients du distributeur attendent. La plateforme est aussi extensible sans code : le client ajoute ses propres champs sans nous rappeler. Un outil qu'on ne peut pas faire évoluer soi-même finit contourné par un nouveau tableur.

L'objectif, dit simplement : que les équipes ne se sentent pas dépossédées de leur façon de travailler, et qu'elles comprennent ce qui a été construit.

Quand faut-il quand même remplacer l'ERP ?

Il y a des cas où c'est la bonne décision, et il faut le dire. Si votre ERP n'est plus maintenu par son éditeur, s'il est impossible d'en extraire les données, si ses fonctions de base (stocks, facturation, comptabilité) posent elles-mêmes problème, ou si vous dépensez plus en contournements qu'un remplacement ne coûterait, alors le sujet est l'ERP. C'est un autre projet, avec d'autres interlocuteurs, et il vaut mieux le traiter comme tel que de l'empiler sous des automatisations.

Pour trancher entre construire autour de l'existant et acheter un logiciel qui fait tout, notre comparatif développer sur-mesure ou acheter pose les critères. Le projet complet du distributeur de câbles est raconté dans l'article sur l'automatisation du pricing, et notre façon de mener une automatisation de processus est décrite sur le site.

Avant de conclure qu'il faut changer d'ERP, faites la liste de ce qui vous manque vraiment. Pour chaque ligne, demandez-vous si c'est l'ERP qui ne sait pas le faire, ou si c'est un processus qui n'a jamais été outillé. Dans la deuxième colonne, vous trouverez en général de quoi commencer sans toucher à l'ERP.