Archives par mot-clé : Système d’information e-commerce

Assistons nous à un changement d’ère au niveau du e-commerce ?

Je lis ici et là que le e-commerce est en train de changer, de muter.
On passerait sur un mode « industriel » à mettre en opposition du mode des pionniers, des explorateurs.

Alors, c’est vrai, le e-commerce est sur certains points de vue mature. Le fait que des millions de personnes achètent en ligne en est le signe le plus visible, le plus évident. Le e-commerce génère des milliards d’euros de chiffre d’affaires, et on prévoit 1000 milliard € de chiffre d’affaires en 2013 !

Donc, de ce point de vue là, on est effectivement sur un marché mature.

Marché mature qui va poursuivre sa croissance, il suffit de voir les leviers permettant d’assurer la croissance pour les années à venir :

  • Part de marché des gens connectés ;
  • Part de marché des clients, il reste de la marge,
  • Habitudes des clients (nombre de commandes annuelles),
  • Sans parler de l’évolution des usages, avec les mobiles, les tablettes.
  • Largeur de l’offre : 100 000 sites en france, 200 000 en Angleterre….

Donc, même dans un contexte particulièrement tendu, le e-commerce va encore croitre.

Maintenant, on est toujours sur un terrain très mouvant ; les choses évoluent très très vite :

Au niveau technique :

  • Le web évolue toujours très vite, tiré par les innovations proposées par les éditeurs de navigateurs (Google, Microsoft, Apple, Mozilla).
  • Les terminaux pour accéder au web sont également en évolution, dopée aux hormones de croissances, avec la compétition mondiale et féroce que se livrent les grands fabricants : Google, Apple, Amazon, Samsung.
  • Les technologies serveurs : il suffit de voir à quelle vitesse se développe une offre, au niveau mondial, pour bien prendre conscience de l’immaturité des offres. Un bon développeur peut sortir un produit bien fait en quelques mois, et le diffuser au niveau mondial… Sans parler de l’évolution accélérée des socles de développements. Aujourd’hui, on demande aux développeurs de faire à la main le codage de l’ensemble des couches, logique métier, présentation, sans environnement de production au niveau de ce qu’on faisait il y a quelques années… Si on est en régression sur ce sujet, c’est que les choses bougent trop vites.

Au niveau des usages : avec le développement d’acteurs comme Facebook, Pinterest, Twitter, qui, en quelques mois deviennent des acteurs mondiaux et changent les usages des internautes.

Donc, les choses changent vites, tant au niveau technologie qu’au niveau des usages.

Le e-commerce doit donc répondre à une situation paradoxale :

Il s’agit de mettre en place un système d’information e-commerce industriel, capable de :

  • Supporter des gros volumes, des pics de trafics,
  • Gérer un volume important de transactions, de manière fiable et 100% sécurisé
  • Gérer des catalogues complexes, riches
  • Gérer un système d’information e-commerce en lien avec une constellation d’autres briques métiers : gestion des stocks, logistique, transport, relation client, …

Et dans le même temps, ce même système d’information doit être souple, doit permettre des mises à jours faciles et rapides, de manière à suivre les évolutions des usages et techniques.

Ce paradoxe est réellement complexe à gérer. Dans tous les cas, il ne peut pas être traité à la légère il demande de la part des gros acteurs une maturité sur ce qu’est un système d’information e-commerce, maturité qui n’est pas très répandue (architecture SOA, méthodes « réellement » agiles, …)

En fait, je pense que la plupart des boites qui veulent réellement réussir, à long terme, sur le e-commerce, doivent intégrer dans leurs gènes que le système d’information e-commerce n’est pas une charge qu’on subie mais plutôt un actif à construire et cultiver.

Les boites doivent apprendre à gérer et capitaliser sur les équipes techniques : à recruter les meilleurs, les payer à la hauteur de leurs responsabilités, les manager de manière adéquate. La meilleure façon de faire du logiciel, c’est l’hyper responsabilisation de chacun. C’est le contraire du Taylorisme…

Les boites doivent définir une stratégie claire, ou l’on défini ce qu’on fait en interne et ce qu’on externalise. Le SAAS va jouer à l’évidence un rôle clé dans les années à venir…

Bref, il s’agit d’une véritable révolution, qui, parce qu’elle touche à l’humain et à l’ADN des boites, prendra du temps.

Les différents niveaux des interfaces back office

Vous voulez qu’une fonction soit paramétrable, qu’on puisse la modifier, simplement.

Il y a plusieurs niveaux d’interfaces.

Le niveau le plus haut, celui que vous avez sans doute en tête, c’est une vrai interface : une page, avec des champs pour éditer les différents paramètres, et des boutons, pour valider, tester, annuler.

Le deuxième niveau, c’est une interface technique : cela ressemble, mais l’interface n’est pas clean : elle a été faite rapidement, peut être même automatiquement. Elle permet bien de paramétrer la fonction, mais la prise en main de l’interface est moins intuitive.

Le troisième niveau, c’est une interface via un fichier de configuration. Un fichier, XML par exemple, permet de régler des variables. C’est très efficace, mais il faut comprendre la syntaxe du fichier de paramétrage. Pour peu que sa structure soit peu intuitive, et c’est pas si simple que ça.

Le niveau suivant, c’est de modifier le code… Si la fonction est bien codée, c’est pas forcément si compliqué, mais il faut savoir coder.

On a donc quatre niveau d’interface.

C’est important de bien comprendre tout ça, et, a chaque fois qu’on veut que quelque chose soit paramétrable, de se demander quel est le niveau qui doit être défini. Tout n’a pas besoin d’être au niveau le plus haut. Exemple : définir le nombre de produits affichés sur une page liste. Cette contrainte évoluera peu, peut être même jamais. Mettre une telle info dans un fichier de paramètre est sans doute une bonne idée.

La page produit, c’est simple…

Rien de plus simple qu’une page produit !

Pourquoi se « faire des noeuds » pour rien ?

C’est :

  • Un nom de produit
  • Un texte de description
  • Quelques photos

Le produit est rangé quelque part, dans une catégories.

Voilà, fin du débat.

Heu, c’est un peu court…

Un produit peut être déclinable, en taille, en couleur, et en tout un tas d’autres choses (motif par exemple).

A-t-on une fiche produit par déclinaison ou est-ce la même fiche produit pour toutes les déclinaisons ?

Au fait, le stock, c’est pour une déclinaison…

Et puis pendant qu’on y est, le prix, il peut varier en fonction de certains critères.

Ah, ok.

Et c’est pas fini : a-t-on une seule page pour toutes les déclinaisons ?

La question est simple mais pas la réponse.

Cela dépend des cas.

En général, on a bien une seule fiche produit pour la déclinaison en taille. Pourquoi ? Parce qu’il s’agit d’une variable « technique », qui n’a pas de valeur sur les pages listes par exemple.

Mais ce n’est pas forcément le cas pour d’autres critères, comme une déclinaison par couleur. Suivant les cas, il peut être intéressant d’avoir une fiche produit spécifique par couleur, avec une URL et donc un référencement spécifique. Si le client cherche un pull rouge, c’est pas mal que cette page remonte chez google, non ?

Oui mais si on a 30 couleurs de pull, vous imaginez la tête des pages listes, qui vont être remplies de toutes les déclinaisons de couleur ?

Sur cet exemple, on voit bien que cette simple question a des réponses riches, pour un même site.

Et je n’ai pas parlé du moteur de recherche interne au site, qui doit permettre d’aller directement sur la bonne fiche si l’internaute cherche « pull rouge ».

Et si je reviens sur les tailles, on peut aussi bien améiorer l’expérience client, en permettant des filtres sur les tailles dès les pages listes. Exemple : je ne cherche que des chaussures en 43. ça serait pas mal que, quand je clique sur la chaussure qui me plait, j’arrive directement sur la chaussure en 43, non ?

bon, j’arrête là, parce que, normalement, vous avez compris mon idée : une page produit n’est pas simple du tout ! C’est même réellement un « objet » complexe.

Et je n’ai pas parlé de personnalisation, d’attributs variables, de comparaison de produits, …

Bref, le produit, c’est un monde… un monde modélisé d’ailleurs par des logiciels, qu’on appellent des PIM : Product Information Management. Si je devais concevoir un système e-commerce, je commencerais par là ;).

Prestashop optimise la version 1.4 et prépare la suite…

Prestashop vient de sortir une toute dernière version de la solution e-commerce.

Ce n’est pas une release majeure, on sait tous que la prochaine version importante, c’est la 1.5, qui est en préparation…

Cette version semble tout à fait intéressante, en ce sens qu’elle apporterait un gain de performance tout à fait significatif.

Quand on sait l’importance d’avoir des boutiques qui répondent vite, ce graphique donne envie d’essayer, non ?

Voir l’article complet sur le blog de prestashop, avec la liste des améliorations, et pleins d’autres infos, en particulier sur la procédure pour migrer vers cette version.

RentAShop, pour des boutiques SAAS sur mesure

RentAShop est une solution SAAS, pour mettre en ligne une boutique e-commerce, qui existe depuis 2005.

C’est une solution de qualité, avec a peu près 220 références.

Les boutiques sont plutôt bien faites.

Pour François Huet, le patron « rock » de RentAShop, la qualité est vraiment un axe clé. Il est très attentif, par exemple, à ce que les boutiques tournent sur l’ensemble des navigateurs Internet. Cela peut paraître une évidence, mais pourtant, ce n’est pas toujours le cas…

Deux exemples de boutiques :

Sympa la présentation des produits, avec des tailles différentes, non ?

Autre exemple :

Le jeu des couleurs, la charte est bien sympa.

RentAShop évolue : l’expérience acquise permet de mieux comprendre les attentes du marché :

Bref, RentAShop est une bonne solution pour se lancer dans le e-commerce, avec un investissement maîtrisé, et donc du budget pour les autres postes clés : le stock et le e-maketing.

Bonne continuation à RentAShop !

 

Architecture du système d’information e-commerce – 2

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.

 

De l’importance de bien utiliser une solution e-commerce

Vous avez de grandes ambitions, et vous souhaitez refaire votre site e-commerce.

Vous avez fait (ou fait faire) un cahier des charges.

Vous avez choisi une solution open source (prestashop ou magento) et vous avez sélectionné une bonne agence, qui va faire les développements.

Quelques mois plus tard, le nouveau site est en ligne.

Bien sûr, tout n’a pas été facile : certaines fonctions qui étaient dans le cahier des charge n’ont pas été développées. Le planning a dérapé, …

Mais bon, globalement, le nouveau site est là, et vous êtes plutôt content d’avoir un nouvel outil, qui va vous permettre de décrocher la lune.

Rapidement, vous déchantez. On vous avait vanté les mérites de la solution open source choisie, la richesse fonctionnelle, les milliers de modules, la communauté.

Votre sentiment est d’être coupé de tout ça !

Pourquoi ?

Parce qu’a chaque fois que vous voulez ajouter une fonction, qui normalement s’active d’un simple clic depuis le back office, votre site est tout cassé.

Ou alors vous installez un module, et le résultat est le même : au mieux, le module ne fonctionne pas. Au pire, il casse le site.

Pourquoi tant de haine ?

La raison est simple : l’agence qui vous a développé votre boutique n’a pas respecté les standards de la solution. Au lieu de faire des développements sous forme de modules, de respecter l’architecture de la solution, ils ont « tapé dans le dur » et modifié directement le code du coeur de la solution.

Le résultat est que la boutique fonctionne… Mais que plus rien n’est évolutif. Vous devez faire développer toute évolution.

Moralité : il est super important de bien valider que la boutique que vous développez respecte les choix d’architecture de la solution retenue.

Hybris propose une place de marché de composants e-commerce – De l’avenir des solutions e-commerce

Hybris vient d’annoncer l’ouverture de leur place de marché, hybris-extend

C’est une super idée !

Pour faire modeste et simple, j’ai même eu le projet de monter une startup sur cette idée…

L’idée, c’est de dire qu’un seul acteur ne peut pas proposer une solution universelle, qui fait tout.

Donc, au lieu de vouloir tout faire, et le faire forcément moyennement partout, on propose des API avec une place de marché, et des acteurs spécialisés proposent leurs solutions, branchées sur les API.

C’est donc ce que propose Hybris.

C’est également l’approche de X.com, la plate forme e-commerce d’eBay.

C’est clairement l’avenir !

Architecture du système d’information e-commerce

Je vous propose plusieurs billets, sur l’architecture du système e-commerce.

D’abord, de quoi parle-t-on ?

Quand on lance le e-commerce, à la mode « garage », le système d’information est réduit à sa plus simple expression : on prend une solution SAAS type Oxatis, Rentashop, Wizishop, … et c’est tout.

La solution est composé, nativement, d’un front office : la boutique e-commerce.

Pour piloter l’activité, la solution propose un accès back office.
Ce back office permet de consulter ou modifier l’ensemble des données du site :

  • Catalogue : On peut modifier l’arborescence du catalogue, et mettre à jour les produits.
  • Client : On a accès à la base des clients, qui se sont inscrits sur le site.
  • Commande : On peut consulter les commandes passées par les clients, et les traiter.

Alors, heureux 😉 ?

Pourquoi parler d’un système d’information, quand on a tout sous la main dans une seule solution ?

En fait, même à ce stade, on peut déjà parler de système d’information e-commerce, avec différentes briques : vous avez nécessairement une compta, vous travaillez peut être avec un logisticien qui utilise un WMS et TMS, vous expédiez vos coli via un transporteur qui propose un logiciel, … Bref, vous avez de fait plusieurs briques. Simplement, elles ne sont pas inter connectés.

Encore une fois, pour se lancer, c’est une très bonne approche, pas de problème avec ça.

Les questions se posent soit quand on veut aller plus loin, soit quand le volume de commande dépasse un certain volume, soit si on est au sein d’une entreprise et qu’on doit synchroniser le système e-commerce avec le système d’information de l’entreprise.

Exemple : on veut réduire la charge lié à la comptabilité.

Avec notre premier système, composé d’une seule solution, on doit reporter à la main les commandes dans la comptabilité.
Quand on a 20 commandes par mois, la charge est raisonnable. A 200, c’est déjà une autre histoire.

On va donc développer une connexion entre le moteur e-commerce, et un module comptable.
On pourra ainsi charger automatiquement les commandes passées, du e-commerce vers la comptabilité.

Bien sûr, la charge comptable ne sera pas pour autant réduite à 0 : il restera toujours quelques opérations à entrer à la main, en particulier sur les cas « hors norme » : retour d’un produit, colis perdu, …

Là dessus, mon conseil est de partir sur des automatisations partielles.

Vouloir tout automatiser n’est en général pas une bonne idée : ça coûte cher, et ce n’est pas utile.
Ce qu’il faut, c’est automatiser les éléments les plus courants. Les cas limites doivent pouvoir être traités à la main.

Dans l’exemple du e-commerce et de la compta, on traitera donc à la main, dans la compta, les cas limites.

La suite au prochain épisode 😉