Ceci est le premier d’une série d’articles que j’écrirai concernant la mise à niveau de votre système SAP. 2010 devrait être l’année de la mise à niveau (vous l’avez entendu ici en premier – peut-être pas), car de nombreux clients SAP considéraient une mise à niveau comme une dépense facilement évitable au milieu du carnage économique des 12 à 18 derniers mois. En outre, SAP s’efforce d’amener ses clients à abandonner les versions antérieures et à passer à ECC 6.0 et à divers EHP (packs d’amélioration) afin que les mises à niveau appartiennent au passé.
Excusez une note de scepticisme quant à la fin des mises à niveau telles que nous les connaissons, je soupçonne que le chemin et le mécanisme pour obtenir de nouvelles fonctionnalités vont changer. La méthodologie et l’approche des manuels vont changer, mais je soupçonne que les clients SAP hésiteront à abandonner complètement les approches précédentes en matière de mises à niveau. Cela ressemble à un sujet pour un prochain article de blog.
Dans ces articles, j’aborderai certaines des considérations initiales avant de vous lancer dans une mise à niveau, puis j’aborderai les moyens d’exploiter certains de vos actifs existants pour rendre le processus aussi réussi que possible. En cours de route, je discuterai de l’impact sur votre environnement SAP, vos systèmes non SAP et d’autres projets en cours que vous pourriez avoir en cours. Comme l’a dit un sage pour qui j’ai travaillé – et je paraphrase – « nous ne voulons pas reconstruire l’avion en plein vol ». Essayer de le faire entrer dans le hangar sans passagers à bord est un objectif noble, mais peut-être pas tout à fait réaliste.
Pour en savoir plus sur les mises à niveau SAP, téléchargez les livres blancs :
Liste de contrôle de mise à niveau SAP
Analyse des risques de personnalisation dans un projet de mise à niveau SAP
Comme toujours, les commentaires et réactions sont les bienvenus, mais je vous demande d’être courtois. Vos expériences ne sont pas les mêmes que les miennes, je peux apprendre de vous et j’espère que vous pourrez apprendre un peu de moi. Commençons.
Mises à niveau SAP : commencez par la fin en tête
Il existe de nombreuses raisons pour lesquelles vous souhaitez mettre à niveau votre système SAP et ces raisons détermineront probablement votre approche, la manière dont vous positionnerez le projet et l’exécuterez. Les facteurs d’influence comprennent, sans s’y limiter :
- La version actuelle est ancienne et fait l’objet d’une maintenance SAP étendue ou est sur le point de passer à une maintenance étendue.
- Les changements récents dans les licences SAP incitent à la mise à niveau
- D’autres parties de votre environnement et de votre infrastructure système évoluent et une mise à niveau SAP facilite ou permet de faciliter certaines de ces modifications.
- De nouvelles fonctionnalités sont nécessaires pour prendre en charge les acquisitions
- De nouvelles fonctionnalités sont nécessaires pour mettre hors service les systèmes existants
- De nouvelles fonctionnalités sont nécessaires pour étendre l’empreinte SAP dans votre organisation
- Le développement personnalisé devient trop lourd à maintenir et peut être mis hors service par les fonctionnalités standard de la nouvelle version.
En bref, il y a probablement plusieurs raisons pour lesquelles vous souhaitez effectuer une mise à niveau et votre organisation a d’autres considérations en plus de celles répertoriées. En identifiant les moteurs de votre mise à niveau, vous devriez être en mesure de déterminer qui souhaite le plus que cela se produise, ainsi que ceux qui ne sont pas partisans. En outre, vous déterminez qui a le plus à gagner à court, moyen et long terme. Tout cela est utile pour monter le pitch
Mise à niveau technique SAP par rapport à la mise à niveau fonctionnelle SAP
Il y a beaucoup de discussions autour des avantages et des inconvénients d’effectuer une mise à niveau technique par rapport à une mise à niveau fonctionnelle. Dans une certaine mesure, je considère cela comme un faux choix : une mise à niveau technique impliquera toujours un travail de mise à niveau fonctionnelle – c’est une question de degré. (La seule clause de sauvegarde ici pourrait être si vous avez réellement installé SAP sans code personnalisé, mais je n’ai pas encore trouvé d’installation sans code personnalisé).
Le principal argument de vente d’une mise à niveau technique est qu’il s’agit de l’option la plus rapide et la moins intrusive. Tout cela est vrai, mais vous devez néanmoins suivre le processus de mise à niveau plusieurs fois pour vous assurer qu’il fonctionne sans problème et vous devez tester le système mis à niveau pour vous assurer que vous pouvez toujours exécuter vos processus métier. Même un système SAP avec des quantités limitées de code personnalisé doit générer des rapports sur le code personnalisé, ce qui vous oblige à effectuer un certain travail et à prendre des décisions à ce sujet. Généralement, le travail et les décisions ont plusieurs résultats possibles :
- Le code personnalisé est toujours nécessaire car la nouvelle version ne prend pas en charge les fonctionnalités requises. Vous devez donc conserver le code et le tester avec la nouvelle version.
- Le code personnalisé n’est plus nécessaire car la nouvelle version offre les fonctionnalités requises. Par conséquent, le code est mis hors service et vous devez tester le processus standard.
- Le code personnalisé doit être modifié d’une manière ou d’une autre pour fonctionner avec la nouvelle version. Encore une fois, cela conduit à des tests et à une vérification des processus métier.
Chaque objet personnalisé doit appartenir à l’un des trois compartiments décrits ci-dessus, ce qui commence par identifier les plans de travail et les activités.
Une mise en garde concernant l’identification des objets personnalisés : les environnements de développement contiennent souvent des objets à moitié terminés et abandonnés, des travaux en cours et des objets qui n’ont jamais bougé. Ces objets peuvent inutilement gonfler la liste des objets qui doivent être examinés, donc obtenir une liste de la production ou du système d’assurance qualité peut produire une liste plus précise.
Ainsi, même dans le cadre d’une mise à niveau technique, je me suis heurté à la nécessité d’effectuer des travaux fonctionnels. Si les objectifs globaux de mon projet de mise à niveau incluent le déploiement de nouvelles fonctionnalités, j’ai les mêmes considérations qu’une mise à niveau technique, mais je dois maintenant définir, concevoir, développer, intégrer, tester et déployer la nouvelle fonctionnalité. Cela signifie clairement plus de travail, plus de temps et plus de dépenses avant la mise en ligne de la mise à niveau.
En bref, j’aime considérer les mises à niveau techniques et fonctionnelles comme deux cercles qui se chevauchent dans un diagramme de Venn : la taille du chevauchement est ce que j’essaie de contrôler lorsque j’qualifie mon projet de mise à niveau technique ou de mise à niveau fonctionnelle.
Trouver votre chemin de mise à niveau SAP
Un autre facteur lors de la planification de la mise à niveau de SAP est d’où vous partez et où vous souhaitez arriver. Il se peut qu’il n’y ait pas de chemin de migration direct de votre version SAP actuelle vers votre version cible, auquel cas vous devez identifier les étapes intermédiaires et l’impact que cela a sur les délais globaux et la complexité. En fonction du caractère unique de votre environnement, vous devrez peut-être entreprendre des actions au niveau de la version intermédiaire avant de pouvoir accéder à la version finale.
Faire le pitch d’une mise à niveau SAP
D’après mon expérience, il existe rarement un seul facteur concis pour effectuer une mise à niveau et chaque installation SAP comporte différents facteurs qui influencent la décision. Trouver le bon argumentaire avec une justification convaincante du coût est assez délicat : une mise à niveau (principalement) technique est souvent présentée comme un précurseur de choses plus importantes (une gratification différée, si vous préférez), alors qu’une mise à niveau fonctionnelle apporte de la valeur plus rapidement.
Répondre aux demandes de vos décideurs et à vos budgets est toujours un défi, mais vous devez également vous rappeler que les mises à niveau font partie du coût total de possession avec SAP. À un moment donné, vous devez effectuer une mise à niveau et il est inévitable de trouver un moment dans les calendriers métier et informatique pour concentrer les ressources sur le projet.
Étapes suivantes Préparation d’une mise à niveau SAP
Dans mon prochain article sur les mises à niveau, j’expliquerai comment vous pouvez exploiter et réutiliser une partie du travail effectué sur des projets antérieurs afin d’accélérer votre mise à niveau.