Techniques & développement

N’ayez crainte, l’objectif n’est pas de vous noyez dans un océan de termes techniques bien au contraire.

Même si vous n’êtes pas informaticien, la technique est un critère de choix EXTRÊMEMENT important car beaucoup de choses en découlent :

  • Langage utilisé : suivant le langage utilisé, il peut être difficile de trouver des ressources. Aussi, il est préférable que l’ERP utilise un langage « ouvert », connu du plus grand nombre et pérenne. Si le langage du fournisseur est propriétaire, dans le sens où la syntaxe de celui-ci a été définie par lui, la formation pour les éventuelles ressources à intégrer dans le projet ne sera que plus complexe et coûteuse. Contrairement à un langage propriétaire, le langage universel est une police d’assurance qui permettra au fabricant de réutiliser son code source peu importe ce que le futur réserve au fournisseur…
    Pour les plus experts dans votre vous, préférez une validation du code écrit lors de la compilation et non lors de l’exécution. Un langage compilé permettra au programmeur d’être 2 fois plus productif qu’un langage interprété (script, etc.). Quand il s’agit de travaux relatifs à de la configuration de produits, il va de soi que l’économie en temps et en maintenance est significative…
  • Souplesse & adaptabilité de l’outil : bien que le fournisseur ait de l’expérience dans votre secteur, vous devrez vous assurer de la capacité de celui-ci à apporter les modifications nécessaires au logiciel afin de répondre à vos besoins.
    Ces modifications peuvent être apportées au cœur du système ou peuvent être faites en spécifique. Dans l’éventualité où elles concernent le cœur, cela signifie que toute l’industrie profitera de ces modifications. Si elles ne sont faites qu’en spécifiques (personnalisation), vous serez les seuls à en profiter.
    Rares sont les logiciels qui permettent une personnalisation de l’application. Cette couche de personnalisation est essentielle car elle permet non seulement d’adapter le logiciel à des besoins spécifiques, mais elle permet surtout au fabricant de recevoir les mises à jour annuelles qui contiennent toutes les améliorations apportées par le fournisseur au fil du temps (investissements en R&D). Sans une couche évoluée de personnalisation, l’industriel, en demandant des modifications, ne sera plus en mesure de profiter des investissements effectués par l’éditeur du logiciel.
  • Automatisation des tests pour une meilleure qualité : une bonne architecture permet de mettre en place l’automatisation des tests. Le catalogue de produits évolue constamment, les nomenclatures également de même que les logiciels comme tels. Ce sont les raisons pour lesquelles il est souhaitable que le fournisseur fasse la preuve de sa capacité à offrir un environnement de tests complet, à tous les niveaux.
    Ce que vous devez éviter, c’est de mettre en production des composantes du système non stables, inexactes ou incohérentes. Avec le temps, cela devient presque impossible de tester manuellement toutes les combinaisons et scénarios possibles découlant de l’utilisation du système, d’où la nécessité de mettre en place un système d’automatisation de tests.
  • Architecture & Performance : souvent, lors des présentations faites en avant-vente, le fournisseur met l’accent, avec raison, sur les fonctionnalités qui viendront combler les besoins.
    Il faut comprendre, par contre, qu’au-delà des fonctionnalités, il est pertinent de comprendre l’architecture qui supporte le logiciel.
    En fait, une bonne architecture assurera :

    • Que le logiciel pourra évoluer
    • Que le logiciel pourra supporter un volume grandissant de transactions
    • Que certaines composantes pourront interagir avec d’autres systèmes. Par exemple, l’utilisation de certaines des composantes du logiciel sur Internet, de l’utilisation du configurateur dans un contexte autre que le ERP, etc.
    • l’utilisation de certains algorithmes externes
    • Qu’advenant un temps réponse inadéquat, il soit possible d’ajouter simplement des nouveaux serveurs et non de les remplacer (virtualisation, répartition de la charge…)

Une bonne architecture permettra à l’éditeur de faire évoluer son logiciel de manière efficace alors qu’à l’inverse, une mauvaise architecture entraînera des coûts, à terme, qui ne sont malheureusement pas pris en compte au départ.

Publicités