Les 61 % de clients SAP confrontés à l’échéance du 31 décembre 2027 pour migrer de SAP ECC vers S/4HANA arrivent à un moment décisif. Une question s’impose rapidement : conversion ou transformation ?
Les conversions se concentrent avant tout sur l’aspect technique de la migration vers S/4HANA. Le projet est généralement de type brownfield, avec des changements volontairement limités — et souvent sous-estimés — puisque le système existant reste en grande partie inchangé. L’objectif est clair : minimiser les perturbations.
La transformation, à l’inverse, considère le passage à S/4HANA comme une opportunité pour repenser en profondeur le fonctionnement de l’entreprise. Elle vise à faire évoluer les processus, l’usage des données, les modèles de sécurité et l’expérience utilisateur afin de tirer pleinement parti des capacités de la plateforme.
Cette distinction est cruciale. Elle renvoie à une règle bien connue de la gestion de projet : rapide, économique ou de qualité (temps, coût, qualité) — on ne peut en choisir que deux. Les intégrateurs systèmes (SI) proposent souvent des conversions industrialisées optimisées pour la vitesse (rapide) et le coût (économique). Mais ces approches aboutissent fréquemment à un système simplement conforme sur le plan technique, sans réelle création de valeur métier.
En clair, le système avance, mais le métier reste sur place. Dans cet article, nous explorons ce qu’il faut prendre en compte pour que votre migration S/4HANA génère une véritable transformation.
Qu’est-ce qui motive les recommandations en faveur de la transformation que vous recevez ?
Une fois la différence entre conversion et transformation comprise, une autre question se pose : pourquoi tant de programmes S/4HANA basculent-ils par défaut vers la conversion ?
La réponse tient en grande partie au mode de fonctionnement de SAP. L’orientation stratégique vers le cloud et les modèles par abonnement s’accompagne naturellement de cycles de migration rapides, où le succès est souvent mesuré par l’atteinte d’objectifs techniques plutôt que par une transformation métier durable.
Les SI opèrent dans ce même cadre. Les approches de conversion standardisées sont plus simples à cadrer, plus rapides à livrer et mieux alignées avec les objectifs commerciaux, les crédits SAP et les indicateurs de performance de delivery.
À l’inverse, une transformation introduit une complexité accrue : dépendances transverses, changements organisationnels, enjeux d’adoption. Ces facteurs allongent les délais, augmentent les risques et rendent la transformation bien plus difficile à industrialiser.
Résultat : des éléments essentiels de la transformation sont souvent sortis du périmètre, au détriment du métier. Des solutions comme Ariba, Concur, SuccessFactors, EWM ou encore la sécurité cloud sont traitées comme des projets ultérieurs, au lieu d’être intégrées dès la conception du programme S/4HANA. Les retards dans la standardisation des processus, l’évolution des modèles opérationnels et l’intégration de la sécurité dès la conception réduisent fortement la valeur que S/4HANA est censé apporter.
Le constat est sans surprise : la migration atteint ses objectifs techniques, mais passe à côté de son potentiel de transformation. Au lieu de poser les bases d’un environnement moderne, sécurisé et orienté croissance, les organisations se retrouvent avec un système mis à jour, toujours ancré dans d’anciens modèles — et leurs faiblesses.
Où l’approche conversion montre-t-elle ses limites ?
Le problème n’est pas que les conversions échouent techniquement, mais que leur approche de delivery est optimisée pour la préparation du système, et non pour la préparation du métier, la sécurité et une conception durable des accès.
Le cycle de vie classique SAP Activate se compose des phases Discover, Prepare, Explore, Realize, Deploy, Run. Dans un scénario de conversion, les phases Discover et Explore sont souvent fortement raccourcies. Elles deviennent des exercices techniques pilotés par des checklists, au lieu d’être de véritables leviers pour repenser les processus métier, les modèles d’accès, la séparation des tâches (SoD) ou la préparation au changement.
Des lacunes apparaissent également dans la phase Realize (conception). Du point de vue des autorisations, l’effort se limite souvent au strict minimum, en s’appuyant principalement sur les SAP S/4 Simplification Items.
Les transactions classiques sont supprimées et remplacées par des transactions utilitaires comme BP (Business Partner centralisé). Sans analyse approfondie des autorisations sous-jacentes, il devient alors trop facile d’attribuer des droits par défaut dès que la transaction BP est requise. Là où clients et fournisseurs étaient historiquement séparés par des transactions distinctes, ils peuvent désormais être gérés au même endroit.
Résultat : un même utilisateur peut, sans le savoir, se voir attribuer des droits sur les données clients, fournisseurs — voire les deux.
De la même manière, lorsque de nouvelles applications Fiori sont livrées, elles sont souvent générées automatiquement à partir des paramètres de la SAP App Library. Peu de réflexion est alors menée sur les risques de divergence de processus, les conflits de SoD ou la stratégie globale d’accès utilisateur.
En fin de phase Realize, puis lors du passage à Deploy, les tests sont fréquemment réduits au minimum dans une conversion. Cela laisse subsister des écarts en matière d’autorisations, d’alignement des rôles métier et de séparation des tâches.
Globalement, sans une attention précoce et structurée, les risques de sécurité augmentent et l’ampleur du changement métier est largement sous-estimée — avec un impact direct sur l’adoption et la productivité.
Opportunités manquées — et conséquences
Que laisse-t-on de côté — ou à quels risques s’expose-t-on — en choisissant une conversion rapide et peu coûteuse ? La réponse est simple : beaucoup.
-
Opportunités manquées de rationaliser et standardiser les processus métier grâce à l’automatisation, à l’efficacité et à la collaboration globale
-
Coût total de possession plus élevé, lié à une optimisation insuffisante des processus
-
Baisse de l’adoption, de la mobilité des talents et de la productivité, due à une expérience utilisateur dégradée et à une mauvaise compréhension des accès fournis
-
Risques organisationnels accrus, liés aux failles de sécurité, de conformité et de contrôle interne, ainsi qu’à l’utilisation d’une base de code obsolète ou peu sécurisée
Opter pour la conversion revient donc à investir des montants significatifs pour une valeur métier limitée. Cela crée un événement de changement perturbateur, malgré la volonté initiale de l’éviter. Et surtout, cela ne fait que repousser la transformation. L’expérience montre qu’elle finit toujours par refaire surface après le go-live, sous la pression des audits, des opérations ou des incidents.
Une transformation réussie va au-delà de la simple migration fonctionnelle. Elle s’intéresse au « qui » et au « comment » du travail, et à la manière dont les systèmes peuvent soutenir et encadrer ces activités. Un élément clé consiste à intégrer la sécurité dès le départ comme un pilier du changement métier, plutôt que de tenter de la rajouter a posteriori.
Comment aborder une transformation complète
À première vue, la transformation peut sembler plus exigeante qu’une conversion. En réalité, elle consiste surtout à anticiper le travail, afin de le planifier, le gouverner et l’aligner sur les objectifs métier — plutôt que de le traiter dans l’urgence lorsqu’il devient problématique.
Les entreprises qui se préparent sérieusement à une transformation parviennent à mieux aligner les parties prenantes, à renforcer les contrôles de sécurité et la préparation aux audits, et à standardiser leurs processus. Surtout, celles qui choisissent cette voie investissent activement dans la création de valeur métier via des initiatives d’efficacité et d’innovation. Et point clé : elles mènent un seul projet, pas deux.
Pour exploiter pleinement le potentiel de valeur et d’adoption, il est recommandé de :
-
Démarrer avec une planification claire et une vision précise des objectifs de transformation
-
Impliquer la sécurité le plus tôt possible et la considérer — ainsi que les autorisations et contrôles — comme un levier proactif du changement
-
Aligner l’IT et le métier afin de dépasser la logique de « simple migration logicielle » et fédérer autour des objectifs d’adoption, d’efficacité et de conformité
-
Revoir et optimiser les processus métier en vue de l’automatisation et de la standardisation globale
-
Garder la maîtrise de la transformation, sans la laisser être dictée par SAP ou par votre SI
En résumé : placer le métier au cœur de la transformation
Vous êtes aux commandes de la transformation, et celle-ci doit être guidée par vos objectifs métier. Ne vous laissez pas détourner par des intérêts contradictoires, ni contraindre à une conversion qui ne répond pas à vos besoins. Saisissez l’opportunité de la transformation pour optimiser, standardiser et simplifier vos processus.
Une planification rigoureuse, un engagement stratégique et un alignement fort entre l’IT et le métier permettent de maximiser l’efficacité, l’adoption et la conformité. En intégrant les besoins des utilisateurs dès le départ, vous garantissez que l’investissement dans la transformation est pleinement justifié.
Turnkey Consulting peut vous accompagner pour aligner technologies, processus et équipes, et rendre votre transformation aussi fluide, sécurisée et pérenne que possible. Contactez notre équipe pour en savoir plus.
Foire aux questions sur les transformations S/4HANA
1 : Quelle est la différence entre une conversion S/4HANA et une transformation S/4HANA ?
La conversion se concentre sur les aspects techniques du passage à S/4HANA. Les changements sont principalement liés aux évolutions du code SAP, sans refonte des processus métier ni démarche d’adoption. L’objectif est de maintenir le système en fonctionnement, dans un contexte généralement brownfield.
La transformation, en revanche, redéfinit les processus métier, l’usage des données, la sécurité et l’expérience utilisateur afin d’exploiter pleinement les capacités de S/4HANA.
2 : La sécurité est-elle réellement impactée si l’on se limite à une conversion technique ?
Oui, clairement. S/4HANA introduit de nouvelles transactions, des processus consolidés comme le Business Partner, et des applications Fiori qui remplacent les transactions classiques. Peu de rôles existants s’adaptent naturellement à ces nouveaux usages. Les autorisations héritées peuvent donc bloquer des processus, créer des conflits de SoD ou conduire à une sur-attribution des droits.
3 : Quand faut-il impliquer la sécurité et la gestion des accès dans une transformation S/4HANA ?
Dès le début, et tout au long du programme : conception des processus, construction, tests et déploiement. La sécurité ne se limite pas à un contrôle technique ; elle soutient le changement métier, la formation, les tests et l’adoption. La traiter après coup augmente les risques, les coûts et les délais. Elle doit donc être intégrée et financée sur toute la durée du programme.
