Archive for the ‘Software Licensing’ Category
Last installment discussed organizing your content; free or fee.
This time, organizing your customers is the topic. Having a simple, and documented vision for how your customers will interact with your ESD system is a critical step in ensuring the long-term success of your program. The foundation of this vision is organizing customers into groups based on how you expect them to use the ESD system.
This is not a market segmentation exercise, per se. What we’re talking about here is use-models. From this perspective you can segment users along the same lines as your content; those who don’t know what they want, and those users who are coming to get what they are owed.
How many of your users will be browsing though your content library, undecided on what files they need or want?
How many are looking to get in and out of your ESD site, as fast as possible, with exactly what they already paid for?
Are your buyers and your users the same people? If not, how will the people who buy your content distribute those assets to the users?
Are the bulk of your users individuals (B2C type) or will you have multiple users per corporate account (typical B2B scenario)?
The only wrong answer in this process is to say “all of the above, equally”. That is a cop-out, and a sure path to disappointing results. Your ESD program needs a defined primary audience and user community. Pre-sales serving of free content, and post sales fulfillment of orders cater to different users at different stages in their relationship with your company. Decide which will be dominant.
Organize your ESD project around how your customers are categorized as they interact with your business. Trying to service every type of customer interaction equally, much like the keychain above, will to lead to a heavy ESD deployment and leave a big hole in your pocket.
Once your new ESD infrastructure is in place, who is going to use it?
If you are about to answer “customers”, don’t bother. That response too easy and too broad.
The list of users that we create in this step is different from project stakeholders. A User is one who will engage the features and functions of the system on a routine basis (double your bonus points if your stakeholder list includes real Users).
Who is responsible for the final approval to “ship” content?
Who manages the part-numbers that for sale and distribution?
Who will submit the files to the public-facing tools?
Who is responsible for creating and approving accounts?
Who are the customer service personnel that will support the process?
List the users, and make sure to add their backups. Plan to involve this group in planning, testing, and post launch audit meetings. As these are the folks who will be using your ESD tools each day or week they are your internal user community. These are the folks getting your product to your customers today, and bearing the burden of any antiquated processes, so its extremely important to bring each of them tangible benefits with your ESD project.
Use whatever is comfortable, including the analog pencil and paper. The format doesn’t matter. Ignore buzzwords like UML, Flow, Process, BPM, etc. and ignore getting sucked into fancy diagramming tool choices. Draw the picture however you are comfortable. The diagram will change, guaranteed.
At OMS we go back-and-forth between system diagrams and activity diagrams.
Here’s an example of an activity box diagram we use to help get lubricate conversations about ESD.
Plan == Create == Build == Manage == Release == Entitle == Distribute == Support
The objective of this step is simply to outline areas of focus that are important to achieving the business outcomes you desire. This is not an implementation checklist, that will come later. This is the umbrella sketch of things your organization will think about (and do) that impact your digital distribution project.
If you prefer, you may wish to sketch the system, or infrastructure for your project. Inside the firewall, staging, testing, Customer facing, Partner facing are four good starting boxes. In other words, the where instead of the what that you will ultimately use. Again, don’t worry about what it looks like, just get it down on paper.
It make no difference, at this point, whether your perspective is process (what) or system (where). Just start drawing. You’ll find that these pictures will become the most used and discussed tools in your ESD project toolkit.
In the past few weeks I’ve been in quite a few meetings with software companies talking about electronic software delivery. And here is the deal: We can predict the degree of difficulty in forming a mutually beneficial operating partnership with you by asking one question, “A year from now, what successes will be be celebrating”?
Sidebar commentary: Inquiries we are receiving about ESD are up in 2010, in part thanks to our marketing efforts (thanks Darci, Charissa, and Chris!) but also because more companies, spurned on by the 360 business reviews of 2009, are looking for every advantage, and they are now getting to Delivery.
I never get tired of asking that question, or the responses it provokes. After more than 15 years in the business of helping high-tech companies get their products into the hands of their customers, going all the way back to the floppy disk days, the answer to this question (or the lack thereof) is the most important and most telling.
Your definition of success must be in place before you start your electronic software delivery project.
As much as I dislike the one-size-fits-all implications of “best practices” language, this one-time, I’ll concede. Too often we hear the “our customers are asking for it” response. While the customer demand is undoubtedly true, I can almost guarantee that your CFO won’t fund your initiative based on that justification.
Here are some real, quantifiable, definitions of success that have been used by some of our customers, in no particular order:
Reduce per unit costs versus physical shipping.
Accelerate revenue recognition.
Decrease call frequency and duration to customer and technical support.
Capture metrics on adoption rates for use by sales, marketing, engineering, etc.
Eliminate costly, repetitive, manual processes.
Provide quantifiable sales/import/export tax advantages.
Comply with (enter jurisdiction of choice) export regulations.
Re-allocate talented individuals to core business tasks.
There are more. Not all are necessary. Your objectives are for you to define. But, define them you must. The single most important “best practice” in ESD is to set your goals, up-front, and with conviction. Because, as many of you might already know, your ESD project will involve many more stakeholders and participant than might readily be apparent. You’ll need these goals to keep everyone on the same page, and to make sure you have something to celebrate.
We had another discussion today on the differences between entitlement and enforcement in software licensing schemes.
Here is an image we have used to draw the distinction from our perspective.
We’ve developed our systems to enable publishers a high degree of control over the entitlement of software and technology. Preserving flexible entitlement choices for publishers eases some of the burden on downstream enforcement tools in a number of business scenarios.