Inscrivez-vous gratuitement à la Newsletter BFM Business
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és ' 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és 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és 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 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.
Votre opinion