Software – Why does it always have to be Software? – Moving from Out of Control to Ready for Anything

By Bruce P. McDowell, McDowell Consulting LLC

ITAK V8 I8

Your average user has one desk, a desk chair, a file cabinet, trash can, the walls and cubbies of their cubicle – not much else for physical assets. IT provisions the user with a desktop or a laptop, monitor, keyboard, mouse – that’s about it for hardware. But inside that computer is software – lots of software. Dozens of applications and utilities. Your job: manage the mess. Know what you have, who’s using what, buy smart, never miss a renewal deadline. Unless you’re in a pretty large company, you’re doing it all by yourself. Best of luck!

Seriously, though, there’s a lot you can do to make your software management life a lot easier and organized. We’ll start at the bottom and work our way up.

Inventory – Your Foundation

It’s a given for software asset management that you have to know what you need to manage before you can manage it, so selecting and implementing an inventory tool is a critical first step. There are dozens of tools available from which you may choose, but here are some key factors to consider when making a choice:

Does the tool recognize the software you need to manage? When you test a tool in your environment, check to make sure the software titles you need to manage show up in the reports. Further, make sure the level of detail meets your needs.

Is software recognition setup out-of-the box, or does the tool need to be taught what it needs to know? Some inventory tools require a substantial investment in up-front consulting to configure the recognition. Others recognize tens of thousands of applications right from the get-go.

Is the recognition tool updated regularly? This is particularly important if the tool utilized a proprietary application signature database to provide software recognition. At the very least that database should be updated monthly with new software recognition signatures.

Is the tool manufacturer receptive to suggestions for application recognition to be added? If you have an application to manage and your tool doesn’t recognize it, the tool vendor should at least listen to your needs for added recognition. Don’t expect the vendor to fingerprint everything – that little utility that only your very small industry relies on, for example. On the other hand, expect the vendor to be embarrassed if they don’t recognize the latest version of Microsoft Office on day one.

If the vendor won’t add all the recognition you request, can you add your own? If you have sufficiently powerful tools available to add your own fingerprints – either for that niche utility or for software you’ve written in-house – then you can fill the recognition gaps on your own.

If you read between the lines of the bullets above you’ll see that, even though you’re deploying a tool to provide accurate counts of your installed applications, it’s very important that you have a clear handle on the titles that should be discovered. If a tool isn’t picking up something, only you can identify the deficiency and take action to close the hole.

(For lots more information on selecting an inventory tool, see “Inventory in a Complex World” by Bruce McDowell in ITAK volume 8, issue 4.)

What’s Licensed and What Isn’t?

OK, we’ve got a great inventory. What’s next? Well, a lot – and I mean a LOT – of that software probably doesn’t have to be subjected to rigorous license management. The next step is to weed out the titles that you don’t need to manage so that you can focus on the priorities.

A while ago I worked with a customer whose internal auditor understood that there was software whose licensing was not relevant, but she just needed to understand why each title was set aside. So my best practice process for understanding the software environment took on an extra dimension. As I divided the applications, on one side was software that was purchased and for which I needed to manage the licenses. On the other side were inventoried products that either clearly weren’t licensed, or that came bundled with a licensed product but that they didn’t need to worry about.

As an example, let’s take Adobe CS Design Premium. There are a number of components of the CS suite that are licensed software – Acrobat, Photoshop, and Illustrator to name several. You can also buy each of them separately. Bundled with the suite are a few items that you can’t buy separately – Bridge and Extension Manager are examples. Are they part of a licensed application? Yes. Did you license them separately? Not really – it’s bundled with the other parts of the suite. So I find a way in the asset management tool to label those products as being bundled with Adobe CS suites.

Over time, I’ve developed a list of over two dozen categories of software that can be excluded from license calculations. Most involve items that are bundled with other products – bundled with an operating system, with hardware devices, with various other applications as with the Adobe CS example. Then I have a set for free software, including freeware and open source. Some of the categories are pretty esoteric and nearly specific to a single customer. But as I move from customer to customer, I find the same titles over and over, validating my process.

I maintain a list of about 700 titles that I can exclude quickly. (See http://www.consultbruce.com/best-practices.html for the list; it includes my list of categories.) Then I move on to evaluating the other titles in the local inventory. This is simple a process of research, with lots of Google searches. Here I’m looking for things that quickly flag a product as commercial – a big “Buy Now” button is a strong clue. If I can’t find something obvious, I have to start looking at license agreements and checking the fine print. Also be on the lookout for products that are free if you use them at home, but must be purchased if used commercially – they manage to creep into just about every customer environment I’ve visited. As you’re doing these searches, save the pertinent URLs to document your findings – eventually you’ll need to refer to them later.

Finally, build a report that shows all the software that you won’t manage, broken down by your categories. This can be handy for both internal and external auditors.

Get your Priorities Straight

At this point, you’ve narrowed your list of software titles down to just those of interest for license management. You may be surprised at the proportion of titles that have fallen by the wayside; I’ve eliminated over 75% of inventoried titles in some projects. The number you have now should at least seem a little bit saner!

Now it’s time to figure out what to do next. Every customer I’ve worked with has some priorities to think about. It could be a pending audit, or a software manufacturer who has sent auditors in the past. It could be a set of products on which the company has spent the most money, or an application that is mission critical. Or you might look at software usage data and find those applications that are most used. Whatever your priorities, get organized and get started.

Purchasing Data and Product Use Rights

With the inventory and priorities under control, the only thing left to be pulled together is purchasing data. Well, that and understanding what you’re actually entitled to by your purchases.

Your software reseller may be your best friend for developing accurate purchasing data. Many now have customizable reporting available so that you can pull electronic data ready to be imported into your software asset management tool. And your reseller won’t drop a dime on you if you find out you’re under-licensed – they’ll just sell you more software. Software manufacturers, on the other hand, just love it when you ask THEM if you have bought enough software for what you have installed. Your audit letter will be in the mail before you hang up the phone.

As you pull together the purchasing data, pay close attention to what each record means. Does it represent new licenses added? Is it an upgrade from a particular version to another, or a multi-version upgrade? Are they licenses for individual named machines or individual named users? Is the software covered by a perpetual license, or is it term limited with specific start and ends dates governing usage? The answers to these questions lead directly to the types of entitlements that will ultimately be used to reconcile purchase data to installed data.

This is also the time to be on the lookout for information that can be fed into a contract management system. Maintenance agreements should be entered with their renewal information so that reminders can be sent in advance. Then, once the reminder is received, you have time to analyze current software usage data to determine if everything you have installed is being used, or if not, cost savings may be possible by reducing the number of supported installations.

It’s a Process, NOT a Project!

So you think you’re done. You’ve reconciled all the purchasing and inventory data you have at hand and you have a good handle on your compliance position. Well, unless you work in a static environment where users are never added or removed and no software is purchased new or upgraded, then you’ll always have maintenance work to perform.

I look for processes that I can review on a periodic basis – perhaps monthly. Here are some best practices I follow:

Inventory data is something of a continuum; if I have scans running once a week, then I have the potential for change in the inventory every week. If new products appear, I either match them to existing licensed products, or create new reconciliation to manage them. I may also have to exclude some and update my exclusion report.

Download and import purchasing data from your software reseller monthly. Reconcile this data into your existing licensing or to new reconciliations created due to change in inventory. Then your compliance reporting will always reflect your current situation and indicate any actions you need to take.

Monitor high-level software usage regularly. Make a habit of watching for applications that are being used lightly, at the very least so that if a user requests a license, you know quickly whether you should be planning to buy a new license or reallocate an existing, under-utilized license.

Resources and Management

Recently during a presentation I was asked a question about how many employees (FTEs) should be required to manage software for a company. I’ve tried to think about this against the various customers with whom I’ve worked, but I’m not going to be able to give you a hard and fast metric.

Take as an example a current customer with a little over 60,000 devices in the inventory. They have a team of two who maintain the configuration management application – and are therefore responsible for delivering the inventory data – as well as another team that builds application packages for distribution. Though critical to software asset management, those teams don’t count directly into SAM headcount as they would be doing their tasks purely to provision software to end users. They have a team responsible for purchasing software, and they will be responsive to requests from a software asset manager, but they don’t manage the software. In the middle of all of these little teams sits one guy – he’s the one responsible for reconciling the two sets of data and keeping it clean. He downloads the data from the reseller and imports it into the SAM tool. He looks at the reports to see when the company is under- or over-installed. He analyzes usage for reallocation potential. He’s busy – and really well organized – but he manages to keep his head above water.

Is that scenario rational? Well, it works for that customer. Another customer with a somewhat higher device count has a team of three, plus a manager, plus a guy who manages the application without performing any asset management tasks. So you could say that’s four people doing the job of one guy in the first example, though they have about 30% more devices. Naturally everyone is availing themselves of as much automation as their tools offer, but I go in assuming that will be minimal.

I don’t think there’s one right-for-every-situation plan. It’s pretty clear that in the early stages – getting organized, establishing baselines for inventory and purchasing data, building out the initial picture of your compliance – there can be a lot of work, even in smaller environments. Some temporary headcount, internal or external, to jumpstart the process will be useful.

Once you begin to come close to maintenance mode, the amount of work to be done on a recurring basis is dependent upon how many software transactions take place over an average month, how many major manufacturers need to be dealt with, and how many resellers are generating purchasing data to be imported. If these factors are relatively low, the headcount can be low. The more complexity and transactional volume, the more bodies you’ll need.

One thing that can help lower the personnel count is some management “influence” to streamline the way things work. If you can settle on one reseller, you only have one type of data to import, which should simplify your reconciliation tasks. If end users are disallowed from buying and installing their own software, then you’ll always have consolidated purchasing data and many fewer surprises when the inventory data gets updated. Consider injecting some financial incentives and to make end-users happy to play your way, and disincentives to keep them from straying.

Summary

I once had an executive at a Fortune 50 company listen to a description of the work necessary to capture a good inventory, organize software purchasing data and then reconcile the two data sets into a compliance position. At the end of my presentation, she cleared the papers from in front of her, leaned down, and gently banged her forehead on the table several times. She was nearly in despair over the task ahead. It need not be that way! You need to be organized, and you need to be persistent. But with those qualities and the right tools, you’re in great shape to succeed!

About McDowell Consulting LLC AP

In 1990, Bruce was a founder of Tally Systems, helping to bring the first hardware / software inventory tool to market and later working with the professional services group, managing on-site inventories for Fortune 1000 companies and product implementations. After Novell acquired Tally Systems in 2005, Bruce worked in a number of roles including Product Management for the inventory, recognition and asset management components of ZENworks. Since 2009, Bruce has been an independent consultant working on configuration and asset management projects mainly based around Novell’s ZENworks product line. He has also developed and presents several courses for Novell Training.