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.
