« On bascule sur IBP. » La phrase circule dans les couloirs du département informatique de l’entreprise depuis des mois, souvent sans que personne ne prenne le temps d’expliquer ce qu’elle recouvre réellement. Et elle contient une approximation qui coûte cher en cadrage de projet.
Car SAP IBP n’est pas le successeur de SAP APO. Il n’en reprend qu’une partie. Comparer SAP APO vs SAP IBP comme on comparerait deux versions d’un même logiciel conduit à sous-dimensionner le projet, à oublier des périmètres entiers, et à découvrir en cours de route que la planification de production ne part pas du tout où l’on croyait.
Voici ce que recouvre vraiment la bascule, avec les échéances de maintenance à jour et ce qui change concrètement pour un planificateur.
Ingénieur de formation, spécialisé en génie industriel, j’ai occupé différents postes (approvisionneur, pilote de flux, global supply planner) pendant plus de 5 ans dans différents grands groupes du secteur avant de devenir formateur en supply chain. Ce blog s’appuie sur mes recherches personnelles et sur ce que j’ai vécu ou observé sur le terrain. Vos réactions en commentaire sont les bienvenues. Rejoignez-moi sur LinkedIn.
Sommaire
APO n’est pas remplacé, il est démantelé
C’est le point que les présentations commerciales escamotent. SAP APO reposait sur quatre modules, et ils ne partent pas au même endroit. Deux rejoignent SAP IBP, deux autres sont réabsorbés dans S/4HANA.
La conséquence est structurante. Une entreprise qui utilisait les quatre modules ne mène pas un projet, elle en mène deux, portés par des équipes différentes et souvent sur des calendriers différents. L’ordonnancement fin et la promesse client dépendent désormais de l’avancement du projet S/4HANA, pas de celui d’IBP.
C’est aussi ce qui explique une situation fréquente : des groupes déjà « passés sur IBP » pour la demande et l’approvisionnement, mais qui font encore tourner APO en parallèle pour le PP/DS, faute d’avoir basculé leur ERP. Le périmètre fonctionnel exact de chaque brique est détaillé dans la documentation officielle de SAP IBP.
Les échéances de maintenance, chiffres à jour
APO fait partie de SAP Business Suite 7, dont le calendrier de maintenance est public. Trois dates à retenir, et la première est déjà derrière nous.
- Enhancement packages 1 à 5 : maintenance standard terminée depuis fin 2025. Les entreprises concernées tournent déjà hors support standard.
- Enhancement packages 6 à 8 : maintenance standard jusqu’au 31 décembre 2027.
- Maintenance étendue jusqu’à fin 2030, en option, moyennant un supplément de deux points sur le taux de maintenance et un engagement sur S/4HANA.
En face, SAP a pris un engagement d’innovation sur S/4HANA jusqu’en 2040. L’écart entre les deux horizons est le vrai argument de bascule, bien plus que les fonctionnalités. Le calendrier officiel est publié sur le portail de maintenance SAP.
Attention à la lecture de ces dates : 2027 n’est pas une date d’arrêt technique. APO ne s’éteint pas, il sort du support standard. Les correctifs légaux et les évolutions cessent, le système continue de tourner. C’est un risque de conformité et de dette technique, pas une panne programmée.
SAP APO vs SAP IBP : ce qui change au quotidien
Sur le périmètre effectivement repris par IBP (demande et approvisionnement), quatre différences se ressentent dès les premières semaines.
| Critère | SAP APO | SAP IBP |
|---|---|---|
| Architecture | Client-serveur, on-premise | Cloud natif sur SAP HANA |
| Interface | Transactions SAP, codes à mémoriser | Add-in Excel et tableaux de bord |
| Simulation | Scénarios lourds, souvent sous Excel | Scénarios parallèles natifs |
| Intégration | CIF vers ECC, à maintenir | Connecteurs S/4HANA et API |
L’add-in Excel mérite une nuance, parce qu’il est systématiquement vendu comme un avantage. Il l’est pour l’adoption : un Demand Planner ou un Supply Planner junior devient autonome bien plus vite que sur les transactions APO. Il l’est moins pour la discipline de données : travailler dans Excel réinstalle les habitudes de retraitement local que le projet était censé faire disparaître.
La vraie rupture est ailleurs : IBP partage un modèle de données unique entre demande, approvisionnement et planification financière. Sous APO, faire dialoguer les modules supposait des interfaces ou des consolidations maison. C’est ce qui rend un cycle S&OP mensuel réellement tenable, plutôt qu’un exercice de rapprochement d’extractions.
Retour d’expérience : dans les environnements où j’ai travaillé, monter un scénario alternatif de planning sous APO pouvait occuper une bonne partie d’une journée. Avec un outil pensé pour la simulation, le même exercice se fait en quelques clics. Ce n’est pas un gain de confort : c’est ce qui détermine si une équipe S&OP peut répondre à un aléa fournisseur dans la journée ou à la réunion du mois suivant.
Pourquoi la migration n’est pas une montée de version
Le point le plus mal anticipé dans les projets : il n’existe pas de migration automatisée d’APO vers IBP. Les modèles de données, le paramétrage et l’interface sont trop différents pour être convertis. Vos configurations APO ne sont pas réutilisables.
Concrètement, vous ne migrez pas un outil : vous reconstruisez vos processus de planification dans un nouveau, en repartant du besoin. Ce qui se transfère, ce sont les données de base et l’historique, pas le paramétrage.
C’est une mauvaise nouvelle pour le budget, mais une bonne pour la qualité du résultat. Les projets qui échouent sont ceux qui tentent de répliquer APO à l’identique dans IBP, en recréant les contournements Excel accumulés depuis quinze ans. Ceux qui réussissent traitent la bascule comme une remise à plat : un site pilote, une stabilisation, puis un déploiement progressif. Ce projet est en général porté par le responsable supply chain, avec la DSI en copilote.
La question à se poser n’est donc pas « faut-il migrer ? », l’échéance de maintenance y répond déjà. C’est « nos données de base et nos processus sont-ils assez propres pour être reconstruits ailleurs ? ». Si la réponse est non, le chantier commence là, avant tout choix d’outil. Pour situer ces solutions dans l’écosystème plus large, notre panorama des logiciels supply chain replace APS, ERP et WMS les uns par rapport aux autres.
Vous préparez une bascule vers IBP ou vous souhaitez monter en compétence sur les outils APS pour évoluer ? Je propose un accompagnement individuel sur ces sujets.
FAQ
SAP IBP remplace-t-il complètement SAP APO ?
Non. IBP reprend la planification de la demande (DP) et de l’approvisionnement (SNP). L’ordonnancement (PP/DS) et la disponibilité à la promesse (gATP) sont repris par S/4HANA, sous les noms ePP/DS et aATP. Une entreprise qui utilisait les quatre modules a donc deux chantiers à mener, pas un.
Quand SAP APO s’arrête-t-il exactement ?
La maintenance standard court jusqu’au 31 décembre 2027 pour les enhancement packages 6 à 8, et elle est déjà terminée depuis fin 2025 pour les versions 1 à 5. Une maintenance étendue optionnelle prolonge la couverture jusqu’à fin 2030. APO ne cesse pas de fonctionner à ces dates : il sort du support.
Peut-on migrer automatiquement d’APO vers IBP ?
Non. Les architectures et les modèles de données sont trop éloignés. Le paramétrage APO n’est pas convertible : la mise en œuvre d’IBP se fait par une nouvelle configuration. Seuls les données de base et l’historique se reprennent.
Faut-il connaître APO pour travailler sur IBP ?
Ce n’est pas nécessaire, et les recrutements le montrent : les entreprises cherchent surtout des profils qui maîtrisent les processus de planification, l’outil s’apprenant ensuite. En revanche, connaître APO reste un atout pendant la phase de transition, tant que les deux systèmes cohabitent.
Laisser un commentaire