J’ai conduit 5 projets « montée de version SAP »
        • De R3 4.6 -> ECC 5.0
        • De ECC 5.0 -> ECC 6.7, sous Hana
        • BW 3.5 -> BW 7.0
        • BW 7.0 -> BW 7.3, sous Hana
        • BI 3.1 -> BI 4.1

Et je suis en train d’ouvrir un projet ECC 6.0 -> S/4 Hana dans mon entreprise !

Dès ma première montée de version, j’ai retenu un principe très fort : organiser les projets upgrade SAP pour obtenir un effet « waouh » de la part des utilisateurs, c’est-à-dire en leur proposant des nouveautés.
C’est en effet le piège principal d’une montée de version SAP : mener (sur R3 – ECC) un projet long (12 mois), couteux, et mobilisant une grande partie des équipes, pour au final, ne rien obtenir de vraiment nouveau.

C’est pourquoi je mène dorénavant un projet montée de version suivant l’axe « améliorations »
        • Performance (infra, Hana)
        • Ergonomie (WebDynpro, Adobe Forms, SAP Fiori, Personas)
        • Nouvelles fonctionnalités

Une montée de version SAP, c’est en général :
        • 3 négociations, où il faut s’investir totalement :
                - Avec SAP (Audit, licences ECC, licences Hana)
                - Avec le constructeur (infrastructure)
                - Avec l’intégrateur
        • 3 projets à mener en parallèle :
                - L’infrastructure et l’upgrade
                - la mise en œuvre de nouvelles fonctionnalités, d’une nouvelle ergonomie (sur quelques transactions)
                - L’accompagnement des utilisateurs
        • 2 équipes à mobiliser :
                - La DSI, ou comment ne pas bloquer tous les dossiers pendant le déroulement du projet montée de version
                - Les keys users : comment les convaincre de passer – encore – du temps à recetter SAP !

En tant que DSI, les montées de version en général, et celles de SAP en particulier, sont au centre de mon travail. Il faut en effet de nombreuses réunions et beaucoup de persuasion pour amener une Direction Générale à accepter de se lancer dans ces projets …