Skip to main content

Posts

Showing posts with the label Service Level Management

Anatomy of an XLA

That is not a typo!   Alan Nance of CitrusCollab recently spoke about The Anatomy of an XLA in an ITSM Academy webinar.   I learned that the days of SLAs are behind us and the future lies with digital experience and eXperience Level Agreements (XLA’s).  If this is the first time you have heard of XLAs then this is a sticky-note moment.    By that I mean; find a sticky note, write down today's date.   Now write down XLA.   Remember that this is the day that you heard it and you heard it here!  XLAs are the foundation of a fresh and optimistic approach to managing the business of technology. Research for yourself and staff members. Learn and explore more about XLA’s! A little history: “Service Management exists to guarantee a valuable experience to customers and colleagues. Despite years of implementing best practices, the reputation of most technology departments is below par in the eyes of business leaders. Consider that 90% of CEOs feel they aren’t meeting their cu

KPIs and SLAs

A short while ago I was asked this question from one of our reader: “ I want to set a KPI around how much of the time we meet the SLA. Like 'meeting the SLA x% of the time'. Can someone advise what would be that 'x'? What is the common practice?  Is there an industry standard around this?”   I’m going to have to go with the consultant answer and say it depends.   First, are we talking about a single service to a single customer? Are we talking about multiple services to multiple customers or somewhere in between those two extremes? Your SLAs should include details of the anticipated performance that your customer expects.  First thing you need to do is discuss with your customer what are the levels of utility and warranty they are expecting? Then document and agree these targets are reachable given the resources that are at your disposal and any constraints that may be discovered. The requirements for functionality (utility) should be defined by your BRM pr

The BRM Function

I was recently asked if I had any insights into what roles (titles) are commonly used in companies and organizations to fulfill the BRM function.  This individual commented that the BRM function is one that they wholeheartedly support, but were finding that investing in a resource that is exclusively focused on that is something that companies either can’t afford (legitimately) or that they struggle to justify the cost for the position. Finding the suitable individual with the proper skill set to fulfill the Business Relationship Management (BRM) role can certainly be a challenge.  One thing to recognize is that the BRM job role function is dual fold.  This person represents first and foremost the customer.  They must be familiar with intimate details regarding customer needs, expectations and preferences.  On the other side the BRM also will liaise with the business to ensure that the service provider can fulfill those customer needs.  This is sometimes more of an art than a

Business Relationship Management (BRM)

Business Relationship Management (BRM) is the process and role that allows us, as a service provider, to establish a strategic and tactical relationship with our customers. This will be based on ensuring we understand the customer and the business outcomes they are trying to create and how and what services are engaged by the business to meet those defined goals and objectives. A key activity of the BRM process is to ensure that as business needs change over time, we as a service provider, are able to translate these needs into requirements through the use of a Service Level Requirements document (SLR) which then manifests itself into the portfolio in the form of defined services.  The BRM will assist the business in articulating these requirements and the value of these services that the business places on them. In this way the BRM process is executing one of its critical success factors, which is to safeguard that the customer’s expectations do not exceed what they are

Visible Ops

Anyone who has worked in Information Technology knows that today, there is and always will be improvement opportunities available to our organizations.  This is especially in light of the pace of change that is taking place in all market spaces and the level of customer expectations that accompanies that change. If you have worked in IT for a number of years, you may remember when change was not welcomed. Well the good old days weren’t always that good and tomorrow ain’t as bad as it seems (Billy Joel).  The challenge is in getting started. If……. ·        the processes that are currently being engaged are not as efficient and effective as you would like ·        you are finding that your environment isn’t as stable and reliable as it should be ·        that when you make changes to your environment it generally results in an outage and prolonged and repeatable firefighting then ……. I recommend that you read The Visible Ops Handbook by Gene Kim, Kevin Behr and Geor

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

Questions about OLAs and SLAs

The Professor was recently asked about the following very interesting situation. In my organization, we have a service desk that is not part of the main IT department.  Since we are a service desk solution provider, it is actually in one of our businesses units.  So our IT department has chosen to take advantage of that in-place service desk to effectively also be the service desk for internal employees.   Is this a situation where an operational level agreement (OLA) applies?    Or are the “parts” of the internal organization too far apart and a service level agreement (SLA) is more appropriate? I think the idea is that the OLA applies to different internal groups within IT?   Is that true? Let’s first define these terms and then apply them to this situation. An SLA is an agreement between a service provider and a customer. In the case of the service desk that is in one of the company’s business units, that service desk is a Type I (internal) service provider. Since ITIL is non-p

Service Level Management Objectives

Service Level Management (SLM) is the process that is responsible for the overall agreeing and documenting Service Level Targets (SLT) and the responsibilities within Service Level Agreements (SLAs) and Service Level Requirements (SLRs) for every service and related activity within IT. The SLA is effectively a level of guarantee or warranty with regard to the level of service quality delivered by the service provider for each of the services supplied to the business.   The accuracy of the SLAs, SLRs and SLTs and the overall success of SLM is very dependent on the quality of the service portfolio and service catalogue and their contents because they provide the detailed information on the services to be managed within the SLM process. With that said the purpose of the SLM process is to certify that all current and planned IT services are delivered in accordance with agreed achievable targets.   This is normally accomplished by SLM through a continuing cycle of negotiations, agreem