Here are some ways to make sure an SLA (service-level agreement) protects your Web business and technology:
Ask for only what you need.
Since the Net is available 24/7, some companies believe their Web systems also need to be up and running all the time. But when outsourcing, it costs significantly more to guarantee 100 percent availability than it does to guarantee 99 percent or 98 percent, and not every company！or every application！needs it. Doug Plotkin, director of sourcing strategies at Meta Group Consulting in Westborough, Mass., advises companies to make sure the performance they request in an SLA meets a specific business need. If you feel the vendor is trying to give you a snow job, don't be too embarrassed to ask someone from your company's IT department to explain all the technological details. "It's easy for a vendor to talk a nontechnical person around in circles and make them feel intimidated," says Naomi Karten, CEO of Karten Associates, a management consulting group in Randolph, Mass.
Protect the important stuff.
Let's say you've outsourced the hosting of 50 servers running various Web applications. Your hoster may want to promise a level of service based on the average availability of all 50 servers, an SLA technique known as aggregation.
"That's perfectly fine unless you have one critical server that's down all the time and you can't function," Plotkin says. When servers are aggregated it typically takes a catastrophe for the average performance to fall below the specified level！and for penalties to kick in. Carving up the penalty equally to cover each individual server is also not necessarily the right move. When that critical server fails the penalty might be so small that it's cheaper for the hoster to ignore the problem than it is to fix it. Plotkin's advice is to identify critical components of the outsourcing deal！and apply penalties that get the outsourcer's attention.
Define your terms and how you will monitor them.
When a service provider promises 98 percent uptime, make sure you ask, "98 percent of what?" Karten says an uptime promise typically does not include scheduled maintenance or acts of God. To avoid any confusion, she recommends creating a set of definitions of performance-related terms.
And don't stop there. Your Web SLA, just like any other SLA, needs to spell out how the agreement will be monitored！how service levels will be tracked, how frequently they will be reported and how often performance will be reviewed. "They're not much good unless they're monitored," says John Funk, a partner at Jones, Day, Reavis & Pogue in Dallas.
Cover best- and worst-case situations.
If you're outsourcing your website's customer support call center, a typical service-level agreement might specify that 90 percent of calls will be answered within 30 seconds. But if the agreement doesn't also specify the maximum length of time for answering all calls, some of your customers could be kept waiting. "The vendor could diligently answer 90 percent of the calls within 30 seconds and let the others remain on hold for minutes" without being in violation of the SLA, Plotkin says. "We've seen this happen." His advice: Spell out both the desired and worst-case levels of service.
Make the penalties fit the crime.
SLA penalties for poor performance are usually in the form of a rebate on the monthly service charge. That won't come close to compensating your company for lost business, especially if you're outsourcing a high-volume e-commerce site. But the penalty should get the vendor's attention to fix the problem, Funk says. Some vendors try to cap penalties at 12 to 18 months of fees. Funk fights to remove any clauses saying that this performance penalty will be the "sole and exclusive remedy of the customer."
Choose rewards with care.
Don't fall into the trap of agreeing to reward a service provider every time it exceeds the contracted level of service. Rewards are useful for business-related service levels！say, for being able to respond to 95 percent of website customer service calls within 30 seconds rather than the contracted 90 percent. But they are less valuable for most technology-related service levels. "What you care about when you construct service-level rewards clauses is giving aid and comfort to your end users," Plotkin says. "If the availability metric for a server is 98.5 percent and the vendor comes in at 98.6 percent, end users will not notice."
Demand continuous improvement.
Since technology improves rapidly over time, the service terms defined in a five- to 10-year contract can easily become out of date. For example, says Plotkin, a few years ago it would have been standard to promise at least 95 percent uptime on a server; today service providers would at a minimum guarantee 97 percent uptime. Make sure to specify that service levels will be updated periodically to match industry standards.
Constructing a service level agreement requires planning and care. While the process can vary among companies, there are often basic elements in common. Bob Quinn, vice president and CIO for computer systems at Sun Microsystems Inc. in Palo Alto, Calif., and Naomi Karten, president of Randolph, Mass.-based management consultancy Karten Associates, who serves as Sun's SLA consultant, recommend the following 10 steps as a guide:
Assess whether an SLA is appropriate.
Get management commitment.
Designate SLA managers.
Educate the parties involved about SLAs.
Assess current services.
Gather customer feedback.
Ensure agreement about the agreement; create a draft.
Solicit feedback.
Complete pre-implementation activities, such as establishing tracking mechanisms and conducting pilots.
Implement and manage the agreement.
Today's service level agreements are distinguished by clear, simple language and a tight focus on the business. For IS groups that use them, the benefits can be substantial.
Ronald Lynn suffers the classic irony of the shoemaker whose children go without shoes. His IT group at Inspire Insurance Solutions Inc., an insurance and technology outsourcing company based in Fort Worth, Texas, serves both external outsourcing clients as well as internal Inspire business units. Money talks when prioritizing service calls, admits Lynn, who is executive vice president and CIO at Inspire. "What do you do when your internal people are screaming for help because you're serving the paying customer instead of them?" he asks.
Lynn and his staff must live by two completely different sets of rules. When his paying customers want more service, they come to the bargaining table. When Inspire customers want more, renegotiating the IT budget is not usually an option. While serving external customers, his staff are revenue generators whose time is money. Internally, they are dedicated "service providers" whose time is undefined！the IT budget clock doesn't have a minute hand or even an hour hand. Performance is harder to measure and harder to control. "With our external clients, we're either above or below the performance level that's set in the contract," Lynn says. "If we've fallen below it there's a penalty, and if we're above it we get a few percent back."
Though CIOs serving internal customers cannot hope to have the same sorts of ironclad contracts that govern outsourcing relationships, the service level agreement, or SLA, is the next best thing. The concept dates back to the '60s, when IT departments used SLAs to measure technical services like data center uptime, for example. But SLAs have evolved to a new level in the last few years, becoming more broad-reaching and bilateral. These new agreements require IT to work with its business customers to define a short-list of services that are most important to keeping the business running, such as guaranteed e-mail delivery time or the availability of important software applications.
The new SLAs are distinguished by their clear, simple language and their tight focus on the needs and wants of the business . IT groups that have adopted this clarity strategy have seen improved relationships with customers, better leverage in budget negotiations and an improved ability to compete with outsourcing vendors. Yet despite these successes, only 20 percent to 25 percent of Meta's IT research clients actively use them. The usual excuses of time and money apply. Few IT departments have a clear sense of their own performance levels, so there's usually much work to be done before real negotiations can begin with the business. Testing or benchmarking IT services costs around $100,000 for each major technology "slice," such as the data center, desktop services or networking.
SLAs also usually require outside help. Both IT and the business will want an objective outsider to help develop the agreements; that consulting can add another $50,000 per technology slice. Finally, there is the old "simple is hard" conundrum. Boiling down the long list of IT services into a clear, simple short-list takes time and energy！figure on at least three months to a year, even with consulting help.
The work doesn't stop once all the SLAs are in place, either. The agreements require constant discussion and renegotiation as the needs of the business change. Untended SLAs can lull IT into a false sense of security about the level of existential happiness among its customers. To be effective, SLAs require more thoroughness and vigilance in measuring customer satisfaction so that dissatisfaction not reflected in the SLA metrics will reach IT before a real crisis hits. Yet despite the trouble and expense, SLAs provide invaluable performance metrics to IT and create more informed customers.
Advertisers
SLA (service level agreement)
A contract that spells out the terms of service that an outsourcer will provide.
Chris Derossi, cofounder and chief technical officer of Mountain View, Calif. based ePeople offered insight and advice on making the most of your contracts with technology vendors.
How do I set up an effective SLA with an outsourcer?
Service level agreements should match your business needs as closely as possible. Getting service level agreements for system uptime could be critical, or it could be a detail of your overall operation because it is more important that your applications are accessible when you need them to be. On the other hand, your business may require that you have immediate response to support issues 24 hours a day, seven days a week. Try to set objectives that support what your business must accomplish. Having objectives and metrics alone is not enough to guarantee customer satisfaction. Good SLAs also include both remedies and penalties for missing established service levels. These penalties need to motivate your vendor to achieve the objectives, and the remedies need to help make sure you get back on track quickly. In other words, you don't want to miss your service levels over and over again, regardless of the size of the penalty. Ask your prospective vendors to help craft SLAs and metrics that are achievable and a win-win for both parties. Ask them for examples of SLAs they have used with other customers who had similar business needs. And, as with any vendor selection process, get references and make sure to ask those references about the metrics used and the quality of the results.
Where can I find examples of SLAs?
Examples of real-world SLAs can be difficult to find because they are considered confidential business information, much like other contract terms. However, there are a few places where you can look. The first place to check is the agreements you have with your own vendors. Many times, the SLAs you will be able to offer are bounded by the SLAs offered by vendors on which you rely. For example, if your internet service provider only guarantees 99% uptime, it would be impractical for you to commit to delivering 99.5% uptime. You can also check the contracts of companies similar to yours that were filed with the SEC during the initial public offering process. These contracts tend to represent the largest and most important deals, and often contain SLA terms that you can use as a benchmark.
One-fifth of companies say vendors' technical skills matter
When evaluating technology-based vendors, 20% of IT buyers say technical skills are the most important factors in their decision making.
Ranking second on the list is previous experience with the vendor (17%), followed by features of the service (16%), availability to meet your deadlines and speed time to market (14%), service-level agreement (13%), firm's reputation (7%), rapport with firm's staff (6%) and price (6%). Just 3% said no single factor is most important.
December 11, 2001 - IT Services Marketing Association
More than half of IT buyers
are influenced by colleagues
More than half (52%) of IT professional services buyers say they are most likely to make purchases based on a recommendation from a colleague. The second most reliable sources are industry analysts (29%) and industry trade press (22%).
Source of
Information
Percentage
responding
Referrals from colleagues
52
Industry analysts
29
Industry trade press
22
Company websites
19
Topical Web searches
16
Industry trade shows
12
Seminars and conferences
10
Service providers/sales reps
10
Business press
7
October 23, 2001 - IT Services Marketing Association
You say you've narrowed your list of vendors, and now you're ready to make some decisions? No one knows better than you: You've made a significant investment in time and money！for starters！and have a lot on the line. How can you better ensure the success of the project?
Checking vendor references is one critical step toward making a final decision. Remember: Not every reference is reliable, but they'll tell you what you need to know if you ask the right questions. Here is a list of questions to ask references before you make a purchasing decision:
Are you still using the system? And if not, why not? This should be your first question because the reference might not be using the system. You need to know why.
What exactly are you using? Which modules? What version? Make sure that you're comparing apples to apples. Many large systems have several modules. It is unlikely that a reference is using all of them. You want to talk to someone who is using the features and modules that you want to use. If the reference is using a system that is several versions old, the new system may have bugs in it. If they've upgraded, ask if the transition was easy.
How are you using the system? This might be useful for you to know！it could be applicable to your business. Or, the reference could be using the system in a way that is not applicable to your situation; you might need another reference to replace this one. Find out what operating system and hardware are being used.
Why did you choose the system? What are its strengths? What are its limitations? Basically, you want to know why the company made the decision to go with the vendor. You might be surprised by what the reference says. One told me that he chose the system because he had no choice！a simple ultimatum from his boss!
What are some of the bugs you've seen? If the company has used the system for a while, it has probably seen everything. Find out how the vendor has addressed such issues.
How long did the implementation take? Implementations can be nightmares. You need to know what to expect. Ask how you could make the implementation smoother. Also, based on the date your system will go "live," a software salesperson may know who will implement your system. If so, ask to talk to references that used the same implementation team to find out if there were any glitches.
What about the vendor's customer service? Ask the reference if it is currently under a support contract. Ask about the responsiveness of the vendor's help desk or if it's ever had any major problems and how they were handled. You are not just buying a solution, you are betting your success on a vendor. You need to know that the company's customer service is acceptable, especially if the system is critical to the success of your department or business.
Do you attend the user-group meetings? Many vendors have user groups！local groups of clients using the vendor's software. Find out if the reference attends the user-group meetings and what the company's experience has been. You should also try to attend the next user-group meeting to hear from companies that are not references. You will get a chance to hear the good, the bad and the ugly.
|
