 |
 |
 |
 |
|
|
|
|
|
Bill Weir Abstract This whitepaper is an exploration of the current Application Service Provider landscape. The author pays specific attention to the transition people are making from the legacy business model of Independent Software Vendors to the new ASP model. The ASP model is defined. Early analyst projections are compared with current reality, and an explanation is offered for the model’s failure in some sectors. The primary reason for early failure is cited as the newness of the model, which needs clarification. A framework is offered for such clarification. Suggestions are made for those considering the launch of an ASP service, and for those moving from the ISV model to the ASP model. A brief discussion of the future of the ASP landscape suggests that many businesses will fail, and that for those who remain revenue models will change. The Author Bill Weir is the President of Outsource Advice, Inc., a consulting organization that specializes in ASP service deployments and transitions. His primary project at Outsource Advice has been to deploy a medical imaging service for Radvault Inc. of Hayward, California. Before Outsource Advice, Bill co-founded Personic Inc., a leading provider of applicant tracking solutions to the Human Resource industry. Having led the Operations organization there he deployed an ASP version of Personic’s Workflow product. Bill has worked with database applications since his graduation in 1985 from the University of Kent at Canterbury, England. Introduction The ASP business model has been an important development as the business world redeploys functions and processes on the Internet. Email showed us a new way to communicate. Web sites showed us a new way to distribute information. Then it became clear that functions could be distributed and business models could be rewired. What if the word processor you installed on a thousand workstations only needed installing one time –somewhere out there on the Internet- and someone else took care of it all for you? What if you could have it all on a subscription basis instead of having to pay huge license fees? A new world of possibilities has presented itself. In this white paper I’m going to define the term ASP, tell you what people are doing with it right now, talk a little about the challenges you may encounter starting up an ASP, and share some hunches about the future. What do we mean by ASP? An ASP serves an application to its customers over the Internet. Take an application you currently run. Imagine that you no longer have it on your computer. Instead, it’s running on another computer in a data center somewhere. Instead of running the application the way you always used to you open up your browser, go to your service provider’s web site, log in and it’s right there inside your browser. That might be an application that looks like a web page or it might be a regular Windows application. That’s what ASP can be. But people have different ideas of what ASP means. Some people think that providing Internet access makes them an ASP. Some people think that providing a data center makes them an ASP. Although they’re not ASP’s in themselves, they are suppliers to ASP’s. In my mind, the ASP is the one who supplies the application, the one who the customer pays and the one who the customer calls when something goes wrong. What is meant by the ASP “Business Model”? Now we know what it looks like to serve up an application on the web we need some clarity about what’s necessary to do it in the context of a business. Application Service Providers provide a contractual service offering to deploy, host, manage and rent access to an application from a centrally managed facility. They are responsible for either directly or indirectly providing all the specific activities and expertise aimed at managing a software application or set of applications. Of primary value for the customer is the fact that they can concentrate on their core competency instead of on the administration of a technological infrastructure. There are five emphases to consider: The model is application centric ASP’s provide access to -and management of an application. The value that a provider brings is that of facilitating a high-level business function. As a result, follow-on sales opportunities may have particularly high value. For example, a provider may offer application compound usage statistics from a community of peer businesses. The service is one-to-many It is critical to understand that the ASP business model only really works if there are a small number of defined services; preferably only one. IS outsourcing, application management services and traditional hosting are –by contrast- one-to-one services having each solution deployed to meet a unique requirement. The business models are very different. The service is centrally managed ASP Services are managed from a central location instead of at a customer site. Customers access applications remotely over the Internet or leased lines. The “outsourcing” of technical and application-level administration can prove a strong incentive to the customer. The product is not software, it’s access to software The customer doesn’t buy the application. They buy measured access to it. Contrast can be drawn with traditional applications management (AM) services: the customer already has acquired and deployed the application environment and the AM assumes responsibility for its management, sometimes bringing that environment to its own data center. The provider delivers on the contract The ASP is responsible for delivering on the customer contract, ensuring that the application service is provided as promised. ASP services will often involve several partners. If a problem arises however, it is the ASP that is responsible for closing the loop on the trouble ticket, even if the ASP works with other companies to provide the actual support. This can be seen as another significant incentive to customers and a corresponding headache for providers. What’s going on with ASP? A recent Dataquest projection shows industry worth at $23 Billion by the year 2003. The reality has turned out to be different. ASP appears to be under-performing. In my view the short-term projections were too generous, but we can expect the segment to perform at least this well in the medium term. Applications continue a broad march to the Internet. Did you trade stocks, buy CD’s or make travel arrangements online in the last year? Probably more so than in previous years. Some online applications have failed. Some have succeeded. Revenue is harder to generate than had been expected. The big question is; "Why has it been so hard?" In the hurry to get people up to the foothills where the veins of gold run from the mountains we paid no attention to the design of their transport. We hammered together rickety horse-carriages. A good number of them broke into pieces on the way to the mountains. If we had paid closer attention to business requirements and infrastructure more people would have arrived at the gold mines of increased productivity. But most couldn’t wait. Newness In the blind rush to the hills we should not forget that this movement is revolutionary. We’re not only introducing technologies; we’re introducing new ways of doing business. Here is a list of just a few things that are new: a) The revenue model: If "business as usual" for an ISV has been to sell a software license to a customer for $100,000, their revenue from the same customer is $5,000 per month (depending on the revenue model). That does radical things to their P&L. It’s great for recurring receipts beyond year 2, but what about year one? b) Market position: In light of the fact that the list price looks like it’s been slashed, has the provider moved down-market? Is it a business opportunity? They need to know, and so does their bank manager. c) The customer service model: Three words; “it’s your fault.” And it really is, even if it isn’t. The provider is only going to succeed if they can manage their infrastructure suppliers on behalf of the client. Further -on service levels- providers are now held to a service level of 99.999% availability. Why is that when the customer always used to be satisfied with 90% availability? Because now they’re seeing real currency leave the bank account each month. They never saw it when it was a line item buried in an internal P&L. d) Technological infrastructures: They’re difficult. If an ISV has been focused on providing application functionality it’s harder than they think to deploy hardware in a data center. Uncertainty Some providers have been so busy building carts that they’ve forgotten why people want to go to the mountains. It’s important to be able to answer the question “Why does the customer want this?” Is it because it’s cheaper for them? Is it because they want to focus on their core competency? Is it because they’re having a hard time hiring? Providers have also been technology driven. Just because a new technology has arrived doesn’t mean it’s useful. Again, the customer is king. Challenges becoming an ASP So you want to do this? Here are my recommendations for those wishing to become an ASP. They’re all –arguably- obvious, and all difficult. Make something people want Take market research seriously, and be open to the possibility that people don't actually know what they want. Remember that the product isn't only a technical entity; the customer will want the right product at the right price. Also bear in mind that this is a service, not a product you can ship and forget. Make something that works Architect the solution correctly. Plan for success, so plan for a deployment strategy that can work big as well as small. A large part of your product is contingent on the quality of your staff, administrators and support in particular, so; Hire the best people you can The human factor is an interesting aspect of the equation. The ASP’s customer often outsources a service because of their inability to attract good staff to support their own implementation. The very same factor can draw good technicians to service providers; technicians are more likely to be drawn to the scale of a challenge involving multiple deployments in one place. It is important, of course for the ASP to hire good people to manage such a significant installation. Make a revenue model that works Take pricing seriously: You’re going to need to derive a model for the service that’s acceptable to the customer; don’t merely divide the cost of a traditional license by 36. Don’t forget the scale of support operations, in particular. And after the recent dot-com cycle, do I need to remind you to make it profitable –sometime? Further challenges for ISV’s becoming ASP’s As if the challenge weren’t hard enough -starting from nothing- try becoming an ASP if you’re already an ISV. It’s like making a television from auto parts. Make believers You’re going to have the hardest possible time implementing a service if the rest of your organization hasn’t bought in, so the project must be supported from the top. But support is different from belief; you will need to win over the hearts of everyone who will be involved. Establish a compensation plan that Sales can believe in: Put yourself in their shoes, would you want to switch from a plan that awarded an up-front 10% of a $100,000 license sale, to a monthly annuity at 10% of $5,000? This kind of transition requires belief, not mere compliance. Develop a whole new plan for technical support; their clients are going to become much more demanding. If your support group is merely processing support requests, it’ll need to learn how to take ownership of customer issues instead. Your accounting group will need to establish new billing procedures for these customers, and you’ll need to convince them that it’s a good idea to increase their paperwork by a factor of ten. Re-deploy your professional services group. Your deployment strategy is now one-to-many and having people around who can respond to customization requests could well become your undoing. You may need to make severance agreements instead of believers here. Redevelop your application One key benefit of the ASP model is that many deployments of an application can be managed centrally, introducing an efficiency that cuts the per-deployment maintenance cost. Another way of thinking about this is that the move from multiple deployments to a centrally managed deployment can introduce a revenue opportunity for the provider, who claims at least part of the efficiency improvement as margin. Sharing a deployment is the primary way of creating generating efficiency. Typical ways to do this are; locate all deployments on a shared server, locate all data in a shared database, include all backups in a shared regime, and use common administrative staff. The revenue facilitated by efficiency gains is jeopardized if the application being served is architected in a way that simply cannot be shared. For example, an application that uses an Oracle database, but which has no data fields to indicate the ownership of that data, cannot host multiple customers. A shared deployment requires that multiple databases are built and each customer gets their own. Whilst Oracle allows this, a measure of efficiency gain has been sacrificed. Rather than work around such issues, it is wise to change the product so it can genuinely be shared. Of course, ensuring reliable data privacy requires some care. The “web native” debate An application may be considered “web native” if it can interact directly with the common web browsers, without using any special downloads or plug-ins. Typically this means the application uses HTML or Java. A provider is not compelled to provide a web native application. Microsoft Terminal Server technology can be used, for example, to host Windows sessions within a browser. Although not required, web native applications are preferred for two reasons: a) It is substantially harder to share non-native applications, and this has an impact on the service’s profitability, and b) Customers will often judge web-native applications to be superior. RFQ’s for such systems often specify that the application be web-native. Customer Management After devising the theory of a great value proposition you need to define the value proposition on paper for the customer. The key is to define a Service Level Agreement, and the more comprehensive this is the better. Include uptime guarantees, penalties and escalation paths. Include the procedure you will follow in the event of system failures: the customer actually cares about this more than any service rebate you may award. Since the customer will hold you responsible for everything they possibly can, be sure to draw clear boundaries about the things that remain theirs, and set expectations about what happens when your suppliers fail you. Deploy a customer management information system in-house. Make it available to Customer Service, Sales and Accounting departments so they can effectively share important information. Deploy a comprehensive metric gathering mechanism so you can accurately represent your service levels. Suggestions for an ISV becoming an ASP If you have an existing software offering and you’re looking at providing it online, the school of hard knocks makes the following recommendations: Avoid model muddle Differentiate between in-house and ASP offerings. Some people prefer to keep their applications “in-house,” retaining control over their administration. If you’re going to offer this option as well as an ASP solution you’re going to need to be clear what the differences are, and under what circumstances you’d recommend each. Also be ready to define the difference between an ASP deployment and a financed in-house deployment because they look very similar to the customer’s CFO. Focus on customer requirements Focus on what do customers want instead of what can be done technically. What will your customers pay? Buy into customer education Many customers will simply not understand the ASP business model because it’s so new. They may not even know they don’t know what ASP is. It helps if you think of this as an exercise in building customer loyalty, or as first mover advantage. Capitalize on ASP benefits and find value-adds Do things that the customer wouldn’t or couldn’t do if they were implanting their own system in-house. You might want to automatically report usage metrics. Some value-adds can be generated by the new proximity of multiple deployments: How about ranking your customers against each other? How about offering third party professional services as standardized packages? You will be able to get better terms because you have the volume. If you’ve architected the service correctly you’ll probably be able to switch features on and off, increase capacity or change service levels at the flick of a switch. Present such adaptations as unique products and they’ll bring follow-on revenue with little effort. Better still get the customer to manage their own service portfolio online and charge themselves for new services. What does the future hold? You can count on technology changing; that’s its nature. ASP’s will continue to go out of business because they’re providing something people don’t want, have hopeless business models, or simply because they’re executing badly. Those who succeed will know their product; they’ll recognize that the customer is king but won’t customize the product; they’ll execute well, and they’ll be funded well enough to get through to profitability. A trend will be to tie service fees to value demonstrated. For example, instead of charging a fixed fee per month a charge will be made per transaction executed (per hire made, etc.). Services will consolidate behind access portals to deliver a richer product. HP’s eServices vision brings vendors together behind the scenes to deliver composite services to the customer. So a customer buying a house doesn’t need to visit a mortgage lending site, a surveyor site, a realtor site, etc.; they visit a house-buyer’s site and their house purchase transaction triggers other transactions with lender, surveyor and realtor behind the scenes.
|
|
|
©2003-2004, outsource advice incorporated |
