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.
