NoSoftwarePackage (6/7) : effets d'engrenage des progiciels

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 ? 
Un nouveau nom pour le développement introduit par les progiciels... le paramétrage

Effet d’engrenage

Les gros progiciels sont souvent des solutions modulaires. Une entreprise peut n’adopter que les modules de base. Mais ces seuls modules de base donnent rarement satisfaction, que ce soit sur le plan de la rentabilité financière ou de l'efficacité organisationnelle. Bien sûr les consultants externes identifieront tout de suite le problème : « il faut aller plus loin dans la rationalisation et acheter d'autres modules. Après avoir remis à plat les procédures au sein des départements administratifs et comptables il faut rationaliser toute l’entreprise… »… jusqu’à être totalement dépendant d’un ERP.

Les éditeurs  ne garantissent jamais la maintenance des applications plus de deux, trois ans, sauf si l'entreprise choisit d'investir dans une nouvelle version du progiciel. Un effet boule de neige commence, de même qu'une forte dépendance vis-à-vis du fournisseur d'ERP et de ses consultants. Une fois que tout le système est géré par un seul éditeur il est difficile de faire jouer la concurrence, et les fournisseurs d'ERP en profitent pour augmenter leurs prix. Ils auraient tord de s’en priver puisqu’ils sont en position de force en tenant en otage les entreprises.

Les solutions évoluent (au niveau de la comptabilité  il faut sans cesse prendre en compte les nouvelles lois) et les clients des ERP doivent être à l’affût des mises à jour proposées par les fournisseurs. Si des personnalisations ont été développées (ou pardon…paramétrées), les mises  à jour demanderont un niveau d’effort plus ou moins important. Certaines entreprises en arrivent même à ne garder que des solutions standards de ces ERP pour limiter au maximum les personnalisations et elles développent à côté d’autres solutions en interne pour gérer les exceptions. Ces solutions hybrides ne vont pas dans le sens des utilisateurs en complexifiant les architectures.

Les fournisseurs d’un ERP sont les maîtres pour faire évoluer leur solution et peuvent choisir de revoir certaines fonctionnalités sans prendre en compte les spécificités de leurs clients. Ils doivent développer une fois pour le plus grand nombre sans se soucier des exceptions (c’est leur business model).  Donc une entreprise peut se voir imposer des réorganisations par les éditeurs qu’ils n’auraient pas prévu initialement et pouvant aller à l’opposé de leur vision initiale. 

Après avoir vu plusieurs arguments montrant que le développement spécifique n'est pas une mauvaise solution et d'autres montrant qu'un logiciel ou progiciel n'était pas l'idéal, j'essayerai  d'aborder les cas où il est intéressant ou non de partir sur une des deux solutions

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