NoSoftwarePackage (5/7) : un nouveau nom pour le développement introduit par les progiciels... le paramétrage

Cet article fait partie de la suite d'article sur NoSoftwarePackage

Le contexte : 
Une question essentielle se pose lorsqu’un besoin informatique est identifié dans une entreprise. Doit-on construire la solution ou faut-il adopter une solution toute faite ? Dans la plupart des cas les entreprises orientent leur choix sur des solutions du marché, et les développements internes n’interviennent que si aucun logiciel n’existe ou seulement si aucun d’entre eux ne répond correctement au besoin.


Articles déjà publiés : 
Le développement est une solution trop risquée dans notre cas
Le développement n'est pas notre métier
Le développement spécifique peut être efficace
N'est ce pas un contre sens métier d'avoir trop de fonctionnalités ? 

La dernière fois j'ai parlé de la problématique d'un logiciel qui apporte beaucoup de fonctionnalités par rapport au besoin réel des utilisateurs. Parlons aujourd'hui de

Paramétrage ou developpement ?

Prenons l’exemple des grands ERP que les grands groupes mettent en place…  Lorsque l’on écoute les commerciaux ces solutions toutes faites sont magiques, s’adaptent à votre besoin sans problème car tout est paramétrable… Vous ne voulez pas d’une fonctionnalité ce n’est pas grave, on la masque. A les écouter la personnalisation d’un  logiciel n’est pas un développement, on ne fait que paramétrer… mais quand on regarde de plus près ce paramétrage peut s’apparenter à du développement amenant tous les problèmes que l’on reproche aux développements spécifiques.

Il faut des mois voir des années  pour mettre en place un ERP dans une société, pour l’adapter à son contexte. Les entreprises possèdent rarement les compétences internes sur le paramétrage de ces solutions et elles doivent passer par des prestations externes souvent tarifées à prix d’or. Je ne citerai pas de nom mais j’ai l’exemple en tête d’un progiciel mis en place pour gérer tous les flux financier d’un grand groupe. La mise en place du noyau commun à toutes les filiales, a nécessité l’intervention d’un grand nombre de personnes. Les spécialisations pour les filiales devaient ensuite être anodines. Une des plus petites filiales du groupe  ne représentant pas 1% du CA,  a nécessité 900 jours au lieu des 180 prévus initialement (…mais non le progiciel coûte moins cher…).

Comme j’en ai parlé rapidement précédemment, la mise en place d’un progiciel est vu par des décideurs comme une occasion de revoir l’organisation de l’entreprise. Comme il faut limiter au maximum les adaptations pour baisser le coût d’une solution, l’entreprise s’adapte aux besoins du logiciel et on ne fait plus l’inverse. Mais il ne faut pas être dupe, chaque contexte demande des paramètres et donc des développements spécifiques pour mettre en place un progiciel.

Adapter un progiciel peut s’avérer plus ou moins coûteux. Les modifications peuvent toucher le cœur du logiciel pour essayer de coller au plus prêt des besoins utilisateurs. Mais agir ainsi, vous expose à des problématiques encore plus dommageables que celles rencontrées pour des développements faits en interne. En effet les personnalisations des progiciels ne bénéficient que rarement des outils permettant de fiabiliser les développements. Elles ne sont connues que d’un panel de consultants alors que les développeurs peuvent facilement intervenir sur des solutions développées sur des langages classiques de programmation. 

Le prochain article parlera des "phénomènes d'engrenage lorsque l'on se lie à un progiciel"

Merci à Agnes Crepet, Anne Laure Rigaudon, Alfred Almendra, et les autres anonymes pour leur relecture et leurs différentes critiques.