FELiX Blog

Eric Chiu
Managing Director

IBM Licence Audits and IASP

The Big Blue Carrot and Stick Approach to Software Licensing in 2022

When IBM first launch its Authorised SAM Provider (IASP) programme in 2020, I held an Open Q&A session with its global programme lead Sanjay Saxena to address the many questions raised by IBM customers and those in the SAM and ITAM community.

My full observation after the session, IBM IASP: The Good, the Bad, and the Ugly, was subsequently published in The ITAM Review and was concluded on the following note:

‘I do believe in Sanjay and his team’s good intentions behind IASP, but when reality hits – auditors losing independence, revenue pressures hitting compliance teams etc – it will be interesting to monitor how the programme progresses.’

18 months after the initial Q&A and after working with several customers evaluating the IASP option globally, it seems that most of my initial suspicions and concerns remain valid, if not more so than before.

The Stick Gets Bigger

IBM appears to be increasingly offering IASP services alongside audit notifications. The message can be often summarised as ‘you have now been selected for a SLR (software licensing review / audit), but we will withdraw this request if you take up an IASP service in 90 days.’

This is significant shift from the earlier observations I had when the programme was first launched, when the carrot and stick was only brought up upon the conclusion of an audit.

It appears that IBM is now pressuring the customer to commit to IASP using the fear of potential noncompliance, before even starting the audit.

What does this mean for IBM customers: If your organisation has been put into a situation like this, it is even more important to have full visibility and understanding of both immediate and future costs associated with IASP, versus the risk associated with a potentially noncompliant audit outcome.

The decision journey could be particularly difficult if you do not have a confident estimate of how big your noncompliance risk is (we can help).

Is it Really a Get-Out-of-Jail-Free Card?

Those of whom that have gone through an IBM compliance audit may agree that most, and the biggest noncompliance liabilities were often caused by accidental deployments, configuration errors or ILMT related Sub-capacity issues, rather than genuine excess requirement on IBM licences.

While IASP may be pitched as ‘you had a chance to fix your issues before we claim liability’, Sanjay’s Q&A response in 2020 already clearly states that the big caveat is that the client must prove ‘no historical use’, as below.

“IBM expects any accidental deployment to be identified by customers in their IASP reports rather than ignored, even if they are corrected before the report is issued. However, if the client and IBM agree that the client had no historical use or planned future use from the accidental deployment under IASP, IBM will not seek to charge it.”

In addition to this, I have not seen any contractual language on ‘error wavier’ as part of the standard IASP terms offered over the past 18 months, casting doubt into the validity of arguably IASP’s biggest Unique Selling Point.

What does this mean for IBM customers: Whatever promises that you are made during an IASP pitch, get IBM to write it down and read it again once it’s written. The most important agreement is the one your organisation sign with IBM, not the one with the IASP provider.

The biggest thing to look out for is the wavier on Sub-capacity violation caused by lack of ILMT at the start of the IASP and incomplete/inaccurate ILMT deployment during the terms of IASP. Be prepared to back-track your IASP decision.

Are you ready to constantly share your data and manually collect your usage stats every year?

All IASP terms I have observed require customers to satisfy at least the following three conditions:

  • Initial baseline report (ELP) to be shared with IBM
  • Subsequent ELPs to be shared to IBM every quarter
  • Acquire licences immediately for reported shortfalls (again no wording on “remediation wavier”)

Failing any of these conditions (and many others as required by IASP terms) would revert the customer back to the default audit terms, potentially rendering any spent or committed spend on the IASP service worthless.

What does this mean for IBM customers: Be aware that your entire IBM deployment will be under constant scrutiny by IBM. More importantly, also be aware that if your previous attempt to manage IBM licensing internally was ineffective because of the inability to collect manual data (required for all non-PVU metric products once a year), the same challenge will fail your IASP conditions as well and lead to a reversal of audit terms.

My updated conclusion is that the current approach of IASP may still offer positive returns but only to two specific types of customers under an active audit notice:

  • those who have never deployed ILMT and therefore likely to attract huge noncompliance claims (subject to WRITTEN waiver agreed), or
  • those who have a significant known over-deployment of IBM software which cannot be remediated and genuinely requires additional licenses (and therefore can acquire this at discounted prices).

For other customers and given the same level of commitment and investment (to IASP), cost savings and risk mitigation from their IBM licensing estate are likely to be better achieved from internal Software Asset Management practices or with existing SAM service providers.