RSS
Логотип
Баннер в шапке 1
Баннер в шапке 2
2010/05/17 17:15:29

SLA - Service Level Agreement the Agreement on the quality level

Service Level Agreement (SLA) — defines the cross liability of provider of the IT service and users of this service. According to the recommendations of ITIL Information Technology Infrastructure Library, SLA is the main document regulating relationship of IT and clients. The document purpose – to give the qualitative and quantitative description of services, both from the point of view of provider, and from the point of view of the user.

Content

Essential part of SLA is the directory of services.

Service Level Agreement – SLA is an agreement between the customer and the contractor, the quality level of providing this service containing the description of service, the right and obligation of the Parties and, the most important, approved. The agreement of SLA accurately registers time frames for elimination of problems, defines the penalties inflicted on our company if service quality was lower than the level stated in the agreement. It will allow to minimize your losses. Thus, the customer receives a convenient method to control services, to be sure of their completeness and quality. The uniqueness of service is that SLA gives the clear answer to the question "Well or Badly the Support Service Works?".

Structure

What does SLA consist of?

The standard SLA model should include the following sections:

  • Determination of the provided service, the parties involved in the agreement, and durations of the agreement.
  • Days and hours when service is offered, including testing, support and upgrades.
  • Number and accommodation of the users and/or the equipment using this service.
  • Procedure declaration of reports on problems, including escalation conditions on the following level. The report set-up time should be included.
  • Procedure declaration of change requests. The expected runtime of this procedure can join.
  • Specifications of the target objectives of quality of service, including:
  • The average availability expressed as a median number of failures for providing service
  • Minimum availability to each user
  • Average time of a response of service
  • The maximum response time for each user
  • Average capacity
  • Descriptions of calculation of the stated above metrics and frequency of reports
  • The description of the payments connected with service. Perhaps as establishment of uniform price for all service, and with breakdown by levels of service.
  • Responsibility of clients when using service (preparation, support of the corresponding configurations of the equipment, the software or change only according to the procedure of change).
  • The procedure of permission of the mismatches connected with providing service.
  • Process of improvement of SLA.

Ideally, SLA is defined as special service. It allows to configure hardware and program for maximizing capability to satisfy SLA.

What surely it is worth including in SLA?

  • The list of the provided services
  • The provided volume and runtime of services
  • Priorities and standard time of the solution of requests
  • Requirements to the reporting and metrics of quality evaluation of service
  • Cost of services, penalties and payment terms

What to pay attention to?

To build effective contractor interaction, it is necessary to understand equally importance of business processes and also to provide direct communication with business

  • Appoint the coordinator from the customer
  • Register the cross liability
  • To monthly monitor metrics
  • Receive a feedback from business experts
  • Not forget about communication with end users
  • Fix interaction in Service Desk

What cost depends on and how not to overpay?

  • Set, complexity and extent of customization of applications
  • Criticality of business processes
  • Required working schedule
  • Organizational structure and territorial structure of the customer
  • Quantity and competence of users
  • Volume and complexity of document flow
  • Reporting structure
  • Status of the user and technical documentation

How still it is possible to reduce cost?

  • Updating of documentation, FAQ
  • Processing of repetitive errors through training or completion of a system
  • Documentation of all changes in a system
  • It is less than completions
  • Balanced approach to SLA

Why SLA are necessary

Let's remember the theory. On ITIL, SLA (Service Level Agreement) – the agreement between IT service provider and the customer (by default – between IT department and core business of the company). In SLA obligations of the supplier and a condition of provision of services and also a duty and a possibility of the customer for consumption of services are described. Concluding SLA with business structure, the IT service guarantees providing service with the quality level not below approved[1].

What does SLA consist of?

  • The description of the services / services provided within SLA (a part or all directory of the services provided by IT service)
  • The description of conditions of providing services / services (up to a request processing order on certain services)


Fixing in SLA of a condition of rendering services, we arrange our relationship with users, defining – who when and in what form sends to us a request. It is impossible to expect fast billing on delivery if on an input we receive a request "Deliver us something, it is desirable in festive packaging". We will absolutely precisely spend a lot of time for detailing of a request. And thus, about any efficiency of accomplishment of requests we will not be able to speak any more - and not through our fault! And in the field of IT services: to provide access to a shared folder, it is necessary to know – to what shared folder access is necessary; on the basis of what we will execute this request (in compliance with information security policy), etc.

At last, SLA is management of expectations of users. Only such service when everyone who submits the application always knows can be qualitative – when this request is performed. So when we competently manage expectations of our users.


Service Desk implementation, certainly, is closely connected both with determination of the directory of services, and with development of SLA. As:

  • without directory of services it is impossible to outline an area of responsibility of IT service – so, to competently pick up resources and to organize work processes
  • without SLA it is impossible to set reference points of work of IT service (and such reference points which would correlate with the business purposes). And without it there will be no understanding, we move or we stand still i.e. as far as we are close to observance of SLA. Where to make additional efforts first of all, etc.

Errors

Lack of rules of parting

  • Whether it will be known of termination in advance?
  • Whether there will be enough compensation amount?

Carelessness to sanctions

  • How will violation be compensated?
  • Whether responsibility is proportional?

There is no mechanism of suspension / resumption of work

Inaccuracy of conditions

  • What requests will I receive?
  • What result can I expect?

How to make it?

Behind each service / request of the user there are the processes started in IT service. In this plan of SLA is an opportunity to construct IT processes and to be sure that such organization will help to work effectively from the point of view of users. Introduction of accurately regulated time of reaction/elimination of incident/providing service is a part of large-scale process of SLM, however it is possible only if in IT service more elementary processes are already adjusted. How in this case to construct effective process of management of the level of service?

  • Begin with one / two SLA for all company.
  • Select user groups for which you will provide services of different quality, for example:
  • SLA for VIP-users:
  • SLA for all others:
  • Select critical services on which you consider it necessary to manage quality – i.e. to undertake obligations and to execute them. NO never undertake development of SLA in all possible directions at once.
  • Determine terms for the selected SLA. How to make it? In general, the choice of target values of critical figures of merit of work (and it is also development of SLA!) – the action which is initially following from the process approach to management. Misters founders of such approach (for example, Dr. E. Deming) bequeath when choosing measure values to make a start from a current status of process. Itself cannot set the purpose – to perform work in 20 minutes – if the current status of processes gives us all 20 hours. Everything what we can hope in the near future for is a reduction for percent, but not much (the same as it is difficult to expect that 9 women in 1 month will give birth to the whole child). Other question if from 20 hours 19 takes place in waiting of the queue. Then we can cardinally influence process change.

In other words, to specify really feasible terms in SLA, we should: a) know what terms we are able to observe now; b) understand what process stands behind observance of these terms.

  • Begin to measure the actual observance of parameters of quality.
  • When it becomes obvious that the terms stated in SLA work not always and in 50% of cases are broken or business sets new tasks, selecting new critical services – begin to detail services and to adjust usloviyasla.

Sometimes talking to clients, we hear: "no, we did not start Service Desk implementation yet – at first we develop SLA. Already few months as …". Such approach has the unconditional right to existence, but if the IT department is able to set a little plausible parameters of quality for the services included in SLA. However often we cannot determine time for which are ready to be responsible. For an example: by preparation of a new workplace sometimes we spend week because we need to buy something, and sometimes one day - we give the equipment from a warehouse and so forth. Or for us new services on which we cannot assume yet are key, what is the time will occupy their service. In these cases it is reasonable to start at first in work of Service Desk without SLA to obtain statistical data on terms of service of these or those services from the directory.

Summary: when developing SLA it is necessary to consider several key moments

  • The quality parameters defining how services should function – i.e. how to measure whether the effective objective is achieved by IT service – should be measurable.
  • The set parameters should be achievable in the current life of IT service. Such organization of work in itself motivates personnel. And here if the task is clear, but is unattainable – from it is not present any I pound.
  • All services and services should be available not to all users (for example, only heads of business units can request service in creation of a new mailbox; and all users can announce an incident). Respectively, it is necessary to plan development of several SLA with different user groups
  • Different staff of the company demands different conditions of rendering the same services. For example, it is admissible to eliminate failure in operation of the PC in a workplace of the secretary in 4 hours. And the working PC of the director cannot stand idle more than half an hour. Also governed what the nature of processing of a request depends on, we should consider in SLA too. Arrow.PNG
  • For any appeal to IT service a set of the entering information is important. Thus, SLA should join the parameters of the entering information which are the compulsory provision providing accomplishment of the obligations by IT service.
  • Provide methods of measurement of the actual parameters of quality.

Gradually moving forward (always - as necessary business, not on own imagination), you will reach that balance when:

  • Everything that is important for business, is described and regulated – so, standardized and measured – so, we work on quality of our work in the points, necessary for business
  • The rest automatically has lower priority, and we can set terms, comfortable for us.

Notes