Faire passer les commandes par fax au Web ── concevoir la période de double exploitation et une migration par étapes

Dans l’article précédent, « Qu’est-ce que l’EDI ? Comment il facilite les échanges de commandes entre entreprises », nous avons passé en revue le mécanisme qui remplace la ressaisie manuelle des commandes reçues par fax ou par e-mail par un échange de données entre systèmes.

Cet article en est la suite. Le thème avance d’un cran par rapport à « comprendre le mécanisme » vers comment migrer concrètement.

Les demandes du type « nous voulons faire passer nos commandes par fax au Web » se poursuivent le plus souvent ainsi :

« Mais certains de nos partenaires ne peuvent utiliser que le fax »

« Nous voulons continuer à utiliser notre système de gestion des ventes tel quel »

« Nous ne pouvons pas nous permettre que les commandes s’arrêtent pendant la transition »

Autrement dit, l’enjeu pratique n’est pas de construire un système de commande Web. C’est de concevoir la période pendant laquelle on migre progressivement vers le Web tout en conservant le fax.

Cet article organise le passage des commandes par fax au Web autour de quatre axes : la conception de la période de double exploitation, l’import CSV comme forme intermédiaire, la préparation des référentiels produits et clients, et la façon d’associer les partenaires commerciaux à la démarche.

1. La conclusion, d’entrée de jeu

Voici les points clés à retenir lorsqu’on planifie le passage des commandes par fax au Web :

• Fixer l’objectif non pas sur « l’abandon du fax », mais sur « la réduction du nombre de commandes nécessitant une saisie manuelle »
• Partir du principe qu’une période de double exploitation du fax et du Web se produira nécessairement, et en concevoir d’abord la durée et la façon de la mesurer
• Les moyens de réception (canaux) peuvent être multiples, mais le traitement interne des commandes doit être unifié en un seul flux
• Ne pas exiger d’emblée une saisie sur écran Web, mais prévoir l’import CSV comme forme intermédiaire
• Comme l’écran de commande Web expose directement les référentiels produits et clients, préparer d’abord ces référentiels
• Ne pas basculer tous les partenaires commerciaux d’un coup, mais les classer selon le volume et le degré de coopération, et les migrer dans l’ordre

JIPDEC souligne également que lorsque des traitements manuels comme le fax ou le téléphone subsistent, le personnel nécessaire pour les gérer reste requis, ce qui rend difficile d’obtenir pleinement les bénéfices de l’efficacité recherchée. C’est précisément pour cette raison qu’il ne faut pas laisser la période de double exploitation comme « quelque chose qui se produit inévitablement », mais faire du plan visant à la raccourcir un objet de conception à part entière.

2. Pourquoi un basculement intégral et immédiat vers le Web échoue souvent

Le passage des commandes par fax au Web présente une particularité qui ne peut pas se décider uniquement en fonction des contraintes du système interne, car c’est le partenaire commercial qui envoie la commande.

Annoncer uniformément à tous les partenaires commerciaux « à partir du mois prochain, veuillez commander via le Web » tend à provoquer les échecs suivants :

• Les partenaires qui ne peuvent commander que par fax cessent d’être une « exception » et deviennent un « obstacle au plan »
• La situation diffère d’un partenaire à l’autre, mais on leur impose la même échéance
• Les commandes des partenaires qui n’ont pas migré continuent d’arriver par fax, si bien que la double exploitation se perpétue indéfiniment
• Le projet est jugé sur le mode « on est passé au Web, mais les effectifs n’ont pas baissé », et il s’arrête

La cause en est que l’objectif a été fixé sur « éliminer le fax ».

En remplaçant cet objectif par « réduire le nombre de commandes nécessitant une saisie manuelle », le plan devient réaliste. Par exemple, si seuls les partenaires principaux, qui représentent 70 % des commandes, migrent vers le Web ou le CSV, le travail de saisie diminue considérablement même si les 30 % restants demeurent sur fax.

Plutôt que de faire bouger l’ensemble d’un coup, on avance en priorité là où l’impact est le plus grand. C’est le principe de base d’une migration par étapes.

3. La forme visée après migration ── plusieurs points d’entrée, un seul traitement interne

Avant de concevoir la migration par étapes, il est utile de dessiner d’abord la forme visée.

Le point clé est de penser séparément le canal de réception et le traitement des commandes.

[Canaux de réception]              [Données de commande communes]    [Traitement interne]

Fax ──── saisi par un employé ──┐
Pièce jointe e-mail ── saisi par un employé ─┤
Import CSV ─── import automatique ────┼──→ Données de commande ──→ Allocation de stock, expédition, facturation
Écran de commande Web ── enregistrement automatique ───┘   (format unifié)

Quel que soit le nombre de canaux de réception, tant que le format et le traitement des données de commande en aval sont unifiés en un seul flux, les processus en aval — stock, expédition, facturation — continuent de fonctionner selon un flux commun.

À l’inverse, si l’on crée un traitement ou un registre distinct pour chaque canal, l’activité se complexifie à chaque nouveau canal ajouté, et la charge de la double exploitation ne cesse de croître.

Même une commande arrivée par fax doit devenir, une fois saisie par un employé, la même donnée de commande que celle des autres canaux. On peut dire que la migration consiste à réduire, dans ce schéma, le volume qui s’écoule dans la ligne « saisi par un employé », tout en augmentant celui qui s’écoule dans les lignes « import automatique » et « enregistrement automatique ».

Il n’est pas forcément nécessaire de refondre le système de gestion des ventes existant. Dès lors qu’on peut vérifier s’il est possible d’ajouter un point d’entrée pour les données de commande (fonction d’import CSV, intégration à une base de données, API, etc.), on peut avancer tout en conservant le dispositif actuel. Ce point de vérification est exactement celui traité dans « vérifier la connexion au système interne » de l’article précédent sur l’EDI.

4. L’import CSV comme forme intermédiaire

Demander à un partenaire commercial de passer directement du fax à la saisie sur écran Web peut représenter une charge importante pour lui.

Du point de vue de celui qui passe commande, la saisie sur écran Web signifie « saisir une seconde fois, dans l’écran de l’autre partie, une commande déjà créée dans son propre système de commande ou dans Excel ». Si le partenaire commercial génère déjà les données de commande via son propre dispositif, recevoir ces données telles quelles sous forme de fichier et les importer représente moins de travail des deux côtés.

C’est pourquoi, comme forme intermédiaire, on prévoit un import CSV (ou Excel).

Étape 1 : recevoir le CSV en pièce jointe d'un e-mail, qu'un employé charge via la fonction d'import
Étape 2 : le partenaire commercial dépose le CSV depuis une page Web, import automatique
Étape 3 : les partenaires devenus standardisés basculent vers l'écran de commande Web ou l'EDI

Même dès la première étape, le temps de saisie et les erreurs de retranscription diminuent nettement par rapport à une saisie manuelle en regardant le bon de commande papier. L’avantage est aussi qu’il est plus facile d’obtenir la coopération du partenaire, puisque le changement de son côté se limite à « remplacer ce qui était envoyé par fax par une pièce jointe e-mail ».

Lorsqu’on conçoit l’import CSV, il faut définir a minima les éléments suivants.

Le CSV a l’air simple, mais c’est un format qui recèle de nombreux pièges du côté de l’encodage des caractères, des retours à la ligne, ou du traitement des virgules et des guillemets. Les points techniques à surveiller lors de l’implémentation du traitement d’import sont détaillés dans notre « Guide pratique du traitement des fichiers CSV ».

Notez que l’import CSV n’est pas la forme finale, mais une forme intermédiaire. La définition des champs et le système de codification décidés ici constituent directement le socle sur lequel s’appuieront ensuite la commande Web ou l’EDI.

5. Préparer d’abord les référentiels produits et clients

Avec les commandes par fax, ce sont les employés qui compensent les insuffisances des référentiels.

Par exemple, même si le bon de commande mentionne un ancien nom de produit, l’employé l’interprète comme « il s’agit en réalité de ce produit actuel » et le saisit en conséquence. Même si l’unité est indiquée en « caisses », il se souvient du nombre de pièces par caisse et fait la conversion.

En migrant vers l’import CSV ou la commande Web, c’est une machine qui doit désormais effectuer cette réinterprétation. De plus, sur l’écran de commande Web, le référentiel produits est exposé directement au regard du partenaire commercial.

Il faut donc, avant la migration, procéder au minimum aux préparations suivantes :

• Nettoyage des codes produits (traitement des références abandonnées, fusion des doublons, table de correspondance entre anciens et nouveaux codes)
• Uniformisation de la formulation des noms de produits (les libellés sont-ils présentables aux partenaires commerciaux ?)
• Unités et conditionnements (relation entre pièce unitaire, caisse et palette, quantité minimale de commande)
• Codes partenaires et codes de destination de livraison (comment traiter le cas d’un partenaire ayant plusieurs destinations de livraison)
• Où gérer les tarifs applicables et les conditions contractuelles propres à chaque partenaire

Le point important ici est de ne pas chercher à perfectionner tous les référentiels avant de commencer. Attendre cela signifie que la migration ne démarrera jamais.

L’approche réaliste consiste à ne préparer d’abord que le périmètre de produits et de destinations de livraison concernant le premier partenaire à migrer (le pilote), puis à élargir ce périmètre à chaque nouveau partenaire ajouté. Intégrez le travail de préparation des référentiels lui-même aux phases de la migration par étapes.

6. Concevoir la période de double exploitation

La double exploitation du fax et du Web (CSV) se produira nécessairement pendant la période de migration. Si on la laisse sans conception, la double exploitation devient permanente, et l’on se retrouve dans une situation où « le travail a augmenté d’autant de canaux qu’on en a ajoutés ».

Concevoir la période de double exploitation revient concrètement à décider les points suivants.

6.1. Fixer une durée et une valeur cible

Décider, en chiffres, « d’ici quand, quelle proportion des commandes devra être importée automatiquement ». Par exemple, sous une forme comme « ramener la part des commandes par fax de 70 % à 30 % en six mois ».

Une double exploitation sans échéance se fige telle quelle. Même si l’objectif n’est pas atteint, l’existence d’une échéance pousse à vérifier, partenaire par partenaire, « pourquoi la migration ne progresse-t-elle pas ».

6.2. Mesurer chaque mois les volumes par canal

L’avancement de la migration se suit avec des chiffres, pas au ressenti.

• Nombre de commandes par canal (fax, pièce jointe e-mail, CSV, Web)
• Nombre de commandes saisies manuellement et temps nécessaire
• Nombre d’erreurs d’import et leurs causes
• Nombre de corrections de saisie et d’enregistrements en double

C’est la même logique que les indicateurs à suivre après le déploiement évoqués dans l’article précédent. Mesurer séparément par canal permet de voir clairement « quel partenaire commercial il vaut la peine de solliciter pour un impact maximal ».

6.3. Harmoniser les règles opérationnelles entre les canaux

La confusion pendant la période de double exploitation survient souvent lorsque les règles métier diffèrent d’un canal à l’autre.

• L’heure limite de prise de commande est-elle la même pour le fax et le Web ?
• Quel canal reçoit les modifications et annulations de commande ? (Si une commande passée sur le Web est modifiée par fax, un rapprochement devient nécessaire.)
• La méthode de notification en cas de rupture de stock varie-t-elle selon le canal ?
• Le numéro de commande est-il unique à travers tous les canaux ? (Nécessaire pour détecter les enregistrements en double.)

En particulier, le schéma « commander sur le Web, puis modifier immédiatement après par téléphone ou par fax » se produira à coup sûr. Décidez à l’avance quel canal reçoit les modifications, et qui est responsable de corriger quelles données.

6.4. Faire aussi de la réception du fax un objet d’amélioration

Pendant la période de double exploitation, le fax subsiste. Puisqu’on part du principe qu’il subsiste, le traitement côté fax est lui aussi un objet d’amélioration.

• Recevoir le fax via un copieur multifonction, le convertir en PDF, et arrêter la gestion papier
• Regrouper les PDF reçus dans un dossier de commandes, et gérer l’état de traitement (non traité, saisi, en attente)
• Relier l’original du fax (PDF) après saisie aux données de commande par le numéro de commande, afin de pouvoir les rapprocher ultérieurement

Considérer que « le fax finira par disparaître, donc inutile d’y toucher » n’allège pas la charge pendant la période de double exploitation. Jusqu’à la fin de la migration, traitez le traitement du fax comme un canal de plus qui converge vers les mêmes données de commande.

7. Comment associer les partenaires commerciaux à la démarche

La réussite de la migration par étapes se joue davantage sur la façon d’agir auprès des partenaires commerciaux qu’en interne.

7.1. Classer les partenaires commerciaux

Ne pas traiter tous les partenaires commerciaux de la même manière, et les classer d’abord.

Ce sont les catégories A et B qui déterminent l’impact. Chercher à faire bouger de force les partenaires de catégorie C ne fait qu’engendrer des coûts, il est donc acceptable de leur affirmer clairement : « nous continuerons aussi à accepter le fax ».

7.2. Choisir un seul partenaire pilote

Plutôt que de migrer plusieurs partenaires en parallèle dès le départ, il vaut mieux d’abord établir le fonctionnement avec un seul partenaire. Les critères de choix sont les mêmes que dans l’article précédent :

• Un volume de transactions élevé, facilitant la mesure de l’impact
• Une majorité de commandes standardisées
• Une communication aisée entre les équipes des deux côtés, et une bonne compréhension de l’intégration système

Avec le pilote, construisez le « modèle » — format CSV, méthode de communication en cas d’erreur, table de correspondance des référentiels, documents d’orientation — que vous réutiliserez pour le deuxième partenaire et les suivants.

7.3. Présenter la démarche du point de vue du bénéfice du partenaire

Du point de vue du partenaire commercial, un changement de méthode de commande est une demande motivée par la convenance de votre propre entreprise. Présentez donc la démarche en mettant en avant le bénéfice du partenaire, et non votre propre gain d’efficacité.

• La confirmation de réception de commande arrive immédiatement, ce qui supprime le besoin d’un appel pour vérifier « si c’est bien arrivé »
• Les erreurs d’expédition ou de quantité dues à une mauvaise lecture diminuent
• Le partenaire peut consulter lui-même son historique de commandes, ce qui facilite les commandes répétées (dans le cas de la commande Web)
• Plus besoin de l’opération d’envoi par fax ni du renvoi en cas d’échec de transmission

Certaines attentions pratiques portent également leurs fruits.

• Résumer la procédure d’utilisation dans un manuel d’une seule page (viser une ampleur qu’une poignée de captures d’écran suffit à expliquer)
• Indiquer explicitement la date de démarrage et la période de coexistence (« à partir du mois X, nous accepterons aussi les commandes sur le Web ; le fax reste utilisable en parallèle pour l’instant »)
• Pour les premières fois, accepter les commandes qu’elles arrivent par fax ou par le Web, et répondre immédiatement aux questions

Par ailleurs, il n’est pas recommandé de commencer par une annonce du type « le fax sera supprimé à partir du mois X ». Il vaut mieux n’aborder la question de l’échéance qu’une fois la migration bien avancée et le nombre de partenaires restants réduit à une minorité, afin de ne pas nuire à la relation.

Concernant la numérisation des échanges de commandes pour les petites et moyennes entreprises, l’Agence japonaise des PME présente des initiatives de standardisation, y compris un EDI commun, et leurs bénéfices. Si votre association professionnelle ou vos principaux partenaires commerciaux se sont déjà alignés sur de telles normes, il est également utile d’envisager de s’y conformer plutôt que d’utiliser un format propriétaire.

8. Un cas type de migration par étapes

Organisons tout ce qui précède en un modèle chronologique. Ces durées ne sont qu’un exemple et varient selon le nombre de partenaires commerciaux et l’organisation interne.

L’« état des lieux » de la phase 0 peut directement réutiliser l’inventaire des méthodes de commande présenté dans l’article précédent.

Par ailleurs, si vous hésitez entre migrer la gestion des commandes elle-même vers un système Web ou la conserver sous forme d’application de bureau, « Faut-il migrer une application Windows vers le Web ? » présente un cadre de décision. La migration du canal de réception vers le Web et la migration du système interne vers le Web sont des décisions qui peuvent être prises indépendamment l’une de l’autre.

9. Écueils fréquents et parades

Pour terminer, voici un récapitulatif des écueils qui se produisent fréquemment lors des migrations réelles.

Conclusion

Le passage des commandes par fax au Web est moins un travail de construction d’un système qu’un travail de conception de la période de migration.

• Fixer l’objectif sur « réduire le nombre de commandes nécessitant une saisie manuelle », et non sur « l’abandon du fax »
• Il est possible d’avoir plusieurs canaux de réception, mais les données et le traitement des commandes en interne doivent être unifiés en un seul flux
• Ne pas exiger d’emblée la saisie sur écran Web, mais insérer l’import CSV comme forme intermédiaire
• Faire avancer la préparation des référentiels par étapes, en partant du périmètre du premier partenaire migré
• Fixer une échéance et une valeur cible pour la période de double exploitation, et mesurer l’avancement par les volumes par canal
• Classer les partenaires commerciaux selon le volume et le degré de coopération, construire le modèle avec un seul pilote, puis élargir

Comme on l’a vu dans l’article précédent, le bénéfice de l’EDI ou de la commande Web se mesure à la profondeur jusqu’à laquelle les données reçues peuvent circuler dans les processus internes. Concevoir la migration, c’est planifier, dans un ordre raisonnable, la façon d’augmenter la proportion de commandes qui rejoignent ce flux.

Pour ceux qui envisagent de faire passer les échanges de commandes au Web

Si vous envisagez de repenser vos commandes par fax mais hésitez sur le point de départ — coordination avec les partenaires commerciaux, connexion à votre système de gestion des ventes existant, façon de faire avancer le format CSV et la préparation des référentiels — il est nécessaire de commencer par organiser d’abord le décompte actuel des commandes par canal.

KomuraSoft LLC (合同会社小村ソフト) peut vous accompagner dans la conception et l’implémentation de l’import CSV et de l’intégration avec la commande Web en tirant parti de vos applications métier et bases de données Windows existantes, ainsi que dans l’organisation du plan de migration lui-même.

Sans forcément partir du principe d’une refonte complète, il est aussi possible d’envisager une configuration qui conserve le dispositif de gestion des ventes actuel tout en ajoutant progressivement des canaux de réception.

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.