Planning the SLM Framework

What is SLM?

Service level management, or SLM, is the set of operational and administrative processes which monitor and control the quality and effectiveness of IT services and support. Most often SLM is connected to ITIL and ITSM and includes the use of a continuous improvement model and key performance indicators. In many ways SLM is quality management in IT.

SLM is almost always found in some form for incident management in the form of help desk SLA’s. But SLM can and should be developed for all other IT services that are customer facing. That would include request handling, user administration, account provisioning, project management, application performance, user experience, and a wide range of user oriented IT services.

Goals for Service Level Management

The goals for implementing service level management (SLM) and using SLA’s must be very clear from the beginning. That is because your goals will guide every decision to be made about the SLA’s and how you will administer the SLM program.

Implementing SLM and using SLA’s is a powerful service management (ITSM) tool for formalizing the shared understanding of what is required by the business from their IT services. SLM also represents the shared acknowledgement of what is out of scope so there will be no confusion.

But there is a more practical side to SLM which is that it serves to focus the IT department on their in supporting technology enable business services and the customers that rely on them. In this regard, SLM is really more of a business management tool than an IT tool.

This is also why SLM tends to be more of a response to the businesses pressure to shore up their dependence on IT for risk management reasons than it is from IT seeking to raise service levels. This is also why SLM needs to business services focused rather than technology focused.

Service Level Management (SLM) Framework

Implementing SLM’s does require a bit of thought on the SLA framework in order to avoid a nightmare in administering the SLM program. Most SLA’s tend to be application SLA’s that are signed by the application owner who is usually the senior functional executive or department head and the CIO or application director.

Since most applications have a narrow user base, an application SLA works just fine. But if you have an application portfolio of any size the use of the application SLA will mean the IT department has to manage hundreds of SLA’s.

Another downside to using application SLA’s occurs when there are enterprise applications used by multiple similar departments, like with an LMS or CMS. This is also the case when there is an enterprise application suite whose functionality spans many different functional areas like with ERP.

In each of these scenarios, it can be impossible to construct an SLA for the application when there are wide ranging, module specific, varying requirements. Just having varying service levels committed for the applications required by a single department can be a nightmare for administering SLM.

Therefore, keeping the number of SLA’s to a manageable number is the key to developing a SLM framework, especially if you are just getting started. One approach to simplifying the SLM framework is to develop one enterprise level SLA for core services like the Help Desk to define the service requirements for responding to and resolving incidents based on priority.

A better way to go is to develop enterprise SLA’s for each of the support Tiers. Using this approach involves defining the IT services and service levels for each of the support tiers at an enterprise level.

Then IT and the application owners simply assign the application classification and support Tier agreement early in the application’s implementation project which should closely reflect the classification and support tier proposed in the original business case.

This often leaves only a handful of exceptions which can easily be covered by a one-off SLA. One example may even include hosting services which can still be defined by Tier for the application or service that will run on top of it. Remember, this is an organizational model not just an IT model.

All that is left then is to set up the process for regularly monitoring performance against the support tiers and reviewing the SLA performance with the various customers and governance groups.

This entry was posted in IT Performance Management and tagged , , , , , , . Bookmark the permalink.

4 Responses to Planning the SLM Framework

  1. Barry says:

    I often find that organisations that are inexperienced or have not been exposed to service management in any formal sense are best to start out with priority based SLA’s and as they mature and gain more experience move to the model suggested above around support tiers.

    Using a priority based model helps in that it is easy to apply SLA’s based on a simple urgency/impact matrix which derives priority. The key , of course, is to ensure that your prioritisation outcomes are in line with agreed outcomes from a business perspective as any misalignment tends to shoot holes in your SLA model and everyone loses confidence.

  2. The Higher Ed CIO says:

    I have also used that approach. It’s like learning to walk before running. But prioritization only touches a small portion of the IT service portfolio and a small portion of what customers care about – application performance, project completions, availability, etc… These dimensions get covered by tiers.

  3. SLM says:

    What are the key parameters that need to be considered for service based SLA?

  4. The Higher Ed CIO says:

    I am actually working on that right now with a client as well as to offer on this site. I think, and my view has been evolving on this over the past couple of years, parameters (aka metrics) are secondary to key performance indicators (KPI). But I find KPI is not always an accepted term or concept so I will simplify it this way.

    An SLA for a service should look at how you would describe overall goodness of the service from the owners and customers perspective. Usually that centers around timeliness, value (cost & quality), accuracy, and the experience. But in many service situations the service goal is not simply to provide a positive transactional result, it is to develop a loyalty for repeat business.

Comments are closed.