Enterprise service management (ESM) systems and tools provide a way to manage IT operations, with specific functions for managing services, performance monitoring, billing and accounting, help desk ticketing and incident tracking. ESM has emerged as a new approach to IT management over recent years as organizations look for ways to improve how they support applications and users.
What happens when you take your entire IT workflow environment and bring it under one management umbrella? It sounds like a great idea, doesn’t it? And, in many cases, it is. But there are limitations with traditional ESMs that may only become apparent after you start implementing.
My friend is a primary school teacher and he says to his students "you get what you get, and you don't get upset".
This is true of traditional ESM solutions because you have no flexibility to define your own business rules and workflow. Your IT module may have a rich ITIL feature set, but your Facilities module is probably just a simple ticketing workflow with an icon of a building. Ditto with HR, Finance, Field Services, all identical, simple workflows but with different icons.
The lack of flexibility means you have to dumb down your business unit workflows to fit the limitations of the tool. Putting a set of workflows in the governance of a ticketing system may be a good initial step, but it is typically a stage that is outgrown.
DevOps is becoming an increasingly important part of enterprise IT. The idea behind DevOps is simple—by sharing knowledge between software developers and IT operations, companies can collaborate to design systems that are easier to implement, support and maintain. As a result, both parties will be able to focus on what they do best while also ensuring maximum productivity and efficiency across all areas of IT.
For ESM, it is typically the ITSM component that interacts with DevOps and many ESM solutions have a relatively mature ITSM component. So far so good.
The challenge arises when DevOps workflows interface with advanced ITIL processes like Problem and Change Management. Lack of flexibility around these processes can make it hard to get the ESM/DevOps interfaces and workflows to match the organization's business processes. Lack of visibility, lack of rich data structures, lack of flexible approval structures are typical.
The reality of traditional ESM systems is that when you scratch the surface of the "single enterprise console" you find it is just a front end for separate and siloed ticketing instance, one for each department. They may come from the same vendor and have the same look and feel, but that is where the integration ends. Typically "enterprise workflows" are achieved by these different instances emailing tickets to each other.
The challenge with this is that you don't get a single workflow platform and a single system of record. This makes it difficult to track work across these instances and know the current location and status of a ticket. Suppose a request was raised in HR and handed off to Finance. After the handoff HR has no visibility into the progress, status and performance of of that workflow.
Furthermore, there is no ability to do top-down reporting on the performance of end-to-end workflows in terms of where things are getting stuck, how much time and effort each ticket classification is requiring, whether tickets are meeting end-to-end SLA performance targets as well as intra-business targets.
This makes it very challenging to assess workflow performance and prioritise continuous improvement efforts.
Beware vendors who say they have a "platform" approach. Go beyond adding a custom table, or a custom field, and ask them to demonstrate how you create a new workflow across different business units, how you do complex SLAs and complex approvals, and how you report on end-to-end status and performance.
And make sure that this can be done by you (without back-end vendor development) in a way that is fast, simple and low-code.
When you combine rigid ticketing modules with simplistic and clunky cross-silo integration capability, you end up with a system that imposes serious constraints on your ability to wire up your organization's business processes without crippling them.
Again, this may not be apparent in the initial stages of deployment (after all simple siloed ticketing is still better than email and phone calls). But before too long the constraints on your organization's digital agility may emerge. You will want to integrate enterprise data systems but may not be able to enrich tickets with their contextual data across silos. You may want to manage processes end-to-end across your enterprise but you won't have the visibility. And you won't have a single pane of glass for your enterprise's operational workflow performance.
The recommendations are simple.
Armed with the distinctions discussed above, interrogate your prospective ESM vendor on these points:
• Does your tool have a single data model?
• Can I configure cross-departmental workflows with complex business logic, rich SLA and approval models, based on the shared data model?
• Can I track SLAs and report status and performance of cross-departmental workflows?
• Is it all fast, easy and low-code?
• Can I do all this myself without requiring the vendor to do back-end development?
Once you have the answers, consider what the implications are on your organization's digital transformation strategy and your tools modernization/consolidation roadmap. Traditional ESM has attractive points but the hidden pitfalls may make it a liability for your transformation agenda.