You don’t have to, but there are some reasons you should consider it:
Reason Nr. 1: because the ITIL Manuals state: What is an Incident? ”An unplanned interruption to an IT Service or reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet affected Service is also an Incident. “
Reason Nr. 2: because you want to have evidence of the state your CMS data is in. By thoroughly tracking such incidents you have a very effective KPI. And you will – over time – see how the system and the content quality develops. In addition you have base data to express quantitative benefits and persuade sponsors when requesting additions/extensions in your CMS for example when you want to apply more strict configuration control (which will end up in more strict change control and which will have an impact on all your IT)
Reason Nr. 3: because you need an incident as reason for the following change with whom you then correct the data in the CMS. Or do you intend to allow updates in the CMS to single users without configuration (=Change) control?
If you intend to apply strict configuration control, and therefore go for full compliance with all the configuration management processes I suggest that you always raise an incident when you find an inexplicable discrepancy between discovered and authorized CI Information OR whenever anybody reports the CMS-data to be incorrect OR when a change failed to be rolled out successfully because of inadequate impact analysis caused by non sufficient information from the CMS. And don’t forget, this includes relationships too.
Tags: Discrepancy, incident, Verification & Audit