By Caroline Denslow
IT projects depend on a good relationship between customer and service provider. This is now being formalised in the shape of a service level agreement — or SLA
|~|main_feature01.jpg|~|Establish ground rules before agreeing to an SLA .|~|For Commercial Bank of Dubai (CBD), any amount of downtime is unacceptable. As one of the biggest banks in the UAE, CBD processes millions of dollars worth of transactions everyday. If its systems fail, it could incur millions of dollars in losses as well.
It is up to Amir Afzal, as assistant general manager of the bank’s IT department, to make sure that all of CBD’s automated business processes, particularly its core banking systems, continually work for 24-hours a day, seven days a week.
One of the key measures that CBD’s IT department has put in place to ensure that its systems run without any interruptions, is to require its service providers to furnish a service level agreement (SLA) for every major project they implement in the bank.
“In the last two years we have deployed seven IT projects,” says Afzal. “All of them had SLAs,” he adds.
An SLA is, first and foremost, an agreement between a service provider and its client, which spells out the terms of services that the IT provider will supply for the project. An SLA, in other words, provides a balance between a customer’s expectations about the project and the kind of support that a service provider can realistically deliver.
It is also a good tool for avoiding conflicts as an SLA opens up communications for both the service provider and the customer even before the project starts, and continues throughout all the stages of the implementation. And if a conflict does arise, having an SLA makes it easier for them to resolve the problem.
However, the effectiveness of an SLA depends on how well it is planned, deliberated and written. According to Brian Ashworth, director, infrastructure operations, EDS Bahrain, the key elements of an SLA include standards, metrics (how the services will be measured), reporting procedures (what will be reported and how often), monitoring procedures (how delivery performance over time will be tracked), escalation procedures (how service-related disputes will be addressed), and steps for reviewing and revision of the agreement.
“Customers also often look for financial details to be defined, including penalties, in case service levels are not met,” Ashworth adds.
To guarantee that an SLA works according to CBD’s objectives, Afzal says that it is vital that even before a project commences, the bank has already discussed every conceivable loophole that can occur once a system is put in place. Normally, he would organise a meeting among CBD users and the bank’s IT support team to draw up a wish list of functionalities that they expect from the system and to come up with every possible event where the system may fail.
For instance, in an SLA meeting they had recently to discuss a new HR system, Afzal invited the people responsible for HR planning, administration and training to provide input on user requirements, such as the number of expected users and frequency of usage. At the same time, the bank’s network architecture manager and application support manager were also present to provide feedback on whether the bank’s existing IT resources can support the demands of the new system or whether additional equipment is necessary. Successive meetings together with the IT supplier will follow as the project progresses.
Such meetings are necessary to make sure that the SLA drawn up later on will have no gaps or oversights, says Afzal.
“For every IT project we take on we make sure that all concerned teams sit together. Right from day one when we start planning our systems and its required configuration, we keep in mind the expected downtime, problems and resolutions. Our general rule is that there should be no single point of failure,” Afzal explains.||**||Misconceptions|~|main_feature02.jpg|~|Afzal Amir has concluded seven SLAs with IT projects for CBD.|~|Part of the reason why some SLAs fail is because of user misunderstanding, says Ashworth. “[Some clients think] an SLA is a quick fix for delivery problems and will force a service provider to resolve these problems,” Ashworth comments “Others think that an SLA, once created, is set in stone and will never have to be changed.”
Among other common misconceptions by clients, says Ashworth, includes treating an SLA as a mechanism for resolving disputes within their own organisations; as a replacement for a contract rather than being a part of a contract; as a requirement for all services to be delivered; and looking at an SLA as a very simple document that can be completed in a very short time.
“It is the company’s right to complain, but sometimes the error is the client’s responsibility,” agrees Manish Nawani, business development manager, Getronics Middle East. “That’s where the problem arises.”
To make sure that they are protected from external factors, ASPGulf includes certain conditions and clauses in its SLAs that specify factors beyond the company’s control, like the occurrence of natural calamities or problems involving internet infrastructures, which is supplied by a third-party provider, according to its channel partner manager, Bhupesh Mehta.
“The most common customer misconception is that everything is provided by us,” comments Mehta. We make it very clear what exact services we provide and these will be the only ones under the SLA. We cannot guarantee anything that is beyond our control.”
To make sure that both sides understand the goal of the SLA, the document has to be straightforward and ideally technology jargon-free.
“It should be simple and use commonly used phrases. What is really measured has to be clearly identified,” says Tariq Sultan, Gulf Air’s vice president for IT. “You cannot have an SLA that can’t be measured. Escalation levels are important. That has to be documented.”||**||Liabilities|~|main_feature03.jpg|~|Tariq Sultan of Gulf Air believes an SLA has to be straightforward.|~|Penalties and escalation procedures are among customers’ major concerns, says Nawani. “Customers would normally go into details such as ‘Is it backed by the vendor?’ Then they try to get into the escalation side. ‘What kind of executive level are you escalating the SLA if it does not meet with the demand?’ comments Nawani.
Mehta agrees. “Mainly customers look for a guarantee of the availability of the service. And if at all there is a downtime, they look for a penalty clause which describes how they can be compensated,” he explains. ASPGulf, an application service provider, includes standard measures of compensating clients in its SLAs. If it does not meet its client’s agreed rate of uptime, the company issues credit points to the client.
“Normally we give 99.99% availability of infrastructure. If it is below that, we give credit points to our customers, which they accumulate and exchange for financial penalties later on,” Mehta explains.||**||Service measure|~|main_feature04.jpg|~|It is important to organise meetings between the service provider and the client to reach an agreement for the implementing of an SLA.|~|Because penalties are important, proper metrics need to be formulated. An SLA provides an objective basis for gauging service effectiveness because it ensures that both parties agree to use the same criteria for measuring service quality.
According to Sultan, metrics differ from project to project and from customer to customer. “Every SLA will have its [own] measurement criteria,” says Sultan. “There are no standard measurement criteria because it depends what area you are working on. It varies from area to area, from project to project.”
“Measurement is key to gauging the level of service. But it depends on the area, on the subject and what you are measuring. It could be the speed as to which your system operates, or the number of transactions it can process. It can be about reliability. It really depends on what you are measuring,” adds Sultan.
The quality of each SLA depends on the criticality of the project, says Afzal. It depends on the business impact once a system downtime occurs. For example, a communication line will have a deeper impact to the bank’s operations compared to a payroll system.
“The communication line is critical because if that line is down, my bank will not be able to work. On the other hand, the business impact of a bank’s payroll system once it experiences downtime is not much because it is mostly needed at a certain day of a month.
The bank can live without the system for a while if it is down because it is not critical to the bank’s entire operations,” Afzal explains.
CBD has a problem management system installed to measure SLA performance. The system records every service request reported by the bank. It evaluates the level of service provided through a series of calculations that involve reporting times and rectification times. Results of the computations are compared to the agreed quality of each service.
At EDS, the company uses an in-house performance management tool called Service Excellence Dashboard, which is a web-based tool to measure and track service quality in every EDS business.
“The Dashboard displays a colour-coded ‘traffic light’ rating system — green, yellow and red — for critical customer-service benchmarks, including value, timeliness and delivery,” explains Ashworth.
Because an SLA is often an open-ended agreement, careful planning does not end once the paper is signed. To make sure that quality is maintained, both vendors and customers conduct evaluations on a regular basis. The review process also gives both parties a chance to revise the SLA document to incorporate modifications and new additions that were overlooked the first time.
CBD holds monthly meetings with key vendors to review the performance of the bank’s major systems, while an annual evaluation is organised for all its IT systems, says Afzal. “At the end of the year we perform a very rigorous review with our vendors. We review vendors from various angles,” he adds.
However, reviews are not limited only to assessing systems performance. For CBD it also includes the improvements done within the service providers’ organisation. Things like skill upgrades for its staff and employer-employee relationships also matter to Afzal.
“We ask these things to make sure that their staff will not be leaving the company soon. Problems may arise when there’s too much employee turnover in a vendor’s company,” Afzal explains.
“All these things ultimately give us the basis on which we review our relationship with vendors, and if we come across any situation where we feel that the vendor’s services has been going down, then we really don’t mind changing.”
More than just a piece of paper, an SLA is a definitive measuring stick of how well customers and vendors work together. Communication is key, and trust needs to be included in the equation for the two parties to work harmoniously. Since an SLA can exist as long as the system installed is being used, it offers both parties a chance to have an ongoing conversation about issues and improvements in a much wider spectrum.
And as Afzal implies, it’s also an effective way of determining how long a customer-vendor relationship will last.||**||