Category/subcategory in incident

[Earl L]

We're working on configuring incident management for our go-live. The category/subcategories that are setup with the OOB configuration aren't necessarily what we want to use for our production site. I'm suspecting others are in similar circumstances.

My question is sort of a poll I suppose. So here goes; how many people stick with the OOB category/subcategory lists when they go live with IM?

And then, if you're not using the OOB category/subcategory lists, what are you doing? Are you revamping the whole thing? Or just making a few tweaks to make it suite your needs? Are your lists long/extensive or short/sweet?

Hopefully you get the gist of my questions. Feel free to respond however you feel appropriate. Thanks.

Earl

[Aaron40]

I have never witnessed a company use just OOB on the Incident cat/subcats before. There has always been a modification, whether it was just adding one additional option or reconfiguring 95% of it.

Every implementation I've done, the cat and subcats were different.

Please take a look at http://www.itsmsolutions.com/newsletters/DITYvol6iss27.htm . This is an awesome article on classifications of incidents.

Do note that it won't just give you a list of things and say "here, add this and you're done". This list isn't supposed to be an easy decision (unless the business already had a specific requirement they are using from a legacy system they want to stick with). Time and consideration should be spent when building this area out so you don't have to modify it later.

Modification to these fields after go-live is not fun if you have workflows, UI policies, client scripts, etc running against your category fields.

I don't mean to steal but here is an excerpt from the article above. This sums everything up nicely. I hope this helps.

"They should always be agreed between IT and the business.
They should always be agreed between IT groups and the Service Desk.
They should direct further analysis, evaluation and routing, not attempt to diagnose root cause.
They should be as simple and easy to use as possible.
They should view things from a user perspective, not from an IT organization or technology viewpoint."

[Earl L]

Great article Aaron, thanks for that pointer. It's good to get a reminder about what the classification part of the incident process is really intended for.

We've had a horrible syndrome where I am, where the past system implementers had this compulsion to tie the categorization to the assignment groups (the cascading CTI model). While this sounds appealing at first it's fraught with problems, as the article spells out. If you happen to pick the wrong categorization, well good luck getting your tickets routed to the right assignment groups.

Not sure if this is improved in any way with the ServiceNow platform but it would be welcome to see more intelligence in the whole assignment/routing process.

Earl

[Kirk2]

One thing to keep in mind is why are we classifying incidents at all?
Whats the purpose of the classification and how does that "sorting" fit into your big picture.

One of the main reasons of classifying anything is to allow the creation of meaningful reports.
Look at what your requirements are for reporting and build out the functionality to meet those requirements.

We use the following cat's to classify our incidents;
Software
Hardware
Network
Application
Security

We do not use subcat at all on the incident form, we do however have all of our CI's identified very granularly. If your CI's are classified properly, maybe the incident classification is mute. You can not have a hardware failure incident on a ci classified as a database object, if it was a true hardware failure then the CI would have to be the server or the disk the database resides on. The database object might be a symptom of a broader outage.
This allows us to report on software outages and hardware outages without referencing the incident classifications.

This works for us, you need to figure out what works for you.

[Earl L]

Wow, you have all of your CI's identified to a granular level? That's impressive. Well done! We're not that mature unfortunately.

We're trying to sort out what is going to work for us, that's exactly why I opened up this question/poll. We've had varying levels of success with the different classification schemes we've used over the years and since we're new to ServiceNow we thought it would be a good time to review/revamp if necessary. We may do an overhaul and we may make a few tweaks.

On your point of classifying for reports, that's clearly one of the goals and ultimate outcomes of classification. But that has to be balanced with getting people's support needs (incidents) routed to where they need to go quickly and accurately. This is where we struggle. I believe the best classification is done by people, not systems. Systems can help, but some folks in our organization would like the system to just handle it. This is a dangerous place to go in my opinion. So I'm trying to find a good balance between the system and the human interaction.

Earl

[Kirk2]

You have your work cut out for you. It's a big process and we are learning that SNOW does not get down to the granular level that we require. Their CMDB is not that mature and we had to do quite a bit of customization to fit our requirements.
As an example, OOB they track DB instances and catalogs but it stops there. We get down to the stored procedures, sql tables, catalogs, views, etc..
We approached our classifications from the back end. How do we report on, ??? then whats the classification that needs to be in place to allow us to report on that. It seemed to be an easier approach for us.
Good luck.