Difficile de lancer un projet de montée de version ! Nombre de DSI confrontés à une évolution de leurs progiciels le ressentent. Comment vont réagir les utilisateurs ? Les autres fonctions du système d’information supporteront-elles le changement ? Les ressources seront-elles suffisantes ? Des préoccupations d’autant plus prégnantes qu’il s’agit de mettre à jour une application maîtresse du cœur de l’entreprise, comme l’est le PGI.

Agrandir l'image

Légende : Tableau de bord prospectif appliqué aux projets de montée de version SAP



Cette frilosité, la communauté des informaticiens et l’USF (club des utilisateurs SAP francophones) l’a déjà mise en évidence. Notamment lors de la sortie il y a près de vingt mois de la nouvelle version majeure, SAP ERP 6.0, intégrant la plate-forme Netweaver.

19 entreprises ont migré de SAP R/3 vers SAP ERP 6

« Pour aller plus loin et savoir si ces craintes sont justifiées, il faut analyser les retours d’expérience déjà opérationnels », préconise alors Jean Leroux, DSI d’Aelia et président de l'USF. L’enquête qui en résulte vient d’être publiée sous forme d’un livre blanc : « Retours d’expérience sur la montée de version SAP ERP ».

Agrandir l'image

Légende : « Cette étude a été réalisée en toute indépendance de l’éditeur, et les résultats repectent les règles d’éthique et de neutralité qui sont à la base de la charte de l’USF. » Jean Leroux, DSI d’Aelia



Elle a été menée auprès de 19 entreprises ayant abandonné SAP R/3 pour ERP 6.0. « Il n’a pas été possible d’en sélectionner davantage parce que le nombre de DSI ayant achevé la montée de version est apparu comme étant trop limité, met en avant Gilbert Grenié, directeur associé d’ASK Conseil. Les résultats donnent la liste des ingrédients et des méthodes organisationnelles pour mener à bien une telle montée de version.

Une démarche adaptée à toutes les migrations informatiques

« Nous avons identifié les facteurs clés de succès et leur avons ensuite rattaché les principaux risques auxquels les entreprises ont été confrontées », détaille Alexandre Colonna d'Istria, coauteur du livre blanc. Découpés par niveau, ils se décomposent en cinq domaines - un par segment dans la démarche (voir le tableau ci après).









Légende : Des solutions logiques pour soutenir les projets de migration



La démarche d’évaluation s’étend de l’amont - la conduite du projet - à l’aval - le contrôle et les tests. Bilan : La montée de version s’est bien déroulée dans la quasi-totalité des cas analysés. Et cela en respectant le budget et les délais. La démarche est claire et logique. Elle s’adapte donc naturellement à l’ensemble des migrations d’un système majeur de l’entreprise. Comme le sont tous les PGI du marché, ou encore les applications de gestion de la relation client (GRC ou CRM), de gestion des ressources humaines ou d’information comptable et financière.

Des solutions logiques pour soutenir les projets de migration

 

Risques		Solutions logiques
Risques liés à la conduite et au pilotage du projet	Difficultés à coordonner les chantiers fonctionnels	Organiser une réunion de lancement en présence des acteurs du projet Présenter les phases du projet selon une approche par processus métier
	Tests incomplets	En phase de préparation, définir le périmètre des tests et d’évaluer la charge associée. Les tests d’exploitation et de performance ne doivent pas être négligés. Reprendre le dernier plan de tests fonctionnels et l’enrichir des nouveaux cas de tests nécessaires
Risques liés à la disponibilité des compétences techniques	Difficulté à trouver les bonnes compétences sur le marché	Dresser la matrice des compétences clés du projet en phase de cadrage et procéder à un appel d’offres (expérience d’une migration SAP ERP appuyée par un CV). S’assurer ensuite auprès des prestataires de la continuité des prestations durant le projet (clause contractuelle)
Risques liés à la disponibilité des ressources métier	Manque de motivation et d’implication des utilisateurs clés	Impliquer la MOA en phase de cadrage et identifier les mises à profit métier de SAP ERP. Bâtir ensuite une communication mobilisatrice, qui rassure les utilisateurs clés sur le bien-fondé du projet et insister sur leur rôle clé au sein du chantier fonctionnel
Risques liés aux objectifs et au périmètre du projet	Projet n’apparaissant pas apporter une réelle contribution au métier	Instaurer un processus de gel des évolutions progressif (éviter le gel « subit »), limiter la plage d’indisponibilité du système (durant la bascule) et insister sur les améliorations fonctionnelles, même mineures, induites par la montée de version. Par exemple, une meilleure intégration entre SAP et la suite de Microsoft Office
	Reconduction d’un trop grand nombre de développements spécifiques	Mettre en place une instance de gouvernance des spécifiques dès la phase de cadrage et solliciter l’adhésion des directions métier à une politique du Core Model et de retour au standard SAP
	Manque de formation et de sensibilisation des équipes internes à la nouvelle version	Identifier les acteurs clés du projet en interne (managers, consultants du CC SAP, utilisateurs clés, développeurs, architectes, etc.) et dispenser les formations adéquates (delta modules, sessions de sensibilisation SAP…)
Risques liés à l’outillage et aux bonnes pratiques de gestion de projet	Dimensionnement inadéquat des composants de l’architecture du système SAP	Dimensionner les serveurs, processeurs, disques et mémoire selon les préconisations SAP (abaques), puis procéder à des tests de performance au moyen d’outils du marché (temps de réponse, montée en charge)
	Mauvaise estimation de la charge liée aux tests	Utiliser des outils du marché permettant d’évaluer la charge liée aux tests : - identification des développements spécifiques, - évaluation de la charge liée à l’adaptation des spécifiques reconduits - évaluation de la charge de tests fonctionnels

Source : « Retours d’expérience sur la montée de version SAP ERP », publié par le Club des utilisateurs SAP francophones (USF)