Entitlement and Compliance Management

Software Bundles – Happy Meals or Heartburn for the Vendor or Enterprise?

By: Cris Wendt

Can you make a meal out of a software license and entitlement? You can, if it’s a software bundle. In almost any industry one of the more common business practices to market a group of products is to create a bundle or a "super product." An historically popular consumer bundle is the McDonald’s "Happy Meal" – a combination of different food items packaged together and designed to appeal to children in a way that gets their parents to buy more food in one meal, and also, to buy more meals over time. In consumer markets, the use of a bundle can be an effective marketing tool to grow market share.

Since we’re all familiar with the concept of creating a software bundle, regardless of whether you call it a solution, suite, package, marketing bundle or sales bundle, we tend to apply the same concepts to the enterprise software business for one or more of the following similar reasons:

• It’s a way to offer and promote "solution" to customers - a situation where you can expose your customer to a combination of products that can address a larger problem than a single product in the portfolio (that may have the most brand awareness).

• By combining products and offering a "bundle discount" it’s possible that the customer may buy more than they normally would because of the incentive of attractive pricing. This can be done on a permanent basis, or, as the result of a "promotion." In a retail situation, this happened to me a few weeks ago when I was looking for a few travel-sized packages for toiletries. I bought a travel kit of toothpaste, shaving cream, and deodorant that also included a comb, mirror and clippers when I only really needed the toothpaste and shaving cream.

• It’s an approach to grow market share in specific market or customer segments by offering a combination of products that would appeal to those particular segments. This is often done as a pricing reaction to a competitor that enters the lower-end of a market where the software producer may not have a product offering, but where they may not want to compromise pricing for the rest of the market.

• Bundling is a method to squeeze competitors by offering a complete solution at an attractive price that makes it more difficult to buy the best-in-breed point products. This is what happened with Microsoft Office – Microsoft was able to pretty much eliminate Aldus Persuasion, Lotus 1-2-3, Quattro, WordSTAR and other software from the enterprise desktop simply by offering Word, Excel, and PowerPoint (initially) in a single package with an attractive discount.

Since creating a software bundle appears to involve little more than packaging existing products together, most product managers think it should be easy to accomplish. The reality is that with enterprise software, nothing could be further from the truth. Bundles cause more trouble than any other product packaging/structure issue I see in companies. It’s amazing that something so simple, can be so elusive.

I have found that almost all software companies have problems with software bundles – either as a result of software entitlement and fulfillment systems, or, lack of consideration for the software license lifecycle. Surprisingly enough, here is what we find – over and over again:

• Software bundles often rarely, if ever, deliver on the stated business objective of increased market share or revenue, whether it was delivered as a promotion or a long-lived product. Bundles tend to be reactive, and generally don’t attack the root-cause issues of why a competitor is gaining market share, or, why pricing is not competitive. In general, I find that bundles tend to be a last- ditch effort to recover revenue from products that aren’t producing as well as they should.

• Software bundles are typically comprised of products that have their own lifecycles independent of the lifecycle of other products in the bundle. If the bundle is marketed as a single super-product, there tends to be a need to break-up the bundle over time into its constituent parts as each of the individual products are End-of-Life’d (EOL’d) and replaced by new products. As a result, maintenance and compliance groups go crazy trying to figure out what a customer is entitled to use – especially after software bundles morph and change over time.

• Quoting and fulfillment systems typically aren’t designed to handle software bundles particularly well and tend to be the forgotten business requirement when ERP and software entitlement systems are designed. When software bundles are comprised of products that cross product fulfillment mechanisms (e.g. due to acquisition) or have different revenue recognition schedules, it’s not uncommon to find that entitlement management systems aren’t designed to allow a single SKU to enable the fulfillment of software license keys from multiple systems. On the other hand, few systems are designed to allow the ordering of a software bundle at an aggregate level that, when a specific combination of products are ordered together, allows a discount to be applied across the individual products, yet still allows the products to be delivered and managed separately over its lifecycle.

• If software bundles do get sold, but are ultimately deemed unsuccessful, then there are the lifecycle issues to deal with to end-of-life the bundle or create new bundles.

As a result, I tell most companies to avoid software bundles. But if you insist on eating the "happy meal", don’t forget the Tum’s!

Next time – best practices for designing product software bundles (if you insist on using them).

 

　

Ramblings on Best Practices for Entitlement Management and Software Licensing

By:Cris Wendt

In the world of consulting in entitlement management and software licensing (or any other field for that matter), the term "best practice" is often used to describe the best process, method or approach for performing a particular task. It’s intended to represent the prevailing wisdom on a particular topic based upon experience and business results. It’s a term often used by both consultants and customers to describe a proven approach to solving a problem.

Best Practice is both powerful and misleading. Many best practices can be broadly applicable and should be adopted, while many are not. It’s important to realize when to use a prevailing best practice and when to not simply adopt what’s worked for someone else.

Some processes or approaches don’t need to be constantly re-evaluated as they are not important to the mission of the business. Processes like those involved in accounts receivable are not often mission -critical (and subject to audit scrutiny), so it’s most efficient to simply adopt prevailing best practices.

Over time, other best practices may evolve due to how companies manage changes in business regulations (SOX auditing, FASB compliance), technology (SaaS, Virtualization, Cloud Computing), market forces (economic conditions leading to a shift from Capital Expense or CAPEX to Operational Expense or OPEX), the competitive landscape (shift in license models by competitors), or other factors.

Having watched software licensing and entitlement management evolve for 15 years, it’s interesting to see how companies view best practices, especially when it comes to establishing powerful market positions.

Ironically, I often see companies struggle with extensive market research and analysis about what their competitors do in order to identify and adopt an existing best practice in an area where they should be looking for differentiation. We recently worked with one client who wanted to know what the prevailing best practice was for the "license metric" in their market. The license metric is the most important attribute of a software license – it’s the characteristic that drives pricing (e.g. counted user, per seat, per-minute of usage, etc). In a sense, they wanted to adopt what the market viewed as a standard way to price software, which is typically an area companies look for a competitive advantage. It really isn’t a surprise this company was not doing particularly well in the market.

On the other hand I have worked with and for companies who actually create best practices. These are the ones who are looking for specific competitive advantages or to accomplish certain strategic objectives and didn’t care too much about existing standards. I remember working with one small company who had an informal mantra of freakishly friendly - we spent extensive time with the executive leadership team developing software license models and an entitlement management process to create an extremely positive customer experience. As a result, they set a new highbar on best practices for customer experiences.

In some upcoming blogs I’ll be exploring some software licensing and entitlement management best practices. I’ll look at when it’s best to adopt prevailing best practices because it’s the most efficient approach. More importantly, I will discuss when it’s time to seek out and find competitive advantages by adopting and evolving best practices.

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?