Service Level Agreement – SLA is defined as an agreement between two or more parties – the service provider and a consumer(s) on the expected behavior of the service from the service provider. The agreement also mentions on the metrics of the service – the service uptime in a month, help desk response in case of incident reported on the service etc along with details like how the SLA data is going to be captured, by whom and how often the SLA data will be published. 

In case of Managed service engagements, also now known as outcome based billing, the SLA data is used to bill the efforts taken to keep the service running. In case of a service violating the agreement, a commercial penalty would exist.

SLA ensures both parties (service provider and consumer(s)) have the same understanding of requirements on the service.

OLA – Operational Level Agreement, is an agreement between the internal support group(s) of an enterprise that support SLA. OLAThe objective of OLA is to ensure that all the support group(s) provide support to meet the intended Service Level Agreement.

Lets consider a case study and define SLAs. The credit card division of a national bank has been having problems in collections. On doing root cause analysis, the team found that there are multiple causes for this – 1. the credit card bill is not generated on specific days, 2. the bills are not reaching customers on time. The customers who donot want to default are having very less time to pay their bills.

The product manager of the consumer credit cards division defines a business requirement that all credit card bills have to reach their customers 15 days before their due date thus giving the customers ample time to pay their bills. The CIO now has the responsibility of implementing this business requirement. The CIO first lists down the process to dispatch the bill  as below -

  1. Generate the soft copy of the bill
  2. Get the bill printed
  3. Dispatch the bill to customer

For each of the activity, he derives the sub-functions as below -

Generate the soft copy of the bill – the java based billing application batch process(es) have to run on separate dedicated servers, on 5th of every month. All the consumer credit card bills have to generated within 2 days from 5th of every month. To enable this multiple teams have to support- the billing application support team to ensure the batch process does not stop, the operating system support team to ensure the OS works as desired so that the billing batch does not stop, the network storage team has to ensure there is enough disk space to store the generated bills.

Each of these sub-tasks within the support groups are now assigned OLAs to meet the SLA. These OLAs are monitored to ensure there is no deficiency of service.

Get the bill printed – Once the soft bill is generated, the printers have to take this as input and generate the hard copies. For this the IT team has to ensure that the multiple printers keep working and in case of problems, there has to be stand-by printers to take the load.

Since the bank has an AMC contract with the printer vendor, it enters into a SLA such that there is minimal downtime for the printers during the printing duration (2 days in a month).

Dispatch the bill to customer -  Once the hard copy is printed, the dispatch department has to courier the bills to consumers. The bank has a tie-up with the local courier company for this activity. The bank enters into a special SLA for dispatch of these bills. The SLA is to ensure that once the bill envelope is given to the courier company, it has to be delivered to the company within 1 working day in same city and 2 working days for other cities within the state. The courier company is told to pass back the delivery date and time information back to the bank so that SLAs can be tracked.

Once the whole process is put in place, metrics is collected for the OLAs and the SLAs. This data has now to be converted into information to derive SLA performance indicators.

Lets say the business wants to ensure that the credit card bills have to be delivered within 15 days of due date to 96% of it’s customers within a month. The IT team can now consolidate the date from the courier company to know how many customers got their bills delivered 15 days before the due date. If 16000 consumers got the their bills out of 16800 consumers, then the SLA compliance is 95.23 %. This is the SLA performance indicator. This figure when tracked over a period of time can give the performance trend.

Now that the business process has been measured, it can look at improvements in all the activities that lead to meeting the SLA targets, like adding new servers to reduce time taken to produce soft copies, add more printers to decrease the time taken to print bills, increase man power involved in packaging the hard copy bills, partner with other courier companies that can further speed up the deliveries. If the bank has the provision of mailing soft copy bills, then it has to track the mail sent date to track the SLA.

SLA primerThis article thus sums up the process of defining and monitoring an SLA.  Each of the systems in an enterprise can have different SLAs based on the business needs. These SLAs need to be referenced in the IT service catalog for ready central reference.

We @ technologia have been providing SLA based support services for OS, platform and applications. If you would like to hear from us, pls contact us from our portal - http://www.technologiaworld.com/contactus.html

 

2 thoughts on “How To Derive SLAs [Service Level Agreements]

Leave a Reply