Pourquoi et comment connecter une solution ecommerce à un PGI. C’est ce que nous explique ici, Luc Michalski, responsable R&D d’Evolutive Business, avec l’exemple de la boutique de Fusalp.
Un cas d’étude : Fulsap
Pour expliciter le mode opératoire, la boutique en ligne de la société Fusalp Créations (http://www.fusalp-boutique.com ) a été choisie afin d’illustrer les problématiques métiers et techniques à résoudre. Ce client utilise l’application Cegid Business Mod comme Progiciel de Gestion Intégré. Etant spécifique à la mode et à la distribution multi canal, il faut aussi savoir que la plupart des acteurs du textile et du prêt à porter utilisent une autre solution Cegid : OrliWeb. Le module de leur e-boutique dispose de plusieurs connecteurs pour les PGI les plus réputées.
Une boutique internet connait différentes phases d’évolution dans son existence.
Première phase : l’activité commerciale est au stade du démarrage sur un rythme modéré ; le traitement des commandes peut s’opérer en mode manuel.
Deuxième phase : l’augmentation du nombre de commandes implique un traitement optimisé de ce flux. Ce qui implique souvent un objectif de saisie automatique des commandes de l’e-boutique dans le PGI par échange de fichiers plats.
Les problématiques métiers de Fusalp Créations.
Le stock de l’enseigne est unique et multi-canal, et il faut réduire le temps de traitement d’une vente (saisie de la commande, picking du produit puis expédition du colis).
Il a donc fallu identifier à la fois les flux sortants de l’e-Boutique vers le PGI et les flux vers l’e-boutique afin d’assurer une meilleure cohérence de logistique et de la disponibilité produits sur l’e-boutique. Il faut gérer un point sensible lors de la construction de ce genre de pont de communication est la qualité des informations échangées : refléter une réalité comptable.
En respectant une nomenclature validée par Cegid, Evolutive Business a procédé à la création de trois canaux de transmission vers le PGI avec un fichier plat pour les clients, les ventes et les règlements.
Le principe : créer un client dans le PGI, dit « boutique e-commerce » et disposer de« n » adresses de livraison pour chaque cyberacheteur. Ainsi, traitées dans le PGI à 9h00 du matin, les commandes sont importées automatiquement via un compte FTP sécurisé. Ce processus permet à l’équipe d’administration des ventes de traiter les commandes de la veille directement dans leur PGI/ERP.
Pour garantir les délais de livraisons, le processus récupère un état de la valeur de stock du PGI/ERP à 14h et 18h, des horaires où les mouvements de stocks sont arrêtés (pause repas, fin de la journée de travail).
Dans l’absolu, plus les fréquences de rafraichissement du stock sont proches, plus elles sont cohérentes par rapport à la réalité du stock. Comme le stock est unique et qu’il sert à différentes branches commerciales chez Fusalp, sa mise à jour en temps réel constitue l’ultime optimisation permettant de transformer l’e-boutique en extension naturelle et fiable du réseau commercial.
L’un des points essentiels dans la création de ce genre de pont réside dans la transmission des différents codes promotionnels ou réduction sur la valeur d’une marchandise.
Prestashop offre un grand nombre de scénarios possibles, parmi lesquels on peut citer : les frais de
port offert à partir d’un certain panier, la réduction fixe ou en % grâce à un code de bienvenue, une simple réduction sur le prix d’un produit. Il faut alors pouvoir remonter cette information dans le PGI afin d’avoir une visualisation analytique de l’ensemble des opérations commerciales réalisées sur la e-boutique.
Quelle solution e-commerce faut-il privilégier ?
Le module développé pour Fulsalp a démontré, sur une période de 6 mois, une fiabilité à 100%. Cette expérience permet d’initier le débat sur choix entre les différentes solutions e-commerce comme Magento ou Prestashop.
Doit-on privilégier l’exhaustivité des fonctions ou la souplesse d’intégration dans une structure industrielle ?
J’ai positionné mon choix sur Prestashop, car dans l’absolu une boutique doit pouvoir absorber des pics de trafic, offrir la possibilité de développer des modules de qualités pour répondre à des problématiques métiers et non pas à des problématiques techniques.
A lire :
Ca me fait plaisir qu’on parle de cette problèmatique.
Dans le cas de ma societe (editeur de PGI), on a poussé le concept encore plus loin pour un client.
Le site est directement relié à la base de donnée de l’entreprise. Ce qui signifie que les flux entrant et sortant sont en temps réel. Autant pour la stratégie de prix, les informations produits et les commandes.
Je me suis toujours demandé si d’autre solution Ecommerce permettait de faire du temps réel à l’aide de connecteur.
Effectivement, le temps réel est la meilleure solution dans l’absolu mais travailler au stock « juste » peut empêcher des ventes pour des produits qui serait en réapprovisionnement le lendemain. :-)
Chaque acteur a un profil logistique différent, et c’est le point que je voulais soulever dans cet article.
Tout est une question de gestion de processus de commande après.
Avoir la valeur du stock réel ne signifie pas forcément de bloquer la commande de l’article. On peut très bien signifier à la place un avertissement avec un délai de livraison supplémentaire (délai qui dépend des commandes fournisseur en cours, du temps de commandes chez le fournisseur) et aussi demandé si l’acheteur veut une livraison partiel ou complète (change les frais de port).
Comme tu le dis chaque acteur a un profil logistique différent, le temps réel change juste la pertinance de l’information et non pas la façon dont on l’utilise.
@Marco : je pense que la connexion en temps réel n’est que rarement nécessaire, et encore pour des hauts volumes quotidiens de commande. Autrement, je me demande si ce n’est pas trop compliqué ou trop cher à mettre en oeuvre, sachant que la plupart des sites e-commerce reposent sur une techno différente du back-office dont l’existence est antérieure de plusieurs années parfois.
Pour avoir réfléchi sur les échanges en tant réel par « webservices », j’ai opposé l’argument de la lenteur et l’instabilité de ce mode.
Si le réseau entre l’ERP et le serveur Web, pour une raison quelconque, est paralysé, la boutique sera dans l’incapacité de fonctionner correctement.
Il y a donc une très forte dépendance de contraintes extérieures pas forcément contrôlables.
Et lorsque la connexion est continue entre front et back qu’en est-il des problématiques de sécurité ? Souvent le site Internet est extrêmement vulnérable (tout étant relatif) et donc est protégé de façon à ce qu’il ne soit pas possible ou tout du moins très difficile de remonter vers les informations vitales de l’entreprise (PGI, voir paye, etc).
@Marco: je suis intéressé par votre approche par rapport à cette problématique de sécurité (flux échangés et données stockées sur le front).
Nous avons opté, dans notre modeste boutique, pour une synchronisation des données régulière, mais toujours à l’initiative du back office et en exposant sur le front que des données essentiels à sont fonctionnement.
Typiquement les stocks/commandes/prix sont remis à jours toutes les 10 minutes (en différentiel), mais les informations produit, disponibilité fournisseur, etc ne sont synchronisées que toutes les heures.
Alex.
@Capitaine Commerce: C’est plus la réactivité que le volume le critère déterminant entre le temps réel et la sychro journalière.
Pour le script de transfert de gérer 10 commandes ou 10′000 commandes ça prend juste un peu plus de temps mais bon de minuit à 7 heures y a de la marge. Ensuite il est clair que c’est plus couteux qu’un Ecommerce open-source vu que c’est un système « proprietaire ». Faut dire que le cout de l’ERP et sa mise en place en général n’est pas donné non plus.
@Michalski: Dans notre cas l’ERP est mis à disposition en mode ASP. Donc le serveur WEB et les bases de données sont sur le BackBone. Je t’assure que ça débite bien^^ (aussi le compte en banque).
Enfin je sais que notre solution n’est pas parfaite (qui peut le prétendre) et que le temps réel à ces avantages et ces inconvénients.
La question c’était principalement de savoir si vous connaissiez d’autre solution de ce type? C’est à dire soit des système Ecommerce permettant une liaison en temps réel (à l’aide de webservice par exemple) ou des ERPs bénéficiant d’une extension Ecommerce en temps réel.
@Alex Chauvin
Le seul flux remontant vers la base de donnée sont l’ajout de produit et la quantité, voir des informations sur la commande adresse de livraison.
Il n’y a pas d’interface d’administration sur le site web et par conséquent il n’est pas possible d’ajouter un produit ou de changer son prix par l’intermédiaire du site. En réalité même le calcul du prix d’une ligne de commande ne s’effectue pas sur le serveur web.
Les flux descendant sont limités au besoin du bon fonctionnement du site (fiches de clients, offre, fiche de produit, stock).
Les seuls données stockées sur le site web sont des information de session (genre des n° de panier). Il n’y a pas de cache sur les informations de produit.
Techniquement le flux descendant est mis à disposition par des vues et le flux montant est traité uniquement par l’intermédiaire des procédures stockées. L’utilisateur de la base de donnée pour le serveur web n’a pas accès au reste.
Bonjour à vous,
Ayant effectué un stage chez un editeur de progiciel CRM et ayant développé des modules prestashop orientés ‘places de marchés’ (fonctionnalités de neteven mais directement dans le BO prestashop), j’aimerai savoir si vos sociétés respectives offrent des opportunités de stage et emploi dans ce genre de projet (ERP/CRM/e-commerce/flux de données).
N’hésitez pas à me contacter par mail si vous avez la moindre question : tlandru@gmail.com