Avant d’évaluer les difficultés et les facteurs de risque ayant des conséquences négatives pour le taux de service de l’outil et la rentabilité de l’investissement, il faut avoir présent à l’esprit les quelques règles et contraintes suivantes :
L’énumération des fonctionnalités d’un progiciel de gestion intégré est insuffisante pour le décrire. Il faut y adjoindre le schéma organisationnel qui sous-tend l’implémentation de ses fonctionnalités. L’ensemble constitue l’architecture du progiciel. Celle-ci peut être caractérisée par son champ d’application et par son potentiel, c’est-à-dire sa capacité à couvrir les besoins au point de départ du projet, et à suivre l’évolution de leur expression (voir règle ci-dessus N° 3), sans avoir à toucher aux dispositifs fondamentaux du système.
Le choix d’une solution dont le potentiel serait sous-évalué par rapport au besoin de l’entreprise, entraînera inéluctablement, et très rapidement, des développements complémentaires conséquents. Par leur importance, leur caractère de nécessité et d’urgence (voir règles ci-dessus N° 1 et 2), il est illusoire de croire que l’on pourra préserver la fiabilité et la cohérence du système, sauf à engager des moyens financiers supplémentaires pour assurer la pérennité du progiciel, au détriment de la pérennité du projet (rentabilité).
Après la formalisation du besoin correspondant à la stratégie de l’entreprise, l’évaluation de l’architecture et du potentiel des solutions disponibles pour les rapprocher du besoin, est la tâche la plus cruciale de votre projet.
Or les performances de tout progiciel, ainsi que son potentiel, n’ont aucun rapport avec la taille de l’intégrateur, voire même de l’éditeur.
Le potentiel est lié à l’originalité et à la cohérence de ses concepts, qui sont le fait d’un très petit noyau de personnes chez l’éditeur.
Quant aux performances, elles sont bien sûr, pour une part, en rapport avec l’importance des moyens mis en oeuvre par l’éditeur. Mais pour l’essentiel, elles résultent de :
Ces facteurs impliquent un nombre très restreint de personnes.
La motivation de l’intégrateur est un compromis entre d’une part, le nombre de licences d’exploitation vendues, et d’autre part , la création de la dépendance (voir règles ci-dessus N° 1 et 2) pour facturer le plus de travaux de développement complémentaires possibles, avec la maintenance qui s’y rattache, afin de « fidéliser le compte ».
Quant à l’éditeur, sa motivation est de vendre le plus grand nombre possible de licences. A cet égard, la performance des ventes n’est pas nécessairement le reflet du potentiel et des performances du progiciel. Ce critère est donc loin de constituer une garantie absolue.
En effet, il faut bien distinguer entre:
De plus, le nombre de licences cédées doit être rapporté à la durée de commercialisation, à la notoriété au point de départ, et aux moyens et méthodes marketing engagés.
Le formalisme d’un cahier des charges, en tant que tel, ne pourra ni changer, ni occulter les contraintes et la réalité décrites précédemment. Il s’impose par nécessité dans le cas de très grandes entreprises (plusieurs milliers de personnes), pour cadrer les responsabilités en raison du nombre élevé d’intervenants. En revanche, la nécessité de respecter les phases cruciales, et de leur prêter la plus grande attention, s’impose quelle que soit la taille de l’entreprise.
Après l’adéquation entre le potentiel de l’architecture du progiciel et le besoin, la pérennité de la plateforme hardware sur laquelle l’application est déployée, constitue le second risque majeur qu’il faut évaluer. Il est essentiel que le constructeur soit en mesure (et affiche sa volonté) d’assurer la maintenance de son matériel ainsi que la compatibilité de celui-ci avec les générations suivantes, et ceci pendant une douzaine d’années.
Le troisième risque est relatif à l’évolution, à la maintenance, aux possibilités d’interfaçage et à la fiabilité du code. Ces aspects concernent principalement l’éditeur et couvrent les notions suivantes :
L’éditeur doit s’engager à enrichir les fonctionnalités du progiciel et à l’adapter aux contraintes résultant de l’évolution du matériel. Il faut s’assurer de son intention de faire vivre le progiciel, et se méfier des mises à niveau à répétition et des abandons prématurés, qui sont les prétextes courants pour ne plus assurer le support de la version en cours d’exploitation, avec ce que cela entraîne.
Tout d’abord, il s’agit de la capacité de l’éditeur à corriger les dysfonctionnements éventuels dans un délai raisonnable, en s’appuyant sur son expertise. Puis, de la garantie de disposer d’un interlocuteur compétent pour fournir rapidement de vraies réponses à vos questions et à vos interrogations.
Du fait de l’extrême variété des problématiques que l’on rencontre, ainsi que de l’emploi de fonctions applicatives très spécifiques, on ne pourra jamais complètement s’affranchir de la réalisation de programmes d’interfaçage entre les différents composants logiciels. Il est essentiel que les performances, la fiabilité des traitements et l’intégrité des données soient préservées.
Un système comportant des procédures dont le déroulement est perturbé par des aléas, ou qui dégrade l’intégrité de la base de données, engendre le doute et le désintérêt, et nécessitera une attention de tous les instants. Ces problèmes se révèlent généralement en phase d’exploitation réelle et généralisée.
Pour l’ensemble de ces questions, il s’avère dans les faits que les difficultés et les risques pour l’utilisateur du progiciel augmenteront avec :
Là encore, la taille de l’éditeur ou de l’intégrateur n’est pas un indicateur pertinent pour évaluer le risque de défaillance du service, car la qualité de celui-ci dépend : du potentiel du progiciel, de la cohérence des concepts, de la rigueur et des méthodes d’implémentation, de la cohésion de l’équipe de développement, et de la stratégie commerciale de l’éditeur. Seul un contact direct (au niveau technique et non commercial) avec ce dernier vous permettra d’évaluer ses niveaux d’exigence sur ce point; ou à défaut, des témoignages crédibles d’un échantillon représentatif d’utilisateurs réels du système.
Reste le cas des rachats, des fusions, des cessations d’activité, et des empêchements physiques. Il suffit de se référer à l’histoire récente, pour convenir qu’aucun éditeur n’est à l’abri de ce genre d’accident, quelle que soit sa taille. Sur le marché des ERP, les parts de marché des différents éditeurs reflètent davantage les moyens marketing mis en oeuvre dont le but principal est l’ouverture d’un compte, que la qualité et les performances réelles du produit. C’est pourquoi, pour se prémunir de la cessation d’activité et l’empêchement physique, la seule vraie garantie réside dans l’accès aux sources du code en cas de défaillance.