Entitlement and Compliance Management: Talking Successful Software

Implementing Software Licensing or Software Auditing is Easy. But Do You Have a Good Design?

By: Cris Wendt

 

When working with software producers and high-tech manufacturer who are implementing software license technology, we use a top-down methodology to find the best fit for how that company will implement software licensing. The process is fairly straightforward: we work with product and business leaders to develop a written compliance philosophy, and then use the compliance philosophy to create one or more enforcement profiles which guide the implementation of software licensing. The result is a well-designed and consistent approach to software compliance and enforcement that balances the company’s desire to balance revenue recovery with a positive customer experience.

This approach can also be used for companies that aren’t using software licensing, but do want to evaluate what the enforcement experience should be for customers who are using software outside the bounds of the license agreement. The importance of this process is the conversation that results among the different business stakeholders who are participating in the process. It allows different perspectives to be discussed, evaluated, and integrated into the way software licensing will eventually be implemented (or perhaps, not implemented) in a product.

Without such a process, different product groups often make their own decisions, sometimes inconsistent with how other product groups implement licensing or approach software compliance, or, they may make decisions based upon one technologist’s view of how the product should behave, possibly ignoring the wider business perspective.

The compliance philosophy is meant to be a guiding statement about how a software publisher views software compliance and will guide the development and implementation of software licensing and associated activities. The compliance philosophy reads a little bit like an extended mission statement. It will need to consider factors (descibed in my previous blog), such as product, market, lifecycle, and geographic considerations, and describe at a high level, the approach the publisher will use to guide the implementation of technology, and it will trade-off revenue recovery efforts with customer experience. The software compliance philosophy is typically 3-4 paragraphs in length - less than a page.

After the compliance philosophy is established, we use a somewhat standardized template to develop a software enforcement profile. The enforcement profile lists about 10 -15 different parameters of non-compliance, such as: using software on the wrong machine, an incorrect user using the software, accessing an incorrect version of software, exceeding the allowed count, etc. For each of the parameters, we assign a specific enforcement action from a list of about 8 approaches. These enforcement actions collectively represent a range of experiences from "Do nothing – No Product Disruption", to "Message the User – Product Operates Normally", through other actions to the other extreme of "Disallow Product Operation". The collection of the 10 – 15 different parameters with its selected enforcement action is considered an enforcement profile.

We typically start by creating about 5 or 6 enforcement profiles for larger companies, based around where we think there may be some commonality for enforcement behavior. For example, we may create one profile for "mission critical" products, one for "commodity products sold into Asia/Eastern Europe", another for "Software sold in large enterprise deals", etc. As we go through the process to develop and compare the different profiles, we usually consolidate the profiles down to one or two. Typically, companies will trade off the simplicity of fewer, more powerful enforcement profiles over the complexity of too many.

After the enforcement profiles are created and socialized, the remaining steps are to implement the software enforcement profiles in standard ways (typically, creating standard implementation libraries), integrating changes to the enforcement profiles into an existing change management process to ensure that consistency is maintained over time. That is how you maintain a good design while implementing software licensing and auditing.

Does your company have a common compliance philosophy? How do you approach this issue?

　

The A, B, C’s of Software License Compliance and Enforcement

By: Cris Wendt

Sometimes the topics of software license compliance and enforcement seem twisted, very much like one of those M.C Escher drawings popular in the 70’s and 80’s that show complex physical objects connected in impossible ways though the optical illusions created by his drawings.

To this end, I thought a few blogs on the subjects of enforcement and compliance would be useful and interesting topics.

Let’s start with some basic definitions: software license compliance is a broad term to describe the behavior - whether or not software is being used within the bounds of a software license as established by the license agreement or the software entitlement the customer purchased. Software license enforcement is the mechanism or the mechanisms that are used to manage software license compliance. An enforcement mechanism will usually result in some experience to the user of the software to let them know if they are using the software outside the bounds of the software license agreement.

An enforcement technology and associated implementation method are designed to balance the needs of the software producer and the software consumer. In general, the software producer uses enforcement to grow revenue in one of two fundamental ways:

1. By making software easier to use so customers use and buy more than anticipated (making this a lower cost way to generating increased sales);

2. Or, by eliminating revenue leakage caused by software piracy and usage of software outside the bounds of the license agreement.

The software consumer doesn’t want unnecessary barriers to adoption of the software, in most cases, but they also don’t want to be out-of-compliance for any extended period of time, because that increases potential liability and risk.

Software license enforcement can be designed to create a continuum of possible outcomes for software that is used outside the bounds of the software license agreement. This continuum can vary from a "do nothing" approach on one extreme of the continuum, all the way to preventing the software from operating at the other end of the continuum. Within this range are a number of possible results such as messaging, enabling overdraft, warning customers that they’re approaching a limit, reduction in quality-of-service, and queuing requests. In fact, the outcome can vary by the specific type of software license compliance condition. For example, you may elect to prevent your software from starting if the customer does not have a valid license, but you may only want to give the customer a message if they are using the wrong version of software.

The software license enforcement methods that software producers employ don’t have to be a one-size-fits-all approach. The enforcement method can be tuned by a handful of key factors:

Market

– Software that is sold primarily to large enterprises and data centers where corporate governance and financial controls are stronger can utilize an enforcement method that is more liberal and tends more toward messaging users or "Nagware." On the other hand, if you are selling games to a consumer markets, piracy and intentional over-usage are probably the problems that you need to address. A stronger enforcement experience may be required.

Geography

– Software sold to the U.S. and Europe, where financial accountability and auditing practices are stronger, can also tend toward a more liberal enforcement policy than software sold to emerging markets with very weak intellectual property laws.

Product Type

– On one extreme, for example, enterprise-level software that is carefully deployed by an IT department and manages data integrity may never shut down due to out-of-compliance usage. On the other hand, desktop design software may be able to sustain a denial of service if the product is out of compliance.

Product Lifecycle

– Products that are early in their lifecycle and provide a lot of value may need stronger enforcement mechanisms to enable secure demos of the new technology, and to protect access to leading edge algorithms (especially with vertical application software such as design and CAD). On the other hand, a company with a wide portfolio of mature products that wants to block competition may want to lessen the enforcement approach as a way to make it easier to use their software and block the use of a competitor’s software.

While the implementation of a software license compliance and enforcement technology has technical implications, it’s very critical that the whole business is involved in defining and articulating a software compliance philosophy that will drive the implementation.

Next Time – Creating a Compliance Philosophy and Enforcement Profile

Through the Looking-Glass at License Models, and What Cris Found There

By: Cris Wendt

When it comes to software license models, I sometimes feel like a singular Tweedledee and Tweedledum, the twin brothers in Lewis Carroll's Through the Looking-Glass, and What Alice Found There. I feel ready to wage a personal battle by promoting opposing perspectives on license models, yet the battle never happens. Like the two brothers with their opposing views, the confrontation never happens because the two views really complement one another and are not contradictory.

The issue is the license metric, the component of a software license model that is used to apply pricing. This is known by such names as "concurrent user", "named user", "Number of CPUs", etc.

At times I feel like Tweedledee by suggesting to companies that the license metric should be a way to create more price points to reach new markets or new customers and increase overall revenue. By understanding different usage profiles, it’s possible to expand a software license that is sold by, for example, named-user, and offer a different type of metric that allows the software to be sold by concurrent users. Such an approach may be used, for example, to take software that is used by a particular individual, and allow it to be affordably used by a wider audience of users as they may not all be using the license concurrently.

At other times, I feel like Tweedledum, by suggesting just the opposite. I sometimes tell companies that they have too many license metrics in their portfolio and that they need fewer of them. For companies that have a large number of software titles that are sold as a larger solution, the complexity of offering many different software license models for the various products can be counter-productive and confusing, especially for customers and channel partners. It’s actually easier for companies with a rich product offering to offer fewer license metrics and not more. This enables a wider portfolio of software to be more easily sold as a collective entity, rather than every product in a solution having a license metric to optimize for its use as a standalone tool.

As it turns out, both recommendations are complementary. When a software producer is small, it’s important to grow market share. By offering the product with more software license models, it’s easier to reach more customers at different price points. When the software producer is large and the solutions naturally reach a broader market, it’s easier to sell more software by making it simpler to buy more software. In these cases, fewer license model options that apply broadly across software titles are more effective.

This perspective reflects a natural lifecycle of software products in a market – over time your license models and product packaging will change to reflect market conditions. As you plan your product roadmap and associate licensing and entitlement management technology, be sure to realize that change will occur, and plan for it. And unlike Tweedledee and Tweedledum, you don’t have to wait for a big black crow to come down from the sky to make you realize these opposing perspectives on software license models aren’t at all at odds.

When it comes to software license models, are you Tweedledee and Tweedledum? Let us know!

In the meantime, check out my V-Smart Radio episode: Virtualizatioin: A Brave New World

 

SaaS / Software + Services – so much that is different, so much is the same

By: John Frame

This past summer, in my conversations with customers, analysts and prospects, a recurring theme was that for all the differences between SaaS and Software + Services models, the number of things that remain the same is remarkable.　Software as a Service, or SaaS, is the latest software delivery model.　 As such, SaaS can be a new way for you to have a relationship with your end-users.  It can address long upgrade cycle times and provide an advantageous cost model.

All indications show that SaaS is likely to follow the same adoption curve as any other new technology -- high growth in the initial phase, but slower growth over time, which makes sense. In fact, many of you are already thinking about and planning for this technology change and are putting in place efforts in two areas.  First, you’re making changes to your product plans, packaging and pricing to enable penetration into adjacent or alternative markets.  Second, you are making changes to ensure that you are fairly compensated for the value that your end-users are getting from the service.

Today access to your services is universally by means of a name and password, or authentication.  Most SaaS / Software + Service providers recognize the problems with authentication and are using session monitoring to try to detect over use or malicious use of the software.  Details on the user sessions are compiled. Reports are generated and based on suspected patterns of abuse; offenders are flagged and targeted for further conversations.  Session monitoring does give software vendors a level of understanding of who is using what. However, it tends to highlight the clear or extreme cases, and does not pick up on cases where the patterns may not be as clear, or if the misuse is more sophisticated. Please remember, unlike traditional software, vendors/manufacturers have a real cost associated with every user of the service regardless of whether the customer paid or not.  Understanding who is using the service and getting fairly compensated by them is a great way to expand profitably.

Licensing services offer some key benefits:　

· Licensing + Authentication provides software vendors and manufacturers granular reporting capabilities allowing them to identify the specific devices where credentials were used during a specific period of time. These reports are far more precise and accurate than what would be generated from simply session monitoring.　

· You can choose to reduce or alter the features available to the user if they are on an "unlicensed" device.　

· Finally, the technology can be used to lock out users from accessing the service if the credentials are being used on unlicensed or too many different devices

By including licensing in your service, all of these benefits are available to you.  You can control all of these different options from the back office and modify the approach based on different users, services, geographies and channels as needed.

I’m going to go out on a limb and say that it’s highly likely you are reading this blog post because you use or offer a service that combines Authentication and Licensing.　

Pop quiz for a $25 Gift Card!

I’ve got a $25 Starbucks card for the first person who can, as a comment to this blog post, name the service with the following characteristics that combine Authentication and Licensing:

· The service launched on April 28, 2003.　

· The service is accessed with a name and password, but that name and password only work on 5 Windows or MAC machines over a two year period.　

· The service does not let you use those credentials on a sixth machine in less than two years; you need to contact the provider of the service.　

What is this service called? (Please provide your answer in the comment box)

　

　

Who Broke the Software Entitlement Supply Chain? A Little ERP Secret.

By: Cris Wendt

For software producers, entitlement management lies at the heart of the business—just as the supply chain is the heart of the business for traditional manufacturers.

Enterprise Resource Planning (ERP) applications have largely evolved to meet the needs of companies that make physical goods, whether pens and pencils or electronic equipment, appliances, and automobiles. For these companies, the ERP system is an integral part of the overall company’s success.

For traditional manufacturers, ERP systems participate in different stages from procuring parts from their supply chain to scheduling manufacturing activity, and eventually to selling the product. During this entire process all of the financials and "books" are being managed. One of the powerful benefits of an ERP system is that because all activities are centrally managed, the process to "close the books" at the end of the quarter is much faster – making the CFO’s job easier.

However, in the world of software, the supply chain model isn’t so simple and is slightly more nuanced. As mentioned in an earlier blog Who Wants a Perpetual "Liability" Business Model?, most software companies sell their software in a perpetual license model, and charge an annual support or maintenance fee. The maintenance fee is generally priced as a percentage of the then current list price of the software. Over time, the fees associated with maintenance can be a significant source of company revenue, so it’s important for the software producer to know exactly what software the customer has installed.

This is where the challenge lies: traditional ERP systems aren’t really designed to track the entitlement lifecycle of a software product. As one of our customers said, "ERP systems are great at building washing machines, but not at tracking the software lifecycle". The software entitlement owned by a customer will mostly likely change over time, and can in fact, look quite different from the original software license that was purchased. This is due to the evolution of software over its "lifecycle". Software "Product A, version 1" may be the original product that was purchased. What might happen is that the customer might evolve his original purchase from version 1, to version 2, and then "upgrade" the software to Product B. A year or so downstream, the customer may be migrated to a completely different product, say Product D, due to M&A activity and an obsolescence of the original product. Some migrations can be even more complex.

Also, the software entitlements associated with software license purchases can become more complex as customers may be entitled to multiple instances when they buy a license. For example, when buying enterprise-class software, the customer will typically purchase the rights to the production instance of the license, but they may also have the rights to a development and test instance of the software to integrate new releases of software into their environment. They may also have the right to install a "cold backup" license for disaster recovery purposes. Over time, the software deployments or "fulfillments" of these entitlements may change.

So can a typical ERP system work for the software entitlement lifecycle? Here are the signs that we tend to see when a somewhat vanilla ERP system is put in place for a software business:

1) Customer entitlement records are quite "dirty" – meaning they don’t reflect what customers actually have installed at a particular point in time.

2) Extensive customizations are in place to support the software business – the original system has been modified to support the "install base"

3) Automated processes that degrade into extensive manual processes in order to "adjust data" to reflect what a customer really has installed.

4) Lengthy time to make changes to products because "the back-office systems won’t allow us to do this".

The result of all of this can be lower upsell and renewal revenue due to inaccurate data, higher operational costs to maintain manual processes, and lost market opportunities because of an inability to react to market changes. In addition, your customers are unhappy, because nobody can agree on what the customer owns.

This is why commercial off-the-shelf (COTS) software entitlement management systems have come into being – they become an integral component, along with ERP, of the "software supply chain". These systems help manage the software entitlement lifecycle and in the process, help you protect revenue, minimize costs, and make it easier for your customers to do business with you.

Is your company debating "build vs. buy" or using your ERP as an entitlement management system? Let us know!

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.

Who Cares About Entitlement Management?

By: Cris Wendt

In the software business, entitlement management describes the rights that you acquire when you purchase a software license as well as the ongoing management of those rights.

To describe software entitlement management by analogy, we can look at the purchase of an airline ticket.  When you purchase the ticket, you are entitled to travel from, say, San Francisco to New York in seat 15A on November 11 at 8:50 a.m.  You are also entitled to receive frequent flier miles equivalent to the total miles flown for the trip if you’ve enrolled in the airline loyalty program.  To poke a little fun at the airline industry, we can also say that you are entitled to flight delays, poor food, unfriendly flight attendants, and a hard seat.  When you actually fly, then we say that you’ve fulfilled those rights.  But, if you change your mind, you may be able to change the flight date and destination, given the particular entitlement rights associated with the airline ticket purchase.

The reason that entitlement management is such an important concept for the software business can be illustrated by some real life incidents that I experienced.  Several years ago I purchased some anti-virus software for my home computer.  Based upon what I purchased, I was entitled to use the software anti-virus engine and access virus signature updates for a year. 

Near the time that my subscription was about to expire, I purchased another computer.   When I went to update my subscription, I made a request to purchase the anti-virus software subscription for 2 computers for a year. In a sense I was renewing the annual subscription for my existing entitlement and purchasing another entitlement.  After conducting the online purchase, I ended up with a total of 2 years of anti-virus subscriptions that worked on both of my computers.  This resulted in what we call “over-entitlement” – a situation where I was trying to do the right thing, but I received more than I was entitled to receive.

Near the expiration of that term, I found out that my internet ISP fees entitled me to use the same anti-virus software as part of my standard monthly fees.  As a result, I decided to access the software entitlement that was provided by my ISP and to not renew my existing entitlements.   So, I enrolled in the ISP’s program.  Meanwhile, the previous entitlement that I purchased had expired.  No problem, I thought.  However, the expiration of my old entitlement also made the entitlement that I was supposed to receive as part of my ISP service to disappear as well.  

So, ultimately what happened is that the anti-virus software company lost some revenue at the first subscription renewal. They had increased support costs to rectify the situation, and they had an unhappy customer, who may switch anti-virus providers at the next opportunity.  In addition, by not knowing who their customer is, they are losing great up-sell opportunities

Furthermore, the lack of accurate entitlement tracking can lead to problems for customers of the software producer.  If the customer is responsible for ensuring compliant usage of software, to what benchmark are they supposed to measure compliance if the software producers themselves cannot keep track of what customers are entitled to use?    Without knowing what entitlements are in effect, how do software users manage compliance?

As it turns out, this entitlement management scenario is not that unique.  We find that software companies often have much more intricate and complex entitlement management situations that occur reasonably often.   Fortunately, the airline industries can teach us a lot.  

Next Time: ERP’s Dirty Little Secret – Entitlement Management.

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.

 

 

 

The Matrix Virtualization - Red Pills, Blue Pills, and Magic Pills

By: Cris Wendt

"There must be an awakening to the crisis, followed by action"  W Edwards Deming

The parallels between the movie, The Matrix and the impact of virtualization on the software industry have been documented and drawn upon before.  Whether or not the software is running on a real physical machine or a virtual machine is an obvious parallel, with a somewhat reversed perspective - we have historically lived in "The Matrix" of physical machines, and we're now entering the virtual world.   

However, the more interesting comparison occurs early in the movie when the lead character Neo (played by Keanu Reeves) is given a choice by the character Morpheus (played by Laurence Fishburne).  Neo is offered either the Blue Pill to return to his existence where he has built on a life based on his current beliefs, or the Red Pill which would provide simply "the truth.”   The Red Pill is typically offered only to those younger than 18.  After that, the risk of denial and psychotic episodes from the reality of separation is much higher. 

For the software publishers, the emergence of virtualization has many software vendors at this philosophical crossroads.  In a recent study conducted by Acresso among a variety of software publishers, we found that 62% of software publishers believe that their customers are using software in a virtual environment, yet, 57% of them have not adopted any policy changes to accommodate virtualization.  Many software vendors are at a standstill.  

For software publishers, the uncertainty over change and disruption caused by virtualization appears greater than the possibility of gaining a market advantage or seeding new opportunities.  However, the study found that 13% of software producers believe there may be opportunities with virtualization, so there are positive signs that virtualization is being embraced.

The major stumbling block is the impact of virtualization to what is known as the "license metric," that part of the license model that is a measure of usage and to which pricing is applied.   A license metric is identified by such terms as: named user, concurrent user, or number of cores.   Clearly, any change to how software is licensed and priced is not something taken lightly, especially if the license metric is based upon a characteristic of the hardware.   But a failure to do anything can result in lost revenue or risk to customers who are trying to do the right thing, but aren't given any guidance or support by their software vendor and face the financial risk that non-compliance can bring.

Unfortunately, there are no magic pills to address virtualization, but if you do decide to take the Red Pill, there are some basic steps you can take, as described by Jim Geisman (of Software Pricing Partners) in a recent webinar we presented on the topic:

· Embrace Virtualization.  Virtualization is here to stay, acknowledge it, it’s a part of today's computing fabric.

 

· Get ready to Virtualize.  Review your pricing metrics and update your entitlement and support models.

 

· Commit to a Position:  At a minimum, establish a platform neutral position where your customers are not at a disadvantage for using your products in a virtual environment.  However, seek ways to find competitive advantages:  Offering your products as "virtual appliances" or using virtualization as an entry to cloud computing are possible starting places.

 

· Establish a Compliance and Enforcement Philosophy: Determine your position with balancing customer experience with the need to manage revenue.  Do you have trusted customers who simply want to be compliant in a virtual world; or do you have problems with intentional software theft or piracy?  Once you’ve characterized and segmented your market, you can then apply the correct level of technical enforcement.

 

· Partner for Success:  Companies like Acresso can help you map out a roadmap and provide you with the technology that you may require to rapidly meet your market requirements.

 

With Morpheous at your doorstep, remember that there are not magic pills, but the Red Pill will lead you to the truth.

 

Are you debating which Virtualization pill to consume?  Let us know!

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.

 

 

The Hidden Costs of Building it Yourself – The Case of the Wayward Sprinkler System

By: Cris Wendt

Ironically, one of the members of our Global Consulting Services organization at Acresso had to learn the true costs of a build-it-yourself approach the hard way.

"Michael", one of our top system architects and implementation consultants had a legacy sprinkler system in his yard. Michael recently bought a house in the central valley of California with a lawn and garden sprinkler system that had been installed by the previous tenant. Of course, the previous owner is now long gone and he didn’t leave much documentation behind. The demands of the sprinkler system had increased, as Michael had new requirements to extend the system to include watering an extended portion of lawn and drip into a garden area. He was done with using the hose and manual sprinkler to get the job done. To update his automated sprinkler system, he needed to add another circuit to his legacy system and add some new types of sprinkler heads. This required some new plumbing, and ideally, a new control unit and a re-design of the sprinkler control units.

Michael could have hired the job out to a local plumber who could install new equipment, added newer control units, and re-design the new circuit in less than a day. But, being an engineer, Michael said to himself, "Hey, I can do this myself, and, I can save a few bucks in the process. We don’t need to re-design the pipes, nor add a new control unit". Michael, did in fact do the job on a warm August weekend, and returned to work on Monday with a nice tan.

A week later, we were working with a customer who was going through a similar experience with their entitlement management requirements. They had a legacy ERP system and needed enhanced functionality to accommodate the growing needs of their software business. Their needs seemed simple. They needed fewer manual steps and a more automated entitlement and customer license fulfillment process. In the room were the 2 lone marketing managers and their business requirements, surround by a lot of business process people and IT architects. The company had spent months evaluating different systems, and decided to build-out and extend their legacy system to accommodate some new requirements to automate more processes. The ROI analysis they did showed that it would be less expensive to build it themselves. They also spent months in mockups, trying to design for every possible business process scenarios; all while making different architectural design assumptions. In the meantime, a competitor had updated their offering and had created competitive havoc in the field.

While we were helping the client to think through all of the activities associated with the entitlement lifecycle of software, Michael received an email on his Blackberry from his wife who was at home. In the email was the single word, "Yikes", along with an attached picture of a very flooded side yard. The legacy sprinkler system that Michael had built upon had malfunctioned due to a brief power spike, and all of the sprinkler control units were activated simultaneously. This led to (pardon the pun) an over-entitlement of water in his yard. To make matters worse, his large dogs were in the area and decided to have some fun and wrestle in the mud. This activity caused them to break a long, exposed pipe, leading to an unrestrained flow of water into the side yard. The result was an undermined concrete walkway and potential damage to the concrete foundation of the house. Michael’s initial cost-savings were over-run by the unexpected costs of the real "lifecycle" of the sprinkler system. It seems the build vs. buy analysis was incomplete and inaccurate.

As Michael returned to the customer meetings, the discussions were still continuing and the final design is more than nine months away. Hopefully, the decision to build won’t result in a flooded foundation.

Is your company debating "build vs. buy" for a licensing and entitlement system? Let us know!

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.

 

Improve Product Lifecycle Management Processes to Reduce SKU Count

by: Cris Wendt

 

One of the behaviors that we see with many software companies and high-tech manufacturers is SKU proliferation. When SKU counts are in the thousands or tens of thousands of items, the task of pruning the product line can become increasingly difficult.  This, in turn, exacerbates the SKU problem as something for someone else to solve.   In addition to the problems mentioned in the previous blog post, the proliferation of product data also can undermine the transition to new ERP, CRM, or entitlement management systems.

 

At some point in most companies, an executive will get involved to trim the product line and begin a product consolidation effort.  I have helped customers with a few of these, and they can be tedious and painful endeavors if left unaddressed for years:  products have to be identified for removal, a transition plan has to be developed to address the customer install base issues, and a communication effort needs to be launched.   This ongoing activity must also be managed.   These efforts take valuable resources away from new product development or addressing important market needs.  Once such an effort is completed, or well underway, the question is asked:

 

“How do I prevent SKU proliferation from happening again?”  

 

While there will always be cases where new products do not succeed in the market, here are some suggestions on ensuring that your product lifecycle management (PLM) efforts are designed to keep your product portfolio as productive as possible.

 

1. Establish minimum annual revenue standards or annual volume standards for each new SKU or product number that will eventually make its way into your ERP and entitlement management systems.  Depending upon the size of your company, the exact number may vary.    The analysis for new product revenue should not just be viewed at a product line, but at the individual SKU level.   Products/feature sets that do not meet these standards, but provide value can be incorporated into another, related flagship product.  This in turn can be viewed as enhancing the maintenance value proposition.  Often, the non-productive SKU’s tend to be product “add-ons”, “options” or “bundles” for a flagship product which drives the largest component of the revenue.  For most enterprise software companies, we recommend a minimum annual revenue of approximately $50,000 or more.  Of course, as the saying goes, “your mileage may vary”.

 

2. Create and publish product packaging and structure taxonomy standards to promote consistency among different products and product lines.  This will ensure that as SKUs proliferate, there are standard structures and behavior that guides how product lines are put together and bundled, so that new partners and employees will be able to extend their knowledge of one product line to another.    This includes not only the basic definitions such as “product”, “base product”, “add-on product”, “upgrade” and “update”, but there should be guidance on how to use these different structures to grow product lines in a systematic and consistent way.  The taxonomy standards should also address when product functionality is best incorporated as part of a “maintenance release.”   This is a fairly broad topic in itself, and will be the subject of a future blog.

 

3. Develop and Publish an End-of-Life (EOL) Process.  This should include a standard templatized approach to:

 

· Identify revenue or strategy “triggers” that determine when products and product releases should be considered for end-of-life.  Most companies already have standards for managing the end-of-life for different releases or versions.

 

· Business, customer, and legal issues to be considered.

 

· Transition considerations for customers who already own the product in order to maintain the highest possible levels of customer satisfaction.

 

· Create a 6 – 18 month plan of activities to progressively transition products from active marketing, sales, and support to final withdrawal.

 

· Communicate the plan through your website to customers and include all products and product releases in the End-of-Life process.   This is a critical step to setting customer expectations that you do run a business and occasionally need to remove products from active sales and marketing.  Our experience has shown that customers will appreciate your proactive approach.

 

· Update the Support portion of your website to include a section for End-of-Life products, including all products in the process, and identify the state of EOL.  Don’t forget to include the status of product releases and any platforms (or OS versions) that are no longer supported.  Here are some samples used on the websites of Infoblox and Acresso.

 

4. Actively manage the steps described as part of your existing PLM processes.  You may want to assign personnel in either Marketing Operations or Sales Operations to take on the tasks of periodically reviewing the portfolio, reporting on metrics, and providing recommendations on products to EOL. 

 

 

Are you encountering SKU proliferation? How are you dealing with it?
Did you miss Part 1? Are you being SKU’ered to death?

 

Next time – The Hidden Costs of Building it Yourself – The Case of the Wayward Sprinkler System.  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.

 

 

 

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.