Catégories
Uncategorized

« Spaghettiware»: de l’art difficile de l’intégration des composants du système d’information.

Lustucru-Recette-Spaghetti-la-moutarde-et-aux-chalottes.jpg

Un système d’information d’entreprise est, dans la plupart des cas, composé de modules remplissant chacun une ou plusieurs fonctionnalités bien précises. Citons les fréquents modules suivants :

  • La gestion de la relation client (CRM), dénommée à tort car il s’agit de gérer les prospects (qui ne sont pas encore clients par définition) et les opportunités associées
  • La gestion commerciale permettant l’établissement automatisé de devis et la transformation en commande
  • La gestion des catalogues de produits et services
  • Le système de facturation (parfois directement associé à la gestion commerciale)
  • La comptabilité
  • Le système d’information des achats et du procurement
  • Les systèmes d’information des ressources humaines (gestion du temps, registre du personnel, gestion prévisionnelle de l’emploi et des compétences, gestion des recrutements, paie, etc.)
  • Le système de gestion des stocks
  • Les annuaires (personnel interne)
  • Le site institutionnel de l’entreprise
  • Les systèmes de reporting et décisionnels agrégeant les données
  • Les sites de e-commerce accessibles aux clients
  • etc.

On le voit donc, au travers de cette première liste, un SI d’entreprise composé de nombreux éléments comporte naturellement une complexité d’autant plus exacerbée que chacun de ces éléments va interagir avec les autres.

Chaque composant peut être une partie d’un progiciel, un développement spécifique, mais à coup sûr ou disons dans 90% des cas, aucun SI n’est composé d’une solution unique couvrant tous les besoins fonctionnels.

D’où la nécessité d’interfaces, c’est à dire d’éléments autorisant la communication entre ces différents modules.
Prenons un module A et un module B, composants d’un SI, on peut avoir une interface « monodirectionnelle » A vers B (A envoie des infos à B), « bidirectionnelle » (A envoie des infos à B et réciproquement B envoie des infos à A). Voilà pour le sens des flux, par ailleurs il faudra considérer la dimension temporelle de ces flux :A envoie-t-il à B des données de façon périodique (par exemple une fois par jour, la nuit entre 3 et 4 h du matin, A envoie l’ensemble de ses données mises à jour depuis la veille à B), ou bien encore A et B échangent-ils de façon synchrone : dès qu’une information de A est ajoutée ou mise à jour, B en est immédiatement notifié et l’information lui est envoyée ? Ce caractère synchrone se mesure-t-il selon une latence exprimable en minutes, secondes, milli voire microsecondes ?
On voit donc plusieurs critères apparaître dans la définition d’un flux inter-applicatif :

  • la (les) direction(s) des flux
  • la temporalité de ceux-ci (périodicité/synchronicité)
  • la nature des données transitant entre les 2 applications
  • les évènements déclencheurs de transit d’information entre les applications (par exemple lors d’un ajout, une mise à jour ou une suppression d’une information dans A, B en est informé et l’information lui étant envoyé).

On comprend dès lors aisément toute la complexité de l’intégration d’un SI comportant, par exemple, une dizaine de modules. Si chaque module communique avec tous les autres, selon un flux unique, ce ne sont pas moins de 9+8+7+…+2+1= 45 interfaces qui sont potentiellement à mettre en œuvre !
Prenons un exemple concret aisément compréhensible. Imaginons un SI composé de 3 modules : un CRM (pour les commerciaux), une gestion commerciale permettant de faire des devis détaillés (avec catalogue de produits et services intégré) et un système de facturation. Voici un flux simple : le commercial identifie un prospect et une opportunité, il les saisit dans le CRM. Son prospect souhaitant recevoir un devis, une première interface permet au système de gestion commerciale de recevoir les informations relatives au prospect, sans que l’on ait à les ressaisir. Puis le devis est réalisé, et s’il est accepté, transmis par une seconde interface au système de facturation. On voit dans cette chaine simple deux interfaces : CRM vers gestion commerciale et gestion commerciale vers la facturation. Il est clair que le premier intérêt de la mise en place de telles interfaces réside dans le fait qu’il évite la saisie multiple d’information, ainsi ici, le nom du prospect saisi en amont dans le CRM, n’aura plus à être écrit de nouveau jusqu’à l’émission de la facture.

Se pose la question de la « vélocité » de ces interfaces. Peut-on accepter un délai d’une journée voire d’une heure entre la création d’un prospect dans le CRM et sa prise en compte dans le système de gestion commerciale ? Quel(s) est(sont) par ailleurs  le(s) événement(s) déclencheur(s) de la transmission d’information ?

L’effet « spaghettiware »

On le conçoit aisément, l’intégration inter-applicative d’un SI constitue une des activités essentielles et réellement difficile de l’architecture informatique d’entreprise. Quand on a vu que pour 10 modules différents, il existe potentiellement 45 interfaces, on comprend mieux l’utilisation fréquente par les informaticiens du fameux mot « spaghettiware » : tel un plat de spaghettis, l’information circulerait au sein du SI au travers d’innombrables tuyaux enchevêtrés. Ce serait d’autant plus vrai que les SI ont une histoire et que, au gré de leurs évolutions, de nouveaux modules se sont greffés, avec leur lot de nouvelles interfaces …

Comment donc concevoir un SI simple, lisible, pleinement opérationnel, et évolutif ? Cela passe par une réflexion sur plusieurs axes:

1/ la définition claire des « datamaster », c’est à dire les systèmes qui sont référentiels pour chaque type de données

2/ les interfaces ne devraient servir qu’à transporter que les informations strictement nécessaires

3/ une analyse détaillée des flux, tant d’un point de vue du contenu transporté que des contraintes de temps de transport

4/ une harmonisation des technologies de circulation des informations (fichiers plats, API, middleware …)

5/ un effort proportionné dans le développement de l’interface en fonction des enjeux sur les données transportées selon plusieurs critères dont : le volume de données, et les délais acceptables pour les transporter.

Jean-Michel Lucas

©2018-2024

Lustucru-Recette-Spaghetti-la-moutarde-et-aux-chalottes.jpg

Catégories
Uncategorized

ROI et NPV (retour sur investissement et net present value)

   Le retour sur investissement (ROI: return on investment, retour sur investissement) est un calcul visant à démontrer, qu’après un certain temps, l’investissement que vous réalisez va vous rapporter beaucoup plus que ce que vous dépensez.

Pour le quantifier, trois principales entités entrent en jeu:

  • le facteur temps
  • le montant de l’investissement
  • le gain réalisé

Le gain réalisé

Le gain réalisé correspond aux économies que vous allez réaliser grâce à votre investissement: il peut s’agir d’un gain en productivité, d’une réduction des dépenses et achats, d’une augmentation de vos ventes rentables.

Par exemple , un logiciel peut vous permettre de passer deux fois moins de temps sur une activité. Le coût de votre activité est donc réduit de moitié dès que vous êtes formés et l’utilisez. Ou encore, un progiciel permet de réduire de 10% les temps de coordination d’une équipe de 100 personnes (*). Alors, chaque personne dégage 1 dixième de son temps pour ses activités principales. L’économie réalisée correspond au travail à temps plein de 10 personnes, qui peuvent dès lors se concentrer pleinement sur leur cœur de métier.

L’investissement

Le montant de l’investissement peut se décomposer en deux principaux paramètres : le CAPEX (coût ponctuel) et l’OPEX (coût récurrent). Par exemple si on achète un logiciel 100 000 € en CAPEX, on aura un OPEX de 20 000 € par an au titre de la maintenance évolutive, corrective, et du support qui est proposé. Ou encore si on loue un logiciel 5 000 € par mois (SaaS), maintenance et support inclus, il n’y a pas de CAPEX. Enfin si on achète un meuble neuf, il n’y a quasiment pas d’OPEX (hormis le temps que l’on passera à l’entretenir).

Le facteur temps

L’échelle de temps est ponctuée par le lancement du projet et le point mort, comme l’illustre le schéma ci-dessous:

Jean-Michel Lucas 18 mai 2018 ROI et NPV

A inflation nulle, le retour sur investissement (ROI) commence donc à opérer après le point mort, c’est à dire le moment d’équilibre entre l’argent investi et les économies réalisées.

Quant au NPV (net present value), il s’agit simplement de se dire: en cas de statut quo, donc si vous retardez votre investissement, vous décalez le point mort et décalez donc d’autant l’encaissement des gains nets cumulés réalisables.

Jean-Michel Lucas

©2018-2024

(*) lire mon article : Tableurs, solution durable ?

« Patience et longueur de temps font plus que force ni que rage. »
Jean de La Fontaine