Software asset management (SAM) doesn’t have to be a daunting process. It can be very simple and rewarding if implemented properly. Here are six necessary steps to a successful SAM program (tongue twister eh?):

1.     Know and understand your SLAs for all your software vendors (not all licensing agreements are created  equal), the terms and conditions, and if you have questions, ask your rep or a consultant to explain them to you. Now this seems basic and it should be, but I would be remiss not to mention it here as the first step.

2.     Take an inventory of all of your IT assets - software and hardware. With Oracle entering the hardware business, companies need to be aware that this may be of significance to future ITAM. Keep track of what is currently in use, who has access to it and where it is being used. Is it being access remotely? How many employees are using it at the same time? While this sounds simple enough, take step 2 and tie it back into step 1.

3.    Compare and Contrast your inventory to the most up-to-date software purchasing records to determine whether or not you have assets that are out of compliance. This should also be checked against employee usage - perhaps more than one employee is using the same licensing which does not comply with your SLA on that program.

4.     Fix the problems  once you know what the problem is, uninstall software that is not compliant,  buy additional licenses and re-negotiate your contract(s). You must plan for the needs of the business over the next 12-18 months to determine whether or not additional licenses will be needed in the near term.

5.     Further planning is needed now that you have a clean slate and have fixed compliance issues. Now is the time to implement a plan for the future, which may include developing a repository for assets, purchasing SAM software with an automated discovery tool, or bringing in outside help. It is always a good idea to assign a group of internal managers to oversee the process and of course, get buy-in from the management team (which can be done by showcasing cost savings associated with a proper SAM program). You will also need to develop and market a new set of policies and procedures across your organization that will keep employees from misusing licenses.

6.    Keep it up! After a plan is in place; policies and procedures have been created and communicated; and licensing is up to date, the last step is maintaining the SAM program. Remember to:

We are always talking about software asset management (SAM) as a means to cut costs and also keep up with compliance. For financial firms, SAM, combined with a Governance, Risk and Compliance (GRC) program are a necessity to keep those regulators happy. Many firms choose to use GRC software to automate the process should they get audited (which the frequently do) to have information at the ready. Here are some tips for those that are in need of a GRC program to track data and remain in compliance:

Some processors have a dual core, single chip that appears to be two CPUs within the Oracle kernel (the Oracle kernel determines the number of CPUs on a system during start-up). This is the case with Intel Hyper-threading, where the number of physical CPUs doubles when running on Linux or Windows with a hyper-threading setting of OS or BIOS.

Oracle will charge a CPU license fee for the extra cores in multiple core CPUs. Therefore, you will need to license for each CPU core in multiple core CPUs, meaning that a hyper-threading CPU is considered a single CPU for licensing, but a dual core CPU is considered 2 CPUs for licensing.

However, when Oracle audits/asks the OS how many CPUs are in the system, the OS just reports the total number of logical CPUs. In the case of Intel Hyper-threading, if the one core looks like two processors, then it is counted as two; therefore, two separate licenses are needed.

A number of years ago, Oracle introduced its Embedded Software License (ESL) model - available to Independent Software Vendors (ISVs). Once in a while, we get an extremely nervous ISV who didn’t understand the licensing restrictions on ESL …..

The ESL is a highly restrictive license that allows ISVs to embed Oracle technology into their products. The end-user would not necessarily know that they are using an Oracle-powered product.  Examples of possible systems using this licensing model include point of sales systems, kiosks, online commerce or an electronic library. It can be any system that requires a database to capture or become a repository for information or transactions.

The one item to note in the ESL model is the party responsible for Oracle software licensing agreement (SLA) - the ISV. Therefore, if you happen to be using the ESL within a market or markets, be cognizant of the usage, users and any alterations to the program that might affect your Oracle licensing.

Hmmm, an online self-service resource - Microsoft License Advisor for Volume Licensing - can be used to figure out what licensing needs your company has.  This is a great initial start to understanding licensing needs.  It’s also a great marketing tool for online self-service resource.

Only issue is that it doesn’t give you insight into how you AREN’T compliant. Devil is in the detail!

Ignore the too-chipper voiceover. It gets on your nerves after the first 30 seconds.

Software vendors have different licensing rules. With Oracle, you have to understand that you’re licensing per processor (CPU) for running the Oracle software, versus per user. There are various scenarios and factors that change the licensing and pricing. For example, multi-core processors are counted by number of cores, and processors have a different multiple.

Note: There are many variables that may change the core processor count or formula. But, in general, the above count is a good baseline.

I wouldn’t have said it better myself….

Yesterday’s Open Q&A Forum on Oracle licensing, audit and procurement was very much a success. Chris Kanaracus (@chriskanaracus) did a great condensed summary on one of the points being made – what’s happening during Oracle discussions. 

Read the entire article from ComputerWorld: Consultant: Oracle Holding Firm on License Discounts

Many of our clients think that once a Service Level Agreement (SLA) is signed and agreed upon, it’s untouchable until the end of the term. This is not the case in most circumstances. In fact, a good SLA should be changed periodically. Particularly, in the case of penalties and rewards built into the SLA, where there is often a need for change. Let’s say, for example, the software vendor is repeatedly missing deadlines and it has become detrimental to your business. Re-negotiating the SLA and increasing the penalties is a motivation tool to get that vendor to meet your deadlines. Otherwise, you’ll have to find another vendor that can do the job. This is the same should the rewards be paying out very well to the vendor - if the goals are being met so easily, perhaps a higher goal should be set to raise the bar?

SLAs are a tool, to be used by the purchaser and by the vendor, to insure quality service is provided over the life of the contract. Just because its signed, sealed and delivered, does NOT mean there is no room for re-negotiation.

One of the best uses of a Service Level Agreement (SLA) in our eyes is its use as a way of setting goals for the vendor. When implemented successfully, an SLA can be a means to manage risk, and create accountability on both the part of the vendor and your own obligation to the technology investment.  We have seen many SLAs with built in penalties for vendors for non-performance, and/or missed deadlines. This can certainly work in your favor in two ways- cost savings and motivation for the vendor to get the project done on time and in good form.

The reality is, that the goal set forth by the SLA is a shared goal. If the terms are not met, everyone loses. Therefore, it’s equally as important as the vendor’s participation, for you to be actively involved in the goals of the project in order to be successful.