Licensing With The Frenemy -- Exploring An IBM Software Audit

I’m conducting research for our sourcing clients about the right approach to take in IBM software audits. In combing through Forrester’s IBM software sourcing inquiries, I’ve found that most sourcing professionals don't realize they have a licensing problem until it's too late — and they’re struggling to get quick information and guidance. 

Some of the problems are vendor-driven:  Market expectations keep the IBM Software Group on a high growth trajectory, and license audits contribute to their objectives. Others are client-driven: IBM's clients should expect audits that reconcile license discrepancies but then struggle to leverage resources to remain compliant. Regardless of the underlying reasons, these audits often end up in the same place — clients who are drowning in contract administration and compliance costs and frustrated with their IBM relationship.

As part of my research on the auditing process, I’ve been interviewing some former IBM sales reps, and I’m seeing a few trends. Some of my preliminary findings indicate: 
 

  1. Sales teams often don’t have control over who’s audited  . . . We spoke with one former IBM sales rep who noted that sales reps don’t have much control over auditing activity. He told us the audit department creates an audit letter and a spreadsheet of clients, pushes that to the sales team, and asks them to find the audit targets. This rep indicated that the auditing team asks sales to continue to call into this exec until they agreed to the audit, at which time it’s handed back to the audit team. So your rep may not be deeply connected to the process behind your audit. 
     
  2. . . . Yet sales teams are often beneficiaries of the audit process. We’d like to think of our sales reps as our trusted advisors, but one former rep told us that sales reps stand to gain some significant commissions from an audit. While there are many factors that dictate the right number of licenses for an organization, several reps told us that this high-margin business is beneficial to IBM and sales — so there’s little incentive to change it.
     
  3. Some audit risks are vendor-created. The tech market changes every day — and IBM’s acquisitions may be a reason for audits. While vendors often view these audits as a simple correction of misaligned license agreements, the impact on the client is the same. For example, after IBM’s acquisition of Cognos, an open enterprise licensing structure was replaced by new policies, and this required audits. The audit is not driven by any specific client activity yet still creates a lot of compliance issues that clients must react to.     

Sound frightening? Perhaps, if you expected your sales rep was always acting in your best interest. Informative? Absolutely. Staying connected with IBM’s audit process can help you prepare for the audit process yourself — and even improve your relationships with IBM.  

It’s important to note that these preliminary findings may not be representative of all situations. But as I continue my research, I’ll post other findings. In fact, that’s a key reason for this post: If you've managed an organization through an IBM audit or have an IBM negotiation story, I'd love to hear about your experience. Further research with users is needed to make sure we aren’t getting too much ex-employee bias. If you’re not comfortable posting in the comments, email me directly at cvillanueva@forrester.com.

Comments

IBM Software Audits

Hi Clarence,

Last year, I managed my organisation through an audit of our use of DB2. The audit was carried out on behalf of IBM by Deloitte. Some feedback that mey be relevant to your study :

(1) The audit was not instigated by or driven by our local IBM organisation (I'm in Ireland). It originated from the IBM Software Licence Compliance team ibased in the UK (covering UK and Ireland). As far as I know, neither our IBM account manager nor the local IBM partner/reseller knoew about the audit in advance.

(2) Contact details used by IBM to notify us of the audit were inaccurate, and resulted in a significant delay to the start of the audit.

(3) My colleagues were more knowledgable about how to count licensable PVUs than than the Deloitte audit team.

(4) My colleagues were also more knowledgable about the relationship between hardare and software licensing than either the Deloitte team or the IBM Software Licence Manager who managed the audit on IBM's behalf. This become clear when interim audit data sent to us by IBM/Deloitte showed DB2 PVU figures associated with processors that we hadn't yet licensed and unlocked.

(5) Either our local IBM account team, or the local IBM partner/reseller did not adequately explain IBM's sub-capacity licensing terms and conditions to us some years ago, with the result that, stricly speaking, at the time of the audit, we were licencing DB2 on a full count basis. Howeverr, IBM was quite willing to allow the audit to be completed on the basis of sub-capacity licensing rules.

(6) Although the audit was confined to DB2 usage, it took an elapsed time of about eight months from start to end to complete the audit. This was much much longer than I would have expected, given its scope.

Regards

Maurice O'Connor
SVM Council Member, EMEA

IBM Audits - Focus on Sub Capacity

I am an intellectual property attorney specializing in defending end-users in software audit matters including those initiated by IBM. We get hired by targets of IBM audits to facilitate the flow of information and protect the client's interest in the audit process. The most significant compliance claims we have encountered arise under Virtualization Capacity (Sub-Capacity) License terms in IBM's Passport Advantage Licensing offering. According to IBM Sub-Capacity licensing "allows flexible software licensing usinge advanced virtualization capabilities such as shared processor pools, micro-partitioning, virtual machines and dynamic reallocation of resources." Sub Capacity Licensing is very attactive in data center environments because "it enables customers to license software for only the processor core capacity availab to the partition hosting the IBM software." Although very attractive, Sub-Capacity licensing can create very significant legal liability under two common fact patterns.

1. Customer Purchases for Sub-Capacity but servers are not capped - in this scenario IBM entitlements are purchased under certain assumptions regarding the server capacity and eligibility for sub-capacity licensing. For whatever reason during the initial deployment or afterwards the hardware is not capped and the processor core capacity available to the partition hosting the server software is much greater than originally believed resulting in significant financial exposure under IBM's Processor Value Unit (PVU) calculations.

2. Customer Purchases for Sub-Capacity but fails to deploy ILMT - in this scenario IBM entitlements are purchased under the assumption of eligibility for sub-capacity licensing and is correctly deployed using appropriate capping. However, because the client fails to delpoy the ILMT discovery tool or to otherwise maintain the required monthly reports, IBM claims that customer owes for the full capacity of the hardware under PVU calculations nothwithstanding the use of capping. IBM argues that because IBM Passport Advantage PVU-based offerings license terms require ILMT reports be created, verified, adjusted, signed, and saved, any customer that fails to comply with the ILMT requirements forfeits it's rights to use sub-capacity licensing and therefore owes as if the hardware had not been capped.

While there are many issues that arise in IBM audits, the issues involving sub-capacity licensing are the most prevalent and involve the most financial exposure based upon our experience.

Rob Scott
Managing Partner
Scott & Scott, LLP
rjscott@scottandscottllp.com

Great Points, Rob and Maurice

My upcoming paper touches on sub-capacity licensing--though business benefits exist under this model, it also presents some risks as you rightly noted. Any suggestions on how to mitigate those risks? What are some people doing out there? In my conversations with clients, there are a few methods by which they addreses this issue, but it appears there are no silver bullets.