Depuis sept ans, IBM pousse ses clients mainframe vers le Tailored Fit Pricing (TFP). Si votre équipe commerciale IBM a déjà lancé la discussion, la meilleure chose à faire est de réduire la baseline TFP avant de signer. Le chiffre qu’IBM va figer fixera votre plancher de coûts pour les 3 à 5 prochaines années.
Un point à prendre en compte : à la signature, IBM calcule votre baseline à partir des 12 derniers mois de données SCRT. Cette baseline détermine ce que vous paierez pendant des années, et vous ne pourrez pas la renégocier ensuite.
La période entre aujourd’hui et votre signature est donc la meilleure occasion d’optimisation que vous aurez jamais sous TFP. Malheureusement, la plupart des clients passent complètement à côté.
Nous expliquons ici comment IBM construit votre baseline TFP et pourquoi elle compte plus que tout autre chiffre de votre contrat TFP IBM. Et pour passer à l’action, nous vous disons ce que vous pouvez faire dans les mois qui précèdent la signature pour réduire le coût de votre contrat.
1. Comprendre comment IBM calcule votre baseline TFP
Dans le mode principal du TFP, la Software Consumption Solution (SCS), votre coût annuel se calcule à partir de deux éléments :
Coût annuel = (MSU de baseline × prix par MSU) + (MSU de croissance × prix par MSU × 50 %)
La baseline correspond à votre consommation mensuelle moyenne de MSU (millions d’unités de service), tirée de vos 12 derniers rapports Sub-Capacity Reporting Tool (SCRT), les mêmes rapports qu’IBM vous demande déjà de transmettre. Toute consommation au-dessus de cette baseline est facturée à un tarif réduit (en général 50 % du prix de base). Toute consommation en dessous coûte la même chose que si vous l’aviez utilisée.
Cette formule a deux conséquences. D’abord, votre baseline est en pratique un plancher : vous la payez, que vous l’utilisiez ou non. Ensuite, la croissance au-dessus de la baseline coûte moins cher, et c’est l’argument de vente qu’IBM met en avant.
Ce qu’IBM souligne moins, c’est que plus votre baseline est basse, plus votre plancher est bas. Concrètement, une baisse de 10 % de votre baseline aujourd’hui rendra votre coût 10 % moins cher pour chaque année du contrat.
2. La fenêtre SCRT de 12 mois, votre levier de négociation
IBM tire votre baseline des 12 derniers rapports SCRT mensuels avant votre date de transition. Vous avez donc jusqu’à 12 mois pour influencer le chiffre qu’IBM utilisera comme plancher de coûts.
Dans la plupart des cas, pourtant, les clients le découvrent trop tard, parfois quelques semaines seulement avant la date de début du contrat. Si vous lisez ceci, vous avez encore le temps d’agir.
📌 Point clé : vous ne négociez pas votre baseline TFP en réunion avec IBM. Vous la réduisez en baissant votre consommation réelle de MSU dans les mois qui précèdent. Ce que vous faites (ou ne faites pas) pendant cette fenêtre est définitif.
Voici trois actions à lancer dès maintenant, pendant la fenêtre qui précède la transition :
- Comprendre d’où vient réellement votre consommation
- Réduire la consommation des charges de travail qui vous laissent le plus de marge
- Automatiser les interventions manuelles qui créent aujourd’hui des pics inutiles
3. Étape 1 — Comprendre votre profil de consommation
Premier obstacle : les rapports SCRT donnent des totaux de consommation, mais ils ne disent pas quelles applications, charges de travail ou traitements batch consomment le plus de MSU.
Les outils de surveillance natifs d’IBM peuvent fournir ce niveau de détail, mais ils ont un coût important : ils consomment eux-mêmes une quantité notable de MSU. Sous TFP, cette consommation entre directement dans le calcul de votre baseline. Vous dépenseriez des MSU pour surveiller vos MSU.
C’est là que Zetaly Data Platform (ZDP) apporte un vrai avantage. ZDP collecte et analyse les enregistrements SMF, les données d’exploitation brutes sur lesquelles repose le reporting SCRT, en n’utilisant que 0,2 % des ressources du mainframe. ZDP montre quels produits, charges de travail et applications consomment le plus, dans un tableau de bord mis à jour toutes les 15 minutes.
Avant toute discussion avec IBM sur votre baseline, il vous faut ces informations. Ce que vous cherchez :
- Vos 5 applications les plus consommatrices et leur tendance mensuelle
- Les traitements batch qui tournent à pleine capacité, quelle que soit la demande
- Les charges de travail de test et de développement qui consomment autant de ressources que la production
- Les pics qui gonflent les moyennes mensuelles sans refléter le fonctionnement normal
4. Étape 2 — Réduire la consommation avant la date de signature
Une fois votre consommation comprise, vous pourrez la réduire. Sous TFP, chaque MSU retiré de votre moyenne mensuelle avant qu’IBM ne fige votre baseline se traduit directement par un plancher de coûts plus bas pour toute la durée du contrat.
Automatisation des charges de travail
Beaucoup d’entreprises lancent leurs traitements batch à heures fixes, quels que soient la charge du système ou la priorité métier. Cette approche avait du sens sous AWLC, quand votre coût dépendait d’un seul pic mensuel. Elle n’est pas optimale sous TFP, où vous payez la consommation cumulée.
Zetaly Automated Capacity (ZAC) automatise la planification des charges de travail pour réduire la consommation inutile de MSU. ZAC peut reporter les traitements batch non critiques vers des périodes où le système est moins chargé. Il plafonne aussi l’utilisation des ressources des charges de travail moins prioritaires et applique des limites souples qui empêchent chaque traitement de consommer plus que nécessaire.
Pour les équipes qui ont perdu des ingénieurs mainframe ou qui travaillent en effectif réduit, ZAC fait ces optimisations automatiquement : vous définissez la règle, ZAC l’applique, de façon constante et sans intervention manuelle.
Isolation du Dev/Test
Les environnements de développement et de test sont une source fréquente de consommation évitable. Si vos charges de travail de dev/test tournent sur la même capacité que la production, ou avec des limites généreuses fixées il y a des années, elles peuvent peser lourd dans vos relevés SCRT mensuels.
Vérifiez si vos charges de travail de dev/test ont vraiment besoin des ressources qu’elles consomment aujourd’hui. Toute baisse à ce niveau se répercute directement sur votre baseline TFP.
Rationalisation des applications
Certaines entreprises font tourner des applications rarement utilisées, mais toujours configurées à pleine capacité. La fenêtre avant la transition est le bon moment pour les passer en revue, et pour suspendre ou retirer les charges de travail dormantes. Vous récupérerez ainsi les MSU qu’elles ajoutent à votre moyenne mensuelle.
5. Et si vous avez déjà signé ?
Si votre contrat TFP est déjà en place, la fenêtre d’optimisation avant la transition est passée. Mais la gestion de la consommation ne s’arrête pas là. Votre baseline est recalculée au renouvellement : les 12 prochains mois de données SCRT fixeront votre plancher de coûts pour la prochaine période du contrat.
Tout ce que dit cet article s’applique aussi à la période qui précède votre date de renouvellement. Les clients qui gèrent le mieux le TFP le traitent comme un processus continu.
Questions fréquentes
Comment IBM calcule-t-il la baseline TFP ?
IBM utilise vos 12 derniers rapports SCRT (Sub-Capacity Reporting Tool) mensuels pour établir votre baseline. Ces rapports enregistrent la consommation réelle de MSU (millions d’unités de service) par produit. La moyenne de ces 12 mois devient le plancher de consommation de votre contrat TFP. Toute consommation de MSU au-dessus de cette baseline est facturée à environ 50 % du tarif standard.
Puis-je négocier ma baseline TFP avec IBM ?
Votre baseline découle directement de votre historique SCRT : IBM ne l’invente pas. Le moyen le plus efficace de l’influencer est de réduire votre consommation réelle dans les mois qui précèdent votre date de transition. Une fois qu’IBM a figé la baseline à partir de vos données SCRT, elle ne peut plus être renégociée, sauf à revenir vers IBM pour un avenant au contrat.
Quand commencer à réduire la baseline TFP avant de signer ?
Idéalement, 6 à 12 mois avant la date de transition prévue. Chaque rapport SCRT transmis pendant cette fenêtre entre dans le calcul de la baseline. Même 3 mois de baisse réelle peuvent réduire votre moyenne. Plus vous commencez tôt, plus vous influencez de rapports.
ZAC a-t-il encore un intérêt si je passe au TFP ?
Oui, pour deux raisons. D’abord, pendant la fenêtre qui précède la transition, ZAC réduit la consommation de MSU par l’automatisation des charges de travail, ce qui abaisse les relevés SCRT qui alimentent votre baseline. Ensuite, après la transition, ZAC continue d’apporter des fonctions d’automatisation et d’optimisation des charges de travail qui aident à gérer la consommation au quotidien, ce qui compte pour la baseline de votre prochain renouvellement.
Qu’est-ce que ZDP et pourquoi est-il utile avant une transition vers le TFP ?
Zetaly Data Platform (ZDP) collecte et analyse les enregistrements SMF du mainframe, les données brutes derrière vos rapports SCRT, en n’utilisant que 0,2 % des ressources du mainframe. ZDP vous montre quelles charges de travail et quelles applications consomment le plus, pour cibler l’optimisation avant la signature. Contrairement aux outils de surveillance natifs d’IBM, ZDP n’ajoute pas de façon notable à la consommation de MSU que vous cherchez à réduire.
Que devient la baseline non utilisée sous TFP ?
Avec la Software Consumption Solution du TFP, vous payez votre baseline, que vous l’utilisiez ou non. Si votre consommation réelle d’un mois est inférieure à la baseline, IBM vous facture quand même le montant de la baseline. C’est pourquoi il est décisif de négocier dès le départ la baseline la plus basse possible : ce n’est pas seulement un plafond pour la croissance à tarif réduit, c’est aussi votre engagement mensuel minimum.
