ITILv3-studynotes

8/18/2019 ITILv3-studynotes

1/55

ITIL v3 Foundation ‐ Study Notes

*********

Read Me

Hi there,

If you’re reading this, you’ve stumbled upon the best study notes you’ll find for ITIL v3. I

wrote these notes, and by studying from them, I scored 90% (I got 4 wrong out of 40 on

the exam). Still not convinced that these notes are awesome!?

Here’s how to use the notes:

1. Order in which you should review the study materials:

a. Exam Tips

b.

Overview (a

mapping

of

the

Processes/Sub

‐processes/Functions)

c. Module 1

d. Module 2

e. Module 3 – SS (Service Strategy)

f. Module 3 – ST (Service Transition)

g. Module 3 – SD (Service Design)

h. Module 3 – SO (Service Operation)

i. Module 3 – CSI (Continual Service Improvement)

j. Overview (a mapping of the Processes/Sub‐processes/Functions)

2.

The first

page

of

every

note

contains

a list

of

constructs

(processes

/ functions

/

etc.) that may be tested on. If you can go through the first page of every

document and answer/define/understand the constructs without looking at the

answers listed on the subsequent pages, you’re ready to move onto the next

document.

3. While these notes are close to a complete study guide, keep in mind that getting

answers wrong on the practice tests is an invaluable exercise which will help you

determine the constructs you still need to figure out. For example, I thought I

knew what a “workaround” was, but I had to get it wrong on the practice exam

to figure out I needed to understand/memorize ITIL’s definition.

Best of luck! And hey, if you need help, don’t hesitate to contact us ([email protected])

regardless of whether you’re taking the course through us. We’ll help!

Your study partner,

B Wyze Solutions (a preferred MindMuze Education Partner)

www.bwyze.mindmuze.com for more details


2/55

ITIL v3 Foundation ‐ Study Notes

*********

Exam Tips

Hi

there,

If you’re reading this, then you’re going to take the ITIL v3 Foundation Exam soon. Here

are some key points to keep in mind:

1. Memorize your definitions. The questions on the exam will provide 2 out of 4

answers that make sense and are very similar when referring to a term, and so if you

don’t have the term memorized, you’ll be stuck. Trust us; 15 questions on the exam

will be just like this.

2. Understanding the interrelationships, jurisdictions, and subtle differences between

the terms,

processes,

sub

‐processes

&

functions

is

just

as

important

as

understanding the constructs themselves. For example:

What is the difference between Availability & Capacity Management?

How does Operational Control differ from Technical Management?

What is the difference between a workaround and a resolution in the

context of Incident Management?

What’s in the Service Catalogue compared to the Service Pipeline compared

to the Service Portfolio?

What’s a Rollout compared to a Deployment?

Any of

the

roles!

What

does

an

Asset

Manager

do

compared

to

a Configuration Manager? Service Owner vs. Process Owner?

Event vs. Alert vs. Incident?

3. When memorizing definitions, you can get stuck in the weeds. Knowing the overall

structure of ITIL v3 will help you organize the information in your mind and help

resolve jurisdiction questions (i.e. who does what?). So create an outline like this

(we’ve started it off for you):

Service Strategy

1.1. Service Portfolio

2.1.

Demand Management

3.1. Financial Management

Service Design

1.1. Change Management

2.1. etc.


3/55

Best of luck! And hey, if you need help, don’t hesitate to contact us ([email protected])

regardless of whether you’re taking the course through us. We’ll help!

Your study partner,


www.bwyze.mindmuze.com for

more

details


4/55

ITIL v3 ‐ Overview

1. Service Strategy

1.1. Service Portfolio

1.2. Demand Management

1.3.

Financial

Management

2. Service Design

2.1. Service Catalogue Management

2.2. Service Level Management

2.3. Availability Management

2.4. Capacity Management

2.5. IT Service Continuity Management

2.6. Supplier Management

3.

Service Transition

3.1. Change Management

3.2. Release & Deployment Management

3.3.

Service

Asset

&

Configuration

Management

4.

Service Operation

4.1.

Functions

Service Desk

Technical Management

Application Management

IT Operations

4.2. Processes

Event Management

Incident Management

Request

Fulfillment

Access Management

Problem Management

5. CSI

Your study partner,




5/55

Module 1: Introducing ITIL v3

Overview & Objectives

1.

Module 1 ‐ Introducing ITIL

1.1.

ITSM –

def

1.2. ITIL

Provides (3)

Doesn’t include (1)

Objectives (3)

1.3. Best v. Good Practice

1.4. Service Mgmt vision

Vision means

Purpose of vision statement

1.5. ITIL Core lifecycle (5)

1.6. Resources vs. capabilities

1.7.

Functions v. Process

1.8. Process Owner v. Service Owner

1.9. Authority Matrix

How it helps

RACI model

1.10. Technology tools (5)


6/55

MODULE 1: INTRODUCING ITIL V3

Submodule Term Definition/Point

Overview & Objectives ITSM A process‐centered approach to delivery IT services that

meet business needs according to perf. Targets.

ITIL

Provides:

Best practices for ITSM

Common language

Drives continual improvement

Doesn’t include methodology to implement

Objective:

Contribute value

to

org.

by

alignment

of

IT

&

business

Increase Efficiency (cost/time)

Improve Effectiveness (meet quality requirements)

ITIL Lifecycle

Focus:

Understanding IT service needs

Improving quality service provisioning

Providing cost justifiable service quality

Identifying roles/responsibilities

Using KB approach

Identifying KPI’s

Best vs. Good Practice Best

= superior

outcomes

to

normal

practices

Now more widespread, itil practices are standards;

outcomes expected; good practice

Service Mgmt Vision

Act like a business, create vision with goals, budget,

metrics

Vision ‐Where do we want to be

Purpose of vision statement

• Clarify direction of IT support


7/55

• Motivate ppl in right direction

• Coordinate actions of ppl

• Outline POV of sr. mgmt

How ITIL can help add

value

Documenting, negotiating, & solidifying customer/biz

targets

Regularly assess

customer’s

perceptions

via

feedback

Ensure IT personnel adapt to business

ITIL Core Lifecycle

5 stages

Service Strategy – s’c approach to ITSM

Service Design – overall biz change process; s’c obj

portfolio of services/assets

Service Transition – develops/improves capabilities

for new/changing IT services into ops; focuses on

moving from obj to how to achieve it

Service Operation

–

deliver/support

IT

services

per

SLA’s; effective/efficiency key

CSI ☺

Provide structure stability strength to service mgmt

capabilities with principles methods & tools

ITSM

Set of org’l capabilities/resources to add value into

services/goods

Capabilities are skills and require raw materials;

resources are the rm

Request –

approval

–

ticket

created

–

appropriate

team

notified – individual does tings to close ticket; joan owns

ticket and interacts with joe/sarah to close ticket

Function, roles,

processes

Fn – units carrying out tings; contain on BOK; provide

structure

Process – activities to accomplish obi; combines

resources/capabilities (p/t) to create outputs which

creates value

Roles – staff involved in process/service delivery; key

roles are

Process

Owner

vs.

Service

Owner

Process vs. Service

Owner

PO – Helpdesk Mgr; ensuring all activities are

undertaken

PO role:

Defining p s’y

Assisting in p design

Review p strategy

Service Owner


8/55

Initiation, transition, ongoing maintenance/support of

service (fulfillment); ensures customers are satisfied

SO role:

Spoc

Ensuring delivery meets requirements

Identifies opportunities

for

improvement

Works with other owners

Confusing

Authority matrix

Clarifies activities to do.

Responsibility – execution of process/activiites

Accountable – ownership of quality/end result

Consulted

–

involvement

through

input

of

knowledge

Informed – receiving info. about process

execution/quality

Only 1 person is accountable for an activitiy; multiple

may be responsibility

Accountability must remain with 1 person for all

activities in a process

Technology tools

•

Workflow

• KB

•

Testing

• BI

• Discovery

Actions required before selecting tools

Process Definition

Set of coord’d activities combining capabilities &

resources to produce value‐add outcome to

stakeholder.

ITIL

Integrated processes through which org’s can meet

goals with eff/eff.

Primary char’s of processes:

Measurable

Specific results

Stakeholders

Specific events

Inputs activities output

If process defined

What to do? Build cpu


9/55

Expected result? Cpu works

Measure delivery – me ask you

How do outputs become inputs of another process?

Benefits of defined

processes for services

Integration/alignment of processes

Transparency of ops

Lower costs/shorter

cycles

Predictable results

Demonstrated confidence to customers

Service

Means of giving value by allowing outcomes sans

ownership

Enable – provides employee with computer; enables

them to work

By enabling them to work, sw and nw access are

embedded

Your study partner,




10/55

Module 2: Introduction to ITIL v3 Con’t.

Service Strategy

1. Purpose

2. 2 Levels of activity for ITSM

3.

3 Questions

+ 3 other

objectives

4. Resources vs. capabilities definitions + how they’re used by each Lifecycle stage

5. Utility vs. Warranty [review] + how relevant in transition, operation, csi

Service Design

1. Purpose – def + consists of (3)

2. Main Goal (1) + Designing services (4) + Balance that must be struck

3. How Resources & Capabilities used in SS & SD

4. 5 aspects of SD

5. 4 P’s

6. Delivery model options (7)

7.

SDP – contains…

Service Transition

1. Purpose + feature

2. Org level vs. service level

3. Goals (4)

4.

Objectives

5. Relevance to res/cap

6. Key aspects of SDP (4)

7. Service V model – ensures + def

Service Operation

1. Primary purpose + Balance that must be struck

2. 4 main functions

3. Internal vs external view

MODULE 2: Lesson


11/55

Overview & Objectives

Service Strategy

Term/Theory Definition/Point

Purpose Establishes overall strategy for IT

2 levels

of

activity

for

ITSM

Org level

–

sets

direction

for

IT

via

strategy

and

objectives

to

achieve

vision

Service level – policies/objectives to ensure value creation

Questions answered

How create value?

How to define quality?

How to efficiently allocate resources across services

Other Objectives

Ensure org can handle cost/risk well

Set expectations of performance

Id/select/prioritize business opportunities

Resources vs.

capabilities +

How they fit in

Lifecycle

Capabilities turn resources into goods/services.

SS manages consumption of resources and capabilities by service

SD uses resources and capabilities

St test against resources/cap

So allocate resources and cap

Csi measure/asses both res / cap

Utility & Warranty

Utility – fit for purpose

- What is delivered

- What customer gets

- What

gains

performance

customer

gets

- Functional requirements for service

Warranty – fit for use (parameters)

It must perform within stated parameters

Both U&W are tested/validated in transition

U&W delivered in Operations

CSI measures/assesses planned utility & warranty vs. actual delivered in operations


12/55

Service Design


Purpose

Design of new/changed services for introduction to production

Arch

Processes

Documentation

Ensures functional/mgmt/operational requirements are considered

Main

goal

Build for all services a SD package that contains all aspects

Other goals:

Designing services

that meet biz obj

with efficiency/effectiveness

security/resilience

measurements/metrics

Balance:

Ensure functional & performance targets are met

Strives to provide more efficiency/effectiveness solutions by coordinating all design

activities for IT services to ensure consistency

R&C SS manages consumption of r/c

SD produces designs using the allocated resources/capabilities

5 aspects to SD

Design used service model from strategy to design services for OP.

Design of solution (including functional Requirements, resources, and capabilities)

must be

agreed

on

Design of SM systems/tools for control/mgmt

Design of technology arch/systems to provide services

Design of measurement systems/metrics

Results‐driven approach

4 Ps & SD

People

Products/tech’y

Processes

Partners/supplies

Delivery model options

Model selected

for

design

is

driven

by

model

selected

for

delivery.

1. Insourcing – internal resources for all stages

2. Outsourcing – resources for all stages

3. Co‐sourcing – combo of in/out for elements of service lifecycle

4. Partnership/multisourcing – formal arrangement between 2/more orgs to

work together (aka strategic partnership)

5. BPO – formal arrangement between 2 org to manage/host entire function (i.e

call centre, payroll)


13/55

6. App service provisioning = formal arr. With application service providers for

shared computer‐based services (on‐demand sw/apps)

7. Knowledge process outsourcing – provide domain‐based processes/biz

expertise rather than just process expertise; required advanced analytical and

specialized skills

SDP

Details of

all

aspects

of

a service

through

all

stages

of

lifecycle;

produced

keeping

in

mind 5 aspects, 4 p’s, and DM options

Passed from SD to transition

All details for implementing evaluating and maintaining a service

Includes functional/architectural requirements

Consults other stages

Service Transition


Input

Transitioning new/changed IT services to operation.

Internal service (move from what’s required) to concept of how it’s implemented

Org level

Develops cap/resources to allow IT to transition to reality

Service level

Resources/capabilities convert ds requirements into portfolio

Require good set of processes to implement in ops.

Provides control; allow you to speed up/slow down.

Goals:

Set customer expectations of performance/usage to new/changed service (SLA)

Enable customer

to

integrate

release

into

biz

processes/services

Reduce variations in predicted/actual performance of transitioned services by

keeping customer informed

Reduce known errors / minimize risks from transitioning new/changed services into

production

Ensure they can be used in accordance with service requirements

Objectives: Primary: delivery service vision in a relevant, timely, quality and cost‐effective

manner.


14/55

Tertiary:

• Plan/manage res to establish service

• Ensure minimal impact on production

• Increase stakeholder sat

•

Increase proper

use

of

services

Cap/res ST must test against res/cap

Key aspects of SDP

required by ST team

Applicable services packages

Service specs/models

Arch design required to deliver

Definition/design of each release

Detailed design of how service components will be assembled

Release/deployment plans

Journey from as is required.

Service V model

ST ensures

alignment

via

testing

against

each

level

of

requirement.

Service V model

1. Define requirements: Biz requirements of Strategy (in SLP) are evaluated

against service review criteria and test plans; validates original biz case.

2. Define service requirements: Define service req. of Design (in SL

Requirements and SLA); i.e. ensure 5k ppl can use system

3. Design service solution: contained in SDP

4. Design service Release (in release package)

5. Design service solution (in SDP) testing done

Conclusion

SDP completed

Service Operation


~ Day to day work for the service

Goal/Obj

Primary purpose is deliver/support is services at agreed levels effectiveness/efficiency,

providing value to stakeholder.

High quality = high cost; balance must be struck


15/55

Day to day realization of previous stages’ work. Develops cap/res allowing IT org to

deliver/support service to customer.

Also needs to monitor

Managed ppl

process

technology

Value of ~ Where processes/activities are executed/delivered/assessed by customers.

Functions

4 main functions:

Service Desk – SPOC for users when service disruption, service requests, or some RFC’s

Tech mgmt – detailed tech skills to support ongoing operation (key role In

design/testing/release/improvement of it services)

Ops control – responsibility for daily operational activities to manage IT infrastructure;

breaks down into IT ops control & IT facilities Mgmt

App mgmt – detailed tech skills/resources to manage apps through SDLC

Required

consistent

accountability/responsibility

via

role

definition.

Conflicting

priorities

Balance conflicting priorities

Internal vs external view of IT – op teams focus on growing functional areas; external view i

customer perception

Continual Service Improvement

1. Primary purpose

2. Address 3 things

3. Key objective


16/55


~ Provides guidance in evaluating/improving the quality of services by measuring,

reporting, and improving service management processes/services.

Purpose Primary: align/realign to changing biz needs by implementing improvements.

Looking for ways to improve alignment/effectiveness/efficiency.

Goal

Address 3 areas:

- Overall Health of ITSM

- Alignment of portfolio of services with biz

- Maturity of IT services

Key objectives

Review,

analyze,

make

recommendations

on

processes

in

each

lifecycle

stage

&

op

services.

4 main reasons to

measure

Validate previous decisions

Set direction (most important reasons)

Justify courses of action w/proof

Intervene and provide corrective actions

Baselines must be set for the following:

Goals/obj

Process maturity

Op’l metrics and KPI’s

IT Governance

Common terms

Improvements – outcomes that show measurable increase/decrease in a metric

Benefits – gains achieved via realization of improvements

ROI – difference between saving achieved and amount expended to realize saving

VOI – extra value created by benefits including non‐monetary or lt outcomes;

subcomponent is ROI

Deming cycle Mgmt philosophy for est. quality, productivity, and competitive position.


17/55

Plan – formulate goal/theory, define how to measure success and plan

Do – execute plan

Check – monitor outcomes vs expected results and look for lessons learned

Act – integrate lessons learned, adjust theory/method, determine what more we

must learn

CSI model

B. Vision ‐ Embrace vision by understanding biz obj

Baseline assessments ‐ Assess current situation (as is); baseline analysis of current

position. Measurable targets

Service & Improvement targets ‐ Understand/agree on priorities based on vision

Detail CSI plan by implementing ITSM processes

Measurement & Metrics ‐ Verify metrics are in place to see if milestones reached/

processes compliant

Ensure momentum is created to ensure it keeps on trucking

Exam Re‐Cap Service Strategy (SS):

ID goals/objs of SS

Define/explain concept of res/cap

Define/explain value composition w/U&W

Exam Re‐Cap Service Design (SD):

Exam Re‐Cap Service Transition (ST):

Exam Re‐Cap Service Operation (SO):


18/55

Exam Re‐Cap Continual Service Improvement (CSI):

Explain the main goals/obj of CSI

Your study partner,




19/55

ITIL v3 ‐ Module 3

Service Strategy

1.

Outline

1.1.

Key decisions

(3)

2. Service Portfolio

2.1. Contains (4)

2.2. Service catalogue

What it is

Contains (4)

2.3. Service Pipeline

2.4. Retired Services

3.

Demand Mgmt

3.1. Responsible for1

3.2. Challenge

3.3. Activity‐based D Mgmt

3.4. Analyzes (3)

3.5. Key Objectives

3.6. Risk

4. Financial Mgmt

4.1. 3 main activities

4.2. Service valuation + goal

What’s the difference between Service Portfolio & Service Catalogue?

The Service Portfolio is composed of all services committed to IT customers ‐‐ current,

under development and future ‐‐ as part of continual service improvement. The Service

Catalogue is that portion of the Services Portfolio that is currently available to IT

customers, so it's a subset of it.

1 Understanding customer demand for it services and provisioning capacity accordingly


20/55


21/55

SC

1 component of sp

Projection of services actual/projected capabilities

It’s published to customers; supports sale/delivery

Includes information about: deliveries, prices, contact points,

ordering and request processes

Service Pipeline – initial stage of new services; doc listing all

services under consideration/dev

Retired services – final stage in lifecycle of all services;

repository of offerings/lessons learned when delivering

services in the past; perm removal of IT services or CI from

production

Biz case Decision support/planning tool; helps predict outcome of

proposed action/justifies investment

D Mgmt

Unique patterns of biz activity become identified.

D Mgmt is responsible for understanding customer demand for

IT and provision capacity accordingly.

Aims to ensure capacity when required.

Challenge of synchronous production/consumption.

Activity based D Mgmt – ties biz activity as primary demand for

it services. PDA – patterns of biz activity

PDA’s helps us define op requirements and Service Level

Packages


22/55

SLP – a definite level of U&W associated with a SLP

D mgmt – looking at:

- User

- Top Utility features

- Warranty

–

speed

Risk Future event that may adversely affect SLA’s

Financial Mgmt

ROI, VOI, cost‐benefit analysis, costing models, IT budget, user

charges support go/no go on biz obj.

3 main activities

- Budgeting

-

IT

accounting

- Charging

Other key activities:

Service valuation – means to a mutual agreement with biz

regarding services what components, actual cost. Key goals

are produce value for services that are fair to biz +

improvement mgmt of demand/consumption via d modeling

Service Investment & CBA – value of services + costs incurred

to provide service

D modeling

–

anticipated

usage

by

biz

and

provisioning

requirements from IT

Encapsulated within SP elements of the biz case & risk

assessment

SLP – contains all work done so far. SD uses to create SD.


23/55

Exam Re‐Cap

Your study partner,

B Wyze

Solutions

(a

preferred

MindMuze

Education

Partner)



24/55


Service Transition – to boldly build, test, and implement SDP’s into SO

1. Change Management

a.

Outline

i. Focuses on

ii. Primary focus

iii. Where strategic

and corrective

changes take

place

b.

Basic Concepts

i. RFC

ii. CAB, ECAB,

Change Authority

iii.

Back out plan

iv. Change Schedule

c. 3 Types of changes*

difference between std

and normal change

d. Change Model

e. Change process 6

f. KPI’s of Change (3)

g. 7 r’s of change1

2.

Release & Deployment

Management

a. Outline

i. Full architecture

broken down into

tech/non‐tech

activities

ii. Responsible for

planning

scheduling

controlling

release from test

production

1 raise, reason, return, risk, resources,

responsible relationship

iii. Primary

objective* how

it

compares to

primary objective

of change

b. Concepts

i. Release package

ii. Storage areas for

authorized media

and hw spare

parts

1. DML

2.

DSS

iii. R&D Models

iv. 4 Release

approaches

c. Roles (3)

d. Terms

i. Release

ii. Deployment

iii. Rollout

iv. Release Unit

3.

Service Asset and Configuration

Management

a. Outline

i. Yep

ii. Critically

interdependent

with (2) processes

b. Differences between SA /

C

mgmt

c. CMDB; critical aspect

thereof

d. CI

e. CMS

f. Configuration baseline

g. SKMS supported by data

in CMS and CMDB


25/55

h. SA Manager, C Manager,

C analyst, C librarian,

CMS admin, C ctrl board,

janitor

i. Terms

i.

Asset Mgmt

ii. Attribute

iii. Baseline

iv. Config Mgmt

v. CMS

vi. Config baseline

vii. Service Asset

viii. SKMS

ix.

Benchmark

x. Snapshot

xi. CI

Service Transition – Part 1 ‐

1. Service Transition

1.1. Outlines

help to plan build test implement SDP’s into Production

internal service to IT; what is required how it’s implemented

1.2. Change mgmt

Outlines:

⇒ Focus on service change (addition, mod or removal of planned service,

component

⇒ Primary objective: enable beneficial changes w/minimal disruption of

IT services

⇒ Other objectives

1.2...1. Changes done controlled manner

1.2...2. Changes recorded, evaluated, authorized, prioritized, planned

tested implemented, shaken a stick at whipped fried buttered

basted

⇒

Strategic changes

triggered

in

SS;

Corrective

changes

in

SO

1.2...1. Strategic change if major change in service

Basic concepts within Change:

⇒ RFC

⇒ Roles:

1.2...1. CAB


26/55

1.2...2. ECAB

1.2...3. Change Authority – provide formal auth. For each change. Roles

include:

⇒ Back out plans must be considered for all changes to revert to pre‐

change state; contingency plans must be created where BOP not

possible

⇒ Change Schedule – lists all approved changes and planned dates. It

becomes an important audit trail to support incident/problem mgmt

among other processes

3 types of changes:

⇒ Emergency

⇒ Normal – I’m moving to another office and need printer moved

⇒ Standard – I want to get a printer that prints in colour

Change model: repeatable process to deal with a particular category of

change (steps, order, timescales, escalation procedures)

Change activity steps:

⇒ Record RFC

⇒ Review

⇒ Assess/evaluate

⇒ Authorize/schedule

⇒ Coordinate change, implementation, plan, build, test, implement

⇒

Review and

close

RFC

KPI of Change Mgmt Process:

⇒ # of change implemented

⇒ Reductions in unauthorized changes

⇒ reduction in backlog

⇒ change success rate

⇒ reduction in associated incidents

Challenges faced by Change activities:

⇒

legacy systems

⇒ balance between stable production and being responsive to b needs

⇒ risk mgmt


27/55

Exam recap:

1.3.

Release & Deployment Mgmt

Outline:

⇒ Manages release of service; planned in design stage

⇒ Full arch broken into tech/non‐technical deployments

⇒ Responsible for release & deployment activities

⇒ Focused on assessing technical/non‐tech activities of release

⇒ Contains hw, sw, and documentation CI’s; all happen in transition

⇒ Responsible for planning scheduling controlling releases from test

production environments

⇒ Primary objective: Protect integrity of IT services/infra by ensuring

correct comp’s

are

released

⇒ Other objectives:


28/55

Concepts:

⇒ Release Package – combo of individual releases grouped together.

⇒

RP contains

individual

CI’s

&

release

units.

Aim

of

defining

release

units is to decided most appropriate release unit for each

asset/component

⇒ Physical storage areas for authorized media and hw spare parts

1.3...1. DML (library in which media config items are stored/protected;

physical area where master copies of media versions are placed;

only sw from DML is acceptable for use in release)

1.3...2. Definitive spares (surplus hw) and physical storage areas for all

authorized media and hardware spare parts

⇒ Standard R&D models – illustrate std flows and activities to guide ppl

on

approach,

mechanisms,

processes,

procedures

and

resources

1.3...1. Big Bang – all user areas in one operation

1.3...2. Phased – part of the user base

1.3...3. Push – to users at a time not of their choosing

1.3...4. Pull – to users of their choosing; they call pull it down at own

location when they please

⇒ Roles

1.3...1. R&D mgr ‐ all aspects of package

1.3...2. Deployment mgr – final physical delivery of the service

implementation

1.3...3. R Packaging & Build mgr – controls workflow

⇒

Exam recap:


29/55

⇒ Terms:

1.3...1. Release – process responsible for planning, scheduling,

controlling the movement of releases to test/production

1.3...2. Deployment – activity responsible for movement of new or

changed, hw, sw, documentation, process to production

1.3...3. Rollout – deliver install commission of new/changed CI’s across

logical/physical parts of an organization

1.3...4. Release unit – comp’s of and IT service that are normally released

together

1.3...5. DML – 1 or more locations in which definite/approved versions of

all sw CI’s are securely stored

1.4. Service Asset & Configuration Mgmt Process

Outline:

⇒

Both asset/c

items

are

managed

from

acquisition

to

disposal

⇒ Objectives:

1.4...1. provide logical model of IT infrastructure

1.4...2. optimize costs

1.4...3. enable organization to comply with corporate governance

requirements

1.4...4. manage change/release

1.4...5. resolve problems/incidents faster

⇒ SACM, change, release & deployment are critically interconnected

Differences between

Service

Asset

and

Configuration

Management:

⇒ SA – tracking & reporting value & ownership of IT assets

⇒ CM – maintaining information about CI’s including their relationships;

information in CMDB

⇒ CMDB – stores config records about details of CI; holds relationship

between all CI’s; scope is a critical consideration

⇒ CI – component of an item can vary in complexity, variety and type


30/55

⇒ SACM process requires CMS; provides interface to relate information

in CMDB to all other service mgmt tools & arch’s; helpdesk analyst

accesses CI information via CMS

⇒ Configuration baseline

⇒ SKMS – supported by data held in CMS and CMDB’s

⇒ It’s much broader than CMS in that it covers experience of staff, user

behaviour, supplier requirements/abilities/expectations, etc.

⇒ Good SKMS results in: better decisions being made with better results

⇒ Facilitates better decision via better knowledge

Roles:

⇒ Service Asset Manager – manage lifecycle of assets

⇒ Configuration Manager – manage lifecycle and relationships of all CI’s

⇒ Config Analyst – analyze/propose scope of A&CM processes

⇒

Config Admin/Librarian – custodian of master copies of CIs

⇒ CMS/tools admin – evaluates A&CM tools

⇒ Config control board – reviews changes in service configuration

⇒ Janitor – cleans up after the above roles when they leave the office

(these roles are getting a bit ridiculous…)

Exam recap:

Terms:

⇒

Asset Mgmt – Process for tracking & reporting value and ownership of financial assets throughout their lifecycle

⇒ Attribute – piece of info about a CI

⇒ Baseline – benchmark used as a reference point

⇒ Config Mgmt – process responsible for maintaining info about CI’s

required to deliver and IT service including their relationships


31/55

⇒ CMS – set of tools/db’s used to manage and IT service provider’s C

data

⇒ Configuration baseline – used as basis for future builds, releases, and

changes

⇒ Service asset – capability or resource of a service provider

⇒ SKMS – set of tools/db’s used to manage knowledge and info

⇒ Benchmark – recorded state of something at a specific point in time

⇒ Snapshot – current state of a CI as captured by a discovery tool

⇒ Relationship

⇒ Configuration – a db used to store c records through lifecycle

⇒ CI – component that needs to be managed in order to deliver and IT

service

⇒ CMDB is subset of CMS which is subset of SKMS

Your study partner,




32/55


Service Design

1. Main purpose

2.

5 Elements

of

Design

3. Service Catalogue Mgmt

3.1. 3 Objectives

3.2. 2 critical aspects

3.3. SL vs. SC Manager

4. SLM Process Part 1

4.1. Objectives (2)

4.2.

SL Requirements (definition + 5 things)1

4.3. UC

4.4. OLA

4.5. SLA

5. Availability Mgmt

5.1. Responsible for

5.2. Objectives

5.3. VBF (def) may avail themselves of special IT Service Designs:

HA

Fault Tolerance

Continuous Operation

Continuous Availability

5.4. Proactive & Reactive strategies

5.5. AMIS Part 2

5.6.

Component vs.

Service

Availability

6. Capacity Mgmt

6.1. Definition of capacity

6.2. Subprocesses (3)2

6.3. CMIS

7. Information Security Mgmt

7.1. Responsible for CIA (def)

7.2. ISMS

7.3. 5 key elements to ISMS3

8. IT Service Continuity Mgmt Part 3

8.1.

Goal

8.2. 2 concepts to be implemented4

8.3. BCM

1 Availability, reliability, maintainability, capacity, serviceability 2 Biz, Service, component 3 Control plan implement evaluate csi 4 BIA & Identification of VBF’s


33/55

9. Supplier Mgmt

9.1. Purpose

9.2. Supplier vs. Service Provider

9.3. UC’s

9.4. SCD

What’s the difference between Capacity Mgmt & Availability Mgmt?

The capacity mgmt process is responsible for ensuring that the capacity of IT services

and the IT infrastructure is able to deliver agreed SL Targets in a cost effective and

timely manner.

The availability mgmt process is responsible for ensuring that the People process tech’y

are appropriate [given SLA’s].

SERVICE DESIGN PROCESS P1

Service Design

10. Outline

10.1. Main purpose

11. Service Catalogue Mgmt

11.1. 3 Objectives

11.2. 2 critical aspects

11.3. SL vs. SC Manager

12. SLM Process

Term/Theory Definition

SD

Main purpose is design of new/changed serv

Serv catalogue mgmt process creates/manages accurate SC. Focuses

on providing information on all servs.

SCM

Objectives of SCM

- Create/mge SC

- Ensure information up to date/interdependencies

- Includes both new/existing

- Support sales/delivery

Two aspects critical

Biz Serv. Catalog – customer view of SC; details all servs

Technical serv catalog – details of all IT serv, CI’s, components, etc.


34/55

required for delivery. Facilitates SLA, OLA, CI components,

underpinning contracts, etc.

SLMgr

Assist with production of accurate SP, SC, App portfolio

SCMgr

Producing/maintaining SC, ensure accurate SC, information consistent

with SP

SLM Process

Negotiates SLA’s and ensures they’re met

SLM Objectives

Impacts 2 other stages (trans/ops)

SLreq’s

Requirements for a customerfacing aspect of an IT service

Based on biz obj and used to negotiated agreed SL targets from

customer perspective

Includes:

Availability

Reliability (time entre inc)

Maintainability MTTR

Serviceability – ability of 3rd

party to meet terms of contract

capacity

Underpinning

contracts

Contract entre suppliers/external partners

OLA Contract between internal units

SLA

Basis for managing rship entre service provider and customer.

Defines key

targets/responsibilities

for

both

parties

Match biz needs/expectations to IT services.

OLA/UC’s support SLA

SLM

Ensures all ITSM processes, OLA’s, and UC’s are appropriate given SL

targets.

Represents IT to biz. Provides POC to biz managers/customers to IT.


35/55

Responsible for agreeing/documenting sl targets/resp for every

activity in IT.

SLM must have close interface with SPM

Planning coordinating

drafting

agreeing

monitoring

reporting

on

targets in SLA

SLA process

activities

SLM metrics

Developed from serv, customer, and biz perspective

Include:

Percentage of targets met

Number/severity of

serv

breaches

Challenges:

Engaging biz

Differing requirements

Getting sla’s signed

Assuring sla’s disseminated

1. SCM

a. Objectives

b. Critical aspects

i. Biz Serv catalog

ii. Technical serv. Catalog


36/55

2. SLM

a. SLA

i. UC

ii. OLA

iii. SL Req.


1. Availability Mgmt

2. Capacity Mgmt

3. Information Security Mgmt

Objectives of lesson:

Know concepts, roles, responsibilities of avail, cap, and information security mgmt.


Availability

Mgmt

Responsible for ensuring all IT infrastructure processes, tools, and staff

roles are appropriate given SLavail targets

Obj: manage avail of services and resources. More obj:

VBF – functions critical to biz process; may require special it serv

designs. May avail themselves of following strategies:

- HA –minimizes effect of IT component failure

- Fault tolerance – ability of it serv ci or component to operate

correctly when other related parts fail

- Continuous operation – approach to eliminate planned downtime

- C’s

avail

–

approach

to

achieve

100%

avail

2 key elements:

Proactive activities – planning, design, improvement of avail | cost‐

justifiable and meets needs of biz

Reactive activities – monitoring, measuring, analysis, and reporting for

serv and comp avail; key output for avail is measurement/reporting


37/55

Created in AMIS (availability Mgmt Info System)

Don’t need to know activities within diagram

Comp avail – all aspects of assessing aval

Serv avail – all aspects of assessing impact/potential impact of compo

avail/unavail

Avail plans/designs given to SLM process; provided for in OLA’s/UC’s in

Serv operation

Exam recap Availability:

Capacity Mgmt


Capacity Mgmt

Capacity – max throughput a CI/serv can deliver while meeting SL

targets

Responsible for capacity of it serv/infra can deliver sl targets eff/eff

Objectives:

Reactive activities of ~

Monitoring, measuring analysis, reporting

Proactive activities of ~

Trending, modeling,

tuning,

optimizing

Creates plans/designs via 3 subprocesses:

- Biz cap mgmt – focused on biz requirements

- Serv cap mgmt – focused on delivery of existing serv (capacity vs sla

& slr targets); proactive/reactive strategies

- Component cap mgmt – al compoenents used to meet serv reqs


38/55

CMIS – guess

Exam recap cap mgmt:

Info Security Mgmt Process

Objectives:


~

Focuses on mgmt of security risks

Ensured (CIA) confidentiality, integrity, avail of assets, info, data and IT

services

ISMS – ppl, process, products, tech’y

5 key elements to ISMS (follow deming cycle)

- Control – est. org structure and provide control docs

- Plan

–

develop

IS

policy

and

integrate

into

sla/ola/uc

- Implement – ensure procedures, tools, and controls are in place to

support IS policy

- Evaluation – conduct audits (int/ext), analyze incidents

- Maintain ‐ csi

Exam recap IS mgmt


39/55


IT Serv. Continuity Mgmt Process

Term/Theory

Definition

~

Focuses on disasters

Goal – support overall biz cont. mgmt. process by ensuring required

facilities can be resumed within agreed scales

Identifies IT services deemed critical to survival of biz

Ensures resumption given required timescales (computer systems,

db’s, telecom, environment, tech support, sd , apps, nw)

Two concepts to be implemented:

BIA – seeks to id company’s critical biz services by analyzing outages and severity; identifies recovery requirements

VBF – fn’s critical to success of biz proceses; BIA id’s VBF’s, indlucing

people, processes, and IT serv’s; important to ITSCM, Avail, BCM)

ITSCM ‐ Cyclic process to ensure they continually align with BCP and

priorities


40/55

BCM – to implement ITSCM you need to identify key Biz processes

Initiation – relationship entre ITSCM and BCM

Exam recap: ITSCM

Supplier Mgmt

Process


~

Builds a value nw and manages contracts

Objectives:

Manages overall nw and value chain; working toward integrating

contracts/policies with our own.

Ensures suppliers meet terms conditions and terms of contracts.

Service Provider (elp wit hemail) – supplies IT servs to customers;

v. Supplier (give you box) – supplies g/s required to delivery IT servs

(telco’s, consultants, etc.); written as UC’s

Supplier & Contract DB (SCD) – complete set of reference info for

supplier mgmt procedures/activities

You establish new suppliers in transition

You review perf and renew/terminate contracts in operation


41/55

Exam recap Supplier Mgmt

5 elements of design, 4 p’s, outsourcing options all go together into SDP

Your study partner,

B Wyze

Solutions

(a

preferred

MindMuze

Education

Partner)



42/55

Module 3:

Service Operation Functions

1. Functions

a.

Service

Desk

i. Outline:

1. What role it plays

2. Focus

3. Primary objective

ii. Organizational Structure (3)

iii. 4 Types (depends on 4

things)1

iv. Outsourcing considerations

(4)

v. Metrics (2 categories)

vi. 4 Roles

vii. Terms:

1. Call centre

2. SPOC

3. Service Request

4. Helpdesk

5. Resolution

6. Service Desk

7. Recovery

b. Technical Management

i.

Outline:

1. Responsible for…2

2. Balances…(2)

ii. 3 roles

c. Application Management

i. Outline

1. Responsible for

2. Objectives (2)

d. IT Operations

i. Outline

1.

Responsible

for

2. Balances…(2)

3. 4 Roles

ii. Terms:

1. Console Mgmt/Ops

Bridge

2. Tech service

3. NOC

1 Staffing training retention technology 2 Right people, right skills, right places, right times

2. Processes

1.

Event

Management

a. Outline

i. Objective

ii. Manages

b. Events vs. Alerts

c. Monitoring

d. 2 significant aspects of definition

& generation

i. Generate…

ii. 3 types of events

e. Roles coordinating Evt Mgmt

procedures

2. Incident Management

a. Outline:

i. Definition of an incident3

ii. Primary objective

b. Incidents vs. Service Request4

c. Incident Lifecycle

i. Identification, log,

categorization,

prioritization (based

on…[2]), initial diagnosis,

escalation (2 types),

investigation and

diagnosis, resolution &

recovery, closure

d. 2 challenges of Incident Mgmt

e. 3 Levels of Support

f. Incident Manager

3.

Request

Fulfillment

a. Service Request definition

b. Promotes

c. Where detected

4. Access Management

a. Protects

b. Executed by (2) functions

3 Any event which disrupts or could disrupt service 4 Unplanned, deviation from actually, potentially affecting

SLA, could or actually disrupts service


43/55

c. Terms

i. Rights Mgmt

ii. Rights

iii. Access5

iv. ID

v.

Confidentiality

vi. Integrity

vii. Availability

5. Problem Management

a. Outline

i. Definition of a problem

ii. Primary objective

b.

2 major processes

c. Workaround

d. Known error record + where

entered + handled by

e. Terms

i. Problem

ii. RCA

iii. Root cause

iv. Workaround

v. KE6

5 Level & extent of it service functionality a user has 6 A problem with a documented rc and workaround


44/55

Service Operation Functions

1. Service Operation

1.1. Outlines

Value of

it

is

ultimately

measured

here;

it’s

where

things

are

executed,

delivered,

assessed

Aimed at providing stable IT infrastructure; use process to leverage capability

Functions

⇒ Service Desk:

1.1...1. Outlines:

1.1...1.1. SPOC for users

1.1...1.2. SD is focused on end user experience, business and quality of service

1.1...1.3. Primary objective: facilitate restoration of disrupted service by restoring normal

service

1.1...2. FCR

1.1...3.

Organizational structure

1.1...3.1. Local SD

1.1...3.2. Follow the sun service

1.1...3.3. Specialized SD groups

1.1...3.4. End result is that virtual SD is transparent, is SPOC, access 24x7

1.1...4. Per the staffing levels, training, retention and technology available, you’ll have one of

the following SD types:

1.1...4.1. Call Center – records calls, no solution, routed to depts

1.1...4.2. Unskilled – recorded, some resolved, easy ones resolved with SOP’s; dispatch

function

1.1...4.3. Skilled SD – recorded, most incidents resolved; new/complex escalated

1.1...4.4.

Expert SD

–

resolve

most

independently

1.1...5. SD outsourcing considerations:

1.1...5.1. tools/processes

1.1...5.2. sla targets

1.1...5.3.

ownership of data

1.1...5.4. access to information

1.1...6. Metrics:

1.1...6.1. Workload analysis – analysis of recorded calls/requests to support staffing & skill

type decisions. Include FCR, cost of handling an incident per minute, etc.

1.1...6.2. Customer sat – how are we doing, customer?


45/55

1.1...7. Roles:

1.1...7.1. SDM – managed overall desk activities, including supervisors

1.1...7.2. SD supervisor – ensure desk is staffed/managed during operational hours

1.1...7.3. SDA – provides l1 support

1.1...7.4.

Super users – liaison points with it in general

⇒ Exam recap:

⇒ Terms:

1.1...1. Incident

1.1...2. Call center – handles large volumes of incoming/outgoing calls

1.1...3. SPOC

1.1...4. Service request

1.1...5. Helpdesk – POC for users to log incidents

1.1...6. Resolution – action taken to repair the root cause of an incident or implement a

workaround

1.1...7. End user

1.1...8. SD – spoc between service provider and users

1.1...9. Recover – returning a CI/IT services to working state

1.1...10. Customer

⇒ Both tech mgmt and app mgmt can overlap into IT ops mgmt

⇒ Technical Mgmt:

1.1...1. outline

1.1...1.1. responsible to ensure right ppl with right skills in right places at right times

1.1...1.2.

balances skill

levels/costs

for

following

roles:

1.1...1.2.1. IT Infrastructure – tech knowledge custodian – identify, develop, refine

technical knowledge

1.1...1.2.2. Technology – HR custodian – train/deploy ppl

1.1...1.3. defines roles and support groups, including tools processes, and procedures

1.1...1.4. 3 groups that help to keep TM operational

1.1...1.4.1. Tech Mg/TL – managed tech analysts/arch’s

1.1...1.4.2. Technical Analysts/Arch’s all members who perform tech tasks related to

design, testing, and improvement

1.1...1.4.3. Tech Operator – technical staff for day to day


46/55

⇒ Application Mgmt:

1.1...1. Outline:

1.1...1.1. responsible to ensure that IT services are delivered and supported per SLA

1.1...1.2. objectives:

1.1...1.2.1.

Identifying functional requirements

1.1...1.2.2. assisting design/deployment

1.1...1.2.3. balances skill level and cost of following roles:

1.1...1.2.3.1. Application – technical knowledge custodian – id develop refine tech

knowledge

1.1...1.2.3.2. Application – HR custodian – works with tech mgmt to deploy ppl

⇒ IT Operations:

1.1...1. outline:

1.1...1.1. responsible to ensure IT services are delivered and supported per SLA’s

1.1...1.2.

balances stability/consistency

by

maintaining

status

quo

: adapting

to

biz

requirements

1.1...1.3. Roles

1.1...1.3.1. IT ops mgr – overall operational responsibilities, including ops control &

facilities mgmt

1.1...1.3.2. Shift Leader – day to day shift mgmt

1.1...1.3.3. IT Ops Analyst – senior staff

1.1...1.3.4. IT Operators – day to day operational activities

⇒ Exam recap:

Technical support – synonym for tech mgmt

Support Group – ppl with tech skills

Console Mgmt/Ops

Bridge

–

physical

location

that

consolidates

all

critical

observational

points

within IT so they can be monitored/managed from a centralized location

Tech service – an it service not used directly by the biz but required by the IT service provider

Application

NOC – consolidates all critical observational points in IT infra relating to the network

IT infrastructure

App Lifecycle

SOP


47/55

1.2. tech mgmt not responsible for OLA’s

SERVICE OPERATION PROCESSES

Evt Mgmt

Objectives:

1. Event Mgmt

1.1. outline:

focused on generating, detecting, and determination of meaningful notifications about status of

IT infrastructure and IT servs in order to initiate appropriate event control actions

manages events and escalating into Inc, Problem, or Change Mgmt

1.2. Event vs alert

Evt – change of state in CI or IT serv which has significance for mgmt thereof; not all are required

to be managed

Alert –

notification

that

evt

has

occurred,

warning

that

a threshold

has

been

reached,

something

has changed, or failure has occurred; requires a specific action to be taken

1.3. Monitoring – tracks conditions to provide information and promote understanding (i.e. check status of

device to make sure it’s operating per limits, event if not generating evts); an evt must be detected

and received before it’s an event

1.4. two significant aspects of how they should be defined generated and captured

must generate an evt notification message

classified by type

⇒ Normal operation (no evt); work completed, message rec’d

⇒ Unusual operation (no evt, requires monitoring) – gets close to exception

⇒

Exception operation

(evt

occurrence;

control

actions

required)

1.5. roles coordinating Evt Mgmt procedures

SD; initial response and communication to app mgmt team

Tech & App Mgmt roles – routine evt mgmt, deal with incidents and problems related to evts

IT ops mgmt roles


48/55

Exam recap:

Incident Mgmt

1. Incident Mgmt

1.1.

Outline:

process for dealing with all incidents (failures, questions, query)

any event which disrupts or could disrupt service; could be from monitoring or end user call

Primary objective: restore it serv to users asap

other objectives:

⇒ detect/resolve incidents,

⇒ align real‐time it activity to biz priorities,

⇒ id potential improvements,

1.2. Inc vs. Ser requests

Both incidents/serv requests are reported to SD

(serv request planned, repeatable

inc unplanned,

deviation

from

normal,

reduction

in

quality

of

agreed

serviced,

could

lead

to

disruption or reduction

Incident models – provided guidance to deal with incidents

1.3. Major incidents are treated differently

shorter timescale

⇒ separate procedures

should include:

⇒ steps to take

⇒ chronological order


49/55

⇒ who should do what

⇒ timescale

⇒ escalation procedures

⇒

evidence

preservation

activities

1.4. Steps:

Incident ID – reported

~ logging – ticket opened; documentation of ~

Categorization – hw, sw, infra

Prioritization – facilitate activities according to sla/ola/UC; priority given based on Urgency

(timeframe which users required resolution) & impact

Initial diagnosis – l1 support, resolving incidents based on knowledge/experience/kb’s/diagnostic

scripts; analysis may resolve on initial diagnosis and then close (FCR)

Escalation – guided by sla, will follow major incident procedure

⇒ functional escalation to tech teams

⇒

hierarchical escalation

to

SDS

and

Inc

process

mgr

Investigation & Diagnosis – l3 support teams do their thing

Resolution & recovery

Incident closure; stays open until related problem mgmt activities are completed if a major

incident

1.5. Challenges for ~

Ability to detect incidents asap

Convincing staff to log all incidents

Encouraging use of self ‐help

1.6. Incident Manager

Authority to

manage

incidents

through

l1

l2

l3

1.7. Levels of support

⇒ 1st

⇒ 2nd

⇒ 3rd

Exam recap:


50/55

Request Fulfillment Process


51/55

1. Request Fulfillment Process

1.1. Outline:

Service requests are frequently recurring

Allow for eff/consistent service fulfillment

i.e. how do I add items?

If cannot help, gets escalated to service desk, external vendors

1.2. Requests are detected in Inc Mgmt and transferred to Request fulfillment

Exam recap:

Access Mgmt

2. Access Mgmt

2.1. Outline:

Allows to make used of IT serv, data, assets

Helps protect confide, integrity, avail to only authorized users

Objectives:

⇒ Execute policies and actions defined in Info Security & Avail Mgmt

⇒

protect confide, integrity, avail to only authorized users

⇒ enables users to access servs within SC

⇒ Access – level/extent of serv’s functionality and data and end user can access

⇒ ID – information distinguishing end user

⇒ Rights – actual settings an end user has

Policies – primary guidelines in ~

Info mgmt plays vital role in identifying unauthorized access

Executed by tech/app mgmt functions

PW reset

No specific roles

Terms:

⇒ Rights/ID mgmt aka access mgmt

⇒ Rights ‐ entitlements

⇒ Access – level and extent of a serv’s functionality or data a user can use

⇒ ID – information about users which distinguish each other

⇒ Service Group

⇒ Confidentiality – data should only be accessed by authorized ppl

⇒ Integrity – items are only modified by authorized activities and ppl

⇒ Availability


52/55

⇒ IS policy

Exam recap:

Problem Mgmt

1.

Problem Mgmt

1.1. Outline

Unknown cause of one or more incidents

Manages lifecycle of all problems

Diagnose root cause, determine resolution, move through change & release

Primary obj: to prevent probs and resulting incidents, minimize impact of incidents

1.2. 2 major processes

Reactive – where inc mgr requires more resources and techniques to resolve; investigate all major

inc

Proactive – executed as part of CSI; tries to prevent future problems; focuses on id’ng preventing

problems via data from incident/problem data

1.3.

Inc/Prob will use similar tools, impact, categorization and priority coding systems

1.4. Workaround – temporary fix or implemention of alternate technique to avoid

1.5. known error record – allows quicker diagnosis and resolution when similar incidents occur; follow RCA

activity

entered into KEDB and forms larger SKMS

1.6. problem models ‐used to handle known errors

1.7. Terms:

Problem – cause of one or more incidents

RCA – sovling problems in a structured/organized manner

Root cause – underlying or original cause of I/P

Workaround

KE – problem with documented rc and a workaround

Status – required field showing stage associated with CI, inc, prob, or other record types

Exam recap:


53/55

Your study partner,




54/55

Module

3:

Continual Service Improvement

1. Outline

2.

7

steps

a. What should we measure

b. What can we

c. Collect data

d. process

e. Analyze

f. Present & Use

g. Implement

3. Key elements of 7 step process

a. CSF

b. KPI

c. Metrics

d. Measurements

4. Roles

a. Service Management

b. CSI manager

Objectives:

1. CSI

1.1. Outline

Integrate with all processes

1.2. 7 steps

Define what you should measure

Define

what

you

can

measure

Gather data

Process data

Analyze data

Present and use information

Implement corrective action

1.3.

Key

elements

of

7

step

process


55/55

CSF

KPI

Metrics

Measurements

Vary on qualitative and quantitative

1.4.

Roles

Serv M – full lifecycle mgmt of services

CSI M – developing CSI domain where CSI concepts/activities are practiced

Other roles:

⇒ Jim

⇒ Pam

⇒ Janitor

Exam recap:

Your study partner,

B

Wyze

Solutions (a preferred MindMuze Education Partner)

www.bwyze.mindmuze.com

for

more

details

Documents

ITILv3-studynotes