Somewhere in the history of the ITSM industry, IT directors around the world were led to believe that buying a ‘all-in-one’ ITSM toolset was going to solve all their problems.
From providing high-quality service desk interactions and meeting every SLA, to totally automated self-service and thriving knowledge bases full of ‘answers’. ITSM tools and ITIL were the gold standard solution IT had been waiting for.
So where does that leave us now?
Well, most IT teams know now that great ITSM comes from a well-managed balance of talented people, well defined processes and a range of tools that support organisation’s operations. But we have been left with the hangover of heavy on-size-fits-all ITSM tools.
We have also seen a huge rise in SIAM and complex multi-vendor IT environments. These supplier led strategies for managing large and complex services are highly effective, drive down operating costs and create modern and mature service outcomes. However, it also presents a number of technology-based challenges, especially for those departments living with ITSM tools and processes that are seemingly incompatible with those of their suppliers and third parties.
The reaction to this scenario is often to try and claim the ITSM toolset, which is already in place as the ‘single-source-of-truth’ across the whole ecosystem or supply chain. This sort of federating of software can seem sensible at the time, but is raft with difficult to manage consequences.
The reality is that different tools will provide different sets of contradicting data. People will not manually update tickets across multiple systems, no matter how many processes you write to ensure they do. And, coded integrations (even with modern APIs) will be fragile, unreliable and inflexible.
When these problems occur, the instinctive response is to blame the tool at the heart of it all. The next step from there is often to replace that tool, with a similar or almost exactly the same tool... Maybe it has nice UI, maybe it is easier to use or maybe it has a simpler to use API. But this will never solve the problem, because the problem was actually deeply set inside the decision to centralise everything around one toolset in the first place.
What’s the answer?
Most of the answers lie within creating transparency across the whole system. Putting intelligent tooling between all the existing systems; which manage the exchange of data for you, and of course, to focus on what is already working well for each party/supplier and enable them to keep doing it.
I believe that service buyers, providers and suppliers alike should all be able to keep and maintain the use of their own tools and processes. Managing tickets in the way they want to; escalating issues using processes that suit their own team organisation. And, to deliver service improvements that are both meaningful to them and holistically beneficial to their whole service ecosystem.