GFI Consulting publie un vieil article sur les bonnes (et non moins vieilles) pratiques qui permettent de choisir un progiciel. En particulier, GFI signale que pour être qualifié de progiciel, un logiciel doit non seulement avoir fait l’objet de spécifications formelles pour chacune de ses versions mais doit également faire l’objet d’un effort régulier de commercialisation et de support. Enfin et surtout, il doit être garanti, maintenu et en évolution durable. GFI recommande de ne pas procéder à un choix de progiciel par émission d’un cahier des charges mais par élimination progressive des candidats potentiels dans une démarche plus interactive avec les éditeurs. En effet, aucun progiciel ne répond parfaitement à un cahier des charges spécifique ce qui conduit fréquemment à l’une des situations suivantes : développement spécifique « par dépit », modifications du progiciel par l’éditeur qui aboutissent à en faire un logiciel spécifique, adoption d’un progiciel tellement paramétrable qu’il devient une plate-forme de développement propriétaire au coût de développement/paramétrage comparable à celui d’un développement spécifique ou sélection du progiciel le moins pire par un « consensus mou ». Il ne s’agirait donc pas d’élaborer un cahier des charges détaillé mais seulement une expression générale des besoins fonctionnelles qu’il s’agira de compléter en fonction de la manière dont chaque progiciel étudié y répond. De toutes façon, il convient de retenir que les utilisateurs auront à modifier leurs processus et méthodes de travail pour s’adapter au progiciel (et non l’inverse).
En ce qui concerne la pérennité de l’offre d’un produit par un éditeur, il convient selon GFI de savoir qu’une telle offre n’atteint l’équilibre économique que lorsque le produit a été diffusé à plusieurs dizaines d’exemplaires. GFI considère qu’un progiciel de gestion intégré (ERP) devrait offrir un coût initial d’achat sensiblement inférieur au dixième du coût d’un développement spécifique. Tant que le progiciel n’a pas été commercialisé auprès de 40 clients, après 18 à 30 mois d’existence, sa pérennité économique reste fragile.
De plus, il convient d’estimer non pas le seul coût d’achat mais le coût complet de la solution pour l’ensemble de son cycle de vie, c’est-à-dire jusqu’à son remplacement par une solution impliquant une reprise des données et une nouvelle formation des utilisateurs.