During the course of the past few of years, the deployment of patches and anti-virus signature files have challenged and humbled organizations with large distributed PC populations. Tools such as Windows Software Update Server (WSUS) and SMS, combined with strict organizational processes and policies, have resulted in most IT organizations being able to prevent or minimize large-scale virus outbreaks.
However in desktop management there are always new challenges.
In my opinion Software Licensing Management is at the top of the heap, unfortunately some organizations tend to put a low priority on this and deploy their resources on development and operational projects.
IT departments who fall into this category should revisit their priorities as Software Licensing Compliance is indeed coming to the forefront at a rapid pace. Why? Because software sales are flat and as a result software manufacturers are jumping on the compliance bandwagon in order to stimulate sales and increase revenue.
The first step any IT department should take is to recognize that they have a problem. If your department does not have a solid software management policy and process in place that is adhered to - along with a solid set of metrics - then you indeed have a problem. I have to emphasize a software management policy and process because one may tend to get complacent when the "techies" tell you that you have nothing to worry about since you have systems such as SMS, Tivoli, and Argus in place.
Don't be led down this primrose path as tools do not manage your software, tools will only help you acquire and manipulate the data. Solid enforcement of software polices, procedures and processes is the management part of this undertaking and will keep the auditors off your back.
Another benefit is costs reduction because I submit to you that you are probably licensed for more product than what you use. However, you have no way to prove it because in all probability you do not have a rigorous software management process in place.
Let's discuss implementing a policy and process. First and foremost, the Policy must come from the head shed and legal department and be a part of the Corporate Code of Ethics. This will ensure that all department heads and employees have both an incentive and obligation to comply with the policy.
Any policy should mandate that ALL software procurements be accomplished by the corporate purchasing department, as this will make the task of creating and maintaining a system of record for software licenses purchased.
Now that you have a policy in place that has been endorsed by the corporate executives you must document processes that will make it simple for both the user community, purchasing department, and IT staff to acquire or re-assign software in accordance with the policy and to enable the IT department to manage the license. At the same time a Software License Inventory Management Process (SLIM) must be developed.
The SLIM process should determine what type of licenses are used within the company and then define the rules about how these licenses are counted. These rules will vary depending on the software and terms and conditions of the software license agreement for each software type. It is extremely important that the software license agreement be fully understood in regard to license count and then documented in the appropriate system of record.
Once you have determined and documented the software license types and how the software is to be counted, you must determine what methodology and tools you will use for discovery.
Obviously in a large distributed environment, automated tool sets are essential and there are many on the market place such as SMS, TNG, and Tivoli. The tool set you choose should be based on your processes, ordering systems, and financial systems and NOT the sales pitch from the vendor. Remember the tool is not the end-all solution, your SLIM process is the solution and the tool will enable it.
Now that you have a process and discovery tool in place, you must determine what the central data repository will be. Data from the purchasing system should populate fields in the central repository you defined in the SLIM process. This may require a significant amount of manual entry depending on what level of automation your past and current software purchasing system used. It is essential that any entry in this system of record can be substantiated by a purchase order and or payment receipt for the software.
The next step is to execute the discovery process and generate an inventory report that can be reconciled to the data in the central repository. The results of this report will give you an idea of where you are over or under-licensed.In the event of under-licensing, the IT department and business unit should determine whether or not the licenses are really required and being used, and if appropriate, uninstall the software immediately. If the licenses are being used and there are not enough license agreements to cover the software, a purchase order should be generated immediately to cover the short fall.
The intent of this article is to create awareness, as I would have to write a book to provide you with a step-by-step framework to establish your policies, procedures, and a software licensing inventory management system.
What I can tell you, is this will be labor intensive upfront, however, if you will make this a priority and take a cradle-to-grave approach to software license management, compliance will not be an issue in the future.
Did I say compliance? Shame on me! Software licensing is all about management and not compliance, if you get my drift.