Entitlement and Compliance Management

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.