Skip to main content

Why Analytics and Automation Are Central to ITSM Transformation

Dennis Drogseth

In research done in 2015, Enterprise Management Associates (EMA) looked at changing patterns of IT service management (ITSM) adoption across a population of 270 respondents in North America and Europe. One of the standout themes that emerged from our findings was the need for the service desk to become a more automated and analytically empowered center of authority across IT as a whole. Rather than casting the service desk as a reactive, low-tech bastion of ineffective customer interaction, the data outlined requirements for a much more dynamic ITSM team — a team that could govern decision making and automate actions in dialog with operations, development, and business stakeholders.

A Little Context

The factors driving the need for analytics and automation in support of ITSM transformation were manifold. Here are just a few key points:

Outreach to the Enterprise – ITSM organizations enjoying investment and growth took on more responsibilities across line-of-business silos. Successful ITSM groups were also consolidating IT and non-IT service desks in terms of process and other efficiencies. Both of these requirements suggest enhanced levels of automation and superior analytic intelligence across a widening enterprise landscape.

Support for Cloud – Another key factor in ITSM team growth, “support for cloud” was also a reason for ITSM decline when it wasn’t forthcoming. When asked about unique cloud requirements, improved levels of IT process automation was ranked number one — tied with improved integrations with operations for more effective incident and problem management, which in itself requires better analytic awareness and more automated process workflows. Automation was also indicated in the next two priorities for managing cloud — more dynamic capabilities for capturing change interdependencies and improved levels of automation for provisioning and configuration.

Support for DevOps – A surprising 65% of our research respondents indicated some level of pre-existing support for development through the service desk, and an additional 16% had plans for integrated DevOps support. Top priorities included integrated workflows and scheduling, as well as active provisioning via configuration automation and a configuration management database (CMDB). Also critical were effective insights on application quality, usage, and value, which also require analytic investments.

Support for Mobile – 62% of respondents viewed mobile as “significantly” or “completely” impacting their ITSM strategies with strong priorities for integrated consoles for monitoring and optimizing a broad array of endpoints, which once again requires investments in superior levels of analytics and automation.

ITSM Analytic Priorities

Our research also delved more deeply into how and why analytics were valued. For instance, we saw that 69% viewed big data and analytics either as a resource shared between operations and the service desk or as primarily an ITSM requirement. When we asked for more specifics about how and why analytics could be used, we saw especially high marks for: analytics for incident/problem and availability management; analytics for IT governance in terms of efficiencies and effectiveness; and analytics for change management. In another question, respondents indicated top rankings for:

■ Analytics to promote superior decision making between ITSM and operations

■ Analytics to support superior decision making between ITSM and business stakeholders

■ Analytics that can draw from an ITSM knowledge base

■ Real-time predictive analytics

ITSM Automation Priorities

I often like to make the connection that the relationship between analytics and automation is a handshake between insight and speed. Just as speed without insight can lead to train wrecks, simply knowing what’s true without clear paths to accelerate action can lead to costly inefficiencies. When asked about functional priorities for ITSM, enhanced automation for self-service came in first place. Then, when we asked for specific priorities in change- and configuration-related automation, we saw the following priorities:

■ IT process automation or runbook

■ Systems configuration automation

■ Workflow between the service desk and operations

■ Storage and network configuration

■ Application provisioning (in general and for self-service)

■ Automation in support of assimilating cloud resources

■ Mobile and endpoint configuration

Success Factors

Perhaps not surprisingly, we saw that those who viewed themselves as “extremely successful” in their ITSM strategies were twice as likely to invest in advanced levels of automation for managing change as less successful groups. They were also more likely to promote higher levels of analytics across the board along with more unified approaches for endpoint management, cloud optimization, and superior levels of integration with operations and development.

So while there are other key game-changing technologies that play to ITSM transformation — most notably service modeling in the CMDB/CMS and application dependency mapping — our data indicates that analytics and automation reside at the very center of ITSM transformation. Perhaps then it’s not surprising that in our most recent research analytics and automation were shown to also be at the very heart of IT and digital transformation. And as we concluded with that research, analytics and automation are also the foundation for something even more important than technology itself — superior levels of dialog and community-building across IT and between IT and the business it serves.

The Latest

IT organizations have historically measured success by how quickly they can respond when something goes wrong. The entire discipline of Incident Management has been optimized around mean time to resolution, first-response SLAs and ticket closure rates. But new research suggests that even though this is a well-executed playbook, it's no longer enough to retain customers ...

Production incidents rarely announce themselves as database problems. They appear as slow transactions, timeouts, rising response times, or an application struggling under a workload it previously handled. APM provides an essential starting point. It can identify a slow transaction path, highlight an affected service, and show that a database dependency is consuming more time than expected. But identifying the database as part of the problem is not the same as explaining what is happening inside it ...

Cloud teams are under constant pressure to reduce spend without slowing development or increasing operational risk. They are deploying autoscalers, rightsizing workloads, enforcing resource requests, reviewing utilization dashboards, and building FinOps processes around cloud-native environments. Yet the results often disappoint ...

Ask most IT leaders about their biggest concern with AI and you'll hear the same answer: hallucinations ... Today, however, the conversation has shifted ... As organizations move beyond chatbots and experiments, they are increasingly deploying AI agents that perform multi-step tasks. These systems retrieve documents, query databases, call APIs, generate reports, write code, and make recommendations. The issue is not whether the model can reason. The issue is whether the organization can see, verify, and govern the decisions being made along the way ...

While organizations want to take control of their telemetry, building telemetry pipelines from scratch can be a very daunting, complicated task, even when leveraging open-source standards like OpenTelemetry. It requires specialized knowledge across distributed systems, data engineering, and security. This fragmented approach across systems causes higher operational costs; it puts a strain on resources and reduces efficiency as teams have to work with different interfaces and processes ...

For decades, enterprise networks were designed around a simple assumption: work happened inside the office. Applications lived in centralized data centers, employees connected through internal infrastructure, and security focused on protecting the perimeter that surrounded everything ... But the way organizations operate today bears little resemblance to that environment. Cloud platforms host critical applications, employees connect from homes and airports as often as they do from offices, and partners collaborate through shared systems that exist far beyond corporate walls. In short, the corporate network no longer resembles the environment it was designed to protect ...

As an analyst who researches how IT organizations design, build, and operate their networks, I find that network data is a constant source of pain. Network teams struggle with data quality, fragmentation, authority, access, and trust. And these issues undermine everything they try to do. Here are the numbers: Only 45% of network teams are completely confident in the accuracy of their network source of truth, which documents the intent of their network ...

The 2026 Global Data Center Survey from Uptime Institute reveals an industry navigating workforce constraints, escalating outage expenses, even as rising costs remain the top concern for management teams ...

The next observability gap may not be in the code. It may be under the rack. That sounds strange until you think about how AI incidents actually feel in the middle of an investigation ... The application dashboard may be accurate. It may also be stopping at the wrong boundary. AI systems depend on software, but they also depend on a dense physical stack: racks, power paths, thermal margin, maintenance activity and, in many environments, liquid cooling. Those physical dependencies can change slowly before they look like a software incident ...

Certificate expiration is the rare outage you can see coming. Every TLS certificate carries the date it stops working, so the moment it will begin breaking connections is knowable in advance. That's what makes an expired certificate such a frustrating way to lose a service. What's changing now is how often that date comes around ...

Why Analytics and Automation Are Central to ITSM Transformation

Dennis Drogseth

In research done in 2015, Enterprise Management Associates (EMA) looked at changing patterns of IT service management (ITSM) adoption across a population of 270 respondents in North America and Europe. One of the standout themes that emerged from our findings was the need for the service desk to become a more automated and analytically empowered center of authority across IT as a whole. Rather than casting the service desk as a reactive, low-tech bastion of ineffective customer interaction, the data outlined requirements for a much more dynamic ITSM team — a team that could govern decision making and automate actions in dialog with operations, development, and business stakeholders.

A Little Context

The factors driving the need for analytics and automation in support of ITSM transformation were manifold. Here are just a few key points:

Outreach to the Enterprise – ITSM organizations enjoying investment and growth took on more responsibilities across line-of-business silos. Successful ITSM groups were also consolidating IT and non-IT service desks in terms of process and other efficiencies. Both of these requirements suggest enhanced levels of automation and superior analytic intelligence across a widening enterprise landscape.

Support for Cloud – Another key factor in ITSM team growth, “support for cloud” was also a reason for ITSM decline when it wasn’t forthcoming. When asked about unique cloud requirements, improved levels of IT process automation was ranked number one — tied with improved integrations with operations for more effective incident and problem management, which in itself requires better analytic awareness and more automated process workflows. Automation was also indicated in the next two priorities for managing cloud — more dynamic capabilities for capturing change interdependencies and improved levels of automation for provisioning and configuration.

Support for DevOps – A surprising 65% of our research respondents indicated some level of pre-existing support for development through the service desk, and an additional 16% had plans for integrated DevOps support. Top priorities included integrated workflows and scheduling, as well as active provisioning via configuration automation and a configuration management database (CMDB). Also critical were effective insights on application quality, usage, and value, which also require analytic investments.

Support for Mobile – 62% of respondents viewed mobile as “significantly” or “completely” impacting their ITSM strategies with strong priorities for integrated consoles for monitoring and optimizing a broad array of endpoints, which once again requires investments in superior levels of analytics and automation.

ITSM Analytic Priorities

Our research also delved more deeply into how and why analytics were valued. For instance, we saw that 69% viewed big data and analytics either as a resource shared between operations and the service desk or as primarily an ITSM requirement. When we asked for more specifics about how and why analytics could be used, we saw especially high marks for: analytics for incident/problem and availability management; analytics for IT governance in terms of efficiencies and effectiveness; and analytics for change management. In another question, respondents indicated top rankings for:

■ Analytics to promote superior decision making between ITSM and operations

■ Analytics to support superior decision making between ITSM and business stakeholders

■ Analytics that can draw from an ITSM knowledge base

■ Real-time predictive analytics

ITSM Automation Priorities

I often like to make the connection that the relationship between analytics and automation is a handshake between insight and speed. Just as speed without insight can lead to train wrecks, simply knowing what’s true without clear paths to accelerate action can lead to costly inefficiencies. When asked about functional priorities for ITSM, enhanced automation for self-service came in first place. Then, when we asked for specific priorities in change- and configuration-related automation, we saw the following priorities:

■ IT process automation or runbook

■ Systems configuration automation

■ Workflow between the service desk and operations

■ Storage and network configuration

■ Application provisioning (in general and for self-service)

■ Automation in support of assimilating cloud resources

■ Mobile and endpoint configuration

Success Factors

Perhaps not surprisingly, we saw that those who viewed themselves as “extremely successful” in their ITSM strategies were twice as likely to invest in advanced levels of automation for managing change as less successful groups. They were also more likely to promote higher levels of analytics across the board along with more unified approaches for endpoint management, cloud optimization, and superior levels of integration with operations and development.

So while there are other key game-changing technologies that play to ITSM transformation — most notably service modeling in the CMDB/CMS and application dependency mapping — our data indicates that analytics and automation reside at the very center of ITSM transformation. Perhaps then it’s not surprising that in our most recent research analytics and automation were shown to also be at the very heart of IT and digital transformation. And as we concluded with that research, analytics and automation are also the foundation for something even more important than technology itself — superior levels of dialog and community-building across IT and between IT and the business it serves.

The Latest

IT organizations have historically measured success by how quickly they can respond when something goes wrong. The entire discipline of Incident Management has been optimized around mean time to resolution, first-response SLAs and ticket closure rates. But new research suggests that even though this is a well-executed playbook, it's no longer enough to retain customers ...

Production incidents rarely announce themselves as database problems. They appear as slow transactions, timeouts, rising response times, or an application struggling under a workload it previously handled. APM provides an essential starting point. It can identify a slow transaction path, highlight an affected service, and show that a database dependency is consuming more time than expected. But identifying the database as part of the problem is not the same as explaining what is happening inside it ...

Cloud teams are under constant pressure to reduce spend without slowing development or increasing operational risk. They are deploying autoscalers, rightsizing workloads, enforcing resource requests, reviewing utilization dashboards, and building FinOps processes around cloud-native environments. Yet the results often disappoint ...

Ask most IT leaders about their biggest concern with AI and you'll hear the same answer: hallucinations ... Today, however, the conversation has shifted ... As organizations move beyond chatbots and experiments, they are increasingly deploying AI agents that perform multi-step tasks. These systems retrieve documents, query databases, call APIs, generate reports, write code, and make recommendations. The issue is not whether the model can reason. The issue is whether the organization can see, verify, and govern the decisions being made along the way ...

While organizations want to take control of their telemetry, building telemetry pipelines from scratch can be a very daunting, complicated task, even when leveraging open-source standards like OpenTelemetry. It requires specialized knowledge across distributed systems, data engineering, and security. This fragmented approach across systems causes higher operational costs; it puts a strain on resources and reduces efficiency as teams have to work with different interfaces and processes ...

For decades, enterprise networks were designed around a simple assumption: work happened inside the office. Applications lived in centralized data centers, employees connected through internal infrastructure, and security focused on protecting the perimeter that surrounded everything ... But the way organizations operate today bears little resemblance to that environment. Cloud platforms host critical applications, employees connect from homes and airports as often as they do from offices, and partners collaborate through shared systems that exist far beyond corporate walls. In short, the corporate network no longer resembles the environment it was designed to protect ...

As an analyst who researches how IT organizations design, build, and operate their networks, I find that network data is a constant source of pain. Network teams struggle with data quality, fragmentation, authority, access, and trust. And these issues undermine everything they try to do. Here are the numbers: Only 45% of network teams are completely confident in the accuracy of their network source of truth, which documents the intent of their network ...

The 2026 Global Data Center Survey from Uptime Institute reveals an industry navigating workforce constraints, escalating outage expenses, even as rising costs remain the top concern for management teams ...

The next observability gap may not be in the code. It may be under the rack. That sounds strange until you think about how AI incidents actually feel in the middle of an investigation ... The application dashboard may be accurate. It may also be stopping at the wrong boundary. AI systems depend on software, but they also depend on a dense physical stack: racks, power paths, thermal margin, maintenance activity and, in many environments, liquid cooling. Those physical dependencies can change slowly before they look like a software incident ...

Certificate expiration is the rare outage you can see coming. Every TLS certificate carries the date it stops working, so the moment it will begin breaking connections is knowable in advance. That's what makes an expired certificate such a frustrating way to lose a service. What's changing now is how often that date comes around ...