Skip to main content

Business Value of Service Level Management

There have been many discussions on what is a Service Level Agreement (SLA) or what is an Operational Level Agreement (OLA).  And by the way how does that differ from an Underpinning Contract?  We can agonize over how to measure and what to measure and who, what, where, and how we should manage our internal and external reviews.  Capturing the appropriate knowledge and building in a system for iterative activities and improvement are always a challenge.  Each of these could provoke a lengthy discussion on their own merit.   In this segment I would like to address the thought of who cares!  In other words, what is the real business value for implementing Service Level Management (SLM)?

Why do I care about SLM?
At the root of it all, the true value of SLM is that it is a vital organ in the systemic approach to integrate the business with IT.   Using SLM to strengthen the relationships between the two provide an opportunity for gleaning benefit from your effort.  For many service providers SLM can mean survival for future.
In this competitive market service providers must be able to respond to questions such as:
·         What services do you provide and how much is it costing you to provision them?

·         Compared to competitor, what value for money can you provision?

·         How much of your IT spend is spent on projects vs. operations or to keep the lights on?
If you are not able to answer these questions, you are not alone and not being able to do so may be a symptom.  A symptom that you are not implementing SLM or perhaps that the scope and targets for existing SLAs are not appropriate to achieve the outcomes you had hoped for.  Many SLAs are based on applications or targets that we internally create instead of on the service.  Even if the service provider is meeting that SLA is there any evidence that they can quantify or demonstrate the value of services to their customer?  How many business executives view IT as awesome or even competent?  How many customers view IT as partners?  It is very difficult for IT Service providers to demonstrate value to the business or their customers and Service Level Management when done correctly can help us to do that.
How to use SLM for Business Value
·         Know your services and your customers
In order to demonstrate real value from SLM the focus must start with the customer and their view of the service.  How can you be a “Service Provider” if you have not identified and documented your services or the service you provide your customer?  How can you have an SLA if you cannot agree what the service is?  The Service Level Manger must be enabled to work with the Business Relationship manager or account rep to keep a pulse on vital information, needs, and perspective of the customer.  It is all about relationships!
·         Create and measure services end-to-end to demonstrate real value to business and customers
Negotiate and Agree what your service is, quantify the service level requirements with the customer view in mind and ensure that the Service Level agreement is backed up with operational level agreements and underpinning contracts for the applications, servers, network and other components that support that service.
·         Become an asset to the business and trusted advisor to the customer
When you are able to appropriately measure and demonstrate value, creditability increases. By sustaining the relationship through iterative SLM activities the service provider can raise the bar. When you can validate a decrease in costs that affect the bottom line and increases in customer satisfaction, the business value from SLM can make you the service provider of choice.

Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…