Une tâche aussi banale que charger un budget de centre de coûts depuis Excel peut révéler tout un pan de la migration vers S/4HANA. Derrière ce petit cas se cache une notion centrale et souvent mal comprise : le compatibility scope.
L’essentiel
- En S/4HANA, une fonctionnalité peut être cible, maintenue en transition (compatibility scope), ou supprimée.
- Une fonction qui marche encore n’est pas une fonction pérenne : la dette se paie au prochain upgrade.
- Chaque fonction reprise mérite un arbitrage conscient, pas une reproduction automatique des habitudes ECC.
- Le rôle du consultant n’est plus de connaître les transactions, mais d’éclairer ces choix.
1. Un cas concret : reprendre un budget de centre de coûts
Le besoin métier est simple. Un contrôleur de gestion prépare son budget annuel dans Excel, ventilé par centre de coûts et par nature comptable. Il veut le charger dans SAP pour qu’il serve de référence au suivi budgétaire. Rien d’exotique, c’est une opération que des milliers d’entreprises font chaque année.
Sous ECC, la procédure était bien rodée. On saisissait le budget via la transaction KP06, et pour éviter une saisie manuelle ligne par ligne, on remontait le fichier Excel grâce au programme KKP_FLEX_UPL. Ce programme avait besoin qu’on lui définisse une description de fichier : la structure qui dit quelle colonne du fichier correspond à quel champ SAP (centre de coûts, compte, montant, période).
Sous S/4HANA, le consultant habitué à ECC se retrouve désorienté. La transaction KP06 existe toujours, mais le chemin d’upload semble avoir changé de logique, et l’endroit où définir la fameuse description de fichier devient introuvable. La fonction n’a pas disparu, elle a changé de paradigme. C’est exactement ce glissement qu’il faut savoir lire.
Vu en mission
Un consultant senior, expert ECC depuis quinze ans, peut tourner en rond une demi-journée sur ce type de tâche. Pas par incompétence, mais parce que son réflexe ECC le pousse à chercher un objet qui n’existe plus sous la même forme. L’expérience devient alors un piège plutôt qu’un atout.
2. Trois statuts possibles pour une fonctionnalité en S/4HANA
Pour comprendre ce qui se joue, il faut savoir qu’une fonctionnalité héritée d’ECC ne se retrouve pas dans un seul état en S/4HANA. Elle peut relever de trois statuts distincts, et savoir les distinguer change tout dans un projet de migration.
| Statut | Ce que ça signifie | Exemple |
|---|---|---|
| Fonction cible | SAP investit dessus, c’est la direction stratégique. Souvent du Fiori, des CDS, ACDOCP, SAC. | Reporting plan/réel via ACDOCP et applis Fiori |
| Compatibility scope | Fonction conservée mais transitoire. Elle marche, mais SAP n’investit plus dessus et fixe une échéance implicite. | Planification CO classique via KP06 |
| Fonction supprimée | Retirée sans équivalent direct. Il faut repenser le processus. | Certaines transactions historiques sans reprise en S/4 |
Le compatibility scope est le statut le plus mal compris des trois. C’est un périmètre de fonctions qu’SAP a choisi de maintenir techniquement en S/4HANA pour faciliter la transition, mais qui n’est ni la cible, ni un acquis définitif. Concrètement, la fonction tourne, mais elle est en sursis : SAP communique des échéances de maintenance au-delà desquelles le support n’est plus garanti.
La planification CO classique, dont fait partie notre upload de budget, relève précisément de ce deuxième cas. Elle fonctionne sous S/4HANA, mais SAP pousse clairement vers d’autres outils pour la planification financière, autour d’ACDOCP et de SAP Analytics Cloud.
3. Pourquoi cette distinction compte dans un projet
Ignorer ces statuts ne bloque pas le projet immédiatement. C’est justement ce qui rend le risque sournois. Une fonction en compatibility scope se comporte exactement comme avant en phase de recette : elle passe les tests, les utilisateurs la retrouvent, tout le monde est rassuré. Le problème arrive plus tard.
- Une fonction qui marche encore donne une fausse sécurité : elle valide la recette mais n’est pas pérenne.
- La dette ne se paie pas pendant le projet, mais au prochain upgrade, quand le support s’arrête.
- Les utilisateurs reproduisent leurs habitudes ECC sur un socle qui n’est plus conçu pour ça.
- L’écart se découvre souvent tard, en phase de test par un key user, quand le planning est déjà tendu.
À éviter en mission
Considérer que « ça marche en recette, donc c’est validé ». Une fonction en compatibility scope passe la recette sans problème, mais reporte une dette technique sur le prochain upgrade. Le vrai critère n’est pas « est-ce que ça fonctionne », mais « est-ce que ce sera encore supporté demain ».
4. Une grille de décision pour chaque fonctionnalité reprise
Face à une fonction héritée d’ECC, la bonne démarche n’est pas de la reproduire par défaut, mais de l’arbitrer. Pour chaque fonctionnalité à migrer, trois options se présentent, et le choix mêle des critères techniques, budgétaires et de pérennité.
- Reproduire à l’identique en compatibility scope. Rapide et peu coûteux à court terme, mais crée une dette à régler plus tard.
- Adopter la cible S/4HANA (Fiori, ACDOCP, SAC). Plus coûteux à mettre en place, mais pérenne et aligné avec la trajectoire SAP.
- Retenir une solution intermédiaire. Par exemple conserver la fonction classique le temps de la migration, avec un plan de bascule planifié vers la cible.
Ce qui compte, c’est que ce choix soit fait consciemment. Une fonction reprise sans arbitrage n’est pas un choix, c’est un report de décision. Et un report de décision sur une migration finit toujours par coûter, en temps ou en budget, au moment le moins opportun.
Réflexe consultant
Pour chaque fonction reprise, pose-toi la question du statut avant celle de la technique. Savoir si tu es sur une cible, du compatibility scope ou une fonction supprimée oriente tout le reste de la décision.
5. Ce que cela change dans la conduite de migration
Une migration S/4HANA n’est pas un portage technique d’un système vers un autre. C’est une succession d’arbitrages fonctionnels, dont chacun engage la pérennité et le coût futur du système. Le cas de l’upload de budget n’est qu’un exemple parmi des dizaines d’autres décisions du même type qui s’accumulent au fil d’un projet.
Dans ce contexte, la valeur du consultant se déplace. Elle n’est plus dans la connaissance par cœur des transactions, qui se périme avec les versions. Elle est dans la capacité à diagnostiquer un écart entre deux logiques système, à situer une fonction dans la trajectoire SAP, et à éclairer le décideur sur la dette qu’un choix implique. Anticiper la dette plutôt que la subir, c’est la vraie compétence.
Sur une migration S/4HANA, ce qui n’est pas tranché consciemment devient une dette subie.
À retenir
Le compatibility scope est un outil de transition utile, à condition d’en connaître les limites et l’échéance. Une fonction héritée d’ECC qui fonctionne encore en S/4HANA n’est pas forcément un acquis : elle peut être en sursis. Le travail du consultant consiste à identifier ces situations, à les arbitrer plutôt qu’à les reproduire, et à rendre visible au décideur le coût futur de chaque choix. La connaissance technique se périme, la méthode de diagnostic non.
Tu prépares ou tu vis une migration S/4HANA ?
Si tu veux échanger sur les arbitrages fonctionnels d’un projet de migration et sur la façon de les rendre lisibles côté décision, on peut en discuter directement.