What do people mean when they refer to a ‘SKU Catalogue’ for license management?
In this article I hope to demonstrate why organizations utilise SKU catalogues, the difference between SKU catalogues and software recognition and the business value to SAM practitioners.
Browse any supermarket around the world and you are likely to find a section of the store dedicated to Coca-Cola and its fizzy drink competitors. Coca-Cola is produced in a myriad of flavours (Diet, regular, cherry, zero…) and a variety of sizes (cans, big bottles, little bottles, value packs…) suited to customer requirements. Each of these Coke variants has a SKU or Stock Keeping Unit assigned to it.
Stock Keeping Units allow the supermarket to manage their inventory and manage millions of different product lines. If the store is running low on Cherry Cola cans it has a unique identifier to isolate that product and manage fulfilment throughout the supply chain. The supermarket can order the SKU, the SKU is quoted on the purchase order, and the SKU is quoted on the invoice, printed on the box and so on. Without some form of unique identifier managing inventory at the supermarket would be a logistical nightmare.
Note: A SKU is different from a barcode. A barcode is used to electronically identify a product using an optical machine reader. Barcodes may contain SKU numbers and other data.
The vast majority software publishers also use a SKU to identify product variants.
If we were to go shopping online for Symantec Backup Exec we might stumble across SKU number ‘MLDZWZC1-EI1AS’ (Referred to in this instance as the manufacturers part number by CDW in image below).
It is important to note that MLDZWZC1-EI1AS refers to a very specific way of purchasing Symantec Backup Exec.
These elements are known as product use rights (sometimes abbreviated to PUR). Some product use rights are made explicit by the manufacturer (this is for one CPU server with up to 6 cores), some product use rights are not made clear on purchase (can I use Backup Exec on VMware with VMotion enabled?). Worse still, some product use rights change on a monthly basis on the whims of the manufacturer.
As you can see the SKU has unique licensing characteristics associated with it. The license would be absolutely worthless if aligned to a French version of Backup Exec installed on a 2CPU server in a non-academic company.
Note: Good practice (and good business) from suppliers is to include the manufacturer’s part number for unique identification as well as the suppliers part number for easy re-ordering on all documentation and invoices (in this instance CDW 2616143). SKU numbers are also usually included in your software vendor license statements and online portals.
Hopefully you can see the business value of a unique identifier in managing an accurate inventory – but how does this apply to license management?
If your procurement process is tracking manufacturer part numbers for your software purchases you are, theoretically at least, already in a strong position in determining what software you are entitled to. We just need to marry up your procurement history with what is in use and installed within your environment. Unfortunately it is easier said than done.
Common sense would say that, just like the supermarket, every product in the shop should have a bar code on it so everyone knows how to identify it. In an ideal world we would whizz around your network with a software bar code reader and tally up all of your installs.
Unfortunately, although software manufacturers use SKUs internally, on their packaging and within their supply chain it is commonly missing from the actual install.
The ISO standard for SAM is doing work to rectify this, by developing an XML software tag which installs alongside every software installation storing the SKU and other meta data in a universally recognised format like a barcode (See Steve Klos over at TagVault for more information on ISO/IEC 19770-2). Although the Standard is making good progress, including Microsoft adding tags to Windows 8, we are a few years away from widespread adoption.
Software recognition is not the same as a SKU Catalogue. A SKU Catalogue typically includes software recognition and normalisation.
Software recognition is the process of recognising and normalising technical configuration management technical jargon into recognisable product names and product families. SKU catalogues also perform software recognition but strengthen the license management process by also normalising procurement data and linking it with installed software data to ensure software is being used in accordance with the product use rights.
When you attempt to marry the worlds of technical configuration management and procurement the challenge is to find a common denominator between the two sets of data – the SKU is that unique identifier. Installed software has technical characteristics that can be aligned to a SKU and in turn the SKU can be married to the correct procurement record. The SKU catalogue is the lookup table, the meta data and the intelligence behind this process.
So how does all of this help with license management accuracy?
The SKU catalogue provides a mechanism for filtering, double-checking and maintaining accuracy in SAM processes.
It forces good practice and accuracy – e.g. it is not possible for a Microsoft Select based SKU installed on your network to be aligned to a Microsoft Enterprise Agreement contract in your procurement system. The incompatibility prevents mistakes and ensures organizations are licensed correctly. The SKU catalogue is the lynchpin and translator between the different complex languages of configuration management, product terminology and procurement.
The main business benefits of using a SKU catalogue are:
If you have any questions or can share experiences of using SKU catalogues please leave a comment below. Thanks, Martin