ITIL v3 (Information Technology Infrastructure Library)/Service Design

Another view of ITIL V3, Service Design volume has its main focus on definition of service itself, based on how it is expected to be from service strategy. Its goal is to design and develop IT services, no matter if it is design of a new service or improvement of an existing one.

Design of a service is not solely based on technology, but addresses a solution interacting largely with business and technical environments, and takes in consideration the whole supply chain required to support the planned service.

Processes for Service Design of ITIL V3 are:

• Design Coordination
• Service Catalogue Management
• Service Level Management (SLM)
• Availability Management
• Capacity Management
• IT Service Continuity Management (ITSCM)
• Information Security Management
• Supplier Management

Service Design

Principles and Key terms

Design of a service has the following principles:

• Portfolio service project
• Business requirements
• Technological project
• Processes project
• Measurement project, including IT-KGI, KGI and KPI

Key terms to design a service include:

• Critical success factor: how to define that service providing succeeds.
• Downtime: one of the key terms for warranty, means how many times a service was unavailable for the client.
• KPI: to define Key Performance Indicators for the service.
• Maintainability: how easy is to maintain service.
• OLA/UC: service agreement with internal or external suppliers.

Four Ps

Four Ps for Service Design are:

• People
• Process
• Product/technology
• Partners/suppliers

Delivery model options

List of delivery model strategies are:

• Insource: when service uses internal resources for all service phases.
• Outsource: this model is set through a well defined portion of service-design. It may use the ASP model, defined below.
• Co-source: it's a combination of insource and outsource.
• Partnership or multi-source: agreement between two or more organizations to work together providing service.
• Business Partner Outsourcing (BPO): relocates entire business function to an external organization that will provide and manage service. This model generally means a more operational partner, like accounting or call-center.
• Application Service Provider (ASP): through a formal agreement an organization provides computer-based software through a network. It is also known as on-demand software/applications.
• Knowledge Partner Outsourcing (KPO): service provided by a thinking partner, it is one step ahead of BPO. Generally provides a specific field expert-knowledge.
• Managed Service Provider (MSP): more broadly end-to-end service partner. This model is not defined in ITIL V3.

Partners agreement

Before closing an agreement with a customer, there is a need to close an agreement with partners. It is not possible to guarantee that a service will be able to return in one day, if that service requires an interaction with a supplier that needs two days.

ITIL defines two forms of agreement:

• Operational Level Agreement (OLA): an agreement between an IT service provider and an internal service provider (part of same the organization).
• Underpinning Contract (UC): an agreement between an IT service provider and an external service provider (outside of the organization).

Measurement

Design may measure a process service by:

• Progress: milestones & deliverables.
• Compliance: according to governance standards.
• Effectiveness: accuracy & correctness.
• Efficiency: optimized use of resources.

A service may be measured by three ways:

• Prerequisite For Success (PFS): an activity that needs to be completed. Generally a PFS is an input for another process.
• Critical Success Factor (CSF): what defines a service to achieve success.
• Key Performance Indicator (KPI): indicators to define that a service has achieved success.

ITIL V3 suggests only KPI, which was improved with elements based on COBIT recommendations.

Processes

Service design has 10 processes, as depicted below.

Service Catalogue Management

Ensures production and maintain of Service Catalogue with accurate information on all operational services and those being prepared to be run operationally. It contains information on all service Service Management processes: service details, current status and service's interdependencies.

There is a clear difference between Service Catalogue and Business Services (services visible to the customer, defined by SLAs) and Supporting Services (services visible only inside the IT organization, defined by OLAs and UCs).

No sub-processes are specified for Service Catalogue Management according to ITIL V3.

Service Level Management

Objective of SL management is to negotiate Service Level Agreements with the customers and to design services in accordance with the agreed service level targets. Service Level Management is also responsible for ensuring that all Operational Level Agreements (OLA) and Underpinning Contracts (UC) are appropriate, and to monitor and report on service levels.

Service Level Management is the glue for Service Level Agreement (SLA), Service Improvement Process (SIP) and Service Level Requirements (SLR). SIP is an important part of Continuous Service Improvement (CSI) volume.

Service Level Requirements contains requirements from client viewpoint for a service and are the basis to reach a SLA. Requirements in SLR need to be defined in business terms, defining service level targets, mutual responsibilities, and other requirements specific to a certain customer or group of customers.

SLM Stages

SLM is defined through following stages:

1. Negotiation: where is defined SLR for service .
2. Finalization: where is defined SLA, after definition of OLA/UC.
3. Monitoring: service monitoring.
4. Report: service report, showing if service complies with SLA.
5. Revision: used as basis for SIP.

SLA Structure Levels

Structure levels for SLA may be:

• Corporation: when target is whole corporation.
• Client: when target is a specific client or group. E.g. financial department.
• Service: when target is not specific. E.g. is an internet service, when target is not solely a corporation nor specific client.
• Multilevel: SLA may be split into different levels, for different customers.

Risk Management

This process is about identification, assessing and controling risks through analyzing asset`s value, threats and how vulnerable each asset is to those threats.

Risk Management is composed of Business Impact and Risk Analyzes, Assessment of Required Risk Mitigation and Risk Monitoring.

<Risk Management is not a part of ITIL V3>

Capacity Management

To ensure that the capacity of IT services and the IT infrastructure is able to deliver the agreed service level targets in a cost effective and timely manner. Capacity Management considers all resources required to deliver the IT service, and plans for short, medium and long term business requirements.

Common metrics

Service-level agreements can contain numerous service performance metrics with corresponding service level objectives. A common case in IT Service Management is a call center or service desk. Metrics commonly agreed to in these cases include:

• ABA (Abandonment Rate): Percentage of calls abandoned while waiting to be answered.
• ASA (Average Speed to Answer): Average time (usually in seconds) it takes for a call to be answered by the service desk.
• TSF (Time Service Factor): Percentage of calls answered within a definite timeframe, e.g., 80% in 20 seconds.
• FCR (First Call Resolution): Percentage of incoming calls that can be resolved without the use of a callback or without having the caller call back the helpdesk to finish resolving the case.
• TAT (Turn Around Time): Time taken to complete a certain task.

Uptime Agreements are another very common metric, often used for data services such as shared hosting, virtual private servers and dedicated servers. Common agreements include percentage of network uptime, power uptime, amount of scheduled maintenance windows, etc.

Many SLAs track to the ITIL specifications when applied to IT services.

Availability Management

To define, analyze, plan, measure and improve all aspects of the availability of IT services. Availability Management is responsible for ensuring that all IT infrastructure, processes, tools, roles, etc., are appropriate for the agreed availability targets.

Sub-processes are:

• Design Services for Availability
• Availability Testing
• Availability Monitoring and Reporting

Measurement

Some availability measurements, that may be included in SLA:

• Mean-Time-Between-Failure (MTBF): elapsed time between a service gets up and down.
• Mean-Time-To-Repair (MTTR): elapsed time to repair a configuration item or IT service.
• Mean-Time-Between-System-Incidents (MTBSI): elapsed time between detection of two consecutive incidents.
• Mean-Time-To-Restore-Service (MTRS): elapsed time from the detection of an incident until it gets up.

Based on terminology above,

MTBSI = MTBF + MTRS

, and availability can be calculated by

A = MTBF / (MTBF + MTTR)

.

MTRS is different from MTTR in the way that MTTR would mean time to repair a configuration item, and MTRS would mean time to restore service after repair. E.g. MTTR=time to change CPU of a node, MTRS=time to restore all services provided by that node.

IT Service Continuity Management

IT Service Continuity Management (ITSCM) aims to manage risks that could seriously impact IT services. This ITIL process ensures that the IT service provider can always provide minimum agreed Service Levels, by reducing the risk from disaster events to an acceptable level and planning for the recovery of IT services. ITSCM should be designed to support Business Continuity Management.