Jennifer-- I do not know of such a document.  In fact, in ITSM 7.X that feature 
is not supported as one would like.

Basic set theory is at work here:  the assignment routine tries to match on a 
specific intersection (yes, set theory term, presumes all required terms are 
.true.) of ALL fields in the 'Routing Order' box where a value is entered.   
This transaction is a single set-theory 'union', where non-match of any one 
criteria sets a value of 'false'.  Refer to the 'Routing Order' section of 
Assignment Configuration-each box can have a value, and those left blank are 
presumed to be 'wildcard' (match anything) for the purpose of assignment.  The 
critera of 'Contact Company', 'Organization', 'Department', 'Category', 'Type', 
and 'Item' are all equally placed, NOT hierarchical, and a match on *all* is 
required to activate a particular assignment (of course, one field or more 
could match as a wildcard for that field only).

In our experience, if more than one rule COULD match, the rule selected from 
among matches is indeterminate-we have verified that behavior via filter/SQL 
logging more than once in our endeavors.

Therefore, the only way to guarantee *exactly* one rule match, is to make these 
assignment records mutually exclusive-so if one rule is generated for a 
combination of catagory/type/item within one 'contact' grouping, separate 
specific rules must be generated individually for ALL CTI within that contact. 
This principle also applies to grouping of operational CTI and product CTI-if 
one item is matched custom within product CTI and a particular operational CTI, 
separate rules are required for all other products within that operational CTI 
as well.

The situation simplifies greatly in absence of Multiple Tenancy;  if one only 
has one company, then this situation simplifies to JUST operational CTI and 
Product CTI.    Yes, this is a paradigm-shift from earlier HelpDesk 
versions....and I'll bet most of us did not want to get this far into set 
theory again.

Nicky and others-routing is simply an automation of an organization's selected 
processes.  Our tier-1 groups here at the University are first-responders for 
incidents for their designated customer base, independent of operational or 
product categorizations.  In fact, we usually prefer that customers NOT try to 
designate CTI-we see such designation as a support-staff function, and many 
user complaints on earlier HelpDesk versions centered on CTI being required by 
requestor on initial report!


Don W. McClure, P.E.
Applications Manager, Call Tracking Administration
University of North Texas
dwmac  (at)  unt (dot) edu

From: Action Request System discussion list(ARSList) 
[mailto:arsl...@arslist.org] On Behalf Of Nicky Madjarov
Sent: Thursday, April 09, 2009 11:15 AM
To: arslist@ARSLIST.ORG
Subject: Re: Product Categorizations and the Elephant Rhyme

**
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<mailto:remedyr...@gmail.com>
Newsgroups: public.remedy.arsystem.general
To: arslist@ARSLIST.ORG<mailto: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<mailto: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:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Meyer, 
Jennifer L
Sent: Thursday, April 09, 2009 9:24 AM
To: arslist@ARSLIST.ORG<mailto: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







_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"

Reply via email to