Faut-il passer de R/3 à SAP ERP ?

SAP incite à migrer vers la dernière génération de son progiciel, à l'architecture totalement SOA. Mais pour ceux qui passent à l'acte, ce n'est pas là une raison majeure.

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.
0

Votre opinion

Postez un commentaire