ServiceNow Common Service Data Model KPIs and Metrics That Matter

KPIs for the Common Service Data Model show whether operational records can rely on its structure. This page covers the measures of adoption and health, such as service coverage, relationship completeness, ownership and consumer linkage, how each is calculated, where the data comes from, and what to avoid when reading them.

What the measures on a CSDM program are for

The Common Service Data Model is the structure that tells the CMDB how business applications, application services, the technical services beneath them and the service offerings consumed by customers relate to one another. A CSDM program succeeds when operational records can rely on that structure: an incident names the application service it affects, a change shows which business applications depend on the server being patched, an alert can be traced to a service with a named owner. Measures on the program exist to show whether that reliance is possible yet, where it is breaking down and whether the model is keeping pace with the estate it describes. They are not a count of configuration items, and they are not a measure of how well incidents are resolved. Those are measured elsewhere.

Two audiences read these measures. The governance forum uses them to decide where to spend modelling effort and whose records need attention. Service owners use them to see whether their own services are described well enough to be analysed during an outage or a change review. A measure that neither audience would act on does not belong on the dashboard.

The measures that describe adoption of the model

Service coverage is the share of in-scope applications that have a business application record and at least one application service beneath it. The scope is the list of applications the organisation has agreed to model, usually the application portfolio, not every record in the CMDB. A low figure early in a program is expected; a figure that stops rising while the portfolio keeps growing is the signal to act on.

Relationship completeness is the share of application services with at least one mapped technical dependency, such as a server, database or cloud resource. It shows whether the service can be analysed at all. A service with no dependencies is a label, not a model, and impact analysis on it will return nothing.

Ownership completeness is the share of business applications and application services with a named service owner and a named technical owner who respond when asked. Group aliases that nobody reads satisfy the field but not the measure, so the quality sample described further down should include a test of whether the owner answers.

Consumer linkage is the share of operational records, chiefly incidents, changes and alerts, that reference a valid application service rather than a free-text field, a retired record or no service at all. This is the measure that connects the model to the work it is meant to support, and the one most likely to be gamed by setting a default value.

The measures that describe the health of what exists

Record currency is the share of service records whose relationships have been reviewed within the window the governance forum agreed, with the review date recorded on the record. A review logged without anyone checking the links counts as a review but is caught by the quality sample.

Duplicate and conflict rate is the number of open reconciliation exceptions where two sources disagree about a service or its dependencies, tracked as a backlog with its age. A growing backlog means intake is faster than review, and the dependencies downstream impact analysis relies on are uncertain until it is cleared.

Class conformance is the share of service records that sit in the class the model prescribes for them rather than in a legacy or generic class. Programs migrating from an older service model often carry records that were renamed but never reclassified, and those records behave differently in reports and in impact analysis.

How the measures are calculated

Each measure is a ratio with a written numerator and denominator. The denominator is the in-scope population: the agreed application portfolio for coverage measures, the active service records for health measures, the operational records created in the period for consumer linkage. Retired records are excluded from both sides, or every decommissioning will move the ratio. The numerator is a saved query against the CMDB and its relationship table, or against the task tables for consumer linkage, filed next to the measure definition so that a changed filter is noticed.

The platform’s own CMDB health reporting, which scores completeness, correctness and compliance against rules an administrator defines, can supply several of these figures directly once the rules are written to reflect the model. Where it cannot, a scheduled report against the same tables will do. What matters is that the same query produces the figure every period, and that someone can show the query when the figure is challenged.

Where the data comes from

Coverage and ownership measures draw on the CMDB service classes and the application portfolio records that define scope. Relationship measures draw on the CMDB relationship table, populated by discovery, service mapping and manual modelling. Consumer linkage draws on the incident, change and alert tables and the service reference field on each. Currency and conflict measures draw on the reconciliation and audit data the CMDB keeps about its own records. When a measure needs data that no source holds, such as a review date that is not recorded anywhere, the first task is to capture the data, not to estimate the measure.

Misuse to avoid

The commonest misuse is to count configuration items and present growth as progress. A CMDB can double in size while the share of services that can be analysed falls. The second is to measure teams against each other on coverage when their service definitions differ, which rewards the team with the broadest definition. The third is to use the measures as individual performance targets for the people who maintain records, which leads to fields filled with defaults and relationships added to satisfy a count. The fourth is to keep migration measures alive after the migration: once legacy records are reclassified, the conformance measure has done its job and should be retired rather than reported at full marks forever.

Review cadence

Review the measure set at the governance forum each month, in the same order every time, with the service owners having seen their own figures first. Look at movement since the last review and at the quality sample before the headline figures. Once a quarter, re-check the scope list and the measure definitions, drop any measure nobody acted on and decide whether the domain the program is currently adopting needs a measure of its own. Tie the review to the operational outcomes it is meant to protect, so that a fall in consumer linkage is discussed as a cause of slower triage, not as a data-quality item on its own.

Measuring the Health of the Model Itself

Much reporting on a CSDM program measures the operations the model supports, such as incident response or change success. Those measures matter, but they cannot tell you whether the model is trustworthy. An incident dashboard can look excellent while the service field on many of those incidents points at a retired server. The measures that protect a CSDM investment are the ones that describe the model: how complete it is, how current it is, and how often operational records can be traced back to it. Track these alongside the operational measures, and treat a drop in model health as an early warning for the operational numbers that follow.

Building a Measure Set That Stays Honest

1. Start from a question the business asks, such as whether a given service can be assessed during an outage. A measure with no question behind it is often ignored once the novelty wears off.
2. Define the numerator and denominator in writing, including which records are in scope. Exclude retired records from both, or the ratio will drift every time a service is decommissioned.
3. Name the source report or query, and file it next to the definition so that a changed filter gets noticed.
4. Set a target that the service owner can defend in a meeting. A target nobody can justify is decoration.
5. Once a quarter, review the measure set and drop any measure nobody acted on during that period.

How the Measures Go Wrong

A measure that rewards the wrong behavior is often the first failure teams meet. If the coverage figure counts any relationship, teams will add generic links that satisfy the count and say nothing about dependency. The corrective is a quality sample: each quarter, pick a few relationships at random and ask the owner whether the link is real. The proportion of confirmed links is more useful than the total count.

A second failure is comparing measures across services that do not share a definition. One team’s idea of a business service may be much broader than another’s, so their coverage figures are not comparable. Compare trends within a service over time, and compare services only after the layer definitions are agreed.

The third failure is hiding a drop behind a stable average. A model with a large number of services can show healthy overall ownership while three critical services have lost their owners. Break the measures down by service tier, so that a gap in a critical service cannot be averaged away.

Linking Model Health to Operational Outcomes

The point of these measures is to anticipate operational trouble. When the share of incidents carrying a valid service reference falls, expect triage to slow, because responders have to work out impact by hand. When the backlog of reconciliation exceptions grows, expect change risk assessments to become less reliable, because the dependencies they rely on are uncertain. Record these links in the monthly review, so that a model problem is treated as a cause and not only as a data-quality item. A review format that fits this pattern is described in the operational intelligence review post.

When a Measure Should Be Retired

Retire a measure when the decision it was meant to inform has already been made, or when the team has fixed the underlying condition and the measure no longer moves. Keeping such measures on the dashboard dilutes attention. A short list that people read is worth more than a long one that people scroll past. The CMDB-side measures in the CMDB KPI guide can be checked against this list to avoid double counting.

Frequently Asked Questions About CSDM Health Measures

Are model health measures the same as data quality rules?

They overlap but serve different purposes. A data quality rule flags a single record that fails a test. A health measure summarizes how the whole model is performing over time and is used to decide where to spend governance effort. Rules feed the measures, and the measures decide the priorities.

How many measures should a CSDM dashboard hold?

Few enough that the governance forum can take each one in turn during the meeting. A handful of model health measures plus a small set of operational outcomes is often enough. If the list cannot be discussed in the time available, it is too long.

Should service owners see their own measures?

Yes, and they should see them before the governance forum does. An owner who sees a gap in their own service can often close it in a single conversation, while a gap raised for the first time in a meeting often gets defended rather than fixed.

What is the best sign that a measure is being gamed?

The measure improves sharply while the quality sample stays flat. When that happens, the measure has stopped describing the model, and the definition should be tightened before anyone reads more into the trend.

Next Step for Your CSDM Measurement Design

The measures that matter often depend on which operational decisions the model is meant to support, so bring those decisions with the list. For the data-side rules that feed these measures, see the CMDB data quality rules post.