Cet article sur les premiers pas à effectuer vers SAP S/4HANA a initialement été rédigé par Paul Hammersley, expert en sécurité et gestion des données SAP chez Epi-Use Labs. Vous pouvez retrouver l’original en anglais sur leur blog. 

La première des décisions concernant tout projet SAP S/4HANA est de choisir entre l’approche Greenfield (nouvelle installation S/4), Brownfield (conversion du système existant), ou, pour les cas plus complexes, une “transition sélective des données” (Selective Data Transition).

Le guide “Mapping your journey to S/4 HANA – A Practical Guide for IT Leadership ” suggère qu’un projet mené par le business sera généralement de type Greenfield, tandis qu’un  projet piloté par l’IT sera plutôt de type Brownfield. Il est donc important que les deux côtés participent aux débats dès le début, quel que soit le responsable du projet. Un tel ouvrage, mené en isolation de l’une ou l’autre partie, est voué à l’échec.

Pourquoi commencer par un bac à sable ?

Si vous décidez d’approfondir la piste Brownfield, SAP vous recommande de créer un bac à sable quatre mois en amont et vous suggère de simuler la conversion deux ou trois fois avant de commencer le projet proprement dit. Bien que cela puisse sembler intimidant, la majeure partie du travail sera en réalité effectuée lors de la phase “Sandbox” : le projet final n’en sera que plus simple et plus rapide.

Il est donc important de comprendre dès le départ que cette conversion ne ressemble pas aux précédentes upgrades que vous avez pu connaître.

SAP S/4HANA est une nouvelle ligne de produits

Tout d’abord, S/4 est une nouvelle ligne de produits. SAP entend par là que vos licences existantes ne seront pas reconduites, de sorte que vous devez discuter des différentes options et de leur coût avec votre responsable de compte SAP.

Notez que si l’approche Greenfield vous permettrait d’envisager les options S/4 Cloud ou S/4 Cloud Single Tenant, celles-ci ne sont pas compatibles avec les approches Brownfield ou Selective Data Transitions.

SAP S/4HANA est une nouvelle architecture : HANA 2.0 et Linux

Le deuxième facteur qui rend cette situation beaucoup plus difficile que les conversions précédentes est d’ordre technique. S/4 HANA nécessite HANA 2.0 et un système d’exploitation Linux pour le serveur contenant la base de données. Vous devrez donc construire une nouvelle architecture système, sauf si vous faites déjà tourner Business Suite sur HANA, auquel cas vous aurez quand même probablement besoin d’une mise à jour de la base de données.

Cette partie a également des implications en termes de hardware, puisque vous ne pouvez pas utiliser n’importe quel serveur pour changer de plateforme. Un environnement HANA préconfiguré ou un serveur capable de passer par le processus HANA TDI (Tailored Datacentre Integration) s’avère nécessaire.

Remaniement fonctionnel de SAP S/4HANA avant SUM

Le troisième facteur est un facteur fonctionnel. Avant de pouvoir entamer le processus SUM (Software Update Manager), vous devrez résoudre un certain nombre de changements fonctionnels causés par la simplifications de S/4. Ces changements sont indiqués dans la liste de contrôle des éléments de simplification (Simplification Item checklist) qui fait partie de l’outil de contrôle de l’état de préparation à SAP 2.0 (SAP Readiness Check 2.0).

Dans certains cas, ces contrôles mettent en évidence des informations simplement pertinentes (Relevance Check), mais dans d’autres il s’agit de changements obligatoires (Consistency Check), où la fonctionnalité utilisée n’est plus prise en charge.

Comprendre l’impact de ces contrôles rend non seulement le projet Sandbox très utille, mais peut même vous amener à revoir votre position sur l’approche Greenfield vs Brownfield. C’est la raison pour laquelle le projet Sandbox doit passer en premier.

Que se passe-t-il dans mon sandbox ?

Avant la mise à niveau de votre bac à sable, vous devrez charger les notes SAP pour installer la liste de contrôle des éléments de simplification. Dans la version 1809, il y a environ 600 de ces éléments qui sont contrôlés, dont 40 à 80 devraient se révéler pertinents pour un système donné.

Avec S/4HANA, certaines fonctionnalités des systèmes périphériques autonomes (comme GTS) sont fournies directement dans S/4HANA, mais remplacent des fonctionnalités plus simples déjà présentes dans le même domaine de l’ERP. Ainsi, toute personne utilisant actuellement la fonctionnalité Foreign Trade dans l’ERP devra s’adapter à la nouvelle fonctionnalité International Trade disponible dans S/4HANA. Mais si vous utilisez actuellement le GTS en tant qu’add-on dans votre ERP, il faudra le désinstaller avant de commencer l’upgrade.

Comme vous pouvez le voir, certains des éléments de la liste de contrôle ne consistent pas simplement à appliquer une note SAP ou à modifier un paramètre de configuration. Ils pourraient déclencher des projets supplémentaires qui devront êtres finalisés avant que la mise à niveau puisse avoir lieu. Il est également possible que le Métier envisage des solutions externes à intégrer au projet au lieu de passer directement à la fonctionnalité recommandée par SAP.

Poursuivre des cibles mouvantes : versions et champ d’application

Il est important de comprendre ici que chaque release S/4 On-Premise apporte plus de simplifications. Donc potentiellement plus d’obstacles majeurs à surmonter. Mais il n’est plus possible de passer à une version de S/4 antérieure à 1709. Donc, plus vous commencerez tard, plus vous aurez de travail pour atteindre votre objectif.

Mon opinion personnelle est que cela vise à accélérer l’adoption de S/4 dont SAP a tant besoin. Je trouve cependant étrange qu’un client sur Ehp8 et capable d’y rester jusqu’en 2025 se retrouve, entre leur version actuelle et la plus récente, avec des versions qui ne seraient plus disponibles. C’est une situation nouvelle pour les clients SAP.

L’activité d’intégration client-fournisseur (CVI) doit également être entreprise avant que la migration ne puisse commencer. Bien que le processus ne soit pas particulièrement long sur le plan technique, il peut ouvrir toute une boîte de Pandore en ce qui concerne la qualité et le nettoyage des données – ce qui peut également conforter le business dans le choix d’une approche Greenfield.

Du point de vue de la gouvernance et de la sécurité des données, même si chaque fournisseur et client doit avoir un BP (ainsi qu’un employé), les données Master Client/Fournisseur restent là où elles sont. Ces données sont toujours dupliquées dans les mêmes tables, sans qu’on sache encore si et quand elles seront supprimées.

Vous pouvez maintenant changer de plate-forme et lancer le SUM

Une fois ces étapes franchies, nous pouvons basculer sur la plateforme à Linux/HDB, ou le faire dans le cadre de l’upgrade avec l’option de migration des bases de données (DMO).

Bien que ce projet consiste principalement à déterminer quelle voie suivre, il faut garder à l’esprit que le projet final nécessitera probablement des temps d’arrêt importants, ce qui doit être pris en compte et noté dans les conversions Sandbox.

Les vérifications des éléments de simplification également validées avant la migration à proprement parler, le processus SUM peut alors commencer. Même si les contrôles sont a priori tous résolus, il se peut que vous rencontriez d’autres problèmes qui nécessitent l’application de Notes SAP.

Vérifiez votre code spécifique

Une fois le système mis à niveau, vous pouvez alors utiliser le cockpit de test ABAP pour commencer à examiner votre code maison.

Avec l’éditeur ABAP Eclipse, vous pouvez également utiliser les options de “correction rapide” lorsque le changement nécessaire est simple, comme par exemple l’ajout de “ORDER BY” à une instruction SELECT parce que les données ne sont plus triées dans la table. Si vous disposez d’extensions tierces, vous devrez également vérifier qu’elles proposent une version compatible avec votre version S/4 prévue. Il s’agit d’une conversation que vous devriez engager en amont, afin que la version appropriée soit appliquée au bac à sable lorsque la correction du code spécifique aura lieu.

Cela pourrait également être une bonne occasion de se renseigner sur Fiori et les changements d’autorisations imposés par S/4. Il existe un grand nombre d’applications Fiori disponibles, généralement pour fournir des fonctionnalités beaucoup plus réduites que les grosses transactions auxquelles les utilisateurs métiers sont habitués. Les applications Lighthouse Fiori peuvent constituer un bon point de départ, mais il vous faudra probablement une solution dédiée pour aller au delà du standard.