Best practice on Incident form taxonomy

[EveThorpe]

Hi, we have been working on building our CMDB and the data it holds and are now at the stage where we want to change our Incident form to ensure the correct data is captured. We have researched various options but essentially want to make it as easy as possible for our first line teams to understand what data they should add in.

Our current form asks for Business service, service offering and CI with only business service mandatory. We have been looking at making service offering mandatory, which then auto populates the BS field, however doesn't do anything to our list of CIs, of which there are thousands to choose from.

Is this the best way or is there a better way to find the data? Is there anything we can do to filter down the list of CIs or is it more a case of providing knowledge/ training?

Any guidance would be appreciated. Thanks

[Peter Kindbom]

Good question to get a discussion about.
We have Service Offering as a mandatory field as this is where we have our Service Committment (for example resolution time) and the tool is tracking this and we can keep track on if we have a SLA breach or not.
The Service Commitment helps first line to prioritize (the Service Offering gets a Business criticallity according to the Service Committment).
When the incident is opened the work to solve it starts and it is here a good CMDB is very helpful. Perhaps the incident is escalated and resolved in "second line" and they find out that it was a change on a specific application that caused the incident. The second line will then fill in the Resolution information on the incident and enter the Casusing CI as the specific application.
This will enable us to track customer experience on Service Offering and what CI is causing incidents. The role responsible for the application can act on this and the "delivery manager" can follow up and maybe report to the role responsible for relations with customer/user.
I apreciate feedback and comments on this setup.