hoosing an ASP may be one of the most important IT decisions a company makes. A good ASP isn't providing just hardware or software; it's selling a company essential infrastructure--the very guts of its business operations. As with other outsourcing arrangements, when a company goes with an ASP, it turns over responsibility for key operational functions. If the relationship ends, the resources don't exist either. For all these reasons, choosing an ASP is much more involved than simply purchasing software. Companies looking to work with an ASP should never do what almost always happens with shrink-wrapped software: click "accept" on a boilerplate contract and jump to work.
Contracts play a crucial role: They define basic parameters of the relationship, short-circuiting potential arguments by defining the responsibilities of the parties so there is virtually no room for misinterpretation. Here are some basic rules that users, ASPs, and consultants suggest:
Balance time-to-market with the need for research. A quick ASP search should take at least 30 days, but even a company in a desperate rush to get online should probably spend close to twice that amount of time. Any company that conducts an aggressive, effective search, selects a vendor, and negotiates terms in that time frame is doing pretty well. Involve CIOs, chief technology officers, controllers, and VPs of IT in the decision-making process.
Be prepared to share. The more an ASP knows about you, the better it can do its job. Therefore, it's crucial that the ASP understand everything about your company--from hardware and software systems architecture to the non-ASP supported applications you're running. It's equally important to share information about present and future business plans. Resources may change during the contract period, depending on business conditions. Give your service provider a chance to prepare for the situations you may encounter.
Don't confuse an ASP with a consultant. A consulting agreement often provides bodies, whereas an ASP will provide a suite of specialized services. So when preparing an ASP contract, realize that while consultants will focus on deliverables, ASPs should have a defined specialty. The services they offer should be equal to or greater than those of the application vendor.
Get what you need. Treat your relationship with the ASP as a two-way street where both sides have obligations. Define what those responsibilities are and establish an infrastructure that keeps constant track of what's happening. Set up systems for managing issues that focus on reporting, notification, and problem escalation. Establish priorities clearly for both sides and keep a tight focus. Create a structure that requires reviewing issues regularly and ensure periodic performance reports.
Establish definite service levels. Set some numbers. Specifics that should be measured on a regular basis include uptime and downtime, the speed with which issues are resolved, how quickly the ASP notifies clients about problems, and capacity planning. In addition, set criteria for customer-support levels and address who will pay for upgrades--still an unresolved issue in the ASP industry. But remember: the higher the level of service, the greater the fees.
Get real. Details are the essence of an ASP contract. The contract should describe the relationship in enough detail to provide a portrait of the system in action during both an average and a peak day--not in abstract terms.
Follow a flat-fee structure. The first step in dealing with fees is to create a "Statement of Services" that defines everything the ASP will be providing. Users should then be charged a flat fee for all services listed in the agreements. Payments are ordinarily made monthly. In a properly crafted relationship, one-time events and emergencies can be paid for separately.
Include an exit strategy. Even good relationships can go bad. Customers that buy software and then have the ASP run it will have the easiest time making an exit: All they need to do is make sure regular backups are made of their application environment. Rental customers face a more difficult situation. They may have to convert programs to another application or face the expense of relicensing the software they're using with another ASP. Either way, it's important to plan ahead.
Allocate extra resources for multiple ASPs. Bring in a systems-integration consultant to make sure the ASPs can work with each other. Then assign responsibilities so the whole process doesn't turn into a blame game when problems occur. One suggestion: Appoint one ASP as the lead service provider and point of contact at the user's site.
hoosing an ASP may be one of the most important IT decisions a company makes. A good ASP isn't providing just hardware or software; it's selling a company essential infrastructure--the very guts of its business operations. As with other outsourcing arrangements, when a company goes with an ASP, it turns over responsibility for key operational functions. If the relationship ends, the resources don't exist either. For all these reasons, choosing an ASP is much more involved than simply purchasing software. Companies looking to work with an ASP should never do what almost always happens with shrink-wrapped software: click "accept" on a boilerplate contract and jump to work.
Back to This Week's Issue
