① Licensing · Tailored Fit Pricing
IBM's Software Consumption Solution prices z/OS on the MSU you actually consume across the year, not the single four hour peak that classic licensing punishes. That sounds like relief, and it can be. But the model moves the whole negotiation onto one number, the annual baseline, and a baseline set on an unoptimized estate locks in the cost you came to escape.
Consumption, not the peak.
The Tailored Fit Pricing Software Consumption Solution is an IBM Z pricing model that charges for z/OS and eligible Monthly License Charge software on the MSU actually consumed over the year, aggregated hourly, rather than on the single highest rolling four hour average that classic Monthly License Charge pricing bills against. You commit to an annual MSU baseline, and consumption above that baseline is charged at a defined growth rate.
It is one of two consumption offerings inside Tailored Fit Pricing. The Software Consumption Solution addresses software cost; the separate Hardware Consumption Solution addresses on demand hardware capacity. Both can apply to the same estate. The buyer side point is that moving to consumption does not by itself save money. It changes what you are billed against, from a punishing peak to a committed baseline, and the saving lives entirely in how that baseline is set.
Same estate, two billing bases.
Take an estate whose classic MLC bill is driven by a sharp month end batch peak. Under MLC the charge tracks that peak even though the machine sits far below it for most of the month. The Software Consumption Solution instead totals the MSU consumed hour by hour, so the quiet hours pull the billed figure down toward real usage. Here is the same workload read two ways.
| Measure | Classic MLC basis | Consumption basis |
|---|---|---|
| What is billed | Highest rolling 4 hour average | MSU consumed, aggregated hourly |
| Month end batch peak | 920 MSU | 920 MSU (a few hours) |
| Typical daytime load | billed at peak | 540 MSU |
| Overnight quiet load | billed at peak | 180 MSU |
| Effective billed MSU | 920 | ~610 avg |
Illustrative MSU figures for arithmetic only. Real consumption profiles and baselines are specific to your estate and contract.
On a peaky estate the consumption basis clearly tells a kinder story, because the bill stops being held hostage by a four hour window that occurs once a month. But notice the trap. IBM does not set the baseline at the kind average. The opening baseline proposal commonly anchors near recent peak influenced consumption, and the growth rate is the second lever. The two together decide whether the move is a real saving or a relabel.
| Baseline set at | Annual commitment | Outcome for the buyer |
|---|---|---|
| Recent peak influenced figure | 900 MSU | Saving handed back to IBM |
| Validated consumption | 640 MSU | Saving retained, growth headroom real |
| The gap you negotiate | 260 MSU | The whole value of the move |
The baseline, not the pricing model name, is where the money is won or lost.
That 260 MSU gap is the entire economic case. Sign at 900 and the consumption model has done nothing for you except remove an operational headache. Sign at a validated 640 and you keep the structural saving and buy genuine growth headroom before any uplift applies. Same contract, same machine, two completely different five year outcomes, decided before anyone touches the technology.
The baseline is the contract.
Consumption pricing is genuinely cleaner to operate, but it concentrates risk into a single negotiated number and a single negotiated rate. The places it bites are predictable.
The baseline anchors high when it is drawn from peak influenced months, so the reference period IBM uses to propose it is itself a negotiation. The growth rate above baseline is a second price you are agreeing to years in advance, and a generous looking baseline paired with a steep growth rate can cost more than a tight baseline. Term length locks both: a multi year commitment on a baseline you did not validate is a multi year mistake. And because the model removes the capping reflex, estates sometimes stop measuring consumption at all, which is exactly when it drifts.
How to optimize it.
Levers on the Software Consumption Solution
Across 500+ engagements and $180M+ of negotiated mainframe spend, the consumption models that saved money were the ones where the buyer set the baseline on validated data and priced the growth rate as carefully as the headline. The ones that disappointed were signed on IBM's opening reference figure. The model is sound. The baseline is the negotiation.
An IBM Z pricing model that charges for z/OS and eligible MLC software on MSU actually consumed over the year, aggregated hourly, rather than on the single rolling four hour average peak that classic licensing measures. You commit to an annual baseline and consumption above it is billed at a defined growth rate.
The Software Consumption Solution covers eligible software charges measured in consumed MSU. The Hardware Consumption Solution is a separate offering for on demand hardware capacity, and more recently zIIP capacity on the newest machines. Different cost problems, and both can apply to the same estate.
It is designed to. Because the charge tracks consumed MSU rather than a four hour peak, the pressure to soft cap purely to hold down a billing peak eases. The trade is that the annual baseline becomes the number that governs the term, so it must be set on an optimized estate.
No. It removes peak distortion, which helps estates driven by short spikes, but the saving depends entirely on the baseline committed and the growth rate negotiated. A baseline set above real consumption hands the saving back to IBM. The work is in the baseline, not the badge on the contract.
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →