Firstly, apologies for not writing an article in so long; we’ve been extremely busy dealing with a recent IBM ‘review’. We learnt an awful lot during and post review, and I wanted to share my experiences with you. Obviously, I’m going to keep a number of details secret and not reveal my identity. It’s a shame really; I write a number of articles and technical documentation for other elements of my job, but can’t share my SAM and software licensing successes thanks to the stigma and the aggressiveness of software vendors. It’s just the world we live in!
So, here are the tips I have for anyone going through, or about to go through a vendor audit. It is important to mention that we are by no means a large organisation; we are small fish in terms of size and custom to IBM, but we still felt the full force of their wrath….
What IBM don’t tell you (well they didn’t tell us anyway) is that we actually had a number of licenses that we owned that were not considered ‘active’ in IBM’s eyes. Basically, we had a number of historic purchases that we decided were no longer in use at some point, so we stopped paying support and didn’t include it in our current agreement. However, what was not explained to us was the fact that we actually are still entitled to use these licenses. They are perpetual, just not ‘active’. You have the right to make these licenses active again for a much smaller fee than purchasing a new IBM license. Excellent news, right? Wrong. The entitlement documentation was lost (completely our fault) but thankfully we still had purchasing information.
The next issue was the fact that our numbers and the numbers IBM were providing were not the same. IBM (through Passport Advantage and our ‘Account Manager’) said we only had a small number of licenses, when our historic purchase information suggested we had a lot more. We spent an awful lot of effort and time making IBM double check the figures. In the end, we got a much better number than IBM were first quoting us, but still not quite the numbers we thought. Quite frankly, we didn’t have the resources or IBM licensing expertise to challenge them any further. Prime example of needing a licensing expert to deal with issues like this and not a general IT professional; we do not have the required skills or expertise to be in a strong position to conduct negotiations.
It seemed odd, but in one of our meetings with IBM we had to tell them what our entitlement was. I assigned one of my service desk staff to compile a simple Excel document highlighting our contract entitlement and our perpetual licenses. We then cross referenced this with our entitlement data (from ILMT which IBM provided for the audit) and identified a number of older perpetual licenses that we could upgrade for a small fee.
Did IBM inform us of this? No, we brought in an IBM Licensing Expert for two days (at great cost) to try and perform some sort of training for myself and my Service Desk Manager so we could ‘get by’ this audit. Top tip: find your whole entitlement and don’t just go off the figures from your agreements.
Massively biased opinion here based on our experiences, but do not trust the data from ILMT. Initially, due to being a bit spooked by the whole audit process and the way in which IBM conducted themselves, we were too naive and cautious to question the data. However, thanks to one of our server guys we identified that ILMT was reporting incorrectly and that IBM were using data that was not accurate. This was not a good start to the engagement and did not fill us with much confidence in the tool.
We had to configure the solution ourselves so that it reported correctly and didn’t report duplicate servers and PVU’s (which was the main problem so it was providing double the consumption data. I just assumed we’d expanded our usage of IBM products). Thank goodness we have smart people within the organisation.
Challenge IBM’s data. Do not be afraid to challenge the vendor’s information on entitlement or the consumption data they provide. Thankfully, we didn’t have too many extra licenses to purchase, so kindly rejected IBM’s request for us to use ILMT to manage our IBM estate. It was too hard to use, inaccurate and not required for our relatively small (and now compliant) investment!
My final piece of important advice would be to check the terms of your contract. How does the contract word or state certain audit activity?;
1. What data are you expected to provide? Are they clearly defined?
2. What technologies will IBM implement to gather the data? Is it clearly defined?
3. Do IBM specify how much disruption implementing their technology will have on your systems? ILMT ground some of our servers to a halt causing other issues
4. How much access will they require to your network? Don’t show them anything they do not need to see
5. If they use a third party, do you have a say in which third party? We accept certain ‘auditors’ as part of our on-going work, but some vendors we wouldn’t let in. Is the auditor specified in the contract?
6. Set a ‘grace’ period in your contract. Once they have audited you, make sure they can’t come back for a while!
7. Agree any fee’s for unlicensed application and back maintenance. Haggle, get as big a discount as you can
8. Secondary Use Rights. Some IBM applications allow you to use other applications in tandem with no extra license required. Get a clear definition as to how this works.
Read your contract as many times as you can before they engage with you. Showing you have taken the time to understand your contract and entitlement will make the relationship a little easier and will help you pre-forecast any spend that may be required.
As a final note, I have to say I was not impressed with the aggressiveness of IBM in auditing us. I would suggest they stop purchasing so many vendors, adding random license metrics that don’t make any sense and focus their time on telling their customers their rights and sorting out accuracy of entitlement.