SKUs and Serial Numbers

SKUs and Serial Numbers

Except in the very smallest of companies, products shipped to customers must be identified for a variety of purposes, including inventory tracking and sales reporting. Most companies rely on SKUs to manage these functions in the various corporate systems that help them perform. Software sold in high volumes may also be serialized for unique identification, tracking, and some limited copy protection.

SKU Management

The changing nature of releases and variations, and their potentially long and descriptive names , puts a great deal of pressure on other corporate systems that must account for sales, shipments, upgrades, or other customer activities. The easiest way to manage this is to establish SKUs (stock keeping units). These are unique release identifiers that enable one release to be distinguished from all others within corporate tracking systems. As an identifier, a SKU is independent of the various textual descriptions of releases that I've described in previous sections.

SKUs are used in a variety of circumstances. One example is orders for specific releases. Another is prices, which are not part of the release identifier or product name and must be obtained from a pricing database or system; the primary key to find the price is the SKU. Inventory levels for physical goods are also usually managed through SKUs. Inventory for electronic software distribution doesn't make sense, but since chances are good that you'll do some physical and electronic distribution, SKUs have a place in your inventory management system.

Teams often struggle with when to assign a SKU to a release. SKUs introduce many additional tasks into the overall release process, so it is understandable that marketects avoid them unless absolutely necessary. The following guidelines have worked well for me.

  • Always assign a SKU to any release that can be sold, regardless of its scope (patch, partial, or full) and target (controlled or general).

  • Try to assign a SKU to any general release (a release targeted to all customers), regardless of scope (patch, partial, or full). This makes for convenient tracking of what is globally available.

  • Always assign a SKU to any release if your primary customer-tracking and distribution systems are keyed to SKUs and you can track who gets the release. This allows you to know who has what release.

  • Avoid SKUs for releases simply posted on self-service Web sites, such as technical support or free-download sites. You're not selling these, so there is no need to create SKUs in your financial systems, and you're not keeping track of who gets them (although perhaps you should).

Of course, these recommendations should be followed only if they fit with corporate policy. If your company mandates that all releases, no matter what, have SKUs, then by all means, create them.

You can't mandate the format of a SKU, because it is usually under the control of corporate IT, fulfillment, accounting, and the like. You can, however, tell these groups how many SKUs you need and work with them on a format that will enable you to accomplish your objectives.

Returning to our example, SuperDraw is one of four product lines at SuperSoft. Other parts of the company, such as accounting and order fulfillment, don't care about the product names or version identifiers. Accounting just wants to track sales results by product line and division, while order fulfillment just wants to make certain that the right deliverable is shipped to the customer. What they care about is the SKU, which is their way of tracking these products. For various reporting reasons, accounting has defined a SKU format NNNN-MMMM-#, where NNNN is a four-character division identifier, MMMM is a four-character product identifier, and # is a unique product number of arbitrary lengthand has defined the division identifiers. Together product management and accounting have defined the product identifiers; product management alone is responsible for assigning unique product numbers. Product management might define the SKUs as shown in Table 15-3.

Table 15-3 contains three key logical components : the SKU, the external name, and the fully qualified release identifier. The last component should be extended as needed by product management to ensure that all aspects of the product are properly managed. For example, you may want to include the location of the build in your internal network (e.g., \\buildmaster\SuperDraw\4\5\1{build} if you're building every day).

Table 15-3. Example: Assigning SKUs to Products


External Name

Internal Identification


SuperDraw 4.5, German Language for Linux

SuperDraw, German Language for Linux


SuperDraw 4.5, Russian Language for Linux

SuperDraw, Russian Language for Linux


SuperDraw 4.5, English Language for Linux

SuperDraw, English Language for Linux

Backend systems often need an estimate of how many SKUs you might need. The number of SKUs associated with a product can be estimated by adding the following:

  • The number of full releases multiplied by the number of full release variations (remember to count each kind of variation, such as language, operating system, or platform, separately). For example, if SuperDraw 4.5 runs on 3 operating systems and supports five languages, this produces 1*3*5 = 15 SKUs for each release. You may have to adjust these numbers as releases often add or subtract variations or variation classes).

  • The number of partial releases intended to receive a SKU multipled by the number of partial release variations.

  • The number of optional components multiplied by the number of optional component variations.

  • Any other SKUs that are generated for other reasons.

As you can see, SKUs can quickly grow to hundreds or thousands of identifiersplan accordingly .

Serial Numbers, Registration, and Activation

A SKU is an identification code that allows a class of products to be tracked for inventory purposes. It can't identify an individual product sold to an individual customer. For that you need a serial number, a unique identifier that does distinguish individual products. Registration is how a customer, who has purchased the unique product, makes themselves known to the vendor who sold it, with the serial number acting as a key that binds the customer to the company. Software activation is a kind of forced registration in which various product features, and possibly even the entire product, are inaccessible until the customer completes an approved registration process. Software activation is closely related to license enforcement (see Chapter 4) as one of the goals of software activation is to ensure that only properly licensed software is allowed to function.

In the physical world, serial numbers range from the lot numbers and associated codes printed on vitamin bottles to the identification tag affixed to my PDA. As a digital good, software cannot easily be identified with a unique serial number. Unlike physical goods, digital goods are often trivially copied , and embedding a serial number within the object code at production often represents an expensive change to internal processes. Moreover, unless you've adopted one of the license enforcement schemes described in Chapter 4 to prevent copying or modification of your software, serial numbers can be easily changed.

Although serial numbers can be a bother, there are real benefits to using them. By associating a serial number with a product and asking the user to register it with your company, you can collect vital demographic statistics and tailor your marketing campaigns . Consider that once your customers have registered their serial number you can use it to notify them of product upgrades, bug fixes, and product and service offers. Registered customers may be willing to provide you with additional valuable information, including their preferences for new features or their willingness to participate in beta programs.

Properly registered serial numbers can help reduce piracy. In the past, when serial numbers were printed on CD sleeves, the sheer size of programs and the difficulty in duplicating CDs were deterrents to piracy, but technological advancements have made such deterrents ineffective , and software developers are continually looking for new ones.

Software activation is effective at deterring piracy while increasing the number of users that register their software. Activation processes vary according to need or by software activation vendor. Generally they work something like this.

  1. The software publisher prepares the software for distribution. A serial number may be assigned at this time, although serial numbers can be generated dynamically instead. The software is protected in some way to prevent execution until it has been given the proper activation code.

  2. The customer purchasing the software, a consumer or an enterprise, installs the software, binding it to the machine. The binding process takes a unique " fingerprint " of the machine, such as the processor ID, motherboard serial number, or MAC address of the primary Ethernet card. This information is usually stored in a secure location to help prevent illegal copying of the software.

  3. To use the software, the purchaser contacts the publisher with the serial number or the machine fingerprint, or some combination of the two, and requests an activation code. This process may also force the entity to register with the publisher. The publisher should provide several channels for acquiring the activation code, such as the Internet, e-mail, phone, and fax. During this process, data from the target machine are stored in various corporate databases and the software associated with that serial number is marked as activated. Registering the serial number ensures that it is uniquely identifying a product, while storing the machine fingerprint and binding the software to the machine helps prevent piracy.

  4. The activation code is given to the software and stored in a secure location. Depending on the technology that was chosen , it or the license allows the software to be used but only on the designated machine.

Adopting a software activation process is a strategic decision. Most companies don't have the resources to create effective activation systems, but several vendors provide them. Offerings must be evaluated relative to existing and planned backend systems and workflows. Managing the backend systems is likely to be a much bigger job than choosing a software activation vendor.

Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
ISBN: 201775948
Year: 2005
Pages: 202 © 2008-2017.
If you may any questions please contact us: