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?
Comments