The following is an adaptation from a transcript of one of XTIVIA’s helpful webinars. The video is available at the bottom of the page, where you’ll also find a form to contact us should you have any questions or are interested to learn more! This is the third article adapted from this informative conversation. Find the first part here and the second part here.
In this article, ITAA Director Koen Din Jung discusses the impact of audits, how they impact your relationship with IBM, and the steps you can take to handle an audit.
First, I’ll talk a little about the IBM audit process itself. Then I’ll talk about tips and tricks in each audit phase. No matter what phase you’re in, you can always do things to improve the outcome. But, of course, the earlier you start taking the right steps, the better the outcome will be.
At a high level, the audit starts when you receive a notification letter from IBM. Sometimes it’s a formal letter, sometimes it’s an email, but this communication will come from IBM, and they’ll announce an audit, which they call a review. So those are the standard parties IBM works with.
They’ll ask for a kickoff meeting. So this kickoff meeting will be a three-way call in which IBM will talk about the audit process and then ask KPMG or Deloitte to talk about the specifics. Then you, as a customer, will be asked to talk about your organization and perhaps also provide details about timelines. Then they’ll proceed to data gathering.
After the kickoff is done, it’ll be a one-on-one exercise between the auditor and you as a customer. So IBM will step away during that period. The auditor will provide information requests, and once all the data is gathered, they’ll ask for certain analysis and validation testing to make sure that the data set they collected is complete and accurate.
Then the final stage is the reporting phase. That’s when the auditor shows their technical findings. Once the report has been confirmed or at least that phase is completed, normally, there are findings, unfortunately, in those audit reports. Then the settlement discussions will begin between IBM and you as a customer.
The typical throughput time varies widely, but often they’ll say it can be done in three months. In reality, that’s probably only true for the smallest organizations. For slightly larger organizations, I would count on at least six months, but it’s possible it could take a year and a half or longer. In situations with these types of extended delays, there are usually specific explanatory reasons.
I’ll move on now to talk about the tips and tricks in each phase. The best way to optimize the outcome of the audits is to start as early as possible. Amir talked before about preparing by doing an internal dry run. An internal dry run is good if you have the time available to actually do an internal compliance assessment to see where you stand.
The second tip is to make sure that you fully meet the requirements for sub-capacity licensing because if you don’t fully meet them yet, there are still things you can do before an audit to put yourself in better shape. I’ll talk a little bit later about why meeting those requirements is so important because of the significant risk involved. Aside from doing a dry run, the most important thing you can do is to make sure that you understand the sub-capacity requirements and that you meet them as much as possible.
When you get into the kickoff and scoping phase, it’s very important that you keep in mind that the audit process itself is negotiable: there’s no one way to do an audit. There are many different sources that can be used or steps that can be taken, so it’s important that you make sure whatever audit process is performed matches your priorities as an organization.
Also, the timeline. You might want to start at a later date because of the availability of internal staff. The audit terms and conditions actually state that the audit should minimize business disruption, so this is something you can use to your benefit.
When it comes to running order scripts, that’s a whole separate topic, but they’re not mandatory in the end. It’s important to consider what data sources you have internally versus what would the outcome be if you would run outer scripts? Many legal teams and organizations find nondisclosure agreements important.
Once you arrive at the data gathering phase, it’s also very important that all data is collected through a single contact person within your organization. You want to avoid the auditor going on a fishing expedition throughout your organization, asking questions to people everywhere, because then you don’t have insight into what information has been shared. It would also make it more difficult for you to understand the audit report in the end. Assigning a single contact person will help you be able to vet all the questions being asked and also reduce the number of surprises in the end.
Rather than just blindly forwarding the technical details that your staff has given you, it’s important to think about whether or not you are capturing the context fully. For example, are you considering non-production use? Have you considered being cold standbys? It’s good to give all that context to the auditor in one go so that you don’t have significant findings you have to push back against at the end.
That leads me to the reporting phase. First, you’ll always receive a draft report from the auditor before it goes to IBM. It’s very important that you take your time to carefully review this report and push back on any items you disagree with, not just on the license entitlements, which you’ve purchased, but especially on the deployment side because that part is where most of the incorrect findings are. That’s simply due to the limited set of information the auditor collects. They make certain assumptions, but those assumptions can be very much inaccurate and it’s very common. I’ve seen that if you push back on enough areas, you can actually reduce the value of the technical shortfalls by 90%. That’s not always the case, but it happens fairly often.
Once you have that compliance report, once that’s shared with IBM and assuming there are still license shortfalls in there, it doesn’t automatically mean you have to buy that amount of licenses from IBM. That might be IBM’s initial proposal, but it’s important to realize that even though you might be short a certain number of PVU licenses, for example, you can still propose to settle using a different metric. As long as it’s the same product covering the same functionality, there might be lower-cost alternatives you can use to cover your license shortfall.
The last two tips are probably the hardest to follow because once the audit is done, everybody wants to move on with their lives. However, it’s important that if you have settled on something, for example, fixing ILMT or cleaning up some installations, it’s important to actually follow through on that because otherwise, you might get hit with a follow-up audit the next year.
Finally, the most valuable follow-up step, which is not commonly implemented, is to capture all the odd steps you went through because now you have experience with who provided information and what the audit procedures were. This is actually something you can build on moving forward with internal software asset management procedures for IBM. It can be hard to keep focus after an audit has been completed, but it’s really an important recommendation.
That’s kind of a deep dive from start to finish on the tips and tricks on dealing with audits. Now I’ll talk a little bit more about sub-capacity licensing and why it’s so important.
Essentially when it comes to some of IBM’s most common license metrics, they’re licensed based on processor and server capacity, and specifically, the most common metric there would be the processor value units, which expresses the power of your servers in a number of PVU points.
IBM’s default rule is that when you install an IBM product that is licensed based on PVUs, you have to license the full capacity of the physical machine. So it doesn’t matter if it’s a virtual machine or a logical partition. Those installations have to be licensed to the full capacity of the machine unless you meet the requirements for sub-capacity licensing.
There are various requirements, but the most challenging is installing the IBM license metric tool or accepted alternative. There are not many of them. This is the number one compliance risk area for all customers.
Just to give an example, on average, what we’ve calculated is that a customer for PVU-based products will have a compliance risk value of two and a half times what they spend every year on those products if they meet the sub-capacity requirements. However, if they don’t meet those requirements, the risk becomes ten times as high. So, if you had spent $1 million per year on certain PVU-based products based on full capacity, you could easily have a $25 million risk for those products. It could be higher or lower, but it’s an average, and in almost all cases, it’s a very significant risk.
When it comes to the IBM Licensing Metric Tool (ILMT), here’s what to focus on. Number one, if you have any processor-based metrics such as PVU, VPC, or some RVU metrics, it’s very important that you have island ILMT installed, but also that it’s operating correctly. Most importantly, it’s critical that your reporting is configured correctly because, by default, ILMT parts are inaccurate. They make certain assumptions about what’s installed, but you have to go through a software classification process to make sure that all the installations are reported correctly.
On the one hand, you have to make sure it’s working correctly from a technical standpoint, but reporting-wise, you also have to make sure that the numbers reported by ILMT are accurate. If those numbers are not up to date, the technical risk is that you don’t meet the sub-capacity requirements. That’s an issue in itself.
There’s also a great risk cause that is over-reporting of PVU quantities. So without proper software classification and bundling or not connecting to the VM managers, ILMT might actually report many more PVUs than are actually deployed. It’s very important that you carefully review those reports before you provide them to an auditor.
For any additional questions, please reach out to XTIVIA by filling out this form. For nearly three decades, XTIVIA has been providing a variety of expert IT services to hundreds of businesses in countless industries. If you can imagine the business outcome, XTIVIA can create it with technology.
Watch Part 3 of IBM Audits: Myth, Pitfalls, Tips & Tricks here.