An Enterprise View to Running the Business of IT
An Enterprise View to Running the Business of IT
Implementing ITIL Based Service Management Programs
Implementing ITIL Based Service Management Programs
and
and
“
“
ERP
ERP
”
”
like tools
like tools
Presented by
Jeff Connie, IBM, IT Infrastructure Principal
[email protected]
Competitive Advantage
through Service Excellence
Lack of service context.
Lack of service context.
Not closed
Not closed
-
-
looped. Not automated.
looped. Not automated.
Data not shared or integrated.
Data not shared or integrated.
Business Growth
Operational Efficiency
and Effectiveness
Requirements
and Planning
Delivery
Support and
Assurance
Financial
Management
Continuity and
Resilience
Deployment
and Fulfillment
Config
Data
Asset
Relationship
Compliance
Data…
Operational
Data
Billing
Data
CxO
CIO
Other
Staff
LOB
Operations
Staff
Diminished Business Performance
Diminished Business Performance
Silo
Silo
-
-
specific. Not Integrated.
specific. Not Integrated.
Apps
Network
Data Center
Security
Voice
Storage…
Business
Objectives
Processes
Information
Technology
People
Business and Infrastructure Silos Must be
Bridged
IT Service Management touches every part of an IT organization
Implement policies by integrating information, technologies and people with
automated processes
Standardized,
federated,
accessible
information
Process
Technology
People
Information
Management
IT Service
Products and technologies to
automate and integrate tasks and
processes
Clearly
defined
roles and
responsibilities
provide a sound
decision-making
framework
IT services needs to support business goals, similar to business ERP
The starting point to a best practice approach is a common
framework…..
ITIL does not claim to be a comprehensive description of everything within
IT, but is a foundation of
comman language and processes
for IT service
management “best practices”
Adopt
ITIL as a common language and reference point for IT Service
Management best practices and key concepts.
Adapt
ITIL best practices to achieve business objectives specific to each
company.
ITIL does
not
define:
Every role, job or organization design
Every tool, every tool requirement, every required customization
Every process, procedure and task required to implement
What is already well defined in CMM, COBIT, BS15000, 7799, ISO
…..a common entry point based on priorities to service your business
needs…….
Incident Mgmt
Problem Mgmt
Change Mgmt
Configuration Mgmt
Incident data
Request for Change
Repaired CI
New version CI
Operations IT Infrastructure
Demand Mgmt.
Service Support
End User
Service Level Mgt
SERVICE
ENTRY
POINT
Service Delivery
Release Mgt
Capacity Mgt
Availability Mgt
Service Continuity
Security
Financial Mgt
Performance
Management
® QWR
SERVICE
ENTRY
POINT
…. and an understanding of how process and technology need to have
integrated workflow and automation
The ultimate question is how do you get from “best
practices” to “implemented” – effectively and efficiently?
Crossing the chasm
Islands of fragmented efforts –
high cost, low quality services
Enterprise direction, control and
execution of valuable services
Plan
Design
Develop/Test
Pilot
Deployment
Filling the design and implement gap will require adopting and
adapting ITIL best practices with a phased and structured
approach
Manage/Operate
Education & Certification
What else do you need to
“make ITIL work?
Without a structured enterprise approach to implementation,
good intentions can lead to higher expenses
ITIL’s popularity has driven a groundswell of
bottom up, “grassroots” but fragmented
efforts – which can lead to
Significant rework
Unwanted items
Costly duplication
Scope creep
Cancellation
Lot’s of education
Some existing work can be reused but this
requires detailed assessment of existing:
Tools
Roles
Processes
Documentation
This approach typically goes no where until
there is at least some top down support
Pursue high level support or seek assistance doing so
“ITIL Awareness” or Executive Briefings” can be helpful
Satisfy
Customer
Relation-ships
Manage IT
Business
Value
Support IT
Services and
Solutions
De
liv
er
Oper
at
iona
l
Se
rv
ic
es
Ma
nag
e IT
A
sse
ts
a
nd
Inf
ra
st
ru
ct
ur
e
Prov
id
e
Ent
er
pri
se IT
M
an
age
m
en
t
Sy
st
em
Re
al
iz
e
Solut
io
ns
Deploy
Solutions
SEI CMM SEI CMM ITILIT Process Model
A.D.E.
A.S.L.
Academic
Knowledge
Best Practices
Frameworks
Architectures
What does it take to successfully
implement
best practices?
Implementation expertise
(Assess, Plan, Design,
Implement)
Governance integrating the
business with IT and the
processes into the
organization
Prioritizing & Diagnostic
Techniques
Capability Maturity Model
Design & implementation
methods
Project management
Tool Vendor Relationships
Accelerator IC if possible
What does it take to
“make ITIL work”?
Align IT with
business
objectives and
enable more
innovation
Lower the long
term cost of
service delivery
Improve the
quality of IT
services
The good news! This is not new and there is an extensive library of
ITIL based templates to facilitate rapid assessment and design
available in the market
3. Change Management Process Overview
Change Management Process Mission Statement
• Change Management will control all changes to all Configuration Items (CIs) in the
managed environment by:
• Ensuring standardized methods, processes, and procedures are used for all
changes from the request for change to the post-implementation review
• Facilitating efficient and prompt handling of all changes
• Minimizing the impact of Change-related Incidents upon service quality thus
improving the day-to-day operations of the organisation
Process Goals
• Maintain a proper balance between the need for Change against the impact of the
Change.
• Minimize the impact of Change-related Incidents upon service quality and
consequently to improve the day-to-day operations of the organization.
• Maintain open channels of communication in order to promote smooth transitions
when Changes take place.
Process Scope
• The process starts with the recognition of the need to put in place and define a
management system to control Change, including procedures and policies; it ends
with the change being installed and activated.
• The process includes managing changes from the creation of a request, its
assessment, through to deployment monitoring and post-implementation review;
• The process also encompasses trend analysis and measurement reporting;
• The process of Change Management is principally managing the Change.
• The process does not include the technical design and testing of the Change
• The process does not include the actual implementation of the Change, but
manages and coordinates the implementation of the Change may also be
performed by the calling process, e.g. Release Management.
• Typical in scope changes include:
• Hardware, Communications Equipment and Software, System Software, Live
Application Software, All Documentation and procedures associated with
running, supporting and maintaining the production environment
• Changes to ongoing projects are out of scope.
Change Management – Carrying Out the Process
High quality requests based on criteria that adapt to practical usage;
organisation feels positive about using the change management process; feedback loop in place. All change
types accepted and controlled. CAB / EC
frequently consider RFCs electronically without the need for physical meetings.
Relevant business areas always involved in CAB / EC decisions
Change entry is automated and process rules enforced as a result - lead times,
process path, authorization requirements etc. are always correct. Emergency RFCs are always justified and handled correctly
Optimizing (5) NowGoal
Efficient (4) Effective (3) Aware (2) Initial (1)
Clear criteria; good
balance struck between
process standardization (automation) and
meeting varied departmental needs.
Risk assessments always done. Lead times required for all changes are enforced. Change types defined for all changes. Membership of CAB / EC always varies, depending on the RFCs being reviewed. Business areas may be represented on CAB Evaluation regularly includes risk assessment. Lead times defined for all changes, but not enforced. Change types are defined but do not include all changes. CAB / EC sometimes limited to those affected by the change. RFCs sent out
electronically for CAB preview
Uneven enforcing of criteria and required information; process known to be frequently
bypassed. Little or ineffective risk assessment. Lead times
defined for major changes. Regular CAB meetings with a large group of people
Much confusion over the evaluation criteria: not agreed/communicated with the change process participants, and possibly changing depending on the assessors. There is no CAB. Review Changes via Change Advisory Board (CAB) / Emergency Committee (EC)
Clear entry point(s); authorization works
(evidence of some "rejects" or requests that
need to be resubmitted due to insufficient information). Change Manager confirms all priorities and categories. RFCs are always sent to the correct areas for assessment. Some Emergency RFCs are due to poor planning
Good enforcement of required information;
tools/database used effectively; "informal"
authorization process,
possibly with some "rubber stamping". Some RFCs are rejected early on if data is missing or there is an obvious conflict of dates. Many
RFCs are classified as Emergency and allowed
through the process
Clear entry point(s), but
authorization process unclear, and known to be frequently bypassed. Required information is not known by all.
Much confusion over the change entry process, or there are multiple (possibly
changing) entry points. IT gets involved late in the cycle -- no notion of authorization to request changes
Accept & Classify Changes
Change Management – Carrying Out the Process
High quality requests based on criteria that adapt to practical usage;
organisation feels positive about using the change management process; feedback loop in place. All change
types accepted and controlled. CAB / EC
frequently consider RFCs electronically without the need for physical meetings.
Relevant business areas always involved in CAB / EC decisions
Change entry is automated and process rules enforced as a result - lead times,
process path, authorization requirements etc. are always correct. Emergency RFCs are always justified and handled correctly
Optimizing (5) NowGoal
Efficient (4) Effective (3) Aware (2) Initial (1)
Clear criteria; good
balance struck between
process standardization (automation) and
meeting varied departmental needs.
Risk assessments always done. Lead times required for all changes are enforced. Change types defined for all changes. Membership of CAB / EC always varies, depending on the RFCs being reviewed. Business areas may be represented on CAB Evaluation regularly includes risk assessment. Lead times defined for all changes, but not enforced. Change types are defined but do not include all changes. CAB / EC sometimes limited to those affected by the change. RFCs sent out
electronically for CAB preview
Uneven enforcing of criteria and required information; process known to be frequently
bypassed. Little or ineffective risk assessment. Lead times
defined for major changes. Regular CAB meetings with a large group of people
Much confusion over the evaluation criteria: not agreed/communicated with the change process participants, and possibly changing depending on the assessors. There is no CAB. Review Changes via Change Advisory Board (CAB) / Emergency Committee (EC)
Clear entry point(s); authorization works
(evidence of some "rejects" or requests that
need to be resubmitted due to insufficient information). Change Manager confirms all priorities and categories. RFCs are always sent to the correct areas for assessment. Some Emergency RFCs are due to poor planning
Good enforcement of required information;
tools/database used effectively; "informal"
authorization process,
possibly with some "rubber stamping". Some RFCs are rejected early on if data is missing or there is an obvious conflict of dates. Many
RFCs are classified as Emergency and allowed
through the process
Clear entry point(s), but
authorization process unclear, and known to be frequently bypassed. Required information is not known by all.
Much confusion over the change entry process, or there are multiple (possibly
changing) entry points. IT gets involved late in the cycle -- no notion of authorization to request changes Accept & Classify Changes
Ex
tra
ct
On
ly
Ex
tra
ct
On
ly
ITIL Process Guides
ITIL Organization Guide
ITIL Service Management Guide
ITIL Process Diagrams: LOVEM, IDEF0
ITIL Metrics
ITIL Maturity Model
Management Surveys
ROI Calculator Tool
Workshop Materials
Project Plans
IBM offers it’s own brand of a phased approach, which
mirrors a similar business based ERP approach
Each phase of
this lifecycle are
influenced by the
following factors:
Infrastructure &
Organizational
Complexity
Customization
Requirements
# of Physical
Locations
Phase 1: Strategy
And Assessment
Phase 2: Design Solution
Assessment
Strategy
Selection
Operation
Processes
High level design
Technology
Organization
Data
Detailed Design
IGS ESM Lifecycle and Methods
based on industry best practices and analysis
of over 400 large enterprise projects
Manage Delivery
Development
Phase 1 : Access and solution Best Practice Considerations
Phase 1: Strategy
And Assessment
Assessment
Strategy
Selection
Planning to Implement
Where do we
want to be?
How do we get
where we want
to be
Where are we
now?
How do we
know we have
arrived
Visions and
business
objectives
Assessments
Process Change
Metrics
Where do we
want to be?
How do we get
where we want
to be
Where are we
now?
How do we
know we have
arrived
Visions and
business
objectives
Assessments
Process Change
Metrics
Planning to implement ITIL best practices requires effective
techniques to diagnose capabilities and prioritize
implementation efforts
Prioritize
Diagnose
Based on your priorities &
current process capabilities
Prioritize capability
improvement
What is healthy?
What needs improvement?
Importance
Ef
fe
c
ti
v
enes
s
Take
significant
action now
Candidates
for internal
iterative
improvement
programs
No action
now
ITIL Maturity Workshop - Service Support
1
2
3
4
5
Overall Rating
Release Management
Change Management
Configuration Management
Problem Management
Incident Management
Maturity
Current
Target
Different Assessment Types
Priority to Improve Assessment
Quick, High Level Capability
Review
Identify and Prioritize improvement
opportunities based a fast
structured and facilitated self
assessment approach
Capability Maturity Diagnostic
Assessment
A more focused and detailed
assessment of management
capability
Identifies specific improvements
Identifies existing re-usable
elements
9
I.e. implemented tools, job descriptions,
Detailed Process Analysis
Activity based analysis as a base
for design
Solution Selection considers the best approach for the
design and implementation of the solution
People
Training materials
Teachers
Customized & tested
enabling technologies
Acquire people
Develop curriculum
Customize and test tools
Define jobs & staffing
Workflows
Tool customization requirements
Select and install base tools
Define Roles and skill requirements
Define tool requirements
Process definition based on best practices
Governance model
Guiding principles
Compelling reason to act
MACRO DESIGN
DETAILED DESIGN
DEV
P
ILOT
Pr
oj
ec
t M
an
ag
em
en
t
Ph
as
ed
in
iti
at
ive
s,
cl
ea
r m
ile
st
on
es
Phase 1: Strategy
And Assessment
Assessment
Strategy
Selection
Phase 3: Implement Solution
Detailed Design
Development
Deployment
Processes
High level design
Technology
Organization
Data
Phase 2: High Level Design
Technology
Technology
Services
Services
Process
Process
Information
Several potential approaches to implementation are considered
with the best approach being selected based on the need for
customization
High Level Design
Processes
Architecture
Organization
Data
Detail Design
Develop
Deploy
ESM Lifecycle Phase 2
Design the
Solution
ESM Lifecycle Phase 3
Implement the
Solution
Traditional Consulting Approach
High Level Design
Detail Design and Implementation
Customized
Fastrack approach based on an ITIL design
High Level Design
Detail Design and Implementation
Tailored
IBM ITIL Accelerator Solution
Personalized
Outsourcing Solution
Service
Provider
Offering
Then, the implementation context should be decided
Design a core set of processes required to support and delivery any
specific service as a foundation for successful service management
ITIL Fast track approach: Design a core set of processes required to
support and delivery any specific service as a foundation for
successful service management
When implementing ITIL, further scope limitation decisions should be made to
aid a quick and effective effort:
Service: implementation will focus on one or more specific services
Infrastructure: implementation will focus on some subset of the
infrastructure
Process: implementation will focus on one or twp processes only
Organization: implementation will focus on some subset of the organization
Improve existing service management based on an incremental change in
infrastructure, systems management tools, organization, sourcing,
services or business applications
Phase 2 : Design Solution Best Practice Considerations
ITIL based templates to
enable fast track design
approach
Process Guide Templates
Organization Guide Template
Service Support and Delivery
Management Guide Template
Project Plan
High Level Implementation Plan
Phase 2: Design Solution
Processes
High level design
Technology
Organization
Data
Phase 2: High Level Design focuses on the logical model
for the management framework
Management
Model &
Guiding
Principles
Elements
To Be Managed
If a phase 1 assessment has not been done, a fast design based assessment is required to gather the information needed at the
beginning of the project to ensure a rapid successful completion
Executive
Steering Committee
Project
Management Office
Design
Team
Process Team
#2
Process Team
#1
Process Team
#3
Define IT Services
Visible & Invisible
Accounts
Sales
Marketing
Legal
Production
Retail
Warehouse
Transport
Design
Payroll System
Accounting
System
Invoicing
Stock Control
System
Legal System
Ordering
Logistics
Postal
Addresses
CAD/CAM
Intranet
Internet
Office Suite
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Process Guide
Definition
mission
scope
inputs& outputs
activities
measurements
Organization Guide
Roles
Subprocesses performed
Technology Used
Skill Requirements
Role Location
Role Levels
Skills/Role
Tool Guide
Required Tools
Functions Performed
Tool Requirements
Location used
Gap Analysis
Service Guide
Definition
Customers, Stakeholders etc
Interfaces
Service flow
IDTask Name 1Start Stage III 2Launch Stage III Project 3 Reconfirm Project Scope, Objectives, Assumptions , Dependencies
4 Set Up Project Environment
5Develop Project Plan 6 Define first implementation scope
7 Meet with Tivoli project manager
8 Meet with Remedy project manager
9 Refine Tasks
10 Refine Schedule
11 Refine Resource Plan
12 Document Project Success Criteria
13Review Project Plan 14 Review Project plan With Sponsor
15 Conduct Project Kick Off with Core team
16 Conduct Project Kick Off with PC/LAN Services
17 Conduct Project Kick Off with Aurora
18 Conduct Project Kick Off with AD building participants
19Document Success Criteria 20 Success Criteria for Processes
21 Success Criteria for Organization
22 Success Criteria for Tivoli
23 Success Criteria for Remedy
24 25Develop Costs 4/84/8 4/84/8 4/84/8 4/294/29 4/294/30 4/305/2 5/25/3 5/35/6 5/65/7 5/75/8 5/85/10 5/95/9 5/105/10 4/84/8 4/84/8 4/84/8 4/84/10 4/84/10
Feb Mar AprMay Jun Jul
