Archives par mot-clé : Urbanisme du SI

Pourquoi n’y a-t-il pas d’Amazon Français ?

Mon humble réponse à cet article des Echos qui retrace la vie de quelques gros acteurs du ecommerce Français : Pixmania, Rueducommerce, CDiscount, Oscaro et Priceminister

L’analyse du journaliste, pour faire simple, c’est de dire que les finances n’ont pas suivies.

Peut être… Mais je pense qu’il y a une autre raison : la culture technique.

La force d’Amazon, c’est d’avoir monté un système d’information qui est une machine de guerre.

Le e-commerce, c’est du “techno-marketing”. Bien sûr, il faut savoir trouver les bons produits, savoir acheter, et savoir vendre… Il faut également s’approprier toute la culture spécifique du ecommerce, et ça fait un “gros morceau”.

Il faut intégrer les notions d’acquisition de trafic : SEO, SEM.

Il faut de plus développer une culture de la data : mettre en place les outils pour avoir de la donnée, et faire de l’analyse.

Mais il faut également avoir une vrai vision de l’urbanisme de son système d’information ecommerce…

C’est sur ce dernier point que, je pense, on pêche le plus.

La difficulté, c’est le passage à l’échelle.

Bien sûr, quand on démarre, il ne s’agit pas d’urbanisme. On prend des outils open source, quelques développeurs, et zou, on a un site en ligne.

Mais quand on doit traiter 100, 1000 commandes par jour, c’est une autre histoire.

Et si on veut de la croissance et de l’agilité, sans urbanisme, on est mort. Le système d’information devient une pieuvre incontrôlable, qui tient par “miracle” et que personne n’ose bouger.

ça coute de plus en plus cher à maintenir, les pannes sont de plus en plus fréquentes, et difficile à corriger…

Le problème ? Pas de vision ambitieuse de la plate forme. On bricole ce qui marche, à cout réduit. Ce qui a fait la réussite des débuts donne l’assurance qu’il faut continuer comme ça…

Alors oui, ça a bien un rapport avec les moyens financiers, mais pas uniquement.

 

Système d’information – Démêler le “plat de nouille”

Dès qu’une boite a une certaine taille, qu’elle a plusieurs canaux de distributions, un “historique” informatique, nécessairement, le système d’information vieilli, devient de plus en plus compliqué et de plus en plus cher à maintenir et à faire évoluer.

Ce système est pratiquement toujours composé de briques différentes, ERP, Compta, Caisse, Logistique, … et e-commerce 😉

Les connections entre les systèmes se sont faites au fil du temps.

Assez rapidement, on se retrouve avec plusieurs problèmes :

  • Les briques, individuellement, ont vieilli
  • L’interconnection du système est devenu anarchique, n’importe quel brique effectuant des échanges avec n’importe quel autre composant.

Comment faire évoluer un tel système ?

Comment sortir de cette logique infernale ?

On peut se dire : on va remplacer tel brique, par une autre plus moderne. Au fil du temps, on pourra remplacer toutes les briques et avoir un système “comme neuf”.

Cela ne va pas vraiment régler le problème, et le cout de cette greffe va être très élevé.

Et on sait bien que tout remettre à plat, c’est d’une part tellement cher qu’on ne le fera jamais, et d’autre part, même si on avait le budget, ça ne serait un pas une bonne idée, car le projet serait trop gros, avec tous les risques associés à ce type de “big bang”.

Alors, que faire docteur ?

Mon avis est que la seule solution raisonnable est de passer par une approche SOA.

Il faut, déjà, mettre fin aux échanges anarchiques entre les différentes briques.

Il faut donc définir des couches d’échanges, des API, qui déinissent des objets et méthodes métiers.

Les briques ne doivent dialoguer qu’au travers ces nouveaux composants.

Ces couchent doivent être bien faites : il s’agit de modéliser, le plus proprement possible, les objets métiers.

Exemple classique : les informations sur un client.

Dans bien des boites, la logique “full CRM” n’est pas en place (c’est un “graal”, en ce sens que ce n’est jamais complètement possible de toute façon), et les infos sur le client sont en fait réparties dans différentes briques : e-commerce, ERP, solution d’emailing, application de call center…

Dans notre approche, on défini une couche abstraite permettant de modéliser le client, et toutes les informations associées à ce client.

En tant qu’utilisateur de cette couche, j’aurais une vision propre, un référentiel unique, cohérent

En fait, c’est cette couche qui doit “se débrouiller” avec l’existant, et aller piocher les infos là ou elles sont

Jusqu’au jour ou l’entreprise décidera de fair évoluer la couche CRM, qui pourra alors se brancher simplement “sous” cette couche.

L’avantage de l’approche, c’est qu’une fois une telle couche en place, les briques utilisatrices sont réellement indépendantes des couches sous jacentes, et les problèmes de modélisations “du dessous” ne remontent plus.

Toute la difficulté de l’approche est qu’il faut définir des objet avec le bon niveau d’abstraction, “comme si” les autres éléments étaient nickel.

Les difficultés de cette approche, c’est qu’elle n’est pas immédiatement rentable : on a un cout supplémentaire, pour définir, développer et utiliser cette couche, ce qui est bien plus long que d’aller chercher l’information directement à sa source.

C’est en fait toujours le cas avec les approches ou l’on recherche la qualité.

Prenons un simple développement web, pour une application quelconque. C’est bien plus rapide de faire un petit développement, sans aucune approche qualité, un petit programme qui pourra allègrement mélanger la couche présentation, les logiques métiers et la couche de données. bien plus rapide à développer (je dirais un facteur 3, pour fixer les idées). Le surcout vien ensuite : le petit programme est rapidement impossible à maintenir.

A mon sens, deux cas de figures : soit les responsables sont “convaincus”, et on va pouvoir y aller, vendre cette approche.

Soit ce n’est pas le cas, les responsables n’ont pas de culture SOA. Dans ce cas, je pense qu’on peut quand même avancer, mais par étapes, et sans mettre en avant ce travail. Simplement, à chaque demande d’évolution, on prend un peu de temps pour définir et mettre en oeuvre une couche d’échange.

Bien sûr, le plus simple, c’est quand cette approche est sponsorisée par les chefs 😉

Un excellent article sur le sujet, par un gars qui a bossé chez Amazon, Google ;).

 

Système d’information e-commerce – centralisé ou pas ?

Bon, le système d’information e-commerce, ça commence par un site e-commerce ;).

Au début, ça va bien. On ne comprend même pas forcément quels sont les autres sujets…

Et puis, quand on en a assez de traiter les commandes par mail, de ressaisir toutes les commandes dans les interfaces des transporteurs, et de ressaisir toutes les infos dans la comptabilité, on pense à mieux s’équiper.

En général, les choses se font petit à petit.

On rajoute une brique par ci, un module par là.

On se retrouve rapidement avec un système… un système quoi !

Il a poussé comme il a pu, et surtout, les connexions entre les composants ont été développées au fil de l’eau…

Il est temps de se poser la question de la pérennité du système, de faire un audit précis de ce système pour identifier les points faibles, et faire gentiment évoluer tout ça.

L’une des questions clé est de bien traiter les données. Pour toutes les briques (ERP, CRM, e-Commerce, …), l’élément clé est bien la base de données.

On est à peu près tous d’accord, entre “pro”, pour dire que, quand on doit auditer un système, on peut faire 80% du travail en analysant les tables de la base de données.

Donc chaque brique à sa propre base.

Les données ne sont donc pas centralisées dans ce cas : chaque brique gère sa partie du modèle de données global à l’entreprise.

Quels sont les problèmes :

  • Les mêmes informations sont dupliquées, entre chaque module ;
  • Ces données ne sont pas nécessairement bien synchronisées. On a donc bien souvent des structures proches, mais avec des valeurs différentes. Exemple : on a bien une table de clients dans le CRM et une autre dans l’ERP, mais ces deux tables ne contiennent pas les mêmes valeurs, et il n’est pas évident du tout de resynchroniser tout ça !

Bon, on doit donc remettre un peu d’ordre dans tout ça.

D’où la question du titre : faut il concevoir un système avec un modèle de données centralisé, ou peut on faire un modèle de qualité, avec un modèle de données décentralisé ?

Mon avis est que le modèle centralisé est un mythe… Pas très réaliste.

C’est le mythe d’un monde simple, ou on pourrait modéliser l’ensemble des données de l’entreprise dans une seule base. Disons le… C’est un peu le mythe de l’ERP.

Dans la pratique, les ERP sont bien pratiques bien sûr, mais force est de constater qu’ils n’arrivent jamais à modéliser toutes les données de l’entreprise, pour tous les métiers.

Outre le fait que le modèle est utopique, il a de plus une certaine fragilité : que ce passe-t-il si le référentiel “tombe” ?

L’ensemble de tous les systèmes de l’entreprise repose sur le bon fonctionnement d’un seul module…

Autre point qui me semble clé : pour mettre en place un tel système, il faut une refonte très “brutale” du système d’informations.

Cette refonte coûte très très cher, prend beaucoup de temps… Et n’apporte pas toujours le résultat attendu (on revient à la promesse difficile à tenir…).

On peut donc raisonnablement réfléchir à un modèle moins “dictateur”, plus décentralisé :

L’idée, c’est que chaque application est bien une application autonome, qui gère donc ces données, et qui les partage avec les autres briques.

Ce qui modélise l’ensemble du système d’information, ce n’est pas une application, mais l’ensemble des applications de l’entreprise.

Belle idée, mais la réalité est un brin plus complexe.

D’abord, les applications ne communiquent pas si simplement que ça les unes avec les autres.

Ensuite, si on ne fait rien de plus, on se retrouve de fait avec la situation de départ : on ne sait plus ou sont les données.

Il fout donc ajouter deux éléments clé à ce modèle :

  • Il faut définir pour chaque type de donnée quelle est l’application qui possède la référence.
  • Il faut ensuite travailler sur les échanges de données.

Pour le premier point, c’est un travail d’analyse. En fait, les choses se mettent en place assez naturellement. Si on reste sur l’exemple du diagramme, on pourrait dire que le e-commerce possède la référence du catalogue. Le CRM est la référence pour les données clients, …

Pour le deuxième point, c’est un peu plus technique.

Nos applications doivent donc dialoguer les une avec les autres :

Ah là là, notre beau “monde” est devenu un enfer de liens dans tous les sens… (bon, d’accord, j’ai un peu exagéré, mais la réalité est souvent pas si loin que ça…).

Comme je l’ai dit dans un autre billet, les liens constituent, entre les modules, un vrai sujet !

Le mieux est donc de penser à mettre en place une architecture à base d’ESB !

L’idée est simple :

On ne fait plus des liens entre les modules, mais on met en place un vrai système de patage d’information.

Bon, il est tard, je vous en dirais plus… plus tard.

Vous reprendrez bien une petite tranche de système d’information ?

Le système d’information, c’est l’ensemble du système informatique, qui tourne dans une entreprise.

Pour une entreprise qui fait du e-commerce, c’est bien sûr un site e-commerce, avec son (ses ?) back offices.

Mais c’est également tous les autres systèmes, plus ou moins anciens, plus ou moins interconnectés : ERP, CRM, …

Toutes les entreprises ont une histoire, et le système d’information de l’entreprise est une trace de cette histoire, souvent non linéaire ;).

Alors voilà, le contexte évolue rapidement, les techno aussi, et l’entreprise doit faire face à de nouveaux défis.

Le système d’information devient un boulet, qui freine l’entreprise.

Il faut donc repenser le système.

Certains (surtout les éditeurs 😉 ) vous proposeront de tout changer…

Pour ma part, je pense qu’une telle opération est en général très risqué. Je préfère travailler sur un plan d’évolution “en tranche” du système d’information.

Après analyse fine du système, l’idée est d’identifier des blocs fonctionnels, et de procéder à des évolutions partielles, morceau après morceau.

Cela parait simple comme ça… ça ne l’est pas forcément !

Comme je l’ai déjà évoqué dans ce billet, les traits d’un schéma sont très important

Pour dire les choses différemment, un point clé va être le travail sur les échanges entre les modules.

Il s’agit bien de faire évoluer le système d’information vers un système plus performant.

Il faut donc repenser les échanges entre les modules du système.

Je dois dire que c’est un truc qu’on j’adore faire chez Araok!

Alors, il est comment votre système d’information ?

Système d’information e-commerce : De l’importance des traits !

Quand on fait le schéma d’un système d’information (un système informatique pour gérer un site e-commerce par exemple), on fait souvent des schémas avec des blocs et des traits.

L’idée est simple : l’important, ce qui doit être étudié, ce sont les blocs.
Ils contiennent les fonctions qui doivent faire vivre le système, et apporter la valeur attendue.

On se retrouve à faire un beau “légo” avec des blocs super sympa, un CRM par ci, un ERP par là, un moteur e-commerce bien sûr…

Méfiez vous !

Tous les “urbanistes” de systèmes d’informations savent que dans la vrai vie, un vrai sujet de complexité se cache dans les traits du schéma.

Les raisons ?

Elles sont nombreuses :

Les différentes briques ainsi assemblées ne parlent pas nécessairement le même langage. Il va donc falloir définir des “traducteurs”, pour que tout le monde se comprenne.

Qui dit “lien” dit en fait protocole d’échange. Il faut spécifier ce protocole, en détail ;

Ce protocole doit définir :

  • Le support pour échanger les données (fichier FTP, Web Services, …) ;
  • Le contenu des échanges (XML, CSV, …) ;
  • Le modèle de données des échanges  ;
  • Le mode de synchronisation :
    • Synchrone (le client fait une demande, et à la réponse en temps réel) ;
    • Asynchrone, soit de manière évènementiel, soit sur intervalles de temps réguliers ;
  • Le traitement des erreurs. Souvent oublié, alors que les raisons et les types d’erreurs sont nombreux (panne d’un des serveurs, bug, évolution d’un des systèmes non répercuté sur les autres, …

Tout cela est sympathique, mais ce n’est pas fini, il faut également penser évolutivité !

Cela veut dire que notre protocole d’échanges doit être capable d’évoluer, sans tout avoir à refaire.

Enfin, un tel système d’échange doit pouvoir s’administrer, se “monitorer”.

Bien sûr, pour un petit site, on doit faire simple,…

Mais “petit site deviendra grand” (c’est tout le mal que je lui souhaite 😉 ) et si on ne prend pas le temps de bien concevoir le nouveau système d’information…

C’est pourquoi dès qu’un site est suffisemment grand, je propose de mettre en place un véritale système d’échange, pour “remplacer les traits” par un module, bien identifié, dont la fonction est de faciliter tous les échanges entre les différentes briques du système d’information.

Le grand avantage de cette architecture, c’est qu’on factorise, on regroupe les différents besoins d’échanges au même endroit.

Enfin, il me semble raisonnable d’ajouter : c’est vraiment l’un des métiers d’Araok de vous accompagner dans ce type de réflexion…