What REALLY Happens During an Audit (Part 3 of 3)

Audits

What REALLY Happens During an Audit (Part 3 of 3)

This is part three of a three part series. Read the first part here.

This article has been contributed by Kylie Fowler. Regular columnist and Analyst at The ITAM Review.

Once you have pulled the deployment and entitlement data together, it must be compared to identify if there are any license shortfalls.

However bear in mind that there may be several versions of data, particularly if the data gathering process has involved different business units or IT departments. Make sure you send the correct version to the auditor!

Reconciliation and Validation

The reconciliation process will almost always be carried out either by the vendor themselves or by a neutral 3^rd party. Although there are license management tools available that can assist vendors and 3^rd parties with the reconciliation process, it is still a largely manual process and is open to considerable error, particularly when calculating the effect of upgrades, downgrades, cross-grades and maintenance.

Once the auditor has completed the reconciliation statement, they will return it to you so you can review it and confirm that you accept the results. Although there is no doubt your auditor would prefer you to accept the results there and then, it is important that you review the reconciliation statement and supporting data thoroughly. It is not enough to review the results on a screen in the meeting room, you must be able to analyse the data in depth on your own computer to validate the results.

In particular, you should:

• Double check calculations, in particular upgrades and downgrades
• Ensure support and maintenance benefits have been applied correctly
• Check for any glaring or surprising discrepancies between deployment and entitlement and follow up on why this has occurred – for instance although a business unit or subsidiary that has deployed a Pro version of software but owns the Standard version has probably made a packaging error (ie they used a Pro disk to create the package rather than a Std disk) – in which case they are non-compliant and will need to purchase the correct licenses – it may just be that they received a free cross grade from Microsoft 10 years ago when the Pro version of the product was introduced, and if you ask them about it they may still have the cross-grade certificate to prove it (Yes, that has happened to me!).

Tracking down the source of these sorts of discrepancies is time-consuming, and the auditor is likely to put a lot of pressure on you to wind down the validation process as soon as possible – after all, you are now asking him or her to spend time on your audit that they could be using to audit another company, and worse, every additional piece of entitlement identified is whittling away at their commission!

You will probably need to prioritise your investigations and focus on the big ‘chunks’ of missing entitlement. This can cause problems politically, for instance if a small business unit finds it has made an error in the data it provided which is minor in the scheme of things, but which will hit them disproportionately if you can’t get it corrected. You will find that not only do you utilise your negotiating skills working with the auditor to gain time to identify and correct discrepancies, but they also get a work-out internally as you explain your decisions and adjudicate whether or not the correction of one error is worth pursuing in preference to others.

But finally, (and much to your auditors relief) you must draw a line and tell everyone that enough is enough! The validation process can’t go on forever, and you and the auditor must reach a settlement.

Settlement

Depending how much of a nuisance you have been to audit, you may find that agreeing a settlement can offer a chance to mend your frazzled relationship with your vendor and to negotiate an opportunity to fix silly, but expensive mistakes, like a packaging error (where one product was packaged and deployed but a different product purchased) or a Citrix publication error (where the application published on a Citrix server is different to the application users are actually entitled to access).

In the majority of audits, accounting and revenue recognition rules mean that settlement actually involves the purchase of licenses to make up an actual shortfall. Your auditor will present you with a list of licences he or she believes you need to buy to become compliant. Occasionally a vendor may try to charge some sort of fee or fine, although the legality of this could be questioned in the UK, where punitive damages for breach of contract are not permitted by the courts.

However although the list and number of license shortfalls may seem cut and dried, there is still plenty of room for negotiation, particularly if it will help rebuild the long-term relationship. For instance, if you have made a silly but expensive deployment mistake, you may be able to agree with the vendor that you will spend an equivalent amount on licenses you know you will need in future, and the vendor will give you time to correct the deployment.

There is also often room to negotiate on price – both LARs and the vendor themselves may agree to give you deep discounts in order to help mend a fractured relationship.

Settlement can be particularly fraught if a large amount of non-compliance is the result of poor advice either from the reseller or LAR, or, as occasionally has happened, a salesperson from the vendors themselves!

The brutal truth is that if the non-compliance is the result of poor advice from a reseller, or even the vendor, you must still remediate it by purchasing the correct licenses and then seek compensation from the reseller separately. This can be a hard message to communicate internally, but it is merely an application of the classic principle caveat emptor – buyer beware.

Learn the Lessons

It can be extremely challenging to be a Software Asset Manager during a software licensing audit as you are constantly ‘piggy in the middle’. In particular, a key role is to mediate between the auditor and the company, trying to explain and justify the company’s position to the auditor and the auditor’s position to your company. It is a particularly thankless role if you also have accountability for the day to day running of SAM, because an audit is effectively the ultimate arbiter of whether your day to day tools, processes and people are up to scratch.

No matter the outcome of an audit, there will always be lessons to be learned. Avoid playing the blame game (particularly likely if audit and remediation costs are passed through to business units) and focus on what can be done better in future.

For instance:

• Analyse your audit data to look at your surplus licenses. By its very nature an audit is designed to focus on short falls, but surpluses are just as important – the purchase of surplus licenses is a complete waste of money
• Identify the causes of major areas of non-compliance (both shortfalls and surpluses) and see what changes can be made to reduce the risks
• Think about which processes can be improved to reduce risks in future e.g. software harvesting, improved record keeping
• Take the opportunity to push for increasing awareness of SAM within the organisation e.g. SAM training for all configuration and change managers so they are aware how important their role is in maintaining compliance

Finally, compile a formal audit report and present it to senior management, if possible including internal Risk Management. This will help raise the profile of SAM and provide visibility of the costs of the audit, ensuring that license compliance is recognised as a major business risk. It will also help you obtain the resource and support you need when the next audit request lands in your inbox.

This article has been contributed by Kylie Fowler. Regular columnist and Analyst at The ITAM Review.

This is part three of a three part series. Read the first part here and the second part here.

Photo Credit

Can’t find what you’re looking for?