ISO 20000 Operational-level agreement Template
What is an Operational-level agreement?
An operational-level agreement (OLA) is a contract between an organisation and its internal or external supplier that defines the operational expectations for a specific service.
OLAs are typically used with service-level agreements (SLAs) to provide a more detailed picture of the operational requirements for a particular service. For example, an SLA might specify that a service will be available 24 hours a day, seven days a week. An OLA might then determine how the service will be delivered by limiting the number of customer support representatives available during each hour of operation.
Service providers typically develop OLAs in consultation with their customers to ensure that their services meet their customers' expectations. The development of OLAs generally is driven by the need to improve service quality or address specific service-related problems. For example, an OLA might be developed in response to customer complaints about the length of time it takes to resolve service issues.
OLAs can document operational expectations for any service, including IT, account management, customer support services, etc.
Who uses operational-level agreements?
Operational level agreements (OLAs) are used in ISO 20000 to manage expectations and ensure everyone understands their roles and responsibilities in IT service delivery.
There are three main groups of people who use OLAs:
- Management: OLAs help management understand what needs to be in place to ensure successful service delivery.
- Service delivery team: OLAs help the service delivery team to understand what is expected of them and how they need to work together to deliver the services.
- Customers: OLAs help customers to understand what they can expect from the services they receive.
Service Requirements of Operational Level Agreements
The purpose of an operational-level agreement is to define the expectations of the service provider and the customers and to establish the framework within which the services will be delivered.
1. Operational-level agreements
It can be used to define the roles and responsibilities of the service provider and the customer, establish Service Level Requirements, and agree on service levels.
Operational-level agreements should be aligned with the business goals and objectives of the organization. They should be reviewed and updated regularly to ensure that they remain relevant.
2. Service Requirements
Operational-level agreements must be based on the service requirements of the customer. The service requirements must be documented and agreed upon by both the service provider and the customer.
3. Service Delivery
Operational-level agreements must define how the services will be delivered and include service levels, reporting, and performance monitoring provisions.
4. Roles and Responsibilities
Operational-level agreements must define the service provider's and customer's roles and responsibilities.
5. Service Level Requirements
Operational level agreements must define the Service Level Requirements, which must be measurable and achievable.
6. Reporting
Operational-level agreements must define reporting requirements so that everyone understands the needs and the
Results are monitored and reviewed by all participants at regular intervals to fine-tune SLA‘s strategic, financial and
Operational objectives.
The Various types of reporting requirements are:
- Service Level Reporting
- Change Management Reporting
- Performance Reporting
- Capacity Management Reporting
- faults/problems Reporting
- Business partnering Reporting
7. Escalations and Penalties
Having some provision to deal with failure to meet the targets is desirable. This is the most controversial part of
An agreement and the most difficult to details. The possible choices discussed in the previous section are:
- Service Credits
- Withholding Money
- Modify the Service
- Sever the Agreement.
Processes:
1. Change Management:
The change management process in operational-level agreements typically includes the following steps:
- Request for change (RFC)
- Change assessment
- Change approval
- Change Implementation
- Change closure
Request for change (RFC):
A request for change (RFC) is raised when there is a need to change the IT infrastructure. The RFC contains details of the proposed change, including the reason for the change, the benefits of the change, and the impact of the change.
Change assessment:
The change management team assesses the RFC to determine whether the proposed change is feasible and will have the desired effect. The assessment will also identify any risks associated with the change.
Change approval:
If the change is approved, a plan is developed outlining the steps needed to implement the change. The change plan is then reviewed and agreed upon by the relevant parties.
Change implementation:
The change is then implemented, following the steps outlined in the plan. Once the change has been completed, it is tested to ensure that it has the desired effect on the organization and its employees. Finally, the organization evaluates whether the change was successful and, if not, what can be done to improve the process for future changes.
2. Availability Management
"The process responsible for ensuring that services are available to meet business needs. It bridges the gap between service design and service operation and is designed to ensure that service availability risks are managed throughout the service life cycle."
The process is made up of the following activities:
- service availability planning
- designing for service availability
- Capacity management
- Availability management
- Service continuity management
The Change Management Process aims to ensure that all changes are documented, assessed, authorized, implemented, and closed in a controlled and consistent manner.
The steps in the Change Management Process are as follows:
- Raise a change request
- Assess the change request
- Authorize the change
- Implement the change
- Close the change request
The Change Management Process is closely linked to the Configuration Management Process, as changes to the configuration need to be recorded and tracked.
3. Capacity Management
For capacity management to be effective, it must be integrated with other processes, such as financial management, risk management, and change management. The capacity management process has four main activities:
- Service capacity planning
- Component capacity planning
- Infrastructure capacity planning
- Resource capacity planning
Service capacity planning ensures that the service's capacity meets the business's future needs. It involves understanding the current and future demand for the service and providing that the power is adequate to meet this demand.
Component capacity planning is concerned with ensuring that the capacity of the individual components that make up the service meets the future needs of the business. It involves understanding the current and future demand for the service and then ensuring that the capacity of each component is adequate to meet this demand.
Infrastructure capacity planning is concerned with ensuring that the capacity of the infrastructure that supports the service meets the future needs of the business. It involves understanding the current and future demand for the service and then ensuring that the capacity of the infrastructure is adequate to meet this demand.
Resource capacity planning ensures that an organization has the resources it needs to meet future demands for products or services.
