- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-24-2023 03:10 AM
Hi,
We just migrated to ServiceNow OOTB instance in our organization and the initial discovery and CI population is almost done.
To support the ongoing CMDB maintenance activites, we are thinking to implement a Service request form which users can submit a request for any type of CI updates and configuration manager can look into it.
My question is, is it something worth to have these kind of manual forms or should we automate these updates via workflows? If we choose complete automation, there is no control over the data and we get lots of questions on how the data is being populated. Please help with some best practices or sample process flows on how we can implement this.
Thanks in advance
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-24-2023 06:08 AM - edited ‎03-24-2023 06:09 AM
My recommendations are as follows:
1. It should not be the configuration manager's responsibility to control the data. It is the data owner's responsibility to control the data. For CMDB that role is typically assigned per CI class, and it is stored in the "Managed by Group" field. As a configuration manager, your general position should be "hands off" when it comes to the actual configuration data, except when required to intervene as a configuration admin to do things like bulk edits, data migrations, user requested edits, etc.
2. There is certainly a valid argument to be made that updating CI attributes via a controlled process such as Service request provides a much more controlled experience, allowing more advanced business logic to be put into the request fulfillment process and thus leading to improved data and process. However, in reality this may cause you a lot of headaches if you practice it widely across the entire CI. So unless you have specific policies that mandate centralized control of the CI data, I would suggest exercising some caution here. If the process is too cumbersome, the likely result is that your CIs won't get updated at all because... well, CI owners are human. And humans don't like unnecessary red tape that they don't see as valuable. And noncompliance is the inevitable result. Instead, look for ways to add value by using this control judiciously. For example, Status/Operational Status fields might be worth locking down for manual edits, forcing users to go through a controlled process such as Request or Change Management to change it. But submitting a Request to modify the Description of a CI is likely to be seen as unnecessary red tape.
3. Keep in mind that there are two kinds of data on a CI. Technical data and business data. Technical data can be discovered and thus having users update those fields might be not only unnecessary but also pointless, unless that data is getting discovered only sporadically, and then allowing users to modify the data themselves might be very useful. Business data, on the other hand, is not discoverable, and needs your CI data owner involvement to make the data complete.
4. Use CMDB Health to manage the Completeness and Correctness of your data. Focus on a finely tuned configuration to measure just what you are most interested in. Have a laser focus only on the most important data and exclude everything else until you get your scores where you want them, and then broaden your view to take on additional CI classes, data, and metrics.
The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-24-2023 03:29 AM
Hi @Allen_Deepak ,
Refer the below useful Articles,Might help for this.
https://vsoftdigital.com/blog/transforming-cmdb-servicenow-and-best-practices/
Thanks
Ajay
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-24-2023 06:08 AM - edited ‎03-24-2023 06:09 AM
My recommendations are as follows:
1. It should not be the configuration manager's responsibility to control the data. It is the data owner's responsibility to control the data. For CMDB that role is typically assigned per CI class, and it is stored in the "Managed by Group" field. As a configuration manager, your general position should be "hands off" when it comes to the actual configuration data, except when required to intervene as a configuration admin to do things like bulk edits, data migrations, user requested edits, etc.
2. There is certainly a valid argument to be made that updating CI attributes via a controlled process such as Service request provides a much more controlled experience, allowing more advanced business logic to be put into the request fulfillment process and thus leading to improved data and process. However, in reality this may cause you a lot of headaches if you practice it widely across the entire CI. So unless you have specific policies that mandate centralized control of the CI data, I would suggest exercising some caution here. If the process is too cumbersome, the likely result is that your CIs won't get updated at all because... well, CI owners are human. And humans don't like unnecessary red tape that they don't see as valuable. And noncompliance is the inevitable result. Instead, look for ways to add value by using this control judiciously. For example, Status/Operational Status fields might be worth locking down for manual edits, forcing users to go through a controlled process such as Request or Change Management to change it. But submitting a Request to modify the Description of a CI is likely to be seen as unnecessary red tape.
3. Keep in mind that there are two kinds of data on a CI. Technical data and business data. Technical data can be discovered and thus having users update those fields might be not only unnecessary but also pointless, unless that data is getting discovered only sporadically, and then allowing users to modify the data themselves might be very useful. Business data, on the other hand, is not discoverable, and needs your CI data owner involvement to make the data complete.
4. Use CMDB Health to manage the Completeness and Correctness of your data. Focus on a finely tuned configuration to measure just what you are most interested in. Have a laser focus only on the most important data and exclude everything else until you get your scores where you want them, and then broaden your view to take on additional CI classes, data, and metrics.
The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.