Gidd (all),
Just my two cents here....
I have often found the separation of "Problem" from "Solution" to be
a critical difference. Often the problem that is described has little to do
with the real root cause. However, the "Solution" should always map to the
root cause. (After all if the Solution worked then the problem was fixed
with that solution. :)
So I favor the idea that the front line use two sets of "CTI" (Category
Type and Item) values.
This allows the HD to report what the problem was reported as "My
email does not work" and still allow them to record that the solution was
"Email Client setting change".
Some think that the CTI should be updated when the real problem is
identified. To some extent I agree. If the user says that they are having
network connectivity problems, and the "network" that is broke is their
ethernet cable then they are partially correct. However the solution to fix
a users ethernet cable is hardly going to be implemented by the same people
who would fix a "router down" problem. Both are truly network down issue.
However the group that will solve them will likely be very different.
However, if the problem is really the "wrong problem" then the
Problem CTI should be updated. (AKA: User said "My email is down today, It
worked yesterday." and you find that the users account was removed because
they were fired a month ago. A much different problem that may require
more legal actions to be taken than technical ones.)
This model allows a mapping of Problem to possible Solutions even
when the Solution may be created under a different CTI value.
Basically every helpdesk ticket that has a Problem CTI that is different
from the Solution CTI will be a new "cross key" for those CTI value. With
that you can suggest "other good CTI values to use to look for solutions".
(And since the solution CTI is a separate combination of fields you can
alter it as many times as you want without loosing your "starting point" of
the Problem CTI.)
In general it is a good idea to keep your CTI structures as small as
possible. However, the order/structure you want to us often varies based on
the purpose of the value. (AKA: How many "email related" problems did the
helpdesk record? Vs. How many tickets did the "Networking group" have to
respond to? To very different questions. However there may be some "email
related" problems because of a partial network outage. So finding the right
structure to store all of the possible data to do your reporting on (after
the fact) can be quite challenging. Especially when the question of "How
many tickets were assigned to one or more "wrong groups" before it was
resolved?" gets asked. That question is not answerable with only CTI
values. :)
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS=Action Request System(Remedy)
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
"Gidd Calden"
TIONS.NET> cc:
Sent by: "Action Subject: Re: Category and location levels
Request System
discussion
list(ARSList)"
ORG>
12/31/2002 09:56
AM
Please respond to
arslist
Jeff,
Points well taken ! Your observations validate my suggestion
concerning using an Excel pivot table to "SEE THIS". It has always
been my experience that the decision makers often cannot realize
the impact of adding additional levels because they cannot see how
it works. Opening a pivot table, adding a new Category and then
displaying the drill down usually visually exhibits the impact
immediately, saving countless hours of sometimes unnecessary Remedy
changes.
Regards...Gidd
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:ARSLIST@ARSLIST.ORG]On Behalf Of Jeff Hodges
Sent: Tuesday, December 31, 2002 7:29 AM
To: ARSLIST@ARSLIST.ORG
Subject: Re: Category and location levels
Emad,
What is the problem you are attempting to address by increasing the
hierarchy
of Category Type and Item.? If you have 3 levels and 8 choices per level
you
get 512 total choices. If you increase to 10 choices each level that's
1000
possible permutations. Adding another level gives 10000 choices. The
issue
with a complex hierarchy is the impact on the user making the selection.
Requiring users to choose from 4000~ 10000 choices is almost guaranteeing
that
you will not get a consistent response and even more important consistent
metrics. Unless the total hierarchy drives workflow, i.e. assignment,
escalation, task definition.... I would say keep the Category, Type and
Item
to
as few as necessary and then add additional fields to track the information
you
were going to add levels on. I like to use Cat, Type and Item to define
the
Service, i.e. what being performed and then use other field combinations to
define Where, When, Who , Why and How. Since Cat, Type and Item drive
assignment, approval, escalation and task definition your choices will
reflect
your organization.
-jeff
-----Original Message-----
From: emad.cybermak [SMTP:emad.cybermak@MAKHARAFI.NET]
Sent: Tuesday, December 31, 2002 1:01 AM
To: ARSLIST
Cc: emad.cybermak
Subject: Category and location levels
<< File: Category and location levels.HTM >>
You may control your subscription options, including UNSUBSCRIBE,and ACCESS
THE ARCHIVES at http://www.ARSLIST.org. For ARSList support, please send
eMail to support@arslist.org
You may control your subscription options, including UNSUBSCRIBE,and ACCESS
THE ARCHIVES at http://www.ARSLIST.org. For ARSList support, please send
eMail to support@arslist.org
You may control your subscription options, including UNSUBSCRIBE,and ACCESS THE ARCHIVES at http://www.ARSLIST.org. For ARSList support, please send eMail to support@arslist.org
Previous Topic
Index