Comment automatiser la saisie des commandes clients : EDI, portail, OCR ou agent relié à l'ERP

Les éditeurs présentent souvent ces méthodes comme concurrentes. Elles ne le sont pas : chacune supprime la saisie pour un type de client différent, et chacune laisse une partie différente du travail à quelqu'un. Ce qui compte, c'est la forme sous laquelle la commande vous arrive, et qui doit changer ses habitudes pour qu'elle arrive autrement.

Le mot « agent » recouvre des produits fondés sur des règles, sur de la RPA qui pilote les écrans de l'ERP, ou sur des modèles de langage. Le critère n'est pas l'étiquette mais ce que l'outil fait d'une ligne qu'il ne peut pas confirmer : il la bloque avec une raison, ou il devine. La différence entre un agent et un robot qui rejoue des clics est détaillée dans agents IA ou RPA.

Avant d'acheter quoi que ce soit, regardez ce que fournit déjà l'éditeur de votre ERP. Le tableau reprend ce que chaque éditeur documente, lu à la date indiquée en haut de page ; les éditions évoluent, confirmez avec votre intégrateur pour votre version.

Deux enseignements. Business Central, Supply Chain Management et Business One documentent chacun un emplacement pour les références des clients, et la plupart des ERP en ont un : si cette table est vide chez vous, la remplir est le premier chantier, quelle que soit la méthode retenue. Et quand la lecture est proposée par l'éditeur, ses limites sont écrites noir sur blanc (devis d'abord, deux langues, pièces jointes seulement) : testez-les sur vos vraies commandes avant de chercher ailleurs.

Cinq critères tranchent la plupart des cas : combien de clients commandent, à quel point le volume est concentré, combien de formats arrivent, quelle est la complexité d'une ligne, et à quelle fréquence les commandes changent après envoi. La matrice se lit critère par critère ; la décision vient de la combinaison, par groupe de clients.

Situations courantes et méthode qui convient le plus souvent

Une commande automatisée s'arrête rarement parce qu'elle est mal lue. Elle s'arrête parce qu'on ne sait pas quel article le client voulait. Les clients commandent avec leurs propres références, vos codes, des codes-barres, des libellés ou un renvoi à une commande passée, souvent plusieurs de ces formes sur le même bon.

Constituez la table de correspondance à partir de l'historique avant tout pilote : pour chaque client, les commandes des derniers mois telles qu'il les a envoyées, rapprochées de ce que l'ADV a saisi. C'est l'actif le plus utile du projet, et sa place est dans l'ERP, pas dans l'outil d'automatisation, pour survivre à un changement d'outil. Après la mise en service, chaque ligne tranchée par une personne doit ajouter une correspondance, pour que la même question ne revienne pas.

Une ligne parfaitement lue peut être fausse dans l'ERP parce qu'un nombre voulait dire autre chose. La règle vaut partout : ce sont vos données de référence qui disent ce que signifie une valeur, jamais le document du client.

Déduire l'unité du prix est le seul raccourci à connaître, parce qu'il se vérifie. Chez Biodéal, quand un bon donne une quantité sans unité, le système compare le prix unitaire du document au tarif SAP de chaque unité possible ; l'exemple de l'étude de cas est un litre de lait à 1,17 €, qui ne peut être qu'une brique et non un colis de six à environ 7 €. Les lignes ainsi déduites sont saisies et signalées à l'équipe pour confirmation.

L'EDI prévoit des messages pour les modifications. Dans EANCOM, la norme de GS1, le message ORDCHG permet à l'acheteur de modifier ou d'annuler des lignes, et précise que le numéro de commande, les parties ou un numéro de ligne ne se modifient pas ainsi : il faut annuler et recommander. La norme américaine X12 associe de même la commande 850 à une demande de modification 860 et à une réponse 865.

L'e-mail n'a pas de tel contrat. Un PDF renvoyé, un bon rectificatif et un aimable « merci d'annuler la ligne 3 » arrivent tous comme de nouveaux e-mails, et un traitement qui prend chaque e-mail pour une nouvelle commande crée des doublons. Écrivez les règles avant le pilote :

La clé est le couple client et numéro de commande, comparé aux commandes déjà reçues, avec comparaison des lignes quand le numéro correspond. L'étude de cas Biodéal décrit la même exigence à sa façon : l'agent suit une commande sur plusieurs e-mails, à mesure qu'elle est créée, fusionnée ou remplacée.

La plupart des calculs de rentabilité ne comptent que la saisie. Le temps qu'une commande coûte vraiment comprend aussi les relances pour la clarifier et les corrections quand elle a été mal saisie, et c'est précisément ce qui change, en bien ou en mal, quand on change la prise de commande. Mesurez-les par canal avant de choisir :

• Compter un mois complet de commandes par canal et par client, depuis l'ERP et la boîte mail
• Chronométrer un échantillon de commandes par canal sur deux semaines, du début à la fin, recherches comprises
• Compter les relances par commande dans les éléments envoyés et en chronométrer un échantillon
• Compter les corrections dans le journal des modifications de l'ERP et les avoirs dus à la saisie
• Noter le temps de référence par canal en minutes par commande, avec la taille de l'échantillon

Pour convertir cette mesure en heures et en coût, le calculateur du coût des erreurs de saisie de commandes prend le volume, les minutes par commande, le taux d'erreur et le coût horaire, et le calculateur de ROI de l'automatisation transforme les heures libérées en délai de retour sur investissement. Sur ce que coûte la saisie manuelle, voir le vrai coût de la saisie manuelle des commandes.

Le prix des licences est la partie visible. Le coût complet compte six postes, et ceux qui décident du résultat sont en général les données de référence, le temps de contrôle et la maintenance, qu'aucun devis ne chiffre.

Deux postes méritent un chiffre à part dans toute proposition. Le temps de contrôle : la part des commandes bloquées multipliée par les minutes pour en traiter une, mesurée pendant le pilote plutôt que promise. Le changement de format : ce qui se passe, et qui paie, quand un client change d'ERP et que son bon de commande change du jour au lendemain. En EDI, c'est un mapping à reprendre avec le partenaire ; en capture par modèle, un nouveau modèle ; avec un agent, rien s'il lit sans modèle, mais ses correspondances restent à entretenir.

Un pilote répond à une seule question : sur nos commandes, avec nos données, cette méthode supprime-t-elle plus de temps qu'elle n'en ajoute, sans perdre ni altérer une commande ? Définissez les mesures avant de commencer, et publiez les définitions avec les résultats.

La méthode générale, du choix de l'échantillon à la décision de continuer ou d'arrêter, est dans le guide pour piloter un projet d'automatisation documentaire. Pour les commandes, incluez au moins un client qui modifie souvent ses commandes : c'est là qu'apparaissent les doublons et les écrasements silencieux.