ITSM Foundation Course Material

Training Reference Material IT Service Management according to ISO/IEC 20000
Welcome & Administration

Structure of the training ISO/IEC 20000 certification and course outline Examination format Agenda
Structure of the training
Welcome & Administration Introduction to IT Service Management

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 1-5 - basics
Content of ISO/IEC 20000-1 and ISO/IEC 20000-2
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
ISO/IEC 20000 Qualification Program
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.
Course Material
Goal of this slide set

Preparation for an ISO/IEC 20000 Foundation Exam according to specifications from EXIN and TV SD Akademie.
Notations used in this slide set:

Blue background Definitions according to ISO/IEC 20000 Minimum requirements of ISO/IEC 20000-1 ISO/IEC 20000-2 recommendation
BEST according to PRACTICE
A best practice, but no ISO/IEC 20000 requirement or recommendation
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
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)
Motivation of Process Orientation

Availability is the most essential service parameter of enterprise services. Availability is determined by frequency and duration of service failure. About 80% of failures are a consequence of people and process issues. Duration of failures heavily depends on non-technical factors.
Application Failures Technology Operator Errors
Causes of service failure

[Gartner 1999]
Need for Management of IT Processes!
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
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
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 Part 1: Specification shall Recommendations should
ISO/IEC 20000-2:
Information Technology Service Management Part 2: Code of Practice
13
Context of ISO/IEC 20000
ISO/IEC 20000-1
SHALL/MUST-HAVEs Minimum Requirements Check lists
ISO/IEC 20000-2
SHOULD-HAVEs Enhancement of Part 1 Recommendations
Basics: IT Service Management (e.g. ITIL , MOF, CobiT) & Quality Management (e.g. ISO 9000)
14
Related Standards Overview

ISO 9000 Six Sigma BS 15000 ISO/IEC 27000
ISO/IEC 20000
ITIL V2
ITIL V3
Legend
(since CobiT V4)
MOF
Quality Management
standard / methodology
CobiT
IT Management Framework Software Engineering CMMI

Maturity Degree Model
CMM
Adoption of concepts
ISO/IEC 15504
Predecessor
15
Basic Principles and Concepts

Process
Processes in general Business Processes IT Processes
Service Process Management Process Assessment Quality and Quality Management
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
Example Business Process Workflow
18
Managements 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
Output
Activity
Output
Activity
Input Control factors
Output
Input
Control factors
Control factors
Domain 1
Domain 2
Domain 3
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
What is a Service? Definition according to ITIL Version 3 (goaloriented)

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 managementrelevant aspects of a service.
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
A Possible Service Model
23
ITSM: Basic Relationships

Business Processes are supported by IT Services. Delivering IT Services is the key task of an IT provider. Customers of the IT provider are basically organizations that are involved in business processes. Users use IT Services to carry out day-to-day activities. ITSM Frameworks describe Best Practices of IT Service Management.
Customer
is responsible User
Business Process
supports use Management
IT Service
delivers
IT Provider
ITSM Best Practice
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
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
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
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
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 customers perspective Customer perception of service quality may vary over time
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. SLAs) Requirements of ISO/IEC 20000
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
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
What is a Quality Management System?

Strategy
QUALITY MANAGEMENT SYSTEM
Process
33
Objective of a Quality Management System
Right products
Right Suppliers
Right People Competent, aware and trained
Right Documents that are managed
Senior Management Buy-In
Requirements for a Management System (Sec 3)
Good communication
34
Steps to Establish a Quality Management System
Identify customers requirements and expectations. Define and assign required resources to achieve the committed quality goals. Launch procedures to measure effectiveness and efficiency.
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
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
Capacity Management Service Continuity & Availability Management Service Level Management Information Security Management Service Reporting
[9] Control Processes

Configuration Management Change Management
Budgeting & Accounting for IT services
[10] Release Process

Release Management
[7] Relationship Processes

Business Relationship Management Supplier Management
[8] Resolution Processes

Incident Management Problem Management
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
Content of ISO/IEC 20000 Part 1: Basics

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

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
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
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
Section 2: Terms and Definitions

Objective
Basic Definitions and Standardized Terminology
44

Terms and Definitions according to ISO/IEC 20000 (2.3.6)
45
Terms and Definitions: Overview

Availability (6.3) Baseline (9.1) Change Record (9.2) Configuration Item (9.1) Configuration Management Database (9.1) Document Incident (8.2) Problem (8.3)
Record Release (10.1) Request for Change (9.2) Service Desk Service Level Agreement (6.1) Service Management Service Provider
Grey highlighted terms: Definitions - see the following slides All other terms: See Specification Sheet Section 7.5 for full list
46
Documents and Records 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
Service
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
BEST according to PRACTICE ITIL Version 2 & 3, MOF
Service Desk
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
Requirements for a Management System

Objective:
To provide a management system enabling the effective management of all IT Services.
Management responsibility Documentation requirements Competencies, awareness & training
Plan, Do, Check, Act
50

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
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
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 coordination and management of all services.
53
Management Responsibilities (continued)

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
Management Responsibilities (continued)

Furthermore, Senior Management should:
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
Documentation
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
Documentation: Best Practices

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
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 Arrange for training and further education Control effectiveness of qualification and training 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
Section 4: Planning and Implementing SM

Objective
Planning and Implementing IT Service Management using Demings Quality Circle.
Management responsibility Documentation requirements Competencies, awareness & training
ACT [4.4] Continual Improvement PLAN [4.1] Plan Service Management
DO [4.2] Implement Service Management
CHECK [4.3] Monitor, Measure and Review
Plan, Do, Check, Act
59

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
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 organizations 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
Demings Quality Circle PDCA
maturity
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
PDCA in Service Management

Business Requirements
Customer Requirements
Management of Services
Business results
Management Responsibility
Customer satisfaction
Request for new/changed services

Other processes (e.g. business, supplier, customer) Service Desk
PLAN Plan Service Management
New/changed Services
ACT Continual Improvement
DO Implement Service Management
Other processes (e.g. business, supplier, customer) Team and people satisfaction
Other teams (e.g. Security, IT Operations)
CHECK monitor, measure and review
63
Section 4.1: Plan Service Management

Objective "Plan"
To plan the implementation and delivery of service management.
PLAN ACT CHECK DO
64
Planning for Service Management

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
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

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

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

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
Implement Service Management & Provide the Services Objective "Do"

To implement the service management objectives and plan.
PLAN
ACT
CHECK
DO
70
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
Monitoring, Measuring and Reviewing

Objective "Check"
To monitor, measure, and review that the service management objectives and plan are being achieved.
PLAN
ACT
CHECK
DO
72
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
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
Comparison: Characteristics of Assessments and Audits
Third party (external) audit

Costs/effort
Second party (vendor) audit

First party (internal) audit Self-assessment
Objectiveness
75
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
Management Review
Management Reviews should focus on:
Achievements compared to service objectives (e.g. from audit results) Customer satisfaction Resource utilization Trends Certain service discrepancies
77
Continual Improvement
Objective "Act"
To improve the effectiveness and efficiency of service delivery and management.
PLAN
ACT
CHECK
DO
78
Policy
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
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 owners means Organization-wide or cross-process improvements
80
Activities to be carried out

Information shall be recorded and analyzed as a baseline and a benchmark against the providers 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
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
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.
83

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
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
Implementation Plans for New/Changed Services

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
Implementation Plans for new/changed Services

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
PINCS: Involved Parties

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
Reviews at planning new or changed services

During planning new/changed services, the following should be reviewed:
Budget Adjustment of budgeting required?
Increased financial requirements through new 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
Reviews for planning new or changed services

During planning new/changed services the following should be reviewed (continued):
SLAs and other commitments
Changing existing or concluding new SLAs 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
Change Records of Changed Services

All changes to existing services should be documented in relevant change records. Staff training - conducted update training for 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
IT Service Management Processes

(section 6 - 10) [6] Service Delivery Processes
Capacity Management Service Continuity & Availability Management Service Level Management Service Reporting Information Security Management Budgeting & Accounting for IT services
Content of ISO/IEC 20000 Part 2:


Release Management


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
Capacity Management Service Continuity & Availability Management Service Level Management Service Reporting Information Security Management


Release Management


93

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
Code of Practice
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 workarounds provided to Incident Management.
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
Incident Management
Objective:
Resolve incidents as quickly as possible and minimize the adverse impact on business operations.
[6] Service Delivery Processes


Release Management


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
BEST according to PRACTICE ITIL Version 2 & 3
Process
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
BEST according to PRACTICE ITIL Version 2 & 3
Functional Escalation
Co-ordination of support units 2nd Level Support
Service Desk
Detection Yes
3rd Level Support
Request? No 1st Support No Diagnosis No Diagnosis No Resolvable? Yes Resolution Resolvable? Yes Resolution Resolvable? Yes Resolution
Request Fulfillment
Closure
100
Service Requests and Incidents

The 20 GB hard disk of my notebook is too small !
Service Request for a storage upgrade Service Request for a cartridge change or a printer failure Performance Incident Service Request for a password or account reset E-mail service failure
The color printer in room D.2 stopped printing red!
It takes a long time to load our external web sites!
I have forgotten my WikiPassword!
I cannot access my emails!
101
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
Code of Practice
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
Assessment Card Template

Section Sub Section Requirem ent of ISO20000 8.1 Incident Managem ent 8.2 8.2 a b All incidents shall be recorded Procedures shall be adopted to manage the impact of service incidents Procedures shall define the recording, prioritization, 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 advance if their service levels cannot be met and an action agreed All staff involved in incident management shall have access to relevant information such as know n errors, problem resolutions and the configuration management database Major incidents shall be classified and managed according to a defined process
8.2
8.2
8.2
8.2
104
Problem Management
Objective:
To avoid disruption by proactive and reactive analysis of the cause of potential incidents.



Release Management


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
BEST PRACTICE
Process
according to ITIL Version 2
Sub-processes within reactive problem management

Problem control Error control
Problem
Known Error
Request for Change
unknown cause Problem Control
known cause Error Control Change Management
Problem Management
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
Trend Analysis
Definition: Analysis of data of various sources to identify timerelated 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
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
Problem resolution shall be monitored, reviewed and reported on for effectiveness. Problem management shall be responsible for ensuring up-todate 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
Code of Practice
Communication
All processes and people involved in service support particularly incident management should be informed of:
Work-arounds Permanent fixes Progress of problems
112
Example: From Problem to Change

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

Sub Se ction 8.3 Proble m Manage m e nt Se ction 8.3 8.3 a b Re quire m e nt of ISO20000
All identif ied problems shall be recorded Procedures shall be adopted to identif y, minimize or avoid the impact of incidents and problems. Procedures shall def ine the recording, classif ication, updating, escalation, resolution and closure of all problems Preventive action w ill be taken to reduce potential problems, eg. Follow ing trend analysis of incident volumes and types Changes required in order to correct the underlying cause of problems shall be passed to change management process Problem resolution shall be monitored, review ed and reported on f or ef f ectiveness Problem management shall be responsible f or ensuring upto-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 be recorded and input into the service improvement plan
8.3
8.3
8.3 8.3
e f
8.3
8.3
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
Section 9: Control Processes

Objective: To manage configuration information and changes effectively. [6] Service Delivery Processes
Capacity Management Service Level Management Service Reporting Information Security Management
Service Continuity & Availability Management


Release Management


116

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
Configuration Management
Objective:
To define and control the components of the service and infrastructure and maintain accurate configuration information. [6] Service Delivery Processes


Release Management


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 CIs relationships with other CIs
119
Fundamental terms
BEST PRACTICE according to 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 CMDBs Federated CMDB manages relationships with other CIs and related incidents, problems, known errors, changes, etc.
120
Process
BEST PRACTICE
according to 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 CIs, name conventions, versioning Recording and Control: record new CIs update existing CIs Status Accounting - record/update lifecycle status of each CI Verification - mapping CMDB and actual situation
121
BEST PRACTICE
Process
Planning
Targets, Scope Types of CIs, Baselines, Name conventions
Identification New CIs, changed CIs
Recording and Control
Status Accounting
Update CI Status
Difference between CMDB and reality
Verification
CMDB
122
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
Configuration management shall provide the mechanisms for identifying, recording, controlling and tracking versions of CIs. 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
A baseline of the appropriate configuration items shall be taken before a release to the live environment. Master copies of digital CIs (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
Configuration Management: Best Practices

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 CIs should be defined by relevant and auditable. Attributes, relationships and dependencies between CIs should be identified. CIs 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

9.1 Se r vice As s e t and Configur ation M anage m e nt 9.1 9.1 9.1 a b c There shall be an integrated approach to change and conf iguration management planning The service provider shall def ine the interf ace to f inancial asset and accounting processes There shall be a policy on w hat is def ined as a 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 documentation necessary f or ef f ective service management Conf iguration management shall provide the mechanisms f or 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 business needs, risk of f ailure and service criticality Conf iguration management shall provide inf ormation to the 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 auditable w here appropriate, eg. For changes and movements of sof tw are and hardw are Conf iguration control procedures shall ensure that integrity of systems, services and service components are maintained A baseline of the appropriate conf iguration items shall be taken bef ore a release to the live environment
9.1
9.1 9.1
e f
9.1
9.1
9.1 9.1
i j
127
Excursus: Service Knowledge Mgmt. according to ITIL

BEST PRACTICE according to 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:
CMDBs CMS
128
Change Management
Objective:
To ensure all changes are assessed, approved, implemented and reviewed in a controlled manner. [6] Service Delivery Processes


Release Management


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
Fundamental terms
BEST PRACTICE according to 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
Process
BEST PRACTICE
according to ITIL Version 2 & 3, MOF
Activities:
Records all RfCs 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
Process
BEST according to PRACTICE ITIL Version 2 & 3, MOF
RfC Change Management
Record accepted? Review & Filter Classification authorized? Authorization Yes
No
RfC rejected
No
Change rejected
Yes
Release Management
Coordination
Assess (PIR)
133
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
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
Code of Practice
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

Sub Se ction 9.2 Change M anage m e nt Se ction 9.2 9.2 a b c Re quir e m e nt of ISO20000 Service and inf rastructure changes shall have a clearly def ined and documented scope A ll requests f or change shall be recorded and classif ied. E g. Urgent, emergency, major, minor Requests f or changes shall be assessed f or their risk, impact and business benef it. The change management process shall include the manner in w hich the change shall be reversed or remedied if unsuccessf ul Changes shall be approved and then checked, and shall be implemented in a controlled manner. A ll changes shall be review ed f or success and any actions af ter implementation There shall be policies and procedures to control the authorization and implementation of emergency changes The scheduled implementation dates of changes shall be used as the basis f or change and release scheduling A schedule that contains the details of all changes approved f or implementation and their proposed implementation dates shall be maintained and communicated to relevant parties Change records shall be analyzed regularly to detect increasing levels of changes, f requently recurring types, emerging trends and other relevant inf ormation. The results and conclusions draw n f rom change analysis shall be recorded A ctions f or improvement identif ied during this process shall be recorded and input into the service improvement plan
9.2
9.2 9.2 9.2 9.2 9.2
d e f g h
9.2
9.2 9.2
j k
9.2
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


Release Management


138

Objectives and requirements within release management (3.2.7) Best Practices within release management (4.2.5)
139
Fundamental terms
Release
A collection of new or changed CIs 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
BEST PRACTICE
Process
according to 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
Process
BEST PRACTICE
according to 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
Exemplary Workflow
BEST PRACTICE according to MOF
Record
Review & filter Change Management Classification Authorization
approved Change approved Change approved Change
Release planning Release building Release Management Acceptance test Readiness Review Roll-out Planning Roll-out preparation
Asses (PIR)
Roll-out
143
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
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
Code of Practice
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
Code of Practice
Release and Roll-out Plan
Objective of Release Planning:
Compatible with CIs 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
Example: From Change to Release

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

Category (risk): Minor Change
148

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

Service delivery processes handle long-term service planning and management of service delivery requirements. [6] Service Delivery Processes
Capacity Management Service Continuity & Availability Management
Service Level Management Service Reporting Information Security Management


Release Management


150

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
Service Level Management

Objective:
To define, agree, record and manage levels of service.



Release Management


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
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
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
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 (SLAs). SLAs, together with supporting service agreements, supplier contracts and corresponding procedures, shall be agreed to by all relevant parties and recorded. The SLAs shall be under the control of the change management process. The SLAs shall be maintained by regular reviews. Service levels shall be monitored and reported as compared to targets.
156
Service Level Management: Best Practices

A service catalogue defining all services should be up-to-date and easily accessible for both customers and support staff. SLAs 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 customers 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

6.1 Service Level Managem ent The full range of services to be provided together w ith the corresponding service level targets and w orkload characteristics shall be agreed by the parties and recorded. Each service provided shall be defined, agreed and documented in one or more service level agreements SLA's, together w ith supporting service agreements, third party contracts and corresponding procedures, shall be agreed by all relevant parties and recorded The SLA's shall be under Change Control The SLA's shall be maintained by regular review s by the parties to ensure that they are up to date and remain effective over time Service levels shall be monitored and reported against targets, show ing both current and trend information. The reasons for non-conformance shall be reported and review ed and shall provide input to service improvement plan
6.1
6.1
6.1
6.1
6.1
6.1
158
Service Reporting
Objective:
To produce agreed, timely, reliable and accurate reports for informed decision making and effective communication. [6] Service Delivery Processes


Release Management


159
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

Se ction Sub Se ction Re quire m e nt of ISO20000 6.2 Se rvice Re porting 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 identif ied needs and customer requirements. Service reporting shall include: perf ormance against service level targets Service reporting shall include: non-compliance and issues, eg. Against the SLA, security breach Service reporting shall include: w orkload characteristics, eg. Volume, resource utilization Service reporting shall include: perf ormance reporting f ollow ing major events eg. Major incidents and changes Service reporting shall include: trend inf ormation Service reporting shall include: satisf action analysis Management decisions and corrective actions shall take into considerations the f indings in service reports and shall be communicated to relevant parties
6.2
Para-1 Para-2
6.2 6.2 6.2 6.2 6.2 6.2
a b c d e f
6.2
Para-3
161
Event Management
BEST PRACTICE according to 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
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


Release Management


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
Average Availability
165
BEST PRACTICE
Process
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
Process
BEST PRACTICE
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
Process
BEST PRACTICE according to ITIL Version 2 & 3
Common Activities
Component Failure Impact Analysis (CFIA) Analyze IT infrastructure dependencies Identification of Single Point of Failures (SPOFs) Business Impact Analysis (BIA) Analyze dependencies between services and business processes Quantification of business impact of service failure Risk Analysis Assets Vulnerabilities Assets Vulnerabilities Risk Threats
Countermeasure
Threats
168
Availability and service continuity requirements shall be identified on the basis of business priority, SLAs 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
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

Se ction Sub Se ction Re quir e m e nt of ISO20000 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 assessments. Requirements shall include access rights and response times as w ell as end to end availability of system components A vailability and service continuity plans shall be developed and review ed at least annually to ensure that requirements 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 agreed changes required by the business The change management process shall assess the impact of any change on the availability and service continuity plan A vailability shall be measured and recorded unplanned no-availability shall be investigated and appropriate actions taken. Where possible, potential issues should be predicted and preventive action taken Service continuity plan, contact lists and the conf iguration management database shall be available w hen normal of f ice access is prevented. The service continuity plan shall be tested in accordance w ith business needs A ll continuity tests shall be recorded and test f ailures shall be f ormulated into action plans
6.3
6.3
6.3
6.3 6.3 6.3 6.3
d e f g
6.3 6.3 6.3
h i j
171
Service Continuity and Availability Management: Best Practices

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
Budgeting & Accounting for IT services Objective:

To budget and account for the cost of service provision.


Release Management


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
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
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
Budgeting and Accounting for IT Services: Best Practices

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
Charging
BEST PRACTICE according to 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

Sub Section Section Requirem ent of ISO20000 6.4 Budgeting and Accounting for IT Services There shall be clear policies and procedures for budgeting, and accounting for all components including IT assets, shared resources, overheads, third party supplied service, people, insurance and licenses There shall be clear policies and procedures for apportioning and allocating all indirect costs to relevant services There shall be clear policies and procedures for effective financial control and authorization Costs shall be budgeted in sufficient detail to enable effective financial control and decision making The service provider shall monitor and report costs against the budget, review the financial forecasts and manage costs accordingly Changes to services shall be costed and approved through the change management process
6.4
6.4 6.4 6.4
b c Para-1
6.4
Para-2
6.4
Para-3
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 customers business needs. [6] Service Delivery Processes


Release Management


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
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
Capacity Management: Best Practices

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 SLAs and should be produced at a suitable frequency (at least annually). Current and projected capabilities of the technical infrastructure should be well understood.
183

Section Sub Section Requirem ent of ISO20000 6.5 Capacity Managem ent Capacity management shall produce and maintain a capacity plan, w hich shall address the business needs Capacity plan shall include current and predicted capacity and performance requirements Capacity plan shall include identified time-scales, thresholds and costs for service upgrades Capacity plan shall include evaluation of effects of anticipated service upgrades, requests for change, new technologies and techniques on capacity Capacity plan shall include predicted impact of external changes, eg. Legislative. Capacity plan shall include 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
6.5 6.5 6.5
Para-1 a b
6.5 6.5 6.5
c d e
6.5
Para-2
184
Information Security Management

Objective:
To manage information security effectively within all service activities.
Capacity Management Service Continuity & Availability Management Service Level Management Service Reporting Information Security Management Budgeting & Accounting for IT services


Release Management


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
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
Information Security Management: Best Practices

Service providera should maintain an inventory of the information 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
Information Security Management: Best Practices in Risk Assessment

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

Se ction Sub Se ction Re quir e m e nt of ISO20000 6.6 Infor m ation Se cur ity M anage m e nt Management w ith appropriate authority shall approve an inf ormation security policy that shall be communicated to all relevant personnel and customers w herever appropriate A ppropriate security controls shall operate to implement the requirements of the inf ormation security policy A ppropriate security controls shall operate to manage risks associated w ith access to the service or systems Security controls shall be documented. The documentation 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 bef ore changes are implemented A rrangements that involve third party access to inf ormation 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 w ith the incident management procedure as soon as possible P rocedures shall be in place to ensure that all security 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 quantif ied and monitored, and to provide input to the service improvement plan
6.6
P ara-1
6.6 6.6
a b
6.6
P ara-2
6.6
P ara-2
6.6
P ara-3
6.6 6.6
P ara-4 P ara-5
6.6
P ara-6
190
Section 7: Relationship Processes

Relationship processes describe the two related aspects of Supplier Management and Business Relationship Management.



Release Management


191

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
Tasks and Scope

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 Management
Business Relationship Management
Supplier
Service Provider
Business
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


Release Management


194
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 SLAs shall
follow from these meetings as appropriate and shall be

subject to the change management process.
195
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

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


Release Management


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 Subcontracted Supplier 4 Lead Supplier 3 Service Provider (internal or thirdparty) Business
199
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 SLAs. SLAs with suppliers shall be aligned with the SLAs 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
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 SLAs 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

Se ction Sub Se ction Re quire m e nt of ISO20000 7.2 Supplie r M anage m e nt The service provider shall have documented supplier management processes and shall name a contract manager responsible f or each supplier The requirements, scope, level of service and communication processes to be provided by the supplier(s) 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 business The interf aces betw een processes used by each party shall be documented and agreed All roles and relationships betw een lead and subcontracted suppliers shall be clearly documented. Lead suppliers shall be able to demonstrate processes to 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 that business needs and contractual obligations are still being met. Changes to the contract(s), if present, and SLA(s) shall 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 disputes
7.3
7.3
7.3 7.3 7.3
c d e
7.3
7.3
7.3 7.3
h i
202
Classification and Perspective

Certification Related practices and standards ISO/IEC 20000 Qualification Program
203

Certification outline (2.2.3)
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
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
Scoping Pictorial Depiction
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 RCBs, which are registered with the National Accreditation Body.
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
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
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
ISO 20000 Implementation Roadmap

Planning Phase GAP Analysis Phase Process Definition & Documentation Phase Implementation Phase Pre Certification Internal Audit Phase Final Certification Phase
Initial Roadmap
GAP Analysis
Process Training and Implementation Enablement
Internal Audit Team Training
Communication Plan
Report Presentation
Documentation of Processes
Coordination with RCB
Gap Analysis Plan
Documentation on Planning
Implementation Facilitation
Internal Audit
212

213

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
Related Standards - Overview

ISO 9000 Six Sigma BS 15000 ISO/IEC 27000
ISO/IEC 20000
ITIL V2
ITIL V3
Legende
(from CobiT V4)
MOF
Quality Management standard/methodology IT Management Framework CMMI Software Engineering maturity degree model
Adoption of concepts
CobiT
CMM
ISO/IEC 15504
predecessor
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
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
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
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 CDs 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
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 B u s i n e s s Infrastructure Management
Business Perspective
Service Support Service Delivery
Application Management
Suppliers
Security Management
T e c h n o l o g y
220
ITIL Version 3
Service lifecycle-oriented approach
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
Mapping Deming Cycle to the Service Lifecycle

Plan:
Service Strategy Service Design
Do:
Service Transiton Service Operation
Check and Act:

Continual Service Improvement
223
What is (not) ITIL?

Definition of IT processes:
Objectives Activities In-/Outputs Interfaces within
What is covered by ITIL: What is not covered by ITIL:

Certifiable standard
Cp. ISO/IEC 20000
Resilient set of minimum requirements
Recommendations for process implementation:

requirements (e.g. staff skills) supporting concepts required functions risks
Software, tools
Formal models and templates for: processes relations information artifacts
Evaluation hints:
Critical success factors Key performance indicators
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
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
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
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
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
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
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
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
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
CobiT: Framework
34 processes, structured in four lifecycle domains For each process:
High-Level Control Objective Detailed Control Objectives Management Guidelines Maturity Model
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

236
analyze, assess, create
ISO/IEC 20000 Qualification Program
apply & analyze

Associate Consultant/Auditor
remember & understand
237
Professional Level Modules

Support of IT Services Control of IT Services Management and Improvement of ITSM Processes Requirements for a Management System section 3 Planning and Implementing Service Management section 4 Alignment of IT and the Business Delivery of IT Services
Incident Manage ment section 8.2 Problem Manage ment section 8.3
Planning & Implementing New or Changed Services section 5 Configuration Management section 9.1 Change Management section 9.2 Release Management section 10
Business Relationship Management section 7.2 Service Level Management section 6.1 Service Reporting section 6.2 Supplier Management section 7.3 Budgeting and Accounting for IT Services section 6.4
Service Continuity & Availability Management section 6.3 Capacity Management section 6.5 Information Security Management section 6.6
Case Study
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 7BLUESs 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. 3. Expanding their service portfolio into other Desktop related services that will appeal to their existing customers. Introducing a web-site offering membership applications and other cloud based Services.
238
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
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
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
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
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 organizations 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
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
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
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 with Leibniz-Rechenzentrum. Responsible authors: Dr. Michael Brenner, Thomas Schaaf Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften Boltzmannstrae 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.

ITSM Foundation Course Material

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ITSM Foundation Course Material

Uploaded by

Copyright:

Available Formats

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

Welcome & Administration

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

Content of ISO/IEC 20000, section 6-10 IT

Service Management Processes:

Classification and Preview

ISO/IEC 20000 Qualification Program

Goal of this slide set

Notations used in this slide set:

A best practice, but no ISO/IEC 20000 requirement or recommendation

Introduction to IT Service Management

Check all IT Service Management Trainings conducted by Simplilearn.com

Learning target of this section

Motivation of Process Orientation

Causes of service failure

Need for Management of IT Processes!

What is ISO/IEC 20000?

History: from BS 15000 to ISO/IEC 20000

1995, 1998: Code of practice (non-certifiable)

2000: First release of the standard

2002, 2003: Second release

2004: Adoption in other countries

ISO/IEC 20000: Development and Parts

Context of ISO/IEC 20000

SHALL/MUST-HAVEs Minimum Requirements Check lists

SHOULD-HAVEs Enhancement of Part 1 Recommendations

Related Standards Overview

(since CobiT V4)

IT Management Framework Software Engineering CMMI

Basic Principles and Concepts

Service Process Management Process Assessment Quality and Quality Management

Example Business Process Workflow

Managements Process Orientation

Process Assessment Critical Success Factors

Key Performance Indicators

Metrics reflect the degree of target achievement

What is a Service? Definition according to ITIL Version 3 (goaloriented)

Model-based Definition (technology-oriented)

A Possible Service Model

ITSM: Basic Relationships

ITSM Best Practice

Process-oriented ITSM: Objectives and Benefit

Process-oriented ITSM: Risks

Roles in Process Management

A fool with a tool is still a fool!

Relationship between IT Services and Quality

Providing constant quality is crucial to perception.

Principles of Quality Management

What is a Quality Management System?

QUALITY MANAGEMENT SYSTEM

Objective of a Quality Management System

Right People Competent, aware and trained

Right Documents that are managed

Senior Management Buy-In

Requirements for a Management System (Sec 3)

Steps to Establish a Quality Management System

Summary ISO/IEC 20000

Consists of two parts:

Basic Structure ISO/IEC 20000

[9] Control Processes

Budgeting & Accounting for IT services