The current CIS-DF blueprint does not treat reporting as a generic platform skill. It expects candidates to understand CMDB Health dashboards, Key Performance Indicators and Critical Success Factors, CMDB 360 custom reports, complex relationship queries, Foundation Dashboards, Natural Language Query, and the business value of CMDB insight. The challenge is choosing the right measurement for the question. A dashboard can look polished while hiding source gaps or low-value averages. The practical emphasis is on reporting that supports CMDB decisions.<\/p>\n
Ask what the report should change. If the goal is to improve service reliability, a count of total CIs may not help. If the goal is source accountability, CMDB 360 coverage or conflicting values are more relevant. If the goal is data quality, completeness, correctness, compliance, and relationship health provide better evidence. A useful KPI has an owner and an expected response when it moves.<\/p>\n
Critical Success Factors should connect data quality to service outcomes. For example, \u201c95% of principal-class CIs have an owner\u201d is useful only if ownership supports incident, change, or lifecycle decisions. Pair technical KPIs with outcome measures such as reduced change-impact investigation time or fewer incidents assigned to unknown owners. This demonstrates why CMDB quality matters.<\/p>\n
Reports should also show remediation progress where useful. Pair the number of failing CIs with open tasks, age, owner, and recurrence. That converts a quality metric into an operational queue and makes it easier to see whether the organization is actually reducing the problem or merely measuring it repeatedly.<\/p>\n
Finally, retire metrics that no longer support a decision. Old KPIs can outlive the process they were built to measure and distract from current priorities. Reporting governance should periodically ask whether each metric still changes behavior.<\/p>\n
CMDB Health scores need drill-down. ServiceNow aggregates health metrics at class, health-group, service, and relationship levels. Use that hierarchy to avoid global averages that hide important failures. A high enterprise score can coexist with a critical production class full of stale records. Data health and governance<\/a> require metrics to resolve to owners and corrective actions; reporting should expose where a metric fails and who can act.<\/p>\n A report showing missing fields is useful if those fields support identification, ownership, service management, security, or compliance. Reporting on hundreds of optional attributes can create busywork. Tie completeness rules to actual process needs and distinguish required from recommended data. Trend missing values by class or source to identify whether the problem is a specific ingestion path or broad governance weakness.<\/p>\n Use thresholds carefully in executive reporting. A target such as \u201c95% completeness\u201d should have a reason tied to process needs, not because it is a convenient round number. If the remaining 5% includes the most critical services, the target can mask material risk. Segment metrics by importance before declaring success.<\/p>\n Correctness trends can reveal failing lifecycle processes. Duplicate, stale, and orphan metrics are more valuable over time than as isolated snapshots. A sudden duplicate spike can point to an identification change. Growing staleness may indicate a source stopped reporting. Orphans may increase after decommissioning or relationship changes. Add source and lifecycle context so the trend explains where to investigate rather than only showing that a score fell.<\/p>\n CMDB 360 dashboards and saved queries can show discovery-source activity, coverage, conflicting attribute values, and source history. Use source analysis when the question is \u201cwho reported this and why did this value win?\u201d rather than trying to infer that from the reconciled CI alone. Reports can also surface CIs reported by multiple sources or classes that depend heavily on a single source.<\/p>\n Report freshness should be visible. Users need to know when health jobs, CMDB 360 queries, or source feeds last updated. A green metric from yesterday can be misleading during a fast-changing incident or migration. Add refresh context and avoid presenting stale analytics as real-time state.<\/p>\n Source-analysis reports should also account for expected asymmetry. Not every CI needs multiple sources. A specialized manual class may correctly have one owner, while a server class may be expected from several integrations. Define expected source coverage by class before treating single-source records as a quality problem.<\/p>\nCompleteness is only valuable when fields matter<\/h2>\n
CMDB 360 reports answer source questions<\/h2>\n