Intro
What is ITSM?
IT Service Management (ITSM) is a collection of best practice guidance used to design, deliver, manage and improve IT service delivery within an organisation.
Its aim is to strike a balance between consistency and practicality, by implementing optimised processes, organisation structure, skills and tooling to enable IT to run effectively.
ITSM Tools
When the early ITSM tools came to the market, they were essentially databases, with a slick front-end that delivered a “ticket tracking” capability
for incidents, problems and changes. As IT organisations develop ever more complex operating models, prompted by multi-supplier integration strategies (also referred to as Service Integration and Management (SIAM)), the reliance upon their ITSM tooling has increased significantly.
As user demands become more sophisticated, ITSM tool providers have expanded their tool functionality to include:
- Asset & Configuration Management
- Ticket Integration between ITSM Tools
- Integration with other systems (e.g. LDAP)
- Software Asset Management
- CMDB Visualisation
- User Request Portal
- “What-if” Analysis
- Complex Workflows
- Discovery
- Request Fulfilment
As a prospective buyer of a new ITSM tool, the array of choice and scope can be overwhelming. Against this complex backdrop, it is vital that organisations select the right tool for their needs.
10 Critical Success Factors
1. Take time to fully understand the functional requirements from all stakeholders
Many organisations often purchase a tool without defining their requirements.
Unsurprisingly, this results in tools being implemented that fail to meet the
expectations of the users. Functional requirements should be based upon the vision for how the organisation wants to work, not a narrow view of how they
operate today. Merely mapping existing functionality into a new tool will not bring about transformational change.
In order to define requirements it will be necessary to do two things:
- Reach consensus on the processes that the tool should support
- Ensure that representatives from process groups are involved in defining
requirements
It might be helpful to assign process owners and ensure that they capture input from their teams, particularly if their teams are geographically diverse.
In addition, don’t forget ancillary functional requirements such as data integration capability, web chat, password reset tools and user request portals, which may not be derived from a basic process workflow requirements set.
2. Ensure you state the non-functional requirements
In addition to a core set of functional requirements, you must also think about the non-functional elements.
Examples of these are:
- Compliance with industry frameworks (ISO 20000, Pink Verify, etc)
- The Architecture (e.g. Cloud, On Premise, etc)
- Performance
- Availability
- Reliability
- Security (particularly, relevant for cloud-based solutions)
- Maintainability
- “Look and feel”
- Vendor financial stability
- Product roadmap
- Ongoing support (user groups)
- Ease of tool configuration
- Ease of product version upgrade
- Contractual approach
- Financial / Licensing model
3. Don’t interview any vendors until you’ve defined your requirements
Many organisations begin by organising product demonstrations, even before
requirements have been captured and documented. This often leads to an unstructured and chaotic procurement process, whereby requirements are largely informed with a bias towards a given product’s capabilities. Whilst attending a trade show to establish a broad understanding of capability is definitely a good idea, engaging individual vendors should not be undertaken until requirements are documented.
4. Score the tool against your requirements
Develop a simple scoring model for your requirements. This will enable you to
objectively score the requirements, and enable direct comparison between tools. You may wish to apply a weighting to your most significant requirements, which could be derived from a MoSCoW analysis (Must Have, Should Have, Could Have, Would Have).
5. Consider the softer side
Whilst scoring methodologies and objective comparison are important, it is also advisable to consider the less tangible aspects of the tool selection.
Ask yourself:
- How easy is the vendor to deal with?
- How likely is the new tool to be used and adopted by technical resolver groups?
- How easy is the tool to work with?
6. Ensure the tool is subject to relevant assurance
All proposed ITSM tools should be subject to assurance by legal, risk and commercial teams within your organisation to ensure that they comply with local and industry standards. This is particularly relevant where tools are cloud-based, and where they are accessible through mobile devices.
7. Run Proof of Concept exercises against defined user stories
The development of “user stories” is a great way to determine alignment of a tool against a very specific set of requirements. A good user story has the following structure:
“As a <role>, I want <goal/desire>so that <benefit>”
In the context of ITSM tool requirements, an example of a good user story might be:
A Change Manager undertakes “what if” analysis on their configuration data, in order to determine the potential impact of a change prior to implementation. Carry out a “proof of concept” exercise, to
conduct testing against a defined set of user stories to determine the capabilities of the tool.
8. Conduct direct financial comparison
Tool service providers offer a bewildering array of capabilities within their product set, which can make it impossible to conduct a like-for-like comparison. It is therefore vital to ensure that the service provider’s responses
are provided in a modular format, preferably with an itemised breakdown. Also, ensure that the license term and numbers are comparable, so you can
produce an accurate business case that compares the various potential options.
9. Identify opportunities to consolidate or integrate existing tools
It may be possible to replace existing tools and therefore positively impact your financial assessment. For example, if you have a discovery tool, and your proposed ITSM tools have discovery capability, you may have the opportunity to retire this tool. Furthermore, consider that efficiency savings may be realised through the automation of manual tasks such as data entry between two tools. We always advise our clients to have ownership of the testing of tools in the context of an end-to-end process and organisational model.
10. Never accept the first quote!
Some tool vendors may be unwilling to negotiate, therefore in our experience, it is best to keep two or more vendors in the process. This can generate some competitive tension, and drive the best possible commercial outcome. Don’t be afraid to seek benchmarking advice from existing user groups, to understand the market rate for the services being procured.
Conclusion
Syniad IT can help with the procurement of your ITSM tooling.
We have been through this process many times, acting as trusted advisors to our customers, working on their behalf to provide:
- A structured procurement approach
- Requirements definition workshops
- Development of scoring and evaluation models
- Oversight and management of the procurement process
- Advice on commercial terms
- Selection and management of systems integration partners
- Management of the configuration phase
- Development and maintenance of the development roadmap
- Process definition
