Categorizing Incidents for various IT groups

[Michael Domke]

There are many different IT groups in my company that manage and support their own "stuff". Regardless of what that "stuff" is, when there's an issue, an Incident is created and assigned to the appropriate group.

Out of the box functionality for Incidents within ServiceNow works for a generalized environment and we've actually customized our instance further to be a little more granular in how Incidents are "categorized". That is, what data we collect to document the Incident.

The issue we're having right now is that several of these groups are becoming more familiar with what ServiceNow can do in terms of customization and they are now requesting very specific needs in terms of categorizing their Incidents. Specific fields with specific choice values, etc. These needs are specific enough that they really can't be shared among other groups.

What I'm afraid of is that we'll need to manage a whole sub-set of different ways to categorize Incidents for many different groups. For example, one group wants a certain choice list of categories and other field types and other groups want something unique to their "stuff". This could get messy.

My question to the community is to find out what others may have done to manage this varying type of Incident categorization.

Thanks for any input,

Michael

[danielbilling]

Hi Michael,

This is the case at most customers. You should always try to get away from the "categorisation" discussion as it time-consuming and never ending story.

Would suggest moving forward using a Service oriented approach and using the CMDB.

Now you also have the possibility to get people to think in a service based delivery.

Depending on the maturity level of your CMDB i suggest different approaches.

• No or low level CMDB - Create new CI class for categorisation and add a type field. You need this in order to set different levels of your categorisations. Create a Service field on task table and set dependency on cmdb_ci
• "mature" / service   defined CMDB - Use the Service Portfolio plugin and start create Service Offerings. Create relationship (dependency) between Service Offerings and CIs

Now you have the possibility to set Tree_picker on configuration item field to easily find your values in a dynamic structure.

The benefit of this is that you can offer your stakeholder the number of levels they want. If the Application team need to have 12 levels of categorization it's up to them, if Network team only need 2 - that's also fine.

Your Servicedesk will also be happy as they would only focus on finding out the Service instead of guessing from a number of levels that only make sense for someone else

If you open an new incident on ServiceNow (demo) , i made an example for you.

[Michael Domke]

Thanks for the reply Daniel,

Unfortunately, I'm not seeing how this works. Perhaps I didn't get to the demo instance in time before someone else decided to change things.

I'm even trying to figure out to setup the tree picker feature on my companies test instance. The Wiki article on it is lacking. What are the key points to defining how the tree picker works?

Thanks,

Michael

[danielbilling]

The easy way to try this.

Create 2 new fields in incident (or task if you want to reuse the structure in or modules).

1 named "Service" of typ Reference to cmdb_ci_service table

1 named "CI" of type Reference to cmdb_ci. set dependency to your service field and add tree_picker=true in attributes.

Go into a config item (like a server och app) and add parent to the form. then choose a service and relate to the CI.

You should now be able to choose a Service on your incident and the CI should only display child elements to that Service.

This is strictly for testing purpose and to get an understanding of the feature. The final solution would be to use the CI relationships instead   and have a Javascript returning the structure.

/

Daniel

[nate_weldon]

What was the effect on reporting from going this route. I would think you would complicate that aspect by having a bunch of different sub-categories on business services.