If you have been in ServiceNow ecosystem for a long time, you already know that CMDB is true digital foundation for the success of ServiceNow project. Whether it is ITSM, IT asset management, GRC or Security operations, CMDB is critical success factor for the effectiveness of various IT processes.
At the same time, we also understand that CMDB can be fragmented, scattered across multiple systems or managed manually. This also means that building CMBD can be a daunting and time-consuming journey as well. An organisation may face challenges in developing a decent CMDB in due time of initial rollout of ITSM due to several factors. Some of them are mentioned below
- Time-to-Value Pressure – Businesses often want quick wins by enabling incident, request, and change processes first for incremental feedback and increase adoption in phased manner.
- CMDB Complexity – Setting up a reliable CMDB involves data modeling, integrations, ownership, and governance, which can be overwhelming.
- Resource Constraints – CMDB initiatives require dedicated roles like configuration managers, discovery experts, and governance committees.
We will discuss the impact on various ITSM processes in exception cases where the business decides to go live and how this can mitigate to an extent.
- Incident Management
When it comes to incidents related to IT infrastructure, CMDB is crucial for incident management effectiveness, as with a good CMDB, agents can map a specific CI item with the incident. This ensures effective root cause analysis, timely triage and resolution, as well as impact assessment.
At the same time, you can technically go live with incident management without CMDB by defining high-level services and their support groups. This will ensure that an incident can be mapped to the service and can be automatically routed to the support group responsible for maintaining and managing the service itself. For example, You can define email service, HR service, Payroll service etc., and in future iteration of ServiceNow phase, you can enable discovery and map the business services manually or with service mapping.
- Change Management
Change management has even higher dependency on CMDB as without CMDB is place, impact assessment is going to be ineffective or CAB/technical approvers will not have visibility into what’s being changed and which downstream services might be impacted.
You can still utilize change state models, change workflow and approvals to track all change requests. It’s prudent to have at least critical CI loaded via discovery or manually to get started with change management and incrementally build a robust CMDB.
When it comes to change risk assessment, you can adjust the change risk condition to ensure that only valid ones are running like sufficient lead time, critical services impacted etc.
- Problem Management
Problem management is the least impacted out of three main ITSM processes as you can still go live with problem management and they can be linked to incident and in turn, services. It will still impact root cause analysis without knowing which exact CI is causing the issue.
Having gone through the above three areas, its essential to understand that for initial rollout without CMDB and high-level services in the beginning is an accepted approach however, focus should be developing a robust CMDB, starting with key services in the beginning and gradually improving CMDB landscape.
