Best Practices Question - CI required in incident record

[William Busby]

I've worked with several companies and some of them have added the CI field to the incident form as a mandatory attribute. This doesn't seem a good idea to me since many incidents are for generic issues such as password reset, etc. which aren't applicable to a CI and it forces them to create bogus CIs such as 'Password Reset' in the configuration item table.

So, I'm asking the community - should CI be a required field on the incident record?

[Lars Kragh-Hans · Accepted solution]

I would say that Configuration item should not be mandatory in the incident record.

In case of an incident opened by a system user because it is triggered by a business rule (threshold breach etc.), it would make sense to make it conditionally mandatory. Requiring that those who build business rules also capture the configuration item gives the remediation team the best foundation for solving the incident with a low MTTR.

On the other hand, configuration items on incidents opened by human users should not be mandatory. Often a user will not know which configuration item is at fault and there is a risk of either the user or the service desk worker setting an incorrect configuration item. In case of human users, it is more important that the service desk worker tries to capture the symptoms experienced and what actions lead to these.

[William Busby]

Waiting on additional replies before I set Lars as the correct response. I'm trying to avoid applying my bias simply because I agree with Lars.

[Ashutosh Munot1]

Hi, I will take this in different way. This CI been mandatory should be always conditional. In our case we have it mandatory in most of the cases but yes there is always an exception. We drive this using category subcategory one, second we have Service offerings and business services on form as well which filter outs the CI because we trust our cmdb and we have provisions to make cmdb upto date. So you should have a logic in place for making it mandatory. We do have password reset and it is not mandatory for that, we use category and subcategories and then CI is not visible or is hidden. But this totally depends on the requirements and clients. Thanks, Ashutosh

[DaveHertel]

Hi,  if the company has a mature, reasonably-well maintained CMDB & configuration management practice, I definitely believe the CI field should be on the incident and be a mandatory field.  While not every CI is in the CMDB and there are always exceptions, missing data (CI's), etc. its a lost opportunity for health, maintenance, issue-correlation, and historical tracking -- if a CI is not tracked to an incident.  Of course not every conceivable CI is in the CMDB, so to deal with that a few generic CI's can be used as place holders.  Either HW, SW, app, whatever works for the business to have 'something' to attach in an incident too when the exact CI is not available (or may not exist depending on issue).  Address how to with help desk staff how to apply generic CI's, use them sparingly when possible, but it provides an option to fill in required incident data.   Later, during incident or problem resolution/reflection, continuous improvement processes can address "why" a specific CI wasn't available.   Or another, similar approach is the CI named "Missing CI" that is just a placeholder.

The value here is in that most incidents should have CI's to help all teams understand, track and correlate issues in context.  Think 80/20 rule perhaps.  Maybe 80% of incidents are tied to real CI's providing historical performance & correlation.  Understanding that issue X related to item Y is advantageous both in short and long run... and that incident data is more likely to exist if the CI field is mandatory.  It also provides incident/CMDB data to reveal where gaps may exist in the IT/CMDB landscape (i.e. items missing from the CMDB that maybe should be corrected...)  Over the long run, fewer incidents should be created with "generic" CI placeholders as the configuration mgmt processes mature.  CM process owners can evaluate the incidents with general-purpose CI's and use this continuously improve.    Meanwhile, some general-pupose CI(s) provide an option for support staff while also gaining metrics from the incidents that can be related to what/where the issue may have been when the actual CI's DO exist in the CMDB.

My 2.5 cents.  Hope this helps?