You’re involved with organising the upcoming event, can you tell us a bit about what you’ll be discussing there?
Put simply, the day is ‘all about audits’ – we know that software asset managers find vendor audits one of the hardest things to deal with in their role, so we wanted to take the opportunity to spend a whole day focusing on them. In the morning we’ll have a series of talks from licensing experts who will discuss specific vendor audits – for instance, Microsoft, Oracle and IBM. In the afternoon we’ll have a series of round tables where people can spend time sharing their experiences of being audited. Our experts will also be present during the round tables to provide feedback, support and advice to those participating in the round tables
Who do you recommend should come to this event and why? What can people learn?
We’d like the event to be oriented to software asset managers working in end user organisations. As a software asset manager I have often felt very isolated – I am the only person in the organisation doing a job that no one else really understands. It gets even harder when the company is audited because the process brutally highlights the result of poor SAM work practices that stretch back many years – basically you are in a position where you tell people they have done a bad job, and no one likes to hear that.
What I’d like people to gain from the day is a sense that they are part of a larger community, that other people share both their challenges and their satisfactions. I would also like people to come away with a toolbox of ideas to help them manage audits more effectively in future – and of course if we can improve people’s licensing knowledge and confidence along the way, that would be great too.
What’s the worst scenario you have seen when a company wasn’t prepared for a software audit?
The worst audits are those where I get called in after the initial reconciliation has been completed and the results have come as a complete shock. Often the audit hasn’t had proper senior management sponsorship and support, so there were no controls in place to ensure the process was thorough and the results are robust. Suddenly everyone starts blaming everyone else, and IT management want you to wave a magical wand and sort everything out ‘so it never happens again’.
When people feel threatened and accusations start to fly things get very ugly and a sense of proportion goes out the window. . I have been threatened with the sack on two occasions as a result of an audit – the first time was by an IT manager who had a shortfall of £250,000+ in his organisation, while the second had a shortfall of six thousand pounds!! The first gentleman’s job truly was threatened, so I’m not surprised he was furious, while the second had invested heavily in software asset management over many years and had excellent processes in place – so much so that he saw a £6,000 shortfall as a personal failure – hence the vitriolic reaction to what were actually excellent results.
How would preparation have helped to avoid this situation?
The best preparation for an audit is proper software asset management process with robust risk management – if I have told managers that I don’t have the proper tools in place to manage Oracle and I suspect there may be a shortfall, my experience is that management are less likely to be taken by surprise when we are audited and there is a nasty compliance bill. I have also covered my back because the decision to de-prioritise the purchase of an appropriate tool is not mine – it was taken by management, who were informed of the risks they were running.
Once an audit has started, it needs to be put on a proper project footing – I ensure we have a sponsor and a steering board, agree a plan with the vendor, ensure there is time to revisit results to identify errors such as missing entitlement, and agree who will authorise the results of the audit internally. I don’t let the vendor push you around about how long the audit should take, although that can be difficult – audits are expensive for a vendor so they want to get through them as quickly as possible, but as an organisation we have every right to ensure the audit is carried out thoroughly and the results are correct precisely because it is a legal obligation and has serious consequences for the business.
Does preparation differ depending on whether you’re looking at Oracle, SAP, IBM or any other vendor?
The principles remain the same, but the details will differ. Some vendors are harder than others because the licenses models are more complex and audit methods are subjective (Oracle, I’m looking at you!). I would never hesitate to engage a 3rd party specialist in support if I felt I didn’t have the skills in house.
How do you get management support? Often the SAM manager knows what needs to be done but they are being pulled in different directions by management, leaving them little time to prepare
An audit (whether a ‘soft audit’ or one with full legal force behind it) is still carried out within the terms and conditions of the license contract and / or Intellectual Property Law. This means it is the company directors that are ultimately accountable for the audit, NOT you.
A software asset manager is in a similar position to a lawyer – we provide advice about how the audit should be conducted, but we cannot make decisions. If management ignore the audit request, then ethically I must advise them this is wrong, but once I have done that, I ignore it too until management tell me otherwise – although I keep reminding management of the risks they are running by not participating in the audit.
However if management refuse to take action, it is up to the vendor to take the next steps in the process of enforcing their right to audit, not me.
Once an audit has commenced, if I find there is a lack of management support, I identify it as a risk on the project risk register and escalate it through the risk management process. I continue with the audit as best I can, behaving as professionally and ethically as possible, and leave it to the vendor to escalate it legally if they feel they need to.
When management are pulling different directions and vendors are applying pressure on me, it’s incredibly difficult to find the right approach while still remaining true to my professional ethics. But software asset managers aren’t the only ones who have to deal with sticky ethical situations – lawyers and police face them all the time, and I have found it incredibly useful to talk over issues I’ve faced in vendor audits with friends in both professions.
What are your top 5 tips for success when it comes to software audits?
- Run the audit as a formal project, preferably under the auspices of the portfolio / programme board if there is one. The paperwork involved is annoying, but the structure a formal project provides is invaluable and the additional escalation paths through the portfolio / programme board can be useful.
- Maintain a risk register and use it to communicate your risks and how you are managing them. Risks should be shared with your line management, with the project portfolio board, and with information security, who are responsible in most larger organisations for identifying and managing IT risks.
- Remember you are responsible but NOT accountable. Management make decisions, not you. Even when they delegate some decisions to you, what they are doing is trusting your advice and accepting it without the formality of a ‘we will do this’.
- Document who makes what decisions (even if you just keep copies of emails), and if a decision is made by NOT making a decision (e.g. if a deadline is missed) then document that too. If a decision is made verbally that you think may be important later on, document the conversation in an email and keep a copy.
- Always, always, always behave professionally and ethically. Use of software is a privilege, not a right and you must always do your best to help the vendor get the correct result from the audit process – no matter what pressure is on you to take sides. If anyone asks you to fake data or hide results, you must immediately report it internally (not to the vendor, you have a duty of confidentiality to your company which you would be in breach of by telling the vendor). Any reputable company will take action. If they do not, well, welcome to the world of the whistleblower – your next step is up to you.
What would your advice be to someone who has recently failed a software audit?
It depends how you define fail! As I illustrated above, different companies and individuals will view audit success or failure differently – and most do so on financial terms. But for me a bad audit is one where everyone blames everyone else and then starts putting pressure on me to wave a magic wand and ‘fix’ software asset management.
In terms of advice, immediately after the audit, take some time to write a software vendor audit policy and process – basically, think about how the audit process could have been improved, and write down how you would do it next time. Circulate it to your key stakeholders for their feedback. Even if the policy is never formally approved or implemented, people are still likely to follow it next time there is an audit.
Secondly, remember that you didn’t become non-compliant overnight, and you won’t prevent it from happening again by finding a magic wand and waving it, no matter how hard management are pushing for a new tool or to outsource the whole SAM process. Really fixing software asset management requires major cultural and process change and that is difficult for people, particularly when their professional competence has been questioned. Try and get everyone to think in terms of continual improvement – thinking about making small but regular changes that will improve processes, manage compliance, and make people’s jobs easier.
Finally, implement and maintain a software asset management risk register where you can identify SAM risks and communicate them to your managers and information security. That way your managers can help you prioritise which risks you should address first, and help you build a business case for the tools and changes that need to be implemented to stay compliant in future. It also means that when the next audit hits and it’s for a vendor you haven’t started working on yet, your management team will have been involved in the decision to de-prioritise that particular vendor and will (hopefully) recognise that this will be reflected in the results.