IT Service Management tools - Acquisition and implementation

Transcription

1 IT Service Management tools - and implementation Christian F. Nissen, CFN People A/S ITIL and PRINCE2 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) TOGAF TM is a trademark of The Open Group of CFN People a/s unless otherwise stated

2 The magic triangle Three P s 2

3 Agenda Agenda 3 IT Service Management tool architecture Definition of requirements of tool and vendor Negotiation and acquisition Configuration and customization Establishing foundation data Post implementation review and improvement

4 ITSM tool architecture Typical IT Service Management tools IT Service Management suites IT Infrastructure Management tools Workflow management Monitoring Portfolio and contract management Event logging and management Integrated configuration management Self-service Administrative and analytical tools Analysis, simulation and modeling Diagnostic utilities Job scheduling Automation Discovery Remote control Security control Reporting and dashboard 4

5 ITSM tool architecture Typical IT Service Management tools Software and Application Management tools Release management and version control and validation management Deployment management License management 5

6 ITSM tool architecture Software suite or Best of breed? Software suite: Best of breed: Vendor 1 Workflow Vendor 2 Self-service portal One vendor All included Vendor 3 Vendor 4 Monitoring CMS Dash-board Vendor 5 Vendor 6 Job schedule 6

7 ITSM tool architecture in a multi-sourcing environment Customer User Service Desk Infrastructure Management Application Management Ordered Company 1 Company 2 Company 3 Scenario 1 Share Scenario 2 Separate Owns tool A Uses tool A Accesses tool A Operates tool A Uses tool A Owns tool A Uses 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/operates/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 7 Configuration data?

8 ITSM tool architecture Integration to other ITSM tools or data sources What to synchronize? Which selection criteria? Incidents? Work orders? Solutions? CIs? Etc.? Specific organization units? Services? CIs? Support groups? When to synchronize? Which way? Status change? Each time the record is changed? Closure? Specific trigger? One way? Two ways? How to synchronize? Notifications and ? How to handle update conflicts? Error handling? Preconditions 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? 8 Capacity and Performance? Volumes? Cascade effect?

9 ITSM tool architecture Relations to other tools and repositories 9

10 Project governance - example Business case? Who approves requests for customization? Tool and process governance? Vendor involvement? Implementation, operational and maintenance partners? 10

11 Definition of requirements How to approach requirement specification? Big bang design - Define all requirements at once Big bang implementation Phased design - Define requirements one part at a time Phased implementation Phased implementation Agile design - Define requirements as you go Agile implementation Agile implementation Agile implementation 11

12 Definition of requirements 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 ( Axelos: The ITIL Software Scheme ( 12

13 Definition of requirements Use cases 13

14 Definition of requirements Traditional requirement specification ID Requirement Priority: Demand Management - Define Service Level Packages Must be possible to make a Service Level Package template to be reused eachtime a new service offering is being created. 1=MUST 2=SHOULD 3=COULD 4=WANT 1 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-ofthe-box please explain WHAT functionality that can be provided through configuration and HOW. Vendor response Fulfilment through customization: If the requirement is not completely fulfilled out-ofthe-box please explain WHAT functionality that can be provided through customization and HOW. Cost of configuratio n: If the requirement is not completely fulfilled outof-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 outof-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 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 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 Must be possible to capture and describe Service Level Objectives in the tool and include these in Service Level Packages

15 of tool and vendor A few commercial sources for tool selection Tool selector ( Gartner Magic Quadrant for the IT Service Desk: PinkVERIFY ( Axelos: The ITIL Software Scheme ( 15

16 of tool and vendor of tool and vendor criteria. E.g.: Functional coverage utility (out of the box, configuration, customization) Non-functional fit warranty (s, 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 Decision 16

17 of tool and vendor Short listing of tool and vendor Product 1 Product 2 Product 3 Product 4 Product Utility Product Risk Vendor Risk Product Cost Product Warranty Relative vendor and tool ranking Good Reasonable Bad 17

18 Proof of Concept 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! 18

19 Sourcing options Use Software ownership Operation and maintanance 19 In-house My company My company My company Outsourcing My company My company Third-party Cloud My company Third-party Third-party 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...

20 Negotiation and acquisition 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 20

21 Configuration vs. customization Configuration vs. customization 21 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

22 Establishing foundation data Establishing foundation data 22 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.

23 To test or not to test that s the question! Determine test strategy, scope, level and plan (ref. ST 4.5): all functionality? Regression testing? changed functionality? high-risk areas? 23 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 of deployment Migration test Operation test Back-up and recovery test Integration test Performance test Stress, load and scalability test

24 Process and tool training Role based training Service Desk agents n th 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 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 24

25 B. A new tool is an excellent opportunity for clean-up!! Different strategies for different records. Incidents? Known Errors? Changes? C. Old tool D. Automated migration C. Look up New tool 25

26 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 Pilot Find a time with low support volume Phase 2 Phase 1 Don t forget to celebrate 26

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

28 Post implementation review Post Implementation Review and improvement Plan a review and a release 3-9 months after go-live Error corrections Postponed customizations New functionality 28

29 Leaving the scene 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.) 29

30 Leaving the scene What should you consider? 30 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

31 Contact Christian F. Nissen