Purpose, Objectives and Scope of Service Design

Service Design is involved in both planning new services and changing existing services to
ensure service strategy are fulfilled.
A service needs to provide utility and warranty (level of service, including security, service
continuity, capacity, etc.) in order to deliver value. Poor design means the service cannot
deliver both utility and warranty.
Service Design requires planning (e.g. risk management) to be successful.
Good design aligns the outcome to business objectives with a lower total cost of ownership
of the service and smooth service transition and operation. It also allows continual
improvement of service by gathering useful metrics. The processes are also designed to be
efficient and effective.

Purpose of Service Design

The purpose of Service Design is to deliver a new service / service amendment that can
deliver the strategic outcome required, the design of both the services and the service
management processes need to be included.
Need to ensure the service will run within budget and meet/exceed customer requirements.

Objectives of Service Design

Deliver a service that would required little improvement later on by learning from lessons
learned of previous projects.

Scope of Service Design

Consider not only the current requirements but also future needs (e.g. take advantage of
technical advancements, can be easily adapted to future needs)
Describes how to identify requirements (functional and service level) and ensure the
delivery of such requirements
Processes include:
Design coordination
Service catalog management
Service level management
Availability management
Capacity management
IT service continuity management
Information security management
Supplier management
Note: these processes may be involved in more than one phase in the lifecycle

Key Output of Service Design Service Design Package

A service design package consists of one or more documents that describe all aspects of the
service throughout its lifecycle, for use in transition (as requirements for testing) and
operation of the service.
Documents of a service design package may include:
Original agreed business requirements for the service (but not the organizational
business strategy)
How the service will be used
Key contacts and stakeholders
Functional requirements
Management requirements
Service level requirements
Technical design of the new or changed service including hardware, software,
networks, environments, data, applications, technology, tools, and documentation
Sourcing strategy
New or changed processes required to support the service
Organizational readiness assessment need for training and supplies
Service lifecycle plan, including the timescales and phasing, for the transition,
operation, and subsequent improvement of the new service
Service program an overall plan of the lifecycle of the service
Service transition plan
Service operational acceptance plan
Service acceptance criteria (SAC)
Another output is service solution

Service Composition
Services are composed of the following elements (utility, warranty, resources and capabilities):
the business processes involved
utility requirements as well as governance / reporting requirements
service level agreement / supporting requirements
technical components and how they are linked as well as environmental requirements
the applications to provide functional requirements as well as the data required
dependencies with other services
service management processes

Key Elements of Service Design

People
Processes
Products

 Partners

People
the availability and capability of the people using or supporting the service
training needs analysis and budgeting for training are to be considered

Processes
new service may require additional processes (e.g. authorization / procurement services)
all processes should be documented with the interfaces in between
identify changes required to existing services

Products
the service itself plus the technology and tools used in design or support

Partners
specialist suppliers / vendors which are managed through supplier management process

Major Aspects of Service Design

Service solutions
Tools and systems for management information
Architectures
Measurement systems
Processes

Service Solutions
the functionality offered by the service itself
deliver the solution within the technical and financial constraints, and corporate rules
the approach must be structured but flexible enough to accommodate future changes

Tools and Systems for Management Information

these are used to support and automate processes (e..g quality management system,
information security system)
ensure the service will integrate with existing management tools and systems

Architectures
compatible with existing architectural platform and technical standards
[definition] Architecture is defined as the fundamental organization of a system, embodied
in its components, their relationships to each other and to the environment, and the
principles guiding its design and evolution.

Measurement Systems
collecting metrics to allow assessments for efficiency and effectiveness

Processes
any services will require processes existing or new
either change the processes to suit the service design or vice versa

Service Level Management Process

Purpose of SLM: ensure that all current and planned IT services are delivered to
agreed achievable targets (service level agreement) using an objective
measurement through discussion and negotiation with customers
primarily concerned about the warranty aspects (security, capability, availability,
service continuity), if accurately captured, will translate into quality of the service
Objectives of SLM
define, document, agree, monitor, measure, report, and review how well the IT
service is delivered
ensure specific and measurable targets are developed
work with business relationship management to build a working relationship with the
customers
ensure customers have a clear and unambiguous expectation of the service level
ascertain customer satisfaction through surveys, interviews, etc. with an agreed
satisfaction score
improve services through a cost-effective and proactive way
Scope of SLM
includes the performance of existing services and the definition of required service
levels for planned services (service level requirements) for expectation management
agreed in the form of service level agreement (SLA) for warranty
when 3rd parties are involved, operation-level agreements (OLA for internal
units) and underpinning contracts (external) are also required
NOT including utility
review with customer for the service quality (better with face-to-face meetings), SLA
might be re-negotiated depending on the circumstances
Activities involved:
Designing SLA frameworks
Using the Service Catalog as an aid, SLM must design the most appropriate
SLA structure to ensure that all services and all customers are covered in a
manner best suited to the organizations needs, e.g. multi-level SLA, etc.

 Determine, negotiate, document and agree requirements for new or changed

services in SLRs, and manage and review them through the service lifecycle
into SLAs for operational services.
Once the Service Catalog has been produced and the SLA structure has been
agreed, a first SLR must be drafted. It is advisable to involve customers from
the outset, and to produce a first outline draft of the performance targets and
the management and operational requirements, as a starting point for more
detailed and in-depth discussion.
Monitor and measure service performance achievements of all operational
services against targets within SLAs.
Measure and improve customer satisfaction.
There are a number of important soft issues that cannot be monitored by
mechanistic or procedural means, such as customers overall feelings. For
example, even when there have been a number of reported service failures,
the customers may still feel positive about things, because they may feel
satisfied that appropriate actions are being taken to improve things.
Review and revise underpinning agreements and service scope.
IT service providers are dependent to some extent on their own internal
technical support teams or on external partners or suppliers. They cannot
commit to meeting SLA targets unless their own support teams and suppliers
performances underpin these targets.
Produce service reports.
As soon as the SLA is agreed and accepted, monitoring must be instigated
and service achievement/misses reports must be produced. The SLA reporting
mechanisms, intervals and report formats must be defined and agreed with the
customers. Exception reports are needed whenever there are incidents.
Conduct service reviews and instigate improvements within an overall
Service Improvement Program/Plan (SIP).
Periodic review meetings must be held on a regular basis with customers (or
their representatives) to review the service achievement in the last period and
to preview any issues for the coming period. It is normal to hold such
meetings monthly, or as a minimum, quarterly.
Review and revise SLAs, service scope and underpinning agreements.
All agreements and underpinning agreements, including SLAs, underpinning
contracts and OLAs, must be kept up-to-date. They should be brought under
Change and Configuration Management control and reviewed
periodically, at least annually, to ensure that they are still current and
comprehensive, and are still aligned to business needs and strategy.
Develop and document contacts and relationships with the business,
customers and stakeholders.
It is very important that SLM develops trust and respect with the business,
especially with the key business contacts. Using the Service Catalog,

especially the Business Service Catalog element of it, enables SLM to be

much more proactive.
Develop, maintain and operate procedures for logging, action and resolving
all complaints, and for logging and distributing compliments.
The logging procedures are often performed by the Service Desk as they are
similar to those of Incident Management and Request Fulfillment.
Output of SLM: Service Level Agreement (SLA)
Mutli-level SLAs Service Level SLA (may include multiple classes e.g. gold,
silver, bronze), Customer Level SLA, Corporate Level SLA
Periodic review of the SLA is required
Red (target breached), amber (target threatened), green (target reached) are
commonly used in service level management monitoring charts (SLAM charts)
In case of identifying issues, service improvement plan (SIP) would need to be
drafted and agreed upon for further actions. The SLM would work with the CSI
manager on the issue.
Whether an SIP is required depends on the cost of improvement actions and the
business benefit
Interface with Other Processes
Business relationship management
This process ensures that the service provider has a full understanding of the
needs and priorities of the business and that customers are appropriately
involved/represented in the work of service level management.
Service catalogue management
This process provides accurate information about services and their interfaces
and dependencies to support determining the SLA framework, identifying
customers/business units that need to be engaged by SLM and to assist SLM
in communicating with customers regarding services provided.
Incident management
This process provides critical data to SLM to demonstrate performance
against many SLA targets, as well as operating with the fulfillment of SLA
targets as a CSF. SLM negotiates support-related targets such as target
restoration times and then the fulfillment of those targets is embedded into the
operation of the incident management process.
Supplier management
This process works collaboratively with SLM to define, negotiate, document
and agree terms of service with suppliers to support the achievement of
commitments made by the service provider in SLAs. Supplier management
also manages the performance of suppliers and contracts against these terms
of service to ensure related SLA targets are met.
Availability, capacity, IT service continuity and information security management
These processes contribute to SLM by helping to define service level targets
that relate to their area of responsibility and to validate that the targets are

realistic. Once targets are agreed, the day-to-day operation of each process
ensures achievements match targets.
Financial management for IT services
This process works with SLM to validate the predicted cost of delivering the
service levels required by the customer to inform their decision-making
process and to ensure that actual costs are compared with predicted costs as
part of the overall management of the cost effectiveness of the service.
Design coordination
During the service design stage, this process is responsible for ensuring that
the overall service design activities are completed successfully. SLM plays a
critical role in this through the development of agreed SLRs and the
associated service targets which the new or changed service must be designed
to achieve.

Key Concepts and Terms

Service Level Requirements (SLR)
represents what is required by the customer in an objective way for a particular aspect of the
service based on business objectives (e.g. checkout capability increase by 20% over the
existing system)
high level SLRs are formulated during Service Strategy to consider the value of the service
while details SLRs are developed during Service Design
need to be agreed with by both customer and IT development team
form an important part of the service design specifications
testing criteria need to be developed for testing

Service Level Agreement (SLA)

Based on the work done with SLR, SLA describes the service and the quality measures by
which the delivery of that service will be judged (in plain terms to avoid confusion), telling
what is and is not provided
signed by the provider and the customer and monitored by both through reporting (with
enough details)
trending in the service level must also be monitored to ensure quality
Contents of SLA:
description of the purpose and scope of the document (location, date, whats included
and not)
support service and period
level of availability, reliability, service continuity and security and the measurement
metrics (to reflect the level of service experienced by the customer)
If the service support involves other internal units or external parties, operation-level
agreements and underpinning contracts are also required before signing of the SLA

 Operation-level Agreements (OLAs) straightforward agreement to specify the

realistic level of support to another internal unit, legal jargons are not needed
Underpinning Contracts (UCs) contractual and therefore legally enforceable
agreements, sufficient monitoring and reporting are needed
Structure of SLA:
Service-based each SLA refers to only one service (organization-wide service)
Customer-based an SLA for a customer
Multilevel include corporate, customer and service levels

/////

Service Catalog Management Process

[definition] A service catalogue is a database or structured document with information
about all live IT services, including those available for deployment. The service
catalogue is part of the service portfolio and contains information about two types of IT
service: customer-facing services that are visible to the business and supporting services
required by the service provider to deliver customer-facing services.
The service catalogue has different views for different people (users, IT, etc.) two-view
(business service/technical service) or three-view (wholesale customer, retail customer and
supporting services).
Purpose: provide and maintain a single source of consistent information on all
operational / ready-to-deploy services, used by customers and IT, essential to service
management
Objectives
the production and maintenance of the service catalogue
documenting the details of the service, status, interfaces and dependencies (obtained
from Configuration Management System), often in service packages (solution)
the info is made available in a suitable format to authorized persons
Scope
all services in production or will be transitioned to production
create definitions and descriptions of services / service packages
may optionally include services that can be requested

Availability Management Process

Poor availability is the primary cause for customer dissatisfaction.
A firm understanding of the effect of downtime to business processes should be well studied
Customer satisfaction is not only about availability but the perception on how IT responds to
issues and understands business processes from customers perception
Vital Business Function (VBF) should have a high availability
[definition] Availability is the ability of an IT service or other configuration item to
perform its agreed function when required. Any unplanned interruption to a service
during its agreed service hours (also called the agreed service time, specified in the service
level agreement) is defined as downtime.
Availability Formula (use the agreed service time in calculation):

Since availability management is primarily concerned about customer satisfaction, the

definition on service uptime (whether it is end-to-end or just the service) should be agreed
by the customer by balancing the cost and availability
Need to identify vital business function (VBF) for high availability need to justify the higher
cost
Purpose: take the necessary steps (improvements) to deliver the availability requirements
defined in the SLA in a cost-effective way and timely manner, taking into accounts current
and future needs
Objectives
create annual or bi-annual plans for fulfilling availability requirements (useful for
budget allocation)
monitor availability
provide availability-related advice throughout service lifecycle
assess risks on availability for change requests
take proactive steps to improve and optimize availability of end-to-end services
Scope
covers the design, implementation, measurement, management, testing and
improvement of IT service and component availability (reduce availability issues
throughout the service lifecycle)
make sure availability is duly considered in service design
should be applied to all operational services and technology, particularly those
covered by SLAs.
monitor and measure availability according to SLA (if available)
include both reactive (monitoring by event management, investigating downtime
incidences) and proactive (identifying and managing risks) activities
all information is recorded in the availability management information system

 an ongoing process, finishing only when the IT service is decommissioned or retired

Concepts of availability:
[definition] Reliability is a measure of how long a service, component, or CI can
perform its agreed function without interruption measured by mean time between
failures / incidents
good quality components / good suppliers
Resilience: designing the service so that a component failure does not result in
downtime
with redundancy (component failure wont affect the system)
Maintainability: (internal) how quickly the fault can be overcome, measured by
mean time to restore service (MTRS)NOT mean time to repair (MTTR)

e.g. with spare parts on site

[definition] Serviceability is the ability of a third-party supplier to meet the terms of
its contract the time taken by the contractor to restore the service (external
including maintainability and/or reliability requirements)
involves two key elements:
Reactive activities These involve the monitoring, measuring, analysis and
management of all events, incidents and problems involving unavailability.
These activities are principally performed as part of the operational roles.
(Service Operation phase)
Proactive activities These involve the proactive planning, design and
improvement of availability. These activities are principally performed as part
of the design and planning roles. (Service Design phase)
service availability (end-to-end service) vs component availability
continuous availability = 100% availability, impossible to maintain

Information Security Management Process

[definition] Information security is the management process within the corporate
governance framework, which provides the strategic direction for security activities and
ensures objectives are achieved.
To identify and mitigate information (data stores, databases and metadata) security risks
Information security is integral to service design
Information security must be an integral part of all services and systems and is an ongoing
process that needs to be continuously managed using a set of security controls
Statistics show that the large majority of security incidents stem from human errors
(intended or not) or procedural errors, and often have implications in other fields such as
safety, legal or health

 Purpose
to ensure IT security meets the overall business security requirements through
availability, integrity and confidentially
information is made available to only authorized persons when needed
data integrity protected from corruption and unauthorized alternation
Objectives
to protect the interests of those relying on information, and the systems and
communications that deliver the information, from harm resulting from failures of
confidentiality, integrity, and availability.
Scope
all aspects of information security
define protection levels (including technical and physical) with security
policy and plans
identify risks and implement countermeasures
understand regulatory and organizational requirements
Output
Information Security Policy (produce and maintain), including:
Use and misuse of IT assets policy
An access control policy, a password control policy
An email policy, an Internet policy, an antivirus policy, a remote access policy
An information classification policy, a document classification policy
A policy for supplier accessing to IT service, information, and components
A copyright infringement policy for electronic material
An asset disposal policy
A records retention policy
Information Security Management System (ISMS) standards, management
procedures and guidelines supporting the information security policies
Available to all customers
Referred to in all SLRs, SLAs, OLAs, underpinning contracts and agreements
Educate all staff about the policy and their responsibilities
Need to be formally reviewed at least annually

Supplier Management Process

[definition] Supplier Management is the process responsible for obtaining value for money
from suppliers, ensuring that all contracts and agreements with suppliers support the
needs of the business and that all suppliers meet their contractual commitments.
Supplier performance is directly related to service performance, therefore in the service
design phrase
Purpose

 ensure suppliers provide value for money by managing the contracts with suppliers
driven by a supplier strategy and policy from Service Strategy
Objectives
ensure suppliers deliver the service paid for which aligns to the business objectives
(as well as SLRs and SLAs)
control the cost of the contract by using objective selection criteria
manage relationship with suppliers the relationship is owned by an individual
within supplier management
Scope
select supplier and agree to the terms of the contracts
review contracts for improvement
monitor and manage supplier performance especially the suppliers providing critical
services through supplier categorization strategic, tactical, operational and
commodity suppliers
risk identification
Output
supplier policy

Capacity Management Process

[definition] Capacity Management is responsible for ensuring that the capacity of IT
services and the IT infrastructure is able to meet agreed current and future capacity and
performance needs in a cost-effective and timely manner.
Purpose
understand current and future service capacity (both hardware and software) needs
and ensure delivery of that level of service
one way to ensure future need is to allow easy and timely increase in capacity
when needed
Objectives
develop a detailed plan on the current and expected future requirements and actions
steps to fulfill these
consider implication of change requests on capacity
take proactive measures to improve performance at a reasonable cost
Scope
ensure sufficient capacity all the time (including seasonal fluctuations)
reduce capacity to save costs if service need dwindles
include technical, application, operation and human resources consideration
monitor pattern of business activity to understand the demands
suggest and enact proactive improvements through metrics feedback from the service
Subprocesses

 Business Capacity Management to calculate and forecast needs according to the

business plan
Service Capacity Management to understand how the use of individual live
services vary over time and deliver agreed capacity for individual services
Component Capacity Management to understand the utilization and capabilities
of all components for end-to-end service, to clear bottleneck
Output
Capacity Plan
captures the current and future requirements and proposes action steps for the
12 to 18 months ahead and to be reviewed at least annually
contents
introduction current capacity and issues, scope of the plan,
assumptions
management summary
possible scenarios reasons, capacity requirements and possible
outcomes (forecast) for individual services
recommendation

IT Service Continuity Process

IT service continuity management (ITSCM) is responsible for the continuity of the IT
services required by the business in times of disasters or extreme events to recover the IT
services. (Less significant incidents are dealt with by Incident Management Process.)
Included as one element of the business continuity plan (BCM) (also: human resources
continuity plan, financial management continuity plan, etc.)
Purpose
identify and manage the risks to the IT services
agree with the business for the minimum requirement of service in case of a disaster
Objectives
to reduce the chance of a disaster occurring at all by identifying the risks to IT
services and implementing cost-effective countermeasures to reduce or remove the
risk
to have a plan to restore an acceptable level of service according to agreed timescales
to review continuity plan from time to time by carrying out business impact analysis
(BIA) and risk re-assessments
Scope
focus on major events with a catastrophic impact (e.g. fire, flood, explosion, etc.)
provide the technical facilities to enable critical services to perform in time of
disasters
agree on policies and plans and test the plans
carry out business impact analysis to manage risks

 develop a strategy for service continuity to align to business continuity strategy

Subprocesses
Business Impact Analysis identify key services that need continuity at different
time of the day/month/year and clarify relative importance of individual services
Risk Assessment to compile a list of evaluated risks and propose countermeasures
These will ensure the provision of IT service continuity in a cost-effective way
Output
IT service continuity plan
adopt a lifecycle approach: initiation, requirements & strategy,
implementation, operation

Design Coordination Process

Service Design not only involves providing the utility but also the warranty (including
availability, security, continuity and capacity), which requires interface with other activities
and processes.
Purpose
carry out the coordination of the many different activities of service design to avoid
complications and misunderstanding
Objectives
to ensure all aspects of the design (architecture, processes and metrics) to provide
utility and warranty to meet business requirements for now and in future
to resolve conflicts in demand in case of simultaneous competing projects including
resources and time conflicts
to ensure everyone is clear about the requirements for handing over between different
lifecycle (e.g. service design package to transition phase)
to check whether all requirements are met and repeatable design practices are used
to reduce risks associated with complexity of projects
to compile the service design package within inputs from various processes
Scope
cover all activities in design and ensure consistency across them for new, existing
and retiring services (usually for large projects but according to guidelines of
individual organizations)
Output
service design package
suggestions for improvements for service design stage

///////////

Roles and Responsibilities in Service Management

roles may be combined, shared or spilt according to organization needs but there is only one
service owner and one process owner
role is NOT identical to the title
may adopt the Skills Framework for the Information Age (SFIA) for describing job
titles, roles and responsibilities
one task may touch several processes, e.g. submit a change request for a capacity issue
[definition] A role is a set of responsibilities, activities and authorities assigned to a
person or team. A role is defined in a process or function.

Service Owner
each service has a single service owner to accountable for delivering the service across all
process areas in an effective and efficient manner
accountable to customer and IT director / service management director
Responsibilities:
represent the service
work with all IT groups and process owners to deliver, support and improve the
service to the required standards according to business objectives
work with customers to understand the requirements, raise RFC and solve issues
monitoring and reporting
study impacts on the service by changes in other services / environments
maintain the service catalogue entry
ensure the process conforms to all policies
as a primary stakeholder in all the processes involved with the service

Process Owner
accountable for a single process (for all affecting services)
Responsibilities:
ensure the process works efficiently and effectively
develop the process strategy, policies and standards
design the process and improve its design, document the process
design the metrics to be collected and monitor for efficiency
ensure the availability of resources and capabilities to carry out the process
responsible for the consistency of the process application

Process Manager
responsible for managing the actual implementation of the process

 Responsibilities:
liaise with process owner
manage staff available and suitability
work with other process managers
monitor the process metrics to suggest improvement (seek feedback from process
practitioners)

Process Practitioner
responsible for carrying out the process activity (can also be the process manager) under the
guidance of the process manager
Responsibilities:
understand and complete the process activities
work with process stakeholders to ensure correctness
produce records of the process activities
identify improvements

The RACI Model

identify the responsibilities and accountabilities for each process task to avoid confusion
The RACI model:
Responsible people (at least one) who get the job done by actually carrying out
the task
Accountable one person (only one) who owns the task and ensures that the
quality of the work meeting the requirements
Consulted people (if any) who are consulted for their opinion / expertise over a
process activity
Informed people (if any)who are updated for the progress of the activity
The process owner is accountable for the end-to-end process (including all activities)
The RACI matrix
Person A Person B Person C Person D
Activity 1
AR
C
I
I
Activity 2
A
R
C
C
Activity 3
R
A
I
Activity 4
A
R
C
I
Clarifying the level of involvement within the process
Helping to understand what should be included in the operation-level agreement
Clarifying the workflow and handoff points
Points to note:
Ensuring that the process, roles, responsibilities and documentation are regularly
reviewed and audited
Interfacing with line management, ensuring that the process receives the necessary
staff resources. Line management and process owners have complementary tasks;

they need to work together to ensure efficient and effective processes. Often it is the
task of line management to ensure the required training of staff.

Competence and Training

Staff need to understand their role and the importance and the relationship to other processes
The ITIL Qualifications scheme provides a roadmap for staff to understand and apply the
ITIL framework
Education and training develop the capabilities of the people
Training include:
knowledge of the business
customer service skills and people skills
knowledge for their roles and the organization policies and procedures
analytical skills