Entitlement and Compliance Management

Stop by and see us at the European ISV Convention in London on 25th February, 2010

By: Vincent Smyth

For all of our European followers, later this week Flexera Software will be at the European ISV Convention at the Tower Hotel in London on 25th February, 2010 as a platinum sponsor.  Be sure to stop by and see us along with other leading software vendors, high-tech manufacturers, service providers, systems integrators and solution providers. It is a great opportunity to hear what is going in the software industry and marketplace and join in panel discussions as well as engage in one-to-one business meetings and network with industry peers.

We will be hosting a panel session as well as a couple of boardroom sessions:

• Software Rights Management solutions – this panel session highlights how three different software vendors found ways to increase revenue and decrease costs by using software licensing and entitlement management
• Missing revenue opportunities because you cannot track what licences customers are entitled to? – This “Best Practices” session looks at the areas where software vendors leave money on the table because they struggle to understand what licences their customers are actually entitled to
• Electronic Downloads and Automatic Software Updates - Deliver a better service for everyone – This “Best Practices” session focuses on enabling software vendors to reduce cost, deliver a better service and drive revenue when they are able to identify and address problems associated with manually sending licence keys, software and software updates to customers

Flexera Software’s FlexNet Producer Suite has also been nominated as a finalist in the SaaS category in the IT Excellence Awards which will take place at the gala dinner after the conference.

You can find more information on the event at http://www.isvconvention.com/. We hope to see you there.

Combating Grey Market Abuse - Part II

By: Bashyam Anant

As a High-tech manufacturer, you often struggle with how to cope with grey market activity, and how easily product entitlements can pass from one entity to another. Protecting your products is essential in today’s market. One source of the grey market for your products can often be tied back to abuse of channel incentives by partners, such as misrepresenting or faking end customer information. KPMG notes:

"The grey market has many sources, i.e unauthorized dealers obtain products from a variety of sources normally at a discounted price either due to price arbitrage, abuse of incentive programs, or simply because the products are not what they seem. For example, an OEM may choose to discount products for a particular end customer to increase sales, especially if there is a stiff competition for that customer. To obtain deeply discounted products for open-market speculation, a channel partner may deceive the OEM into deep-discounting products for non-existent customers and then divert those products to the grey market for possibly greater gain. Some brokers may misrepresent themselves in the authorization process and use the resulting relationship to obtain discounted goods that are then diverted into the grey market."

So what can you do?

In our experience, tracking software licensing entitlements (e.g. the name of the customer the device is sold to) as they move through your channel network, along with enforcing product activation is the only sure way to know who the end customer actually is, from who they purchased their products and under what incentive program.

While 51% of high-tech manufacturers collect device serial numbers from channel partners as part of their claims submissions for incentive programs, it is cumbersome or impossible to correlate serial numbers to incentive-eligible end customers till they actually call the manufacturer for technical support. As an example, suppose a manufacturer offers distributors a 10% rebate for units of Product A sold during the month of September. It is difficult to accurately determine actual sales of Product A by the distributor during September. In addition the system is open to abuse (e.g. claiming rebates on serial numbers sitting on the shelf). However, if the vendor tracked software licensing entitlements sold to the distributor and the product activations during September from customers who bought from the distributor, such verification would be easy.

What approaches have you tried? How effective have you found them to be? Let us know!

[1]  Effective Channel Management is Critical in Combating the Grey Market and Increasing Technology Companies Bottom Line, KPMG Grey Market Study Update, 2008

Growing Trend—High-Tech Manufacturers Using Software Licensing to Achieve Customization on Massive Scale

By: Randy Littleson

During 2009 we saw a growing trend from high-tech manufacturers where software became the strategic differentiator for their products that are facing commoditization, but interestingly most manufacturers lack a strategic solution to manage application usage. Only recently have high-tech manufactures begun to look for ways to monetize their software offerings, innovate business and revenue models related to their hardware products, and streamline end customer experience related to delivering, activating and updating products. 

To support that observation, Ubiquisys recently announced that they will be using software licensing  to customize the capabilities of Ubiquisys-powered femtocells to meet the needs of different customer groups. They indicated that their software licensing management system will allow them to—offer reliable customization on a massive scale, allocate and activate software licenses as required to add functionality or adjust offer bundles—all independent of the underlying femtocell hardware. They plan to use embedded software licensing to manufacture “Engine-ready” femtocells, which will enable them to produce fewer hardware variants, increase mass-scale efficiencies and drive down unit and logistical costs.

Ubiquisys is enabling the mass-adoption of femtocells by reducing cost and friction in the supply chain. Their software licensing management system includes a management system to design and administer Femto-Engine licenses, an operations system to create software licenses, a license client in every Femto-Engine software femtocell, and an administration system for operators to allocate and activate purchased licenses.

Are you a high-tech manufacturer facing similar challenges and opportunities as Ubiquisys? How are you planning to differentiate your offerings and cut costs to drive adoption?

We are currently conducting a high-tech manufacturer survey to better understand the unique challenges and opportunities high-tech manufacturers face and we welcome your input.

Combating Grey Market Abuse

By: Bashyam Anant

One of our independent software vendor customers recently lamented, with a resigned tone, that their software products are available at a 90% discount in the Chinese grey market. A grey market arises whenever your products have an exploitable price differential. Grey markets are quite well-known in pharmaceuticals where prescription drugs are purchased at steep discounts in one country and sold at below-market prices in another country. They are known to exist in consumer devices and in automobiles.

For software and hardware products, a grey market arises in many scenarios. For example, unauthorized brokers might purchase your products from legitimate channels at steeply discounted prices and target end customers by undercutting your prices. You might also have a price differential in different geographies to account for purchasing power differences or currency fluctuations, making it possible for someone to buy your products in the lower priced country and undercut your prices in the higher-priced country. End customers are buying products that often have no warranty coverage. In fact, most vendors we speak to find out about the existence of a grey market when customers call them for warranty or support.

From all accounts, the grey market for hardware and software products is growing, especially for vendors that expand into new geographies. A KPMG study estimates the value of grey market goods grew to about $58B in 2007, up 80% cumulatively since 2002 (equates to 12.5% year over year growth). This translates to a loss of $10B of gross profits to grey market sales, which is about 4% of high-tech industry profits. On average, grey market prices are 27% lower than the vendor’s pricing, which eats into profits for both vendors and their legitimate channel partners.

Are you losing profits to the grey market? Can you quantify the revenue leakage? What are you doing about it? In the next article, we provide some suggestions.

_{[1]  Effective Channel Management is Critical in Combating the Grey Market and Increasing Technology Companies Bottom Line, KPMG Grey Market Study Update, 2008}

　

Cloud Computing is Raining Results on Entitlement Management

By: Cris Wendt

Cloud Computing is beginning to deliver results for a software company’s entitlement and compliance management (ECM) solution. It’s also fitting that the company is based in cloudy Seattle.

Too often, I hear of companies wanting to "Create a SaaS Strategy" or "Move into the Cloud" as though by simply embracing these technologies a company is somehow going to achieve some results or reach the Promised Land. So it was refreshing to visit a customer recently who is realizing the benefits of cloud computing because cloud computing was a means to achieving a business objective, and not an end in and of itself. What was especially gratifying was helping the company put the plan in place and seeing it deliver on its promise!

The company is driven by a strong strategic vision of what it means to succeed in its market. They encapsulate some of their vision in the mantra "Freakishly Friendly". They believe that, above all else, the success of their products and business depends upon a very easy-to-use product, and a very "easy to do business with" experience for all facets of the customer relationship.

As we worked with the company, they said that they wanted their entitlement management and licensing and compliance experience for the user to be as "Freakishly Friendly" and as automated as possible. After the initial purchase experience, all activities such as viewing the entitlement status (what did I buy, what’s left, etc), product upgrades, and product updates should be as transparent as possible, or, done with only a few mouse clicks in the product GUI. They wanted to avoid emailing special codes, or, requiring the customer to go to a self-serve portal.

To this end, we connected the customer product to the company through "the cloud." The product calls home on occasion to retrieve updates, upgrades, and new license rights. In addition, software can be moved with a few mouse clicks. All of this is done with both the software company and the customer are able to keep close tabs on compliance. In addition, the back-office entitlement systems are also in "the cloud", ensuring that the high availability and reliability of the entitlement management systems don’t interfere with the customer experience. The result is a total customer experience that is "freakishly friendly"

Oh, and I forgot to mention. We went to visit them because their business was growing at such a rapid rate, and they were looking at new ways to improve their product (with enhanced licensing and compliance management techniques), that they wanted to ensure the the cloud solution could handle a 3x expansion in throughput.

The question for this company wasn’t "how to use cloud computing" but rather "how we can use more?" While some may argue this isn’t pure-play cloud computing, who cares? Results are raining!!

Have you considered taking entitlement management and compliance into the cloud? How do you think it would affect your customer experience and your business?

Software Licensing and Entitlement Management : Some New Twists on Current Themes in 2010

By: Cris Wendt

With 2010 upon us, I thought I’d share some of our field observations about industry trends we see in the field for software licensing and entitlement management. While some of the topics below are certainly well documented, we have been seeing some twists.

From Device Revenue to Software Revenue:

We have been working with more high-tech manufacturers in 2009 and in 2010 who have been traditionally viewed as hardware manufacturers, that is companies who have derived most of their revenue from hardware. This seems especially true in the medical equipment, industrial automation, and the telecommunications industries. As the underlying hardware becomes commoditized, an increasing number of companies are looking at new ways to create more annuity-based revenue streams from software, maintenance, and services. This includes the design of new entitlement management systems to track the deployment and even of their software through complex sales channels to know more about who is using their products

Server Virtualization in Production:

While the general growth in virtualization is certainly no surprise, what did surprise us wasn’t the use of server virtualization per se, but the increased deployment of virtualization into production environments (as opposed to just development and test) as a way to take advantages of technologies such as WMware’s Vmotion to create lower cost business continuity solutions. This trend has also been driven by the improved performance of virtualization offerings.

Evolution & Maturation of SaaS:

Almost all companies we work at are in some phase of planning a SaaS solution to bring to market, if they haven’t already done so. Certainly, many small companies offer exclusively SaaS-based solutions, but what surprised us is how many mature companies are looking to create new revenue opportunities from hosted offerings. This means that simply offering a solution in a SaaS model may no longer be a unique way for startups to differentiate themselves against the more traditional software companies. For the mature SaaS companies who realize SaaS isn’t enough, we’ve been working also with some to evolve their solution to increase revenue through improved authentication, and improved entitlement management.

The Next Phase of M&A:

We see many larger companies creating initiatives to simplify and consolidate product offerings that have evolved through years of M&A. By consolidating complex and often overlapping product lines into fewer, "high impact" products and license models, larger companies are finding it easier to do business with channel partners and customers and simplify the sales process. In addition, the reduction of clutter enables companies to focus development and support on newer generation products.

Interested in hearing more on trends and predictions? Join us on January 28, 2010 as Amy Konary from IDC will be presenting the software licensing and pricing survey findings and share insights during a Flexera Software Webcast.

The inevitable move to usage-based software licensing will have a profound impact on software license management

By: Randy Littleson

In a recent blog post entitled "Predictions for software license management in 2010: Usage-based software licensing models on the rise", I talked generally about the trends we’re seeing in the market related to usage-based software licensing models and cited our recent research report entitled "2009 Software Pricing and Licensing Trends" on the topic. What I’m seeing is that the application market is maturing and historically mature markets have moved to value-based pricing, which for applications is usage-based.　

Whether you’re a software company selling applications to enterprises and/or governments or a high-tech manufacturer increasingly differentiating your products with applications, this trend is gaining momentum and will surely impact your business. I’m hearing this in the discussions I’m having with various vendors.　 Making this more challenging are technology changes like virtualization, cloud and SaaS that are taking place at the same time. These add new wrinkles as most licensing models have not been usage-based and they have been tied to the physical hardware where the applications run. Both of these fundamental software licensing premises are under increasing pressure.

In fact, in my discussions with vendors, it is virtualization that seems to be the key driver today. Users want virtualization to consolidate their computing infrastructure, save money and provide a more dynamic environment to adapt more quickly to changing business conditions. But, from a vendor perspective as noted above, virtualization introduces a host of software licensing and entitlement management implications. Another vendor I spoke with shared the story of how their customers are increasingly looking for "time bound" or "lease for use" (just different terms for usage-based) licensing. Their customers realize that they have peaks and valleys in demand for their applications and don’t want to pay the same rate in a valley as they do in a peak. High-tech manufacturers see the same thing as many products need to be able to dynamically allocate capacity and/or enable specific functionality but only at certain times.

Almost everyone I talk to acknowledges that change is underway. Of course, like all change, this too brings uncertainty. There’s a lack of standards today, vendors struggle with the implications to their business and revenue models (both software licensing models and the entitlement management infrastructure needed to manage their customers’ rights to use the applications), etc. These all need to be figured out, and some are further along than others, but the trend seems inevitable and users are going to continue to push these issues. The question for vendors then is what to do about it?

Are you seeing a growing interest in usage-based software licensing models? If so, what are you doing about it?

　

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!

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).