La fonction Environnement, Hygiène et Sécurité (EHS, EH&S, HS&E, appelez-là comme vous voudrez) n’est pas parfaitement couverte par les progiciels de gestion intégrée (ERP) tels que SAP. Cet article fait le point sur la question et donne quelques conseils à ceux qui sont amenés à lancer des projets d’acquisition de progiciels environnementaux également appelés EMIS (Environmental Management Information Systems).
Ce sont les investisseurs et non les managers (et encore moins les managers EHS) qui ont fait évoluer les systèmes comptables depuis les années 30. Ce n’est qu’avec l’Activity-Based Costing et l’Activity-Based Management que les managers EHS ont eu une opportunité de communiquer sur les technologies et actions de prévention de la pollution. Dans l’offre progicielle actuelle de SAP, le système comptable peut être interfacé avec un module EHS essentiellement tourné vers la gestion des substances dangereuses (à travers les fiches MSDS) mais fournissant également des fonctionnalités orientées santé, hygiène industrielle et sécurité. Les sociétés TechniDATA en Allemagne et Enterprism Solutions aux USA étendent ces fonctionnalités notamment en s’orientant vers la gestion des déchets. De grands pans de l’EHS ne sont donc pas encore couverts. Le reporting actuel « manque de robustesse » et les fonctionnalités EHS sont d’une grande pauvreté comparativement aux systèmes dédiés EHS ou aux logiciels EHS développés sur mesure.
Il ne faut pas se leurrer, nous rappelle l’article : ce sont les points de vue financiers et comptables qui influencent le plus les services informatiques. Et la sélection d’un progiciel EHS peut prendre des mois et impliquer un grand nombre de consultants et de prestataires. Ces projets sont donc complexes et requièrent une très forte clarification des rôles de chacun de ses acteurs, faute de quoi le projet peut tourner au renvoi réciproque des fautes et responsabilités, comme l’a montré l’exemple de Hershey Foods.
L’option du développement spécifique n’est pas à éliminer d’emblée : bien que risquée et coûteuse, elle permet d’obtenir des fonctionnalités très adéquates au besoin et offre une solution évolutive car implémentée de manière incrémentale. L’approche la plus couramment retenue dans les entreprises dotées d’un ERP consiste à se doter d’un progiciel EHS particulier, qui sera ensuite interfacé avec l’ERP comptable et financier. Des éditeurs EHS tels que Essential Technologies et Quantum Compliance Systems sont ainsi certifiés compatibles pour et par SAP.
Des organismes tels que l’EHS Software Development Group (EH&SSDG) peuvent être d’utiles conseillers dans de tels projets. Donley Technologies connaît également bien le marché des progiciels EHS et on trouvera quelques informations intéressantes sur http://www.ehsfreeware.com.

Aaron l’a fait, pour le W3C : un agrégateur RSS qui vous envoie ses résultats par email.

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.

Le CIGREF a réuni dans un document des recettes de bon sens pour réussir un projet
progiciel. Le magazine L&S a repris l’essentiel de ce document dans un article
dont il ressort les points
suivants:
Le coût de licences ne représente que 20% des dépenses totales de ce genre de
projet. Ce type de projet donne habituellement lieu à un appel d’offres, rationnel et
contradictoire. Mais l’organisation d’un appel d’offres engendre des coûts et délais souvent
sous-estimés. Le choix du progiciel doit s’appuyer sur une approche à trois dimensions : par
les besoins fonctionnels, par l’offre du marché et par l’existant dans le système
d’information de l’entreprise. Le choix s’effectue en trois étapes : définition du cahier
des charges pour l’appel d’offre et inventaire de l’existant, identification d’environ 6
progiciels offerts par le marché, réduction à un échantillon de 2 ou 3 candidats puis choix
du progiciel à acheter. Le cahier des charges doit contenir au minimum les principales
règles de gestion et les principes d’organisation exprimant le besoin fonctionnel. Les
critères de choix pour identifier la solution répondant au mieux à ce besoin doivent
comporter toutes les dimensions suivantes : durabilité du fournisseur, durabilité du
progiciel, caractéristiques des données traitées (volumes, formats, interfaces),
caractéristiques informatiques, coûts (pour chaque étape de vie du progiciel), performance,
sécurité, services du fournisseur. Le choix doit s’appuyer sur une comparaison de progiciels
sur la base de jeux d’essai donnés au fournisseur, sur le prototypage des fonctionnalités
spécifiques et les spécifications des adaptations nécessaires. En particulier, la
faisabilité de l’interfaçage du progiciel avec l’architecture du S.I. existant doit être
examinée en détail. En ce qui concerne le degré de flexibilité du progiciel, on remarquera
que plus un progiciel est paramétrable et adaptable aux spécifications fonctionnelles
détaillées, plus le travail de paramétrage et d’adaptation sera long et coûteux. A l’inverse
un progiciel rigide implique des coûts d’adaptation des processus de travail. Afin de
procéder à la comparaison des progiciels candidats, il est judicieux d’élaborer une grille
d’évaluation comme outil de réflexion mais il convient de savoir s’abstraire de tout système
de notation pour prendre une décision ultime de manière responsable. Une grille d’évaluation
peut permettre de constater que, quelque soit, la pondération affectée à chaque critère de
notation, une solution se dégage (ou non) comme préférable auquel cas il convient d’en tirer
des conséquences lors du choix final. Enfin, il ne faut pas s’arrêter à la comparaison des
coûts logiciels dans la mesure où une offre moins complète entraîne des surcoûts de
développements complémentaires.
En ce qui concerne le prototypage, il est particulièrement utile puisque qu’il doit se
focaliser sur les processus métiers considérés comme essentiels ou posant le plus de
problèmes de faisabilité, de compatibilité technique avec l’existant ou de qualité
d’ergonomie. Il permet de prendre en compte les contraintes techniques imposées par le
projet et d’étudier les performances et limites du progiciel en se concentrant sur les 20%
de cas qui couvrent 80% des volumes ou les 20% de cas les plus complexes à traiter.
L’article détaille également les bonnes pratiques pour les phases de paramétrage, de test,
de conduite du changement, de migration et de reprise de données, d’adaptation, de
documentation et de contractualisation. Il insiste en particulier sur l’importance, pour ce
dernier point, de se faire accompagner dans le choix par un juriste et par un acheteur seuls
capables de prévenir les écueils courants pour ce type de projets.

Le réseau O’Reilly a publié une introduction à la méthodologie de développement « Extreme Programming ».