Stoneageblog.com

Second article sur le thème de la migration oscommerce vers magento, je vais aborder ici la gestion des commandes.

Magento propose un back office très puissant et très souple : la boutique est entièrement paramétrable. Cependant cela ne doit pas vous dédouaner d’y apporter une attention particulière lors de votre projet de migration… En effet sa modularité et son aspect « je peux tout faire avec » risque de vous donner un sentiment de confiance un peu trop prononcé. Vous y accorderez alors moins d’importance que ce que vous auriez fait avec tout autre outil : Erreur !

Une petite démonstration pour prouver ce que je dis : chaque jour votre service client valide 300 commandes* sur votre boutique en 4 heures (validation le matin pour expé dans la journée), vous savez qu’il vous faut entre 1′30 et 2min par commande, vous avez donc besoin de 2 personnes pour faire le travail. Imaginez maintenant qu’après votre migration magento, ce n’est plus 2min qu’il vous faut pour valider une commande mais 3… Et bien le premier jour, ça va râler en service client (normal !), le deuxième jour pareil, le 3ème jour ce sont les premières réclamations ($) pour délais de traitement, le 4ème vous lancez des développements ($$) pour améliorer l’interface de validation et le 5ème vous embauchez une nouvelle personne ($$$) pour palier aux différents problèmes…

… Alors, comment faire pour ne pas rater la migration magento d’un point de vue gestion de commandes ?

* Disclaimer : Je me demande si je vais devoir en faire un à chaque article, mais bon mieux vaut prévenir que guérir : je parle d’expérience vécue c’est certain, cependant pour des raisons professionnelles je ne peux parler de chiffres et de volumes réels. Volontairement, je prendrais donc des échelles différentes selon les exemples, tout en m’efforçant de rester cohérent.

Avant de continuer, voici un petit rappel du sommaire général de la série d’article sur la migration oscommerce magento :

1. Qu’est ce que je fais de mes clients ? (Migration des données)
2. Vous êtes ici -> Ok, les clients c’est fait, et mon service client ? (Gestion des commandes)
3. J’ai toutes mes données, maintenant je peux repeindre les murs ? (Réalisation du front office)
4. Ah bon… il fallait aussi que la boutique soit connectée à mon outil d’emailing ? (Intégration des outils tiers)
5. Petit développeur, s’il te plaît, dessine-moi un mouton magento… (Choix de prestataires, dimensionnement de l’équipe, montée en compétence)
6. Bonjour Monsieur Dell, vous me mettrez 2 douzaines de processeurs, 48Go de ram, un loadbalancer et quelques To de disques… (Architecture et dimensionnement de l’hébergement)
7. Euh… on m’avait dit que Magento c’était génial pour le réf nat mais depuis qu’on a migré on a disparu de google ! (Problématiques SEO lors d’une migration : l’importance des redirections 301)
8. Allo Huston, le site est en ligne mais on a plus de commandes… WTF ? (Les moyens de suivi et d’analyse des problèmes éventuels : comment réagir vite et bien !)
9. Le CA du jour ? Ah.. euh… non on a pas prévu de reporting… attendez je vais demander au développeur de nous faire une requête SQL… (Importance du reporting et mise en place d’outils adéquats)
10. Boss, je lance une refonte complète du S.I., ça va prendre 2 ans, coûter beaucoup d’argent et en plus je vais avoir du mal à gérer d’autres projets… (Comment concilier un projet de migration, de l’amélioration continue et des sorties de nouveaux sites : tâche difficile mais nécessaire.)
11. Grr… toujours pas de titre pour cette partie !

Au passage pour les « détracteurs » et/ou inquiets du premier article (et pour ma motivation personnelle ) : Yeah ! déjà 20% du travail accompli et une augmentation de 100% du nombre de posts sur mon blog cette année !

2. La gestion des commandes

Si vous envisagez un projet de migration aujourd’hui c’est que votre business est en croissance (sinon ne migrez pas ! l’investissement est lourd et il est peu probable qu’un changement de boutique entraine une hausse des commandes, mais bon ça c’est mon avis !)

Cette croissance vous a donc amené à réfléchir à vos process, aux différentes étapes qui permettront entre autre que vos colis soient expédiés dans les meilleures conditions. Ainsi, après quelques mois années de travail sur Oscommerce, vous avez probablement définis un ensemble de statuts de commandes bien particuliers à votre métier et quelques facilitées de validation (n’est il pas pratique au moment de cette validation d’avoir sous les yeux un historique des dernières commandes du client ?) Bref, il y a déjà tout un ensemble de choses que vous avez mises en place historiquement et qui sont importantes dans le travail au quotidien, ne les oubliez pas au moment de la migration sous prétexte que vous changez complètement d’outil !

2.1 Les spécificités de votre métier (votre workflow)

Allez let’s go ! Comme pour chaque partie du projet on va commencer par analyser l’existant : énumérez donc les différents statuts de votre boutique oscommerce et pour chacun listez les actions possibles :

1. En attente de paiement :
   1. Saisir l’arrivée d’un paiement offline (chèque, virement)
   2. Annuler la commande
   3. Relancer le client sur le paiement
   4. Changer la commande de statut
   5. Modifiez le contenu de la commande
   6. etc…
2. En attente de validation (paiement OK)
   1. Vérifier la cohérence de la commande
   2. Vérifiez la qualité des photos et des textes saisis dans les produits personnalisés (spécifique à notre métier)
   3. Valider la commande
   4. Demander au client de retoucher sa commande si problème
3. …

Faites en de même pour chacun des différents statuts de votre boutique, vous aurez ainsi devant les yeux une bonne cartographie de votre fonctionnement actuel, soyez plus détaillé que moi ci-dessus évidement. Je pense que pour chacun des status on doit pouvoir trouver une bonne quinzaine d’actions différentes ! Au passage, si vous cherchez un outil pour faire ce travail à votre place, je ne saurais trop vous conseiller le bon vieux bloc note … et Xmind un outil de mind mapping assez efficace :

Ce boulot fait, vous voilà prêt à réfléchir à l’intégration de tout cela dans votre future boutique magento…

2.2 Les objectifs de votre migration (piqûre de rappel !)

Mais attention ! Autant que faire se peut, essayez d’identifier les points noirs de votre fonctionnement actuel, un projet de migration c’est aussi (et surtout) l’occasion de clarifier certains process et d’en optimiser d’autres.

Rappelez vous maintenant pourquoi vous entamez ce projet de migration : outre les différentes problématiques marketing et développement que vous avez avec votre vieille boutique, vous avez probablement atteint une taille critique. Il est donc temps de passer d’un système « artisanal » à une organisation plus « industrielle » et pour cela il va falloir mettre en place des process clairs et rigoureux sans quoi vous ne pourrez pas passer au niveau supérieur (Level up !).

Mais tout cela ne se fera pas tout seul… et encore moins en « imposant » un nouvel outil à une équipe en place depuis déjà quelques années avec un outil certes vieux mais qui (qu’on le veille ou non !) fonctionne bien et fait tout plein de commandes

2.3 Intégrez votre service client au projet !

On reprends donc notre analyse de l’existant (vous savez, tous nos statuts et leurs actions possibles) et on va la confronter au quotidien du travail du service client… Inutile de vous dire que votre joli dessin va très vite ressembler à une belle toile d’araignée… et vous découvrirez très probablement certains fonctionnements que vous ignoriez jusqu’alors !

Le mind mapping, c’est bien, mais dès qu’on commence à parler d’organisation et donc de workflow, il est préférable de modéliser l’enchainement des étapes… Avec votre service client, vous allez donc commencer une nouveau travail après avoir terminé la cartographie de vos process : la modélisation de chacun des process dans le temps.

L’idée ici, c’est de prendre de façon unitaire chaque action du service client et la décomposer en étapes simples et logiques. Il y a plusieurs moyens de modéliser cela mais l’une des plus efficace est le diagramme état-transition de la méthode UML (j’imagine que certains lui préfèrerons le MOT de le méthode MERISE mais il est moins adapté à la modélisation applicative.)

Voici ce que cela peut donner avec la modélisation de l’arrivée d’un paiement offline (chèque par exemple) :

Au passage ce schéma rapide a été fait grâce à Gliffy sans même avoir eu à créer un compte

2.4 Le workflow magento

Quelques jours semaines après avoir commencé vos premiers diagrammes vous aurez enfin une vue claire (ou du moins la plus claire possible ^^) du fonctionnement de votre service client. En plus, vous aurez appris plein de choses sur les habitudes (bonnes ou mauvaises d’ailleurs) des personnes qui travaillent au sein de ce service ! C’est très bien, cela à du vous donner des dizaines d’idées d’optimisation pour le futur !

Très probablement d’ailleurs c’est directement le service client qui vous parlera des améliorations possible, écoutez le attentivement et n’oubliez pas que vous êtes sur le point de lui changer complètement ses habitudes. Si vous pouvez par la même occasion résoudre certains de ses soucis c’est un gros point positif (et une adhésion supplémentaire au projet…) !

2.4.1 Ne cassez pas tout !

Mais attendez un peu, vous n’en êtes pas encore à l’interface… Commencez d’abord par vous documenter un maximum sur le fonctionnement « par défaut » de Magento. L’idée est de faire rentrer l’ensemble de vos process dans ce fonctionnement « par défaut » (dans la mesure du possible…).

Pourquoi ? Parce que faire du développement spécifique c’est jamais bon si on peut l’éviter ! Si vous n’avez pas une bonne connaissance de ce backoffice Magento, vous risquez de lancer des développements inutiles car déjà présents dans le coeur de la boutique ! (encore une fois, je vous parle d’expérience vécue… c’est très facile de considérer un process maison comme spécifique alors qu’il peut très bien être généralisé en prenant un peu de recul)

Vous avez vos process, vous connaissez maintenant par coeur Magento, vous devez donc avoir réussi à faire rentrer à peu près tous vos anciens process dans les nouveaux, du moins dans votre tête De ce côté là il ne vous reste plus qu’à coucher tout par écrit pour ne pas l’oublier ! C’est très bien, en effet, tout ce que vous avez pu faire entrer dans le process par défaut sera en moins en développement et donc en moins en soucis potentiels !

Ce travail est aussi important vis à vis de la migration des donnée abordée en étape 1, en effet il va vous donner les parallèles entre les statuts de commandes Oscommerce et les statuts Magento, ce sera important de bien mapper les informations pour que vos anciennes commandes restent cohérentes dans le nouveau système.

2.4.1 Modifiez proprement

Oui mais voilà, si vous êtes comme nous et que le tunnel de commande n’est pas tout à fait classique (par exemple de notre côté chaque produit nécessite une personnalisation) alors vous aurez surement des interventions à faire sur le workflow magento par défaut !

C’est en tout cas notre cas, chez nous le service client doit valider la création faite par le client : correction de fautes d’orthographes, validation de la qualité de la photo, vérification des marges d’impressions, etc… (pour ceux qui se posent la question : oui, c’est du boulot ! mais c’est aussi ce qui fait qu’on est bon et quitte à faire de la pub je vais même caler un backlink pour le meilleur service client du faire part de naissance personnalisé )

Il vous faudra alors vous entourer d’une équipe de personnes (cf partie 5 !) connaissant magento sur le bout des doigts, en d’autres termes il vous faut trouver « ze développeur » qui sache étendre magento sans casser son architecture : c’est primordial, il faut impérativement que vos développements lourds passent par des modules, cela préservera ainsi au maximum la capacité de magento à évoluer de version en version.

Vous pourrez ainsi envisager de modifier le fonctionnement de magento sans prendre de trop gros risques et ainsi ajouter des fonctionnalités supplémentaire au workflow par défaut.

2.5 Soignez votre interface de validation de commande

Nous appelons chez nous l’interface de validation de commande, la page qui permet de valider une commande afin qu’elle soit traitée. Il vous faut y accorder une importance particulière : rappelez vous l’exemple en introduction. _(on valide 3000 commandes par jour, à raison de 300km à l’heure ce qui nous donne environ 4 salarié/kilo de colis expédié : si j’augmente le poids du papier alors je serais obligé de délocaliser mon service client en Inde… ^^ )

Ça parait anodin peut être comme réflexion mais je vous garanti que si votre service client a déjà des habitudes de fonctionnement avec Oscommerce, il est important de vérifier qu’elles ne seront pas complètement perdues après la migration. Chacune de ces habitudes (si elle est justifiée) doit pouvoir trouver une alternative dans l’environnement magento. A nouveau je vous parle d’une expérience vécue et si certains collègues du service client passent par là ils pourront vous confirmez que c’était une erreur de pas assez faire attention à leurs attentes ! (hein Carole ) Heureusement, comme chaque erreur, cela se corrige… mais cela à un coût et croyez moi à nouveau, ce coût là est plus important à postériori qu’à priori…

Nous avons donc dû adapter l’interface de validation de commande Magento afin qu’elle permette une validation rapide. L’idée était de présenter sur une même page l’ensemble des informations à vérifier et l’ensemble des actions possibles. Par exemple si nous devons faire un geste commercial vis à vis d’un client, ce serait une perte de temps d’aller sur sa fiche client, vérifier son historique pour savoir si nous devons lui offrir une commande complètement ou plutôt un bon de réduction, nous avons donc tout intérêt à lui présenter cette information dès le premier écran… Ce n’est qu’un exemple parmi d’autre mais de manière générale, souciez vous de chaque action que vous faites au moment de valider une commande sur oscommerce et assurez-vous que vous aurez un accès facile à cet action sur votre future boutique.

Quand on parle de refonte, on pense trop souvent à l’ergonomie de notre site (y’a qu’à voir en ce moment la twittosphère ecommerce tremble à la question de savoir si le bouton ajouter au panier est mieux à droite ou à gauche !) et malheureusement pas assez à l’ergonomie applicative pour les utilisateurs quotidien de l’outil. C’est en tout cas un chose qui revient peu souvent dans les différents comparatifs de solutions ecommerce que l’on trouve sur le web…

2.6 La vision projet de cette phase.

La migration de votre process de commande est aussi une partie critique du projet, moins consommatrice de temps et donc d’argent en général que la gestion de la migration, elle est tout aussi importante car elle va définir votre futur fonctionnement sur la boutique (en d’autre terme comment vous aller travailler demain !). C’est donc le bon moment pour envisager des optimisations sur certains process que vous n’aviez pas forcément bien définis avec oscommerce !

Si vous rentrez dans les process magento par défaut, cette phase là sera certe longue en analyse mais moins coûteuse que ce qu’à pu être la migration des données. Le travail d’ergonomie sur l’interface de validation est un travail nécessaire mais peu couteux, en effet il s’agit principalement d’organiser l’information à l’écran de manière efficace.

Enfin, si vous avez besoin de modifier le « core » magento pour l’adapter à vos process spécifiques (développement de modules) les coûts de développement peuvent vite devenir importants selon la complexité de votre métier (… et ce magento n’est pas à la porté du premier développeur venu, j’en sais quelque chose… j’ai bossé longtemps avec oscommerce )

Allez, je termine cet article la dessus, au prochain épisode je vous la jouerai « M6déco style » et on se demandera si les murs de la boutique sont mieux en 1024 ou en 800px