Category/subcategory in incident
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-13-2013 09:26 PM
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
- Labels:
-
Incident Management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-14-2013 01:31 AM
Our system came pre-loaded with some best practice ITIL configs essentially its:
1. An incident can only be categorized 4 ways; Incident (default)/Request for Info/Request for change/Complaint
2. If its is an incident then there are 3 sub-types; incident Type: Parent/Unique (default)/Linked
3. Primary service and CI fields to tell us what service is affected and what component is broken (if an)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-14-2013 07:57 AM
Very interesting that you said what you did; "Our system came pre-loaded with some best practice ITIL configs". I was under the assumption that our incident configuration is the OOB setup and yet our cat/subcat items are very different.
For categories we have:
Request
Inquiry
Software
Hardware
Network
Database
For each of these choices the subcategories cascade/change depending on which category is selected.
What version of ServiceNow are you on, or did you start with? To see that your "pre-loaded" choices are so different from ours is very interesting indeed.
BTW, I checked the choice lists table to see how/when the entries got into our instance and they were placed there by the "system" user, so I'm assuming these are the standard OOB config. Please correct me if that assumption is wrong.
Earl
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-14-2013 08:29 AM
Hi Earl
A large amount of basic Incident/Change configuration was done by our partner who have their own ITIL best practice update package (I've since modified it for our needs)
To see a truly out of the box version you need to look at the demo's of ServiceNow.
Currently we are on Berlin but started on Aspen.
Personally i don't like categorizing an incident as a Hardware issue, to me that should be something filled in on resolution because the customer or help desk can't truly say what the root cause of the incident was until its resolved, entering it twice is a waste of time and duplicates what you already know.
Another point on your categories:
Request and Inquiry are "Types" of incident
Hardware, network, and database are "categories" of CI's if your linking CI 's into an incident then your duplicating data.
I suppose it comes down to what do you want to report on
Neil
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-14-2013 12:41 PM
Good comments Neil, I appreciate them very much. Our IM module cat/subcat are OOB, and match what is on the SN demo site. Not to say that it's right, it just is.
I like what you said about your config matching ITIL best practices. I'm going to look into that a little more and see where that takes me.
If you don't mind me asking, and if you can say, can you tell me who your services partner company is/was?
And like I said, this is really more of a poll kind of a question so if anyone else has anything they'd like to contribute to the discussion I'm all ears. Thanks!
Earl