Voici donc la suite de ce billet, ou l’on parle donc de l’architecture du système d’information.
Vous avez donc un moteur e-commerce en place.
Vous avez créé un lien vers une solution de comptabilité, qui permet d’automatiser la descente des commandes dans la compta.
La question intéressante, c’est la gestion des clients :
La moteur e-commerce propose bien sûr une base client.
En fait, on gère plusieurs choses très différentes associées aux clients :
- Le compte utilisateur, utilisé pour se connecté sur le site et pour effectuer des achats
- L’abonnement à (aux) news letters
- La liste des commandes passées par le client
- L’historique associé au site : liste des visites, produits et catégories visitées, liste des paniers, des recherches…
- Les emails envoyés, liés au traitement des commandes (ce qu’on appelle souvent les emails transactionnels)
- Les emails marketing envoyés (newsletter, relance suite à abandon de panier, …)
- Les échanges avec le client, suite à un appel de sa part ou suite à un problème. Cela peut être en avant vente, ou en après vente. Ces échanges peuvent se faire sur différents suport : téléphone, chat, mail. Un échange peut mixer différents support (le client appelle, on lui répond par mail, …)
- Les éléments liés à la fidélité : carte, points accumulés, …
- Les éléments liés à des opérations commerciales : bons de réductions, …
Et pour les entreprises multi canal, on doit gérer des informations liés à chaque canaux.
Comme je le disais, la brique e-commerce gère une partie de ces informations, mais pas toutes, et la brique e-commerce ne couvre pas tous ces besoins.
Si on « laisse aller les choses », on va avancer par petites touches sur tous ces sujets, sans avoir un référentiel client : un endroit ou stocker toutes les informations associées au client.
On va donc rapidement se retrouver avec un système composé de briques hétérogènes, sans cohérences les unes avec les autres.
Une première solution peut consister à enrichir la solution e-commerce avec des éléments CRM.
Malheureusement, cette solution n’est pas très réaliste, dès que les enjeux deviennent un peu important.
On doit donc aller rapidement vers une architecture ou on a au moins deux briques : une brique e-commerce et une brique CRM.
Déjà, si on arrive à tout couvrir avec seulement deux composants, c’est très bien.
Ce n’est pas si facile parce qu’il n’y a pas, aujourd’hui, de solution CRM qui couvre bien tous les sujets.
On doit donc partir de solutions existantes, et les adaptés au contexte du e-commerce.
Dans cette configuration, on aura toujours 2 bases clients : celle de la solution e-commerce et celle de la solution CRM.
Il faut donc bien définir les flux d’échanges entre ces solutions, de manière a garder la plus grande cohérence entre ces système.
Il faut éviter, en particulier, de dupliquer toutes les données. Pourquoi ? Parce que si on duplique toutes les données, il faudra constamment tout synchroniser, pour que les données restent à jour.
On doit donc chercher un juste milieu, certaines données sont copiées, et d’autres non.
Niveau métier, il faudra travailler avec plusieurs back offices. Si on a les moyens, on peut également développer des passerelles « profondes » entre les solutions : je suis sur une commande, sur la solution e-commerce, et d’un clic, j’arrive sur la fiche du client qui a passé cette commande, dans le système CRM.
Ce que tu nommes « brique » eCommerce mériterait pour cette seule appellation, une définition, ou au moins la couverture fonctionnelle de cette dernière. En effet tu mentionnes dans ce billet, l’intégration avec un outil de gestion Client après ou en parallèle d’une intégration avec un ERP – et j’étends volontairement la notion de comptabilité à celle d’ERP, plus large. Toutefois d’autres « briques » peuvent se révéler intéressantes, je pense par exemple à l’OMS (Gestion des commandes), regroupement, planification des livraisons, gestions des stocks intermédiaires pour regroupement, …,
Je pense à un CMS (Outils de gestion des contenus, contenus qui ne sont pas « simplement » les descriptions courtes et longues des produits associées qql images, je parle ici des contenus à forte valeur ajoutée, des guides d’achats, des notices d’utilisations, des vidéos, des messages promotionnels, des annonces de nouveautés, et tant d’autres choses,
Je pense à la « brique » recherche, qui jamais, jamais ne doit retourner « pas de résultats »
Je pense à la « brique » Supply Chain (gestion de la logistique) qui diffère de celle OMS
Je pense à la « brique » PIM (Gestion des produits) avant mise en catalogue ….
Aujourd’hui, impossible d’échapper à une intégration FB autre que « j’aime » « j’aime pas », il faut être capable d’intégrer l’API FB (le fameux graphe social), …
Bref le eCommerce de par sa dimension, est obligatoirement au carrefour de plusieurs « briques ». Outre le choix d’une architecture ouverte ET évolutive, se pose la question du recouvrement de chacune de ces briques avec sa voisine.
Choix cornélien, s’il en est, c’est la pierre angulaire d’un système d’information performant. Car la performance du site eCommerce est le reflet de la performance de l’entreprise …
Et ça beaucoup ne l’ont pas compris.
Et un genre à Octave.biz qui apparemment saurait « tout faire » ça m’a l’air bien intéressant mais il faudrait approfondir l’étude.
Je n’ai jamais trouve de retour d’expérience les concernant
Des « qui savent tout faire » j’en connais des tas … 🙂
Malheureusement vu la complexité si on veut être honnête, il faut la jouer « modeste », « tout faire » c’est possible, mais ca va dépendre du périmètre, de la taille du projet, de son ambition, des moyens dont on dispose,
Je sais ca fait un peu « consultant » mais c’est hélas la vérité. De très grands groupes se plantent sur des projets d’intégration eCommerce d’envergure (je pourrais écrire un roman sur le sujet), la prudence est donc de rigueur, et sans que cela discrédite la société des frères Perrinet (que je ne connais pas).
Comme cela a souvent été dit ici (Merci François) il n’y a pas de réponse absolue, Blanc/Noir, BON/Mauvais, tout est question de périmètre, d’ambition, de croissance, de l’existant, … bref une pré-étude, par un bon consultant intégre, non lié à telle où telle solution (j’en connais, je participe à son blog – 🙂 ), est une premiere étape qui peut éviter bien des déboires.
Appellons ca cadrage ou Business Value Assessment ou n’importe quoi d’autre mais le résultat doit être un plan de marche clair, qui met en lumière les points d’intégration, les risques liés à tel où tel choix technique/technologique, les coûts associés et bien evidemment les projections en terme d’évolution (business, produits, contenus, croissance de traffic, etc.)
Avec cette carte, il peut y avoir des suprises (il y en a toujours), mais on sait immédiatement lorsque l’on s’écarte du chemin tracé et ce quelqu’en soit les raisons car 1 projet est « vivant », il doit donc aussi évoluer en fonction de son contexte économique/technique/…, sans que cela n’amène une totale remise en cause.
Flexibilité, agilité, réactivité, évolutivité sont autant de mots – certes un peu éculés – pour lesquels avoir des critéres mesurables me semble plus que recommendable, je dirais vivement conseillé …
Mais il y a tant à dire … l’essentiel en fin de compte c’est de se lancer, apres une bonne analyse de risque. Par exemple l’approche US est de ce point de vue, très interessante. Un premier site est ouvert apres une analyse précise du marché, des risques et de la stratégie de la boite. Apres 1 an ou 2, les dirigeants de manière pragmatique, n’hésitent que rarement à jeter ce qui a marché, pour repartir sur une autre solution, plus en phase avec la situation dans laquelle ils se trouvent. J’ai toujours été impressionné par cette manière de faire du business. Il y a de manière sous-jacente une notion de rendement de la solution, des lors que la solution est amortie et que son évolution fini prend des allures « d’usine à gaz toxiques », ils jettent sans état d’ame, et reconstruisent.
J’ai peu vu ca en France, on est plus à vouloir le beurre, l’argent du beurre, et consort, et s’arcbouter sur un truc de bric et de broc qui fini par être un frein au développement du business. Question de culture … peut être
Merci Jean Michel : je ne savais pas par quel bout répondre 😉