It is relatively common to find a client where the ITSM tools in use have been configured so heavily as to render it useless or, in their words, ‘broken’.
The reasons cited for this vary but tend to follow the same common themes:
- A lack of change control and governance around the tool and its technical and functional ability – just because you can change something, doesn’t mean you should.
- A short-term siloed view with no understanding of the longer-term impact of making the changes to the configuration.
- Clients usually say the tool was not fit for purpose, but oftentimes they admit no process definition work was done in parallel.
This results in a tool no longer fit for purpose and unable to support current services or scale to meet future demands – which in turn creates a high level of frustration and stress amongst staff.
Other example scenarios include:
- Changing the way the organisation works in order to meet the process workflows of the tool does not always create a good fit – however, if the processes are redesigned to align with industry best practices and a flexible tool is chosen that is built on workflows that map to these industry processes – the outcome will likely be way more successful.
- Best practice guidance always advocates an adopt and adapt approach – but not to the point where the tool is unrecognisable or the process does not work – creating bottlenecks and inefficiencies.
- Changing the configuration so much means it is unlikely that the tool will be able to be upgraded to newer versions without losing all of the changes made.
- The tool becomes unrecognisable and is therefore unsupported and relies on the knowledge of those involved in the changes to maintain its stability. Which in turn creates a significant risk to internal capability.
- Old versions of tools don’t always allow for effective reporting, self-service portals, or integration with other tools.
Industry research has consistently shown that organisations tend to ‘rip out and replace’ ITSM tools every five years, which does not allow for the growth of the capability of the tool in alignment with business requirements.
Improving the tool usually involves an exercise to understand what the technical and functional requirements of the tool are, to identify any issues with internal processes, and to ensure that the tool facilitates automation of how the process should work.
Industry best practice provides guidance around how the processes should flow, but doesn’t often align with how the tool should be configured.
Doing both in tandem with an effective communication plan underpinning the project is the most effective way to engage with a successful tool implementation.