Archives de BLOG E-COMMERCE de François Ziserman, Consultant e-commerce

déc 14

Coeur de métier – Suite

sous , , , | Pas de réponses

Suite de mes réflexions sur le cœur de métier.

Pour le e-commerce, cette question peut prendre plusieurs directions.

Pour une entreprise qui vend des produits ou des services et qui souhaite se développer sur le e-commerce, doit elle le faire ou le faire faire ? C’est bien une question de « cœur de métier ».

Et pour répondre à cette question, il faut analyser sur plusieurs axes :

  • Ai-je les ressources en interne pour monter cette nouvelle activité ?
  • Si je n’ai pas ces ressources, aurai-je les moyens de les recruter ?
  • Le projet sera-t-il compatible avec mon organisation actuelle ?
  • Sinon, aurai-je les moyens de faire évoluer cette organisation assez rapidement ?
  • Qui est le sponsor du projet ? Pour porter le projet en interne, il est important que ce sponsor soit au plus haut niveau.
  • Quels sont les enjeux pour ce projet ? Est-ce un projet stratégique ?

Mais on peut également se poser cette question, du cœur de métier, dans d’autres situations.

Exemple : vous avez développé un site e-commerce.

Le développement de ce site a nécessité le développement de briques logicielles métiers.

Cela peut paraitre tentant que de mettre ces briques sur le marché.

Oui, tentant, mais est-ce une vrai bonne idée ou le début d’une future « galère » ?

  • Vendre du logiciel, ce n’est pas du tout la même chose que vendre en ligne des produits ;
  • Si les briques logiciels ont été développés sans réel volonté de les revendre, le « packaging » de ces « lignes de codes » en un produit risque d’être assez douloureux ;

Au final, ce n’est pas parce qu’Amazon y arrive que c’est une bonne idée.

Enfin, dernier exemple autour de cette question : vous vendez en ligne, et vous vous dites que c’est une bonne idée que d’ouvrir des points de ventes physiques.

On est bien, de nouveau, en face d’une vrai question stratégique. Le changement de canal de vente change l’analyse (pas les mêmes concurrents, pas les mêmes règles marketing).

déc 13

Cœur de métier !

sous , , | 9 réponses

C’est une question qui me fascine, et que j’ai déjà du traiter plusieurs fois.

On dit souvent que pour réussir, il faut rester centré sur son cœur de métier.

Mais c’est quoi son cœur de métier ?

Et puis, quand les choses évoluent, le coeur de métier se doit dévoluer…

Ainsi, si votre cœur de métier était, il y a 15 ans, la photo argentique, j’espère pour vous que vous avez su prendre le virage du numérique…

Prenons d’autres exemples :

Quel est le cœur de métier d’Amazon ?

Ils ont démarrés par la vente de livres en ligne.

Ils ont ensuite ajouté tout un tas de rayons.

Ils ont ouvert les rayons à d’autres marchands avec la mise en place d’une place de marché.

Ils fabriquent et vendent le Kindle.

Ils vendent tout un tas de services, briques de bases de services en ligne.

Alors, c’est quoi le cœur de métier d’Amazon ?

Autre acteur : IBM.

Son cœur de métier était la fabrication de gros ordinateurs.

En pleine crise, ils ont effectués un virage à 180°, pour qu’aujourd’hui une bonne part des revenus soient issues des services.

Et Apple ?

Son métier était de fabriquer et de vendre des ordinateurs.

Quelle fantastique évolution ces dernières années !

Apple est devenu en quelques années le leader des baladeurs, puis c’est mis en tête de révolutionner le monde de la mobilité avec l’iPhone…

Aujourd’hui, si on vous demandais, comment positionneriez vous le cœur de métier d’Apple ?

Dans cette réflexion, je me dis que finalement, le coeur de métier est une notion a manipuler avec précaution.

Oui, il faut bien créer une idéntité de boite, et donner du sens… Mais on est dans un monde qui bouge très vite. Cette identité doit suivre le rythme.

Et sur la diversification des activités, il faut analyser en détail avant de se faire une idée sur la pertinence de la démarche.

déc 10

La fin de Symbian ?

sous , , | 2 réponses

Symbian est un OS pour mobile.

A l’origine, cet OS avait été développé par Psion, pour ces PDA.

Il avait comme caractéristique d’avoir de « bon fondamentaux » : multi tâche, 32 bit (au moment de sa création, c’était un choix ambitieux…)

Ce système, et l’équipe qui le porte, a été pas mal chahuté, entre Psion, puis un consortium de constructeur, avant que Nokia en prenne le contrôle.

Tout ces milliard de $ (plus de 6 je dirais), pour que Nokia le laisse tomber ?

On n’en est pas encore là, mais bon, le dernier né de chez Nokia tourne sur un Linux : le Nokia N900.

Cela montre a quel point il est difficile de maintenir un bon OS.

Un OS, c’est un logiciel, juste un petit peu plus compliqué qu’un autre.

Que faut il pour bien développer un logiciel ?

Une culture logicielle (merci, intéressant comme remarque).

Non mais c’est vrai : cela à l’air de  rien, mais une culture logicielle, cela ne court pas les rues.

Cela veut dire qu’on a une vrai notion de road map, une vision clair du cap, et surtout un vrai processus produit, pour décider ce qui est du domaine du coeur et ce qui est périphérique.

Quand on ne fait pas ça, le « machin » pousse dans tous les sens, et devient vite un monstre, non contrôlable (trop complexe, trop lent, trop moche, …

déc 09

Android versus iPhone : ou le vrai intérêt d’avoir un parc avec (presque) un seul modèle

sous , , , , , | 4 réponses

Android versus iPhone : ou le vrai intérêt d’avoir un parc avec (presque) un seul modèle

La grande force de l’iPhone, c’est l’extrême homogénéité du parc.
Depuis le lancement de l’iPhone, tous les téléphones Apple ont finalement pratiquement la même forme, exactement le même écran, et juste quelques fonctions en plus pour le GS (3G, GPS et boussole).

On ne peut pas dire la même chose côté Androïd :
Les tailles, les formes, les fonctions : tout peut différer d’un terminal à l’autre.

Ça n’a l’air de rien mais cette différence change tout pour la qualité des applications !

Si vous connaissez exactement les spécifications du mobile, vous pouvez développer une application parfaitement adaptée au mobile et à son usage.

Si le mobile peut avoir un clavier ou pas, un écran plus large que haut ou au contraire un écran vertical, … l’application doit soit s’adapter à tous ces cas, et c’est « l’enfer » à concevoir et à développer, soit l’application fait « au mieux » et cela veut dire finalement une interface « moyennement » adapté à chaque cas.

Pour le client, ça change tout.

En mobilité plus qu’ailleurs, avoir une interface parfaitement adaptée est un vrai plus.

L’application doit être pensé pour être simple, rapide à utiliser, et tout ce qui permet d’améliorer l’ergonomie est bon a prendre.

Pour revenir à l’iPhone, il y a à mon sens clairement deux types d’applications :

  • Celles conçues pour être faciles à utiliser, avec un vrai travail sur le service et son ergonomie ;
  • Les autres, avec des effets « woihou » mais finalement pas vraiment utilisables.

Bien sûr, rien n’empêche de faire du « woihou » et de bien penser l’application… Mais c’est une question de priorité et de moyens.

Et vous, votre application, vous la voulez dans quelle catégorie ?

Pour la première catégorie, Araok est là pour vous aider ;)

déc 08

Erreur classique d’ergonomie dans un formulaire

sous , , | 12 réponses

Ah là là, les formulaires, on en parlera jamais assez !

Pas si facile de faire un bon formulaire, clair, lisible, et qui transforme bien.

Une erreur très classique est, pour gagner de la place, de mettre des boutons radios en ligne :

bugboutonradio

Erreur, car en regardant rapidement, la sélection n’est pas du tout intuitive. Le bouton du milieu permet il de sélectionner le brun ou le vert ?

Pareil en fait avec des boites à cocher :

bugboiteacocher

ça n’a l’air de rien, mais ce sont bien ce type d’erreurs qui attaquent le taux de transformation d’un site, parce que l’impression de l’internaute n’est pas « rassurante ».

La solution en occurrence, c’est soit de mettre une option par ligne, soit de bien séparer les options, de manière à ce que l’association entre le bouton et le libellé soit évidente.

déc 07

Google Temps réel

sous , , , , | 2 réponses

Beaucoup de nouveau services sont basés sur le « temps réel », l’information instantannée.

Mine de rien, c’est une sacré révolution (encore une ;) ). Le protocole sous jacent n’était pas du tout fait pour ça…

Donc, Twitter, Facebook, les chat, … Tous ces services sont basées sur le temps réel : dès que l’info est publiée, elle est diffusée.

Et même si Google essaye d’adapter son moteur, c’est un peu la quadrature du cercle, parce qu’à l’origine, pour Google, plus une info est référencée, plus elle apparait haut placé.

(on avait déjà discuté de tout ça dans ce billet)

Et bien Google vient d’annoncer la sortie d’un service de recherche temps réel :

C’est une révolution !

Si le service est rapidement déployé, cela peut tout changer dans les stratégies SEO des marchands (et des autres).

Si aujourd’hui des services comme Twitter restent marginaux pour le e-commerce, ce type de changement peut clairement changer la donne, et pousser les e-marchands à développer une communication temps réel riche !

A suivre de très prêt donc !

(info trouvée via Cédric Ingrand (twitter) )

déc 07

Système d’information : Les effets de bords d’un prix très élevé

sous , | 3 réponses

Ce billet concerne plutôt les entreprises de taille moyenne à grande.

J’ai déjà parlé dans des billets précédents, de l’effet de bord d’un projet IT très très cher :

En général, de tels projets sont validés par la direction générale.

Et, comme par magie, le projet est « toujours » un succès.

Pourquoi ?

Parce que si ce n’était pas le cas, la direction serait « challengé ».

Donc, même si dans la pratique c’est pas si rose que ça, on va s’arranger pour dire que « tout va bien ».

Qui ira vraiment vérifier ?

Les équipes vont se débrouiller, jongler entre excel et des applications instables, la communication sera : « on track ».

Et bien parfois, un autre scénario se produit : la mort du projet.

Le scénario est le suivant :

Un projet « mastodonte » est lancé.

A un moment donné, quelques années plus tard, un dirigeant, n’ayant pas trempé dans la décision, regarde le truc, et fait une rapide analyse :

  • ça a coûté combien ?
  • ça a rapporté quoi ?

Et là, rapidement, la décision va être prise d’arrêter le projet.

le projet est donc mort d’avoir coûté trop cher, au démarrage, et donc d’avoir, les premières années, un bilan « indéfendable ».

Quelle est la différence entre les deux scénarios ?

Finalement, dans le deuxième projet, on peut se dire que la décision n’a pas été prise assez haut, et que le projet n’a pas été vendu assez cher ;) .

Plus sérieusement, c’est pour moi un élément complémentaire pour pousser des solutions par étapes, avec une monté en puissance très progressive.

Il faut éviter à tout pris les projets « cathédrale », qui coute cher, sont long à faire, et ont des résultats très incertains.

Il vaut tellement mieux privilégier une approche « agile », par étapes.

Mais pour cela, les mentalités doivent énormément évoluer !

déc 07

Nouvelle fonction sur Lengow pour enrichir les flux produits

sous , , , | Une réponse

Lengow est une solution (dont j’ai déjà parlé ici) qui permet de publier tout ou partie du catalogue vers différents moteurs de shopping.

Bien sûr, pour fonctionner, le moteur à besoin d’avoir le plus d’informations possibles sur les produits.

Et c’est souvent là que ça coince.

Pour régler ce problème, Lengow a ajouté un système, qui permet de récupérer les données sur les produits directement à partir de la page web du produit.

On a pas mal discuté avec Mickael (fondateur / directeur technique de Lengow) de cette fonction.

Au final, c’est un choix pragmatique, qui permet de mettre en place Lengow sans avoir à attendre d’avoir le flux qui va bien.

Mais la question que ça pose, nécessairement, c’est : pourquoi les e-marchands ne peuvent ils pas produire le flux directement ?

Et oui, si la page produit affiche des informations sur les produits, c’est bien que ces informations sont stockées dans le système d’information e-commerce du marchand.

Oui, mais voilà, bien souvent, ce système est :

  • Soit mal maîtrisé (ou pas maîtrisé du tout) ;
  • soit externalisé : et les demandes d’évolutions peuvent être chères, et longues à venir (ou ne jamais venir…) ;
  • soit l’équipe technique a d’autres priorités.

Cela donne une assez bonne idée du chemin qu’il reste à parcourir, pour fournir aux marchands un système e-commerce réellement performant…

déc 05

Affligeant, la qualité de l’émission « Envoyé spécial » sur le e-commerce

sous , | 17 réponses

Cela fait quelques temps qu’on ne regarde plus la télé chez nous.

On a basculé, il y a plusieurs années maintenant, avec un écran, un vidéo projecteur, et une bonne collection de DVD (avec un très bon loueur tout près).

Mais le lecteur DVD a un tuner, et bon, l’émission était sur le e-commerce… J’ai eu une rechute ;) .

Oui, mais la qualité de l’émission, au delà du reportage sur le e-commerce d’ailleurs, m’a tellement affligé que je vais avoir du mal à recommencer !

Ce qui m’a marqué, c’est la recherche de l’anecdote, la superficialité de l’émission.

Quelques exemples :

Pour le reportage sur Berlusconi, la majeur partie du temps de ce reportage s’est attardé sur un groupuscule ridicule, proposant que Berlusconi ait le prix nobel. Aucun intérêt, et surtout, bien loin du sujet : ce groupuscule n’est évidement en rien représentatif de quoi que ce soit.

Sur le reportage sur l’évolution « 3D » du cinéma, là, on c’est attardé dans un restaurant Français aux US, ou se retrouvent les ingénieurs français travaillant pour les prestigieuses sociétés américaines. Intérêt de cette scène par rapport au sujet ? Zero, rien.

Et enfin, sur notre sujet « fétiche », le e-commerce : la majeure partie du reportage a permis de couvrir « l’enquête » sur un site bidon, censé vendre des parfums. Pas d’info sur la croissance vertigineuse de ce marché, sur le fait que 99,9% des transactions se passent bien… En fait, quand on sait que plus de 20 millions de personnes achètent déjà en ligne, je me dis que les téléspectateurs sont plus au courant que les reporters de cette émission…

La meilleure analogie que j’ai trouvé est la suivante : cela donne l’impression de feuilleter un journal comme « Voici ». Vous voyez ? Rien sur le fond, mais des anecdotes « croustillantes » pour faire de l’émotion, de l’audience… sans moi !

déc 04

Critère de qualité – La robustesse

sous , , , | 2 réponses

Quand un site e-commerce grossit, que le site représente plusieurs millions d’euros, la qualité du site prend de plus en plus d’importance.

Ce n’est pas le cas au début, au lancement d’un site e-commerce.

Mettre la barre trop haut, au lancement d’un site n’est pas forcément une bonne idée, parce que la qualité à un prix…

Pour faire simple, au démarrage, il vaut mieux privilégier le e-marketing, et accepter de prendre certains risques au niveau de la qualité de la solution.

La qualité se mesure par plusieurs critères.

Le critère que je propose de creuser un petit peu ce soir, c’est la robustesse.

C’est quoi la robustesse ?

La robustesse, en informatique, c’est la capacité qu’à une solution informatique à se comporter le mieux possible, même quand « le monde s’écroule ».

Concrètement, cela veut dire, pour un site e-commerce, que le site doit continuer à fonctionner même si des incidents surviennent, à différents endroits (un serveur qui s’arrête, un service tiers qui ne répond plus, …).

Bien sûr, on ne peut pas demander à ce que le service continue « comme si de rien n’était » alors que des services clés ne répondent plus. Mais on peut demander à ce que la dégradation du service soit contrôlée et progressive.

Exemple : le lien avec la logistique tombe, et le site Front office n’a plus les infos de stock.

On peut tout à fait imaginer que le Front ai une sorte de cache, et qu’il puisse continuer à effectuer des ventes, en s’appuyant sur le stock géré en cache.

Autre exemple : sur pecheur.com, il y a deux systèmes de paiement CB, indépendants. C’est une solution (simple pour le coup) pour permettre de vendre à tout instant, même si l’une des plateformes de paiement tombe.

Pour un service Web, la robustesse, c’est également bien se comporter quand le site doit supporter une charge trop importante.

Exemple de stratégie : au lieu de ne plus rien répondre, le site peut s’adapter à la montée en charge, en se délestant de certaines fonctions (merchandising par exemple) pas complètement indispensables.

C’est toujours mieux que de laisser tous les clients attendre devant une page qui s’affiche à la mode des années 80.

C’est finalement assez cher de concevoir une solution vraiment robuste. Il faut doubler les serveurs, mettre en place des processus pour gérer les différents cas de panne, concevoir une architecture avec des composants assez indépendants, faire des tests, …

Mais c’est clairement indispensable et rentable pour un gros site, ou il est carrément impensable que le service s’arrête.