Entitlement and Compliance Management

Are You Being SKU-ered to Death?

by: Cris Wendt

One of the most prevalent problems in high tech companies is the virtually unmanaged growth of part numbers or orderables in a company’s price book.   Don’t get me wrong, producing new technology and new products to capture new customers or new markets is the life blood of most technology companies.   However, what we tend to see are many downstream problems associated with too many orderable items in a company’s portfolio.   As product orderable options increase over time, so does the complexity in figuring out how to order, configure, stock (for high-tech manufacturers) and sometimes build different products.  This is really a failure of product lifecycle management.

High tech companies are seemingly good at bringing new products and product variants to market, but do a poor job at managing the overall product portfolio.   It is very common to see the 80/20 rule in high tech companies – typically less than 20% of the products generate more than 80% of the revenue.   I’ve seen even more exaggerated cases, where less than 10 products generate 90% of the revenue and where some products generate either $0 or a few hundred dollars a year (for an enterprise-class software company).   For many software companies it seems like “no big deal” because software doesn’t seem to have any real costs, outside of a few CD-ROMs. 

However, one customer recently told us that each orderable in the product line has a cost of over $2,000, due to a variety of factors including sales productivity, support load, R&D expenses, lost sales, channel inefficiency,  entitlement management systems costs, and in some cases, stocking costs. 

More importantly this result can be a competitive disadvantage in a market where it’s easier to figure out how to order the competitor’s product.   This becomes more crucial as a product or technology becomes more commoditized (as is happening in the high-tech device market).

How does this happen?

For starters, there is always a need to adapt to market conditions or change and add product orderables for a variety of reasons, including:

• Products sometimes miss the mark in terms of their competitiveness, so the product managers experiment with different product packaging strategies as an immediate way to make products more competitive
• Products are added as a result of attempting to address new markets and customers
• M&A activity can result in an immediate increase in new product orderables from the acquired company
• New marketing management joins the company and has a different strategy for packaging products into orderable units

Now, add to the mix that no one is really compensated on product portfolio efficiency.    As a result, if companies do have an End-of-Life process, no one is incented to follow or communicate to customers that such a process exists.  But often, companies don’t have a formal policy, citing “customer anxiety” over removing products.

However, upon closer inspection, why would customers care if you removed products that provided almost $0 revenue to the bottom line?

Is this a problem you’ve encountered at your company?   How do you deal with it?
Have you experienced SKU-er shock as a customer? What was your reaction?

Next time – how to trim the fat, and create portfolio management excellence!  In the meantime:

• Take the 2009 Software Pricing and Licensing Survey for software producers and high tech manufacturers.
• Check out my new V-Smart Radio episode: Virtualization: a Brave New World.

"Software as a Business" - The New Mantra of High Tech Manufacturers

by: Cris Wendt

Running a traditional software company can definitely be a fun and profitable endeavor.   Oracle, SAP, Microsoft, Novell, CA, EMC, and others have proven that to be the case.  

But, we’re starting to see a new breed of software company—the manufacturer of hard/electronic goods. As we work with our customers, we find these traditional, even old line companies trying to position themselves as software companies.   I’ve heard the rally cry "Software as a Business" more than once.  So what does it mean?

Companies that manufacture electronic appliances, from handheld portable devices to internet appliances to telecom and security systems, are finding that the underlying hardware in their devices are becoming commoditized. Competition is becoming fierce for the underlying platform.  Many devices and appliances these days use mostly the same standard, powerful chip-sets and one of the standard embedded operating systems.   A few years back, one classic electronic appliance manufacturer told me that "what we have is a cheap Linux box on a standard chip set.  In fact, that’s what most of our competitors have too".   

In this climate, how does a company differentiate itself from the competition?  The answer is in their software – both in how it can provide monetized value, and, in how it can reduce the channel and stocking costs of the device.   High tech manufacturers also see value in the recurring revenue stream that software maintenance delivers.

To set some context, the value that many high tech manufacturers provide is moving up the technology stack from the underlying hardware, OS, and device driver to the application software.  In this case, the application software is the software which gives the device its personality – whether an IP phone, a router, camera, etc.    I’ve had several device manufacturers tell me that their investment in software development is greater than their investment in the underlying hardware development.   What they are looking for are ways to better monetize their investment.

One way to do this is by attacking the market with multiple price points, using only a single product manufacturing SKU.  The single SKU contains a standard hardware configuration and standard set of pre-installed software binaries.  At the time of sale, different products can be enabled by delivering the single hardware configuration along with a license key that enables different functions and capacity.   

How does this work? One internet appliance company told me they were the first to market with a new device, so they offered the complete full-function offering at the highest price point. Over time as lower-end competitors entered the market, they could appear to throttle down the functions and create a lower price points simply by providing a license key that enabled fewer functions and capacity.  Such an approach, they told me, not only allowed them to enter the market when it was most profitable, but it also enabled them to protect their market share against new competitors and still be able to up-sell to the higher-capacity products.  Software as a business = maximum profit.

One high tech manufacturer recently told me that their service prices are eroding because their customers will just replace hardware if it goes bad.  On the other hand, the customers see value in the ongoing stream of new software updates and patches.  

Another approach I hear is something similar to the iPOD model, where the device manufacturer is trying to create an ecosystem around their platform, where they, and other companies can release additional value-added software functions, many of which can be enabled via simple license keys or activation codes.

In the end, all of these companies are moving their business from the lower profit hardware, to the higher value software-enabled functions.

Are you struggling with a similar challenge?  Tell us how you’re thinking about solving it.

Who Wants a Perpetual "Liability" Business Model?

by: Cris Wendt

The perpetual license model is the most frequently used one for selling software.  However we’ve uncovered several problems that can occur with this model, in working with customers on entitlement & compliance systems design and product packaging behavior.

Let’s Summarize the Perpetual License Model:

Most of the B2B software licenses are sold in a model where the right to use the software is sold with the perpetual license.  Once the software license has been purchased with a license fee, the user has the right to use it, in essence, forever.

As part of the business model, the customer can optionally purchase a maintenance contract, which provides product support, and entitles the customer to refresh the functionality of the software with new updates and upgrades.   The access to new updates and upgrades keeps the software current – that is, the software is continually enhanced to fix defects, provide additional functionality required for the software to be productive, or even enable the movement of software to next generation hardware platforms as older platforms reach end-of-life.   Maintenance is often priced at a value of 18% - 22% of the list price of the software.

The Pressure to Protect Revenue:

Over time, this arrangement becomes a blessing and a curse.  When products mature in the market, the revenue stream associated with product maintenance increases to a point where it overtakes the new product revenue.  So it’s important to keep the customers on a maintenance plan.  However, with time, there is an evolution of the license lifecycle of the product that becomes very difficult for processes and systems to manage.  

Enter the License Lifecycle of a Perpetual License:

Below is a fictional, but all-too-real, description of what happens behind the scenes in a software company.

Product A, version 1.0 evolves to version 1.1, then 1.2, etc.  At some point in the lifecycle of Product A, marketing decides to split this into multiple products (products B and C).  To deal with this re-packaging, product management deems that some customers with the perpetual license who are covered by a maintenance contract receive Product B, some receive product C, and some customers receive both.  Also, maintenance fees have to be manually adjusted to accommodate the fact that the product packaging was changing. 

A year later, a company merger occurs, and more product packaging with manual processes is done to protect the maintenance revenue.  In some cases, sales discretion is allowed to determine the exact mix of products that customers receive.   All of these changes are accomplished with manual processes because the ERP system (which forms the basis for managing entitlement and maintenance records) was designed around the physical product paradigm of building and shipping a physical product.  Over time, these manual processes become an enormous operational expense to the software company.

At this point, there are weak links between what the customer originally purchased, the information to describe what the customer is currently entitled to run, and what they are actually running.  This is when customers complain about inaccurate license keys; when order management processes remake orders; or when the corporate audit groups try to work with customers to “true up” with no record of truth.

If you don’t believe me, ask your local maintenance renewal representative or order management representative. 

Are Time-Based Models Going to Dominate Software License Sales?

Granted the perpetual license had only a part in this entire chain of events, but companies with time-based license models tend to have less of these types of problems.  The actual right-to-use expires on a regular basis, enabling a re-start to the license and compliance process.

I’ve likened time-based models to a haircut: if you don’t like what you did last time, just wait a little bit and cut it again.

I’d be interested to know if the fictional scenario above is true for your company? Are your software licensing and entitlement processes handcuffed with manual inefficiencies?

The Fine Art of Token Licensing

by: Cris Wendt

The Token License Model (as a variant to the floating license model) is a great way to provide flexibility to your customers.  By selling tokens that can be used to invoke multiple products, you provide a lot of flexibility to users who can’t always accurately predict what to purchase. 

Implementation & Planning Considerations:

Using tokens as a mechanism to control access to products requires some careful thought and planning.  Typically, the Token License Model is implemented in conjunction with a license manager technology, and operates something like this:  before a product operates, it makes a request to check-out or consume tokens (non-product specific license keys) from the license manager.  Based upon the availability of tokens in the pool at the moment of the action (determined by how many tokens were originally sold to the pool less how many tokens are consumed at that moment), the request is either granted or denied.   While the implementation of this token license model is easily accomplished in the software when a license manager is present, there are some important policies that need to be established before an implementation begins:

• How many tokens do I need for each product when it operates? 
  That is, how is a token calibrated to list price?  What is the sufficient granularity of value for a token?  Is it $500 per token? $1,000 per token?
• How do I handle list price changes to software? 
  If a product is designed to consume 5 tokens when it runs, what happens when the price of the product changes, especially if the software is already installed in the field?   Suppose the new list price warrants that 6 tokens are consumed for each invocation but customers are licensed for a version that checks out 5 tokens.
• How do I measure the usage of actual products when tokens are consumed? 
  License managers typically record all license key request activity in a usage log for subsequent asset management and usage profile analysis.  In a non-token license model, a particular product will consume a license key that is specific to a particular product.  That way when the usage log is inspected, the usage attributed to a particular product can be understood by looking at the number of times specifically-named license keys are consumed.  When generic tokens are checked out, however, all usage is attributed to a generic token. It’s impossible to understand which particular product consumed the token.

All of these issues can be easily addressed in a design phase, but they must be carefully considered during the planning and implementation phases.  

The Temptation of the Token

One of the more seductive aspects of a token is the capability to allow customers to access future products that were not available at the time the original sale was made.  For example, at the time of the sale, it’s easy to tell customers that a new, desirable product will be available in 6 months, and that it will automatically operate with the token system.

While such an assertion is appealing, there is a potentially serious downside:  Some or all of the revenue associated with the agreement may be deferred until the new technology is available.   The topic of revenue recognition was discussed in some of the earlier blogs in this series under Subscription licensing.

It’s very important to define and bound the parameters of future technology access whenever customers are provided with a flexible model like token licensing and to carefully consider the impact of revenue recognition. 

Token Licensing – are you thinking of adopting such a license model?  What are your challenges with token licensing models?

Next week: The Perpetual “Liability” Business Model