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?

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…