Three Teams. Three Open Tickets. One Problem Nobody Connected.
Incident management, problem management, and change management are designed to work together as a system. In most organizations, they work alongside each other — similar goals, shared data, zero integration. The result is the same problem being worked by three teams in three directions simultaneously. CSDM is what connects them.
A Wednesday That Proved Three Processes Can Fail Simultaneously
Wednesday, 2:18 p.m. The service desk opens Incident INC0047821: the case management portal is responding slowly. The team assigns it to the application team, notes the affected CI as the portal application server, and begins triage.
Wednesday, 2:24 p.m. The problem management team closes out a recurring problem record they've been investigating for three weeks — PRB0003104, "intermittent latency on the document processing queue." After analysis, they've attributed it to "network congestion, likely external." The record is resolved with no corrective action taken.
Wednesday, 2:31 p.m. A change manager reviews and approves RFC0091445: a routine update to the shared authentication service, scheduled for Thursday morning. The risk is scored as medium. There are no holds.
By Thursday afternoon, all three of those decisions look different. The Thursday change to the authentication service triggers a full service outage affecting the case management portal and the document processing pipeline — the same systems behind both INC0047821 and PRB0003104. Post-incident review establishes that the three Wednesday records were all describing symptoms of the same underlying architecture: a shared authentication service under gradual stress that a change nudged into failure.
Three ITSM processes ran correctly. None of them saw what the others saw. The shared service context that would have connected them wasn't in the data model.
✦ ✦ ✦
The Problem
ITSM Processes That Run in Parallel When They Should Run Together
Incident management, problem management, and change management are intended to form a virtuous cycle: incidents surface symptoms, problem management finds root causes, change management implements fixes while protecting stability. In theory, information flows naturally between them. In practice, each process tends to operate in its own lane — different teams, different workflows, different views of the same underlying reality.
The structural cause is the same one that appears throughout this series: ITSM processes that work at the component level have no native mechanism for recognizing when two separate component-level events are actually the same service-level story. The incident team sees a slow portal. The problem team sees a queue anomaly. The change manager sees an authentication service update. None of those facts are wrong. They're just not connected.
What Gets Missed When Processes Don't Share Service Context
Related incidents are investigated independently. Two incidents affecting different CIs that both depend on the same technical service look unrelated. Each gets its own investigation, its own team, and its own resolution — without anyone recognizing that a systemic issue is responsible for both. Duplicate work. Missed pattern. Root cause unaddressed.
Problem investigation misses architectural patterns. Problem managers who work at the CI level can identify that a specific server keeps having issues. They cannot easily see that the server is one of four application components that share a dependency on a technical service with a creeping degradation problem — not without manually tracing architecture that should already be modeled.
Changes proceed without incident context. A change manager approving a modification to a technical service doesn't know — unless the service model tells them — that two active incidents are currently affecting application services that depend on it. A change that would be held during active service disruption gets approved because the disruption isn't visible at the change review level.
All three problems have the same solution: a service model that all three processes share, so that a service event recognized in one process is visible to the others.
The Explanation
CSDM as the Shared Language That Connects ITSM Processes
When CSDM service relationships are accurate and connected to ITSM workflows, something important changes: a service event becomes visible in all three processes simultaneously, not just the one that happened to receive the first ticket. The portal slowness, the queue anomaly, and the authentication service change are now recognizably related — because all three reference configuration items that trace to the same technical service in the CMDB.
This is the operational shift that service context enables. It doesn't replace the three processes. It lets them inform each other in ways that component-level data never can.
What Changes for Each Process
Incident Management gains scope awareness immediately. When an incident is created against a CI, the service model surfaces which other services and business capabilities are affected, whether a related problem record exists, and whether any approved or pending changes touch the same service. The incident responder starts with context instead of having to build it manually. Priority is set based on service criticality, not infrastructure severity. The stakeholder notification says "the case management portal and document processing service are both degraded" rather than "a server is down."
Problem Management gains architectural visibility. The most common failure mode in problem investigation is identifying a component-level symptom and treating it as a root cause. CSDM gives problem managers the full dependency map — so when multiple incidents affect different application services that share a technical service dependency, that shared dependency is visible from the problem record. The pattern that took three weeks to notice in PRB0003104 becomes visible in three hours when the service relationships are in the data.
Change Management gains active service intelligence. A change manager who can see — at approval time — that a service currently has two active incidents associated with it makes a different decision than one who approves the same change without that context. Active incident holds become automatic when a change targets a service that's currently experiencing disruption. Changes are sequenced to avoid concurrent modifications to shared technical services. The change advisory board reviews with full awareness of the service's current operational health.
"Incident, Problem, and Change aren't three separate processes. They're three views of the same operational reality. CSDM is the shared data model that makes that reality visible to all three at once."
The Solution
One Service Model. Three Processes. Compounding Returns.
The practical implication of connecting ITSM processes through CSDM is that improvement compounds. Each process that operates with service context makes the other two more effective.
Incidents associated with services rather than just CIs feed richer data into problem investigation — because the problem manager can see not just which CI failed, but which service was affected, and whether other services sharing the same architecture have active incidents too. That richer investigation feeds better-scoped change requests — which can now be assessed against current incident and problem records on the same service, rather than proceeding in isolation of them.
And every change that's approved with full service context — including awareness of active incidents, related problem records, and the criticality of the services at stake — is a change that's less likely to create the incident that starts the next cycle unnecessarily.
The compounding works in the other direction too. Organizations that allow ITSM processes to operate without shared service context accumulate compounding debt: incidents that don't feed problem investigation, problem investigations that don't improve change scoping, changes that create incidents that weren't predicted because the service context wasn't visible.
The Wednesday afternoon that opened this article is that compounding debt made visible in a single day. Three records, three teams, zero shared context. It took a Thursday outage to prove they were describing the same problem.
Summary
Connect the Processes. Connect the Reality.
ITSM processes don't fail because the teams running them are bad at their jobs. They fail because those teams are each working a partial view of the same operational reality, without a shared model that lets them see what the others see.
CSDM is that shared model. When incident, problem, and change management all reference the same service relationships — when a CI's upstream context is visible to every process that touches it — the three processes stop running in parallel and start running as a system. Incidents are scoped to services. Problems find roots across architectures. Changes are approved with awareness of the service's current operational health.
The Wednesday afternoon with three disconnected records becomes a Wednesday afternoon where the incident responder immediately sees a related problem record, the problem manager sees the shared CI, and the change manager sees two active service incidents and holds the Thursday change pending resolution. The Thursday outage doesn't happen. Nobody schedules the post-incident review that finds what everyone should have already known.
Connect the processes. They've been trying to tell each other something for years.
