IT Service Management tools

- Acquisition and implementation

Christian F. Nissen, CFN People A/S

ITIL® and PRINCE2® are Registered Trade Marks of the Office of Government Commerce in the United Kingdom and other countries
COBIT® is a registered trademark of the Information Systems Audit and Control Association (ISACA) and the IT Governance Institute (ITGI)
TOGAFTM is a trademark of The Open Group

© 2011 of CFN People A/S unless otherwise stated

 Three P’s
The magic triangle

2 © 2011 – CFN People A/S

 Agenda

 IT Service Management tool architecture

 Project set-up
 Definition of requirements
Selection of tool and vendor
Agenda


 Proof of concept
 Delivery model
 Negotiation and acquisition
 Configuration and customization
 Establishing foundation data
 Test
 Training
 Data migration
 Go-live
 Early life support
 Post implementation review and improvement
3 © 2011 – CFN People A/S
 Typical IT Service Management tools
Tool architecture
ITSM tool architecture

IT Service Management IT Infrastructure Project set-up

suites Management tools Requirements

Selection
 Workflow management  Monitoring
Proof of concept
 Portfolio and contract  Event logging and
Delivery model
management management
Acquisition
 Integrated  Diagnostic utilities
Customization
configuration  Job scheduling
management Foundation data
 Automation
Test
 Self-service
 Discovery Training
Administrative and
 Remote control Data migration
analytical tools
 Security control Go-live
 Analysis, simulation
Early life support
and modeling
PIR and improvement
 Reporting and
dashboard
4 © 2011 – CFN People A/S
 Typical IT Service Management tools
Tool architecture
ITSM tool architecture

Software and Application Project set-up

Management tools Requirements

Selection
 Release management
and version control Proof of concept

Delivery model
 Test and validation
management Acquisition

Customization
 Deployment
management Foundation data

Test
 License management
Training

Data migration

Go-live

Early life support

PIR and improvement

5 © 2011 – CFN People A/S

 “Software suite” or “Best of breed”?
Tool architecture
ITSM tool architecture

Software suite: Best of breed: Project set-up

Requirements
Vendor 1 Vendor 2
Selection
Workflow Self-service portal
One vendor Proof of concept

“All” included Delivery model

Acquisition
Vendor 3 Vendor 4 Monitoring
Customization

Foundation data
CMS
Test

Training

Data migration

Go-live

Early life support

Dash-board Job schedule
PIR and improvement
Vendor 5 Vendor 6

6 © 2011 – CFN People A/S

 Multi-sourcing - partnership governance
ITSM tool architecture

Interface
AS-IS AS-IS AS-IS AS-IS AS-IS AS-IS

AS-IS AS-IS
TO-BE
AS-IS

AS-IS AS-IS
Alignment TO-BE AS-IS TO-BE
AS-IS TO-BE AS-IS TO-BE
TO-BE
AS-IS
TO-BE

TO-BE TO-BE
TO-BE
TO-BE TO-BE TO-BE
Integration TO-BE TO-BE
/ Control
Services

Requirements

Agreements

Management

Ownership

Functions

Roles

Decision forums

Processes

Knowledge

Competences

Tools

Applications

Infrastructure

Data
7 © 2011 – CFN People A/S
 Tool architecture in a multi-sourcing environment
Tool architecture
ITSM tool architecture

Project set-up

Requirements

Selection
Customer User Service Desk Infrastructure Application
Management Management Proof of concept

Delivery model
Ordered Company 1 Company 2 Company 3
Scenario 1 Owns tool A Operates tool A Acquisition
Uses tool A
Share Uses tool A Uses tool A Customization

Scenario 2 Accesses tool A Owns tool A Owns tool C Foundation data

Separate Uses tool A Uses tool C
Test

Training

Scenario 3 Owns/operates/uses Owns/operates/uses tool Owns/opera- Data migration

Integrate tool A B tes/uses tool C
Go-live

Early life support

Uses shared
Scenario 4 Uses shared tool A Uses shared tool A in (a
tool A in (a PIR and improvement
Cloud tool in (a private) cloud private) cloud
private) cloud

8 Configuration data?
© 2011 – CFN People A/S
 Integration to other ITSM tools or data sources
Tool architecture
ITSM tool architecture

 What to synchronize?  Incidents? Work orders? Project set-up

Solutions? CIs? Etc.? Requirements
 Which selection criteria?  Specific organization units?
Selection
Services? CIs? Support
groups? Proof of concept

 When to synchronize?  Status change? Each time Delivery model

the record is changed?
Acquisition
Closure? Specific trigger?
Customization
 Which way?  One way? Two ways?
Foundation data
 How to synchronize?  Full record? Fields? Function
of other fields? Test

 Notifications and e-mail?  Cross-site notifications? E- Training

mails with links?
Data migration
 How to handle update conflicts?  Lock record? Master/slave?
Go-live
 Error handling?  Queuing? Close system?
Early life support
 Preconditions  Shared foundation data?
Shared categories, priorities, PIR and improvement
SLAs etc?
 Capacity and Performance?  Volumes? Cascade effect?
9 © 2011 – CFN People A/S
 Relations to other tools and repositories
Tool architecture
ITSM tool architecture

Project set-up

Requirements

Selection

Proof of concept

Delivery model

Acquisition

Customization

Foundation data

Test

Training

Data migration

Go-live

Early life support

PIR and improvement

10 © 2011 – CFN People A/S

 Project governance - example
Tool architecture

Project set-up

Requirements
Project set-up

Selection

Proof of concept

Delivery model

Acquisition

Customization

Foundation data

Test

Training

 Business case? Data migration

 Who approves requests for customization? Go-live

 Tool and process governance? Early life support

 Vendor involvement? PIR and improvement
 Implementation, operational and maintenance partners?

11 © 2011 – CFN People A/S

 How to approach requirement specification?
Definition of requirements

Tool architecture

Project set-up

Big bang design Requirements

- Define all requirements at once
Selection

Proof of concept

Delivery model
Big bang
implemen- Phased design Acquisition
tation - Define requirements one part at a time
Customization

Foundation data

Phased
implemen-
Phased
implemen-
tation
Agile design Test

tation - Define requirements while you Training

build
Data migration

Agile Agile implementation Go-live

Agile implemen-
implemen- tation Early life support
tation
PIR and improvement

12 © 2011 – CFN People A/S

 How to specify requirements?
Definition of requirements

Tool architecture

Approaches: Project set-up

Requirements
 Out-of-the box (request the vendors user guides and
Selection
system and administration documentation)
Proof of concept
 Use cases based on your processes (request the vendors Delivery model
process documentation – but be aware that some of them Acquisition
provide processes that don’t match their own tool)
Customization

 Traditional requirement specification Foundation data

Combinations of the above Test

Training
Sources for requirements:
Data migration
 PinkVERIFY (http://www.pinkelephant.com/pinkverify) Go-live

 OGC: The ITIL Software Scheme Early life support

(http://www.itil-officialsite.com/SoftwareScheme/ITILSoftwareScheme.aspx) PIR and improvement

13 © 2011 – CFN People A/S

 Use cases
Definition of requirements

Tool architecture

Project set-up

Requirements

Selection

Proof of concept

Delivery model

Acquisition

Customization

Foundation data

Test

Training

Data migration

Go-live

Early life support

PIR and improvement

14 © 2011 – CFN People A/S

 Traditional requirement specification
Definition of requirements

Vendor response
ID Requirement Priority:
Degree of Degree of Degree of Fulfilment Fulfilment Cost of Cost of General Alternative
fulfilment fulfilment fulfilment through through configuratio customizatio comments: solution:
1=MUST of the of the of the configuration: customization: n: n:
2=SHOULD requireme requiremen requiremen Provide If adequate,
3=COULD nt from 0- t from 0- t from 0- If the If the If the If the general specify an
4=WANT 100% out 100% if 100% if requirement is requirement is requirement requirement comments alternative
of the box configurati customizati not completely not completely is not is not such as solution
on is on is fulfilled out-of- fulfilled out-of- completely completely dependencie
required required the-box please the-box please fulfilled out- fulfilled out- s to other
explain WHAT explain WHAT of-the-box of-the-box requirements
functionality that functionality please please , etc.
can be provided that can be provide the provide the
through provided cost of 100% cost of 100%
configuration through fulfilment fulfilment
and HOW. customization through through
and HOW. configuratio customisatio
n in EUR n including 5
years
subsequent
operational
costs in EUR
Demand Management - Define Service Level
Packages
12.16 Must be possible to make a Service Level Package 1
template to be reused every time a new service
offering is being created.

The service level options can be standardized for

selected service level objectives while for others it
must be set separately for each service level package.
12.17 Service Level Packages must at minimum contain the 1
following information
- ID, name, description
- version
- Create date, last updated, last review and next
review, live date
- SLP owner
- Service level objectives
- Cost including cost drivers
- Price including price drivers
12.18 Must be possible to capture and describe Service 1
Level Objectives in the tool and include these in
Service Level Packages

15 © 2011 – CFN People A/S

 A few commercial sources for tool selection
Selection of tool and vendor

Tool architecture

 Tool selector (http://www.itsmportal.com/tools) Project set-up

Requirements
 Gartner Magic Quadrant for the IT Service Desk:
Selection

Proof of concept

Delivery model

Acquisition

Customization

Foundation data

Test

Training

Data migration

Go-live

 PinkVERIFY (http://www.pinkelephant.com/pinkverify) Early life support

PIR and improvement

 OGC: The ITIL Software Scheme
(http://www.itil-officialsite.com/SoftwareScheme/ITILSoftwareScheme.aspx)

16 © 2011 – CFN People A/S

 Selection of tool and vendor
Selection of tool and vendor

Tool architecture

 Selection criteria. E.g.: Project set-up

 Functional coverage – utility (out of the box, configuration, Requirements

customization) Selection
 Non-functional fit (Delivery models, warranties, architecture
Proof of concept
fit, integration options, geographical support, language and
time-zone support etc.) Delivery model

 Cost (investment/operating/upgrade, external/internal, Acquisition

product/training) Customization
 Risk (Vendor (profile, credentials, presence, partners) and
Foundation data
product)
 Business opportunities Test

 Evaluate existing tools (upgrade, consolidate, replace) Training

Data migration
 Request for Information (RfI)
Go-live
 Request for Proposal (RfP)
Early life support
 Customer reference visits
PIR and improvement
 Proof of concept
 Decision
17 © 2011 – CFN People A/S
 Selection of tool and vendor
Selection of tool and vendor

Tool architecture

Project set-up

Requirements

Product 1 Product 2 Product 3 Product 4 Selection

Product Proof of concept

Functionality
Delivery model
Product Risk
Acquisition
Vendor Risk

Product Cost Customization

Non-functional Foundation data

requirements
Test

Training
Relative vendor and tool
ranking Data migration
Good
Go-live
Reasonable
Bad Early life support

PIR and improvement

18 © 2011 – CFN People A/S

 Proof of Concept
Tool architecture

 You cannot cover everything. Concentrate on: Project set-up

Proof of Concept

Requirements
 Key functionality – e.g. Search capabilities, reporting, use of
Selection
CMS data for impact analysis in all other processes, use of
SLA information to manage performance Proof of concept

 High risk areas – e.g. Integration to other products Delivery model

Acquisition
 New functionality – e.g. Service Portfolio Management and
Service Packaging Customization

Foundation data
 Prepare well
Test
 Define use cases
Training
 Agree preconditions and critical success criteria Data migration

 Approve or reject result Go-live

Early life support

 Get access to the tool!!!!
PIR and improvement
 Let the vendors do the work!

19 © 2011 – CFN People A/S

 Sourcing options
Tool architecture

Delivery model Use Software Operation and Project set-up

ownership maintanance Requirements
Delivery model

Selection

In-house My company My company My company Proof of concept

Delivery model
Outsourcing My company My company Third-party
Acquisition
Cloud My company Third-party Third-party
Customization

Impacts: Foundation data

 Cost Test

 Risk (continuity, security, availability, performance etc.) Training

 Flexibility Data migration
 Ease of integration Go-live
 Tool governance and requirements to management
Early life support
 Access to resources and skills
PIR and improvement
 Quality management and control
 ...
20 © 2011 – CFN People A/S
 Negotiation and acquisition
Negotiation and acquisition

Tool architecture

 Keep negotiating with more than one vendor as long as Project set-up

possible – but be reasonable, as negotiations are costly to Requirements

all parties Selection

 Identify and isolate high-risk areas and areas of disputes Proof of concept

as soon as possible. Settle all other areas with a letter of Delivery model

intent or alike Acquisition

 Obtain detailed solutions and price options for high-risk Customization

areas Foundation data

 Ask for alternative scenarios and trust that the vendor has Test

more experience with their product than you have Training

 Focus on your requirements and processes – let the Data migration

vendor suggest the solutions Go-live

 Be open to change your mind if the suggested solutions Early life support

from the vendor make more sense than your processes PIR and improvement
and practices

21 © 2011 – CFN People A/S

Configuration and customization
Configuration and customization
Tool architecture

 Make a clear definition of “configuration” and Project set-up

“customization” and agree with the vendor, e.g.: Requirements

Selection
 By “configuration” is meant modifications that can be made
solely by changing parameters or data. Configurations must Proof of concept

be automatically transferred to new versions and releases Delivery model

without further intervention
Acquisition

 By “customization” is meant modifications and extensions Customization

that requires bespoke code or changes to parameters or
Foundation data
data that require involvement of IT professionals
Test
 Try to go-live without customizations and then assess if Training
the need still exists after 3-6 months
Data migration

 Create “micro” business cases for each customization to Go-live

enforce the stakeholders to justify each and every Early life support
customization. PIR and improvement

 Let the steering committee approve or reject all

customizations
22 © 2011 – CFN People A/S
 Establishing foundation data
Establishing foundation data

Tool architecture

 Automate the capture and maintenance of foundation data where Project set-up

reasonable Requirements

 Typical foundation data: Selection

 Companies, daughters, third parties
Proof of concept
 Organization, business units, sections, departments, groups
Delivery model
 Locations, regions, sites, affiliates
 Cost centers, cost models, charging models Acquisition

 People, IDs, roles, skills, permissions Customization

 Support groups, assignment rules
Foundation data
 Categories
Test
 Priorities
 Services, CI-types and relations, CIs Training

 Service levels, service hours, support hours Data migration

 Service catalogues Go-live
 Notification rules, escalation rules
Early life support
 Process models, Service request models, Incident models, Change
models, standard changes PIR and improvement

 Etc.

23 © 2011 – CFN People A/S

 To test or not to test – that’s the question!
Tool architecture

 Determine test strategy, scope, level and plan (ref. ST 4.5): Project set-up

Requirements
 Test all functionality?
Selection
 Regression testing?
Proof of concept
 Test changed functionality?
Test

Delivery model

 Test high-risk areas? Acquisition

Customization

Foundation data

Test
Users IT professionals Operation Maintenance
Training
 User acceptance  Installation test
test (based on  Test of deployment Data migration
requirement  Migration test
specification, use  Operation test Go-live
cases, test cases)  Back-up and
recovery test Early life support
 Usability test
(based on real life  Integration test PIR and improvement
situations)  Performance test
 Stress, load and
scalability test
24 © 2011 – CFN People A/S
 Process and tool training
Tool architecture

 Role based training Project set-up

 Service Desk agents Requirements

 nth level support and third parties (don’t forget!) Selection
 Process Managers – cross-record functionality
Training

Proof of concept
 Service Managers – service centered functionality
Delivery model
 Process and service owners
 Tool administrators – maintenance of process models and Acquisition
foundation data, e.g. CI domain administrator
Customization
 System administrators – system management and operation
Foundation data
 If end-users requires training, then redesign the tool!
Test
 Identify gaps between processes and tools. These require
special attention Training

 Training types Data migration

 Simulation (combine process and tool training) Go-live
 E-learning
Early life support
 Class room
PIR and improvement
 Gaming (not very useful for tool training)
 Consider certifying people in process and tool
25 © 2011 – CFN People A/S
 Data migration
Tool architecture

 A new tool is an excellent opportunity for clean-up!! Project set-up

Requirements
Data migration

 Different strategies for different records. Incidents?

Selection
Known Errors? Changes?
Proof of concept

Delivery model

Acquisition

Customization

Foundation data

Test

C.
Training
B.

Data migration

Go-live

Early life support

D. Automated migration
Old New PIR and improvement
tool C. Look up tool

26 © 2011 – CFN People A/S

 Go-live
Tool architecture

 Plan go-live, fall-back and verification Project set-up

Requirements
 Replace support pages, documents, processes etc.
Selection

 Big bang or phased approach Proof of concept

Go live

 One process domain at a time Delivery model

 Geographical phases Phase 2 Acquisition

Phase 1 Customization
 One service domain at a time
Pilot Foundation data
 Organizational phases
Test

 Find a time with low support volume Training

Data migration
 Don’t forget to celebrate
Go-live

Early life support

PIR and improvement

27 © 2011 – CFN People A/S

 Early life support
Tool architecture

 Don’t declare victory before the war is over Project set-up

Early life support

Requirements
 Prepare and provide early life support
Selection
 Support presence in the Service Desk Proof of concept

 Access to skilled subject matter experts Delivery model

 Coaching – caring guidance Acquisition

Customization
 Collect and communicate tips and tricks and workarounds
for known errors Foundation data

Test

Training

Data migration

Go-live

Early life support

PIR and improvement

28 © 2011 – CFN People A/S

 Post Implementation Review and improvement
Post implementation review

Tool architecture

 Plan a review and a release 3-9 months after go-live Project set-up

Requirements
 Error corrections
Selection
 Postponed customizations
Proof of concept
 New functionality Delivery model

Acquisition
1. Define what
you Customization
should measure
Foundation data
2. Define what
7. Implement Test
you
corrective action
can measure
Training
Vision, strategy
and goals Data migration

6. Present and Go-live

use 3. Gather the data
the information Early life support

PIR and improvement

5. Analyze the 4. Process the
data data

29 © 2011 – CFN People A/S

 What should you consider?

Typical weak areas:

Leaving the scene

 Integrated use of configuration information (Automated

impact assessment, enforcement of compliance
control, graphical access to configuration data etc.)
 Service Portfolio Management (Integration of the
Service Portfolio elements in the CMS and Service
Catalogues, multilevel packaging of services,
integrated investment analysis tools etc.)
 Search facilities (Automatic searches from all relevant
screens, continual update of search results,
replaceable search engine etc.)
 Integration (Seamless integration, configurable
integration facilities, locking functionality, etc.)

30 © 2011 – CFN People A/S

 What should you consider?

Service Portfolio
Leaving the scene

Service

Supporting Supporting Supporting

Service Service Service

Configuration Management System (CMS)

Capabilities Resources

Processes Organisation Knowledge

Controls Roles

Activities Functions

Boards

31 © 2011 – CFN People A/S

 What should you consider?
Service Service
Package
Portfolio
Leaving the scene

Core Service
service Level
Pipeline services Agreement
+ Customer 1
Service
Supporting
service
Catalogue

+
Service
Service
Level
Live services level Agreement
package
Core service
Core service

Enhancing service
Service
Enhancing service
Package
Market A
Service Service Service
Enabling service Package
Enabling service Catalogue Level
Agreement
Service
Package

Retired services +
Service
level
package

32 © 2011 – CFN People A/S

 What should you consider?

 Choose scalable solutions (number of processes, number

Leaving the scene

of users, transaction volumes etc.)

 Choose tools that can be integrated – even though you
don’t plan to integrate them now
 Focus on supporting or automating key activities of the
processes. A typical distribution:
 200,000 Service Requests
 60,000 Incidents
 4,000 Changes
 2,000 Problems
 Automate simple activities such as Service requests and
Standard changes first
 Use as much “out-of-the box” functionality as possible
 Only pay for the modules or parts of the tools that you
actually use
33 © 2011 – CFN People A/S
Contact

Christian F. Nissen
cfn@cfnpeople.com
 +45 40 19 41 45
www.cfnpeople.com

34 © 2011 – CFN People A/S