People come and go. They change roles, move to different departments, and leave for another job or retirement. The more people you have, the more this happens. Often this leaves your CMDB incomplete, and you may end up with Business Application owners who have left the building. Of course, this applies to other CI’s, too.
Most companies have implemented exit processes to ensure that user accounts are deactivated and that relevant assets are returned to the company. However, references to these people often remain in the CMDB or the Foundation Data of your ServiceNow instance.
An Active Directory integration or another mechanism might automatically deactivate User records in ServiceNow. However, references to these people might still exist after leaving, especially if they went to a new role without leaving the organization.
How much will it cost you, if something critical fails and the owner is no longer there?
Let’s look at two scenarios and see how you can use DCM to catch these situations:
- People leave the company
- People transfer to new roles (and responsibilities)
Let us assume that these people have been responsible for certain Configuration Items in your CMDB – for example, Business Applications. Now someone else should quickly take over those responsibilities.
Case 1: Elvis Has Left The Building.
So Elvis left, but we still have records in our CMDB referring to his User record. This is a trivial case to check with DCM. We simply check if we still have Business Applications that refer to “Elvis” as a Business Owner or an IT Application Owner.
Here’s a simple DCM Blueprint that will define the said User references on any active Business Application.
This Blueprint defines that every Business Application should have:
- Business owner reference to an active user
- IT application owner reference to an active user
The “Active User” condition is configured as part of the links between the records. In DCM, we call them “Target record conditions.”
After auditing your data against this Blueprint, you will get results like this:
When you schedule this audit to run regularly, you can ensure that these occurrences are caught and reported automatically.
Case 2: Elvis No Longer Sings.
Elvis still works for us but in a new role. It requires a little bit more from the DCM Blueprint but is still a very simple thing to solve.
Let’s say that all “IT Application Owners” should belong to the “IT department.” Furthermore, let’s agree that “Business Owners” should NOT belong to the IT department.
A DCM Blueprint that includes those department-related conditions could look like this:
In addition to the Blueprint in Case 1, this one also defines that:
- Department for “IT Application Owner” must contain “IT”
- Department for “Business owner” should not contain “IT”
These conditions can include any details from the user record, department, or other referenced records, including roles, group memberships, etc.
When we run an audit against this Blueprint, we find that even if Elvis is active, he is not a valid IT Application owner because he doesn’t belong to an IT department. The opposite goes for “Fred” who does not qualify as a Business owner since he works for the IT department.
In this case missing information in the CMDB ended up costing 2 million euros. Read: The 2 Million Euro Incident.
The Big Picture
The examples above showed results from individual audits and specific findings as audit messages. Getting the details right is vital for operations. However, understanding the big picture is often even more important for management and planning purposes.
Data Content Manager includes interactive dashboards that help you understand and analyze your current data quality. You also get trends to see how things have evolved over time. The results in these dashboards are based on Blueprints, such as the ones above.
Drawing the Blueprints is the only thing that needs to be done to get results – no customizations or scripting are required. You get audit results with minimal work without resorting to developers.
The example below shows data audit reports with trends. They are based on blueprints and audits that have been scheduled to run on a weekly basis.
Conclusions
People come and go, and we can do nothing about that. But we can ensure that our CMDB data does not reference people who no longer work for us or have other priorities today.
Nothing is more frustrating than working on a ticket and finding out that a “Service manager” or an “Application owner” referenced by a related CI can’t help you or doesn’t have anything to do with the matter anymore. Furthermore, it will result in having to find the information manually.
In practice, somebody starts calling around or checking from other systems (or Excel sheets) instead of being able to trust the CMDB.
Studies show that this costs 10x more than if the information was correct in the CMDB to begin with. The “Rule of 10” states that it costs 10 times as much to complete a unit of work when the input data are defective as it does when they are perfect. Check out this article on Harvard Business Review for some ideas.
The “Rule of 10” states that it costs 10 times as much to complete a unit of work when the input data are defective as it does when they are perfect
Try it Yourself
If you have a ServiceNow non-production environment that contains a reasonably recent copy of your data, you can try this for free.
DCM is available as a Free Trial, and we can run this use case together with you. There is no cost or need to learn the product – we’ll help you set it up and create the example blueprints. You only need to spend a couple of hours on this with us to get the results. The results can be sobering.
