Marketplace #2 – L’intégration de la marketplace dans mon écosystème e-Commerce : Les impacts techniques

Dans cet épisode, nous allons expliquer les impacts techniques de l’intégration d’un moteur de marketplace dans votre écosystème e-Commerce.
Dans nos exemples ou nos mises en situation nous prendrons l’hypothèse d’un e-commerçant qui souhaite faire évoluer son site vers un modèle marketplace (donc vers un e-Commerce multi-vendeur). Mais même si vous n’avez pas encore d’e-Commerce, les impacts que nous allons décrire restent valables dans un projet de création de marketplace from scratch.

Vocabulaire

• SI (Système d’Information) : dans notre article le SI est la brique macro qui contient tous les systèmes pour gérer les fonctionnalités back-office de l’e-Commerce (ERP, WMS, OMS,
• Référentiels : Ce sont les briques logicielles qui portent vos référentiels de données. Le PIM pour le référentiel produit, le RCU pour le référentiel client, le DAM pour les assets, …
• PIM : Product Information Management : il gère votre référentiel produit enrichi.
• DAM : Digital Assets Management : il gère vos assets, c’est à dire vos visuels et autres medias.
• RCU : Referentiel Client Unique.
• BI (Business Intelligence) : il vous permet d’éditer votre reporting.
• OMS (Order management System)
• GRC (Gestion de la Relation Client) : il s’agit de votre outil de suivi des demandes clients, traitées par votre service client.
• WMS (Warehouse Management System) : il s’agit du système informatique qui gère votre entrepôt/stock, intégré à votre SI, ou délégué à un tiers Logistique, permettant d’assurer les expéditions sur vos ventes en propre (ou dans le cas où vous faites du “Fulfillment by”). Dans le cadre d’une marketplace, chacun de vos marchands possède son propre WMS pour son entrepôt à lui.
• CMS e-Commerce : la solution technique qui gère l’exposition du catalogue pour vos visiteurs, les fonctionnalités d’animation commerciale en ligne, et tout le transactionnel (le tunnel de commande et le paiement).
• MMKP : Le Moteur MarKetPlace : la brique applicative permettant l’intermédiation de l’opérateur (vous) entre le vendeur et l’acheteur. (cette brique illustre l’intégration d’une solution de type Mirakl, Izberg, Wizaplace, Octopia,….)
• Un produit : l’ensemble des informations “froides” qui décrit un produit (descriptions, caractéristiques)
• Une offre : les données “chaudes” dans le cadre de la vente d’un produit (le stock, le prix. L’information de l’état du produit – neuf, reconditionné, occasion,… – est également portée par l’offre). 2 marchands peuvent vendre un même produit : ce sera 2 offres différentes.
• MVP : Minimum Viable Product : c’est le périmètre acceptable pour mettre en ligne une version 1 viable.

Introduction

Si vous êtes DSI, prêt à vous lancer dans la lecture de cet article, vous allez constater qu’il y a pas mal de travail. Mais rassurez-vous, vos collègues en auront également beaucoup car des chantiers conséquents sont à paralléliser de la technique :

• Le juridique
• Le commercial
• Les RH
• Le marketing/l’acquisition
• La relation client
• La data
• …

Il y a énormément de problématiques liées à l’intégration d’une marketplace pour ces services, mais nous ne les aborderons pas dans cet article.

Intégration macro de la marketplace dans l’écosystème

La question que l’on nous pose souvent au démarrage d’un projet de marketplace c’est : “mais où s’intègre la marketplace dans mon SI* ?”. Derrière cette question, il y a un besoin préalable de se représenter (de visualiser), même de manière macro, où s’intègre la brique qui va opérer l’intermédiation : qui consomme quels flux, quels applicatifs de mon écosystème e-Commerce vont être impactés, … où est-ce que, moi DSI, je vais souffrir ?

Répondons tout de suite à cette question de manière macro.

* Les solutions de marketplace sont en Saas et ne s’intègrent donc pas réellement à votre SI. Il y a des flux à tirer pour intégrer cette brique applicative dans votre écosystème e-Commerce.

1. AVANT l’intégration de la marketplace :

Vous faites de la Vente En Propre (VEP) sur votre e-Commerce qui est couplé à votre SI.
L’ERP envoie les prix et les stocks à l’e-Commerce.
Le PIM récupère les données produits de base (ref, titre,… quelques attributs..) depuis l’ERP, et l’e-Commerce récupère des données produits enrichies depuis le PIM.
L’ERP récupère les commandes, les données clients.

2. APRÈS l’intégration de la marketplace :

La brique Marketplace permet de récupérer les informations produits des vendeurs.
Les produits de la marketplace sont récupérés dans le PIM.
L’e-Commerce récupère :

• depuis le PIM : vos données produits en propre ET les données produits marketplace (dédoublonnées).
• depuis la MP : les descriptions vendeurs, les offres des vendeurs (prix/stock)

L’ERP continue de récupérer vos commandes en propre, comme avant.
La MP récupère les commandes vendeurs.
L’ERP récupère les informations de facturation des commissions.

Les impacts macro les plus notables :

• Faire une place aux produits des vendeurs dans votre référentiel,
• Pouvoir gérer la notion d’offres sur l’e-Commerce, et de commandes splittées (distinction entre vos commandes en propres et les commandes des vendeurs),
• Descendre les commandes à la marketplace et permettre la gestion de l’après-vente (suivi commande, litiges, retours, messagerie client<>vendeurs),
• Facturer les vendeurs,
• Mettre en place un paiement qui fonctionne sur un modèle marketplace (autorisation, multi-capture, encaissement pour compte de tiers,… nous ferons un billet spécifique sur ce sujet).

Détail des impacts techniques de l’intégration d’une marketplace sur mon e-Commerce

Quand on commence à avoir l’ambition de donner des détails des impacts techniques de l’intégration d’une marketplace en un seul article, on se lance à corps perdu et… on constate rapidement qu’on n’y arrivera pas.
Le sujet est trop vaste même en faisant des impasses. Nous avons tenté l’exercice, mais il est beaucoup plus sage et plus digeste de proposer plusieurs articles pour en faire le tour.

Dans la suite de ce paragraphe, nous faisons donc un teasing de ce qui vous attend dans les prochains articles.
Nous prendrons, comme repère central, le moment où un client visite votre marketplace et passe une commande. Et de cet événement, nous expliquerons ce qu’il doit se passer avant (EN AMONT) pendant (ON SITE : pendant la visite) et après (EN AVAL : l’après vente).

1. EN AMONT

Il s’agira ici d’expliquer l’onboarding technique des marchands et la diffusion de leurs catalogues de produits/offres sur votre e-Commerce.

• Comment ils s’inscrivent ?
• Comment ils poussent leurs produits et leurs offres ?
• Comment les publier sur l’e-Commerce ?

Voir l’article “L’intégration technique d’une marketplace EN AMONT : de l’onboarding vendeur à la diffusion des catalogues”.

2. ON SITE : le back-office e-Commerce

Nous ferons ici le focus sur les transformations nécessaires de votre back-office e-Commerce. Des transformations “légères” mais néanmoins indispensables sur :

• La modélisation de certaines données :
  • Produits
  • Offres
  • Commandes
  • Vendeurs
• Quelques interfaces utilisateurs à mettre en place pour gérer, afficher ou déclencher des actions sur ces données.
• Les flux de données à mettre en place (MMKP <- > PIM <- > e-Commerce)

Voir l’article : “L’intégration technique d’une marketplace ON SITE : adapter le back-office de mon e-Commerce”.  (à venir)

3. ON SITE : le front-office e-Commerce

Pour proposer toute l’expérience marketplace à votre visiteur (par rapport à un site e-Commerce mono-vendeur) vous devez faire des modifications et des ajouts sur le front existant :

• Dans les fiches produits
• Dans les listing produits
• Créer des pages vendeurs
• Adapter le compte client
• Revoir l’UX et la mécanique de tout le tunnel de vente (et l’intégration au PSP).
• Adapter le formulaire de contact général du site

Voir l’article : “L’intégration technique d’une marketplace ON SITE : adapter le front-office de mon e-Commerce”.

4. EN AVAL : l’après-vente

Quand le client valide et paie sa commande, que se passe-t-il ensuite ?
Nous verrons :

• La gestion de l’après-vente entre clients et vendeurs
  • Le cycle de vie de la commande (actions côté vendeur, captures des paiements, remontées de statuts de commandes,…)
  • La déclaration d’un éventuel litige quand la commande se passe mal
  • La messagerie opérateur/vendeur/client
  • La demande de retour et/ou de remboursement
• La gestion de l’après-vente côté opérateur :
  • Déclenchement des cash-out
  • Comptabilité et réconciliation
  • Le service client de niveau 2
  • Le reporting

Voir l’article : “L’intégration technique d’une marketplace EN AVAL : l’après vente”. (à venir)

Des impacts techniques/SI, oui ! Mais des impacts DSI… aussi !

Comme nous parlons de technique dans cet article, nous parlons ici des impacts humains, liés à un projet de marketplace, pour une DSI.
Ces impacts sont de l’ordre du renforcement de l’équipe et de l’accompagnement au changement.

En effet, votre DSI est dimensionnée pour assurer le maintien en condition opérationnelle de vos systèmes et outils, et pour produire une road map.
Lorsqu’un gros projet tel que l’intégration d’une marketplace vient s’intégrer, il faut anticiper de nouvelles ressources pour pouvoir continuer d’assurer les affaires courantes tout en absorbant la charge d’un gros projet, sans devoir déshabiller Pierre pour habiller Paul.

Il faut donc anticiper les nouveaux besoins…

• De nouveaux développeurs (avec des compétences peut-être un peu différentes de ce que vous aviez l’habitude d’onboarder)
• Un pilotage dédié
• Des ressources MOA et MOE dédiées.

… tout en essayant de profiter de l’expérience des ressources en place (ne pas mettre une équipe 100% nouvelle, sans historique dans l’entreprise, bien sûr).

Les changements à accompagner sont aussi au niveau des usages : nouveaux outils (prévoir les formations), nouveaux process (une communication sans failles pour mettre tout le monde au même niveau d’information), nouveaux interlocuteurs (permettre à tout le monde de bien identifier les nouveaux rôles qui prennent part à l’aventure).

Encore une fois, les autres services/métiers de l’entreprise auront les mêmes problématiques que la DSI en termes de besoin de ressources et d’accompagnement au changement.

Des impacts infra/architecture/tiers…

Nous l’avons vu, et nous le verrons encore dans les prochains articles : intégrer un modèle marketplace sur votre e-Commerce va être un gros travail d’adaptations techniques pour couvrir le périmètre fonctionnel que cela demande, et permettre les échanges de données.

Mais une marketplace c’est aussi :

• Plus de trafic
• Plus de données
• Plus d’applications dans l’écosystème
• Plus de flux à monitorer
• Plus d’utilisateurs internes en gestion

Bref !… Plus de volume pour presque tout…

Donc en termes d’architecture, de monitoring, et de dimensionnement des infrastructures il y a un vrai sujet à ne surtout pas négliger.

A noter également : Vos abonnements à des services tiers qui ont un modèle économique au volume (par exemple : un moteur de recherche sur lequel vous indexez quelques milliers de produits en propre), quand vous passerez à plusieurs centaines de milliers de produits marketplace, les coûts vont grimper.

Quelques erreurs à éviter

Lister toutes les erreurs à éviter… Encore faut-il toutes les faire pour pouvoir les identifier.
Dans la plupart des projets que nous avons accompagnés, la maturité et la dimension des équipes de nos clients ont permis des succès.
Il n’en reste pas moins qu’il y a eu aussi des échecs et qu’il y en aura d’autres.
Mais ces échecs ne sont pas forcément dûs à la technique (voire rarement), mais plus à l’organisation, ou aux mauvaises stratégies business.

Quoi qu’il en soit, voici quelques pièges dans lesquels on peut parfois tomber.

1. Les interférences projets

Démarrer un projet d’intégration de marketplace, c’est se poser énormément de questions parallèles sur l’écosystème e-Commerce.

• Est-ce que ce ne serait pas l’occasion de mettre un PIM en place ?
• Quitte à adapter le front, pourquoi ne pas refaire une refonte UX/UI globale ?
• J’ai une vieille solution e-Commerce, pourquoi ne pas replatformer ?
• …

OUI ! C’est 100% légitime de se poser ces questions, et la plupart des projets d’intégration de marketplace sont accompagnés de refontes de certains périmètres dès que c’est pertinent.
Et ça ne pose pas de problèmes lorsque c’est anticipé, staffé, budgété, planifié, dé-risqué au maximum et piloté comme il se doit.

Un des risques quand on aborde la marketplace, c’est que l’on met du temps à bien comprendre l’étendue réelle d’un tel projet, à monter en maturité.
Et que l’avancée dans le projet faisant mûrir, on risque de soulever des problématiques structurantes qui n’avaient pas été identifiées avant le démarrage.
D’où l’importance de s’appuyer sur les éditeurs et les intégrateurs pour prendre un maximum de retours d’expérience en amont et prendre les bonnes décisions et les bonnes directions. D’autres ont déjà essuyé les plâtres, il faut s’en servir.

2. Introduire de la dette technique dès le départ.

Que le DSI qui ne souffre d’aucune dette technique dans son système lève la main !
Cette dette ne se résout pas par magie, et ce n’est pas un nouveau projet d’intégration qui va l’effacer. Cependant, conscients de cette dette, il y a forcément une vision sur la cible à atteindre pour en sortir partiellement ou complètement.

Il est donc impératif que le projet de marketplace s’intègre dans cette vision et soit un moyen, sinon d’accélérer l’atteinte de la cible, surtout pas un accélérateur d’une future dette supplémentaire.

Pour cela :

• Respecter et faire respecter les bonnes pratiques de développement,
• Utiliser les solutions techniques pour ce qu’elles savent faire, (attention à certains détournements de logiciels utilisés à des fins auxquelles ils ne sont pas destinés),
• S’assurer de la cohérence des compétences,
• Documenter et maintenir la documentation,
• Utiliser des technos qui vont dans le sens de l’histoire,
• Eviter le “quick&dirty” provisoire… qui va rester.

3. Ne pas chouchouter vos vendeurs

Vos vendeurs sont vos nouveaux clients. Il faut les chouchouter.
Leur onboarding sur votre marketplace a aussi des impacts humains et techniques chez eux. Il faut tout mettre en place pour les accompagner.
Par exemple dédier une ressource technique au support à l’onboarding technique des marchands (surtout ceux qui s’intègrent directement par API avec leur système).
Sans cette compétence chez vous, opérateur, vous pourriez vous couper de quelques vendeurs.

4. Développer trop de custom

Nous défendons le best-of-breed et le natif des solutions. Mais il est parfois nécessaire d’ajouter des développements spécifiques.

Oui, il est parfois nécessaire d’ajouter des développements.
Juger de cette nécessité vous appartiendra, mais nous avons trop souvent rencontré d’échecs ou de dérives dûs à des développements custom pour “faire plaisir”.

• “Faire plaisir” aux métiers pour éviter un trop gros changement d’usages
• “Faire plaisir” aux marchands pour leur faciliter l’import de leurs produits (notez la contradiction avec le paragraphe précédent 😉
• “Faire plaisir” à la direction pour ….

On ne fait pas de développement pour “faire plaisir” (c’est un peu exagéré comme expression il faut avouer ;). Mais le Go/Nogo pour lancer un développement doit se faire de manière éclairée.
Cela semble être du bon sens. Mais le bon sens n’est pas toujours partagé à parts égales. Ainsi, quand doit se poser la question des développements spécifiques, pour aligner les parties prenantes d’un tel projet dans une même vision du bon sens, penser toujours :

• MVP
  Est-ce que le besoin exprimé doit rentrer dans le périmètre MVP ?
  Voir, décider clairement de sortir les développements spécifiques du MVP pour s’assurer de respecter les délais, le budget, et pouvoir éprouver sa marketplace et ainsi bénéficier d’un retour d’expérience qui validera ou non le besoin.
• Natif des solutions
  Les solutions du marché savent faire de la marketplace. N’essayons pas de les refaire.
  Une solution est maintenue par un éditeur.
  Quid de la maintenance, de la documentation, de la pérennité d’un développement spécifique maison. Une fois que le développeur historique est parti ?
  Est-ce que je ne risque pas d’intégrer de la dette à terme ?

Pour aller plus loin

Encore un peu de patience pour nos 3 prochains articles :

• L’intégration technique d’une marketplace EN AMONT : de l’onboarding vendeur à la diffusion des catalogues
• L’intégration technique d’une marketplace ON SITE : adapter le front-office de mon e-Commerce
• L’intégration technique d’une marketplace EN AVAL : l’après vente (à venir)

Et si vous avez raté le début : Marketplace #1 – Les grands principes d’une marketplace