Case Study: Audits for Software – Inspiration from Last Year’s IAITAM Conference

By Mary Barr, ERCOT

Don’t you love the feeling you get when you attend a presentation and find out you’re not alone in what your instincts are telling you? That someone else out there in the wide world of asset management has considered the same things, created some order out of those scattered thoughts and ideas, and stood up to present them?

And don’t you love when those presentations give you food for thought, and have you “chomping at the bit” to get home and try out new ideas? That’s what happened to me at the 2010 IAITAM conference, when I attended a presentation by Mr. Krzysztof Baczkiewicz and Mr. Terry Divelbliss from Eracent, called “Focus! The Art of Choosing Goals for an Internal Software Audit.”

They presented several different types of audits, what the primary and secondary emphasis of each was, and what to consider out of scope. Listening to the presentation I realized I’d already implemented several of them and that I now had a name for the work I was doing.

Compliance Audit

The first goal was to make sure software was compliant and stayed that way. I gathered proof of purchase history for software most requested by the community, as well as the publishers being mentioned in the Gartner conference surveys on auditing trends.

This proof was matched up with installations and the results evaluated. Processes were then set up to re-visit the software inventory on a regular basis and make corrections when needed.

Harvesting Audit

Once the audit for compliance was underway, I looked for other layers of efficiency. The next important, and easiest to implement, was to harvest unused installations. For software nearing or out of compliance, I started emailing the managers a list of installations in their departments to find out which were not being used. I’m fortunate! My company is small enough in headcount and only in two locations.

Business Alignment Audit

Next, I started educating managers on software that did the same thing and what the differences were between editions, so that the right software could be aligned with the work their people were doing. The emphasis was to move towards freeware, open-source, and less expensive editions than what had been installed initially.

Standardization Audit

About the same time, I also implemented ‘standardization.’ With the help of the new supervisor of our workstation management team, his team’s software packaging and archives process were cleaned up. A version was identified to standardize the company on and a plan for implementing the change in an orderly manner developed. The plan included moving everyone to that version with the appropriate licenses in place. The process was repeated for each of our widely used software.

Authorized Use Audit

I created a process to review new software and to document which departments were authorized to have the software installed. Subsequent requests for the software were checked against the results. This audit focused on the new software and is missing the comparison of existing installs to the review results to identify unauthorized installs. Also missing is the implementation of controls that shut down installs and use of unauthorized software. I hope to implement this type of audit next.

Open-Source Authoring Audit

This audit is one I’ve thought of and determined I don’t need for now. It is the review of open-source code to make sure the appropriate authors are being given credit for their work.

Use Audit

This type of audit compares the software installed to software that is being used. The most common use of this audit is during the renewal of services and identifying:

  • Software that is no longer in use
  • Services no longer being used or with levels of support that don’t align with business needs

The audit includes examining future needs for software such as development forecasts related to the software. I have not formalized this audit in my processes as yet.

Cross Departmental Audit

These audits involve providing information to other areas in the company to support their work. Here are a few examples of departments with whom a Software Asset Management program interacts, along with my notes on my program:

  • Financial/Accounting: My company doesn’t have a charge-back process so these audit types have not been areas of importance to-date. With further exploration, it’s possible I could generate a new service to other departments I’ve not worked with before.
  • CMDB: My company does use a CMDB but exclusively for our server environment; all of my audits are used in the workstation environment.
  • Security: My company has a ‘cyber’ security team and they do review software, but both parties are interested in what the other is doing so there are opportunities for development of this audit type.

Attending the presentation on the use of audits helped me gain perspective on the processes and organization in the existing Software Asset Management that I had already done. Using the audit approach allows me to not only confirm how well processes that are in place are working but also to help evaluate potential improvements to the program.

About the Author

Mary has moved in the IT world her entire career with the last 12 devoted to software asset management, in the energy and software publishing industries. Although duties have changed with time in these 12 years they all gravitate to educating internal and external customers on what SAM is, what the impact to their work is, and is always about how to make their work move smoother and with less risk.