The document serves as training reference material for IT service management following ISO/IEC 20000 standards, covering certification, examination formats, and training structure. It details the standard's sections, which include requirements for a management system, IT service management processes, and qualifications for certification. Additionally, the material emphasizes the importance of process orientation for managing IT services effectively and improving service quality.

1. Training Reference Material
IT Service Management
according to ISO/IEC 20000

2. 2
Welcome & Administration
• Structure of the training
• ISO/IEC 20000 certification and course outline
• Examination format
• Agenda

3. 3
Structure of the training
• Welcome & Administration
• Introduction to IT Service Management
• Content of ISO/IEC 20000, section 1-5 - basics
Content of ISO/IEC 20000-1
and ISO/IEC 20000-2
Scope
Terms and definitions
Requirements for a management system
Planning and implementing service management
Planning and implementing new or changed services
• Content of ISO/IEC 20000, section 6-10 – IT
Service Management Processes:
Resolution Process
Control Process
Release Process
Service Delivery Process
Relationship Process
• Classification and Preview
ISO/IEC 20000 certification
Related practices and standards
ISO/IEC 20000 Qualification Program

4. 4
ISO/IEC 20000 Qualification Program

5. 5
Examination Format
Already available in English, Dutch, French,
Portuguese, Japanese, Chinese, German, Italian,
Latin-American Spanish and European Spanish.
This is a closed book exam. No materials are permitted
in the examination room.
Duration: 1 hour
Number of questions: 40
Multiple-choice with
four options: A, B, C or D and
a single answer
Score minimum of 65 percent (26 of 40) to pass the
exam.

6. 6
Course Material
Goal of this slide set
• Preparation for an ISO/IEC 20000 Foundation Exam
according to specifications from EXIN and TÜV SÜD
Akademie.
Notations used in this slide set:
Blue background Definitions according to ISO/IEC 20000
0000
ISO/IEC 2 Minimum requirements of ISO/IEC 20000-1
tion
Specifica
0000
ISO/IEC 2 ISO/IEC 20000-2 recommendation
actice
C ode of Pr
BEST according to A best practice, but no ISO/IEC 20000
PRACTICE …
requirement or recommendation

7. 7
Introduction to IT Service
Management
• Motivation of process-oriented IT Service Management
• Background, History
• Basic principles
Check all IT Service Management Trainings conducted by Simplilearn.com

8. 8
Learning target of this section
• IT Services and their elements (1.2.1, 1.2.2)
• IT Service Management: Concept, Benefit, Risks
(1.3.1, 1.3.2)
• Process orientation: Concept, Benefit (1.4.1)
• Process control and measurement (1.4.2)
• Roles of IT Service Management (1.4.3)
• Quality, Quality of Service (1.1.1, 1.1.2, 1.2.3)
• Principles of quality management and setup of a
quality management system (1.1.3)
• ISO/IEC 20000: Purpose, Benefit, History, Owner
(2.3.1, 2.3.2)
• Groups of processes within ISO/IEC 20000 (2.3.4)

9. 9
Motivation of Process Orientation
• Availability is the most essential
service parameter of enterprise Application
services. Failures
• Availability is determined by
frequency and duration of service Technology
failure.
• About 80% of failures are a
Operator
consequence of people and process Errors
issues.
• Duration of failures heavily depends
on non-technical factors.
Causes of service failure
[Gartner 1999]
 Need for Management of IT Processes!

10. 10
What is ISO/IEC 20000?
• ISO/IEC 20000 is a worldwide standard that
describes the implementation of an integrated
process approach for the delivery of IT
services.
• A set of minimum requirements to audit an
organization for effective IT Service
Management.
• Owner:
ISO (International Organization for Standardization)
IEC (International Electro-technical Commission
Developed by JTC 1 / SC 7)
(Joint Technical Committee 1 / Subcommittee 7)

11. 11
History: from BS 15000 to ISO/IEC 20000
• BS 15000:
Direct predecessor of ISO/IEC 20000
Developed by BSI (British Standards Institution)
• 1995, 1998: Code of practice (non-certifiable)
PD 0005 A Code of Practice for Service Management
• 2000: First release of the standard
BS 15000: 2000 Specification for Service Management
PD 0015: 2000 IT Service Management Self-Assessment Workbook
• 2002, 2003: Second release
BS 15000-1: 2002 Specification for Service Management
BS 15000-2: 2003 Code of Practice for Service Management
PD 0015: 2002 IT Service Management Self-Assessment Workbook
• 2004: Adoption in other countries
Australia: AS8018
South Africa: SANS 15000

12. 12
ISO/IEC 20000: Development and Parts
• Date of Publication: December 15, 2005 - Developed using a
fast-track approach by adoption of BS 15000 during 14 months
• Changes to BS 15000
Formally 450 changes (renumbering, etc.)
In terms of content, just slight differences (sole terms, etc.)
• No other official publications by ISO/IEC but increasing number
of secondary publications by BSI (BIP 0030-0039, BIP 0015)
• Two Parts:
ISO/IEC 20000-1: Requirements -
Information Technology Service Management – shall
Part 1: Specification
ISO/IEC 20000-2: Recommendations -
Information Technology Service Management – should
Part 2: Code of Practice

13. 13
Context of ISO/IEC 20000
SHALL/MUST-HAVE’s
00
ISO/IEC 200  Minimum Requirements
tion
Specifica ISO/IEC  Check lists
20000-1
SHOULD-HAVE’s
0000
ISO/IEC 2  Enhancement of Part 1
ctice
Co de of Pra ISO/IEC 20000-2
 Recommendations
Basics:
IT Service Management
(e.g. ITIL® , MOF, CobiT)
& Quality Management (e.g. ISO 9000)

14. 14
Related Standards – Overview
ISO 9000
Six Sigma ISO/IEC 27000
BS 15000 ISO/IEC 20000
ITIL® V2 ITIL® V3
Legend
(since CobiT V4) MOF Quality Management
standard / methodology
CobiT IT Management
Framework
Software Engineering
CMM CMMI Maturity Degree Model
Adoption of concepts
ISO/IEC 15504 Predecessor

15. 15
Basic Principles and Concepts
• Process
Processes in general
Business Processes
IT Processes
• Service
• Process Management
• Process Assessment
• Quality and Quality Management

16. 16
What is a Process?
• Hammer, Champy (Reengineering the
Corporation):
“A business process is a bundle of activities,
which requires one or several inputs and which
creates value for the customer.”
• Office of Government Commerce (ITIL® Version 3):
“A structured set of Activities designed to
accomplish a specific Objective. (…)“
• DIN/ISO (ISO 9000):
“A business process is a collection of interrelated
resources and activities, that transform inputs
into outputs. Resources could be personnel,
buildings, machinery, technology and
methodology.“

17. 17
Example Business Process Workflow

18. 18
Management’s Process Orientation
Processes control and impact on …
• individuals’ behavior
• employment of technology
• usage of information/knowledge
•  Processes make results of activities predictable
•  Process Orientation as a Management Paradigm
Input Activity Activity Activity Output
Output
Output
Input
Input
Control factors Control factors Control factors
Domain 1 Domain 2 Domain 3

19. 19
Process Assessment
Critical Success Factors
Meet all critical conditions to achieve success
– What are the basic conditions of the process?
– Does the process operate effectively?
 Qualitative consideration

Key Performance Indicators
Metrics reflect the degree of target achievement 
– Calculation based on parameter values measured during process
execution
– Does the process actually operate (now, last month, last quarter, etc.)
effectively and efficiently?
 Quantitative consideration

20. 20
What is a Service?
Definition according to ITIL® Version 3 (goal-
oriented)
• A means of delivering value to customers by facilitating
outcomes customers want to achieve without the
ownership of specific costs and risks.
Model-based Definition (technology-oriented)
• Target – A view of all components and management-
relevant aspects of a service.

21. 21
Components of an IT Service
Information System:
- People, Processes, Technology, Partners
- Used to manage information
Support:
- Changes, system restoration in case of failure
- Maintenance
- To ensure performance according to the agreed
requirements
Quality:
- Availability, Capacity, Performance, Security
Scalability, Adjustability, Portability
- Quality attributes of the information system to be
specified and agreed upon

22. 22
A Possible Service Model

23. 23
ITSM: Basic Relationships
• Business Processes are
supported by IT Services.
Customer
• Delivering IT Services is the key
task of an IT provider. is responsible User
• Customers of the IT provider are
Business Process
basically organizations that are
involved in business processes. supports use Manage-
•
ment
Users use IT Services to carry IT Service
out day-to-day activities. delivers
• ITSM Frameworks describe Best ITSM
Practices of IT Service IT Provider Best
Management. Practice

24. 24
Process-oriented ITSM: Objectives and Benefit
• Objectives: Management of IT Services for
Fulfillment of Business Requirements
• Benefit:
– Effectiveness and efficiency of workflows will be
increased.
– IT Management will be placed on a stable foundation by
focusing on business objectives and customer
orientation.
– Improved external communication, competitive
advantage.
– Improved communication, Knowledge Management
– Output is more predictable and comprehensible.
– Less failures and resultant faults.
– Better management of risks (reduced insurance rates,
compliance requirements)

25. 25
Process-oriented ITSM: Risks
• Bureaucratic procedures, more paperwork.
• Lower effectiveness and efficiency, if…
– The staff is not aware of processes and measures
and personnel do not accept the system.
– Senior Management only pays lip-service to the
system.
– Important work is done outside of the system and
process is not complied with.

26. 26
Roles in Process Management
Sets of responsibilities, activities and authorities
granted to a person or team
• Per process:
- Process owner is responsible for process results.
- Process manager is responsible for realization of the process,
day-to-day control and management.
- Process operatives (professionals) are responsible for defined
activities.
Results assessed based upon agreed performance
indicators.
One person or team may have multiple roles.

27. 27
Role of Tools
Automated support aids in the performance of tasks/activities
Purpose:
• Increased efficiency = cost reduction
• Provide evidence of the process activities performed
Examples:
- Monitoring tools
- Software distribution tools
- Service Management / workflow tools
- Remote infrastructure management tools
“A fool with a tool is still a fool!”

28. 28
Service Quality
“Quality of Service is a measure that indicates the overall
effect of service performance that determines the degree
of satisfaction of a user of the service. The measure is
derived from the ability of the resources to provide
different levels of services. The measure can be both
quantitative and qualitative.”
• Quality of service is a critical part of customer and end user
satisfaction
• Measure of the ability of a service to provide the intended
value to a customer
• Specific to the individual customer; quality metrics should be
defined from the customer’s perspective
• Customer perception of service quality may vary over time

29. 29
Quality Policy
The Quality Policy recognizes that there is always the
potential to increase effectiveness and efficiency
(continual improvement).
The Quality Policy determines the general quality goals of an
organization.
• The Quality Policy however does not cover:
Legal Requirements
Customer specific requirements in quality (cp. SLA’s)
Requirements of ISO/IEC 20000

30. 30
Relationship between IT Services and Quality
• A service is provided through the interaction of the
provider with customers and users; quality of the service
depends upon this interaction.
• Quality is a measure of the extent to which the service
fulfills the requirements and expectations of the
customer.
• Customer perception of quality is largely based on
expectations:
Common language/terminology required to ensure
effective dialogue.
Expectations need to be clearly defined.
Supplier should continually assess how service is being
experienced and what the customer expects in the
future.
Providing constant quality is crucial to perception.

31. 31
Principles of Quality Management
ISO/IEC 20000 is predicated on basic principles of
Quality Management as defined in ISO 9000
e.g.
Principles of Quality Management (QM):
Customer focus
Leadership
Involvement of people
Process approach
System approach to management
Continual improvement
Factual approach to decision making
Mutually beneficial supplier relationships

32. 32
What is a Quality Management System?
QUALITY
MANAGEMENT
SYSTEM

33. 33
Objective of a Quality Management System

34. 34
Steps to Establish a Quality Management System
• Identify customer’s requirements and expectations.
• Define and assign required resources to achieve the
committed quality goals.
• Launch procedures to measure effectiveness and
efficiency.

35. 35
Summary
ISO/IEC 20000
• Worldwide Standard
• Process-Oriented Approach for IT Service
Management
• Based on:
Best Practices in IT Service Management (as per
description in ITIL® e.g.)
Principles of Quality Management (as per description
in ISO 9000 e.g.)
• Consists of two parts:
ISO/IEC 20000-1: Specification
ISO/IEC 20000-2: Code of Practice
Structure of both parts is identical.

36. 36
Basic Structure ISO/IEC 20000
[1] Scope
[2] Terms and Definitions
[3] Management System
[4] Planning & Implementing Service Management
[5] Planning & Implementing new or changed Services
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & [9] Control Processes Budgeting & Accounting
Availability Management for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes
Business Relationship
Incident Management Management
Release Management Supplier Management
Problem Management

37. 37
Revision Course
• What is IT Service Management?
• What is a Management Process?
• What is ISO/IEC 20000?
Content?
Structure?
Processes and process clusters?
History?
Relationship to ITSM Frameworks?
• What is the advantage of process-oriented
management?
• What are the risks?
• What is a QM System?

38. 38
Content of ISO/IEC 20000 Part 1:
Basics
(section 1 - 5)
[1] Scope
[2] Terms and Definitions
Management responsibility
[3] Management System Documentation requirements
Competencies, awareness & training
[4] Planning & Implementing SM Plan, Do, Check, Act
[5] Planning & Implementing new or changed Services

39. 39
Section 1: Scope
Objective
Description of ISO/IEC 20000 Standards and its content
[1] Scope
[2] Terms and Definitions
Management responsibility
[3] Management System Documentation requirements
Competencies, awareness & training
[4] Planning & Implementing SM Plan, Do, Check, Act
[5] Planning & Implementing new or changed Services

40. 40
Learning target of this section
• Applicability and Scope of the Standards
(2.2.1)
• Usefulness and benefit of a certification
(2.2.2)
• Difference of ISO/IEC 20000-1 and ISO/IEC
20000-2 (2.3.3)

41. 41
Scope: Description ISO/IEC 20000
What is the common advantage of ISO/IEC
20000?
• ISO/IEC 20000 defines requirements for Service providers.
• ISO/IEC 20000 sets up a basis of standardized terminology
for IT Service Management.
• ISO/IEC 20000 is applicable ...
• in a bid context
• securing consistency in a supply chain approach
• as IT Service Management benchmarking
• as basis for an independent assessment
• to prove capability in meeting customer requirements
• improving service

42. 42
Scope: Description ISO/IEC 20000
What is the purpose of the respective parts of
ISO/IEC?
ISO/IEC 20000-1: Requirements for service providers intending
to offer managed services with acceptable quality levels
ISO/IEC 20000-2: Additional guidelines for auditors and service
providers
Where is ISO/IEC 20000 not suitable?
Product evaluation of tools, etc.

43. 43
Section 2: Terms and Definitions
Objective
Basic Definitions and Standardized Terminology
[1] Scope
[2] Terms and Definitions
Management responsibility
[3] Management System Documentation requirements
Competencies, awareness & training
[4] Planning & Implementing SM Plan, Do, Check, Act
[5] Planning & Implementing new or changed Services

44. 44
Learning target of this section
• Terms and Definitions according to
ISO/IEC 20000 (2.3.6)

45. 45
C
00
200 n
O/IE icatio
Terms and Definitions: Overview
IS if
pec • • Record
S Availability (6.3)
• Baseline (9.1) • Release (10.1)
• Change Record (9.2) • Request for Change (9.2)
• Configuration Item • Service Desk
(9.1) • Service Level Agreement
• Configuration (6.1)
Management • Service Management
Database (9.1) • Service Provider
• Document
• Incident (8.2)
• Problem (8.3)
Grey highlighted terms: Definitions - see the following slides
All other terms: See Specification Sheet Section 7.5 for full list

46. 46
ISO/IEC 2
0000
tion
Documents and Records
Specifica
Document
• Information and its supported medium.
Record (objective evidence)
• A record is a document which shows what
kind of results are being achieved or how well
activities are being performed.

47. 47
000
ISO/IEC 20 Service …
tion
Specifica
Service Desk
• Interface function for communication of provider and
user, which covers the bigger part of the first level
support.
Service Management
• Management of IT Services in order to support and
meet business requirements.
Service Provider
• Supplier of IT Services (target object of ISO/IEC
20000 certification).

48. 48
Service Desk
BEST according to
PRACTICE ITIL® Version 2 & 3, MOF
Service Desk – Objectives
• To ensure availability of the IT provider
• Single Point of Contact (SPOC) for Users
Tasks -
• To take over tasks of service support (e.g. particularly
within Incident Management Process)
• Communication to users
Service Desk is a Core Definition, but not part of the ISO/IEC 20000 requirements.

49. 49
Requirements for a Management System
Objective:
To provide a management system enabling the effective
management of all IT Services.
[1] Scope
[2] Terms and Definitions
Management responsibility
[3] Management System Documentation requirements
Competencies, awareness & training
[4] Planning & Implementing SM Plan, Do, Check, Act
[5] Planning & Implementing new or changed Services

50. 50
Learning target of this section
• Objective and purpose of a management system
(3.1.1)
• Management responsibilities (3.1.2, 4.1.1)
• Documentation requirements (3.1.3, 4.1.2)
• Competence, Awareness and Training (3.1.4, 4.1.3)

51. 51
Management Systems
What is a management system?
A possible definition: A management system is the
framework of processes, tools and resources
(personnel and machinery) used to plan,
execute, document and continually improve
management tasks in a target-oriented,
customer-oriented and quality-oriented way.
• Important Aspects:
• Quality (cp. Quality Management)
• Management responsibilities
• Documentation
• Competence, Awareness and Training

52. 52
0000
ISO/IEC 2
Specifica
tion Management Responsibilities
Management shall:
• prove commitment to development, implementation and
improvement of service management capabilities by
appropriate leadership behavior and appropriate
measures;
• establish policy, objectives and plans;
• communicate the importance of meeting the objectives and
the need for continual improvement;
• ensure that customer requirements are determined and are
met;
• appoint a member of management responsible for the co-
ordination and management of all services.

53. 53
Management Responsibilities (continued)
0
0 00
EC 2 tion
O/I ifica
IS ec
Sp
Management shall: (continued)
• determine and provide resources (e.g. personnel) for
Service Management;
• manage risks to the organization and services;
• conduct reviews of service management at planned
intervals.

54. 54
Management Responsibilities (continued)
ISO/IEC 2
0000 Furthermore, Senior Management should:
actice
C ode of Pr • require and support the implementation of service
management processes;
• assign an executive position to the senior responsible
owner of IT Service Management ;
• provide management representatives with required
resources for continual or project-related improvement;
• allocate a decision-making group to the management
representatives with sufficient authority to define guidelines
and make decisions.

55. 55
ISO/IEC 2
0000
tion
Documentation
Specifica
Documentation and records shall be provided to
support effective planning, operation and control.
• Including at least:
• Documentation of Service Management guidelines and
plans
• Documentation of Service Level Agreements
• Documentation of processes required by ISO/IEC 20000
• Records required by ISO/IEC 20000
Procedures and responsibilities shall be established
for the creation, review, approval, maintenance,
disposal, and control.

56. 56
20
0
00 ce Documentation: Best Practices
C acti
IE
O/ of Pr
IS e
Co
d • Senior responsible owner should ensure evidence is
available for audit, such as:
• Policies and plans
• Service documentation
• Procedures
• Processes
• Process control records
• Documents should be in a medium suitable for their purpose.
• Documents should be protected from damage due to
circumstances (e.g. environmental conditions, computer
disasters).

57. 57
0000
ISO/IEC 2
Specifica
tion Competence, Awareness & Training
• All roles and responsibilities in combination with the
required competencies shall be defined.
• Competencies and training needs shall be determined
and managed:
• Maintain appropriate records of qualifications,
experience, skills and trainings ISO
Co /
• Arrange for training and further education de IEC 2
of 0
Pra 000
cti
• Control effectiveness of qualification and training ce
• Management shall ensure that staff are aware of the
relevance and importance of their activities and how
they contribute to the achievement of service
management objectives.

58. 58
Section 4: Planning and Implementing SM
PLAN
PLAN
Objective [4.1] Plan Service
[4.1] Plan Service
Management
Management
• Planning and
Implementing IT ACT
ACT
[4.4] Continual
[4.4] Continual
DO
DO
[4.2] Implement Service
[4.2] Implement Service
Improvement Management
Service Management Improvement Management
using Deming’s CHECK
CHECK
Quality Circle. [4.3] Monitor, Measure
[4.3] Monitor, Measure
and Review
and Review
[1] Scope
[2] Terms and Definitions
Management responsibility
[3] Management System Documentation requirements
Competencies, awareness & training
[4] Planning & Implementing SM Plan, Do, Check, Act
[5] Planning & Implementing new or changed Services

59. 59
Learning target of this section
• Objective and purpose of the section Planning and
Implementing IT Service Management (3.1.5)
• Plan-Do-Check-Act methodology for Service
Management Processes (1.5.1, 3.1.6, 3.1.8)
• Principles of a Service Management Plan (3.1.7)
• Internal and external audits (4.1.5, 4.1.6)
• Conduct internal and external audits (4.1.6)

60. 60
Continual Improvement
1. Necessary in order to improve the performance of the
organization and increase customer satisfaction.
2. Needs to be a permanent objective of the organiation.
3. Continual activity which keeps the wheel of the PDCA
cycle turning.
4. Ensures improvement activities at all levels are aligned
to the organization’s strategy.
5. Increases flexibility to act quickly on opportunities.
6. Applying the principle leads to a company culture and
organization-wide approach to continual improvement.
7. Leads to more business in the mid-term by actively
improving the relationship with customers.

61. 61
Deming’s Quality Circle – PDCA
Plan
Act
Do
maturity
Check
time
• Process model of quality management according
to W. Edwards Deming
• Cyclical optimization of quality leads to continual
improvement
• Plan-Do-Check-Act is applicable to all processes
defined in ISO/IEC 20000

62. 62
PDCA in Service Management
Business Management of Services
Requirements
Business results
Customer Management Responsibility
Requirements
PLAN Customer satisfaction
Request for Plan Service
new/changed services Management
New/changed Services
Other processes
(e.g. business,
supplier, customer) ACT DO Other processes
Continual Implement Service (e.g. business,
Improvement Management supplier, customer)
Service Desk
Team and people
Other teams CHECK satisfaction
(e.g. Security, monitor, measure
IT Operations)
and review

63. 63
Section 4.1: Plan Service Management
Objective "Plan"
To plan the implementation and delivery of service
management.
PLAN
ACT DO
CHECK

64. 64
000
Planning for Service Management
ISO/IEC 20
tion
Specifica
•Create a plan for implementing service
management.
•The plan is called the Service Management
Plan.
•Responsibilities shall be determined and
documented to control, authorize,
communicate, operate and maintain the plans.
•All process-related plans have to be
compatible with the service management plan.

65. 65
0000
ISO/IEC 2
Specifica
tion Service Management Plan
The plans shall at a minimum define:
1. Scope of service management
2. Objectives and requirements to be achieved by
service management
3. Processes to be executed
4. Framework of roles and responsibilities
5. Interfaces between service management
processes

66. 66
0000
ISO/IEC 2
Specifica
tion Service Management Plan
The plans shall at a minimum define (continued):
6. Approach to risk management
7. Methods for interfacing with development projects
8. Resources, facilities, budget
9. Tools for process support
10.Methods to manage service quality including audit
and improving

67. 67
0000
C
ISO/IEC 2
ode of Pr
actice Service Management Plan
Approaches to implementing the Service Management Plan
• The Service Management Plan should be implemented by
considering the following issues (providing a map for directing
progress):
Required new service management processes
Changes in existing processes
Improvement of established procedures
etc.
Other possible content of the plan:
• Appropriate tool support for processes
• Change procedure for the plan

68. 68
0000
ISO/IEC 2
Co de of Pra
ctice Service Management Plan
Events with impact on the Service Management Plan:
• Service Improvement
• Changed Services
• Changes to the target-state of infrastructure
• Changed legal/official requirements
• Regulation or deregulation of branches
• Mergers and acquisitions

69. 69
Implement Service Management & Provide the Services
Objective "Do"
To implement the service management
objectives and plan.
PLAN
ACT DO
CHECK

70. 70
0000
ISO/IEC 2
Specifica
tion Implementing Service Management
Implementing Service Management
• Allocation of budgets
• Allocation of roles and responsibilities
• Documenting and maintaining policies, plans,
procedures and definitions for each process
• Identify and manage risks to the service
• Managing teams (staff)
• Managing facilities and budgets
• Managing teams for service desk and operations
• Reporting on progress of Service Management Plan
• Co-ordination of service management processes

71. 71
Monitoring, Measuring and Reviewing
Objective "Check"
To monitor, measure, and review that the
service management objectives and plan are
being achieved.
PLAN
ACT DO
CHECK

72. 72
0000
ISO/IEC 2
Specifica
tion Achievement of Objectives
• Appropriate methods shall be applied for monitoring and
measuring processes to disclose achievement of targets.
• Management shall conduct reviews at planned intervals to
determine whether:
• Service management requirements conform with the
Service Management Plan and requirements of
ISO/IEC 20000
• Service management requirements are effectively
implemented and maintained
• An audit program shall be planned.
• Objectives of reviews, assessments and audits shall be
documented together with the results and detected
resolutions.
• In case of failure to fulfill obligations and other
problematical concerns, all relevant parties shall be
informed.

73. 73
Characteristics of Assessments and Audits
• Self-assessment
e.g. a department assesses its own procedures
Poor comparability, often not objective
• First party (internal) audit
Auditing is performed by a department within the
organization
Auditor belongs to same organization, but is not
involved in audited department
• Second party (vendor) audit
• Third party (external) audit
Auditing is performed by an independent external
organization
In the context of standard audits mostly a registered
certified body (RCB).

74. 74
Comparison: Characteristics of Assessments and Audits
Third party
(external) audit
Second party
Costs/effort
(vendor) audit
First party
(internal) audit
Self-assessment
Objectiveness

75. 75
0000
ISO/IEC 2
Specifica
tion Audit Program
•To be considered by internal audit
program:
Status and importance of the audited processes and
organizations
Results of previous audits
•Criteria, scope, frequency and methods
shall be defined in a procedure.
•Selection of auditors shall take into
consideration:
Audit has to be objective and impartial.
Auditors shall not audit their own work.

76. 76
ISO/IEC 2
0000
actice
Management Review
C ode of Pr
Management Reviews should focus on:
•Achievements compared to service objectives (e.g.
from audit results)
•Customer satisfaction
•Resource utilization
•Trends
•Certain service discrepancies

77. 77
Continual Improvement
Objective "Act"
• To improve the effectiveness and efficiency of
service delivery and management.
PLAN
ACT DO
CHECK

78. 78
ISO/IEC 2
0000
tion
Policy
Specifica
•A published policy for service improvement is
required.
•Any non-compliance with ISO/IEC 20000 or with
service management plan shall be remedied.
•Roles and responsibilities for service
improvement shall be defined clearly.

79. 79
0000
ISO/IEC 2
Specifica
tion Management of Improvement
•All suggested service improvements shall be
evaluated, documented, prioritized and
authorized. Monitoring these activities shall be
planned.
•A specific process is required for continually
identifying, measuring, reporting and managing
improvement. This encompasses:
Improvements concerning individual processes that
can be implemented by process owner’s means
Organization-wide or cross-process improvements

80. 80
000
ISO/IEC 20 n
pecific
a ti o Activities to be carried out
S
• Information shall be recorded and analyzed as
a baseline and a benchmark against the
provider’s capability in managing services and
service management processes.
• Identify, plan, and implement improvements.
• Consultation with all involved parties.
• Set a goal for improvements regarding quality,
costs, resources.

81. 81
0000
ISO/IEC 2
Specifica
tion Activities to be carried out
• Consider relevant requests for improvement
of all services and management processes.
• Measure, report and communicate service
improvements.
• Revise service management policies,
processes, procedures and plans where
necessary.
• Ensure that all approved actions are
delivered and that they achieve their
intended objectives.

82. 82
Section 5: Planning and Implementing Services
Objective:
To ensure that new services and changes to services will be
deliverable at the agreed cost and service quality.
[1] Scope
[2] Terms and Definitions
Management responsibility
[3] Management System Documentation requirements
Competencies, awareness & training
[4] Planning & Implementing SM Plan, Do, Check, Act
[5] Planning & Implementing new or changed Services

83. 83
Learning target of this section
• Parties involved in planning new or changed services
(3.2.1)
• Objective and purpose of planning and implementing
new or changed services (3.2.2)
• Quality requirements for new or changed services (3.2.3)
• Content of an implementation plan for new or changed
services (3.2.4)
• Planning and implementation policy for new or changed
services (4.1.4)
• Reviews for planning new or changed services (4.2.1)
• Records for service changes (4.2.2)

84. 84
000
ISO/IEC 20
Specifica
tion Minimum Requirements
• The costs, commercial and organizational impact of any
proposed new or changed services shall be considered by
operations and management of these services.
• New or changed services, including closure of service,
shall be planned and authorized/approved through change
management.
• Planning of new/changed services shall consider aspects
of funding and allocation of resources.
• New/changed services require acceptance by service
provider before deployment to live environment.
• Post implementation review (including target-performance
comparison) through change management process.

85. 85
Implementation Plans for New/Changed Services
0000
ISO/IEC 2
tion
Specifica
Implementation plans for new/changed
services comprises at least:
• Roles and responsibilities for implementing,
operating and managing (as well at the customer and
at vendor)
• Required changes to existing services and systems
• Communication to the stakeholders
• New and changed contracts and agreements
• Manpower requirements
• Skills and training requirements

86. 86
Implementation Plans for new/changed Services
0000
ISO/IEC 2
ion
Specificat
Implementation plans for new/changed services
consists of at least (continued):
• Processes, measures, methods, and tools to be used in
connection with the new/changed service
• Budgets and timelines
• Service Acceptance Criteria
• The expected outcomes from operating the new service
expressed in measurable terms

87. 87
ISO/IEC 2
0000
PINCS: Involved Parties
tion
Specifica
• Roles and responsibilities related to the service need
to be defined, including activities to be performed by:
Customers
Suppliers
Service Provider
Implementation via Change Management
Skills and training requirements for:
Users
Technical support of the service

88. 88
Reviews at planning new or changed services
During planning new/changed services, the
0 00 e following should be reviewed:
20 ctic
O
C a
/IE f Pr • Budget – Adjustment of budgeting required?
IS e o
d Increased financial requirements through new
Co
services?
Reduction of costs through changes or replacement
of expensive services?
• Staff – Is existing staff able to provide/support
new/changed services?
Increased headcount (e.g. at support)?
Possible personnel consolidation through
new/changed services?
• Service Levels – Impact on existing service
levels?

89. 89
Reviews for planning new or changed services
During planning new/changed services the
0
00 e
following should be reviewed (continued):
20 ic
C ract • SLA’s and other commitments
IE
O/ of P
IS e
d
Co Changing existing or concluding new SLA’s required?
Other commitments?
• Processes, procedures and documentation
Changing existing processes and procedures required (e.g.
at support)?
Changed services require new documentation or update of
existing documents?
• Scope of Service Management
New or not yet implemented service management
processes required?
Service Management Plans update required?

90. 90
Change Records of Changed Services
All changes to existing services should be
documented in relevant change records.
0
00 ce
20 ct i • Staff training - conducted update training for
C
O /IE Pra
IS e of
Co
d support staff
• Move or transfer
• Conducted user training
• Any change-related communication
• Changes to supporting technologies (e.g.
system components, software)
• Closure of services

91. 91
Content of ISO/IEC 20000
Part 2:
IT Service Management Processes
(section 6 - 10)
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

92. 92
Section 8: Resolution Processes
About the process group
Incident and Problem Management are closely related
processes but differ in their objectives. These processes are covered
in the Professional module Support of IT Services within the ISO/IEC
20000 Qualification Program.
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

93. 93
Learning target of this section
• Objectives and requirements within
Incident Management (3.5.1)
• Best Practices within Incident
Management (4.5.1)
• Objectives and requirements within
Problem Management (3.5.2)
• Best Practices within Problem
Management (4.5.2)

94. 94
00
IS
C 2 00 ce
O/IE Practi Code of Practice
of
Code
Classification Incident vs. Problem Management
• Incident Management: Quickest possible service
recovery
• Problem Management: Root cause identification and
resolution
Similarities and connections between Incident and
Problem Management
• Prioritization of Incidents and Problems
• Problem Management develops and maintains work-
arounds provided to Incident Management.

95. 95
ISO/IEC 20000
Code of Practice Code of Practice
Aspects to consider scheduling Incidents and
Problems
• Priority: Control factor resulting from
Impact
Urgency
• Staff skills
• Competing requests for resource allocation
• Costs of implementing the resolution
• Approximated time to implement the resolution

96. 96
Incident Management
Objective:
Resolve incidents as quickly as possible and minimize the
adverse impact on business operations.
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

97. 97
Fundamental terms
Incident
• An unplanned interruption to a service or
reduction in the quality of an service.
Further Terms
• Service Request:
Request for documentation
User Request for Change
• Escalation: procedure of forwarding an incident
Functional Escalation
Hierarchical Escalation

98. 98
BEST according to
Process
PRACTICE ITIL® Version 2 & 3
Activities:
•Detection and Recording - description of symptoms,
creation of ticket
•Classification and Initial Support - if possible,
resolution through first level support (Service Desk);
incident prioritization and categorization
•Investigation and Diagnosis - find a resolution to
restore the service as quickly as possible
•Resolution and Recovery - initiation of required
recovery measures
•Closure - resolution documentation, user
confirmation, close ticket

99. 99
BEST according to
PRACTICE ITIL® Version 2 & 3
Functional Escalation
Service Co-ordination of support units
Desk
2nd Level
Support
Detection 3rd Level
Support
Yes
Request?
No No No
1st Support Diagnosis Diagnosis
No
Request
Fulfillment Resolvable? Resolvable? Resolvable?
Yes Yes Yes
Resolution Resolution Resolution
Closure

100. 100
Service Requests and Incidents
The 20 GB hard disk of my
Service Request for a
notebook is too small ! storage upgrade
Service Request for a
The color printer in room
D.2 stopped printing red!
cartridge change or a printer
failure
It takes a long time to
load our external web Performance Incident
sites!
I have forgotten my Wiki- Service Request for a
Password! password or account reset
I cannot access
my emails!
E-mail service failure

101. 101
Minimum Requirements
0000
ISO/IEC 2
tion
Specifica
All Incidents shall be recorded.
Procedures for detection, impact analysis, prioritization,
classification, escalation, resolution and closure of
incidents shall be defined.
Customers shall be kept informed of the process progress and
alerted BEFORE SLA is breached or at risk of being
breached.
All staff involved in incident management shall have access to
relevant information such as:
 Known errors
 Problem resolutions
 Configuration Management Database (CMDB)
Major Incidents shall be managed according to a process.

102. 102
Code of Practice
00
ISO/IEC 200
actice
C ode of Pr
Process closure
Prerequisite - Final closure of an incident should only take
place when the initiating user has confirmed that the
service is restored.
Major incidents
Important - There should be a clear definition of what
constitutes a major incident.
All major incidents should have a clearly defined
responsible manager at all times.
The process for a major incident should include review.

103. 103
Assessment Card Template
00
ISO/IEC 200
actice
C ode of Pr
Section
Sub
Requirem ent of ISO20000
Section
8.1 Incident Managem ent
8.2 a All incidents shall be recorded
Procedures shall be adopted to manage the impact of
8.2 b
service incidents
Procedures shall define the recording, prioritization,
8.2 c business impact, classification, updating, escalation,
resolution and formal closure of all incidents
The customer shall be kept informed of the progress of their
reported incidents or service request and alerted in
8.2 d
advance if their service levels cannot be met and an action
agreed
All staff involved in incident management shall have access
8.2 e to relevant information such as know n errors, problem
resolutions and the configuration management database
Major incidents shall be classified and managed according
8.2 f
to a defined process

104. 104
Problem Management
Objective:
To avoid disruption by proactive and reactive analysis of the cause of
potential incidents.
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

105. 105
Fundamental terms
•Problem
An unknown cause of one or more incidents
Additional terms:
Known Error - root cause of one or more incidents for
which work-arounds exist, if applicable.
Reactive and proactive problem management

106. 106
Process
BEST according to
PRACTICE ITIL® Version 2
Sub-processes within reactive problem management
Problem control
Error control
Problem Known Error Request for Change
unknown cause known cause
Problem Control Error Control
Problem Management Change Management

107. 107
Process
according to
BEST
ITIL® Version 3
PRACTICE
Process activities within reactive problem management
Problem detection
Problem logging
Categorization
Prioritization
Investigation and Diagnosis
Find out work-arounds, if possible
Create Known Error Record
Submit request for change, if required
Resolution
Closure

108. 108
Trend Analysis
Definition: Analysis of data of various sources to identify time-
related patterns.
Examples of sources:
•Ticket system - number of similar incidents
•Monitoring tools - resource utilization peaks
Examples of time-related patterns:
•Each Monday between 7:30-9:30 p.m. noticeable
accumulation of submitting network incidents
 Problem identification (reactive problem management since
incidents already occured)
•Every day between 2-5 a.m. marginally high utilization of an
information system
 Problem identification (proactive problem management
since incidents should be avoided)

109. 109
Minimum Requirements
0000
ISO/IEC 2
tion
Specifica
• All identified problems shall be recorded.
• Procedures shall be adopted to identify, minimize or avoid the
impact of incidents and problems. They shall define the
recording, classification, updating, escalation, resolution and
closure of all problems.
• Preventive action shall be taken to reduce potential problems.
• Changes required in order to correct the underlying cause of
problems shall be passed to the change management process.

110. 110
Minimum Requirements
0000
ISO/IEC 2
tion
Specifica
• Problem resolution shall be monitored, reviewed and reported
on for effectiveness.
• Problem management shall be responsible for ensuring up-to-
date information on known errors and corrected problems is
available to incident management.
• Actions for improvement identified during this process shall be
recorded and implemented.

111. 111
Code of Practice
0000
ISO/IEC 2
ctice
Co de of Pra
•Communication
All processes and people involved in service support
particularly incident management should be informed of:
• Work-arounds
• Permanent fixes
• Progress of problems

112. 112
Example: From Problem to Change
Incident Problem Known Error
It takes a long time to Category: SW/Service Max. file size of web
load our external web Impact: server log files reached
sites! Highest (all users)
Urgency:
Low (no SLA affected) Resolution
Install patch for
Root cause web server
Failure in writing log
files causes delays RfC
Work-around Install patch T12-02
for web server on
1. Back up log file machine pclx3
2. Empty log file

113. 113
Assessment Card Template
00
ISO/IEC 200
actice
C ode of Pr ction
Se
Sub
Re quire m e nt of ISO20000
Se ction
8.3 Proble m M anage m e nt
8.3 a All identif ied problems shall be recorded
Procedures shall be adopted to identif y, minimize or avoid
8.3 b
the impact of incidents and problems.
Procedures shall def ine the recording, classif ication,
8.3 c
updating, escalation, resolution and closure of all problems
Preventive action w ill be taken to reduce potential problems,
8.3 d
eg. Follow ing trend analysis of incident volumes and types
Changes required in order to correct the underlying cause
8.3 e of problems shall be passed to change management
process
Problem resolution shall be monitored, review ed and
8.3 f
reported on f or ef f ectiveness
Problem management shall be responsible f or ensuring up-
8.3 g to-date inf ormation on know n errors and corrected
problems is available to incident management
Actions f or improvement identif ied during this process shall
8.3 h
be recorded and input into the service improvement plan

114. 114
Revision Course
• Trend analysis is important during what activity of problem
management process?
• What is the difference between a problem and an error?
• What are the sub-processes of problem management?
• How is problem management linked to change
management?
• What is the next step within problem management after a
change was implemented to resolve an error?
• What kind of information does problem management
provide for the incident management process?

115. 115
Section 9: Control Processes
About the process group
Objective:
To manage configuration information and changes effectively.
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

116. 116
Learning target of this section
Objectives and requirements of Configuration Management (3.2.5)
Best Practices of Configuration Management (4.2.3)
Objectives and requirements of Change Management (3.2.6)
Best Practices of Change Management (4.2.4)

117. 117
Configuration Management
Objective:
To define and control the components of the service and infrastructure
and maintain accurate configuration information.
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

118. 118
Fundamental terms
Configuration Item (CI)
Any IT infrastructure component or other element that is
recorded and maintained by configuration management
process
Configuration Management Database (CMDB)
A database used to store:
• all relevant information of all CI’s
• relationships with other CI’s

119. 119
Fundamental terms
BEST according to
PRACTICE ITIL® IL Version 3
Additional terms
Attribute - a piece of information about a CI (e.g. asset id,
location)
Baseline - a benchmark used as a reference point.
Configuration Management System (CMS) - a set of tools and
databases that are used to manage configuration information:
• includes one or more CMDB’s  Federated CMDB
• manages relationships with other CI’s and related incidents,
problems, known errors, changes, etc.

120. 120
Process
BEST according to
PRACTICE ITIL® Version 2 & 3
Activities
Planning of:
• CMDB targets (e.g. Which processes have to be supported?
How?)
• Scope of CMDB
Identification - define types of CI’s, name conventions,
versioning
Recording and Control:
• record new CI’s
• update existing CI’s
Status Accounting - record/update lifecycle status of each CI
Verification - mapping CMDB and actual situation

121. 121
Process
BEST according to
PRACTICE ITIL® Version 2 & 3
Targets, Scope
Planning
Types of CI’s, Baselines,
Name conventions
Identification
New CI’s, changed CI’s
Recording and Control
Update CI Status
Status Accounting
Difference between
CMDB and reality
Verification
CMDB

122. 122
Minimum Requirements
0000
ISO/IEC 2
tion
Specifica
•There shall be an integrated approach to change and
configuration management planning  Scope of CMDB
= Scope of change management!
•Configuration management shall have an interface to
financial asset accounting processes.
•There shall be a configuration management policy on
what is defined as a configuration item and its constituent
components.
•The information to be recorded for each item shall be
defined and shall include the relationships and
documentation necessary for effective service
management.

123. 123
Minimum Requirements
0000
ISO/IEC 2
tion
Specifica
Configuration management shall provide the mechanisms
for identifying, recording, controlling and tracking
versions of CI’s. It shall be ensured that the process
meets the business needs, risk of failure and service
criticality.
Configuration management shall provide information to
the change management process:
• Supporting Change Management in risk and impact analysis
of planned changes
• Tracking of hardware/software changes

124. 124
Minimum Requirements
0000
ISO/IEC 2
tion
Specifica
•A baseline of the appropriate configuration items shall be
taken before a release to the live environment.
•Master copies of digital CI’s (software, documents) shall
be controlled in secure physical or electronic libraries
(cp. release management: definitive software library) and
referenced to the configuration records.
•All configuration items shall be uniquely identifiable and
recorded in a CMDB to which update access shall be
strictly limited and controlled.
•Audit procedures shall include process and CMDB.

125. 125
Configuration Management: Best
Practices
00
ISO/IEC 200 e
ractic
Code of P
• Should be planned and implemented together with Change and Release
Management.
• All major assets and configurations should be accounted for and have a
responsible manager who is accountable.
• There should be an up-to-date configuration management plan for the
infrastructure and/or services.
• Managed CI’s should be defined by relevant and auditable. Attributes,
relationships and dependencies between CI’s should be identified.
• CI’s should be held in a secure and suitable environment.
• No CI should be added or undergo an uncontrolled status change. Status
records should provide current and historical data and be available to all
relevant parties.
• Configuration audits should be carried out regularly.

126. 126
Assessment Card Template
00
O/IEC 200
IS 9.1 Se r vice
actice
As s e t and Configur ation M anage m e nt
C ode of Pr There shall be an integrated approach to change and
9.1 a
conf iguration management planning
The service provider shall def ine the interf ace to f inancial
9.1 b
asset and accounting processes
There shall be a policy on w hat is def ined as a
9.1 c
conf iguration item and it's constituent components
The inf ormation to be recorded f or each item shall be
def ined and shall include the relationships and
9.1 d
documentation necessary f or ef f ective service
management
Conf iguration management shall provide the mechanisms f or
9.1 e identif ying, controlling and tracking versions of identif iable
components of the service and inf rastructure
The degree of control shall be suf f icient to meet the
9.1 f
business needs, risk of f ailure and service criticality
Conf iguration management shall provide inf ormation to the
9.1 g change management process on the impact of a requested
change on the service and inf rastructure conf igurations
Changes to conf iguration items shall be traceable and
9.1 h auditable w here appropriate, eg. For changes and
movements of sof tw are and hardw are
Conf iguration control procedures shall ensure that integrity
9.1 i of systems, services and service components are
maintained
A baseline of the appropriate conf iguration items shall be
9.1 j
taken bef ore a release to the live environment

127. 127
Excursus: Service Knowledge Mgmt. according to ITIL®
BEST according to
PRACTICE ITIL® Version 3
Why Service Knowledge Management?
Sole Configuration Management is insufficient to soundly support
management decisions.
Service Knowledge Management –
additional documentation of:
• experiences
• key findings of former projects
• expert knowledge
Service Knowledge Management System (SKMS): A set of tools
and databases that are used to manage knowledge and
information. The SKMS includes the:
• CMDB’s
• CMS

128. 128
Change Management
Objective:
To ensure all changes are assessed, approved, implemented and
reviewed in a controlled manner.
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

129. 129
Fundamental terms
Request for Change (RfC)
Form to register all relevant details of a required change to a CI.
Change Record
A record containing the CI details of an authorized change.

130. 130
Fundamental terms
BEST according to
PRACTICE ITIL® Version 2 & 3, MOF
•Additional terms:
•Change Advisory Board (CAB) - A group of people that
advises in the assessment, prioritization and scheduling
of changes.
•Emergency Change Advisory Board (ECAB) - A
subset of the Change Advisory Board put together on
demand that plans and makes decisions about
emergency changes.
•Forward Schedule of Change (FSC) - Schedule of all
planned changes.

131. 131
Process
BEST according to
PRACTICE ITIL® Version 2 & 3, MOF
•Activities:
•Records all RfC’s
•Review and Filter - decide on RfC acceptance by
defined formal criteria
•Classification:
• Priority (impact, urgency)
• Category (Risks)
•Authorize and Plan - release changes for development,
budgeting and resource planning
•Coordination of change development and change
release
•Post implementation review (PIR)

132. 132
Process
BEST according to
PRACTICE ITIL® Version 2 & 3, MOF
RfC Record
No RfC
accepted?
rejected
Change Management
Review & Filter
Yes
Classification
No Change
authorized?
rejected
Authorization
Yes
Coordination Release Management
Assess (PIR)

133. 133
Minimum Requirements
0000
ISO/IEC 2
tion
Specifica
•Changes shall have a clearly defined and documented
scope.
•All requests for change shall be recorded and classified
and assessed for their risk, impact and business benefit.
•The process shall include the manner in which the
change shall be reversed or remedied if unsuccessful.
•All changes shall be reviewed after implementation
(PIR).
•There shall be policies and procedures to control the
authorization and implementation of emergency
changes.

134. 134
Minimum Requirements
0000
ISO/IEC 2
tion
Specifica
•The scheduled implementation dates of changes
shall be documented including details of all the
changes (FSC).
•Change records shall be analyzed regularly to detect
increasing levels of changes, frequently recurring
types and other trends.

135. 135
Code of Practice
0000
ISO/IEC 2
ctice
Co de of Pra
• Standard Change
Established, documented and practiced procedure
Pre-authorized by Change Management
• Emergency Change
Emergency change procedure will follow the normal change
procedure as far as possible.
Regular requirements can be relaxed for time-critical steps,
e.g.
• Testing may be reduced, or in extreme cases forgone
completely
• Documentation may be deferred
Emergency changes should be reviewed after the change to
verify that it was a true emergency.

136. 136
Assessment Card Template
Sub
Se ction Re quir e m e nt of ISO20000
Se ction
9.2 Change M anage m e nt
Service and inf rastructure changes shall have a clearly
9.2 a
def ined and docum ented scope
A ll requests f or change shall be recorded and classif ied.
9.2 b
E g. Urgent, emergency, m ajor, minor
Code of Practice
Requests f or changes shall be assessed f or their risk,
9.2 c
ISO/IEC 20000
im pact and business benef it.
The change m anagem ent process shall include the m anner
9.2 d in w hich the change shall be reversed or rem edied if
unsuccessf ul
Changes shall be approved and then checked, and shall be
9.2 e
im plem ented in a controlled manner.
A ll changes shall be review ed f or success and any actions
9.2 f
af ter im plem entation
There shall be policies and procedures to control the
9.2 g
authorization and im plementation of em ergency changes
The scheduled im plem entation dates of changes shall be
9.2 h
used as the basis f or change and release scheduling
A schedule that contains the details of all changes
approved f or im plem entation and their proposed
9.2 i
im plem entation dates shall be m aintained and com unicated
m
to relevant parties
Change records shall be analyzed regularly to detect
9.2 j increasing levels of changes, f requently recurring types,
em erging trends and other relevant inf orm ation.
The results and conclusions draw n f rom change analysis
9.2 k
shall be recorded
A ctions f or improvement identif ied during this process shall
9.2 l
be recorded and input into the service im provement plan

137. 137
Section 10: Release Process/Release Management
Objective:
To distribute one or more changes in a release to the live
environment including planning and documentation.
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

138. 138
Learning target of this section
Objectives and requirements within release management
(3.2.7)
Best Practices within release management (4.2.5)

139. 139
Fundamental terms
•Release
•A collection of new or changed CI’s required to be tested together and
deployed to live environment.
Additional terms
Definitive Media Library (DML):
• Master copies of deployed software (licensed third-party software and
proprietary)
• Basis for packaging of releases
Definitive Hardware Store (DHS):
Physical storage location of approved and registered hardware

140. 140
Process
BEST according to
PRACTICE MOF
Activities leading to Release Readiness Review
• Release Planning - release plan development, strategy
and guidelines on further steps
• Release Building - release package construction
including all required tools and documents for release
roll-out
• Acceptance Tests - release test in a simulated
production environment
• Release Readiness Review - assessment of test
results, Go/No-Go decision on release
• Information to change management, if release was
rejected.

141. 141
Process
BEST according to
PRACTICE MOF
Activities after Release Readiness Review
Roll-out planning:
•details of physical provisioning in production environment
•verify environment is ready for release (e.g. capacity: storage,
room in hardware racks, etc.)
•concrete roll-out times and timeframes for resource allocation
•communication and training
•separate plans for different locations as an option
Roll-out Preparation: Ensure that…
•all resources included in roll-out plan are available.
•prerequisites for contingency plan are met.
Roll-out - coordination, documentation and final provisioning
of releases

142. 142
Exemplary Workflow
BEST according to
PRACTICE MOF
Record Release planning
Review & filter approved Release building
Change
Change Management
Release Management
approved Acceptance test
Classification Change
approved Readiness Review
Authorization Change
Roll-out Planning
Roll-out preparation
Asses (PIR) Roll-out

143. 143
Minimum Requirements
0000
ISO/IEC 2
tion
Specifica
• The release policy stating the frequency and type of
releases shall be documented and agreed upon.
• The service provider shall plan with the business the
release of services, systems, software and hardware.
Plans on how to roll out the release shall be agreed to by
all relevant parties (e.g. customers, users and support
staff).
• The process shall include the manner in which the release
shall be reversed or remedied if unsuccessful.
• Plans shall record the release dates and deliverables and
refer to related change requests, known errors and
problems.
• Requests for change shall be assessed for their impact on
release plans.

144. 144
Minimum Requirements
0000
ISO/IEC 2
tion
Specifica
• Release management process requires update and
change procedures for configurations items.
• To test releases before distribution requires a
controlled test environment.
• Release and distribution shall be designed and
implemented so that the integrity of hardware and
software is maintained at all times.
• Success and failure of releases shall be measured.
Measurements shall include incidents related to a
release in the period following a release. Analysis shall
provide input to a plan for improving the service.

145. 145
Code of Practice
0000
ISO/IEC 2
ctice
Co de of Pra
Release Policy
A document to define general requirements for release management.
A Release Policy should include:
• frequency and type of release (release types)
• roles and responsibilities for process
• authority for the release into acceptance test
• unique identification and description of all releases
• approach to grouping changes into a release
• approach to automating the plan, build and release distribution processes
• verification and acceptance of a release (e.g. error-free or covered by
known error database)

146. 146
Code of Practice
000
ISO/IEC 20 ce
racti
Code of P
• Release and Roll-out Plan
• Objective of Release Planning:
• Compatible with CI’s in target environment
• Ensure that all changes are authorized by Change Management (feedback)
• Release Plan:
• Detailed document to plan a concrete release (important: differs from release policy)
• The planning for a release and roll-out should typically include (abstract):
• release dates
• related changes
• problems and known errors closed or resolved by this release
• known errors that have been identified during testing of the release
• the manner in which the release will be reverted or remedied if unsuccessful
• detailed description of the required test
• communication training (particularly for customer and support staff)
• resources required for release

147. 147
Example: From Change to Release
Incident RfC Release
Install patch T12-02 Schedule:
It takes a long time to for web server Complete until
load our external web 2008-06-25
sites! Status: Accepted
Roll-out Plan
Change 1. Download patch
2. Install in test
Install patch T12-02 environment
Priority:
PIR Report
Medium (high impact,
low urgency) 1. Install in operative
environment
Category (risk): 2. Post Implementation
Minor Change Review

148. 148
Assessment Card Template
Sub
Se ction Re quir e m e nt of ISO20000
Se ction
10.1 Re le as e M anage m e nt
The release policy stating the f requency and type of
10.1 a
releases shall be documented and agreed
The service provider shall plan w ith the business the
10.1 b
release of services, systems, sof tw are and hardw are
Code of Practice
P lans on how to roll out the release shall be agreed and
ISO/IEC 20000
10.1 c authorized by all relevant parties, eg. Customers, users,
operations and support staf f
The process shall include the manner in w hich the release
10.1 d
shall be backed out or remedied if unsuccessf ul
P lans shall record the release dates and deliverables and
10.1 e ref er to related change requests, know n errors and
problems
The release management process shall pass suitable
10.1 f
inf ormation to the incident management process
Requests f or change shall be assessed f or their impact on
10.1 g
release plans
Release management procedures shall include the updating
10.1 h and changing of conf iguration inf ormation and change
records.
E mergency releases shall be managed according to a
10.1 i def ined process that interf aces the emergency change
management process
A controlled acceptance test environment shall be
10.1 j
established to build and test all releases prior to distribution
Release and distribution shall be designed and implemented
10.1 k so that the integrity of hardw are and sof tw are is maintained
during installation, handling, packaging and delivery

149. 149
Section 6: Service Delivery Processes
About the process group
Service delivery processes handle long-term service planning and
management of service delivery requirements.
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

150. 150
Learning target of this section
• Objectives, requirements and best practices within
Service Level Management (3.3.1, 4.3.1)
• Objectives, requirements and best practices within
Service Reporting (4.3.2)
• Objectives, requirements and best practices within
Budgeting and Accounting for IT Services (3.3.3, 4.3.3)
• Objectives, requirements and best practices within
Service Continuity and Availability Management (3.4.1,
4.4.1)
• Objectives, requirements and best practices within
Capacity Management (3.4.2, 4.4.2)
• Objectives, requirements and best practices within
Information Security Management (3.4.3, 4.4.3)

151. 151
Service Level Management
Objective:
To define, agree, record and manage levels of service.
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

152. 152
Fundamental terms
•Service Level Agreement (SLA)
An agreement between an IT service provider and a
customer which describes the IT service and service
level targets.
•Additional terms
•Service Level - Acceptable quality level of a
service
•Service Catalogue - A structured document
with information about all provided services (may
contain reference to SLA)

153. 153
Supporting Service Agreements
Business
Service Level Agreements
Service A Service B Service C
Service
Provider
IT Systems
Service Agreements / OLAs
Contracts Contracts
Internal Organizations Suppliers Lead Suppliers
Subcontracted Suppliers

154. 154
Service Level Agreements
Possible SLA content (abstract):
• Service description
• Validity period
• Authorization details
• Service hours
• Service targets
• Escalation and notification process
• Guidelines to define impact and priority
• Workload limits
• etc.

155. 155
Minimum Requirements
0000
ISO/IEC 2
tion
Specifica
• The full range of services to be provided together with the
corresponding service level targets and workload
characteristics shall be agreed to by the parties and
recorded.
• Each service provided shall be defined, agreed upon and
documented in one or more service level agreements
(SLA’s).
• SLA’s, together with supporting service agreements,
supplier contracts and corresponding procedures, shall be
agreed to by all relevant parties and recorded.
• The SLA’s shall be under the control of the change
management process.
• The SLA’s shall be maintained by regular reviews.
• Service levels shall be monitored and reported as
compared to targets.

156. 156
Service Level Management: Best Practices
0000
ISO/IEC 2
actice
C ode of Pr
• A service catalogue defining all services should be up-to-date
and easily accessible for both customers and support staff.
• SLA’s should be defined from a customer perspective.
• SLM process should be flexible to accommodate major business
changes and changing customer requirements.
• Service provider should be given adequate information in order
to understand their customer’s business drivers and
requirements.
• SLM process should encourage both the service provider and
the customer to be proactive and take joint responsibility for the
service.
• Customer satisfaction is key but should be recognized as a
subjective measurement.
• Supported services should be documented and agreed upon
with each supplier, including internal groups.

157. 157
Assessment Card Template
6.1 Service Level Managem ent
The f ull range of services to be provided together w ith the
6.1 a corresponding service level targets and w orkload
Code of Practice
ISO/IEC 20000
characteristics shall be agreed by the parties and recorded.
Each service provided shall be def ined, agreed and
6.1 b
documented in one or more service level agreements
SLA's, together w ith supporting service agreements, third
6.1 c party contracts and corresponding procedures, shall be
agreed by all relevant parties and recorded
6.1 d The SLA's shall be under Change Control
The SLA's shall be maintained by regular review s by the
6.1 e parties to ensure that they are up to date and remain
ef f ective over time
Service levels shall be monitored and reported against
targets, show ing both current and trend inf ormation. The
6.1 f reasons f or non-conf ormance shall be reported and
review ed and shall provide input to service improvement
plan

158. 158
Service Reporting
Objective:
To produce agreed, timely, reliable and accurate reports for
informed decision making and effective communication.
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

159. 159
Minimum Requirements
0000
ISO/IEC 2
tion
Specifica
• There shall be a clear description of each service report
including its identity, purpose, audience and details of the
data source.
• Service reports shall be produced to meet identified needs
and customer requirements. Service reporting shall include:
performance against service level targets
non-compliance and issues (e.g. against the SLA, security
breech)
workload characteristics (e.g. volume, resource utilization)
performance reporting following major events (e.g. major
incidents and changes)
trend information
satisfaction analysis
• Management decisions and corrective actions shall take into
consideration the findings in the service reports and shall be
communicated to relevant parties.

160. 160
Assessment Card Template
Sub
Se ction Re quire m e nt of ISO20000
Se ction
6.2 Se rvice Re porting
There shall be a clear description of each service report
6.2 Para-1 including its identity, purpose, audience and details of the
Code of Practice
ISO/IEC 20000
data source
Service reports shall be produced to meet identif ied needs
Para-2
and customer requirements.
Service reporting shall include: perf ormance against service
6.2 a
level targets
Service reporting shall include: non-compliance and issues,
6.2 b
eg. Against the SLA, security breach
Service reporting shall include: w orkload characteristics,
6.2 c
eg. Volume, resource utilization
Service reporting shall include: perf ormance reporting
6.2 d
f ollow ing major events eg. Major incidents and changes
6.2 e Service reporting shall include: trend inf ormation
6.2 f Service reporting shall include: satisf action analysis
Management decisions and corrective actions shall take into
6.2 Para-3 considerations the f indings in service reports and shall be
communicated to relevant parties

161. 161
Event Management
BEST according to
PRACTICE ITIL® Version 3
• Service reports are based on events and event statistics
respectively.
• Event - a change of state that has significance for the
management of a Configuration Item or IT Service.
• Classification of events:
Informational Event – purely informative, for reporting purpose
 no action required
Warning – A service or device is approaching a threshold 
notify the appropriate persons, process or tool
Exception – currently operating abnormally, SLA breach 
Reaction required
• Exceptions can cause incidents and/or requests for change.

162. 162
Service Continuity & Availability Management
Objective:
To ensure that agreed service continuity and availability
commitments to customers can be met in all circumstances.
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

163. 163
Fundamental terms
Availability
Ability of a component or service to perform its agreed
function when required.
Additional terms
Availability Plan - a document to define aspects of
service availability in day-to-day operations
Service Continuity - the capability to continue
service operations in exception cases
Service Continuity Plan - a document to manage
risks of exceptional events in order to continue or
recover IT services

164. 164
Average Availability

165. 165
Process
BEST according to
PRACTICE ITIL® Version 2 & 3
Activities within Availability Management
Define availability requirements:
•SLA requirements?
•What is the maximum duration with or without constricted
service that is acceptable for customers?
•What is the maximum frequency of service failure that is
acceptable for customers?
Plan availability:
•Average Availability
•Serviceability
•Maintainability
Measure availability

166. 166
Process
BEST according to
PRACTICE ITIL® Version 2 & 3
Activities within Continuity Management
• Define continuity requirements:
•SLA requirements?
•Business critical systems/services?
•Maximum duration with or without constricted service that is acceptable for
customers?
• Plan service continuity:
•Preventive measures
• Technical - provide standby systems, emergency power supply, etc.
• Organizational - reciprocal arrangements
•Recovery options
• Do nothing
• Manual work-around
• Cold Standby, Warm Standby, Hot Standby
•Documentation of recovery procedures and operational instructions
•Regular test and review of all plans

167. 167
Process
BEST according to
PRACTICE ITIL® Version 2 & 3
Common Activities
Component Failure Impact Analysis (CFIA)
•Analyze IT infrastructure dependencies
•Identification of Single Point of Failures (SPOF’s)
Business Impact Analysis (BIA)
•Analyze dependencies between services and business
processes
•Quantification of business impact of service failure
Risk Analysis Assets Vulnerabilities Threats
•Assets
•Vulnerabilities
Risk
•Threats
Countermeasure

168. 168
Minimum Requirements
0000
ISO/IEC 2
tion
Specifica
• Availability and service continuity requirements shall
be identified on the basis of business priority, SLA’s
and risk assessments.
• Availability and service continuity plans shall be
developed and reviewed at least annually.
• The availability and service continuity plans shall be
re-tested at every major change to the business
environment.
• The change management process shall assess the
impact of any change on the availability and service
continuity plan.

169. 169
Minimum Requirements
0000
ISO/IEC 2
tion
Specifica
• Availability shall be measured and recorded.
Unplanned non-availability shall be investigated and
appropriate actions taken.
• Service continuity plans, contact lists and the CMDB
shall be available when normal office access is
prevented.
• The service continuity plan shall include the return to
normal working.
• The service continuity plan shall be tested in
accordance with business needs.
• All continuity tests shall be recorded and test failures
shall be formulated into action plans.

170. 170
Assessment Card Template
Sub
Se ction Re quir e m e nt of ISO20000
Se ction
6.3 Availability and Se r vice Continuity M anage m e nt
A vailability and service continuity requirements shall be
identif ied on the basis of business plans, SLA 's and risk
6.3 a assessments. Requirements shall include access rights and
Code of Practice
response times as w ell as end to end availability of system
ISO/IEC 20000
components
A vailability and service continuity plans shall be developed
and review ed at least annually to ensure that requirements
6.3 b
are met as agreed in all circumstances f rom normal through
to a major loss of service.
These plans shall be maintained to ensure that they ref lect
6.3 c
agreed changes required by the business
The change management process shall assess the impact
6.3 d
of any change on the availability and service continuity plan
6.3 e A vailability shall be measured and recorded
unplanned no-availability shall be investigated and
6.3 f
appropriate actions taken.
Where possible, potential issues should be predicted and
6.3 g
preventive action taken
Service continuity plan, contact lists and the conf iguration
6.3 h management database shall be available w hen normal
of f ice access is prevented.
The service continuity plan shall be tested in accordance
6.3 i
w ith business needs
A ll continuity tests shall be recorded and test f ailures shall
6.3 j
be f ormulated into action plans

171. 171
Service Continuity and Availability Management:
Best Practices
000
ISO/IEC 20 ce
racti
Code of P
• Service Continuity and Availability processes should work
together to ensure agreed service levels are maintained.
• Processes should include elements of the delivery under the
control of the customer, suppliers or other service providers.
• Availability should be monitored and recorded, and resulting
corrective actions should be recorded and carried out.
• An overall service continuity strategy should be defined and
regularly reviewed. Any changes should be formally agreed upon.
• Service continuity plans and related documents should be linked
to change management and contract management processes.
• Testing should occur with sufficient frequency to ensure plans
remain effective.
• Testing should be a joint involvement between customer and
service provider.

172. 172
Budgeting & Accounting for IT services
Objective:
To budget and account for the cost of service provision.
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

173. 173
Basic Activities
• Budgeting - predicting demand behavior to forecast
costs of service and to manage expenditures
• Accounting - identify actual costs
• Charging - requiring payment for IT services from
customers
• Charging is not part of ISO/IEC 20000 requirements .

174. 174
Cost types and cost classifications
• Cost types
• Depends on purpose of costs
• Examples:
Hardware
Labor
Capital
Operation
etc.
• Cost classifications
• Direct and indirect costs
• Fixed and variable costs

175. 175
Minimum Requirements
000
ISO/IEC 20
tion
Specifica
• There shall be clear policies and processes for:
 budgeting, and accounting for all components including IT
assets, shared resources, overheads, externally supplied
service, people, insurance and licenses;
 apportioning indirect costs and allocating direct costs to
services;
 effective financial control and authorization.
• Costs shall be budgeted in sufficient detail to enable
effective financial control and decision making.
• Costs shall be monitored and reported as compared to
the budget.
• Review the financial forecasts and manage costs
accordingly.
• Changes to services shall include cost estimates and be
approved through the change management process.

176. 176
Budgeting and Accounting for IT Services:
Best Practices
0000
ISO/IEC 2
actice
C ode of Pr
• All accounting practices used should be aligned to the wider
accountancy practices of the whole organization.
• Policy should define the objectives to be met as well as the detail
to which budgeting and accounting are performed.
• Level of investment in financial processes should be based on
the need of customers, service provider and suppliers for
financial details.
• Budgeting should take into account planned changes to services
and the management of shortfalls/variances.
• Accounting should be used to track costs to an agreed level of
detail over an agreed period of time, and make cost of low levels
of service or loss of service visible.
• Where charging is in use (OPTIONAL!), the mechanism for
charging should be understood by all parties.

177. 177
Charging
BEST according to
PRACTICE ITIL® Version 2 & 3
Possible charging motivation:
• Demand management
• Cost reduction, identify inefficient areas of delivery
• Stronger alignment of services and business
requirements
Charging model (examples):
• costs
• cost-plus
• market price
• fixed price

178. 178
Assessment Card Template
Sub
Section Requirem ent of ISO20000
Section
6.4 Budgeting and Accounting for IT Services
There shall be clear policies and procedures for budgeting,
Code of Practice
and accounting for all components including IT assets,
ISO/IEC 20000
6.4 a
shared resources, overheads, third party supplied service,
people, insurance and licenses
There shall be clear policies and procedures for
6.4 b apportioning and allocating all indirect costs to relevant
services
There shall be clear policies and procedures for effective
6.4 c
financial control and authorization
Costs shall be budgeted in sufficient detail to enable
6.4 Para-1
effective financial control and decision making
The service provider shall monitor and report costs against
6.4 Para-2 the budget, review the financial forecasts and manage
costs accordingly
Changes to services shall be costed and approved through
6.4 Para-3
the change management process

179. 179
Capacity Management
Objective:
To ensure that the service provider has, at all times, sufficient capacity
to meet the current and future agreed demands of the customer’s
business needs.
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

180. 180
Fundamental terms
Capacity Plan:
• Current infrastructure performance
• Future needs
• Documentation of cost-calculated options to achieve requirements
and recommendations
• Shall be produced at least annually
Capacity Predictions:
• Modeling, Application Sizing
• Trend analysis
• Customer and business-related forecast
Demand Management - Influence user behavior for an
optimal capacity usage

181. 181
Minimum Requirements
0000
ISO/IEC 2
tion
Specifica
• Capacity management shall produce and maintain a
capacity plan.
• Capacity management shall address the business
needs and include:
current and predicted capacity and performance
requirements;
identified timelines, thresholds and costs for service
upgrades;
evaluation of effects of anticipated service upgrades, requests
for change, new technologies and techniques on capacity;
predicted impact of external changes, e.g. legislative;
data and processes to enable predictive analysis.
• Methods, procedures and techniques shall be identified to
monitor service capacity, tune service performance and
provide adequate capacity.

182. 182
Capacity Management: Best Practices
0000
ISO/IEC 2
ctice
Co de of Pra
 Requirements should be understood in terms of what the
business will need to enable it to deliver to customers.
 Utilization data should be captured and analyzed so that
results of variations in workload or environment become
predictable.
 Process should support development of new and
changed services by providing sizing and modelling of
services.
 Capacity plan should support SLA’s and should be
produced at a suitable frequency (at least annually).
 Current and projected capabilities of the technical
infrastructure should be well understood.

183. 183
Assessment Card Template
Sub
Section Requirem ent of ISO20000
Section
6.5 Capacity Managem ent
Capacity management shall produce and maintain a capacity
6.5 Para-1
Code of Practice
plan, w hich shall address the business needs
ISO/IEC 20000
Capacity plan shall include current and predicted capacity
6.5 a
and performance requirements
Capacity plan shall include identified time-scales, thresholds
6.5 b
and costs for service upgrades
Capacity plan shall include evaluation of effects of
6.5 c anticipated service upgrades, requests for change, new
technologies and techniques on capacity
Capacity plan shall include predicted impact of external
6.5 d
changes, eg. Legislative.
Capacity plan shall include data and processes to enable
6.5 e
predictive analysis
Methods, procedures and techniques shall be identified to
6.5 Para-2 monitor service capacity, tune service performance and
provide adequate capacity

184. 184
Information Security Management
Objective:
To manage information security effectively within all service
activities.
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security
Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

185. 185
Fundamental terms
Information security:
• Information security is the result of a system of policies and
procedures.
• Designed to protect information and any equipment used in
connection with its storage, transmission and processing.
ISO/IEC 27000:
• Bundle of information security ISO/IEC standards
• ISO/IEC 27001: Information Security Management Systems
– Requirements
• ISO/IEC 27002:
• former ISO/IEC 17799
• Code of Practice for Information Security Management

186. 186
Minimum Requirements
000
ISO/IEC 20
tion
Specifica
Management with appropriate authority shall approve an
information security policy that shall be communicated to
all relevant personnel and customers where appropriate.
Appropriate security controls shall operate to:
•implement the requirements of the information security policy;
•manage risks associated with access to the service or
systems.
Security controls shall be documented:
•The documentation shall describe the risks to which the
controls relate
•and the manner of operation and maintenance of the controls.

187. 187
Information Security Management:
Best Practices
00
C 200 ice
IS O/IE Pract
of • Serviceprovidera should maintain an inventory of the information
Co de
assets, classified according to criticality.
• Asset owners accountable for asset protection.
• Controls should be in place, such as:
- a defined and enforced security policy
- ISM roles and responsibilities
- information security training for staff with security roles, e.g.
knowledge of ISO/IEC 17799
- expert help on risk assessment and control implementation
- information security incidents handled within Incident
Management
Records should be analyzed periodically for control, measuring
effectiveness, trend identification, and improvement activities.

188. 188
Information Security Management:
Best Practices in Risk Assessment
000
ISO/IEC 20 ce
racti
Code of P
• Regular security risk assessments should be performed.
• Risks assessed based on:
- their nature
- likelihood
- potential business impact
- past experience
• Risk assessment should pay attention to disclosure of sensitive
information to unauthorized parties, fraudulent information, availability
of information, security policy objectives, specific customer security
requirements and statutory requirements.

189. 189
Assessment Card Template
Sub
Se ction Re quir e m e nt of ISO20000
Se ction
6.6 Inform ation Se curity M anage m e nt
Management w ith appropriate authority shall approve an
6.6 Para-1 inf ormation security policy that shall be communicated to all
relevant personnel and customers w herever appropriate
Code of Practice
ISO/IEC 20000
A ppropriate security controls shall operate to implement the
6.6 a
requirements of the inf ormation security policy
A ppropriate security controls shall operate to manage risks
6.6 b
associated w ith access to the service or systems
Security controls shall be documented. The documentation
6.6 Para-2 shall describe the risks to w hich the controls relate and the
manner of operation and maintenance of controls
The impact of changes on controls shall be assessed
6.6 Para-2
bef ore changes are implemented
A rrangements that involve third party access to inf ormation
6.6 Para-3 systems and services shall be based on a f ormal
agreement that def ines all necessary security requirements
Security incidents shall be reported and recorded in line
6.6 Para-4 w ith the incident management procedure as soon as
possible
P rocedures shall be in place to ensure that all security
6.6 Para-5
incidents are investigated and management action taken
Mechanisms shall be in place to enable the types, volumes
and impacts of security incidents and malf unctions to be
6.6 Para-6
quantif ied and monitored, and to provide input to the service
improvement plan

190. 190
Section 7: Relationship Processes
About the process group
Relationship processes describe the two related aspects of Supplier Management and
Business Relationship Management.
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

191. 191
Learning target of this section
• Objectives and requirements within Business
Relationship Management (3.3.4)
• Best Practices within Business Relationship
Management (4.3.4)
• Objectives and requirements within Supplier
Management (3.3.5)
• Best Practices within Supplier Management
(4.3.5)

192. 192
Tasks and Scope
0000
ISO/IEC 2
ctice
Co de of Pra
• The relationship processes should ensure that all parties:
• understand and meet business needs;
• understand capabilities and constraints;
• understand responsibilities and obligations.
• Supplier Management interfaces with suppliers. Business
Relationship Management interfaces with customers.
Supplier Business
Management Relationship
Management
Service
Supplier Business
Provider

193. 193
Business Relationship Management
Objective:
To establish and maintain a good relationship between the service
provider and the customer based on understanding the customer and
their business drivers.
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

194. 194
Minimum Requirements
0000
ISO/IEC 2
tion
Specifica
• The service provider shall identify and document the
stakeholders and customers of the services.
• A service review shall be conducted:
 with the participation of provider and customer; other
stakeholders may also be invited to the meetings;
 to discuss any changes to the service scope, SLA, contract
(if present) or the business needs
 at least annually;
 and results shall be documented.
• Changes to the contracts, if present, and SLA’s shall
follow from these meetings as appropriate and shall be
subject to the change management process.

195. 195
Minimum Requirements
0000
ISO/IEC 2
tion
Specifica
• The service provider shall remain aware of business needs
and major changes in order to prepare to respond to these
needs.
• There shall be a complaints process:
 The definition of a formal service complaint shall be agreed
up on with the customer.
 All formal service complaints shall be recorded and
managed.
 Where a complaint is not resolved, escalation shall be
available to the customer.
• There shall be a named individual who is responsible for
managing customer satisfaction.
• A process shall exist for obtaining customer satisfaction
information (shall be input for Service Improvement Plan).

196. 196
Assessment Card Template
Sub
Se ction Re quire m e nt of ISO20000
Se ction
7.1 Bus ine s s Re lations hip M anage m e nt
The service provider shall identif y and document the
7.2 a
stakeholders and customers of the service
The service provider and customer shall attend a service
Code of Practice
review to discuss any changes to the service scope, SLA ,
ISO/IEC 20000
contract (if present) or the business needs at least annually
7.2 b
and shall hold interim meetings at agreed intervals to
discuss perf ormance, achievements, issues and action
plans
7.2 c The customer review meetings shall be documented
Other stake holders in the service may also be invited to the
7.2 d
meetings
Changes to the contract(s), if present, and SLA (s) shall
7.2 e
f ollow f rom these meetings as appropriate.
These changes shall be subject to the change management
7.2 f
process
The service provider shall remain aw are of business needs
7.2 g and major changes in order to prepare to respond to these
needs
7.2 h There shall be a complaint procedure
The def inition of a f ormal service complaint shall be agreed
7.2 i
w ith the customer
All f ormal service complaints shall be recorded by the
7.2 j service provider, investigated, acted upon, reported and
f ormally closed.

197. 197
Supplier Management
Objective:
To manage suppliers to ensure the provision of seamless,
quality services.
[6] Service Delivery Processes
Service Level Management
Capacity Management Service Reporting Information Security Management
Service Continuity & Budgeting & Accounting
Availability Management
[9] Control Processes for IT services
Configuration Management
[10] Release Change Management [7] Relationship
Process Processes
[8] Resolution Processes Business Relationship
Incident Management Management
Release Management
Problem Management Supplier Management

198. 198
Fundamental Terms
• Supplier
• Lead Supplier - A supplier who obtains parts of
delivered services from a third-party
• Subcontracted Supplier - Supplier of a lead
supplier
Supplier 1
Supplier 2 Service Provider Business
Subcontracted Lead (internal or third-
Supplier 4 Supplier 3 party)

199. 199
0000
ISO/IEC 2
Specifica
tion Minimum Requirements
• There shall be documented supplier management
processes and a contract manager responsible for
each supplier.
• The scope, level of service and communication
processes of the delivered services shall be
documented in SLA’s.
• SLA’s with suppliers shall be aligned with the SLA’s for
the customers.
• The interfaces between processes used by each party
shall be documented and agreed upon.
• All roles and relationships between lead and
subcontracted suppliers shall be clearly documented.
Lead suppliers shall be able to demonstrate processes
to ensure that subcontracted suppliers meet
contractual requirements.

200. 200
0000
ISO/IEC 2
Specifica
tion Minimum Requirements
• A process shall be in place for a major review of the
contract:
at least annually
to ensure that business needs are still being met
to ensure that contractual obligations are still being met
• Changes to the contracts, if present, and SLA’s shall
follow from these reviews as appropriate and shall be
subject to the change management process.
• Processes shall exist:
to deal with contractual disputes
to deal with the expected end of service, early end of the service
to deal with transfer of service to another party
• Performance shall be monitored and reviewed:
Compared to service level targets
Actions for improvement shall be input for a service improvement
plan.

201. 201
Assessment Card Template
Sub
Se ction Re quir e m e nt of ISO20000
Se ction
7.2 Supplie r M anage m e nt
The service provider shall have documented supplier
7.3 a management processes and shall name a contract manager
responsible f or each supplier
Code of Practice
The requirements, scope, level of service and
ISO/IEC 20000
communication processes to be provided by the supplier(s)
7.3 b
shall be documented in SLAs or other documents and
agreed by all parties
SLA's w ith the supplier shall be aligned w ith the SLAs w ith
7.3 c
business
The interf aces betw een processes used by each party
7.3 d
shall be documented and agreed
All roles and relationships betw een lead and subcontracted
7.3 e
suppliers shall be clearly documented.
Lead suppliers shall be able to demonstrate processes to
7.3 f ensure that subcontracted suppliers meet contractual
requirements
A process shall be in place f or a major review of the
contract or f ormal agreement at least annually to ensure
7.3 g
that business needs and contractual obligations are still
being met.
Changes to the contract(s), if present, and SLA(s) shall
7.3 h f ollow f rom these review s as appropriate or at other times
as required
A f ormal process shall exist to deal w ith contractual
7.3 i
disputes

202. 202
Classification and
Perspective
 Certification
• Related practices and standards
• ISO/IEC 20000 Qualification Program

203. 203
Learning target of this section
• Certification outline (2.2.3)

204. 204
Prepare Certification
• Choose a Registered Certification Body (RCB)
• Define Scope of certification together with RCB
• Conduct initial assessment:
Internal or third-party
Methodology e.g.
• Self-Assessment Workbook PD0015
• Pre-audit of RCB / Certifier
• Apply maturity model, degree model
• All requirements considered?
• Arrange a time and date for audit.

205. 205
Scoping
• The Scope defines the effective range of
the management system.
• Scoping Statement includes:
Services
Geographical and local restrictions
Organizational and functional restrictions
Infrastructural restrictions

206. 206
Scoping – Pictorial Depiction

207. 207
Roles and Responsibilities in Certification
• Internal or external consultants can aid organizations
in preparing for certification.
• Internal audits, to idenitfy any non-conformances, can
be carried out by internal auditors.
• Certification audit has to be carried out by a
Registered Certification Body (RCB).
• Most countries have local RCB’s, which are
registered with the National Accreditation Body.

208. 208
Certification
• Prerequisite: Ownership and control of all processes
defined within ISO/IEC 20000
• Certification audit:
– The audit typically consists of:
• Verification of documents
• on-site inspection
• reporting
– Evidence of reviewed and approved procedures (process
descriptions):
• Knowledge and control of process input
• Knowledge, usage and interpretation of process output
• Metric definition and evaluation
• Accountability for process functionality according to ISO/IEC
20000 standard
• Define, measure and review process improvements
– Required effort:
• Depends on number of people and locations
• Related to ISO (effort scale)

209. 209
After the Certification
• The certification is valid for three years:
– Surveillance audits are performed every year
normally.
– Full recertification required every three years.
• Certified Organizations:
www.isoiec20000certification.com

210. 210
Benefits of Certification and Compliance
• Visible short term benefits:
• improved efficiency and effectiveness
• cost savings
• improved customer satisfaction
• improved service quality
• Medium to long term benefits:
• to create new business and/or attract new customers, as certification
is required for some tendors
• to enter global markets, as the standard is international
• to have better and more traceable documentation, e.g. for
legislative purposes
• to give your company a competitive edge based upon quality drive

211. 211
ISO 20000 Implementation Roadmap

212. 212
Classification and
Perspective
• Certification
 Related practices and standards
• ISO/IEC 20000 Qualification Program

213. 213
Learning target of this section
• Field of application, objective, audience
and owner of CMMI, CobiT, ISO 9000, ISO
15504, ISO/IEC 27001, ITIL® , MOF and Six
Sigma (2.1.1)
• Principles of maturity degree models
(1.5.2)

214. 214
Related Standards - Overview
ISO 9000
ISO/IEC 27000
Six Sigma
BS 15000 ISO/IEC 20000
ITIL® V2 ITIL® V3
Legende
(from CobiT V4) MOF Quality Management
standard/methodology
CobiT IT Management
Framework
Software Engineering
CMM CMMI maturity degree model
Adoption of concepts
ISO/IEC 15504 predecessor

215. 215
ISO 9000
• Owner: ISO
• Field of application / audience: industry and service
providers / management, customers
• Objective: International quality management standard,
certified companies
• Publication media / source: Standard (printout,
PDF) / via ISO
• Miscellaneous:
ISO 9000 comprises a series of documents.
Best known: ISO 9001 - Quality management systems
- Requirements
ISO 9000 process approach

216. 216
ISO/IEC 27000
• Owner: ISO/IEC
• Field of application / audience: All types of
organizations / management, customers
• Objective: International information security standard,
certified companies
• Publication media / source: Standard (printout,
PDF) / via ISO
• Miscellaneous:
ISO 27000 comprises a series of documents.
Best known: ISO 27001 – Information Technology --
Security techniques -- Information security
management systems -- Requirements
ISO 27000 process approach, PDCA implemented

217. 217
Six Sigma (6σ)
• Owner: none
• Field of application / audience: Historically it has
been primarily for industry, but is increasingly used by
service providers / management
• Objective: Increase in productivity (e.g. reducing
spread for standard factory models) through use of
different quality management methodologies
• Publication media / source: Many books (no official
general document) / book trade
• Miscellaneous:
The use of statistical tools to achieve structured
improvement is characteristic of Six Sigma.
„6σ“ relates to a statistical quality target (defect free
yield of 99,99966%).

218. 218
IT Infrastructure Library (ITIL®)
• Owner: Office of Government Commerce (OGC)
• Field of application / audience: IT Service
Provider / Management
• Objective: Best Practice Guidance for IT Service
Management
• Publication media / source: Books and CD’s
published by TSO (The Stationary Office) / book
trade
• Miscellaneous:
ITIL® Version 2 is the most popular ITSM framework
Since Summer 2007, fully revised version 3 (ITIL®
V3) available

219. 219
ITIL® Version 2
Content of ITIL® V2
Service Support Book: Operational processes
Service Delivery Book: Tactical processes
Security Management Book
Some additional books
Planning to implement Service Management
T
B e
Management
Infrastructure
u Service c
s Perspective Support h
Business
i n
n o
e Service l
s o
s Delivery g
Security y
Application Management Management
Suppliers

220. 220
ITIL® Version 3
• Service lifecycle-oriented approach

221. 221
Mapping ISO 20000 Standard to the Service Lifecycle
Service Strategy:
Requirements for a Management System
Budgeting and Accounting
Service Design:
Planning and Implementing New or Changed Services
Other disciplines (e.g. Availability Management, Capacity
Management, Service Level Management)
Service Transition:
Change, Configuration and Release Management
Service Operation:
Incident and Problem Management
Continual Service Improvement:
Planning & Implementing Service Management

222. 222
Mapping Deming Cycle to the Service Lifecycle
Plan:
Service Strategy
Service Design
Do:
Service Transiton
Service Operation
Check and Act:
Continual Service Improvement

223. 223
What is (not) ITIL® ?
What is covered by ITIL®: What is not covered by
• Definition of IT processes: ITIL®:
Objectives Certifiable standard
Cp. ISO/IEC
20000
Activities
In-/Outputs • Resilient set of minimum requirements
Interfaces within
• Recommendations for
• Software, tools
process implementation:
requirements (e.g. staff skills)
• Formal models and templates for:
supporting concepts
• processes
required functions
• relations
risks
• information artifacts
• Evaluation hints:
Critical success factors
Key performance indicators

224. 224
Process Document Contents
1) Introduction
2) Objective
3) Scope
4) Target Audience
5) Process Roles
6) Inputs
7) Process Flow
8) Process Details
9) Outputs
10) Process Metrics
11) Process Interfaces
12) Appendix
13) Glossary

225. 225
Microsoft Operations Framework (MOF)
• Owner: Microsoft
• Field of application / audience: IT Service
Provider / Management
• Objective: Operational Guidance for users of
Microsoft products
• Publication media / source: printable files
(Word, PDF) / free from web
(www.microsoft.com/mof)
• Miscellaneous: Based on ITIL® V2, but providing
prescriptive guidance extended to ITIL® ’s
descriptive guidance

226. 226
MOF 4.0: Framework
• Composition:
Process model
Team model
Risk management
disciplines
• Process model
divided in four
quadrants
• Process model
extended and
substantiated
from ITIL® V2

227. 227
Capability Maturity Model Integration (CMMI)
• Owner: Software Engineering Institute (SEI) of
Carnegie Mellon University
• Field of application / audience: Software and
system developing organizations / management,
customers
• Objective: Measurement of Organizational Maturity
• Source: Printable files (Word, PDF) / free from web
(www.sei.cmu.edu/cmmi)
• Miscellaneous: No ITSM standard, but maturity
levels is a frequently used concept

228. 228
CMM / CMMI Maturity Levels
Optimizing
Process improvement is established
Managed
Monitoring of quantitative quality goals
Defined
Standard processes implemented and documented
Repeatable
Basic process existing
Initial

229. 229
Capability Assessments
• Compares the performance of a process against a
performance standard, such as:
– agreements in a SLA
– a maturity standard
– a benchmark (comparison to average in the industry)
– an ISO standard
• Assessments will help in identifying ‘where are we now?’
and the gap with ‘where we want to be’
• Crucial to define clearly what is being assessed
• Identifies conformances, non-conformances and
observations

230. 230
Types of Capability Assessments
• Evaluation of individual processes within the
management system
• Systematic review of the entire management system by
top management
• Comprehensive review via self-assessment, e.g. BIP 0015
Self-Assessment Guide Book as support aid
• Official first, second or third party audits
• Benchmark projects e.g. itSMF benchmark based on
comprehensive process questionnaire

231. 231
ISO/IEC 15504
• Owner: ISO/IEC
• Field of application / audience: Software and
system developing organizations / management,
customers
• Objective: International standard of organizational
maturity assessment
• Publication media / source: Standard (printout,
PDF) / via ISO
• Miscellaneous: The standard results from the
European project SPICE (Software Process
Improvement and Capability Determination)

232. 232
CobiT
• CobiT – Control Objectives for Information and
Related Technology
• Owner: ISACA/ITGI (Information Systems Audit
and Control Association / IT Governance Institute)
• Field of application / audience: IT service
provider / management, customers, IT auditors
• Objective: IT Governance – „Control of IT“
• Source: Core documents free from ISACA website
(www.isaca.org/cobit.htm, registration required)

233. 233
CobiT: Framework
• 34 processes,
structured in four
lifecycle domains
• For each process:
High-Level Control
Objective
Detailed Control Objectives
Management Guidelines
Maturity Model

234. 234
Company Specific Standards
• Tailor-made to a specific organization
• Often based upon existing frameworks and models, e.g.
MOF (based on ITIL, designed to support Microsoft
products)
• Company specific standards need to conform to ISO/IEC
20000 Part 1 requirements, in order to gain certification
• Various standards and frameworks used by one
organization need to be aligned to each other
• Examples:
Security policies
Standards concerning IT architecture
In-company finance standard

235. 235
Classification and
Perspective
• Certification
• Related practices and standards
 ISO/IEC 20000 Qualification Program

236. 236
analyze, ISO/IEC 20000 Qualification Program
assess, create
apply &
analyze
Associate
Consultant/Auditor
remember &
understand

237. 237
Professional Level Modules
Management
and Alignment of
Support of Control of Delivery of
Improvement IT and the
IT Services IT Services IT Services
of ITSM Business
Processes
• Incident •Planning & •Requirements •Business •Service
Implementing for a Relationship Continuity &
Manage New or Changed Management Management Availability
ment Services System section 7.2 Management
section 5 section 3 •Service Level section 6.3
section •Configuration •Planning and Management •Capacity
8.2 Management Implementing section 6.1 Management
section 9.1 Service •Service section 6.5
• Problem •Change Management Reporting •Information
Management section 4 section 6.2 Security
Manage section 9.2 Management
•Supplier
ment •Release Management section 6.6
section Management section 7.3
section 10 •Budgeting and
8.3 Accounting for
IT Services
section 6.4

238. Case Study 238
Introduction
7BLUES was set up in 1981 to provide aid to customers whose PCs have broken down in the form of Annual
Maintenance Contracts (AMC) based services. This service has been achieved by a mix of 7BLUES’s own
technicians and outsourced partners. Over the last 1 year they have begun to grow their business on three
fronts by:
1.Expanding their customer base, by moving into new areas of operation and by achieving a reputation of
providing a quality service
2.Expanding their service portfolio into other Desktop related services that will appeal to their existing
customers.
3. Introducing a web-site offering membership applications and other cloud based Services.
The services are supplied by a structure based upon a strong Head office, in Bangalore, India, and satellite
offices throughout their area of operation. Until recently the local offices, whilst bound to the practices lay
down by Head Office, took calls from customers needing assistance in their area and arranged to get help to
them. This has been changing over the last 6 months as a new centralized Service Desk has been setup and a
new Remote Management Centre has been implemented in the Head Office. Accordingly, the future of the
local offices is under review. The number of such offices will certainly be reduced and a revised role for
those that remain is not yet certain.

239. 239
At present there are 180 people working in the HQ, 60 of them work in the IT department.
There are 24 regional offices, each with between 4 and 12 staff. Field staffs of
approximately 920 are supported by about 60 staffs who are responsible for training,
supervision and maintenance. Contracts exist with 5 outsourced service providers for the
provisioning of spares.
The organization is successful in an increasingly competitive field. They realize that
versatility is the order of the day and they are looking at offering cloud based services as a
future set of service offerings. They also plan to expand into new geographical areas, into
new services by means of co-operations with other organizations where possible. The
organization has set itself a target of 15% annual growth, to be achieved with a maximum
increase in costs of 5% per year in real terms. A part of the growth is related to cost
effective service provisioning by incorporating latest technologies and looking at
automation of routine activities.

240. 240
Exercise
IT services
The infrastructure consists of a mainframe in the Head office, together with an extensive LAN
supporting a PC on almost every desk. Each regional office has PCs, most have a LAN and all have
links via a WAN into the head office.
Key IT services are:
Desktop/PC Support Services (PCSS)
This is the ‘legacy’ of the 7BLUES IT unit. The Core Asset Tracker runs on the mainframe and keeps a
track of all existing customer data including the systems supported including their configuration details
and is mostly accessed via PCs through the LAN and/or WAN.
The system should be running 24 hours x 7 days including all public holidays.
Direct Stock and Sales (DSS)
This system supports the (relatively) new direct sales to customers. It resides on a network server within
HQ, although use is made of the customer data held on the mainframe, as discounts are available to
those taking AMC with 7BLUES. Since sales are made directly from shops at the regional sites, access
to the central stock and pricing is made over the WAN.
Personnel and Administration Control (PAC)
Basically Personnel and Finance, much of the input is directly from paperwork and the service is used
mostly within the PAC section at Head Office. Pay slips etc produced in Head Office are posted to
remotely based staff. This system was developed by Finance Systems – an independent software
company based in Delhi, India - who maintain the system under an external contract.

241. 241
Insurance Services System (ISS)
Holds local data on policies and customers and provides links via modems to underwriting companies for
quotes. Insurance is dealt with by telesales from Head Office and by direct ‘over the counter’ transactions
at some of the local offices.
Office Systems
7BLUES have recently adopted Open Office© as their preferred office system, although there are still
pockets of staff other software purchased locally. Traditionally, staffs have been able to acquire software
for specific requirements on local and low level sign off. Accordingly there is a diversity of schedulers,
graphics, and even project management software around the organization.
Web-site
The web-site is increasingly important as the percentage of business done by this method is continuing to
increase. There is a 7 x 24 x 365 requirement for the availability of this web-site.
The 7BLUES hardware is maintained by a third party Maintenance Company, IIHS. They have staff
based across all over India.

242. 242
IT Service Management
As an organization whose core business is built around responding to customer contacts and delivering a
committed level of service, the ethos of help desk and service level agreements are well understood by
managers and most of the staff.
Service Level agreements are in place across the organization. In view of the critical nature of the IT
services to 7BLUES central functions, a team dealing with Availability and IT Contingency has recently
been established. The IT Service Continuity elements are considered as part of the organization’s overall
Business Continuity Management.
A Centralized Service Desk has recently been formulated and the customers have been made aware of the
1800-7BLUES-INDIA toll free number. The new Service Support Manager has been slowly increasing the
formalization of referring calls to second line and specialist support groups through pre-defined escalation
procedures. Formal Change Management procedures exist and an up to date CMS is in place.
It is well realized that 7BLUES are becoming ever more dependent upon the PCSS system for their
operational effectiveness - if that fails they can not function. This has perhaps diverted attention from the
rest of the IS provision and made those working on enhancing and maintaining the PCSS system into an
‘elite’ who sometimes feel ‘above the rules’.
There is a commitment to training and most of the IT Service Management staff has received some ITIL
based training.

243. 243
Some Constraints
• There appears to be a breakdown of communication between the IT department of 7BLUES and the
business units. Due to a lack of understanding about systems and processes within the IT organization
the day-to-day operation of the business is being affected. The business feels that there is a lack of
internal cohesion within IT and this is causing the channels of communication to be confused and
disorganized.
• The introduction of Incident and Problem Management have highlighted issues around the poor
control of changes made to the IT infrastructure. In the previous 4 months 43% of changes released
have resulted in Incidents being raised. Currently, each Regional Offices has its own ad hoc process
for change coordinated through the Project Delivery Managers.
• Each Regional Office have their own CMDB and process. However, there is no standard product or
process to manage configurations throughout the organization. All audits are carried out internally by
each Regional Office. The CIO has communicated a desire to keep moving towards a best practice
approach with process-oriented systems. However, some teams are continuing to resist and work in
isolation.

244. 244
Exercise
Considering the case study ISO 20000 Implementation Approach:
Make two groups of participants.
Group No 1:
Presentation of 30 Mins include details of
1)Planning phase
2)Gap Analysis
Group No: 2
Presentation of 30 mins include details of
1)Enablement
2)Internal Audit

245. 245
Contact Information
EXIN International
Godebaldkwartier 365, 3511 DT Utrecht
P.O. box 19147, 3501 DC Utrecht
The Netherlands
tel: +31 30 234 48 25
fax: +31 30 234 31 11
e-mail: info@exin-exams.com
web: www.exin-exams.com
This documentation was developed in collaboration Leibniz-Rechenzentrum der
with Leibniz-Rechenzentrum. Bayerischen Akademie der
Responsible authors: Wissenschaften
Dr. Michael Brenner, Thomas Schaaf Boltzmannstraße 1
D-85748 Garching
www.lrz.de
Copyright © 2008 EXIN/TUV SuD Akademie
All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system or
circulated in any form by print, photo print, microfilm or any other means without written permission by EXIN/TUV SuD Akademie.
ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce,
and is Registered in the U.S. Patent and Trademark Office.
IT Infrastructure Library® is a Registered Trade Mark of the Office of Government Commerce.