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.