Entitlement and Compliance Management

Beware: “All-You-Can-Eat” Software Licensing Can Give You Indigestion!

By: Jim Geisman, Software Pricing Partners

Whether you call them "enterprise-wide", "site license", "all-you-can-eat", or "strategic", all involve unlimited software license use in one way or another. If you are involved in these unlimited software license deals, no matter what they are called, you may be leaving a lot of money on the table unnecessarily and as a result, suffer from chronic indigestion.

Of course, it is always better to do the deal, and get the cash, than to leave money on the table. But if you are going to do the deal, either get paid the amount YOU think is fair or make sure you get something in return. An unlimited software license doesn't have to mean an unlimited everything-else deal.

When a prospect asks for an unlimited software license deal, price isn't the only response. Recognize there are many dimensions to a deal so look for ways to pull out value and costs to make sure the money you receive is in line with the value your software delivers.

Prospects wanting unlimited software license use shouldn't be given a perpetual license. Unlimited perpetual license deals limit a vendor's upside to add-ons. Instead of a perpetual license, consider using a limited-term license, a.k.a. subscription license. If you are going to get "hosed" make sure you know how long that situation will continue. Even all-you-can-eat buffet restaurants aren't open 7/24, 365 days a year.

Don't rely on maintenance and support fees (M&S) associated with the unlimited perpetual license either. Make sure M&S is priced correctly based on the level of support and the maintenance hassles you might encounter. The typical "X-percent-of-license-fee" may not even cover your costs.

If you get squeezed in M&S, consider reconfiguring your traditional maintenance and support offering. Can you offer second level support? What about per-incident pricing with a guaranteed minimum? As for upgrades and product updates, forget about them – updates maybe – but upgrades are out.

Another way to deal with all-you-can-eat unlimited software licenses is to extend the range of volume discounts.

Suppose a multinational company wants to use your products in multiple subsidiaries and multiple locations within each subsidiary. To make sure you are being paid fairly, develop a discount structure that will encourage customers to pay fairly.

Start with a volume discount schedule that maxes out at a reasonable (large) number of users. Offer a site license price that is beyond the maximum number of users. In addition to the site license price, offer multiple-site license prices that are also suitably discounted. Then provide an enterprise-wide license price that is beyond the multiple-site license discount schedule and is an amount you would accept.

Even if the customer is unwilling to pay what you ask, you have provided a framework for establishing a price you think is fair while offering the customer less costly options.

But frankly, we've found no one is really empowered to do an enterprise-wide deal especially in a huge multinational company. Sometimes the enterprise-wide deal is a way to avoid license administration. If that is the case, either make the administrative tasks easy or do the work for the customer if you can. In general, though, a request for an unlimited deal is really just part of the negotiating dance and the more you have heard the music the better you can dance.

Regardless of how you configure the unlimited deal, make sure you are gathering information about software license usage even if the customer is paying a flat fee. It is essential to gather usage data so you know what an unlimited deal really means and what it is costing you so you use this experience to price other deals appropriately and, possibly, avoid unlimited deals altogether.

We've described a few ways to deal with "all-you-can-eat" software licensing deals. How do you respond to your customers or prospects who want them?

Jim Geisman is a guest blogger on Flexera Software's Entitlement and Compliance Management blog. Jim is the founder and principal of Software Pricing Partners, Inc. He provides senior management counsel, marketing and sales consulting services and workshops. Learn more about upcoming workshops (including the one after SoftSummit 2010).

Reaching New Markets with a Metered Software Licensing Business Model

By: David Znidarsic

What do you do when the high-end market for your high-end software product or high-tech intelligent device starts stagnating? Throwing more capabilities into your existing product to lure existing customers to upgrade might not do the trick. You might have to appeal to prospects in lower-end markets, some of which may be your former high-end prospects.

Should you Discount?
Luxury brand owners have known for years that you can't just reduce the price of your high-end product to reach lower-end prospects. Your high-end customers will get wind of that and demand the same discount, or worse, shun your brand because your reduced priced also reduces your product's perceived value.

Should you Retool?
If you can't change the price of your product to reach lower-end markets, then you have to change your product, but how? Lower-end markets may indeed have unique needs that cannot be satisfied by your existing product or even by a derivative of your existing product. If this is the case, then you have a much harder decision regarding the direction of your business. However, often your lower-end prospects today aspire to be your high-end customers tomorrow. They currently need all the capabilities in your high-end product, but can't yet afford it. So even as they acknowledge that your current product is out of reach for them, they would like to see a straightforward path that gets them from where they are today to where they aspire.

Should you Offer to Lease?
Leasing of luxury items has long been a way to reach lower-end markets without discounting or retooling. Here are two metering options to consider when considering leasing: by time and by usage.

• Meter by Time – Some of your lower-end prospects may value the ability to use as much of your product as they need within the lease period. The pricing of the meter by time will be based on the assumption that the customer will be heavily using your product through the lease period. When the lease period ends, your software will be controlled with an expiring electronic license that is enforced by the software itself.
• Meter by Usage – Some lower-end prospects won't be using your product continuously, so will want to extend the lease period. However, an extended lease period may be too expensive for them. These prospects will want to pay for only the amount of your product they actually use regardless of how long they possess your product. The payment for this type of model can range from pre-paying for a specific amount of usage, to post-paying for the amount of actual usage, to putting down a deposit toward the eventual post-use payment.

Defining Usage
A key component to metering by usage is the ability to define usage in a way that is satisfying to you and your prospects. After all, prospects that need such fine-grained pricing will scrutinize the metric to which their price is tied.

Your pricing metric can be based on transactions processed by your application or time spent using your application. If your product offers very discreet units of value to your customers, say, number of tests performed or number of gigabytes processed, then those would be ideal metrics to base price upon. However, if your product doesn't offer such discreet metrics, metering based on time spent in your application is the best option.

Here are some other considerations as you try to define time spent using your application:

• Is application idle time counted as usage?
• Is the time the customer is navigating menu items counted as usage?
• Is one second of usage rounded up to one hour of usage?
• Is thirty minutes and one second of usage rounded up to one hour of usage?
• Is only sixty continuous minutes of usage considered one hour of usage?
• If, say, twenty minutes of usage is immediately followed by, say fifteen minutes of usage, but both within the same hour, is that two (rounded up) hours of usage, or added together (then rounded up) to be one hour of usage?

Regardless of whether you choose transactions or time spent in your application, you will have to have a pricing policy in the event a bug in your software renders useless the transactions or time spent. Do you offer full credit? Partial credit? Refund? Neither?

Get Help
Once you have established the lease model you want to offer your lower-end prospects, you may need help managing this entire process in an automated fashion. Application usage management technology can help you process, monitor, and enforce whatever lease model you offer to your prospects.

                                                                                                                                        

Software Entitlement Management & the Compliance Burden of Proof

By: Cris Wendt

If you buy software licenses, you will probably be presumed guilty until proven innocent for ensuring that you are using software in compliance with your software license agreement. The burden of proof of evidence is place upon the user of software. If an audit occurs, you somehow must match the deployment and usage of software to some combination of documents to show entitlement rights.

However, if the burden of proof were placed on the shoulders of the software vendors, then the story may be different. This is especially true in the world of B2B enterprise software.

As a colleague of mine once said, "compliance is like the sound of hands clapping – one hand is usage reporting and software asset management from the customer, while the other hand involved in the clapping represents the software vendor's entitlement management systems." In most cases, the hand representing the software vendor's entitlement management system would be missing, or at least missing a few fingers.

Many software vendors will readily admit that their records of what software licenses customers are entitled to use are so bad, that they often call their customers to find out what the customer should own. In fact, I think that every software vendor over $1M in annual revenue has dirty data in their entitlement management systems.

How can this be? There are several problem areas that seem to contribute to an ever-worsening situation. Below are some of those problem areas:

• Non-standard agreements with little auditability: Many software vendors derive the lion's share of their revenue from large ELAs (Enterprise License Agreements )– deals designed to meet the specific needs of their customer, but they are often non-standard in nature and include many terms that cannot be tracked without spreadsheets, and knowledge inside of people's heads. One example is the "remix" – an approach to allowing customers to remix their licenses annually, based upon a formula that involves the list price of the software, and, the percentage of the total software purchased.
• Fuzzy license models: Some software vendors sell concurrent licenses, but aren't clear on the distribution of those concurrent users – are the users all local to one building, or, can they be dispersed geographically? The issue arises when licenses are being used on a worldwide-basis (24 hour usage), but the pricing intent was for the licenses to be used locally.
• Product packaging changes: Over time, software entitlements change because the underlying software product packaging changes. As the result of M&A, market re-branding, or end-of-life processes, customers may be "migrated" from one set of products to another, using a method that is customer friendly, but difficult to track or audit in an entitlement management system.

• Using ERP systems as entitlement management to track license rights: ERP systems were designed to track the manufacture and delivery of physical goods. Upon delivery, the product is shipped, and the role of the ERP typically ends. With software, the trouble usually starts after the software is delivered, as exact mix and version of software, including who exactly is entitled to use the software evolves over time due to upgrades, updates, moves, M&A, and product repackaging. Over time, software vendors often lose track of which customer is entitled to own a product. A true entitlement management system is needed, and must be properly integrated with an ERP system to effectively manage software entitlements.

Next week – How to approach improved entitlement management…

Software Licensing – Pricing the Concurrent License

By: Cris Wendt

The most predominant license metrics used today for most enterprise software are either a named-user or machine-locked license. With the named user license metric, fees are applied typically by the name and role of the user accessing a set of software functions. This is often used with enterprise CRM or ERP software. With the machine-locked license, fees are applied based upon usage on a particular machine. These metrics are typically used with traditional desktop software deployed throughout the company.

Another type of license in use is the concurrent license metric, or, the case where license fees are paid based on a high watermark – the maximum number of users that can access the software at one time. This is sometimes also called a "floating license" as the license rights are in essence, available or floated among users provided one is available (e.g. they haven't all been checked-out). This typically requires some license management technology, and works well in large environments where a large number of users access the software, and the administration of managing a large number of named users or node-locked software deployments becomes overwhelming.

Concurrent licenses are often adopted by software producers that start with a named-user license or node-locked license metrics. There comes a point where there is a need for simplicity, and a concurrent license meets the need. In addition, the availability of software in a concurrent license model promotes deeper account penetration by allowing additional users to "test drive" the software.

The trick is – how do I price the concurrent license? Since more users can potentially access the same "amount" of software when it's made available in a concurrent method, the software producer wants to ensure that they don't lose revenue. Certainly, if the software is providing more value, then one can argue that the software producer should make more money than before.

An effective approach is to evaluate software usage for a single license with the existing metric, and then determine usage in the concurrent. From there, pricing can be multiplied by the increase in usage as a starting point. For example, let's assume that a software producer sells a desktop productivity perpetual license for $100, and also that the software is used on average 2 hours per day. For a reasonably large deployment, one can assume that the software license will be used 8 hours per day as all users in a particular site will have access to the software (4 times the usage, and presumably, 4 times the value). This suggests that concurrent license should sell for $400, or, close to that price. Of course, market testing may suggest a slightly lower price. In real world experience, I have seen the software license sold with the concurrent license metric priced anywhere from 25% higher than a machine locked or named user license, up to 400% higher. The method used above was part of the process used to establish the concurrent license price.

Now, let's assume that the software producer is selling to an enterprise that has a worldwide presence, in which case the software might be used "around the clock". In this situation, the software license that was only used 2 hours per day may now be used 24 hours per day. This is 12 times the usage, so perhaps a price of $1200 may be needed. Again, the actual price will probably not be so extreme.

What's nice about offering the concurrent license is that it doesn't have to be the model license metric, but it can be part of a larger portfolio that enables more flexible pricing and license for different types of customers. One can offer a machine locked license for individuals, a campus-wide concurrent license for SMB accounts, and, a worldwide concurrent license for global accounts.

Next week: SaaS is More Than a Software License Model!

Increasing preference for more choice and flexibility in software licensing

In this video interview, we sat down with Amy Konary of IDC who shares findings from the Flexera Software 2009 Key Trends in Software Licensing and Pricing Survey. The survey, found that enterprise customers are demanding more software licensing flexibility and options.  This creates multiple challenges for software vendors - this comes at the same time they are trying to reduce complexity and simplify SKUs and it raises questions of whether their back end software entitlement management systems support such flexibility.

 

 

Disparity found in software licensing preferences

 

Reflecting on joint research done last year between Flexera Software and IDC, Amy Konary speaks about the survey results that found a disparity in software licensing enforcement preferences between software vendors and their enterprise customers.  This disparity represents both a risk and opportunity for software vendors as they seek to balance their own business objectives with the demands of their customers.  Amy shares insights from the survey and her own experiences dealing with software licensing issues with both software vendors and their enterprise customers.

 

 

Why Is Software Licensing and Device Lifecycle Management Important to Medical Device Manufacturers?

In a recent article featured in Design Manufacturing Services, David Znidarsic, Vice President of Technology at Flexera Software, explores electronic software licensing management, a simple solution for medical technology manufacturers that can ensure regulatory compliance while delivering a host of additional benefits, including simplifying how companies bring their products to market and ensuring they can maximize their revenue.

Here’s a snippet of the article…

As healthcare facilities rely on an ever-growing population of medical devices controlled by FDA regulations, ensuring compliance becomes an increasingly complex challenge. At the same time, manufacturers have begun implementing more of their key features through software, turning these hardware providers into software companies that must confront issues related to software product lifecycles, version control, and software pricing. Meeting these challenges, however, should not require a massive administrative and operational effort.

The article goes on to talk about:

· The Changing Industry

· Electronic Software Licensing to the Rescue: Three specific benefits for medical equipment manufacturers

1. Compliance

2. Feature control

3. Multiple device identifier types

· Electronic Software Licensing in Action: Three Use Cases

1. Compliance

2. Capabilities

3. Generating Revenue

· Looking for an Electronic Software Licensing Solution

Read the entire article -- Managing Compliance and Software Lifecycles for Medical Device Manufacturers.

What other types of intelligent (embedded with software) devices do you think would benefit from software licensing and device lifecycle management?

Software Licensing Revolutionizing the Appliance Market—Take 2!

By: David Znidarsic

In my recent blog post -- Software Licensing Revolutionizing the Appliance Market – I talked about how software licensing models are helping high-tech manufacturing companies transition from low profit products to high profit successes.  I shared how many device manufacturers are now in the software business or how they want to be in the software business.  In my example, I talked about a networking company who has been in the business of selling blade servers and their desire to get out of the business of sourcing hardware and moving to virtual appliances, but didn’t mention why they wanted to do that.

Here are some more details on what is driving this transition.

If the manufacturer allows their customers to install and configure their software on hardware chosen by the customer, the manufacturer will be forced to accept the technical support responsibility for diagnosing mis-configured deployment environments—which could result in higher support costs. Virtual appliances greatly reduce this possibility by not only allowing the manufacturer to pre-install and pre-configure the machine, operating system and software stack, but also allows the manufacturer to lock-down the configuration of the virtual appliance (for example, with VMware’s ACE tools).

The manufacturer explained that their customers often buy general-purpose hardware in greater volumes than the manufacturer, so the customers can get better hardware discounts. Here is an example, say the manufacturer buys general-purpose hardware and pre-installs and pre-configures the operating system and software stack, then resells both as a unit. If the manufacturer pays, say, $1,500 per unit for the hardware; they must fold that cost into the bundled offering. However, if the customers can buy that same general-purpose hardware at, say, $1,250 per unit, they are often willing to install and configure the operating system and software stack themselves in order to save 17%. However, for the reasons mentioned above, the manufacturer doesn’t want to lose control of the deployment environment, so delivering a virtual appliance instead of an installable software application is a good compromise.

How are you redefining the way you do business? Are you moving to virtual appliances?

In the meantime, want to learn more about how machine virtualization impacts your business—join us for our upcoming webinar on May 26th. Hope to see you there!

Will SaaS finally be the tipping point for Pay-Per-Use Licensing?

By: Cris Wendt

Pay-per-use software licensing has been on the minds of a lot of people these days, including industry analysts. The thinking on how a pay-per-use model works with traditional software is that as users leverage the software, the usage information is gathered on the customer premise, and sent back to the ISV frequently. The ISV then analyzes the usage information, and pricing is applied. In addition, there is a wealth of analytics that can be gathered by the ISV.

A few times, our blogs have touched on why pure-play pay-per-use license models will not appeal to traditional software vendors (cost of the infrastructure implementation and unp redictability of payment), and how some software vendors have remediated these issues with alternative models that balance the flexibility of use of the pay-per-use model with the predictability of more standard license models. Some of these hybrid models are known as remix, subscription with rental option, or token models.

However, the wider adoption of SaaS models may lead to the adoption of more pay-per-use models. When I hear people describe how they would like a pay-per-use model to work, the explanations include: "just like a cell phone plan based on minutes of use" or "just like a water or electricity model". A major reason why a pay-per-use model works for utility companies is that the utility company controls the provisioning of the service That is, the service being provided actually flows through the utility provider where its usage can be monitored. It's an artifact of the way the service is provided (although some may argue that the use of meter readers offsets this argument a bit).

Controlling the provisioning of the service is exactly how software is consumed in a SaaS model. The software service flows through the SaaS provider, where its usage and consumption are easily metered. And as SaaS deployments continue to proliferate, we are beginning to see more licensing models based upon usage consumption (MB of storage, # of transactions, etc.). This is also partly due to a situation where expectations for consuming SaaS software are different than traditional software, so customers and ISV's may expect to utilize a different business model where some unpredictability is acceptable for some time.

Software pay-per-use, on the other hand, rely on data gathering and reporting mechanisms to frequently transport usage logs from the customer environment to the ISV in order to apply pricing. And so far, the value proposition hasn't been sufficiently compelling to adopt these more complex mechanisms for traditional software license models.

While the argument for the cost and method of deployment may not be the most compelling issue for why pay-per-use licensing isn't widely adopted, it is probably the tipping point issue.

Stay tuned for more on SaaS and pay per use software licensing blogs. In the meantime, interested in learning more about the impact of machine virtualization on your business? Register for our May 26^th interactive Webinar entitled: Machine Virtualization—Is It Impacting Your Software Business?

SaaS Software License Models – Can Traditional Independent Software Vendors Adapt?

By: Cris Wendt

Most SaaS companies sell access to their SaaS software with some form of named user or managed capacity metric, using a subscription license model. In these license models, software access is sold based upon the amount of access to the SaaS offering that is being used. Customers are then invoiced monthly or quarterly for access. Revenue is "recognized" accordingly – on a periodic basis as the SaaS service is being consumed. Since SaaS is really a service, that type of licensing and pricing model makes sense and works well. This creates a recurring revenue model that grows over time as the SaaS offering gains market acceptance. This is more of a "farmer model" to growing revenue, and works well for companies who are pure-play SaaS providers.

The real challenge is for traditional Independent Software Vendors (ISVs) who sell their software using a perpetual license model. For these companies, their business is built for the accounting model of recognizing their revenue up-front, at the time the software is booked. For these companies, there is a large infusion of revenue that occurs, typically well in advance of the software being operational and productive. The financial model, Wall Street expectations (for public companies), and internal sales and management compensation models are built for these large bursts of revenue as deals are signed. This is more of an "elephant hunting" model to revenue creation.

I see the difficulty many ISV's have in changing this model even for adding simple subscription license models to their offerings. I've seen the subscription offering fail because sales compensation was not aligned with the recurring revenue model. Individual sales compensation plans were based on an "elephant hunting" model. Even in cases where more sophisticated time-based models were offered, there was often dysfunctional behavior to structure the deal in such a way that more revenue could be recognized up-front.

The real question with a SaaS offering for traditional ISV's isn't so much that is it technically possible, but, can the organization really adapt and adjust the business model?

So, how does a traditional ISV succeed in providing a SaaS offering? Clearly, some companies have succeeded. Usually, they follow a few simple principles that also apply to rolling out a successful subscription model:

• Use the SaaS offering to initially grow or develop a new market opportunity, where the overall revenue impact to existing revenue streams are not large, and, where there are incremental revenue opportunities.
• Align sales compensation with to the new model. In some cases, a different sales channel may be required. This may work well if the SaaS offering targets a different market.
• Consider creating a new business unit with its own P&L so that it can be isolated from the pressures on the mainstream business.
• Be patient, grow, and learn.

Do you have other approaches to bringing a SaaS offering to market?