01net Pro Entreprise informatique
Actualités gestion et logiciel informatique professionnel
Offre et recherche Emploi informatique internet
Salon conférences inofrmatique IT ebusiness 01
Le Cloud Computing
Vidéos reportage entreprise acteur informatique
Retrouvez tous les services 01Net dédiés aux professionnels !
Télécharger logiciels Pro et progiciels
Livres blancs e-commerce informatique et nouvelles technologies
Retrouvez l'ensemble des dossiers de la rédaction 01net Entreprise
Les synthèses des bonnes pratiques sur les sujets IT du moment

Concevoir son PGI plutôt que le subir

Plutôt que s'adapter au PGI choisi, mieux vaut analyser ses processus métier afin de trouver le PGI qui convient le mieux. Cela passe par une étroite coopération entre utilisateurs et équipes informatiques.

Plus personne ne met en doute la pertinence d'une démarche PGI pour structurer les fonctions centrales de l'entreprise. Pour autant, les bénéfices attendus sont-ils automatiquement au rendez-vous ? Cela dépendra beaucoup de la façon dont le projet PGI aura été conduit sur le plan fonctionnel. Les considérations techniques et architecturales ont certes leur importance, mais les erreurs que l'on pourrait commettre en termes de dimensionnement des serveurs, de choix d'infrastructures d'accès, d'optimisation des temps de réponse, etc, pourront être corrigées assez facilement lors des phases de préproduction et de maintenance.
En revanche, que l'on ait mal sélectionné le PGI ou bâclé la modélisation des processus métier, et c'est l'assurance d'un système d'information bancal pour des années. Comme le souligne Jean-Michel Galliou, responsable informatique de la société Mecelec, ' le choix d'un PGI est affaire de compromis entre les différentes demandes internes. Si l'on veut prendre les meilleurs outils pour répondre aux besoins de chaque processus, autant ne pas faire ce choix '. Il parle en connaissance de cause, l'équipe informatique de Mecelec a testé pas moins d'une dizaine de PGI avant d'opter pour celui de Jeeves, en remplacement de plusieurs applications spécialisées vieillissantes.

Les besoins : réaliser un audit fonctionnel précis

La phase de sélection peut débuter par une étude d'opportunité, qui permettra de s'assurer que l'approche PGI répondra aux besoins exprimés par les responsables fonctionnels. Elle demandera ensuite un examen poussé des solutions mises en concurrence. Le groupe de presse Mondadori Magazines France avait ainsi sélectionné trois offres. ' Nous avons fait réaliser des maquettes par les trois éditeurs et les avons ensuite présentées aux utilisateurs, explique Régine Levard, responsable de ce projet. Ceux-ci ont évalué les modules qui les concernaient en répondant à des questionnaires basés sur un cahier des charges que nous avions établi avec le cabinet CXP. L'équipe informatique s'est intéressée, elle, aux aspects techniques. ' Et c'est en croisant les notes fonctionnelles et techniques que l'équipe projet a retenu la solution Qualiac sur AIX.
Même démarche chez ColArt France, la filiale française d'un distributeur de produits artistiques. ' Nous avions envoyé notre cahier des charges à cinq éditeurs, avec l'idée de n'en sélectionner que trois en short list, explique Patrick Ollier, son directeur informatique. Une fois ces trois éditeurs sélectionnés, leurs équipes avant-vente ont commencé à travailler sur nos processus. De notre côté, nous avions monté une équipe projet de vingt personnes, avec des responsables de domaines et de sous-domaines fonctionnels. Chaque éditeur avait deux jours pour présenter son offre, puis il était noté par les membres de l'équipe. ' Suite à ce passage en revue, le distributeur a retenu la solution Movex d'Intentia (racheté depuis par Lawson Software) sur AS/400. Dans une telle mise en concurrence, l'avantage n'est pas forcément aux grands éditeurs, peu habitués à traiter avec les PME.
Chez Mecelec où, lors d'un dernier choix contradictoire, Jeeves a été comparé au PGI de SAP, la lourdeur et les coûts d'implémentation de ce dernier ont fait pencher la balance en faveur de Jeeves. SAP n'est certes pas le seul éditeur à avoir du mal à se conformer aux contraintes des PME. Avant d'opter pour le progiciel Exact Globe 2003 Enterprise sur Windows, la société Vocalcom a dû batailler ferme. Pour Mickaël Jadaud, son directeur des opérations, ' l'approche commerciale n'était, au départ, pas du tout adaptée à la taille de notre société. En tant que PME, nous devons être réactifs. Or la migration telle qu'elle était proposée aurait pris trop de temps. Après négociation, nous avons pu faire diminuer de 20 à 30 % le nombre de jours nécessaires à l'implémentation '.

Les ressources : s'appuyer sur les experts métier

Pour pouvoir faire plier les éditeurs, encore faut-il s'appliquer une discipline certaine. Un projet PGI ne peut être conduit sans la participation active des utilisateurs. Il est donc primordial que les responsables fonctionnels et les ' utilisateurs-clé ' soient mobilisés, au moins à temps partiel. Le répartiteur pharmaceutique Alloga a ainsi mobilisé une vingtaine de fonctionnels et d'informaticiens pour préparer la mise en place du progiciel IBS Pharma sur AS/400. Pour Magali Demazet, directrice informatique d'Alloga, ' le PGI est un projet d'entreprise. Il est important que les fonctionnels adhèrent à un projet qui modifiera leur façon de travailler, et qu'ils définissent leurs besoins. À cette fin, nous avions désigné un utilisateur-clé par grand domaine [ADV, logistique, etc., Ndlr] '.
Pour définir le périmètre fonctionnel à couvrir, ces utilisateurs-clé doivent être impliqués dès la mise à plat des processus métier. Cette phase de modélisation peut démarrer très tôt si l'on souhaite, à l'instar de ColArt France, sélectionner un PGI qui colle au plus près des processus de l'entreprise. Même constat pour Patrick Ollier : ' Nous voulions éviter d'orienter la refonte de nos processus en fonction du produit que nous aurions choisi. D'où un long travail d'analyse préalable des processus à la rédaction du cahier des charges '. Certes, reconnaît Patrick Ollier, ' une fois Movex retenu, nous avons dû accepter quelques adaptations ; au final, cependant, nous avons réussi à préserver l'essentiel de nos processus '. Quoi qu'il en soit, que l'on modélise les processus métier afin de guider le choix du PGI ou que l'on se livre à un travail de réingéniérie de ces processus de façon à s'adapter au PGI déjà retenu, il ne faut pas sous-estimer le temps et les ressources que requiert l'analyse fonctionnelle. Et ce, y compris pour des projets modestes.
Le cabinet d'expertise comptable MC2 Partenaire, qui avait choisi Microsoft NAV pour ses 80 utilisateurs, a consacré l'essentiel de ses efforts à cette phase de modélisation, se rappelle Sébastien Pottie, son responsable administratif et financier : ' Nous étions trois, dont un consultant de notre intégrateur Gesway, à avoir travaillé sur le projet pendant six mois, et ce, à raison de deux jours par semaine, pendant les quatre premiers mois, et d'un jour par semaine, les deux derniers mois '. Pour des entreprises plus importantes, l'investissement à consentir peut être bien plus lourd. Avant de sélectionner son PGI, ColArt France a ainsi travaillé presque un an pour mettre à plat ses processus internes.

Mise en ?"uvre : planifier pour contenir les dépassements

Après l'analyse fonctionnelle, viennent le paramétrage, la définition de la cible de déploiement et, bien entendu, le transfert de compétences, étapes pour lesquelles il n'est pas aisé d'évaluer les charges de travail. Bien former les utilisateurs-clé pour qu'ils soient en mesure d'intervenir sur le paramétrage des modules peut demander de deux à quatre mois si l'on se réfère aux expériences d'Alloga, qui a étalé les formations entre fin 2005 et mars 2006, et de Mondadori France, qui a formé ses personnels de façon roulante, durant l'été, afin d'être prêt pour la mise en production, fin septembre 2006. En définitive, toutes phases cumulées, il faut parfois plus d'un an pour implémenter un projet PGI.
Chez Alloga, l'implémentation de la solution IBS aura pris plus de deux ans. Certes, la durée de ce chantier tient à l'implantation internationale de cette société qui a demandé de segmenter la phase de déploiement en plusieurs lots. Ainsi, décompte Magali Demazet, ' les travaux préalables de mise à plat de processus ont pris neuf mois, et ont été suivis de trois projets de déploiement de six mois chacun, en Espagne, au Portugal et en France '. La société s'accorde une pause avant d'achever le déploiement sur ses autres sites européens. Difficile, en effet, de bloquer informaticiens, gestionnaires et logisticiens sur de trop longues périodes. Le cas d'Alloga montre ainsi qu'un mode de déploiement en ' big bang ' n'est pas toujours réalisable ni même souhaitable. Certes, en échelonnant les déploiements locaux, on rajoute à la difficulté de maîtriser l'agenda des mises en production. Pour autant, il serait illusoire de vouloir condenser le projet PGI dans des laps de temps trop courts. En la matière, il faut se garder de tout excès d'optimisme.
Tout projet PGI a ses aléas : des ressources humaines insuffisantes, certaines difficultés sous-estimées, des développements supplémentaires non anticipés, se grefferont sur le projet initial. En conséquence, les dépassements en temps et en budget seront la règle plus que l'exception. C'est être réaliste que de l'admettre, l'essentiel étant de contenir ces dépassements dans des proportions raisonnables.

Les écueils : gérer la reprise des données

Comme l'a expérimenté Mondadori France, la reprise des données des anciennes applications est parfois source de déconvenues : ' Nous projetions de faire une reprise de données détaillées. Malheureusement, notre ancien logiciel d'origine anglo-saxonne n'enregistrait pas les données de la même façon que les logiciels français et nous avons eu un gros problème de qualité de données. Nous avions 15 à 20 % de rejet manuel, ce qui n'était pas acceptable. Nous avons donc été obligés de nous limiter à une reprise globale des données comptables. Ce chantier de reprise a donc été plus difficile que ce que nous avions envisagé. Il nous a pris presque cinq mois, alors que nous avions pensé y consacrer trois mois '.
La reprise des données ne pose heureusement pas systématiquement des problèmes de cette ampleur. Dans tous les cas, elle constitue une bonne opportunité de nettoyer les données et de supprimer celles qui sont obsolètes. En procédant par des échanges de fichiers Excel et bureautiques, l'équipe de ColArt France a ainsi pu mettre à jour son catalogue technique en moins de trois mois.
agrandir la photo

1 - Des offres abouties
Les PGI capitalisent une vingtaine d'années d'expérience de la part des éditeurs de progiciels. Cette expérience se traduit par une grande modularité et une large couverture fonctionnelle des processus métier génériques, de nature administrative (finance, comptabilité, RH, etc.) et industrielle (logistique, production, etc). Le recours à des développements spécifiques complémentaires est donc de moins en moins nécessaire.

2 - Un dimensionnement maîtrisable
Les constructeurs de serveurs disposent d'abaques sophistiqués pour calculer le niveau de puissance des machines de production, en fonction du nombre d'utilisateurs et de la nature des transactions. Côté poste client, plusieurs options (interfaces C/S ou Java/web, services de présentations centralisés) s'offrent aux entreprises pour concilier les contraintes d'ergonomie, de productivité et de temps de réponse.

3 - L'existant et ses pièges
Certaines tâches techniques peuvent faire déraper le planning d'un projet si l'on en a sous-estimé la difficulté. Il est, par exemple, difficile d'évaluer la charge de travail que nécessiteraient la reprise et le nettoyage des données des anciennes applications remplacées par le PGI. L'intégration du PGI avec son environnement applicatif peut aussi entraîner des retards, ne serait-ce qu'en phase amont du projet, si l'on a sous-estimé la couverture fonctionnelle du PGI.

4 - Un pilotage délicat
La mise en place d'un PGI requiert la participation active des responsables métier et des utilisateurs experts, chose plus facile à décréter qu'à réaliser. Par ailleurs, l'équipe informatique ne peut se passer d'une assistance externe pour sélectionner les solutions, planifier les lots de déploiement, modéliser les processus métier et former les personnels. Elle est donc tributaire de la compétence des prestataires.

Notre sélection des principaux PGI

agrandir la photo

Retour d'expérience : Mickaël Jadaud (Vocalcom) : ' Nous déployons au rythme de deux à trois filiales par an '

Un PGI pour l'international

Vocalcom est passé au PGI car ' il nous fallait plus de réactivité en matière de gestion commerciale ', explique Mickaël Jadaud. Vocalcom étant implanté dans plusieurs pays, le choix d'Exact Globe 2003, un PGI adapté au traitement de l'international, était logique. Toutefois, il a d'abord été déployé au siège de la société. ' Nous avions commencé le déploiement français à partir de juin 2005 pour pouvoir démarrer le nouvel exercice en décembre. ' En interne, deux personnes ont été mobilisées ; elles ont été épaulées par deux consultants Exact Software. ' Ces derniers nous ont fait réaliser les manuels d'exploitation, pour nous aider à prendre en main le progiciel et à nous structurer. ' Afin de minimiser les problèmes de migration, ' nous avions travaillé en décembre 2005 sur une base de test. L'ancienne application n'avait donc pas été arrêtée. En revanche, nous avions bien basculé les prises de commande sur le PGI au 1er janvier 2006 '. Exact Global 2003 a été déployé sur un serveur Windows installé au siège de la société. Dans un premier temps, les filiales devront s'y connecter en mode TSE (Terminal Server Edition). Néanmoins, Vocalcom ambitionne de bâtir une infrastructure collaborative basée sur la solution E-Synergy du même éditeur. Pour l'heure, le déploiement se poursuit. Après la France, Vocalcom s'est intéressé à la Belgique. Viendront ensuite le Maroc et l'Italie, puis, d'ici à la fin 2008, le Canada, le Brésil et l'Argentine.

Vocalcom

Retour d'expérience : Jean-Michel Galliou (Mecelec) : ' Chaque module a été présenté aux différents acteurs-clé '

Impliquer les utilisateurs

Mecelec a choisi un PGI pour remplacer des progiciels HP 3000. ' Nous voulions acquérir des logiciels de gestion des achats et ventes et nous avions besoin d'une base de données unifiée et d'outils de pilotage. Nous avons donc tout remis à plat. Après avoir examiné une dizaine de solutions, nous avons sélectionné Jeeves. ' Pour le déploiement initial, Jean-Michel Galliou est resté à peu près dans l'enveloppe budgétaire qu'il s'était fixée : ' Le matériel a représenté 15 à 20 % du budget, le reste se répartissant à parts égales entre les coûts de licence et les coûts de paramétrage/formation '. Le responsable n'exclut pas de nouvelles dépenses : ' Par exemple, nous nous intéressons à la saisie de production sur terminaux Wi-Fi, ce qui n'était pas prévu dans le projet initial '. Mecelec a fait appel aux services de la SSII Ambassade. Une étude d'adéquation fut menée en juin 2006 de façon ' à nous donner une porte de sortie, s'il apparaissait que nous avions fait le mauvais choix '. Cette analyse ayant donné satisfaction, le paramétrage a pu commencer. Le premier lot de déploiement intéressait les 60 utilisateurs du siège de la société. Il a été achevé en décembre 2006 avec deux semaines de retard et sera suivi en 2007 par trois autres chantiers de déploiement sur des sites distants. Le progiciel a été déployé sur deux serveurs Windows en miroir qui auront au final à gérer 80 utilisateurs.

Mecelec

Avis d'intégrateur : Xavier Devriese (IBS France) : ' Il est fondamental que les personnels opérationnels de l'entreprise participent au projet '

Que prendre en compte dans un budget PGI ?
On doit planifier un budget sur deux ou trois ans. Le matériel représente de 10 à 20 % des dépenses. Outre les coûts de licence, il faut tenir compte des coûts de maintenance annuelle, qui sont d'environ 20 % du prix des licences avant remise. Évaluer aussi les coûts de consulting (formation, prototypage, reprise des données, réalisation des adaptations, déploiement...).

Quels sont les risques de dérapage ?
Se tromper sur le nombre de jours d'intégration et mal évaluer la compétence des intervenants. Les utilisateurs-clé doivent pouvoir remettre en cause les processus afin de les conformer au mieux aux approches standards du PGI. Il convient aussi de limiter les développements spécifiques.

Comment dimensionner les serveurs ?
Il faut mettre en place une plate-forme évolutive. Dans certains cas, on cherchera à dimensionner le serveur en fonction des pics de sollicitation. Dans d'autres cas, on dimensionnera le serveur pour répondre à une activité moyenne, quitte à accepter une certaine dégradation des temps de réponse. Cette question de la performance peut conduire à réaliser des études sur le choix du poste client, web ou client-serveur.

IBS France

envoyer
par mail
imprimer
l'article
Nos partenaires