While we don't have the service affected identified in the incident, problem, change, etc. (end even if we do, I'd love to have categorization within the affected service) how can one route everything properly if not using the categorization. I have seen months spent by managements to determine proper categorization, and either way they end with too few or too many. My present approach is to embed the actual service (as per service catalog) into the 2'd level of categorization, keep the first to reduce the choices, and use 3'd and further to define specifics. This way you can throw everything from level 2 below in the hands of the service managers to define what they need.
Regards, Nicky Madjarov phone: 973-202-4278 Find out how to bust your AR System performance @ http://www.SpeedUpARS.com ----- Original Message ----- From: Rick Cook Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Sent: Thursday, April 09, 2009 11:29 AM Subject: Re: Product Categorizations and the Elephant Rhyme ** You're right as usual, Chris. But she said that they were already using Categorizations for Assignment. While testing paradigms is a practice we should all undertake, changing the entire support model is an undertaking that requires buy-in from all users and owners of the Support model. It doesn't sound like Jennifer's organization has those things in place. Categorizations are not REQUIRED for ITSM 7 Assignments to function. However, they may be required for the structure of your Support Organization to function, and they may be required for current reporting purposes. Just because you set the Cats from templates doesn't mean that they aren't being used, just that the values are automatically chosen. The broken "2000 Op Cats" situation (which is not at all abnormal, BTW) is precisely why I cut through the Gordian knot with my idea for generic Op Cats. The bottom line is that the tool and the ITIL protocols are there to support the organization, not the other way around. Can the Support model change? Sure. Whether it should is for each company to decide. Rick On Thu, Apr 9, 2009 at 8:10 AM, strauss <stra...@unt.edu> wrote: ** I’m going to have to challenge your assumptions here, just as mine were when we first began testing the 7.x applications several years ago. I’m not sure that in 7.x it is a best practice to key on CTI anymore; the app basically discards it as a requirement, and the new 7.x assignment engine doesn’t even support it very well, not when compared to the very specific ways that CTI were processed in 3.x through 6.x applications. Based on our testing of the 7.x apps (where assignment rules using location and/or categorization no longer have reliable outcomes unless every rule is mutually exclusive) we decided to drop category as a determining factor, and key on Organization to tie our customers to a particular distributed support organization based upon their payroll accounting numbers. All tickets opened for a group of customers paid under one account (and assigned to a specific Organization in their location values) route to a particular distributed support organization by default, as set in an explicit assignment rule (there are ~25 desktop support organizations). When we have one Department in an Organization that needs a different routing than the others, the only way you can make that work in 7.x is to build separate, mutually exclusive assignment rules for EVERY Department in the Organization, not just the one that differs, or you will get inconsistent assignments. If you still want to incorporate CTI in the assignment processing, you will be forced to build all of the rules to be at the same level (C or T or I, not some combination of the same as pre-7.x) and make them mutually exclusive. Whatever you were using for 5.x or 6.x isn’t going to work. Our users are, quite frankly, much happier processing large quantities of tickets without any categorization at all, focusing on Assignment and occasionally Ownership. They only categorize them when they need to do so for reporting purposes, and we have facilitated that as much as possible by using a lot of Incident Templates to apply categorizations. They HATED the over 2,000 categorizations that we used in the 3x, 4x, and 5x systems, and don’t miss them at all in 7.x. The other way we have made this easy is to make a lot of the tickets entered through Kinetic Request use the same, pre-defined Incident templates, which can control not only the CTI but the assignment as well. Another factor in your use of categorization is going to be how your organization(s) does reporting. Here almost all reporting is by assigned and/or owner group, and was that way even when we had a VERY detailed categorization scheme. Our message to managers when we implemented 7.x was, if you want categories to report on, you will have to define the ones that are important to you (very few have), and then convince your IT staff to use them, as the 7.x app no longer enforces their use. Only the central helpdesk and a couple of the central support groups they work closely with have seen fit to define many CTIs, and they use them through Incident templates in order to help with their reporting. So in our perception, and in our analysis of the 7.x application behavior, CTI are no longer a driver for assignment, only for reporting. Don McClure did all of the testing on assignment rules, and will draft you a more detailed answer when he has a chance, but suffice it to say that the 7.x apps are no longer designed to use CTI as a primary driver for assignment, in part because they no longer do the kind of sequential matching that the earlier versions did that allowed you to make very specific automatic assignments based on different levels of the CTI data. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Meyer, Jennifer L Sent: Thursday, April 09, 2009 9:24 AM To: arslist@ARSLIST.ORG Subject: Product Categorizations and the Elephant Rhyme ** Listers, Please help me with this one. One of my management users got hold of an external source that said categorizations don’t have to be used for routing. Somehow, the user misunderstood what the external source was attempting to communicate, grabbed hold of the elephant’s tail, and is now trying to tell us we don’t need to use Incident assignment rules based on Operational and Product Categorizations to route tickets to the correct support group. Unfortunately, we route tickets in our system based on categorizations, but this user stubbornly clings to his part of the elephant. Of course, I have Rick Cook’s excellent “A New Paradigm of Generic Incident Classification,” BMC’s “Best Practices” documentation, and several other things I’ve dug up which refer obliquely to CTI (OpCats) and assignment. The problem is I ***KNOW*** CTI is used for assignment. You don’t have to use it for that, but I’ve been using it that way since 6.X. It’s so ingrained that I take it for granted that everybody else knows that, too. Does anybody have a best practices document that explicitly states that Incident assignment is based on categorization? Jennifer Meyer __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html_____Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
