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.

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

6 commentaires

  1. Interessant… Le bus serait oriente services?
    De mon cote j aurai plus vu une centralisation des donnees communes dans une appli dediee

  2. Bonne vulgarisation de la problèmatique l’urbanisation d’un Système d’information.

    Cependant il y a encore une étape entre l’ESB et le premier schéma théorique. Cela s’appelle le Master Data Management, c’est l’organisation des processus et du stockage des données métiers référentes (commandes, articles, clients).

    Plus d’info sur http://buzz-mdm.blogspot.com/ (Un blogs de collègues de Logica)

  3. @Vincent> Oui, le bus est là pour transmettre les messages aux applications.
    Centralisation -> On revient vers le modèle ERP ?
    C’est une solution possible… Mais qui dans la pratique est rarement la meilleure solution.

  4. Les ESB sont des entités dont on entend parler en général dans des projets ayant une démarche SOA (services oriented architecture).

    Dans une démarche dite SOA, il y a (en théorie) une véritable séparation entre la modélisation métier et le stockage de le donnée.

    L’application (la « brique CRM » par exemple) ne sait pas ou est stockée la donnée « adresse du client » ou son historique de tickets de caisse. Elle appelle un service métier, via le bus (qui est un référentiel des services), et c’est ce service qui se charge d’assurer la recherche ou la mise à jour des données.

    La gestion des données, elle, devrait être pragmatique. La BDD du référentiel produit, par exemple, peut être centralisée (pour des raisons pratiques, ce sujet étant réalisé au niveau du Groupe (société mère), par exemple, alors que les BDD données des commandes d’achats fournisseurs peut être multiples, chaque filiale étant maitre de ses achats (une BDD par pays, car une appli par pays, mais des services métiers uniques.)

    Oupsss, je deviens verbeux … Mais c’est un sujet intéressant.

    Pour tous ceux qui s’intéresse de près à l’urbanisme des SI et à la démarche SOA en particulier, je recommande le livre suivant : « SOA, le guide de l’architecture du SI », chez Dunod (ISBN : 978-2-10-051708-4; tiens, belle exemple de normalisation, ça, l’ISBN).

  5. @francois> pour moi l erp je le voie plus comme un socle mettant a disposition toutes les fonctionnalites de l entreprise plus qu une centralisation des donnees communes.
    Je m en fait peut etre une mauvaise idee…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *