Faut-il passer de R/3 à SAP ERP ?
par mail
l'article
Des différentes versions du progiciel de gestion intégré R/3 de SAP, seule la 4.7 est encore en phase de maintenance standard. L'édition 4.6c est entrée en maintenance étendue il y a près d'un an. Or elle équipe beaucoup des clients de l'éditeur allemand. Pour eux, SAP prône la montée de version vers son nouveau standard, SAP ERP version 6.0, lancée en 2006. Une mouture jugée assez stratégique par l'éditeur pour qu'il en étende la durée de maintenance standard à sept ans (au lieu de cinq pour ses produits précédents). Ou qu'il lance, avec le club des Utilisateurs de SAP Francophones (USF) et le cabinet de conseil Bearing Point, un “ Observatoire de la migration ”. Objectif de l'éditeur : avoir fait migrer sa base installée vers ERP 6.0 avant fin 2009 ou 2010. Pour l'instant, le taux d'adoption annoncé en France est de 26 %, en recensant les clients ayant migré mais aussi ceux qui ont juste précommandé les clés logicielles.
Des arguments qui laissent de marbre les utilisateurs
Pour inciter à la montée de version, SAP propose depuis 2001 des contrats particuliers aux utilisateurs de R/3. Les 75 % de clients français qui en bénéficient n'ont pas de supplément de licences à payer à l'heure de migrer. Mais SAP communique aussi, comme lors de la convention de l'USF en octobre dernier, sur les atouts de SAP ERP. Si R/3 4.7 était compatible avec le monde Java et que ERP 5.0 s'appuyait sur Netweaver, la version 6.0 est, elle, totalement basée sur une architecture SOA. D'où une possible ouverture vers le monde non SAP, et une intégration facilitée, par exemple en cas de croissance externe de l'entreprise. Un avantage apporté par le bus d'entreprise de SAP, Pi (anciennement nommé Xi), dont l'usage n'est d'ailleurs pas obligatoire : “ Les utilisateurs majoritairement SAP devraient l'utiliser, les autres peuvent conserver un bus différent ”, estime Eeng Ang Ong, responsable de la ligne SAP pour IBM Global Services.
Egalement mis en avant, l'Unicode, qui gère les différences de caractères entre les pays, est une réalité depuis la version 4.7. En réalité, rien n'oblige à passer à l'Unicode, à moins d'être utilisateur de MDMP, le précédent mode de gestion des caractères exotiques qui n'est plus supporté dans SAP ERP 6.0. D'autres nouveautés concernent les différents modules, notamment le Grand Livre de la partie finance ou, encore, l'intégration du décisionnel.
Mais, si l'on en croit les échos qui remontent du terrain, l'attrait pour ces nouveautés n'est pas le principal moteur de la montée de version. La publication d'enquêtes réalisées par l'USF et l'ASUG (Americans SAP Users Group) auprès de leurs adhérents fait ressortir que, dans les deux cas, la fin de maintenance standard est la première raison pour migrer. 72 % des répondants francophones l'évoquent (réponses multiples) et 23 % de leurs homologues américains la citent même comme unique raison. Quant à l'architecture SOA, elle n'est encore qu'en phase d'évangélisation en entreprise : une étude HP/PAC auprès de 110 sociétés utilisatrices SAP françaises montre que seules 13 % pensent l'adopter d'ici à 2010.
Un retour sur investissement plutôt long
Dès lors, faut-il migrer ? Rares sont les utilisateurs qui, tel Didier Roux, DSI de la société Hammel, se laissent la liberté d'envisager “ la montée de version, la maintenance du noyau R/3 en interne sans support de l'éditeur, voire un changement de progiciel ”. La plupart des utilisateurs suivent la politique de l'éditeur. Pourtant, ceux qui choisissent de migrer doivent encore convaincre leur direction générale. Ce qui n'est pas forcément facile, cette montée de version étant surtout technique, et n'apportant, à court terme, que peu d'avantages en regard des coûts d'un projet pouvant durer de trois mois à plus d'un an. “ Heureusement, une partie du coût peut être reportée sur le budget de formation ”, note Daniel Binet, directeur général de la PME Zhendre, qui a achevé sa migration technique il y a près d'un mois.
Faut-il, d'ailleurs, effectuer un changement de version uniquement technique ou en profiter pour élargir le périmètre fonctionnel ? Pour Eric Remy, président de la commission technologie de l'USF, “ introduire des gains fonctionnels entraîne l'adhésion des utilisateurs à un projet dont, sinon, ils ne verraient pas l'utilité ”. Plusieurs intégrateurs conseillent toutefois de ne pas trop complexifier le projet, et surtout de le séparer en deux phases : la migration technique, puis une éventuelle évolution fonctionnelle.
Une remise à plat des développements spécifiques
Que ce soit à périmètre fonctionnel identique ou étendu, cette montée de version est – comme les autres – l'occasion de remettre les choses à plat techniquement. La phase initiale du projet permet d'auditer l'existant, et notamment de recenser les développements spécifiques, dont la quantité est un critère important pour évaluer la durée du projet. Suite à cet inventaire, il est conseillé de remettre à plat les développements spécifiques Abap : en se débarrassant du code inutilisé, en remplaçant certains développements par des fonctions non proposées à l'époque, ou en opérant des retours au standard des personnalisations. Lors de sa migration, la société Audioptic a ainsi éliminé. 10 % de ses développements personnalisés. Quant au code Abap spécifique que l'on souhaite conserver, il apparaît peu pertinent de le redévelopper dans un autre langage : “ Cela aurait un coût important, pour un gain essentiellement idéologique, juge Eric Remy. Il vaut mieux le laisser tel quel, mais en revanche effectuer les prochains développements avec un langage SOA. ”
Autre métrique importante : la quantité d'interfaces avec d'autres blocs du système d'information impactées par la migration. 36 % des répondants au sondage de l'USF déclarent en avoir plus de 50, ce qui demandera un effort important.
Pour ceux dont l'implantation ou l'activité internationale nécessite l'utilisation d'Unicode, il faut avoir à l'esprit qu'il peut y avoir un impact sur le matériel. Comme sur la base de données, qu'il faut exporter, convertir et réimporter. De l'avis de Guillaume Chavy, consultant chez SAP, comme de Christophe Emelien, expert en migration SAP pour la SSII CSC, “ l'impact est faible avec une base de données Oracle ”, mais plus important avec celles de Microsoft et d'IBM. A noter que la compatibilité de SAP ERP 6.0 avec les bases de données du marché n'est pas la même que celle de R/3, et il faudra peut-être parfois migrer aussi la base de données. Ce qui peut être l'occasion de rajeunir toute son architecture. Chez Zhendre, par exemple, elle était figée depuis l'installation de R/3 4.0b en 1999. “ La montée de version s'est accompagnée d'une migration de SQL Server 7 à SQL Server 2005. Serveurs et réseaux ont été actualisés, pour des temps de réponse divisés par 10 ”, dit Daniel Binet, directeur général de Zhendre.
Un risque de pénurie de consultants
Ceux qui préparent leur migration doivent penser à quel moment la planifier. Il faut, en effet, pouvoir figer les processus pendant un certain temps, et inscrire le projet dans le calendrier de l'entreprise, sans gêner ses autres projets. Mais il faut également tenir compte des possibilités des partenaires intégrateurs spécialisés. D'après eux, 2007 est l'année du cadrage et 2008 devrait être celle qui verra le plus de migrations ; un avis que partage d'ailleurs l'éditeur. D'où une éventuelle crainte d'une pénurie de consultants SAP. Pour Eeng Ang Ong, cette fin de maintenance “ met le feu au marché ” des consultants SAP. Or, “ ce marché est déjà tendu ”, rappelle Thierry Bouvier, responsable de l'activité SAP de Bearing Point. Plus optimiste, Christophe Emelien penche pour un équilibre de l'offre et de la demande : “ Lorsque l'on monte de version, on ne lance pas d'autre projet. ” Toutes ces sociétés de conseil se préparent, en tout cas, à la migration vers SAP ERP depuis 18 mois. Pour que ses consultants se fassent la main, la SSII GFI Informatique les a fait travailler sur sa propre montée de version de R/3 4.7 à ERP 6.0.
Le chiffre
72 % des 89 entreprises qui ont répondu au récent questionnaire du club des utilisateurs SAP francophones (USF) disent migrer vers la version la plus récente de SAP à cause de la fin de la maintenance standard de SAP R/3 (possibilité de réponses multiples).
Glossaire
Le nom du dernier progiciel de gestion intégré de l'éditeur allemand SAP. Basé sur la plate-forme SOA Netweaver, il fut également nommé mySAP ERP, mySAP.com. La version actuelle, SAP ERP 6.0 (ex SAP ERP 2005), s'appuie sur les composants ECC6 (Enterprise Core Component).
La précédente famille de progiciels de SAP. La version la plus courante est la 4.6c. La version Entreprise est aussi appelée 4.7.
Mickaël Lenoir, responsable du centre de compétences SAP d'Audioptic
“ Le plan stratégique à 5 ans de notre entreprise prévoit la mise en place, grâce à Netweaver, d'autres applications ”
Didier Roux, directeur des systèmes d'information du groupe Robinetteries Hammel
“ Parmi les alternatives, nous envisageons de maintenir nous-mêmes le noyau sans le support de l'éditeur, voire de changer de progiciel ”
Trois types de maintenance
En maintenance standard, le coût annuel est de 17 % du montant des licences. La maintenance étendue (trois ans) passe de 19 % du montant annuel des licences la première année, à 23 % les deux suivantes. Ensuite, l'éditeur propose une maintenance spécifique, dont “ l'impact financier est inconnu ”, dit Guillaume Chavy, consultant chez SAP.
Une migration difficile à justifier
Si elle n'offre pas une vue globale du parc français, cette étude renseigne sur l'état du parc actuel. Un autre sondage, de l'USF, montre que certaines sociétés sont encore équipées de versions ultérieures, 3.1 par exemple.
Si la sécurité des infrastructures et des accès à l'application est la première source de préoccupation pour les utilisateurs sondés, la gestion des montées de version arrive en seconde position, et se fait notamment sentir sur la frange médiane des PME (entreprises de 1 000 à 5 000 employés).
La fin de la maintenance standard est, et de loin, la première raison invoquée pour migrer.
La difficulté à justifier le coût du projet se détache nettement et se retrouve loin devant les autres freins à la montée de version.
Guy Chemisky (Condat) : “ l'avantage lié au SOA n'a pas joué dans notre décision de changer de version ”
“ Condat avait planifié l'acquisition d'une société pour le second semestre 2007. Et comme nous voulions migrer notre application SAP R/3 4.6c, il fallait le faire avant, pour mener les projets les uns après les autres. Il a été compliqué d'obtenir de SAP les informations sur le meilleur parcours à suivre : migrer vers la 4.7, ou passer en SAP ERP. On a fini par faire le grand saut vers ERP 6.0, même si, pour une PME comme la nôtre, le coût d'évolution des licences reste excessivement cher, en partie parce que notre coût d'acquisition avait été assez bas. En revanche, l'absence de développements spécifiques permet de se passer d'intégrateur. Nous avions des craintes quant à la compatibilité de SAP ERP et de SAP CRM 3.0, dont l'installation avait été très difficile. Mais cela s'est bien passé. Composante importante du projet : pour remporter l'adhésion des utilisateurs, il a fallu les impliquer dans ce qui n'était a priori qu'une migration technique. ”
Solène Lajoux et Erwan Le Moigne (Centigon France) : “ nous voyons mal ce que passer à SAP ERP peut nous apporter ”
“ Nous avons installé la version 4.7 de SAP R/3 en janvier 2005. Nous voulions rester le plus standard possible pour des raisons de budget et de fiabilité : il y a donc très peu de développements spécifiques. Nos 55 utilisateurs se servent des modules FI, CO, MM, SD, PP et PS. Concernant SAP ERP 6.0, nous en avons eu quelques démonstrations lors de réunions avec le groupe des Sappeurs de l'Ouest [NDLR : association informelle d'utilisateurs SAP]. Mais l'offre de SAP n'est pas très claire, nous avons du mal à savoir ce que cela va apporter d'un point de vue technique et fonctionnel. Certaines informations sont disponibles, mais cela reste du langage d'informaticien. C'est l'architecture technique qui est mise en avant, mais l'utilisateur final ne verra pas la différence. Pour l'instant, notre version fonctionne très bien. Nous serons tout de même amenés à réfléchir à la montée de version, qui peut être assez longue et coûteuse. ”
