Entitlement and Compliance Management

SaaS / Software + Services: What Happens to Software Licensing?

By: John Frame

Independent software vendors are looking at the software industry and realizing that it is changing rapidly. From software licensing we are now talking about SaaS/Software + Services. What does this all mean? Before we attack the subject in this latest blog, I wanted to congratulate all readers who came up with iTunes as the answer to my previous blog. Many of you provided comments and as Christopher Painter pointed out in his comments there are many other aspects of software licensing that do not go away simply because you are using a SaaS or Software + Services deployment model.　 The list that we could come up with is very long, lets toss out just two examples to illustrate the various aspects of the software business you might want to be thinking about as part of your SaaS / Software + Services strategy.　

Many SaaS services have code that is downloaded by the web browser that then enriches the user experience. These might be ActiveX objects, DLLS, visual controls or Java code that is critical to the user experience you are delivering in the service. How are those files going to be installed on the various user desktops? The browser does a basic job but many independent software vendors find that they are forced to replace that installation experience with one that is more compressive and capable of dealing with all the nuances of thousands and thousands of machines. Is your service targeted at an enterprise market? If so the desktop environment at most enterprises is pre-configured and locked down.How is the IT organization going to be able to get all the various downloaded components of your service installed and included in the desktop image? How will enterprise IT keep that collection of components current?　

But what does that mean for software licensing? How about we move away from the technology and look at a business example. As we all know, some geographies or markets are effectively owned by VARs, SIs and distributors. So what is the role of the channel in the services component of a software + Services or SaaS solution? You can go down the path of trying to separate the customer from a channel partner or you can craft your services with the idea of the channel in mind. As early as possible can you have a vision in mind that accounts for the channel? For example, can your channel partners combine your services with others that do not compete but deliver something unique for that market? How will that create value and cash for the channel partner and open your solution to new markets?

SaaS and Software + Services is the latest evolution in software with previous transitions being client / server, distributed computing, mainframe / PC and so on. I think the thing for all of us to remember is that with every transition that has occurred in our industry, the various aspects of the software business changed, but they didnt go away. We have some great conversations and design efforts underway around the role of software licensing, installation, and application repackaging in SaaS and the services component of Software + Services. I would welcome the chance to include your thoughts in our conversations both internally as well as here on the blog. 

If you have some thoughts please let us know!

　

　

Create Software Bundles for Entitlement Management Success

By: Cris Wendt

Entitlement management and software bundles can be perceived as a headache for many software producers and high-tech manufacturers. When working with customers to develop and define software bundles and bundle templates, I tend to start with the 3 most common types of bundles that we see in the market. When designing the bundles we use the bundle template to define the 360 degree view of the bundle to ensure that they are completely defined and consistently adopted. They are listed below with some common names that we use to define them, although different companies may use different names.

The real point is that whatever name is used, there can only be one meaning for how the software bundle is designed and deployed in the ERP, CRM, and entitlement management systems, price books, and product use-model. Variations are either not supported, or, result in the design of a different type of bundle.

Soft Bundle:

I refer to this as a "quasi product" or "quasi bundle". Ironically, this is typically what product managers want, but there often is the least amount of support in a quote configurator or entitlement management system. The Soft Bundle allows a group of individual products to be collectively identified as a single product identifier (e.g. "The HP Photo Center"), but that identifier is immediately separated into the constituent products that make up the bundle at the time a quote is prepared (e.g., the computer, the printer, and the software). This enables a grouping of products to simplify either the presentation and pricing of several products, but once ordered, the individual identity of the products is preserved for all other activities over the lifecycle of the products (maintenance coverage, updates, upgrades, license fulfillment, product lifecycle, etc.). This is the most powerful approach for allowing a group of products to be sold together, but managed separately over the lifecycle of the products that make up the bundle. This is often the case when companies want to combine unlike elements (services, hardware, software) into a single presentation or combine products from companies that were acquired through M/A activity.

Suite:

This is a grouping of products where products are ordered and managed as a single unit, but where the products can be used independently. This means a single product code is used to order the product and track it over its lifecycle, but where the products might be used separately during operation. This could be thought of as a special version of Microsoft Office where each product that makes up Microsoft office (e.g. Word, Excel, PowerPoint) could be used by a separate user, but where it is ordered and tracked as a unit. The bundle is presented to customers as a group of individual products, but where they cannot be separated for ordering and tracking purposes. These kinds of bundles provide a nice benefit for grouping products together, but often fall apart over time as the products that make up the bundle have different lifecycle needs. This results in the bundles being broken apart over time so that they can be separately tracked.

Package:

This is where a group of products are combined in such a way that they are inseparable from one another, and behave as a single unit - the identity of the products that make up the bundle is no longer maintained as part of the Package. The bundle is ordered as a single unit, fulfilled as a single unit, used as a single unit, and can only be operated over its lifecycle (maintenance, updates, upgrades, end-of-life) as a single unit. Creating this kind of bundle may require changes to the constituent products so that they truly operate as a single unit. I’ve seen some companies use this approach to create a new product that was priced greater than the sum of the parts to drive up the ASP and broaden the position of the strength of the solution.

By carefully planning out several different software bundles that meet your company’s needs (usually during an ERP design or re-design), companies can provide direction to product managers on how to structure products so that bundles can be successfully built and supported by license and entitlement management systems. In the absence of strict definitions and implementation standards, software licensed bundles tend "to just happen" with expectations that are typically not met in the entitlement management systems or product design.

Nex time: Looking back on 2009 - what have we learned about Entitlement management and software licensing?

　

How to Get a Handle on Those Pesky Bundles – Establish Bundle Standard Templates

 

By Cris Wendt

Our last blog described many of the problems that occur when enterprise software producers create bundles – a collection of existing software products - usually in an attempt to either create a pricing incentive for users, or, create a more simple method to present a total "solution". The general problem is that bundles tend to be a collection of products put together in a reactionary fashion, and they often lack the underlying product design functionality and entitlement system design to support intended usage-models or business process support that the product manager intended.

To get ahead of this problem, I suggest that companies take a proactive role to create a set of bundle templates that reflect the most common approaches for designing the software bundles to meet business needs. A bundle template is a product structure that is uniquely identified, and has very specific meanings across a number of disciplines. Most companies will require several of these templates to meet their business needs.

This approach ensures an alignment of expectations from the product manager, to sales, and on to the customer on what to expect from a bundle, and the template also establishes guidelines for product functionality and entitlement management system design. Here are the different elements of the bundle templates that need to be considered.

1) Product structure identification

It’s important to standardize on a set of unique names for your bundle templates: do you call it a "bundle", a "package", a "suite", a "marketing bundle", a "solution", etc? There is not necessarily a single nomenclature or a correct name, but what is important, is that when a term is adopted and defined, it has only 1 meaning in implementation and downstream systems.

2) Product descriptions in price books

Each type of bundle has a different description associated with it to help eliminate confusion over possible permutations that can exist. The description should consistently describe how the bundle is put together and intended to be used according to some of the attributes described below.

3) Delivery & Installation

Is the bundle installed as a single unit, or, is it installed as a collection of individual products? Can the bundle consist of products (typically acquired through M&A) be delivered by separate ESD and licensing fulfillment systems?

4) Use-Model

This is probably the most important element of defining a bundle. This describes how the individual products that make up the bundle are intended to be used. Are the products within the bundle inseparable when they’re being used, or, can the products be used independent of one another (e.g. by separate users) once it is installed?

5) Part numbering & ERP View

Is the bundle identified in the ERP and CRM systems by the product part number of the bundle, or, by the part number of the constituent parts of the bundle

6) Pricing

It’s a good idea to create some starting set of pricing rules when bundles are used to promote "solution pricing", such as the following example: "bundle is 30% less than the sum of the individual product prices that make up a bundle". However, this is often the hardest to have hard rules around as pricing tends to be the most difficult element to standardize due to market conditions, and, it tends to be the least troublesome area when creating bundles. Also, you need to consider maintenance pricing and how it applies to the bundle.

Once the desired bundle templates are designed, and implemented across the various disciplines, they become the only options for designing and deploying a bundle. There are no "in-between" ways. But, if the bundles are well designed, there should be no need for any other types of bundles. But, if a need does arise to create a new type of bundle, using a template is a good way to describe what is required to ensure a consistent and successful deployment.

Next time – Bundle Template examples!