Itil Foundation Presentation

ITIL Essentials for IT Service Management

1

The Philosophy of Service Management

IT is the business And The business is IT

2

Triple P To let the philosophy work, we need:

• People – Customers, Users, IT Staff & Top -Management • Processes – ITIL • Products – Tools and IT technology 3

IT Process

Decision Making Level: ITIL definition (s)

Objective

Result Activities

Operational Level

Department X

Department Y

Input

Department Z

Output Process

4

Deming Quality Circle

Maturity

Continuous Step by step improvement

Act Plan Check Do ty

li a Qu

Plan (Project Plan) Do (Project) Check (Audit) Act (New actions)

Time Scale 5

The Objective of Service Management • Align IT services in such a way that

they will always meet the business/ organization needs which will change in time • Quality Improvement of the IT services Provided • Reduce long-term costs of the IT services provided Service Management: is the delivery of customer-focused IT services, by using a process-oriented approach/ Method 6

ITIL (CCTA’s) Reference Model

IT Customer Relationship Management

Release Management Change Management Configuration Management

Service Level Management Financial Management for IT Services

Service Delivery

Service Support Problem Management Incident Management

Capacity Management IT Service Continuity Management

Service Desk

Availability Management

Security Management

7

ITIL Certification Program Serv ic e

Service Delivery

Mg t. 2

Service Mgt. 1

Service Support

Case Studies

ITIL Pr act itio ner s : -Configuration Management -Service Desk

+ Exam

-Problem Management -Change Management -Capacity Management -Availability Management -Financial Management For IT Services -Service Level management

IT IL Fou nd ati on (3 -d ay Cour se) 8

ITIL in a Nutshell (1) Bridge

IT

Business

GAP 9

ITIL in a Nutshell (2) Bridge =SLM

Supplier UC’S

GAP

Bridge =SLM

IT

Business

OLA’s

SLA’s

GAP 10

ITIL in a Nutshell (3) Bridge =SLM $ Pricing

Supplier UC’S

GAP Service Service

Bridge =SLM Service

IT

Business

OLA’s

SLA’s

GAP $ Charging 11

ITIL in a Nutshell (4) Bridge =SLM $ Pricing

Bridge =SLM Service

$

Profit Supplier UC’S

GAP Service Service

IT

Business

OLA’s

SLA’s

GAP $ Charging 12

ITIL in a Nutshell (5) Bridge =SLM $ Pricing

Bridge =SLM Service

Service

Profit Supplier UC’S

GAP Service Service

IT

Business

OLA’s

SLA’s

GAP $ Charging

Suppliers

Pricing

$ 13

 Goals of Configuration Management • Is to Provide information on the total IT

•

Infrastructure for: – ITIL processes – (IT) Management Keep in control of the IT infrastructure by monitoring, maintaining and updating information on: – All the resources needed to deliver services – Status and history of the Configuration Items(=CI’s) – Relationships of the CI’s 14

Configuration Item (CI) •A Configuration Item is: – needed to deliver service – uniquely identifiable – subject to change – Can be managed

15

• Asset •

•

Assets versus Configuration Items

– Element/ part of a business/ Organization process Configuration Item (CI) – Element/ part of an IT infrastructure - or an item associated with an IT infrastructure which is under the control of Configuration Management Configuration Management Database (CMDB) – A database, which contains all relevant details of each CI and details of the important relationships between CI’s NOTE: A CMDB contains RELATIONSHIPS BETWEEN CI’s , DOCUMENTATION and goes much further than an Asset DB 16 Tool

Configuration management Process

Plannin g Identification/ verification Register & Recoding of CI’s Status Accounting Controlling & Updating Auditin g

Configuration Items =(CI’s) Service s Environmen t HW/ SW

Detail (Attributes)

CMDB Scope (Category)

Documentatio n Procedure s Processes

Contract s SLA’s, OLA’s UC’s WI (= Work Instructions) Manuals Relationships between CI’s Baseline Models 17

er w k Po ea br

How to Determine IMPACT of Incidents through the Relationships between the CI’s

DB Virus Scanners

Security

Backup os

18

Baseline • Configuration Baseline – Configuration of a product or system established at a specific moment in time, which captures both the structure and details of the product or system – A snapshot or a position, which is recorded. Although the position may be updated later, the baseline remains unchanged and available as a reference of the original state and as a comparison against the current position 19

Life Cycle of a CI …

…

ir

Re pa

ti o

an ce

en

n w n

Do nt

e M ai

… Ar . ch iv ed

…

In

In

ok

Br

uc

od

st

Pr

Te

In

In

ed

ed

er

rd

O

nn

Detail of the CMDB

Pl a

Status of CI’s

Scope of the CMDB 20

 Goals of Incident Management • To restore the normal service operation(s) as quickly as possible according to the agreed SLA’s

• Minimize the impact on business operations • Ensuring that the best possible levels of service quality and availability are maintained according to the existing SLA’s

• Managing Incidents and Service Request’s from beginning till end and communicate about them till the moment they can be closed

21

Service Desk in an ITIL Environment • A more structured approach to controlling • • • • • • •

incidents Single Point Of Contact (=SPOC) The face of the IT organization Not a process but a functionality in the ITIL Methodology Initiating escalation procedures Reports of different types arrive at the Service Desk (= Service Requests & Incidents) Responsible for supplying first-line support and assistance in daily use of IT Services Local, Centralized & Virtual Service Desk(s)= Structures! 22

Terminology

• Incident Any event / interruption, which is not part of the standard operation of a Service or causes a reduction in the quality of that service • Work-Around Method/ temporary solution of avoiding an Incident, so that the normal standard operation can continue • Service Request Every Incident not being a failure in the IT Infrastructure (=Password redefinition) 23

Incident Management (=IM) Process Incident/ SRQ

Incident Management Service Desk =SPO Incident Detection and recording Classification of Incident(s) & Service Request(s) - Impact - Urgency

Users

C

Prioritization * High * Medium * Low

CMDB

Knowledge out of Configuration Management

Categorization - Hardware - Software

24

Service Requests are dealt within SRQ procedures Matching of Incidents

Outstanding Incidents DB K.E. / Workarounds DB

Knowledge out of Problem Management

Problem DB

Routing Incidents 1st Line-Support 2nd Line-Support 3rd Line-Support

Escalation Inform / Support (vertical escalation)

Service Desk

Knowledge (functional/horizontal escalation)

25

 Goals of Problem Management • To make sure that we minimize the

operational impact of Incidents and Problems, which are caused by errors within the IT Infrastructure

• To prevent repeated Incidents from

happening again, which are related to errors

• To Improve productive use of (IT)

resources, by knowing how to use them (Knowledge DB) 26

Terminology

• Problem – When the root cause (=underlying cause) of one or more incidents is not known • Known Error – A condition that exists after the successful diagnosis of the root cause of an Incident or Incidents, when it is confirmed that a CI is at fault. (We can remove the error by implementing a change) 27

Problem Management Process (1) Service Escalation of Incidents

Desk

Problem Management

Recording Escalated Incident(s) Assign Resources

Establish Workaround first Problem Record through PM SubProcesses 28

Sub-Processes Problem Management (2) Escalation Problem Record

Escalation Known Error Record

1 Problem

Identification and Control registration

Fi ot Ro nd use Ca

Assigning Resources Investigation and Diagnosis

Error Control Identification and Recording

T” ES “B n tio nd Fi Solu

Classification

Error

2

Error Assessment

Recording Error Resolution (RFC)

RFC

Successful completion

Error (Record) Closure Establish Known Error 29

From Reactive  Proactive Problem Management Prevention of

problems on/ in ITInfrastructure

Monitor Change Managemen t Initiating changes: • Fix Incidents • Control RFC Identify trends/ trend analysis Problem identification & diagnosis Delivering (2nd) & 3rd line support 30

 Goals of Change Management To implement changes which are approved and authorized by change management and which are proven efficient & effective, so that they can be implemented with acceptable risk in the existing IT-Infrastructure, or to the new IT Service(s)

31

Terminology • Change The addition of…, the modification of…, or the removal of…, approved and supported CI’s or baseline CI’s • Request for Change Form use to record details of a request for a change to any CI; can be submitted from each single ITIL Process • Forward Schedule of Changes Schedule that contains details of all the Changes authorized for implementation and their proposed implementation dates. It also shows the dependency of each change!!!

32

Impact of a Change • Standard

The change may be executed without contacting the Change Manager (Manual with standard Changes)

• Category 1

Small Business impact on the Services. The Change Manager is entitled to authorize this RFC

• Category 2

Medium Business Impact on the services. The RFC must be discussed in the CAB. The Change Manager requests advice on authorization and planning

• Category 3

Large Business Impact on the services. Management is involved in the decision process 33

Priority of a Change • Urgent Change necessary immediately, approval by CAB/Emergency Committee (CAB/CEC) • High Change needed as soon as possible • Medium Change will solve annoying errors or missing functionalities (can be scheduled) • Low Change leads to minor improvements (which is not contractually necessarily) 34

Change Management Process

Entering Change Managemen t Process

Projec t

Change Manager does Registration & Classification of RFC’s

RFC’s

Verification

Planning & Controlling the Project

Approval /Refusal by CAB (Change Advisory Board)

Roll Out BackOut

Implementa tion

Authorization /Refusal for Implementation by the Change Manager

Built Phase

Test Phase of Roll Back & Project 35

Periodic Audit within Change Management

P.I.R

Audit Carried out by External (independent) Organization 36

The Change Advisory Board (CAB)

Change Manager (Chair Man)

Release Manager

Service Level Manager

A A

R

A

Financial Manager

Incident Manager

Problem Manager

Configuration Manager

User /Dept. Manager

Business Representation

37

Clarification

Change Manager Release Manager

38

 Goals of Release Management • Plan and Manage the rollout of SW & HW • Design and implement efficient & effective procedures • Manage customer expectations during rollout • Agree upon the content and rollout plan for a release • To implement new software & hardware releases into the production environment • Secure all software masters in the definitive software library • Use the configuration management process to ensure that all hardware and licensed software which has been rolled out is 39 changed in the CMDB, secured & traceable

Definitive Software Library (DSL) Protection of all Authorized Software Versions Base for Releases

One or More Physical File Stores

DSL Linked with CMDB

Logical Storage Distribution

40

Definitive Hardware Store (DHS) Protection of Hardware Spares and Components Spares for Recovery

Linked with CMDB

DHS

Components for Changes

One or More Physical File Storages

41

Form of Releases Full, Package And Delta Release

Emergency Release Release Unit

Release policies Release Frequency

Version Numbering

42

 Goals of Capacity Management

To determine the right Capacity, against the right costs and justifiable considerations of IT resources. So that the agreed Service Levels with business are achieved at the right time and at the right moment.

43

Capacity Management Process Demand Management (INPUT)

Business Capacity Management

Service Capacity Management

Resource Capacity Management

Capacity Database (INPUT) Capacity Plan 44

Sizing and Modelling • Application Sizing Determining the hardware capacity required to support new (or adapted) applications, according to the agreed SLA’s

• Modelling – Trend analysis – Simulation modelling – Baseline models

45

 Goals of Availability Management • To predict…, plan for… and manage… the availability of services provided by ensuring that: – All services are sufficient, reliable and proper maintained, incl. CI’s – Where CI’s are not supported by the Internal IT Organization, then there must be appropriate underpinning contracts with suppliers – Request for Change’s must be submitted to prevent future loss of IT service(s)

46

Responsibilities of Availability Management • Optimize availability by monitoring, managing & reporting • Determine availability requirements in business needs • Predicting, planning & designing for expected levels of availability & security • Developing of the Availability Plan • Collecting, analyzing and managing data • Monitoring the availability levels to ensure that SLA’s & OLA’s are met • Continuously step by step improvement of the availability levels

47

Terminology – Availability = MTBF (Mean Time Between Failures= Up Time) – Maintainability = MTTR (Mean Time To Repair =Down Time) – Serviceability = MTTR (Mean Time To Repair =Down Time) – Reliability =MTBSI (Mean Time Between System Incidents) – Resilience (Redundancy) – Security = (Confidentiality, Integrity & Availability)

48

The Unavailability LifeCycle

T Unavailable=Downtime A M v i T a m il T B e a R F b l = e S A = e v U a rp ti v il m e a i

R W I T M e T I s M B t E S o I r = e R e l b c e il i

49

CRAMM= CCTA’s Risk Analysis Management Methodology

Threats Value of Assets

Risk Analysis

Vulnerabilit ies

Risk Management

Counter Measures

Planning for potential Outage

Managing an Outage

50

When Is a Service Available? “IT Service(s) is/ are not available to a customer if the function(s) required during Service Hours at that particular Location can not be used. This does not necessarily means that the agreed SLA conditions are not being met” To calculate the Availability we use the following formula: Availability=

(AST-DT) AST

X 100% 51

Availability Formula In Series

In Parallel Avail = 90%

Network Printer

Disk Y Print Server

Avail = 90%

Avail = 80%

Disk Z

Avail = 80%

Available only if both work =

Available = 1 - Not Available =

AxB =

1 - both down =

0.90 * 0.80 = 0.72 or 72%

1 - (Y Down) x (Z Down) = 1- 0.1 * 0.2 = 0.98 or 98% 52

Security Management

• The Process of managing a appropriate level of security on information and IT Services • Protection of Security in a more structural an organized manner • Managing and Controlling Security procedures

53

Structure of Security Management

S B S I e u L T c s A S u ri i e t n cy e u P

54

Security Definitions (1) CI A

E A C P S I v o n ar a n o s tf e u fti g eril a d u c ri b e n ati n g tri

55

Security Definitions(2) •Risks Analysis (Quantitative Process) & Risk Assessment (Qualitative Process); CRAMM •Security Policy; why security is done •Security Standard; What to do •Security Procedures; How to do IT •BS 7799 (Code of practice for Information Security Management) & ISO/IEC 17799 (Document Developed in the UK initially by the heads of six commercial Organizations, is not a Cookbook for Security) 56

Security Lifecycle

ti

c

e

t

ct D io e n

yut

nsre

isnoi a v d g no/ e Rt n

m cuevr acetr easoit nio

narperl h ae

R C P E D T R I oevr

d

57

Information Security Model (ISM) Information Security Policy Risk Analysis External Influence

Operational Measures

Business Drives

Planning

Evaluation & Audit 58

BS 7799 & ISO/IEC 17799

The 10 Control areas defined within ISO/IEC 17799 (British Standard BS 7799

The Code of Practice for Information Security Management Security Policy Security Organization Asset Classification and Control Personnel Security Physical & environmental Security Communications & Operations Management

Access Control Systems development & Maintenance Business Continuity Management Compliance 59

Security Activities • Assess (Analyze) Risk; Prerequisite to implement any security measures

•Manage Risk reactively; Quick action, Counter-measures •Develop Security Policy; document that is easy to read & assimulate

•Manage Risk Proactively; to modify the security regime to achieve the optimum level of security commensurate with its cost & impact

•Monitor Security; Security must be monitored on an appropriate basis and on regular times

•Report; Periodic and ad hoc reporting is an important aspect of keeping security in the forefront of the organization’s collective mind 60

Benefits • Corporate Management Receive Assurance • Business Continuity is assured • Risk Assessment is “Enforced” • Management attention is focused on Value • Everyone thinks differently about Information

61

Challenges • Expensive and no Benefits • The ‘Ostrich Approach’, or “IT’ll never happen • • •

2me!” You can not protect against all the threats Lack of Senior Management interest “Entropy Rules”; Security degrades over time!, Maintaining security at the agreed level is an imperative

• No ‘Security by Design’; Many ‘Legacy’ applications do not have security embedded in them.

• Locks on grass huts; There is no point securing one aspect of an information system or IT Infrastructure, if the rest is less secure. Similarly, failing in one small area of security is failing overall 62

Reporting • •

Risk Assessment Reports Security Breaches with details of:

3. 4. 5. 6. 7.

type of Breaches How caused Counter-measures in place (and why failed) Actions taken, and to what effect Recommendations for action to avoid repetition

•

Recommendations for Changes to:

9. 10. 11.

policy Procedures Standards

•

Recommendations for new guidelines 63

IT Service Continuity Management

Reduce Time of Recovery

Reduce Costs

Survival 64

ITSCM Process (1) Initiate Continuity MGT

Initiation

Business Impact Analysis

Requirements and Strategy

Risk Assessment Business Continuity Strategy Organization and Implementation Planning

Implementation

Implement Stand-by Arrangements

Implement Develop Risk Reduction Recovery Plans Measures

Develop Procedures Initial Testing

65

ITSCM Process (2) (=Operational)

Testing Review & Audit

Change Manageme nt

Education & Awareness

Training

Assurance 66

CRAMM= CCTA’s Risk Analysis Management Methodology (=based on Business Impact)

Threats Value of Assets

Risk Analysis

Vulnerabiliti es

Risk Management

Counter Measures

Planning for potential Disaster

Managing a Disaster 67

Recovery Options

Cold Standby

Gradual Recovery Warm Standby Intermediate Recovery HOT Standby

Immediate Recovery 68

Roles & Responsibilities in Normal Operation, Change during a Crisis Situation Does everybody know what role to play in a crisis situation Does everybody know what the roles are and to whom they belong during a crisis situation 69

Extensive Testing & Reviewing of the ITSCM Plan • Every 6 to 12 months and after each disaster! • Test it under realistic circumstances! • Move / protect any live services first! • Review and change ITSCM plan! • ALL change through the Change Advisory Board! (=Change Management Process) 70

Financial Management For IT Services Charge s Business IT Requirements

IT Operational Plan (Incl. Budgets) Financial Targets

Cost Analysis (IT Accounting) Cost Models

Charge s Charge s

Charging Policies

Feedback about proposed charges to Business 71

IT- Accounting • Base IT decisions on cost-effective

assessments, in such a way that it is measured service by service

• Provide Management with information to justify IT expenditures & investments to Business

• Plan and budget with confidence and Integrity, so that the ring of trust can not be broken

• Show under- or over-consumption of service(s) in financial terms to Business / Customers

72

Charging

• Customers paying the full costs of the IT services provided in a fair manner (“…what you use is what you pay for……”)

• Ensure that customers are aware of

the costs they spent on IT Services and influence customer behavior by advising them how to spend their IT Funds

• Make formal evaluations of IT

services and plan for investments, based on cost recovery and

73

Charging & Pricing Options Charging • No charging • Notional Charging / Differential Charging • Actual/Real Charging Pricing • Recover of costs • Cost price plus • Going Rate • Market prices • Fixed Price 74

Service Level Management Balance between:

Demand for IT services

&

Supply of IT services

How???: – Know the requirements of the business – Know the capabilities of the IT Organization 75

 Goals of Service Level Management • IT CRM (between customer and IT supplier)

• Better Customer understanding of IT services requirements

• More flexible and more responsiveness in IT services provision

• Balance customer demands against cost of services provision

• Measurable service levels

(SMART=Specific, Measurable, Achievable, Realistic, & Time Bound)

• Quality improvement (continuous review & Step by Step…)

76

Service Management Reports • Everything is measured from the

customers perspective • Data such as “reaction times, escalation times and IT Service support” should be made measurable • Reports should be produced on regular bases, and they should be used • Reports contains measuring values concerning the “NOW” supporting Service levels and the latest trend 77 developments in that Service(s)

Re vie AU w S DI LA TS 's Re vi Pr ew oc SL es M s

4

PERIODIC REVIEW

MANAGE THE ONGOING PROCESS

tio

OL Re A’ ate vie sa w nd ex UC’ s, ist in g SL A’ s Ag re e

Ne go ti

Dr aft

n

2

IMPLEMENT SLA’s

Re vie w

Re po rt

nt a

ESTABLISH FUNCTION

ito r

me

g

1

Mo n

ple

nin

an

Ca Se talog rvi ue ce s

Im

Pl

The Service Level Management Process Define Execute Control

3 78

Contracts:

II OLA’s C O S U n T e u L C t p A re’ s O v p s rt’ o s rli n a m g ci al e I n r T C (i D

79

Service Quality Plan (SQP) • Internal service description of

responsibilities and delivery times to meet the agreed service level(s)

• Must be Focused on IT staff (performance & delivery)

• Describes exactly what we need to do, to deliver the desired quality of service

• Description based on the actions to be take when we do not deliver the correct quality agreed in the service level(s) “Written upfront”

80

Service Improvement Program (SIP) • Objective: – Controlled improvement of the IT Service provided

• Used whenever there is a need in/ for – Deviation from agreed levels – Strategic choice – Continuous Improvement

• More than one SIP’s can run simultaneously

81

Elements of a Service Level Agreement General Introduction • Parties • Signatures • Service Description(s)

Reporting & reviewing • Content • Frequencies

Incentives & Penalties

Support Service Hours Support Change Procedures Escalation

Delivery Availability Reliability Throughput Transaction response times Batch turnaround times Contingency & Security Charging

82

Exam Preparation

83

BREAK A LEG!!!!!!! ITIL S N O I T A D N U O F

e World Wid d Recognize

84