In today’s technology-driven marketplace, delivering superior IT service management is a requirement . As such, organizations must monitor key infrastructure performance indicators and business services, all defined in :
- Service Level Agreements (SLAs)
- Operational Level Agreements (OLAs)
- Underpinning Contracts (UCs)
However, they must do this in a way that maximizes IT productivity while keeping costs low. Let’s take a look at these three, then dive deep into OLAs in particular.
SLAs vs OLAs vs UCs
- Service Level Agreements are external agreements between a service provider and a customer. They allow your organization to track performance and progress against commitments to the customer as defined in the SLAs. The agreement can consist of one or more service targets. Service targets can define penalties for noncompliance of an agreement or rewards for meeting and exceeding the specified goals.
- Operational Level Agreements (also known as Operating Level Agreements) are internal agreements that a service provider defines for internal users to meet SLAs. OLAs can also contain one or more objectives or service targets. The OLAs would be used to track internal service commitments such as the following service targets:
- Response time for incidents or problems assigned to IT groups
- Availability of servers supporting various applications
- Underpinning Contracts are agreements that are used to track performance between an external service provider and a vendor.
The below graphic shows how the three commitments work together:
The main difference between OLAs and SLAs is that they represent different commitments:
- The SLA underscores a commitment to the client/customer.
- The OLA highlights the commitment to internal groups within the organization.
In addition, the OLA typically has a smaller target group compared to an SLA, with more detail on technical aspects of the problem or service.
OLAs in ITIL & ITSM
In ITIL and ITSM frameworks, an OLA represents the relationship between an IT Service Provider and another part of the IT organization. It describes relationships at the operational level, including those between:
- Service Desk
- Support Group(s)
- Incident Resolution
- Network Management
- Operations Management
All of these relationships are captured in a document typically owned by the Service Management Team.
Components of an OLA
At the most basic level, the OLA functions as a document that serves as a matter of record between parties:
General overview
The General Overview does three important things:
- Reaffirms the purpose of the agreement between parties
- Outlines the goal of the agreement
- Highlights objectives of the document
Parties Responsible
This section lists all the stakeholders involved and will include their names, titles, and roles.
Service & Charges
This part of the document contains:
- The agreed upon Scope of Work (SOW)
- Customer Requirements
- General Service Terms
- Service Hours and Operational Hours
Service Provider Roles & Responsibilities
This identifies every internal or external service provider involved and describes their responsibilities, in great detail.
Hours of Coverage, Response Times & Escalations
Here, operating hours are covered in depth, as well as escalation policies. This section covers a few main topics:
- Work Requests
- Service Requests
- Incident Management
- Problem Management
- Service Maintenance/Change Management
- Service Exceptions
Reporting, Reviewing & Auditing
This section pertains to the term of the OLA and offers a schedule or timeline for audits, reviews and reporting.
SLA Mandates for OLAs
Putting together an OLA is time-consuming as it requires precision, attention to detail and knowledge of how an OLA corresponds with an SLA.
The body of the SLA mandates a few things with regards to an OLA:
- Rules for making changes to the OLA
- How requests for changes to OLA are submitted
- Rules for terminating an OLA
- Intervals for reviewing OLA
It is important to note that these mandates do not cover how SLAs themselves are structured. See our previous post on best practices for creating SLAs for more detail on this aspect.
Best practices for writing an OLA
If you are writing or creating an OLA, here are some best practices to consider:
- Outline the purpose of the document in 1-2 paragraphs.
- List all parties (people and entities) involved in service management and the fulfillment of SLAs.
- An agreement must include a compliance target and at least one service target. Optionally, an agreement can include one or more milestones with one or more actions associated with each milestone.
- Include detailed information regarding present challenges and how the OLA will serve to resolve them.
- Outline the method(s) of communication that parties must adhere to throughout the OLA term.
- Fully describe service operations, including hours of operation and service hours.
- Include terms and conditions.
- Indicate the authority of each signer to the document.
- Attach appendices as needed with additional information.
OLAs & Multi-sourcing
Structuring OLAs within a multi-sourced environment is inherently more complex than creating them within a single organization. However, you can avoid the common pitfalls of multi-sourced OLAs by implementing the following strategies:
- Create an internal OLA. This should be priority number one in a multi-sourced environment to ensure that a culture of accountability is established within the internal IT organization.
- Set expectations. Understand that each relationship is different and brings its own unique set of challenges.
- Control the process. The OLA should outline the path to achieving the organization’s service delivery requirements without the potential for interference from service providers who may have their own agendas.
- Talk about OLAs early and often with service providers. Do not wait until the Request for Proposal process to bring it up.
- Take ownership. Ensure that you remain accountable to clients at all times.
- Be precise. Include specific interactions in the OLA language.
- Evaluate performance routinely. Use OLA reporting and metrics to shape best practices.
OLA Readiness
How do you know whether your organization is primed to use OLAs to maximize collaboration across internal and external teams? The short answer is that if you work with clients, it’s time to brush up on your OLA expertise using the tips above.
There are also considerations to make to determine if you should use OLAs across internal groups or multi-sourced vendors:
- When you deliver services to clients does it require cooperation from various operational groups?
- When you deliver services to clients does it require vendor involvement or vendor management operations?
- Do you have SLAs in place with customers to enhance your business model and service delivery?
OLAs: Key for Enterprise Organizations
Operational-Level Agreements sometimes get confused with Service-Level Agreements because of their connected nature. However, understanding the distinction between the two is important because it ensures all internal and external resources are on the same page when it comes to providing services to the end-user.
Overall, OLAs serve as excellent tools for enterprise organizations who have embraced digital transformation by:
- Ensuring consistent levels of quality in a multi-sourcing environment
- Providing transparency across all levels of organization and to the customer
- Defining standards of accountability for all involved
Related reading
- IT Service Management Blog
- SLAs vs OLAs: What’s The Difference?
- SLA Best Practices for ITIL, Help Desk & Service Desk
- What Are XLAs? EXperience Level Agreements Explained
- A Primer on Service Level Indicator (SLI) Metrics
These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.
See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.
