Catégories
Uncategorized

Développement spécifique versus progiciel, ou comment réinventer la roue …

  Désireuse de s’équiper d’une solution informatique dotée d’un certain nombre de fonctions, une entreprise émet une expression de besoins, le plus souvent un « cahier des charges ».

Une question fondamentale -à mon sens- doit apparaître très vite : un progiciel, c’est à dire une produit de « série » proposant une gamme de fonctionnalités pourra-t-il répondre à ce cahier des charges, ou bien alors faut-il envisager un développement spécifique, c’est à dire un produit « sur mesure », totalement spécifié par le cahier des charges ?

Cette réflexion est réellement fondamentale pour l’entreprise à de nombreux égards, notamment :

A. Le coût total de la solution

B. La maintenabilité et l’évolutivité de la solution

C. L’adéquation fonctionnelle attendue


A. Le coût total de la solution

J’ai pour habitude d’utiliser une métaphore automobile pour comparer le coût potentiel d’une solution spécifique versus l’acquisition d’un progiciel.

En investissant pour un développement spécifique, le client demande un « prototype », une solution unique, qu’aucun autre client n’utilisera. En choisissant un progiciel, c’est comme si celui-ci choisissait un véhicule de « série », fabriqué en grande quantité, en usine.

On comprend mieux alors, au travers de cette analogie industrielle, la différence potentiellement drastique de coût entre les deux solutions.

Le raisonnement est simple. Imaginons la solution 1., spécifique, dont le développement coûterait 1 Million d’€. Cette solution sera vendue une fois et une seule au coût de 1,3 Million d’€ par exemple. 

Imaginons désormais la solution 2., progiciel dont le développement coûterait 2 Millions d’€. Si la solution est vendue 50 fois, il suffit de la vendre 2 x 2 M€ / 50 soit 80 000 € pour générer au total un revenu double du coût de production !

1,3 M€ dans le 1er cas …

80 k€ dans le second cas …

De quoi réellement s’interroger quant à la bonne alternative ! 


B. La maintenabilité et l’évolutivité de la solution

Une entreprise s’équipant d’une solution logicielle un tant soit peu élaborée le fait pour plusieurs années. Se pose donc la question du caractère maintenable et évolutif de la solution choisie. Quels sont les risques en fonction du scénario choisi ?

  • progiciel
    • dépendance vis à vis de l’éditeur (« souveraineté numérique »)
    • limitations quant à la « customisation » possible du progiciel
    • la « mitigation » de ces risques consiste à 
      • s’assurer de la qualité économique et technique proposée par le fournisseur (l’éditeur)
      • s’organiser pour optimiser l’autonomie (configurabilité, connaissance intime du produit, transfert de compétences de l’éditeur au client)
      • veiller au nombre de versions livrées par an, au nombre de clients de l’éditeur etc.
  • choix d’une solution spécifique
    En 1997, je suis personnellement intervenu au sein d’une PME (électronique) qui avait fait réaliser une partie de son informatique de gestion (prise de commandes et facturation) par un indépendant qui lui avait « codé » une application spécifique. Résultat: trois ans plus tard, l’indépendant était occupé à tout autre chose, et le système se met à « bugger ». L’entreprise, qui avait tout de même pris soin de devenir propriétaire du code, se retrouve totalement bloquée, sans possibilité de générer la moindre commande ni la moindre facture. Je me souviens de plusieurs journées passées à trouver les fameux « bugs », en entrant dans le code qui avait été réalisé (non documenté bien sûr et absolument pas du tout maitrisé par l’entreprise). Indéniablement, choisir une solution spécifique et la faire développer, c’est prendre un risque important quant à la capacité d’assumer la maintenance corrective et évolutive de la solution.

La vocation même de l’éditeur est effectivement de proposer des produits qu’il fera évoluer, débuggera, et qui sont utilisés par plusieurs clients.


C. L’adéquation fonctionnelle attendue.

On marche souvent sur la tête dans ce domaine si l’on n’a pas bien compris l’importance de la dualité progiciel / développement spécifique.

On lit même bien souvent dans des cahiers des charges : « un développement spécifique ou une solution à base de progiciel pourront être proposés ».

De fait, le processus d’expression des besoins est – me semble-t-il – à reconsidérer:

Processus classique

  1. Quel sont les besoins fonctionnels ?
  2. Quelle ergonomie est souhaitée ?
  3. Rédaction et émission d’un cahier des charges
  4. Réception des réponses
  5. Décision 
  6. Lancement du projet

Le processus qui me semble participer d’une démarche optimisée: 

  1. Quelles sont les fonctions offertes par les différentes solutions du marché ?
  2. Quels sont mes besoins essentiels parmi ces fonctions ?
  3. Rédaction et émission d’un cahier des charges orienté éditeurs
  4. Choix de l’éditeur
  5. Lancement du projet

Ceci me parait d’autant plus pertinent que 80% des besoins ne sont pas spécifiques à la société (ou organisation) cliente, mais communes à toutes les entreprises (ou organisations) du même secteur. Par ailleurs, il est bon de rappeler la fameuse règle des 80/20 : 20% des efforts risquent de représenter 80% du prix.

A quoi bon se restreindre à une description très spécifique et unique du besoin ? A quoi faire (il en existe encore) des maquettes d’écran ? A quoi bon croire que c’est le client qui reste décideur quant à l’ergonomie du logiciel ?

En conclusion : 

  • soit le besoin est couvert à plus de 50% par un produit du marché, et il me semble alors totalement inefficace d’envisager une solution en « développement spécifique ».
  • soit le besoin est tellement spécifique qu’aucun progiciel du marché ne le couvre. J’attends des exemples de ce cas là …  Je ne parle bien sûr ici pas du jargon, des sigles, des acronymes utilisés par le client mais réellement des fonctionnalités attendues.

Jean-Michel Lucas

©2018-2024

vieille-roue-de-chariot-antique-2465566 (1)

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