How to lower TFP baseline before signing IBM’s contract

For the last seven years, IBM has been pushing mainframe customers toward Tailored Fit Pricing (TFP). If your account team has already started this conversation, the most valuable thing you can do is to lower TFP baseline before signing on, because the number IBM locks in will set your floor for the next 3 to 5 years.

Here is something to consider: when you sign on, IBM calculates your baseline from the last 12 months of SCRT data. That baseline determines what you will pay for years ahead, and you cannot renegotiate it after the fact.

What that means is that the window between now and your signature is the single most valuable optimization opportunity you will ever have on TFP. Unfortunately, most customers completely overlook it.

We are going to explain here how IBM builds your TFP baseline and why it matters more than any other number in your IBM TFP contract. And to make it actionable, we’re going to tell you what you can do in the months before you sign to lower your contract costs.

1. Understanding how IBM calculates your TFP baseline

Under TFP’s primary mode, 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, and 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 emphasise is that the lower your baseline, the lower your floor. And what that translates into is that a baseline reduction of 10% today will make your cost 10% cheaper for every year of the contract.

2. The 12-Month SCRT window, your negotiating lever

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

In most cases, however, customers discover this too 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 lower it by reducing actual MSU consumption in the months before. What you do (or don’t do) in that window is permanent.

Here are three actions you can take now, 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

The first challenge is that SCRT reports give you total consumption numbers, but 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 analyzes SMF records, the raw operational data that underpins SCRT reporting, while using only 0.2% of mainframe resources. It points out which products, workloads, and applications are consuming the most, in a dashboard updated every 15 minutes.

Before you can have any conversation with IBM about your baseline, you need this information. 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 understand your consumption, you will be able to reduce it. Under TFP, every MSU you remove from your monthly average before IBM locks your baseline translates directly into a lower cost floor for the lifetime of the contract.

Workload automation

Many organizations 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. It also caps resource usage for lower-priority workloads and applies 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, while ZAC enforces it, consistently and 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 organizations run applications that are rarely used but remain configured at full capacity. The pre-transition window is the right moment to review these and to suspend or decommission dormant workloads. This way you will be able to 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. However, 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 process.

Frequently Asked Questions