Continuous Improvement and Software Asset Management

If you are reading this blog, hopefully you will have implemented your Software Asset Management system, and have the appropriate processes and people in place to derive the reports and data that are going to support your IT department, as well your business.

Now might be the time to pat yourself on the back, or dwell a pause of two marching paces and admire the splendour and view that your Software Asset Management system has created.  However; don’t rest on your laurels!  As I heard someone say in a former engagement “Computing would be ok if it wasn’t for the humans”.  The point this person was trying to make (in a very round-about way) is that regardless of how dynamic your processes, systems or staff are – the value of any reports produced will always have a half-life (i.e. their worth to the organisation is in indirect proportion to change-state of your IT environment).  Another way of looking at this is: “ Software Asset Management is a project, the rest is change management”.  Having embedded one or several software suites to manage your IT estate, and deriving quality reports – you then have to ensure that those reports generate activity, so that any “deltas” detected (differences between the current report, and the former edition) are acted upon or acknowledged as the new steady state.

IT operations can go so far in tracking down unauthorised installs of software (as an example) but I would place money on the fact that decisions made at much higher levels than IT operations will have a direct bearing on what is reported; and what the IT department is expected to do about it.  Let’s consider mergers and acquisitions – does the IT department get any prior notification that their area of concern is about to expand (or contract) by x,000 number of seats (and associated servers)?  What of new projects that spring up that are deemed sacrosanct from the top, and afforded resource and scope that circumvents the very Software Asset Management system you have created?

Wherever possible, try not to get sucked into the Software Asset Management suite console thinking it is your telescope on the wider business – Remember in my previous article I talked about communication being a two-way street? Ensure your business is telling you what’s going on so that you can attempt to remain ahead of the curve if any of the following might change:

Business Requirements

New projects, M&A activity, new departments or organisational restructuring are but a handful of changes in business that could alter your scope or circumvent it altogether; yet the business might well expect the Software Asset Management system to magically adapt to such changes because IT “is where the magic happens” (I have heard this phrase used to describe IT on more than one occasion).

Changes to Licensing terms and conditions

This is a real hot potato within Software Asset Management, not least because the quality of information that gets produced by software vendors on such changes can be so incredibly variable.

Changes to Software Asset Management scope

You might have demonstrated excellence in dealing with one particular vendor, or an office, or a country – but then the business might come back to you and ask for the scope to be widened.

Changes in Personnel

It could be that the very people who you have trained up to run your Software Asset Management system then decide they wish to work elsewhere, and leave the company.

Changes in Reporting Requirements

As a result of the reports your Software Asset Management system provides, could instigate a change in strategic thinking, and therefore result in a change to the reports being asked of you.  Take this as the back-handed compliment that it is; it is a maturing of the business the Software Asset Management system has driven.

System Performance

It might be that the software system chosen needs to re-scale or adapt to greater data sources, or could do with improved hardware resources dedicating to it.

Process Performance

Hopefully you will have built metrics/measurements into your processes that will give you some indication of their success in under-pining the Software Asset Management system; but these too, should be placed under review to ensure they still meet the needs of the business.

The better Software Asset Management practitioners I have met realise that staying ahead of the curve is the best approach in trying to maintain the status quo, and so continuous review should never be far away from a Software Asset Management Manager’s thoughts.

Image Credit

1 thought on “Continuous Improvement and Software Asset Management”

  1. Good points here.

    I have found that where there are monthly checks on what is actually deployed against what was expected (usually from either a Change Management System or CMDB) and the exceptions published to senior management you get the best control.

    When a difference has to be explained to management you’ll find the system is quickly corrected.

Leave a Comment

Your email address will not be published. Required fields are marked *