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 😉
J’aime beaucoup ta manière d’expliquer simplement des concepts qui sont assez simples dans la description mais souvent compliqués dans la réalisation. Assez souvent l’informatique dans les petites structures est perçu comme un cout direct et non comme un investissement pour de futures économie sur le SI. Merci pour l’éclairage apporté !
@Nicolas> Merci pour ce commentaire sympathique 🙂
Lorsque l’on discute automatisation des tâches, nous devons appliquer le concept général du coût/bénéfice. Si l’activité à automatiser reste peu gourmande en temps, inutile de l’automatiser et inversement.
Cet article est clair et bien structuré, il reste assez en surface pour ne pas nous faire plonger dans les détails mais permet d’aborder ce sujet assez rebutant à priori pour les petits e-commerces. Merci.
On parlant de l’informatisation complète des systèmes d’e-commerce, on peut donner exemple d’Amazon. Le numéro un mondial du commerce en ligne qui ‘a déjà informatisé une grande partie de ses procédures (et il semble que ça fonctionne très bien). Il expérimente même un système de livraison informatisé (via des drones) pour minimiser les risques d’erreurs humaines, et comme vous l’avez mentionné les charges de comptabilité.