Sie sind auf Seite 1von 84

ITIL Essentials for IT Service Management

The Philosophy of Service Management

IT is the business And The business is IT

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

Department Z

Input Process

Output

Deming Quality Circle


Continuous Maturity

Step by step
improvement

Act Plan

Check Do

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 (CCTAs) Reference Model


Service Support
Problem Management Incident Management

IT Customer Relationship Management

Release Management Change Management Configuration Management

Service Level Management Financial Management for IT Services

Capacity Management IT Service Continuity Management Availability Management Service Desk

Service Delivery
Security Management

ITIL Certification Program


Service Mgt. 2 Service Delivery

Case Studies
Service Support

Service Mgt. 1

ITIL Practitioners :
-Configuration Management -Service Desk -Problem Management -Change Management -Capacity Management -Availability Management -Financial Management For IT Services -Service Level management

+ Exam

ITIL Foundation (3-day Course)

ITIL in a Nutshell (1)


Bridge

IT

Business

GAP
9

ITIL in a Nutshell (2)


Bridge =SLM Bridge =SLM

Supplier UCS

IT
OLAs

Business
SLAs

GAP

GAP
10

ITIL in a Nutshell (3)


Bridge =SLM $ Pricing Bridge =SLM Service

Supplier UCS

IT
OLAs

Business
SLAs

GAP Service Service

GAP $ Charging
11

ITIL in a Nutshell (4)


Bridge =SLM $ Pricing Bridge =SLM Service

Profit
Supplier UCS

IT
OLAs

Business
SLAs

GAP Service Service

GAP $ Charging
12

ITIL in a Nutshell (5)


Bridge =SLM $ Pricing Bridge =SLM Service Service

Profit
Supplier UCS

IT
OLAs

Business
SLAs

Suppliers

GAP Service Service

GAP $ Charging

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(=CIs) Relationships of the CIs

14

Configuration Item (CI)


A Configuration Item is:
needed to deliver service uniquely identifiable

subject to change
Can be managed

15

Assets versus Configuration Items


Asset
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 CIs NOTE:

A CMDB contains RELATIONSHIPS BETWEEN CIs , DOCUMENTATION and goes much further than an Asset DB Tool
16

Configuration management Process

Planning Identification/ verification Register & Recoding of CIs Status Accounting Controlling & Updating Auditing

Configuration Items =(CIs)


Services
Environment HW/ SW

Detail (Attributes)

CMDB
Scope

Documentation Procedures Processes

Contracts SLAs, OLAs UCs


WI (= Work Instructions) Manuals Relationships between CIs Baseline Models 17

(Category)

How to Determine IMPACT of Incidents through the Relationships between the CIs

DB
Virus Scanners

Backup os

Security
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

Status of CIs

Detail of the CMDB

Life Cycle of a CI
Scope of the CMDB
20

Goals of Incident Management


To restore the normal service operation(s) as quickly as
possible according to the agreed SLAs

Minimize the impact on business operations

Ensuring that the best possible levels of service quality


Managing Incidents and Service Requests from

and availability are maintained according to the existing SLAs 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

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

Terminology

Incident Management (=IM) Process


Incident/ SRQ

Incident Management Service Desk =SPOC


Incident Detection and recording Classification of Incident(s) & Service Request(s) - Impact - Urgency * High * Medium * Low Knowledge out of Configuration Management

Users

Prioritization

CMDB

Categorization
- Hardware - Software 24

Service Requests are dealt within SRQ procedures Matching of Incidents


Outstanding Incidents DB K.E. / Workarounds DB Problem DB

Knowledge out of Problem Management

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 again, which are related to errors

To prevent repeated Incidents from happening


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)


Escalation of Incidents

Service
Desk

Problem Management

Recording Escalated Incident(s) Assign Resources

Establish Workaround first Problem Record through PM Sub-Processes


28

Sub-Processes Problem Management (2)

1
Problem Control

Escalation Problem Record

2
Error Control

Escalation Known Error Record

Identification and registration Classification Assigning Resources Investigation and Diagnosis Establish Known Error

Error Identification and Recording

Error Assessment

Recording Error Resolution (RFC)

RFC

Successful completion

Error (Record) Closure

29

From Reactive Proactive Problem Management Prevention of problems


on/ in IT- Infrastructure

Monitor Change Management 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 CIs or baseline CIs 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) Small Business impact on the Services. The Change Manager is entitled to authorize this RFC Medium Business Impact on the services. The RFC must be discussed in the CAB. The Change Manager requests advice on authorization and planning Large Business Impact on the services. Management is involved in the decision process
33

Category 1

Category 2

Category 3

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

Project

Entering Change Management Process

Change Manager does Registration & Classification of RFCs

RFCs

Verification

Planning & Controlling the Project

Approval /Refusal by CAB (Change Advisory Board)

Built Phase

Roll Out Back-Out Implementation Authorization /Refusal for Implementation by the Change Manager

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)

Release Manager

Change Manager (Chair Man)

Service Level Manager

A
A A

R 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 changed in the CMDB, secured & traceable

39

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
One or More Physical File Storages

Components for Changes

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 SLAs

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. CIs Where CIs are not supported by the Internal IT Organization, then there must be appropriate underpinning contracts with suppliers

Request for Changes 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 SLAs & OLAs 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 Life-Cycle

T Unavailable=Downtime A M iv T a m i T B e l R F a b = l S A e e v = U r a p v it ili m c a e
49

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

CRAMM= CCTAs Risk Analysis Management Methodology

Threats Value of Assets

Vulnerabilities

Risk Analysis
Risk Management

Managing an Outage Counter Measures Planning for potential 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)
X 100%

AST
51

Availability Formula
In Series
Network Printer Print Server

In Parallel
Avail = 90%
Disk Y

Avail = 90%

Avail = 80%

Disk Z

Avail = 80% Available = 1 - Not Available = 1 - both down = 1 - (Y Down) x (Z Down) =

Available only if both work = AxB = 0.90 * 0.80 = 0.72 or 72%

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 S c s A e u r ic i n u t e r y

54

Security Definitions (1) CIA

C A I E P S o v n r a n n a t o f s f i e t e u i l g e g r d a r c u i e b i t a n n i t i r g

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

57

Information Security Model (ISM)


Information Security Policy Risk Analysis External Influence Business Drives Planning Operational Measures

Evaluation & Audit


58

BS 7799 & ISO/IEC 17799


The Code of Practice for Information Security Management
The 10 Control areas defined within ISO/IEC 17799 (British Standard BS 7799

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

1. 2. 3. 4. 5. Risk Assessment Reports Security Breaches with details of:
type of Breaches How caused Counter-measures in place (and why failed) Actions taken, and to what effect Recommendations for action to avoid repetition

1. 2. 3.

Recommendations for Changes to:


policy Procedures Standards

Recommendations for new guidelines


63

IT Service Continuity Management

Reduce Time of

Recovery

Reduce Costs

Survival
64

ITSCM Process (1)


Initiation
Initiate Continuity MGT Business Impact Analysis

Requirements and Strategy

Risk Assessment Business Continuity Strategy Organization and Implementation Planning

Implementation

Implement Stand-by Arrangements

Develop Recovery Plans Develop Procedures Initial Testing

Implement Risk Reduction Measures

65

ITSCM Process (2) (=Operational)

Testing

Review & Audit

Change Management

Education & Awareness

Training

Assurance
66

CRAMM= CCTAs Risk Analysis Management Methodology (=based on Business Impact)

Threats Value of Assets


Vulnerabilities

Risk Analysis

Risk Management

Managing a Disaster Counter Measures Planning for potential 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


Charges

Business IT Requirements

IT Operational Plan (Incl. Budgets) Financial Targets

Cost Analysis (IT Accounting)


Cost Models
Charging Policies

Charges

Charges

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) they spent on IT Services and influence customer behavior by advising them how to spend their IT Funds

Ensure that customers are aware of the costs

Make formal evaluations of IT services and

plan for investments, based on cost recovery and business benefits


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

More flexible and more responsiveness in IT services

Balance customer demands against cost of services


Measurable service levels (SMART=Specific,
Step)

Measurable, Achievable, Realistic, & Time Bound)

Quality improvement (continuous review & Step by


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 developments in that Service(s)
77

The Service Level Management Process


1
ESTABLISH FUNCTION

2
IMPLEMENT SLAs

Define Execute Control

4
PERIODIC REVIEW MANAGE THE ONGOING PROCESS

78

Contracts:

I OLAs C I O S U n u T L e C t s A r p e t O v s p r o r s i l n a m g c i l e a r n I iC T z a (

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 SIPs can run simultaneously


81

Elements of a Service Level Agreement


General Introduction
Parties Signatures Service Description(s)

Support Service Hours Support Change Procedures Escalation

Reporting & reviewing


Content Frequencies

Incentives & Penalties

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

82

Exam Preparation

83

BREAK A LEG!!!!!!!

84

Das könnte Ihnen auch gefallen