IT Service Management tool architecture Project set-up Definition of requirements Selection of tool and vendor 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

1. IT Service Management tools
- Acquisition and implementation
Christian F. Nissen, CFN Consult
RESILIATM, ITIL®, PRINCE2® MSP®, MoP® and MoV® are Registered Trade Marks of AXELOS 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 and IT4ITTM are trademarks of The Open Group
SIAM® is a registered trademark of EXIN
© 2018 of CFN Consult unless otherwise stated

2. Three P’s
2
Themagictriangle
© 2015

3. Agenda
 IT Service Management tool architecture
 Project set-up
 Definition of requirements
 Selection of tool and vendor
 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
Agenda
3 © 2018

4. Typical IT Service Management tools
IT Service Management
suites
 Workflow management
 Portfolio and contract
management
 Integrated
configuration
management
 Self-service
Administrative and
analytical tools
 Analysis, simulation
and modeling
 Reporting and
dashboard
IT Infrastructure
Management tools
 Monitoring
 Event logging and
management
 Diagnostic utilities
 Job scheduling
 Automation
 Discovery
 Remote control
 Security control
4
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
ITSMtoolarchitecture
© 2018

5. Typical IT Service Management tools
Software and Application
Management tools
 Release management
and version control
 Test and validation
management
 Deployment
management
 License management
5
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
ITSMtoolarchitecture
© 2018

6. “Software suite” or “Best of breed”?
6
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
ITSMtoolarchitecture
Best of breed:Software suite:
Workflow
CMS
Monitoring
Vendor 1
Vendor 3
Vendor 2
Self-service portal
Vendor 5 Vendor 6
Job scheduleDash-board
Vendor 4
“All” included
One vendor
© 2018

7. “Software suite” or “Best of breed”?
7
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
ITSMtoolarchitecture
Source: http://na-ab10.marketo.com/rs/032-SYX-996/images/theme-functions%20%281%29.png
© 2018

8. Tool architecture in a multi-sourcing environment
8
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
ITSMtoolarchitecture
Configuration data?
Customer User Service Desk Infrastructure
Management
Application
Management
Ordered Company 1 Company 2 Company 3
Scenario 1
Share
Owns tool A
Uses tool A
Operates tool A
Uses tool A
Uses tool A
Scenario 2
Separate
Accesses tool A Owns tool A
Uses tool A
Owns tool C
Uses tool C
Scenario 3
Integrate
Owns/operates/uses
tool A
Owns/operates/uses tool
B
Owns/opera-
tes/uses tool C
Scenario 4
Meet
Uses shared tool A
in (a private) cloud
Uses shared tool A in (a
private) cloud
Uses shared
tool A in (a
private) cloud
© 2018

9. Integration to other ITSM tools or data sources
 What to synchronize?
 Which selection criteria?
 When to synchronize?
 Which way?
 How to synchronize?
 Notifications and e-mail?
 How to handle update conflicts?
 Error handling?
 Preconditions
 Capacity and Performance?
 Incidents? Work orders?
Solutions? CIs? Etc.?
 Specific organization units?
Services? CIs? Support
groups?
 Status change? Each time
the record is changed?
Closure? Specific trigger?
 One way? Two ways?
 Full record? Fields? Function
of other fields?
 Cross-site notifications? E-
mails with links?
 Lock record? Master/slave?
 Queuing? Close system?
 Shared foundation data?
Shared categories, priorities,
SLAs etc?
 Volumes? Cascade effect?
9
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
ITSMtoolarchitecture
© 2018

10. 10
Relations to other tools and repositories
ITSMtoolarchitecture
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
© 2018

11. 11
Relations to other tools and repositories
ITSMtoolarchitecture
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
© 2018

12. Project governance - example
12
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
Projectset-up
 Business case?
 Who approves requests for customization?
 Tool and process governance?
 Vendor involvement?
 Implementation, operational and maintenance partners?
© 2018

13. How to approach requirement specification?
13
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
Definitionofrequirements
Big bang design
- Define all requirements at once
Big bang
implemen-
tation
Phased
implemen-
tation
Agile
implemen-
tation
Phased design
- Define requirements one part at a time
Phased
implemen-
tation
Agile
implemen-
tation
Agile design
- Define requirements as you go
Agile implementation
© 2018

14. How to specify requirements?
Approaches:
 Out-of-the box (request the vendor’s user guides and
system and administration documentation)
 Use cases based on your processes (request the vendors
process documentation – but be aware that some of them
provide processes that don’t match their own tool)
 Traditional requirement specification
Combinations of the above
Sources for requirements:
 PinkVERIFY (http://www.pinkelephant.com/pinkverify)
 Axelos: The ITIL Software Scheme
(https://www.axelos.com/itil-software-scheme)
14
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
Definitionofrequirements
© 2018

15. Use cases
15
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
Definitionofrequirements
© 2018

16. Traditional requirement specification
16
Definitionofrequirements
Vendor response
ID Requirement Priority:
1=MUST
2=SHOULD
3=COULD
4=WANT
Degree of
fulfilment
of the
requireme
nt from 0-
100% out
of the box
Degree of
fulfilment
of the
requiremen
t from 0-
100% if
configurati
on is
required
Degree of
fulfilment
of the
requiremen
t from 0-
100% if
customizati
on is
required
Fulfilment
through
configuration:
If the
requirement is
not completely
fulfilled out-of-
the-box please
explain WHAT
functionality that
can be provided
through
configuration
and HOW.
Fulfilment
through
customization:
If the
requirement is
not completely
fulfilled out-of-
the-box please
explain WHAT
functionality
that can be
provided
through
customization
and HOW.
Cost of
configuratio
n:
If the
requirement
is not
completely
fulfilled out-
of-the-box
please
provide the
cost of 100%
fulfilment
through
configuratio
n in EUR
Cost of
customizatio
n:
If the
requirement
is not
completely
fulfilled out-
of-the-box
please
provide the
cost of 100%
fulfilment
through
customisatio
n including 5
years
subsequent
operational
costs in EUR
General
comments:
Provide
general
comments
such as
dependencie
s to other
requirements
, etc.
Alternative
solution:
If adequate,
specify an
alternative
solution
Demand Management - Define Service Level
Packages
12.16 Must be possible to make a Service Level Package
template to be reused eachtime 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.
1
12.17 Service Level Packages must at minimum contain the
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
1
12.18 Must be possible to capture and describe Service
Level Objectives in the tool and include these in
Service Level Packages
1
© 2018

17. A few commercial sources for tool selection
 Gartner Magic Quadrant for the IT Service Desk:
 PinkVERIFY (http://www.pinkelephant.com/pinkverify)
 Axelos: The ITIL Software Scheme
(https://www.axelos.com/itil-software-scheme)
17
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
Selectionoftoolandvendor
© 2018

18. Selection of tool and vendor
 Selection criteria. E.g.:
 Functional coverage – utility (out of the box, configuration,
customization)
 Non-functional fit – warranty (Delivery models, warranties,
architecture fit, integration options, geographical support,
language and time-zone support etc.)
 Cost (investment/operating/upgrade, external/internal,
product/training)
 Risk (Vendor (profile, credentials, presence, partners) and
product)
 Business opportunities
 Evaluate existing tools (upgrade, consolidate, replace)
 Request for Information (RfI)
 Request for Proposal (RfP)
 Customer reference visits
 Proof of concept
 Decision
18
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
Selectionoftoolandvendor
© 2018

19. Product 1 Product 2 Product 3 Product 4
Product Utility
Product Risk
Vendor Risk
Product Cost
Product Warranty
Short listing of tool and vendor
19
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
Selectionoftoolandvendor
Good
Reasonable
Bad
Relative vendor and tool
ranking
© 2018

20. Proof of Concept
 You cannot cover everything. Concentrate on:
 Key functionality – e.g. Search capabilities, reporting, use of
CMS data for impact analysis, use of SLA information to
manage performance
 High risk areas – e.g. Integration to other products
 New functionality – e.g. Service Portfolio Management and
Service Packaging
 Prepare well
 Define use cases
 Agree preconditions and critical success criteria
 Approve or reject result
 Get access to the tool!!!!
 Let the vendors do the work!
20
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
ProofofConcept
© 2018

21. Sourcing options
Impacts:
 Cost
 Risk (continuity, security, availability, performance etc.)
 Flexibility
 Ease of integration
 Tool governance and requirements to management
 Access to resources and skills
 Quality management and control
 . . .
21
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
Deliverymodel
Delivery model Use Software
ownership
Operation and
maintanance
In-house My company My company My company
Outsourcing My company My company Third-party
Cloud My company Third-party Third-party
© 2018

22. Negotiation and acquisition
 Keep negotiating with more than one vendor as long as
possible – but be reasonable, as negotiations are costly to
all parties
 Identify and isolate high-risk areas and areas of disputes
as soon as possible. Settle all other areas with a letter of
intent or alike
 Obtain detailed solutions and price options for high-risk
areas
 Focus on your requirements and processes – let the
vendor suggest the solutions
 Be open to change your mind if the suggested solutions
from the vendor make more sense than your processes
and practices
22
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
Negotiationandacquisition
© 2018

23. Configuration vs. customization
 Make a clear definition of “configuration” and
“customization” and agree with the vendor, e.g.:
 By “configuration” is meant modifications that can be made
solely by changing parameters or data. Configurations must
be automatically transferred to new versions and releases
without further intervention
 By “customization” is meant modifications and extensions
that requires bespoke code or changes to parameters or
data that require involvement of IT professionals
 Try to go-live without customizations and then assess if
the need still exists after 3-6 months
 Create “micro” business cases for each customization to
enforce the stakeholders to justify each and every
customization.
 Let the steering committee approve or reject
customizations
23
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
Configurationvs.customization
© 2018

24. Establishing foundation data
 Automate the capture and maintenance of foundation data where
reasonable
 Typical foundation data:
 Companies, daughters, third parties
 Organization, business units, sections, departments, groups
 Locations, regions, sites, affiliates
 Cost centers, cost models, charging models
 People, IDs, roles, skills, permissions
 Support groups, assignment rules
 Categories
 Priorities
 Services, CI-types and relations, CIs
 Service levels, service hours, support hours
 Service catalogues
 Notification rules, escalation rules
 Process models, Service request models, Incident models, Change
models, standard changes
 Etc.
 Etc.
24
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
Establishingfoundationdata
© 2018

25. To test or not to test – that’s the question!
 Determine test strategy, scope, level and plan (ref. ST 4.5):
 Test all functionality?
 Regression testing?
 Test changed functionality?
 Test high-risk areas?
25
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
Test
Users IT professionals Operation Maintenance
 User acceptance
test (based on
requirement
specification, use
cases, test cases)
 Usability test
(based on real life
situations)
 Installation test
 Test of deployment
 Migration test
 Operation test
 Back-up and
recovery test
 Integration test
 Performance test
 Stress, load and
scalability test
© 2018

26. Process and tool training
 Role based training
 Service Desk agents
 nth level support and third parties (don’t forget!)
 Process Managers – cross-record functionality
 Service Managers – service centered functionality
 Process and service owners
 Tool administrators – maintenance of process models and
foundation data, e.g. CI domain administrator
 System administrators – system management and operation
 If end-users requires training, then redesign the tool!
 Identify gaps between processes and tools. These require
special attention
 Training types
 Simulation (combine process and tool training)
 E-learning
 Class room
 Gaming (not very useful for tool training)
 Consider certifying people in process and tool
26
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
Training
© 2018

27. Data migration
 A new tool is an excellent opportunity for clean-up!!
 Different strategies for different records. Incidents?
Known Errors? Changes?
27
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
Datamigration
New
tool
Old
tool
B.
D. Automated migration
C. Look up
C.
© 2018

28. Go-live
 Plan go-live, fall-back and verification
 Replace support pages, documents, processes etc.
 Big bang or phased approach
 One process domain at a time
 Geographical phases
 One service domain at a time
 Organizational phases
 Find a time with low support volume
 Don’t forget to celebrate
28
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
Golive
Pilot
Phase 1
Phase 2
© 2018

29. Early life support
 Don’t declare victory before the war is over
 Prepare and provide early life support
 Support presence in the Service Desk
 Access to skilled subject matter experts
 Coaching – caring guidance
 Collect and communicate tips and tricks and workarounds
for known errors
29
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
Earlylifesupport
© 2018

30. Post Implementation Review and improvement
 Plan a review and a release 3-9 months after go-live
 Error corrections
 Postponed customizations
 New functionality
30
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
Postimplementationreview
© 2018

31. 31
What should you consider?
 Typical weak areas:
 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.)
Leavingthescene
© 2018

32. 32
What should you consider?
 Choose scalable solutions (number of processes, number
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
Leavingthescene
© 2018

33. Questions and comments
33 © 2018
Leavingthescene

34. Contact
34
Christian F. Nissen
cfn@cfnconsult.dk
+45 40 19 41 45
CFN Consult ApS
Linde Allé 1
DK-2600 Glostrup
CVR: 39 36 47 86
© 2018