CSDM implementation stages — Foundation

In the Foundation stage of implementing the CSDM framework, you prepare the referential data that enables accurate reporting to support good business decisions. Use the base-system tables when you begin implementing the CSDM to derive the highest value from your ServiceNow products and the ServiceNow AI Platform.

Benefits of preparing the data in the Foundation stage

The basis of any good data model is the foundational data that is referenced throughout the model.

• The base-system tables act as the foundation for many ServiceNow products.
• The tables help your company align with reporting requirements early to expedite the value you get from the CSDM. You can reduce or eliminate costly rework tasks needed to align with reporting requirements.

Tables that you work on during the Foundation stage

Business Process table [cmdb_ci_business_process]

A business process has a well-defined start and finish. Examples of business processes in the banking industry are the customer onboarding process and the credit check process. Each business process can have levels of criticality and impact. Business processes are stored in the cmdb_ci_business_process table.

Contract table [ast_contract]

The Contract table identifies binding agreements between two parties. When you populate services provided by vendors into the CMDB, consider the role that contracts play when evaluating service level agreements (SLAs).

Product model table [model_id]

The Product model table [model_id] identifies the unique types of products your organization develops or consumes. When you group assets and CIs by product model, you unify and relate CIs that are part of the same digital product and portfolios of products. Grouping assets and CIs by product model can help you plan projects, monitor costs, and rationalize your data. Discovery can populate hardware product models after they’re operational, but other types of product models require planning from product owners.

Use the CSDM Product Model Assignment job to auto-generate a product model record (application model, service model, or software model) for each logical CI that is not yet associated with a product model. Product models are ideal for associating CIs that are parts of a single digital product. See Auto-generate product models for logical CIs.

CMDB Group table [cmdb_ci_query_based_service]

The CMDB Group table identifies a collection of CIs based on the results of saved Query Builder queries, encoded queries, or manual entries. CMDB groups are critical elements of Dynamic CI groups and the strategic management of CIs. Decide early how you want to report CI information and how you want to monitor CIs. These decisions affect how you create CMDB groups.

Location table [cmn_location]

The Location table uniquely identifies geographic locations. You can create a hierarchy of location data using the Parent attribute. The hierarchy might include entries that match your reporting requirements. For example, you could populate the location table as follows

Figure 1. Your organization's location attributes

To include more detail in reports, you could extend the Location table to include floors, rooms, and even datacenters. With hierarchy capabilities, trusted source data, and your requirements in hand, you can create locations that support your future reporting needs.

Group table [sys_user_group]

The Group table identifies sets of users that share a common purpose. Groups may perform tasks such as approving change requests, resolving incidents, receiving email notifications, or performing work order tasks. Groups also use the referential data in the CMDB to identify how CIs are managed (for example, the Managed by group) and supported (for example, the Support group). Any business rules, assignment rules, system roles, or attributes that refer to a group automatically apply to all group members.

User table [sys_user]

The User table identifies the persons and applications that have access to your ServiceNow instance. You can organize users into groups that are associated with the Company, Business Unit, and Department tables.

Organizational structure

Organization structure tables identify internal business structures and external customers, manufacturers, and vendors.

Company table [core_company]

The Company table is populated with the legal entities of companies. Entities can be either internal (your organization) or external. You can use the Parent attribute to build a hierarchy. Consider the legal entities that you need for reporting when the CMDB is populated.

• Internal entries should focus on a hierarchy of legal entities rather than a hierarchy of business units within a legal entity.
• External entries are identified by a True or False flag. The Customer flag identifies your external customers.

  The Manufacturer flag identifies companies that create products that you consume. An internal organization might be a manufacturer.

• The Vendor flag identifies organizations that provide products that you purchase. An internal organization might be a vendor.

Business Unit table [business_unit]

The hierarchy of your business is populated in the Business Unit table with a reference to the parent company. A business unit is a part of your organization that is responsible for specific operations, such as finance, human resources (HR), or IT. A hierarchy within a business unit is common. For large multinational organizations, you may have business units that identify independent regional operations and the specific operations within the region.

Department table [cmn_department]

The Department table includes a finer level of detail about a business unit. The Department table gives you another way to categorize users, groups, assets, and CIs.

Life-cycle tables

Life-cycle states track the life cycles for products, assets, contracts, CIs, locations, and other objects. Using the standard life-cycle values consistently helps you to track objects through their transitions over time. Reporting can therefore accurately reflect the actual states of CIs: usage, availability, end of support, and so on.

Note:

Based on the type of item, the [life_cycle_control] table specifies which life cycle stage values are available for each life cycle stage.

The standard CSDM life-cycle value pair covers all phases of a product instance life cycle.

• A Life cycle stage is one of the broad phases that a CI moves through, from inception or procurement to retirement and end of life.
• Life cycle stage status is the specific status of a CI within its current life cycle stage.

For example, a hardware CI in the Operational stage might change status over time from In Use to In Maintenance to End of Support. A different hardware CI might go from In Use to End of Support without ever having been in In Maintenance status.

When you enable the CSDM framework, you can start using the Life Cycle Stage and Life Cycle Stage Status fields to track an asset's life cycle. To use the fields, follow the procedure described in Second activation step — Activate the CSDM plugin. The following assets can use life-cycle states:

• Product life cycle
• Hardware life cycle
• Logical life cycle
• Document life cycle
• Location life cycle

Watch the ServiceNow Community video: CSDM V4 product and life cycle discussion