ITSM Foundation Course Material

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

2

Welcome & Administration • • • •

Structure of the training ISO/IEC 20000 certification and course outline Examination format Agenda

3

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

Content of ISO/IEC 20000-1 and ISO/IEC 20000-2

• Content of ISO/IEC 20000, section 1-5 - basics

4

ISO/IEC 20000 Qualification Program

5

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

6

Course Material

Goal of this slide set • Preparation for an ISO/IEC 20000 Foundation Exam according to specifications from EXIN and TÜV SÜD Akademie.

Notations used in this slide set: Blue background Definitions according to ISO/IEC 20000 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

7

Introduction to IT Service Management • Motivation of process-oriented IT Service Management • Background, History • Basic principles

Check all IT Service Management Trainings conducted by Simplilearn.com

8

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

9

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

ISO/IEC 20000-2: Information Technology Service Management – Part 2: Code of Practice

shall Recommendations should

13

Context of ISO/IEC 20000

ISO/IEC 20000-1

ISO/IEC 20000-2

SHALL/MUST-HAVE‟s  Minimum Requirements  Check lists

SHOULD-HAVE‟s  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 ISO/IEC 27000

Six Sigma

ISO/IEC 20000

BS 15000

ITIL® V2

ITIL® V3 Legend

(since CobiT V4)

MOF

Quality Management standard / methodology

CobiT

IT Management Framework Software Engineering

CMM

CMMI

Maturity Degree Model

Adoption of concepts

ISO/IEC 15504

Predecessor

15

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

Management‟s Process Orientation Processes control and impact on … • individuals’ behavior • employment of technology • usage of information/knowledge •  Processes make results of activities predictable •  Process Orientation as a Management Paradigm

Domain 1

Domain 2

Input

Control factors

Activity Output

Control factors

Activity Input

Activity Output

Input

Control factors

Domain 3

Output

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

IT Service

use Management

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 customer’s 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. SLA’s) 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

Senior Management Buy-In

Right Documents that are managed

Requirements for a Management System (Sec 3)

Good communication

34

Steps to Establish a Quality Management System

•

Identify customer’s requirements and expectations.

•

Define and assign required resources to achieve the committed quality goals.

•

Launch procedures to measure effectiveness and efficiency.

35

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

[10] Release Process

Service Level Management Information Security Management Service Reporting

[9] Control Processes Configuration Management Change Management

[8] Resolution Processes Release Management

Incident Management Problem Management

Budgeting & Accounting for IT services

[7] Relationship Processes Business Relationship Management Supplier 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

Management responsibility Documentation requirements Competencies, awareness & training

[4] Planning & Implementing SM

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





40

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

41

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 [1] Scope [2] Terms and Definitions [3] Management System





44

Learning target of this section • 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

Service Desk

BEST according to PRACTICE ITIL® Version 2 & 3, MOF

Service Desk – Objectives • To ensure availability of the IT provider • Single Point of Contact (SPOC) for Users

Tasks • To take over tasks of service support (e.g. particularly within Incident Management Process)

• Communication to users Service Desk is a Core Definition, but not part of the ISO/IEC 20000 requirements.

49

Requirements for a Management System Objective: To provide a management system enabling the effective management of all IT Services.






50

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

51

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 PLAN [4.1] Plan Service Management

Objective • Planning and Implementing IT Service Management using Deming’s Quality Circle.

ACT [4.4] Continual Improvement

DO [4.2] Implement Service Management

CHECK [4.3] Monitor, Measure and Review






59

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

60

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

61

maturity

Deming‟s Quality Circle – PDCA

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

Management of Services Business results

Customer Requirements

Request for new/changed services

Management Responsibility

PLAN Plan Service Management

Customer satisfaction

New/changed Services Other processes (e.g. business, supplier, customer) Service Desk

Other teams (e.g. Security, IT Operations)

ACT Continual Improvement

DO Implement Service Management

CHECK monitor, measure and review

Other processes (e.g. business, supplier, customer) Team and people satisfaction

63

Section 4.1: Plan Service Management Objective "Plan" To plan the implementation and delivery of service management.

PLAN ACT

DO CHECK

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

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

67

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

68

Service Management Plan Events with impact on the Service Management Plan: • • • • • •

Service Improvement Changed Services Changes to the target-state of infrastructure Changed legal/official requirements Regulation or deregulation of branches Mergers and acquisitions

69

Implement Service Management & Provide the Services Objective "Do" To implement the service management objectives and plan.

PLAN

ACT

DO CHECK

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

DO CHECK

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

Costs/effort

Third party (external) audit

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

DO CHECK

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 owner’s 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 provider’s capability in managing services and service management processes. • Identify, plan, and implement improvements. • Consultation with all involved parties. • Set a goal for improvements regarding quality, costs, resources.

81

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. [1] Scope [2] Terms and Definitions [3] Management System





83

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

84

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): • SLA‟s and other commitments Changing existing or concluding new SLA’s required? Other commitments?

• Processes, procedures and documentation Changing existing processes and procedures required (e.g. at support)? Changed services require new documentation or update of existing documents?

• Scope of Service Management New or not yet implemented service management processes required? Service Management Plans update required?

90

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

Content of ISO/IEC 20000 Part 2:

IT Service Management Processes (section 6 - 10) [6] Service Delivery Processes Capacity Management Service Continuity & Availability Management

[10] Release Process Release Management

Service Level Management Service Reporting

Information Security Management


[8] Resolution Processes Incident Management Problem 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





93

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

94

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 Capacity Management Service Continuity & Availability 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

Service Desk

2nd Level Support 3rd Level Support

Detection Yes

Request? No 1st Support

Request Fulfillment

No

No Diagnosis

Diagnosis No

Resolvable? Yes Resolution

Closure



100

Service Requests and Incidents The 20 GB hard disk of my notebook is too small !

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!

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

101

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

a

8.2

b

8.2

c

8.2

d

8.2

8.2

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

e

All staff involved in incident management shall have access to relevant information such as know n errors, problem resolutions and the configuration management database

f

Major incidents shall be classified and managed according to a defined process

104

Problem Management Objective: To avoid disruption by proactive and reactive analysis of the cause of potential incidents.

[6] Service Delivery Processes Capacity Management Service Continuity & Availability 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

Process

BEST PRACTICE

according to ITIL® Version 2

Sub-processes within reactive problem management Problem control Error control

Problem

Known Error

unknown cause

known cause

Problem Control

Error Control

Problem Management

Request for Change

Change 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

Minimum Requirements • •

• •

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

It takes a long time to load our external web sites!

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

RfC Install patch T12-02 for web server on machine pclx3

113

Assessment Card Template Sub Se ction 8.3 Proble m Manage m e nt Se ction

Re quire m e nt of ISO20000

8.3

a

All identif ied problems shall be recorded

8.3

b

Procedures shall be adopted to identif y, minimize or avoid the impact of incidents and problems.

8.3

c

Procedures shall def ine the recording, classif ication, updating, escalation, resolution and closure of all problems

8.3

d

Preventive action w ill be taken to reduce potential problems, eg. Follow ing trend analysis of incident volumes and types

8.3

e

8.3

f

8.3

g

8.3

h

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

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 About the process group Objective: To manage configuration information and changes effectively. [6] Service Delivery Processes Capacity Management

Service Continuity & Availability Management







116

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

117

Configuration Management Objective: To define and control the components of the service and infrastructure and maintain accurate configuration information. [6] Service Delivery Processes Capacity Management Service Continuity & Availability 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 CI’s • relationships with other CI’s

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 CMDB’s  Federated CMDB • manages relationships with other CI’s 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 CI‟s, name conventions, versioning Recording and Control: • record new CI’s • update existing CI’s Status Accounting - record/update lifecycle status of each CI Verification - mapping CMDB and actual situation

121

Process

BEST PRACTICE


Planning

Targets, Scope Types of CI’s, Baselines, Name conventions

Identification

Recording and Control

Status Accounting

Verification

New CI’s, changed CI’s

Update CI Status Difference between CMDB and reality

CMDB

122

Minimum Requirements •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

Minimum Requirements

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

124

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

125

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 CI’s should be defined by relevant and auditable. Attributes, relationships and dependencies between CI’s should be identified. CI’s should be held in a secure and suitable environment. No CI should be added or undergo an uncontrolled status change. Status records should provide current and historical data and be available to all relevant parties. Configuration audits should be carried out regularly.

126

Assessment Card Template 9.1 Se r vice As s e t and Configur ation M anage m e nt 9.1

a

9.1

b

9.1

c

9.1

d

9.1

e

9.1

f

9.1

g

9.1

h

9.1

i

9.1

j

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

127

Excursus: Service Knowledge Mgmt. according to ITIL® BEST PRACTICE


Why Service Knowledge Management? Sole Configuration Management is insufficient to soundly support management decisions. Service Knowledge Management – additional documentation of: • experiences • key findings of former projects • expert knowledge

Service Knowledge Management System (SKMS): A set of tools and databases that are used to manage knowledge and information. The SKMS includes the: • CMDB’s • CMS

128

Change Management Objective: To ensure all changes are assessed, approved, implemented and reviewed in a controlled manner. [6] Service Delivery Processes Capacity Management Service Continuity & Availability 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


according to ITIL® Version 2 & 3, MOF

•Activities: •Records all RfC’s •Review and Filter - decide on RfC acceptance by defined formal criteria •Classification: • Priority (impact, urgency) • Category (Risks)

•Authorize and Plan - release changes for development, budgeting and resource planning •Coordination of change development and change release •Post implementation review (PIR)

132

Process BEST according to PRACTICE ITIL® Version 2 & 3, MOF

RfC Change Management

Record accepted? Review & Filter

authorized?

Coordination

Assess (PIR)

RfC rejected

No

Change rejected

Yes

Classification Authorization

No

Yes Release Management

133

Minimum Requirements •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

Minimum Requirements •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

Assessment Card Template Sub Se ction 9.2 Change M anage m e nt

ISO/IEC 20000 Code of Practice

Se ction

9.2

a

9.2

b

9.2

c

9.2

d

9.2

e

9.2

f

9.2

g

9.2

h

9.2

i

9.2

j

9.2

k

9.2

l

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

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 Capacity Management Service Continuity & Availability Management







138

Learning target of this section 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 CI‟s required to be tested together and deployed to live environment.

Additional terms Definitive Media Library (DML): • Master copies of deployed software (licensed third-party software and proprietary) • Basis for packaging of releases

Definitive Hardware Store (DHS): Physical storage location of approved and registered hardware

140

Process

BEST PRACTICE

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


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

Release planning

Review & filter

approved Change

Release building

Classification

approved Change

Acceptance test

Authorization

approved Change

Readiness Review Roll-out Planning Roll-out preparation

Asses (PIR)

Roll-out

Release Management

Change Management

Record

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

Minimum Requirements • • •

•

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 CI’s in target environment • Ensure that all changes are authorized by Change Management (feedback)

• Release Plan: • Detailed document to plan a concrete release (important: differs from release policy) • The planning for a release and roll-out should typically include (abstract): • release dates • related changes • problems and known errors closed or resolved by this release • known errors that have been identified during testing of the release • the manner in which the release will be reverted or remedied if unsuccessful • detailed description of the required test • communication training (particularly for customer and support staff) • resources required for release

147

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

Release Schedule: Complete until 2008-06-25

Status: Accepted Roll-out Plan Change Install patch T12-02

Priority: Medium (high impact, low urgency) Category (risk): Minor Change

1. Download patch 2. Install in test environment PIR Report 1. Install in operative environment 2. Post Implementation Review

148

Assessment Card Template Sub Se ction 10.1 Re le as e M anage m e nt


Se ction


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 Plans 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 Plans 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. Emergency releases shall be managed according to a def ined process that interf aces the emergency change management process

10.1

a

10.1

b

10.1

c

10.1

d

10.1

e

10.1

f

10.1

g

10.1

h

10.1

i

10.1

j

A controlled acceptance test environment shall be established to build and test all releases prior to distribution

k

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

149

Section 6: Service Delivery Processes About the process group Service delivery processes handle long-term service planning and management of service delivery requirements. [6] Service Delivery Processes Capacity Management Service Continuity & Availability Management







150

Learning target of this section • • • •

• •

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

151

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








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

Internal Organizations

Contracts

Suppliers

Contracts

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

Minimum Requirements •

• • • • •

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

156

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. SLA’s should be defined from a customer perspective. SLM process should be flexible to accommodate major business changes and changing customer requirements. Service provider should be given adequate information in order to understand their customer’s business drivers and requirements. SLM process should encourage both the service provider and the customer to be proactive and take joint responsibility for the service. Customer satisfaction is key but should be recognized as a subjective measurement. Supported services should be documented and agreed upon with each supplier, including internal groups.

157

Assessment Card Template


6.1 Service Level Managem ent

6.1

a

6.1

b

6.1

c

6.1

d

6.1

e

6.1

f

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

158

Service Reporting Objective: To produce agreed, timely, reliable and accurate reports for informed decision making and effective communication. [6] Service Delivery Processes Capacity Management Service Continuity & Availability 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

6.2

Sub Se ction

Para-1 Para-2

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

6.2

a

6.2

b

6.2

c

6.2

d

6.2

e

Service reporting shall include: trend inf ormation

6.2

f

Service reporting shall include: satisf action analysis

6.2

Para-3

Management decisions and corrective actions shall take into considerations the f indings in service reports and shall be communicated to relevant parties

161

Event Management BEST PRACTICE

• • •

•


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 Capacity Management Service Continuity & Availability 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

Process

BEST PRACTICE


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



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



Common Activities Component Failure Impact Analysis (CFIA) •Analyze IT infrastructure dependencies •Identification of Single Point of Failures (SPOF’s) Business Impact Analysis (BIA) •Analyze dependencies between services and business processes •Quantification of business impact of service failure Risk Analysis Assets Vulnerabilities •Assets •Vulnerabilities Risk •Threats Countermeasure

Threats

168


• •

•

Availability and service continuity requirements shall be identified on the basis of business priority, SLA’s and risk assessments. Availability and service continuity plans shall be developed and reviewed at least annually. The availability and service continuity plans shall be re-tested at every major change to the business environment. The change management process shall assess the impact of any change on the availability and service continuity plan.

169


•

• •

•

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

6.3

a

6.3

b

6.3

c

6.3

d

The change management process shall assess the impact of any change on the availability and service continuity plan

6.3

e

A vailability shall be measured and recorded

6.3

f

6.3

g

6.3

h

6.3

i

6.3

j

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

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. [6] Service Delivery Processes Capacity Management Service Continuity & Availability 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


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

6.4

a

6.4

b

6.4

c

6.4

Para-1

6.4

Para-2

6.4

Para-3

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

179

Capacity Management Objective: To ensure that the service provider has, at all times, sufficient capacity to meet the current and future agreed demands of the customer’s business needs. [6] Service Delivery Processes Capacity Management Service Continuity & Availability 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 SLA’s and should be produced at a suitable frequency (at least annually). Current and projected capabilities of the technical infrastructure should be well understood.

183



Section

Sub Section

6.5

Para-1

6.5

a

6.5

b

6.5

c

6.5

d

6.5

e

6.5

Para-2

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

184

Information Security Management Objective: To manage information security effectively within all service activities. [6] Service Delivery Processes Capacity Management Service Continuity & Availability Management


Service Level Management Service Reporting



Information Security Management Budgeting & Accounting for IT services


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

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

Assessment Card Template Se ction

Sub Se ction



6.6 Infor m ation Se cur ity M anage m e nt

6.6

Para-1

6.6

a

6.6

b

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

6.6

Para-2

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

6.6

Para-2

The impact of changes on controls shall be assessed bef ore changes are implemented

Para-3

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

6.6

6.6

Para-4

6.6

Para-5

6.6

Para-6

Security incidents shall be reported and recorded in line w ith the incident management procedure as soon as possible Procedures 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

190

Section 7: Relationship Processes About the process group Relationship processes describe the two related aspects of Supplier Management and Business Relationship Management.








191

Learning target of this section • Objectives and requirements within Business Relationship Management (3.3.4)

• Best Practices within Business Relationship Management (4.3.4) • Objectives and requirements within Supplier Management (3.3.5) • Best Practices within Supplier Management (4.3.5)

192

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.

Business Relationship Management

Supplier 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 Capacity Management Service Continuity & Availability 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 SLA’s 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

7.2

a

7.2

b

7.2

c

7.2

d

7.2

e

7.2

f

7.2

g

7.2

h

7.2

i

7.2

j

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.

197

Supplier Management Objective: To manage suppliers to ensure the provision of seamless, quality services. [6] Service Delivery Processes Capacity Management Service Continuity & Availability 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

Subcontracted Supplier 4

Supplier 2

Service Provider

Lead Supplier 3

(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 SLA’s. SLA’s with suppliers shall be aligned with the SLA’s for the customers. The interfaces between processes used by each party shall be documented and agreed upon. All roles and relationships between lead and subcontracted suppliers shall be clearly documented. Lead suppliers shall be able to demonstrate processes to ensure that subcontracted suppliers meet contractual requirements.

200


A process shall be in place for a major review of the contract: at least annually to ensure that business needs are still being met to ensure that contractual obligations are still being met

•

•

Changes to the contracts, if present, and SLA‟s shall follow from these reviews as appropriate and shall be subject to the change management process. Processes shall exist: to deal with contractual disputes to deal with the expected end of service, early end of the service to deal with transfer of service to another party

•

Performance shall be monitored and reviewed: Compared to service level targets Actions for improvement shall be input for a service improvement plan.

201



Se ction

Sub Se ction

7.3

a

7.3

b

7.3

c

7.3

d

7.3

e

7.3

f

7.3

g

7.3

h

7.3

i

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

202

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

203

Learning target of this section • 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 RCB’s, 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

Initial Roadmap

GAP Analysis

Communication Plan

Gap Analysis Plan

Report Presentation

Documentation on Planning

Process Definition & Documentation Phase

Implementation Phase

Pre Certification Internal Audit Phase

Process Training and Implementation Enablement

Internal Audit Team Training

Documentation of Processes

Final Certification Phase

Coordination with RCB

Implementation Facilitation

Internal Audit

212

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

213

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

214

Related Standards - Overview ISO 9000 ISO/IEC 27000

Six Sigma

ISO/IEC 20000

BS 15000

ITIL® V2

ITIL® V3 Legende

(from CobiT V4)

MOF

Quality Management standard/methodology

CobiT

CMM

IT Management Framework CMMI

Software Engineering maturity degree model Adoption of concepts

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 CD’s published by TSO (The Stationary Office) / book trade • Miscellaneous: ITIL® Version 2 is the most popular ITSM framework Since Summer 2007, fully revised version 3 (ITIL® V3) available

219

® ITIL

Version 2

Content of ITIL® V2 Service Support Book: Operational processes Service Delivery Book: Tactical processes Security Management Book Some additional books

Service Support Service Delivery

Application Management Suppliers

Infrastructure Management

B u s i n e s s

Business Perspective

Planning to implement Service Management

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

What is covered by ITIL®: What is not covered by ITIL®:

• Definition of IT processes:

• Recommendations for process implementation: requirements (e.g. staff skills) supporting concepts required functions risks

• Evaluation hints: Critical success factors Key performance indicators

• Resilient set of minimum requirements

• Software, tools • Formal models and templates for: • processes • relations • information artifacts

Cp. ISO/IEC 20000

Objectives Activities In-/Outputs Interfaces within

Certifiable standard

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

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

236 analyze, assess, create

ISO/IEC 20000 Qualification Program

apply & analyze Associate Consultant/Auditor

remember & understand

237

Professional Level Modules Support of IT Services

•

•

Incident Manage ment section 8.2 Problem Manage ment section 8.3

Control of IT Services

•Planning & Implementing New or Changed Services section 5 •Configuration Management section 9.1 •Change Management section 9.2 •Release Management section 10

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

•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

Delivery of IT Services

•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 7BLUES’s own technicians and outsourced partners. Over the last 1 year they have begun to grow their business on three fronts by: 1. Expanding their customer base, by moving into new areas of operation and by achieving a reputation of providing a quality service 2.

Expanding their service portfolio into other Desktop related services that will appeal to their existing customers.

3.

Introducing a web-site offering membership applications and other cloud based Services.

The services are supplied by a structure based upon a strong Head office, in Bangalore, India, and satellite offices throughout their area of operation. Until recently the local offices, whilst bound to the practices lay down by Head Office, took calls from customers needing assistance in their area and arranged to get help to them. This has been changing over the last 6 months as a new centralized Service Desk has been setup and a new Remote Management Centre has been implemented in the Head Office. Accordingly, the future of the local offices is under review. The number of such offices will certainly be reduced and a revised role for those that remain is not yet certain.

238

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 organization’s overall Business Continuity Management. A Centralized Service Desk has recently been formulated and the customers have been made aware of the 1800-7BLUES-INDIA toll free number. The new Service Support Manager has been slowly increasing the formalization of referring calls to second line and specialist support groups through pre-defined escalation procedures. Formal Change Management procedures exist and an up to date CMS is in place.

It is well realized that 7BLUES are becoming ever more dependent upon the PCSS system for their operational effectiveness - if that fails they can not function. This has perhaps diverted attention from the rest of the IS provision and made those working on enhancing and maintaining the PCSS system into an ‘elite’ who sometimes feel ‘above the rules’. There is a commitment to training and most of the IT Service Management staff has received some ITIL based training.

243

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: [email protected] 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 Boltzmannstraße 1 D-85748 Garching www.lrz.de

Copyright © 2008 EXIN/TUV SuD Akademie All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system or circulated in any form by print, photo print, microfilm or any other means without written permission by EXIN/TUV SuD Akademie.

ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office. IT Infrastructure Library® is a Registered Trade Mark of the Office of Government Commerce.

ITSM Foundation Course Material

Recommend Documents