Service Design

The Service Design book provides guidance for the design and development of
services and processes, covering design principles and methods for converting
strategic objectives into portfolios of services and service assets.
4 Service Catalog Management (SCM)

5 Service Level Management (SLM)

6 Supplier Management

7 Capacity Management

8 Availability Management

9 IT Service Continuity Management (ITSCM)

10 Information Security Management

C Design Coordination
2

Created by PelegIT, Ltd. – www.pelegit.com, - All Rights Reserved

Every time a new service solution is produced, it
needs to be checked against the rest of the
Service Portfolio to ensure that it will integrate
and interface with all other services in
production.


Service Design Package
Business Requirements Organizational Readiness Assessment
Service Applicability User Acceptance Criteria
Service Contracts Service Program
Service Functional Requirements Service Transition Plan
Service Level Requirements Service Operation Plan
Service Design & Topology Service Acceptance Criteria


5


Service Level Agreement (SLA):
(ITIL Continual Service Improvement, CSI)

An agreement between an IT service provider and a customer. A SLA describes the IT
service, documents service level targets, and specifies the responsibilities of the IT
service provider and the customer. A single agreement may cover multiple IT services
or multiple customers. (OLA)

7


Operational Level Agreement (OLA):
(ITIL Service Design, SD & ITIL Continual Service Improvement, CSI)

An agreement between an IT service provider and another part of the same
organization. It supports the IT service provider’s delivery of IT services to customers
and defines the goods and services to be provided and the responsibilities of both
parties. For example their could be an OLA:

• Between the IT service provider and a procurement department to obtain
hardware in agreed time frame
• Between the service desk and a support group to provide incident resolution
in agreed times

8


Underpinning Contract (UC):
(ITIL Service Design, SD)

A contract between service provider and a third party. The third party provides goods
and services that support delivery of an IT service to the customer. The UC defines
targets and responsibilities that are required to meet agreed service level targets in
one or more SLA’s.

9


Service Catalogue:

A written statement of available IT services, default levels, options, prices and
identification of which business processes or customers use them.

10


Service Level Requirements (SLR):

Detailed recording of customer’s needs, forming the design criteria for a new or
modified service.

11


Service Level Targets (SLT):
(ITIL Service Design, SD, Continual Service Improvement, CSI)

A commitment that is documented in a service level agreement (SLA). Service level
targets (SLT) are based on service level requirements (SLR) , and are needed to ensure
that the IT service is able to meet business objectives. They should be SMART, and are
usually based on key performance indicators (KPI).

12


SMART:
(ITIL Service Design, SD, Continual Service Improvement, CSI)

An acronym for helping to remember that targets in service level agreements and
project plan should be:

13


Capability:

The ability of an organization, person, process, application, IT service or other CI to carry
out an activity. Capabilities are assets of an organization. Capabilities represent an
organizations ability to coordinate, control and deploy resources to produce value.

14


Configuration Item (CI):
(ITIL Service Transition, ST)

Any component or other service asset that needs to be managed in order to deliver an IT
service. Information about each CI is recorded in a configuration record within the
Configuration Management System (CMS) and is maintained throughout it’s lifecycle
by Service Asset and Configuration Management (SACM).

15


Key Performance Indicator (KPI):
(ITIL Service Design, SD & ITIL Continual Service Improvement (CSI))

A metric that is used to help manage an IT service, process, plan, project or other
activity. Key performance indicators are used to measure the achievement of critical
success factors (CSF) Many metrics may be measured, but only the most important of
these are defined as key performance indicators and used to actively manage and report
on the process, IT service or activity. They should be selected to ensure that efficiency,
effectiveness and cost effectiveness are all managed.

16


Critical Success Factor (CSF):

Something that must happen if an IT service, process, plan, project or other activity is to
succeed. Key performance indicators (KPI) are used to measure the achievement of
each critical success factor.

For example, a critical success of “protect IT services when making changes” could be
measured by key performance indicators (KPI) such as “percentage reduction of
unsuccessful changes”, “percentage reduction in changes causing incidents” etc.

17


Availability:

Ability of an IT service to other configuration item to perform its agreed function when
required. Availability is determined by reliability, maintainability, serviceability,
performance and security.

Agreed Service Time (AST) - Downtime
Availability (%) =
Agreed Service Time (AST)

Downtime is defined as the service being unavailable only during
Agreed Service Time (AST)

18


Maintainability:

A measure of how quickly and effectively an IT service or other configuration item can
be restored to normal working order after a failure. Maintainability is often reported as
Mean Time to Restore Service (MTRS).

19


Information Security Management System (ISMS):

The framework of policy, processes, functions, standards, guidelines and tools that
ensures an organization can achieve its information security management objectives.

20


Mean Time Between Failures (MTBF):

A metric for measuring and reporting reliability. MTBF is the average time that an IT
service or other configuration item can perform it’s agreed function without
interruption.

21


Goal: The primary goal of Service Level Management is to
ensure that an agreed level of IT service is provided for all
current IT services, and that future services are delivered to
agreed achievable targets.

During the design phase SLM performs the following:

• Designs and plans the SLM processes and Service Level Agreement (SLA)
structure.
• Determines the Service Level Requirements (SLR)
• Negotiates and Agrees upon relevant Service Level Targets (SLT) with customers
to produce SLA’s
• Negotiates and agrees upon the support elements required by internal IT groups
and External Suppliers to produce Operational Level Agreements (OLA = Internal)
and Underpinning Contracts (UC = External)

23


SLA’s, OLA’s and UC’s
Customers

Service Level Management (SLM)

Supplier Management
OLA UC

SLA

Internal External
Supplier Supplier

24


SLA Questions

Will the SLA structure allow flexibility in the levels of service to
be delivered to various customers?

Will the SLA structure require much duplication of effort?

Who will sign the SLA?

25


Service Level Agreement Structures

Customer 1

Service A

Customer Based SLA
26



Customer 1 Customer 2 Customer 3

Service A

Service Based SLA
27


Corporate Level

Customer 1 Customer 2

Service A Service B

1. Corporate Level – All generic issues are covered, which are the same for the entire organization.
(Corporate Security Baseline: passwords, ID Cards etc.)

2. Customer Level – Those issues specific to a customer can be dealt with. (Security Requirements
of one or more departments within the organization are higher. Financial Department may have
higher security needs.)

3. Service Level – All issues relevant to a specific service (in relation to customers) can be covered.
(The e-mail services for a particular department needs encryption and secure back-ups

Multi-Level Based SLA 28


SLA is a written agreement between an IT service provider and the IT customers,
defining the key service targets and responsibilities of both parties.

SLA’s should not be used as a way to hold one side or another for ransom.

A mutually beneficial agreement should be reached – otherwise the SLA could
quickly fall into dispute and a “Blame Culture” could develop.

SLA’s should be used as a tool for teamwork and cooperation between the IT
customers and the service provider.

29


OLA is an agreement between the IT service provider and anther part of the same
organization.

OLA should contain targets that underpin those within an SLA to ensure that
targets will not be breached by an failure of supporting activities.

30


When talking about OLA, it is an agreement between the internal support
groups of an institution that supports SLA.

According to the Operational Level Agreement, each internal support group has
certain responsibilities to the other group. The OLA clearly depicts the
performance and relationship of the internal service groups.

The main objective of OLA is to ensure that all the support groups provide the
intended Service Level Agreement.

1. Service Level Agreement focuses on the service part of the agreement, like
uptime of services and performance. On the other hand, Operational Level
Agreement is an agreement in respect to maintenance and other services.

2. The Service Level Agreement is basically a contract between a service
provider and a customer. OLA is an agreement between the internal support
groups of an institution that supports SLA.

31


The agreement between service provider and supplier is critical.

For service provider and supplier the UC should expose risks that need to be
addressed and must be comprehensive and practical, covering a wide variety
of risks, including financial, business reputation, operational, regulatory and
legal.

A comprehensive agreement minimizes the risk of disputes arising from a
difference in expectations.

A good UC should be adaptable and maintainable with a minimum amount of
renegotiation.

32


Goal – Mange suppliers and the services they supply, to
provide seamless quality of IT services.


Supplier Service Improvement Plan (SSIP):

Used to record all improvement actions and plans agreed between suppliers and service
providers.

36


Supplier Survey Reports:

Feedback gathered from all individuals that deal directly with suppliers throughout their
day to day roles. Results are collated and reviewed by Supplier Management to ensure
consistency in quality of service provided by suppliers in all areas.

37


Supplier & Contract Performance Reports:

Used as input for the Supplier Contract review meetings to manage the quality of the
service provided by suppliers and partners. This should include information on shared risk
when appropriate.

38


(Supplier & Contract Database - SCD)
Supplier and Contract Management Information System (SCMIS):

A set of tools, data and information that is used to support supplier management. See
also Service Knowledge Management System (SKMS).

39


Co-Sourcing An informal combination of insourcing and outsourcing, using a number
of outsourcing organizations working together to co-source key
elements within the lifecycle.

Partnership or Formal arrangements between two or more organizations to work
Multi-Sourcing together to design, develop, transition, maintain, operate and or
support IT services. The focus here tends to be on strategic partnerships
that leverage critical expertise or market opportunities.

Business Formal arrangements where an external organization provides and
Process manages the other organizations entire business processes or functions
Outsourcing in a low cost location. Common examples include: payroll and call
centers.

40


Knowledge This is a new enhancement of Business Process Outsourcing, where
Process external organizations provide domain based processes and expertise
Outsourcing rather then just process expertise and as such this requires advanced
analytical and specialized skills from the outsourcing organization.

Application Where external organizations provide shared computer based services to
Service customer organizations over a network. The complexities and costs of
Provision such shared software can be reduced and provided to organizations that
could otherwise not justify he investment. (Example: AS400)

41


Goal – Ensure that a service catalogue is produced,
maintained and always accurate information on operational
services and those ready for deployment.


Business Service Catalogue
Contains details of all IT services defined in the context of customers, together with
relationships to the business units and the business processes they support. This
information is used to form the customer view of the service catalogue. In cases
where the customer is a IT organization the technical view may be expanded.

Technical Service Catalogue
Contains details of all IT services delivered to the customer. However by
compression the technical service catalogue includes records of relationships that
exist with other supporting services, shared services, components and configuration
items (CI) necessary for deliver of the service to the business.


Service Catalogue
Business/Customer Service Catalogue View

Business Business Business
Process 1 Process 2 Process 3

Service A Service B Service C Service D Service E

Support
Hardware Software Network Mainframe Data
Services

Technical Supporting Service Catalogue View

Links to related
Information

Service Asset/Configuration Records

Key = Customer facing services = Supporting services
45


Business/Customer service catalogue view

This view contains details of all the IT services delivered to the customer.
(customer facing services), together with relationships to the business units and
business processes.

Technical/Supporting service catalogue view

This contains details of all the supporting IT services, together with
relationships to the customer-facing services they underpin and the
components, CI and other supporting services necessary to provision the service
to customers.

46


Service Catalogue
Wholesale Service Catalogue View Retail Service Catalogue View

Wholesale Wholesale Retail Retail
Customer 1 Customer 2 Customer 1 Customer 2

Service A Service B Service C Service D Service E

Support
Hardware Software Network Mainframe Data
Services

Supporting Service Catalogue View

Links to related
Information

Service Asset/Configuration Records

Key = Customer facing services = Supporting services
47


Wholesale customer view

This view contains details of all the IT services delivered to the wholesale
customer.

Retail customer view

This view contains details of all the IT services delivered to the retail customer.

Technical/Supporting service catalogue view

This contains details of all the supporting IT services, together with
relationships to the customer-facing services they underpin…

Notice Service C is shared.
48


There is no single correct way to structure and deploy a
service catalogue.

49


Consequences of Reactive Behavior

$$
Capacity
Incident
To many resources &
capabilities = Increased Cost
$
Incident
To few resources & capabilities =
Decreased Performance
Time
Needs

Management Ideal


Business Capacity Management
• Manages capacity to meet future business requirements for IT services
• Identifies changes occurring in the business to asses how they might impact
capacity and performance of IT services.
• Plans and implements sufficient capacity in an appropriate timescale
• Should be included in Change Management and Project Management activates.

Service Capacity Management
• Focuses on managing ongoing service performance as detailed in the Service Level
Agreements (SLA)
• Establishes baselines and profiles for use of Services, including all components and
sub-services that affect the user experience.

Component Capacity Management
• Identifies and manages each of the individual components of the IT infrastructure
(CPU, Memory, Disks, Network Bandwidth, Server Load etc.)
• Evaluates NEW technology and how it might be leveraged
• Balances loads across resources for optimal performance of services.


Activities of Capacity Management
Business capacity Strategic
management

Storage of capacity
management data
Management

Application
Modeling
Activities

Demand
Iterative

Sizing
Service capacity
Tactical
management

Component capacity
Operational
management

Capacity Production of capacity plan
management
sub-processes

Reports on all aspects of
capacity management CMS
53


1. Performance Monitoring - Measuring, monitoring and tuning
performance of IT infrastructure components
2. Demand Management – Short term reactive implementation of
strategies considered in Service Strategy to manage current demand.
3. Application Sizing – Determining the hardware or network capacity to
support new or modified applications and the predicted workload.
4. Modeling – Used to forecast the behavior of the infrastructure under
certain conditions (e.g. if the number of users is doubled, if a network link
fails)
5. Tuning – Modifications made for better utilization of the current
infrastructure
6. Storage of Capacity Management Data
7. Capacity Planning
8. Reporting


Goal – Ensure the level of service availability delivered in all
services is matched or exceeds the current and future agreed
needs of the business in a cost effective manner.


Security

Services, systems and information should be made available to authorized users at the
authorized times (see Information Security Management and Access Management)

© Crown copyright 2011. Reproduced under license from OGC. - Created by PelegIT, Ltd. – www.pelegit.com, - All Rights Reserved

Reliability

Freedom from operational failures.


Resilience

The ability to withstand a failure. (example: redundant components)


Maintainability

Internal; The ability of an IT component to be retained in or restored to, an operational
state. This will be affected by the skills, knowledge and availability of IT staff, as well as
various other ITSM tools for detecting and managing disruptions.


Serviceability

External; The contractual arrangements made with external suppliers that document
their obligations for supporting the availability of services. Measured by Availability,
Reliability and Maintainability of IT services and components under the control of the
external suppliers.


Vital Business Function

The business critical elements of the business process supported by an IT service.
Typically this will be where more effort and investments will be spent to protect these
vital business functions.


30 Minute

Outage

60 Minute

Outage


1. 30 Minute outage during peak hours, overtime being paid to
staff, urgent report being required.

2. 60 Minute outage on a weekend, holiday, off-peak hours, when
the service was not required

3. 30 Minute outage of critical IT services

4. 60 Minute outage of non-critical IT services

5. 30 Minute unplanned outage

6. 60 Minute planned outage (maintannce)


Mean Time between Failures (MTBF) or Uptime
Average time between the recovery from one incident and the occurrence of the
next incident, this relates to the reliability of the service.

Mean Time to Restore Service (MTRS) or Downtime
Average time taken to restore a CI or IT service after a failure
This is measured from the time when the CI or IT service fails until it is FULLY
restored and is able to deliver normal functionality.

Mean Time Between Service Incidents (MTBSI)
Average time between the occurrence of two consecutive incidents
Sum of MTRS + MTBF

High Ratio of MTBF / MTBSI indicates there are many minor faults.

Low Ratio of MTBF / MTBSI indicates there are many major faults.


Goal – Disaster recovery planning


Disaster

NOT part of the daily activities and requires a separate system.


Business Continuity Management (BCM)

Strategies and actions to take place to continue Business Processes in the case of a
disaster.


Business Impact Analysis(BIA)

Quantifies the impact of loss of IT services would have on the business.


Risk Assessment

Evaluates Assets, threats and vulnerabilities that exist to business processes, IT
services, IT and infrastructure and other assets.


Counter Measure

Measures to prevent or recover from a disaster.


Manual Workaround

Using Non-IT based solutions to overcome a IT service disruption.


Gradual Recovery

Aka Cold Standby or Cold Site (> 72 Hours to recover from a disaster)


Intermediate Recovery

Aka Warm Standby or Warm Site (24 - 72 Hours to recover from a disaster)


Immediate Recovery

Aka Hot Standby or Hot Site (>24 Hours to recover from a disaster, usually implies 1-2
hours to recover from disaster.)


The recovery site should be a minimum of 35 Miles from the
organizations main site.


Stage 1
Define Scope of BCM
Initiation

Business Impact Analysis
Stage 2
Requirements Risk Assessment
& Strategy Business Continuity Strategy

Organization Imp. & Planning

Stage 3
Stand-by arrangements and Risk Reduction Measures
Implementation
Recovery plans and procedures
Initial Testing

Stage 3
Operational
Management
Assurance


Goal – Security is present and aligned with the business
needs.


Availability

Ability of an IT service to other configuration item to perform its agreed function when
required. Availability is determined by reliability, maintainability, serviceability,
performance and security.


Confidentiality

A security principle that requires that data should only be accessed by authorized people.


Integrity

A security principle that ensures data and CI’s are modified only by authorized personnel
and activities. Integrity considers all possible causes of modification, including software
and hardware failures, environmental events and human intervention.


Security Baseline

The security level adopted by the IT organization for its own security and from the point
of view of “Good Diligence”
Possible to have multiple baselines


Security Incident

Any incident that may interfere with achieving the SLA security requirements;
materialization of a threat


Information Security Management (ISM)

The process responsible for ensuring that the confidentiality, integrity and availability
(CIA Triangle) of an organization’s assets, information, data and IT service match the
agreed needs of the business.


Security Policy

External Influence
Business Drivers
Risk Analysis

Planning

Operational
Measures

Evaluation and
Audit


Information Security Control Process

92


4 P’s
People
Products /
Processes
Technology
Partners /
Suppliers

93


94


Service Design

More Related Content

What's hot

Similar to Service Design

More from Peleg

Service Design