Skip to main content

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-prescriptive on organizational structures and focuses more on the value chain concept, it does not matter ‘where’ the service desk is located. The service desk is serving as a function and helping to provide IT services to the business, therefore the agreement on the services that the service desk provides to the business would be reflected in a SLA. In other words, the IT organization is a customer of the service desk, hence the need for an SLA. This is an important concept as SLAs document not only the expected service level targets; they also specify the responsibilities of both the service provider and the customer. An important customer responsibility is that the customer must be willing to fund the agreed upon level of service. In other words, the IT organization as the customer in this case, must be willing to ‘pay’ for the services it is receiving from the service desk. This is particularly important in this situation as without adequate funding, the service desk may not have the resources needed to satisfy both its external and internal customers…putting the business at risk either way.

An OLA is an agreement between an IT service provider and another part of the same organization and underpins an SLA. Any arrangements that the service desk has with other parts of the same organization (including the IT organization) would be reflected in OLAs. So if, for example, the IT desktop support or network support teams, or a non-IT department such as Facilities, provide second or third level support to the service desk, how those teams support the services delivered by the service desk would be reflected in OLAs. Those OLAs would unpin the SLAs that the service desk has with its customers. If an external supplier such as a software publisher also provides second or third level support to that service desk, how that company supports the services delivered by the service desk would be reflected in an underpinning contract. Those underpinning contracts would unpin the SLAs that the service desk has with its customers.

The professor was further asked…
Also, in another situation if you actually have a service desk that has been outsourced, then you as the IT provider would have the underpinning contract with that supplier, but from the supplier perspective, they would have an SLA with you?
The concept of ‘SLA’ is widely used to formalize service provider/customer relationships, both internally and externally. A contract comes into play when an enforceable commitment is required. These contracts are often referred to as ‘SLAs’ but the important distinction is that contracts are legally binding agreements

If you have outsourced your service desk, you would have a contract with the supplier of those services. That contact will contain terms that speak to the levels of service that you have agreed upon, and so may in practice be referred to as an ‘SLA,’ but it must also include the language that makes it a legally binding agreement. It is therefore, technically, a contract. Before signing on the dotted line, however, it is important to ensure that the contract reflects terms that adequately unpin any SLAs that you have with your customers.

The Professor would be happy to debate this topic further as it presents some very interesting situations. What do you think?


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 th

The ITIL Maturity Model

Most organizations, especially service management organizations, strive to improve themselves. For those of us leveraging the ITIL® best practices, continual improvement is part of our DNA. We are constantly evaluating our organizations and looking for ways to improve. To aid in our improvement goals and underscore one of the major components of the ITIL Service Value System , Continual Improvement .   AXELOS has updated the ITIL Maturity Model and is offering new ITIL Assessment services. This will enable organizations to conduct evaluations and establish baselines to facilitate a continual improvement program. A while back I wrote an article on the importance of conducting an assessment . I explained the need to understand where you are before you can achieve your improvement goals. Understanding where you are deficient, how significant gaps are from your maturity objectives, and prioritizing which areas to focus on first are key to successfully improving. One method many organi

The Four Ps of Service Design - It’s not all about Technology

People ask me why I think that many designs and projects often fail. The most common answer is from a lack of preparation and management. Many IT organizations just think about the technology (product) implementation and fail to understand the risks of not planning for the effective and efficient use of the four Ps: People, Process, Products (services, technology and tools) and Partners (suppliers, manufacturers and vendors). A holistic approach should be adopted for all Service Design aspects and areas to ensure consistency and integration within all activities and processes across the entire IT environment, providing end to end business-related functionality and quality. (SD 2.4.2) People:   Have to have proper skills and possess the necessary competencies in order to get involved in the provision of IT services. The right skills, the right knowledge, the right level of experience must be kept current and aligned to the business needs. Products:   These are the technology managem