By Jacky Hofbauer, Published May 2026, Last update May 2026

IBM is pushing mainframe customers toward Tailored Fit Pricing (TFP) at an accelerating pace. If your account team has started the conversation, you may feel like it's a decision you need to make quickly — sign the contract, lock in the pricing model, move on.

Before you do, here is something most customers don't realize: the moment you sign, IBM calculates your baseline from the last 12 months of SCRT data. That baseline determines what you pay for years. You cannot renegotiate it after the fact.

The window between now and your signature is the single most valuable optimization opportunity you will ever have on TFP. Most customers miss it entirely.

This guide explains how IBM builds your TFP baseline, why it matters more than any other number in your contract, and what you can do in the months before you sign to lower it.

1. How IBM Calculates Your TFP Baseline

Under TFP's primary model — the Software Consumption Solution (SCS) — your annual cost is calculated from two components:

Annual cost = (Baseline MSUs × Price per MSU) + (Growth MSUs × Price per MSU × 50%)

The baseline represents your average monthly MSU consumption, derived from your last 12 Sub-Capacity Reporting Tool (SCRT) reports — the same reports IBM already requires you to submit. Any consumption above that baseline is charged at a discounted rate (typically 50% of the base price). Any consumption below it costs the same as if you had used it.

Two things follow from this formula. First, your baseline is effectively a floor — you pay for it whether you use it or not. Second, growth above the baseline is cheaper, which IBM uses as the headline selling point.

What IBM does not emphasize: the lower your baseline, the lower your floor. A baseline reduction of 10% today is 10% cheaper for every year of the contract.

2. The 12-Month SCRT Window — Your Negotiating Lever

IBM draws your baseline from the 12 monthly SCRT reports submitted before your transition date. This means you have up to 12 months to influence the number IBM will use as your cost floor.

In practice, most customers discover this window late — sometimes only weeks before their contract start date. If you are reading this, you still have time to act.

Key point: You don't negotiate your TFP baseline in a meeting with IBM. You determine it by reducing actual MSU consumption in the months before the contract clock starts. What you do (or don't do) in that window is permanent.

Three categories of action matter in the pre-transition window:

• Understand where your consumption actually comes from

• Reduce consumption in the workloads that give you the most room to move

• Automate the manual interventions that are currently driving unnecessary peaks

3. Step 1 — Understand Your Consumption Profile

You cannot reduce what you cannot see. The first challenge is that SCRT reports give you total consumption numbers — they do not break down which applications, workloads, or batch jobs are driving the most MSU.

IBM's native monitoring tools can provide that granularity, but they carry a significant overhead — consuming meaningful MSU themselves. Under TFP, that overhead goes directly into your baseline calculation. You would be spending MSU to watch your MSU.

This is where Zetaly Data Platform (ZDP) provides a distinct advantage. ZDP collects and analyses SMF records — the raw operational data that underpins SCRT reporting — using only 0.2% of mainframe resources. It identifies which products, workloads, and applications are consuming the most, and surfaces that in a dashboard updated every 15 minutes.

Before you can have any conversation with IBM about your baseline, you need this view. What you're looking for:

• Your top 5 consuming applications and their monthly trend
• Batch jobs that run at full capacity regardless of demand
• Test and development workloads that consume the same resources as production
• Any spikes that inflate monthly averages but do not reflect normal operation

4. Step 2 — Reduce Consumption Before Your Signature Date

Once you have visibility, the next step is targeted reduction. Under TFP, every MSU you remove from your monthly average before IBM locks your baseline translates directly into a lower cost floor for the life of the contract.

Workload automation

Many organisations run batch jobs at fixed times, regardless of system load or business priority. This approach made sense under AWLC — when your cost was driven by a single monthly peak — but it is not optimal under TFP, where you are paying for cumulative consumption.

Zetaly Automated Capacity (ZAC) automates workload scheduling to reduce unnecessary MSU consumption. It can defer non-critical batch jobs to periods when the system is less loaded, cap resource usage for lower-priority workloads, and apply soft limits that prevent individual jobs from consuming more than they need.

For teams that have lost mainframe engineers or are running lean, ZAC handles these optimisations automatically — you define the policy, ZAC enforces it consistently without manual intervention.

Dev/Test isolation

Development and test environments are a common source of avoidable consumption. If your dev/test workloads run on the same capacity as production — or with generous limits that were set years ago — they may be contributing significantly to your monthly SCRT readings.

Review whether your dev/test workloads genuinely need the resources they currently consume. Any reduction here flows directly into your TFP baseline.

Application rationalisation

Some organisations run applications that are rarely used but remain configured at full capacity. The pre-transition window is the right moment to review these, suspend or decommission dormant workloads, and reclaim the MSU they contribute to your monthly average.

5. What If You Have Already Signed?

If your TFP contract is already in place, the pre-transition optimisation window has passed — but that does not mean consumption management is over. Your baseline resets at renewal, which means the next 12 months of SCRT data will determine your cost floor for the next contract term.

Everything in this blog applies equally to the period before your renewal date. The customers who manage TFP most effectively treat it as a continuous discipline, not a one-time exercise.

Frequently Asked Questions

How does IBM calculate the TFP baseline?

IBM uses your last 12 monthly SCRT (Sub-Capacity Reporting Tool) reports to establish your baseline. These reports capture actual MSU consumption per product. The average across those 12 months becomes the consumption floor in your TFP contract. Any MSU usage above that baseline is billed at approximately 50% of the standard rate.

Can I negotiate my TFP baseline with IBM?

Your baseline is derived directly from your SCRT history — IBM does not invent it. The most effective way to influence it is to reduce actual consumption in the months before your transition date. Once IBM locks the baseline from your SCRT data, it cannot be renegotiated without going back to IBM for a contract amendment.

How long before signing should I start optimising?

Ideally, start 6 to 12 months before your planned transition date. Each SCRT report you submit in that window feeds into the baseline calculation. Even 3 months of meaningful reduction can lower your average. The earlier you start, the more reports you influence.

Does ZAC still make sense if I am moving to TFP?

Yes — for three reasons. First, during the pre-transition window, ZAC reduces MSU consumption through workload automation, lowering the SCRT readings that feed your baseline. Second, after transition, ZAC continues to provide automation and workload optimisation capabilities that help manage ongoing consumption for DEV/TEST container which is billed on R4H and last, the ZAC Reporting is providing an accurate view on the MSU consumption and allow to react in case of deviation. 

What is ZDP and why is it useful before a TFP transition?

Zetaly Data Platform (ZDP) collects and analyses mainframe SMF records — the raw data behind your SCRT reports — using only 0.2% of mainframe resources. It shows you which workloads and applications are consuming the most, enabling targeted optimisation before you sign. Unlike IBM's native monitoring tools, ZDP does not itself add significantly to the MSU consumption you are trying to reduce.

What happens to unused baseline under TFP?

Under TFP's Software Consumption Solution, you pay for your baseline whether you use it or not. If your actual consumption in a given month is below the baseline, IBM still charges you for the baseline amount. This is why negotiating the lowest possible baseline upfront is critical — it is not just a ceiling on discounted growth, it is also your minimum monthly commitment.

About Zetaly

Zetaly builds mainframe FinOps software used by 60+ enterprises to control IBM Z costs. Our products serve customers across both IBM pricing models: Zetaly Automated Capacity (ZAC) reduces Monthly License Charges by 5–20% under AWLC by managing the Rolling 4-Hour Average billing peak in real time. Zetaly Data Platform (ZDP) and Zetaly Service Intelligence (ZSI) give TFP customers near-real-time observability into mainframe consumption — at under 0.2% mainframe resource overhead — with dashboards organized for finance and line-of-business audiences.