• Will the SLA structure allow flexibility in the levels of service to be delivered for various customers?
• Will the SLA structure require much duplication of effort?
• Who will sign the SLAs?

Three types of SLAs structures that are discussed within ITIL® are service-based, customer-based and multi-level or hierarchical SLAs.

Figure 5.D – SLA structures

Many different factors will need to be considered when deciding which SLA structure is most appropriate for an organization to use.

Typical Multi-level SLA Structure components:

1. 1. Corporate level: All generic issues are covered, which are the same for the entire organization.   

Example: The Corporate Security Baseline, e.g. Passwords, ID cards etc.

1. 2. Customer level: Those issues specific to a customer can be dealt with.

Example: Security requirements of one or more departments within the organization are higher e.g. the financial department needs higher security measures.

1. 3. Service Level: All issues relevant to a specific service (in relation to customer) can be covered.

Example: The email services for a particular department needs encryption and secure backups.

Using a multi-level structure for a large organization reduces the duplication of effort while still providing customization for customers and services (by inheritance).

Figure 5.B – SLAs, OLAs and UCs

Negotiating and agreeing upon the SLAs and OLAs is the responsibility of Service Level Management. Supplier Management is responsible for negotiation and agreeing upon UCs with external suppliers. These two processes must communicate to ensure that the UCs do align with and support the SLAs in place.

What are the roles of OLAs and UCs?
They are agreements with other internal areas of the organization (e.g. the Service Desk, human resources) and external suppliers on how they support the IT organization in meeting the SLAs with customers.

Figure 5.C – How SLAs, OLAs and UCs fit together

Question:

An organization is planning to formalize its IT Service Management practices, and wants to implement Service Level Management. At present, there is very little documentation of the services currently being provided to customers.

According to the ITIL®® framework which of these documents should be developed first?

Answer: Normally the Service Catalog should be produced first because we need to define and agree what we actually are providing, and then we can map the customer requirements to the Service Catalog to see what gaps or redundant services exist. By rushing in to the creation of SLAs, it is likely they will develop into complex or inaccurate representations of service levels, and not help to manage the relationship between the service provider and customers.

Although Service Level Agreements are implemented in a wide variety of fashions, the guiding principle is that they are a written agreement between an IT service provider and the IT customer(s), defining the key service targets and responsibilities of both parties.

The key word here is agreement, in that SLAs should not be used as a way of holding one side or the other to ransom. When SLAs are viewed in a positive nature, a way of continually improving the relationship between provider and customers, mutually beneficial agreements will be developed. Viewing SLAs as just contracts can contribute to development of a ‘blame culture’ by both parties.

The level of technical detail included within the SLA will also vary, depending on the type and nature of the customer. Some customers may be an IT Service Provider themselves, others will be purely business focused. To be successful in all these scenarios, SLAs must be written in such a way that they are clear and unambiguous for both parties, leaving no room for confusion or misinterpretation. They certainly won’t be perfect from the moment they are developed, so a continual cycle of review and revision should seek to improve the quality and effectiveness of SLAs over time.