Transformation vers S/4 et Hana : comment s'y prendre ?

S/4 n'est pas un tigre de papier

Ulysse a eu dix ans pour rentrer de Troie et est arrivé chez lui à Ithaque en mendiant. Le client de SAP ne dispose que de cinq ans environ et il ne veut pas passer pour un échoué, mais pour un projet de gestion du changement réussi.

Un "changement de version" n'est pas une situation nouvelle ou inhabituelle. Depuis le succès de R/2, il est de bon ton de ne customiser un système SAP qu'avec l'aide de conseillers et d'experts expérimentés. Mais avec Hana et S/4, il ne s'agit pas seulement de personnaliser !

Comme le montre clairement le rapport de Heiko Friedrichs, Hinrich Mielke et Achim Zimmermann, les exigences sont cette fois beaucoup plus élevées. Il s'agit de la transformation numérique du monde SAP. Il ne s'agit pas d'un changement de version technique.

Lors de la transformation vers S/4, il faut également tenir compte des aspects économiques, organisationnels, techniques et de licence. Pour cela, le recours à des consultants et des experts est une démarche tout à fait naturelle.

Dans la phase de "transformation numérique", le client SAP existant a besoin de beaucoup d'expérience et de connaissances qui ne seront plus utilisées quotidiennement dans l'exploitation opérationnelle. Un système SAP correctement paramétré n'est certes pas un mouvement perpétuel, mais tout de même une machine bien huilée qui n'a besoin que d'un rafraîchissement temporaire de son sang.

Le recours à des conseillers et à des experts, comme le font les équipes de Devoteam Alegri et de QPCM, est donc le processus de customisation naturel de la communauté SAP. Chez SAP, on voit les choses de la même manière, sauf que l'inventeur de Hana et le fournisseur de S/4 a commis une erreur : les conseillers et les experts ne sont pas disponibles à volonté et leur journée ne compte que 24 heures.

Les très gros clients SAP ont déjà acheté il y a de nombreux mois des milliers de jours/homme auprès des sociétés de conseil internationales. Il n'y aura plus de ressources disponibles d'ici 2025.

Il faut remercier les partenaires SAP de taille moyenne d'avoir commencé il y a longtemps à développer à leurs frais des connaissances sur Hana et S/4, dont de nombreux clients existants ont actuellement un besoin urgent. Ce n'est probablement qu'en 2022 que l'on décidera si SAP doit ou non tourner la vis du temps, compte tenu des ressources limitées en consultants.

Cependant, attendre n'est en aucun cas une option. Et encore un conseil pour la communauté SAP. En fait, cette transformation numérique concerne deux sujets : Base de données et ERP.

Hana peut être une base de données fantastique, mais aussi un défi. Achim Zimmermann de QPCM pourrait remplir des livres à ce sujet. S/4 est un nouveau modèle et concept ERP. Heiko Friedrichs et Hinrich Mielke de Devoteam Alegri peuvent le prouver à l'aide de nombreux exemples.

Dans le texte suivant, le sujet est brièvement expliqué à l'exemple du nouveau grand livre. Mais dans tous les cas, les domaines FI/CO et logistique sont concernés. S/4 n'est donc pas un tigre de papier - au contraire : c'est un défi auquel il faut consacrer beaucoup d'attention, même avec l'aide d'experts ! (pmf)

Il y a une date limite officielle en 2025

Le problème : le support pour ECC 6.0 est garanti par SAP jusqu'en 2025. Pour la période suivante, seul le support pour S/4 Hana est signalé en l'état actuel. Cela signifie que le passage à S/4 doit être terminé dans cinq ans et demi.

Ce délai est plus court qu'il n'y paraît. Comme pour le passage à l'an 2000 et à l'euro, il est de plus en plus difficile de recruter du personnel qualifié à mesure que la date butoir approche. Cela vaut en interne comme en externe, ainsi qu'au niveau mondial. Le défi est similaire : Il n'était pas question de "ne pas participer" au passage à l'an 2000 ou à l'euro.

De même, il convient de noter qu'en plus de la chaîne technologique (passage à une nouvelle base de données, éventuellement à un nouveau système d'exploitation), il faut également considérer les processus commerciaux et les développements propres.

Parallèlement, il convient de clarifier les questions relatives à la stratégie frontale (Fiori), d'intégrer de nouveaux services basés sur le cloud et, de manière générale, d'examiner et d'évaluer les possibilités offertes par le cloud (IaaS, PaaS, SaaS).

Tous les processus commerciaux et les développements propres doivent être passés au crible, y compris ceux qui fonctionnaient jusqu'à présent en dehors d'ECC. Dans le cas le plus simple, ces processus commerciaux et ces développements propres sont simplement adaptés aux nouvelles possibilités.

Les nouvelles opportunités ne sont donc qu'incomplètement exploitées. Il est préférable de se familiariser avec les nouvelles possibilités et de les utiliser au mieux pour les modèles commerciaux existants.

Ces tâches sont toutefois connues depuis quelques années - chaque DSI ou directeur SAP aura préparé des solutions adéquates et mis en place une gestion de programme correspondante. Il ne faut pas sous-estimer les dépenses qui en résultent. Ils sont bien investis - et peuvent être réduits de moitié avec un partenaire expérimenté, selon une règle générale.

Mais le problème principal est généralement le soutien des services spécialisés : Il manque des utilisateurs clés qui n'ont pas le temps et souvent pas la marge de manœuvre existante ou accordée pour "penser différemment".

Dans certains cas, cela signifie que le DSI doit pousser le passage à S/4 Hana auprès de ses clients, les départements, que le projet est perçu comme mal aimé et qu'il est donc plutôt mené à la traîne.

Deux domaines sont directement et immédiatement concernés par le passage à S/4. Dans le domaine FI/CO, la conversion obligatoire au nouveau grand livre, l'intégration client-vendeur (CVI) et la convergence de FI et CO créent un besoin d'action considérable.

Les processus commerciaux établis doivent être révisés, les applications tierces doivent être testées à nouveau et le reporting doit être établi à partir de la structure modifiée des tableaux. Les améliorations sont tangibles, les avantages sont perceptibles - il faut donc mettre en place un projet de changement.

S/4 plus Ariba

Dans le domaine de la logistique, des changements importants doivent également être gérés. Dans ce cas, les avantages commerciaux sont toutefois plus immédiats et le retour sur investissement plus facile à présenter. Un détail techniquement intéressant est l'utilisation du "pull" pour des informations de statut à court terme provenant de systèmes tiers, par exemple l'emplacement des marchandises en cours de transport.

Ainsi, le "pull" remplace ici le "push" traditionnel et réduit la charge du système. De même, la connexion intégrée d'Ariba en tant que plateforme d'approvisionnement réduit les ruptures de médias et permet de concevoir des processus de bout en bout dans l'univers SAP.

L'idéal est toutefois d'établir des processus commerciaux nouveaux et entièrement modifiés, qui sont possibles en raison des nouvelles circonstances. Pour ce faire, il est nécessaire de disposer d'un savoir-faire sur les possibilités professionnelles et techniques et de "penser en dehors de la boîte".

Un partenaire avec un regard neuf accélérera énormément ce processus initial et l'enrichira constamment grâce à son point de vue extérieur. C'est la seule façon d'avoir une longueur d'avance sur ses concurrents.

Tous ces changements auront un impact sur la collaboration entre les services spécialisés, l'informatique et les partenaires externes. Pour atteindre l'agilité nécessaire, il faudra des équipes interdisciplinaires qui comprennent et, dans l'idéal, parlent également le langage technique des spécialistes respectivement impliqués.

Une répartition classique entre client et prestataire de services n'est pas prometteuse. Ce n'est qu'avec une égalité collégiale et beaucoup d'initiative personnelle que le changement se réalisera dans un contexte propice à l'atteinte des objectifs.

Nous pouvons dire d'emblée que cela continuera à être la recette du succès après le changement, pour une utilisation agile et créatrice de valeur des nouvelles possibilités. Ce changement est donc également un changement dans l'organisation, la collaboration entre les différents secteurs et la perception des contributions commerciales.

Grâce à la méthodologie S/4 Booster, Devoteam Alegri dispose d'une approche simple et peu invasive pour présenter à ses clients les changements et les avantages de S/4 en un temps record. Et ce, en utilisant les processus, les données et les procédures du système ECC 6.0 existant - dans un S/4 allégé, relié au système du client.

S/4 Booster & iHAL

Il est ainsi possible d'expérimenter rapidement les avantages de S/4 et Hana - avec ses propres données et processus. Ce S/4 peut par exemple être déployé à court terme à partir du cloud (déjà réalisé avec Azure) et, en cas d'évaluation positive, être mis en place sur site.

L'avantage est qu'un service spécialisé peut rapidement faire l'expérience des avantages de S/4 avec ses propres données et processus - et qu'il soutiendra donc cette transformation sur le plan du contenu et de la morale.

Un autre exemple est l'iHAL (intelligent Hana Assurance List), développé par le partenaire SAP QPCM : SAP Hana évolue rapidement. Comme pour chaque évolution d'un logiciel, chaque révision contient, outre des améliorations et de nouvelles fonctions, également des bugs. Ceux-ci peuvent concerner aussi bien les anciennes que les nouvelles révisions.

Les erreurs logicielles sont graves, car elles ne peuvent être interceptées par aucune solution HA. Pour minimiser les risques liés aux erreurs logicielles lors de l'exploitation de Hana, il faut vérifier de manière cyclique les avis SAP nécessaires.

La vérification des indications - adaptées à son propre scénario - peut vite devenir fastidieuse. Avec l'iHAL, QPCM a créé un outil qui permet d'effectuer ces contrôles de manière rapide, efficace et efficiente.

Cloud, IaaS et gouvernance

Ces exemples montrent comment les technologies aident les clients à passer à S/4. De même, l'utilisation du cloud en tant qu'IaaS est un moyen éprouvé de mettre en place des tests, des projets et des systèmes de formation en quelques heures ou jours, au lieu de s'occuper de l'achat de matériel informatique sur site ou chez un sous-traitant.

Tant que l'on exploite IaaS dans le modèle Pay-as-you-go, les systèmes peuvent également être redimensionnés ou décommissionnés en quelques heures. Cela a pour conséquence qu'il n'y a plus aucun risque de dimensionnement. Ce qui ne convient pas est adapté - avec le temps d'arrêt d'un "boot".

Cette préparation et ce déstockage doivent être accompagnés des processus commerciaux correspondants. Dans le cas contraire, une prolifération de systèmes peut rapidement apparaître - ce qui entraîne une augmentation correspondante des coûts.

Il ne s'agit pas d'un danger théorique, les expériences les plus diverses des clients parlent d'elles-mêmes. Bien entendu, l'utilisation de services en nuage doit être accompagnée d'une gouvernance appropriée. C'est là qu'un partenaire expérimenté peut raccourcir de manière décisive le temps de préparation, afin que l'agilité du cloud puisse être utilisée rapidement et facilement.

Le choix d'un fournisseur de cloud pour IaaS - abordé de manière systématique - est l'un des projets préliminaires les plus légers pour la plupart des clients : Il doit être supporté par SAP, répondre aux exigences de conformité et de certification et les sites proposés par le fournisseur doivent correspondre aux exigences et aux contraintes techniques.

Un aspect important est l'intégration du fournisseur de cloud dans l'environnement existant - souvent, des services sont déjà consommés, ce qui permet de dégager des effets de synergie.

Méthodologie des opérations et portée

Il est facile de constater que ce changement peut être complexe et que les approches traditionnelles ne suffisent souvent pas pour en tirer le maximum de bénéfices.

La phase de recherche d'informations et la définition du champ d'application sont plus complexes et encore plus importantes que pour les changements traditionnels. Parallèlement, une approche agile est nécessaire, avec une détermination régulière de l'état des lieux et un réajustement de la prochaine étape.

Devoteam Alegri a conçu une procédure sur la base de son expérience et de son savoir-faire. Celle-ci s'inspire des directives de SAP et a été complétée par les expériences des consultants.

Les années d'expérience en matière d'appels d'offres et d'exploitation dans un environnement IaaS, ainsi que les projets greenfield et brownfield relatifs à S/4, ont permis de créer des outils et des instruments qui réduisent les durées et les risques des projets et minimisent les efforts des clients.

Administration de S/4 Hana

Le développement d'une stratégie - en tenant compte des nouvelles possibilités du cloud, de l'architecture, y compris des systèmes Fiori - ainsi que la transformation proprement dite sont une chose. Après une phase d'hypercare, l'exploitation qui s'ensuit est un autre sujet, souvent considéré (trop) tardivement : pour de nombreuses transformations, on organise un soutien pour la mise en place des nouveaux processus, la connexion au cloud jusqu'à la mise en service du système S/4.

Mais comment un client peut-il adapter son organisation administrative existante à la nouvelle architecture et la transformer sans interruption ? La base SAP classique tout comme les équipes d'application devront s'adapter à de nouvelles structures, solutions et tâches. Deux exemples simples permettent d'illustrer ce point :

1. les tâches administratives telles que la surveillance ou la sécurité vont changer. Les solutions de monitoring actuelles dans SAP sont adaptées aux systèmes Abap et Java, un monitoring global sur site ainsi que des solutions cloud ne peuvent être intégrés que de manière détournée. Il en va de même pour les paramètres de sécurité.

Si l'informatique d'une entreprise peut encore garantir une sécurité complète au sein de son propre réseau sur site, elle se heurte à ses limites lorsqu'elle intègre des solutions en nuage. Dans ce cas, tout comme pour la surveillance, il est nécessaire de trouver de nouveaux moyens pour une utilisation et une surveillance confortables et sécurisées.

2. le support d'application et le développement sont actuellement organisés en fonction du système, car les processus commerciaux se déroulent également au sein d'un système. Cela va changer à l'avenir et les processus se dérouleront à l'échelle du système et du monde entier.

Le développement et l'assistance doivent donc acquérir des connaissances transversales. Cela implique par exemple une gestion des changements adaptée, car à l'avenir, les changements devront être organisés de manière cohérente sur un nombre nettement plus important de systèmes et d'univers de systèmes.

De nouvelles structures organisationnelles devront également être mises en place, car les équipes administratives et professionnelles collaboreront beaucoup plus étroitement.

Le passage de la gestion classique des systèmes SAP à un soutien hybride moderne des processus et des services autour du noyau numérique sous la forme du système S/4, avec l'intégration de diverses structures et applications cloud, est complexe. Elle requiert des experts expérimentés qui ont déjà effectué avec succès des conversions analogues et qui connaissent déjà les avantages et les risques des structures potentielles.

Il n'est même pas nécessaire de parler d'intégration de l'IoT, de l'intelligence artificielle ou de la blockchain, un simple regard sur le transfert de fonctionnalités SAP vers des solutions cloud (WebIDE, fonctionnalités SCM, cockpits de monitoring, intégration d'interfaces et de données...) suffit amplement.

Conclusion

Le passage à S/4 n'a pas d'alternative, il doit être achevé d'ici 2025 et ne doit pas être sous-estimé. Les bénéfices potentiels de la transition justifient l'effort si elle est soigneusement planifiée. De même, S/4 et Hana sont les conditions préalables à une intégration transparente des solutions du portefeuille de SAP, qu'il s'agisse d'Ariba ou même d'une connexion via SCP.

Le traitement des données IoT est également simplifié et immédiatement efficace grâce à l'utilisation de S/4. Le client peut influencer la vitesse et le niveau de qualité du futur paysage, mais il a besoin pour cela de temps et d'expertise, deux ressources déjà limitées aujourd'hui.

Une perception comme un "changement de version" ne rend pas justice à la fois au projet et à ses implications et constitue une sous-estimation grossièrement négligente. De même, reporter le projet dans le temps est inapproprié, car le manque de consultants expérimentés pour le nombre de projets augmentera de manière flagrante au fil du temps.

L'espoir que SAP élargisse l'échéance de 2025 est compréhensible - mais ne peut pas être la base de l'action. De même, il est fort probable qu'en plus des avantages déjà clairement visibles d'un passage à S/4, SAP rendra le maintien d'ECC 6.0 de moins en moins attractif, y compris sur le plan économique.

En effet, SAP a tout intérêt à accélérer le taux de transition vers S/4 et Hana - ce n'est qu'ainsi que d'autres produits et licences pourront être placés chez les clients. Un partenaire tel que l'association de Devoteam Alegri et QPCM - neutre, sans intérêts propres en matière de licences et disposant d'une grande expérience - avec des années d'expérience pratique peut ici faire la différence.

Un état des lieux de la situation actuelle, un advisory sur l'espace actuel des solutions et ensuite un plan directeur - et voilà que ce changement est gérable et peut être expliqué de manière ciblée à ses propres parties prenantes.