CMDB Design and Implementation best practices

[ITPeaceKeeper]

We have Service Now in our organization and it was modified by a third party vendor to support a basic Ticketing System with Request and Incidents as well as a Change Management system. The vendor who provided the product did not create a system that links any of the data we input to any meaningful CI's. We do not have a way to extract metrics beyond, how many tickets, what are their priorities and who is assigned the ticket. I want to incrementally enhance our product to use the CI's in a CMDB by creating a small test case. Where can I start with this?

[SVimes]

Here is my take.

1. Ensure your CMDB is being accurately populated and governed. Clean and accurate data comes first.
2. Configure the required CI classes as Principal Classes using CI Class Manager. This will make just these CIs available to select on the Incident which would be a good starting point until you are ready to open up selecting CIs to more or all classes.
3. Configure the Incident form to use the Configuration Item field (conditionally display the field, make mandatory, and anything else you need to ensure it is used and used accurately)

[s-sandeep4]

Hi @ITPeaceKeeper 

• Start with a small pilot, such as one business application or service.
• Create the required Configuration Items (CIs) in the CMDB for that application.
• Define the relationships/dependencies between application, server, database, and other related CIs.
• Begin linking Incidents, Requests, and Changes to the appropriate CI.
• Make the Configuration Item field mandatory or strongly encouraged for support teams.
• Assign owners to each CI to maintain data accuracy.
• Create basic reports such as:
  • Incidents by CI
  • Changes by CI
  • Most frequently impacted systems
  • Recurring issues for specific CIs
• Review the results and improve data quality as needed.
• Expand gradually to additional applications and infrastructure once the pilot is successful.
• Avoid trying to build the entire CMDB at once; prove value with a small use case first.

[Sandeep _]

Hi @ITPeaceKeeper 

• Start with a small example in your PDI instead of trying to build the entire CMDB.
• Create an Application CI called Employee Portal.
• Create a Server CI called Server01.
• Create a relationship showing that Employee Portal runs on Server01.
• Raise a few test Incidents and select Employee Portal in the Configuration Item field.
• Create a Change Request for Server01 and link it to the CI.
• Now you can easily report on:
  • How many incidents affected Employee Portal
  • How many changes were made to Server01
  • Which application is most impacted by outages

Example: If Server01 goes down and 10 incidents are logged against Employee Portal, ServiceNow can show that all 10 incidents are related to the same application and server. This is much more useful than just knowing "10 incidents were created."

My recommendation is to start with one application, one server, and a few test tickets in your PDI. Once you see the value, expand the CMDB gradually to other services.

[ajmalmuhamm]

Hey @ITPeaceKeeper ,

Yes — this is actually a good use case for an incremental CMDB/CSDM improvement. I would not try to fix the entire ServiceNow implementation at once. Start with one small Incident use case, prove the value, and then expand.

ServiceNow's CMDB is intended to represent the infrastructure/services and their relationships, and the CI can then be referenced from Incidents and Changes.

Where I would start

Pick one Assignment Group + one type of Incident.

For example:

Assignment Group: Network Support
Incident type: Network connectivity issues
CI: Network device / Router / Switch

Your first objective should simply be:

Incident → Configuration Item → Support Group

Instead of having:

Incident
  ├── Priority
  ├── Assignment Group
  └── Assigned To

you want:

Incident
  ├── Service
  ├── Service Offering
  ├── Configuration Item
  ├── Assignment Group
  └── Assigned To
          │
          ▼
        CI
          │
          ├── Support Group
          ├── Location
          └── Relationships

The Incident Configuration item field is specifically intended to identify the primary CI affected by the incident. If multiple CIs are affected, ServiceNow also provides affected/impacted CI relationships.

A simple pilot I recommend

Suppose your organization has an Email/Outlook service.

First make sure you have something meaningful in the CMDB:

Service
  Microsoft 365 / Email
        │
        ▼
Service Offering
  Corporate Email
        │
        ▼
CI
  Exchange / Microsoft 365 CI
        │
        ▼
Support Group
  Messaging Team

Then modify your Incident process so that when users create an email-related Incident, they can select the appropriate Service / Service Offering / CI.

Don't start by automatically creating hundreds of CIs. Start with perhaps 10–20 good-quality CIs.

Then automate Assignment Group

This is where you can demonstrate immediate value.

For example:

Category = Network
CI = Router-ABC

              ↓

Assignment Group = Network Support

ServiceNow supports Assignment Data Lookup rules where the Configuration Item can be one of the matching fields and the Assignment Group can be populated based on it.

So your pilot could become:

User creates Incident
        ↓
Selects Service
        ↓
Selects CI
        ↓
System determines Assignment Group
        ↓
Incident routed to correct team
        ↓
CI is stored against Incident

That gives you something measurable very quickly.

Then start reporting

Once you have enough Incidents with CIs, you can build reports such as:

Incidents by CI

CI                    Incidents
--------------------------------
Email Server             127
VPN Gateway               82
Router ABC                45
Application XYZ           31

Then you can go further:

• Incidents by CI
• Incidents by Service
• Incidents by Service Offering
• Top 10 problematic CIs
• Priority by CI
• MTTR by CI
• Incidents by Assignment Group + CI
• Repeat incidents against the same CI
• Changes against a CI
• Incidents occurring after changes to a CI

That's where the CMDB starts providing business value, rather than simply being an inventory database.

An important warning

Don't just populate the CI field with arbitrary records to make the reporting work.

ServiceNow's CMDB design guidance specifically recommends that CIs represent things that can actually be the subject of an Incident or Change, and that CIs should have meaningful relationships to the services they support.

So I would establish a very small governance rule for your pilot:

If a CI cannot help us understand, troubleshoot, route, change, or report on a service, don't create it just for the sake of populating CMDB.

Your phased approach

I'd structure your project like this:

Phase Goal

1. Assess	Identify one service and 10–20 relevant CIs
2. CMDB	Validate/create the CIs and relationships
3. Incident	Make users associate Incidents with the correct CI
4. Automation	Derive Assignment Group from CI where appropriate
5. Reporting	Build CI/service-based Incident metrics
6. Change	Associate Changes with the same CIs
7. Expand	Repeat the model for another service/team

I'd also avoid starting with Discovery or a complete CMDB cleanup. Those can become large projects. Your first success criterion should simply be:

"Can we take one existing Incident process, associate it with a meaningful CI, and produce a report that we couldn't produce before?"

If the answer is yes, you have a strong proof of concept to show management and then expand.

One particularly useful next step would be to take one of your existing Incident categories/services and design the exact pilot — including which CI class to use, what fields to configure, how to populate the CI, how to automatically derive Assignment Group, and what dashboard/report to build. I can walk you through that implementation step-by-step in ServiceNow.