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 ;).

 

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

3 commentaires

  1. Merci François pour m’avoir fait découvrir cet excellent article. Je me permet de compléter ton analyse par quelques réflexions issues de mes 13 dernières années passées sur internet, du côté professionnel :
    – une boîte a très rapidement un système d’information complexe. Il suffit d’un ERP, une compta et un site e-commerce pour que le fête commence. Il n’y a guère que les boîtes mono-canal qui peut s’en tirer à moindre frais, en mettant en œuvre un site ecommerce qui-fait-office-d’ERP, pour gérer le catalogue produit, le stock, les prix, les commandes et la base client. Mais dès qu’une boîte est multi-canal, elle a besoin d’outils métiers-bien-faits.
    – ce qui me fait arriver un second point (qui est sous-entendu dans ton article) : il n’y a pas d’outil miracle qui fait tout, et qui le fait bien. Ce serait une solution très pratique, puisque les connections ne sont plus nécessaires. Mais il faut aujourd’hui clairement oublier cette idée. Même les plus grosses solutions pêchent sur de nombreux points. Les gros ERP ne savent pas faire de la publication web (accessible, SEO friendly, designable…). Les applications web e-commerce ne savent pas faire correctement du master data management (http://fr.wikipedia.org/wiki/Gestion_des_donn%C3%A9es_de_r%C3%A9f%C3%A9rence) pour centraliser un catalogue produit dans une optique multi-canal : visuels haute-définition, multi-support (y compris print !). Ces mêmes solutions seront toujours avec un train de retard sur les législations si elles devaient faire de la compta.
    – j’irai même plus loin : il n’y a pas UNE bonne solution ERP, UNE bonne solution e-Commerce, UNE bonne solution WMS… Il n’existe que les bonnes solutions pour la boîte concernée. Celle qui saura être adaptée à sa stratégie multi-canale, cellle qui saura être adaptée à la façon dont la boîte est organisée, la façon dont elle crée son référentiel produit, la façon dont elle traite ses commandes, la façon qu’elle exploite ses données clients… Il s’agit de trouver le best-of-breed pour son propre besoin.
    – chaque brique de son système d’information vie à un rythme différent, technologiquement, fonctionnellement et réglementairement. Ce qui fait que le système parfait n’existe pas, et qu’il est en permanence en chantier.

    – à partir de là, le premier conseil sera, quel que soit le composant du système d’information, de choisir une solution ouverte avec des services, non seulement pour la rendre interconnectable avec des solutions tierces, mais aussi pour la rendre maléable par rapport à son propre besoin.
    – et le second conseil sera de gérer réellement des données de références (l’aspect MDM que j’évoquais précédemment) pour au minimum 2 domaines : le client et le catalogue produit.

    C’est sur ce second point qu’il faut insister. Car c’est de celui-ci que vont découler toutes les décisions concernant le système d’information, et notamment l’approche SOA.

  2. @Eric> Merci pour ce commentaire riche 😉

    tu as raison, il y a des sous entendus dans ce billet :
    – Le composant parfait qui fait tout n’existe pas
    – toute les solutions vieillissent, avec plusieurs facteurs de vieillissement
    – Pour avoir une approche SOA, il faut que chaque module soit suffisamment ouvert pour pouvoir se brancher facilement dessus

    Après, je n’ai pas du tout parlé des techniques pour les échanges, ça ferait un autre (plusieurs autres 😉 ) billet !

  3. Un projet eCommerce c’est un projet d’intégration. Je ne sors pas de ca.

    Oui à une approche SOA avec comme tu le mentionnes, une approche PRAGMATIQUE ! Un ancien collègue ventait tous les jours la méthode GBS – Gros Bon Sens. Les exemples d’usines à gaz toxiques ne manquent pas, c’est même parfois à se demander si ce n’est pas un fond de business que de faire des systemes qui sont – inmaintenables – y compris avec des gouroux du SOA.

    Les vrais difficultés ne sont que rarement autour des produits ou même de la transaction, mais par contre des lors que l’on fait appel à des services externes – et c’est toujours le cas – se posent des questions non triviales.

    Moteur de recherche, avis d’utilisateurs, gestion de contenus, design de pages via des services comme freemarker, des outils de gestion de communautés ou d’amélioration d’audience comme Lithium, des outils de ranking/avis de consommateurs (Shopzilla) ou même un simple « store locator » via Google. Tout cela demande de prendre un peu de temps pour penser « sécurité », politique de BKP, disponibilité du site, performances … autant de sujet « architecture » qui sont peu vendeurs surtout face à une direction marketing et commerciale.

    En plus des sujets évoqués (CRM, ERP, OrderManagement, …)

Laisser un commentaire

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