Presumably what management really would like to know is how many dollars (euros, whatever currency you're working in) was saved. How you go about calculating that depends...
If you're under Tailored Fit Pricing with IBM your IBM software bill is based on the CPU time you consume over the year. You should have two numbers from IBM the: the baseline cost per "MSU" (really MSU hour) and the lower (50%?) incremental cost per MSU that kicks in after you've reached your baseline for the year. Note that TFP contracts are individually negotiated but my understanding is that in most contracts, reducing your MSU-hours consumed below the annual baseline won't reduce the actual money you're committed to send to IBM. But you could still argue that the value of MSU-hours saved is that baseline cost per MSU. Converting from CPU time to MSU-hours is relatively straight-forward: MSU-hours consumed = (MSU Rating of Machine / GPs of the machine) * CPU-seconds / 3600 If your TFP agreement says that you pay $x / MSU for your baseline and $y / MSU for your incremental beyond the baseline, multiply by the appropriate number depending on whether you're going to be above or below the baseline for the year. (Recognizing that if you're below, you may not actually be reducing the money sent to IBM.) That's one of TFP's selling points: you can more directly relate CPU consumption to your software costs. If you don't have TFP you're most likely under WLC (Workload License Charges) and your IBM MLC software bill is based on the peak rolling 4 hour average for the month. If that's the case, you first have to determine if you reduced that peak. If you didn't, you didn't save anything. If you did, then you need to find your incremental MLC cost per MSU. That is not the average cost/MSU. Your IBM MLC rep should be able to help with this. There may be an argument to be made that if you removed workload from your peak, but the peak didn't go down because other latent demand immediately consumed that capacity, well presumably there was some business value in that other work getting done sooner. (If there wasn't then think about whether that work needs to run in the peak!) If you're not under TFP, separate from MLC, your IBM IPLA/PPA software is likely not based on the R4HA and is likely based on some amount of paid-for capacity (which could be less than your hardware capacity). Typically, reducing your usage won't reduce those (usually annual) maintenance charges until/unless you give back some of your purchased license capacity. But then you'll have to re-purchase that license capacity if you need it back in the future. ISV software costs are of course dependent on your software contracts. You may possibly have a combination of all 3 of the aforementioned models. Then there's the whole hardware cost point of view too. For many customers this is somewhat abstract and is something along the lines of "if we're reducing our utilization maybe we can delay an eventual hardware upgrade". Putting a dollar value on that may be... difficult. But if you're regularly doing Capacity On Demand to add more capacity, and you've enabled efficiencies that have let you avoid a COD event, then the savings from that should be fairly obviously the cost of that COD that you avoided. Understanding the real dollar impact of tuning efforts is important but obviously requires knowledge of how your billing is arranged. We've seen customers who've saved significant real dollars from tuning to avoid COD or reducing their peak utilization under R4HA. But we've also seen customers who've not saved real dollars at all because they were paying for the R4HA peak and they were only affecting things that were off-peak. For customers trying to move workload off from the mainframe, it can sometimes be hard to reduce mainframe costs until they've moved off really significant amounts of workload. (Notice I didn't use the word "savings" in the previous sentence: whether the mainframe is cheaper or more expensive than the environment they're moving too is a yet deeper discussion!) Scott Chapman ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
