subject:"Categorizations"

I certainly understand.  These are some of the same questions/conversations
everyone has with their customers.  One challenge is that the Incident Type
field is a drop down field and requires a considerable amount of
customization to the OOB apps in order to change.  I believe this is tied to
something like 42 forms.  I have found that this field is very confusing to
most service desk people and not everything will fall into those 4 buckets.
This approach is for Tier 1 - Process Impacted, Tier 2 - Service/Service
Area/Procedure impacted, Tier 3 - Issue/Action impacted.  This is one of
many approaches.  The advantage of this approach is a customer can build
business rules and reporting around their process, procedures, and services.
There are significant advantages to this approach, but it might not be right
for everyone.  They are merely examples of what may be used.  I would love
if Incident Type was a configurable field along with Reported Source and
didn't require any modifications to the underlying system.  Unfortunately,
someone just starting out developing in Remedy may be quick to add values to
these drop down menus and not realize that if they only change it in one
spot a lot of things will break.

 

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Gmail
Sent: Friday, September 23, 2011 7:19 PM
To: arslist@ARSLIST.ORG
Subject: Re: Age old debate - categorizations

 

** 

Brian,

 

The examples below do not align with the tool. Basically, they seem to be
redundant. Why would you waste one category when  you can use the Incident
Type field to describe your incident type.  

 

(User Service Restoration, User Service Request, Infrastructure Event and so
on.)

 

From: Brian Pancia [mailto:panc...@finityit.com] 
Sent: Thursday, September 22, 2011 8:31 AM
Subject: Age old debate - categorizations

 

** 

This topic comes up every once and awhile on arslist.  I talked to a few
people at WWRUG that have really struggled with this.  I would be interested
to see if we can have people submit 5 examples of operational categorization
for Incident Management they use and why they chose the method.  In the end
we should end up with a pretty decent list that people can use when trying
to define categorizations.

 

Examples

 

Incident - Application - Error

Request - Password - Reset

Request - Question - How-To

Event - System - Approaching Threshold

Inquiry - Suspicious Activity - Malicious Code

 

I've used this approach to allow for reporting and setting business rules
per ITIL process (incident, request, event, and security management).  Tier
2 is for the what under each process and lines up with an organizations
services, technical areas, and key support areas.  Tier 3 is a simplified
explanation of the issue the user is calling about.

 

I continually try to come up with different ways to simplify the
categorization, so that it is useful to the business, but also easy enough
for the Service Desk people to quickly chose the right categorization for
the ticket.  I really appreciate everyone's input and insight.  I know this
is always a burning issue for new Remedy admin/developers to seasoned.

 

 

Brian Pancia
President

 

Finity IT, LLC

44081 Pipeline Plaza, Suite 100-5

Ashburn, VA 20147
Tel:  (571) 252-5090 x301
Fax: (571) 222-0043
brian.pan...@finityit.com

www.finityit.com <http://www.finityit.com/>  



Finity IT, LLC is a  Service Disabled Veteran Owned Small Business (SDVOSB).
Finity IT is a leading provider of IT Optimization services and solutions.
Specializing in Service Management, Enterprise Architecture, and Solutions
Arcitecture services.

 

DISCLAIMER:  The information contained in this e-mail and its attachments
contain confidential information belonging to the sender, which is legally
privileged.  The information is intended only for the use of the
recipient(s) named above.  If  you are not the intended recipient, you are
notified that any disclosure, copying, distribution or action in reliance
upon the contents of the information transmitted is strictly prohibited.  If
you have received this information in error, please delete it immediately.

 

 

_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_

_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ 


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Age old debate - categorizations

2011-09-23 Thread Gmail

Brian,

 

The examples below do not align with the tool. Basically, they seem to be
redundant. Why would you waste one category when  you can use the Incident
Type field to describe your incident type.  

 

(User Service Restoration, User Service Request, Infrastructure Event and so
on.)

 

From: Brian Pancia [mailto:panc...@finityit.com] 
Sent: Thursday, September 22, 2011 8:31 AM
Subject: Age old debate - categorizations

 

** 

This topic comes up every once and awhile on arslist.  I talked to a few
people at WWRUG that have really struggled with this.  I would be interested
to see if we can have people submit 5 examples of operational categorization
for Incident Management they use and why they chose the method.  In the end
we should end up with a pretty decent list that people can use when trying
to define categorizations.

 

Examples

 

Incident - Application - Error

Request - Password - Reset

Request - Question - How-To

Event - System - Approaching Threshold

Inquiry - Suspicious Activity - Malicious Code

 

I've used this approach to allow for reporting and setting business rules
per ITIL process (incident, request, event, and security management).  Tier
2 is for the what under each process and lines up with an organizations
services, technical areas, and key support areas.  Tier 3 is a simplified
explanation of the issue the user is calling about.

 

I continually try to come up with different ways to simplify the
categorization, so that it is useful to the business, but also easy enough
for the Service Desk people to quickly chose the right categorization for
the ticket.  I really appreciate everyone's input and insight.  I know this
is always a burning issue for new Remedy admin/developers to seasoned.

 

 

Brian Pancia
President

 

Finity IT, LLC

44081 Pipeline Plaza, Suite 100-5

Ashburn, VA 20147
Tel:  (571) 252-5090 x301
Fax: (571) 222-0043
brian.pan...@finityit.com

www.finityit.com <http://www.finityit.com/>  



Finity IT, LLC is a  Service Disabled Veteran Owned Small Business (SDVOSB).
Finity IT is a leading provider of IT Optimization services and solutions.
Specializing in Service Management, Enterprise Architecture, and Solutions
Arcitecture services.

 

DISCLAIMER:  The information contained in this e-mail and its attachments
contain confidential information belonging to the sender, which is legally
privileged.  The information is intended only for the use of the
recipient(s) named above.  If  you are not the intended recipient, you are
notified that any disclosure, copying, distribution or action in reliance
upon the contents of the information transmitted is strictly prohibited.  If
you have received this information in error, please delete it immediately.

 

 

_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Age old debate - categorizations

2011-09-23 Thread Pargeter, Christie :CO IS

Here is some we are using
 
Incident
Troubleshoot / Software
Troubleshoot / Database Services / Oracle
General Inquiry / Training
General Inquiry / Not Supported
Evaluate / Hardware / Memory Stick
Change
IMAC / Software
IMAC / Database Services / Oracle
Evaluate / Hardware / Memory Stick
Capital Project / Build_Remodel
Backup - Restore / Application



From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Brian Pancia
Sent: Friday, September 23, 2011 1:35 PM
To: arslist@ARSLIST.ORG
Subject: Re: Age old debate - categorizations


** 
Wow.  This is a great conversation.  I didn't mean to side rail this
into an ITIL processes conversation.  Just was curious on examples of
what other people are using as operational categorization.  I've spent a
lot of time over the years with a lot of clients on the sometimes
painful process of defining categorization.  I've seen a lot of
different ways to do categorization.  Usually one method will work for
some and won't work for others,  I was hoping that by getting a lot of
people to give 5 examples it would give everyone a solid set of examples
to try in their organization to see which method works best.  I'm always
asked if I have examples of categorization.  I have a sample list of
about 200 that I have that I will give out to clients as examples.  Some
are used all the time and some are used seldom.  
 
For password resest a few examples may be:
 
Reset - Account - Password
Request - Password - Reset
Account Management - Password - Reset
 
If seen all 3 work at various sites.
 
 
On Fri, Sep 23, 2011 at 12:17 PM, Tommy Morris
 wrote:


** 

Or longest signature J Man some of these government guys have
everything except their desk location and lunch box combination.

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Chowdhury, Tauf
Sent: Friday, September 23, 2011 10:52 AM
To: arslist@ARSLIST.ORG
Subject: OT: Age old debate - categorizations

 

** 

There needs to be a new award for next year's RUG for: "Wordiest
Posts!"

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Marsh, Lee
Sent: Friday, September 23, 2011 11:48 AM 

To: arslist@ARSLIST.ORG
Subject: Re: Age old debate - categorizations



 

** 

We generally use a template in remedy's incident management for
password unlocks and resets.  The Incident type is set to User Service
Request.  An incident is indicated by a service restoration either at
the user or infrastructure level.  Under ITIL and incident is
characterized by a service disruption.   With passwords maintenance the
security service is not disrupted it is working properly.  However, this
is a highly urgent service request because a user cannot work until the
service request is complete.   Another service request that generates
confusion is replacing toner cartridges although in today's printers
service may be down,  generally nothing is broke.  We have a template
for this in incident management that specifies this as an infrastructure
service request which and an operation categorization of "Resupply
consumable".

 

Our rule of thumb for Change is that if it requires an active
approval it needs to go through change management.  

 

Also we open security alerts as Problem Investigations because
we are looking for root cause or to verify the existence of a reported
"Known-error".   This root cause may spawn a change such as a new patch
release or other corrective action.   An incident is only opened if an
actual service disruption has occurred.  

 

 

* 
Lee Marsh 
Remedy Administrator

BAE Systems Office Automation Systems Team
Antitrust Division, U.S. Department of Justice

Phone:  202-305-9725 

Cell:  202-203-0036
Email: lee.ma...@usdoj.gov 
*

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Gard, Richard J 

Sent: Friday, September 23, 2011 11:07 AM
To: arslist@ARSLIST.ORG
Subject: Re: Age old debate - categorizations





 

** 

IMHO - it is neither Incident nor Change but a Service Request.
The password function is not broken; it is doing what it is supposed to
do by keeping you out when the password expires or is compromised. As
Rick said, you are not managing passwords as CIs. Service Requests offer
users a means to have someone doing something for you and provides the
ability to define a workf

Re: Age old debate - categorizations

2011-09-23 Thread Jan Lindhardsen

God how I love these discussions, there is always so many ways to do this, and 
only a couple of them is dead wrong... 
It's always very useful to see how other people have solved this!

Richard, Im completely on your track in regard to what is an Incident and what 
is a Service Request. But...
Consider that we, as some will argue, should register Incidents in IM, and 
Service Requests in SRM
Consider that we have a service desk, acting as a single point of contact, 
answering customers on the phone.
When a customer calls in with "printer not printing" issue, this is clearly an 
incident, and we will register it in IM.
When the customer calls in an says that he has forgotten his password, this 
should then be registered in SRM, but how? As we do not have a "backend" for 
registering Service Requests.
Also say that we would register this as work orders (not the same as a service 
request), it will be confusing and time consuming for the CSR to decide, and 
alway choose to start out in the right application.

Using IM to register both Incidents and Service Requests solves part of this 
issue, but from a pragmatic point of view, SR's has got nothing to do, being 
mixed up with my Incidents...

I had a long discussion with a customer a year back, where the customer argued 
that everything should start out as a service request, and then after the call 
(or during), the CSR has to decide if the SR should be "escalated" to an 
Incident, Change etc... Thank god I managed to talk him out of this! Not 
because he necessarily is wrong in his view on things, but because it would be 
more or less impossible to handle in ITSM/SRM as it is today, and it would just 
ad a huge extra layer of complexity and administration to the whole solution ;-)

And again, it will be interesting to see how the rest of you think around this, 
and how you have solved it in real life!

Best
/Jan

On Sep 23, 2011, at 17:06 , Gard, Richard J wrote:

> ** IMHO - it is neither Incident nor Change but a Service Request. The 
> password function is not broken; it is doing what it is supposed to do by 
> keeping you out when the password expires or is compromised. As Rick said, 
> you are not managing passwords as CIs. Service Requests offer users a means 
> to have someone doing something for you and provides the ability to define a 
> workflow where approvals and service fulfillment tasks need to be performed 
> separately (separation of duties is required in our banking environment).

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Age old debate - categorizations

Wow.  This is a great conversation.  I didn't mean to side rail this into an
ITIL processes conversation.  Just was curious on examples of what other
people are using as operational categorization.  I've spent a lot of time
over the years with a lot of clients on the sometimes painful process of
defining categorization.  I've seen a lot of different ways to do
categorization.  Usually one method will work for some and won't work for
others,  I was hoping that by getting a lot of people to give 5 examples it
would give everyone a solid set of examples to try in their organization to
see which method works best.  I'm always asked if I have examples of
categorization.  I have a sample list of about 200 that I have that I will
give out to clients as examples.  Some are used all the time and some are
used seldom.

For password resest a few examples may be:

Reset - Account - Password
Request - Password - Reset
Account Management - Password - Reset

If seen all 3 work at various sites.


On Fri, Sep 23, 2011 at 12:17 PM, Tommy Morris
wrote:

> **
>
> Or longest signature J Man some of these government guys have everything
> except their desk location and lunch box combination.
>
> ** **
>
> *From:* Action Request System discussion list(ARSList) [mailto:
> arslist@ARSLIST.ORG] *On Behalf Of *Chowdhury, Tauf
> *Sent:* Friday, September 23, 2011 10:52 AM
> *To:* arslist@ARSLIST.ORG
> *Subject:* OT: Age old debate - categorizations
>
> ** **
>
> ** 
>
> There needs to be a new award for next year’s RUG for: “Wordiest Posts!”**
> **
>
> ** **
>
> *From:* Action Request System discussion list(ARSList) [mailto:
> arslist@ARSLIST.ORG] *On Behalf Of *Marsh, Lee
> *Sent:* Friday, September 23, 2011 11:48 AM
>
> *To:* arslist@ARSLIST.ORG
> *Subject:* Re: Age old debate - categorizations
>
> ** **
>
> ** 
>
> We generally use a template in remedy’s incident management for password
> unlocks and resets.  The Incident type is set to User Service Request.  An
> incident is indicated by a service restoration either at the user or
> infrastructure level.  Under ITIL and incident is characterized by a service
> disruption.   With passwords maintenance the security service is not
> disrupted it is working properly.  However, this is a highly urgent service
> request because a user cannot work until the service request is complete.
> Another service request that generates confusion is replacing toner
> cartridges although in today’s printers service may be down,  generally
> nothing is broke.  We have a template for this in incident management that
> specifies this as an infrastructure service request which and an operation
> categorization of “Resupply consumable”.
>
> ** **
>
> Our rule of thumb for Change is that if it requires an active approval it
> needs to go through change management.  
>
> ** **
>
> Also we open security alerts as Problem Investigations because we are
> looking for root cause or to verify the existence of a reported
> “Known-error”.   This root cause may spawn a change such as a new patch
> release or other corrective action.   An incident is only opened if an
> actual service disruption has occurred.  
>
> ** **
>
>  
>
> ***
> Lee Marsh
> Remedy Administrator
>
> BAE Systems Office Automation Systems Team
> Antitrust Division, U.S. Department of Justice
>
> Phone:  202-305-9725 
>
> Cell:  *202-203-0036*
> Email: lee.ma...@usdoj.gov
> ***
>
> ** **
>
> *From:* Action Request System discussion list(ARSList) [mailto:
> arslist@ARSLIST.ORG] *On Behalf Of *Gard, Richard J
>
> *Sent:* Friday, September 23, 2011 11:07 AM
> *To:* arslist@ARSLIST.ORG
> *Subject:* Re: Age old debate - categorizations
>
>   ** **
>
> ** 
>
> IMHO - it is neither Incident nor Change but a Service Request. The
> password function is not broken; it is doing what it is supposed to do by
> keeping you out when the password expires or is compromised. As Rick said,
> you are not managing passwords as CIs. Service Requests offer users a means
> to have someone doing something for you and provides the ability to define a
> workflow where approvals and service fulfillment tasks need to be performed
> separately (separation of duties is required in our banking environment).
>
> For CTIs, I believe with 7.6.04 you can restrict/reduce CTIs presented to
> user based on the role of user. For example, since I do not manage mutual
> funds, I should not have to wade through mutual fund CTIs. However, with a
> properly organized Knowledge Base, I should be able to search for what I am
> looki

Re: Age old debate - categorizations

2011-09-23 Thread Tommy Morris

Or longest signature J Man some of these government guys have everything except 
their desk location and lunch box combination.

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Chowdhury, Tauf
Sent: Friday, September 23, 2011 10:52 AM
To: arslist@ARSLIST.ORG
Subject: OT: Age old debate - categorizations

** 

There needs to be a new award for next year’s RUG for: “Wordiest Posts!”

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Marsh, Lee
Sent: Friday, September 23, 2011 11:48 AM
To: arslist@ARSLIST.ORG
Subject: Re: Age old debate - categorizations

** 

We generally use a template in remedy’s incident management for password 
unlocks and resets.  The Incident type is set to User Service Request.  An 
incident is indicated by a service restoration either at the user or 
infrastructure level.  Under ITIL and incident is characterized by a service 
disruption.   With passwords maintenance the security service is not disrupted 
it is working properly.  However, this is a highly urgent service request 
because a user cannot work until the service request is complete.   Another 
service request that generates confusion is replacing toner cartridges although 
in today’s printers service may be down,  generally nothing is broke.  We have 
a template for this in incident management that specifies this as an 
infrastructure service request which and an operation categorization of 
“Resupply consumable”.

Our rule of thumb for Change is that if it requires an active approval it needs 
to go through change management.  

Also we open security alerts as Problem Investigations because we are looking 
for root cause or to verify the existence of a reported “Known-error”.   This 
root cause may spawn a change such as a new patch release or other corrective 
action.   An incident is only opened if an actual service disruption has 
occurred.  

* 
Lee Marsh 
Remedy Administrator

BAE Systems Office Automation Systems Team
Antitrust Division, U.S. Department of Justice

Phone:  202-305-9725 

Cell:  202-203-0036
Email: lee.ma...@usdoj.gov 
*

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Gard, Richard J
Sent: Friday, September 23, 2011 11:07 AM
To: arslist@ARSLIST.ORG
Subject: Re: Age old debate - categorizations

** 

IMHO - it is neither Incident nor Change but a Service Request. The password 
function is not broken; it is doing what it is supposed to do by keeping you 
out when the password expires or is compromised. As Rick said, you are not 
managing passwords as CIs. Service Requests offer users a means to have someone 
doing something for you and provides the ability to define a workflow where 
approvals and service fulfillment tasks need to be performed separately 
(separation of duties is required in our banking environment).

For CTIs, I believe with 7.6.04 you can restrict/reduce CTIs presented to user 
based on the role of user. For example, since I do not manage mutual funds, I 
should not have to wade through mutual fund CTIs. However, with a properly 
organized Knowledge Base, I should be able to search for what I am looking to 
do, and have the KM system provide the proper URL to launch the correct form 
with the correct CTI set. This is the direction we are taking and it seems to 
be a big improvement over having the user know exactly how to code the CTI to 
get we he(she) needs to go.
Regards,
Rich
Service Technology Development Manager
State Street Bank

From: Rick Cook [mailto:remedyr...@gmail.com] 
Sent: Friday, September 23, 2011 10:31 AM
To: arslist@ARSLIST.ORG  
Subject: Re: Age old debate - categorizations 

** 

I am not an ITIL expert, but it would seem that the dividing line between an 
Incident request and a Change request would be whether a change to a CI was 
required.  For a password reset, I think Incident.  Remember that Change 
Management is really Configuration Management - Management of the Configuration 
Items, which user accounts are not. 

Rick

On Sep 23, 2011 10:12 AM, "Brian Pancia"  wrote:
> Rick - very interesting. I have a situation right now where there is huge
> debate on what to track in each of the apps. Do requests belong in Incident
> Management? The debate in this situation is around password resets. This
> organization looks at them as requests and currently put them in the Change
> Management application. I personally would put them in the Incident
> Management application. The question would be are there requests that
> belong in the Incident Management app versus the Change Management app
> versus Work Orders? What about Event Management? High CPU or memory
> utilization probably does not cause service disruption and may or may not be
> a Problem if it is only 1 occurrence tha

Re: OT: Age old debate - categorizations

2011-09-23 Thread Rick Cook

One thing to keep in mind is that there isn't one perfect way to do this.
Like ITIL, there are some rules and some guidelines, but the rest should be
based on what works for your company.  So let's keep this a sharing of
ideas, and not let it descend into a Holy War of any kind.

Rick
On Sep 23, 2011 12:02 PM, "Chowdhury, Tauf"  wrote:
> There needs to be a new award for next year’s RUG for: “Wordiest Posts!”
>
>
>
> From: Action Request System discussion list(ARSList) [mailto:
arslist@ARSLIST.ORG] On Behalf Of Marsh, Lee
> Sent: Friday, September 23, 2011 11:48 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Age old debate - categorizations
>
>
>
> **
>
> We generally use a template in remedy’s incident management for password
unlocks and resets. The Incident type is set to User Service Request. An
incident is indicated by a service restoration either at the user or
infrastructure level. Under ITIL and incident is characterized by a service
disruption. With passwords maintenance the security service is not disrupted
it is working properly. However, this is a highly urgent service request
because a user cannot work until the service request is complete. Another
service request that generates confusion is replacing toner cartridges
although in today’s printers service may be down, generally nothing is
broke. We have a template for this in incident management that specifies
this as an infrastructure service request which and an operation
categorization of “Resupply consumable”.
>
>
>
> Our rule of thumb for Change is that if it requires an active approval it
needs to go through change management.
>
>
>
> Also we open security alerts as Problem Investigations because we are
looking for root cause or to verify the existence of a reported
“Known-error”. This root cause may spawn a change such as a new patch
release or other corrective action. An incident is only opened if an actual
service disruption has occurred.
>
>
>
>
>
> *
> Lee Marsh
> Remedy Administrator
>
> BAE Systems Office Automation Systems Team
> Antitrust Division, U.S. Department of Justice
>
> Phone: 202-305-9725
>
> Cell: 202-203-0036
> Email: lee.ma...@usdoj.gov
> *
>
>
>
> From: Action Request System discussion list(ARSList) [mailto:
arslist@ARSLIST.ORG] On Behalf Of Gard, Richard J
> Sent: Friday, September 23, 2011 11:07 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Age old debate - categorizations
>
>
>
> **
>
> IMHO - it is neither Incident nor Change but a Service Request. The
password function is not broken; it is doing what it is supposed to do by
keeping you out when the password expires or is compromised. As Rick said,
you are not managing passwords as CIs. Service Requests offer users a means
to have someone doing something for you and provides the ability to define a
workflow where approvals and service fulfillment tasks need to be performed
separately (separation of duties is required in our banking environment).
>
> For CTIs, I believe with 7.6.04 you can restrict/reduce CTIs presented to
user based on the role of user. For example, since I do not manage mutual
funds, I should not have to wade through mutual fund CTIs. However, with a
properly organized Knowledge Base, I should be able to search for what I am
looking to do, and have the KM system provide the proper URL to launch the
correct form with the correct CTI set. This is the direction we are taking
and it seems to be a big improvement over having the user know exactly how
to code the CTI to get we he(she) needs to go.
> Regards,
> Rich
> Service Technology Development Manager
> State Street Bank
>
>
> From: Rick Cook [mailto:remedyr...@gmail.com]
> Sent: Friday, September 23, 2011 10:31 AM
> To: arslist@ARSLIST.ORG 
> Subject: Re: Age old debate - categorizations
>
>
> **
>
> I am not an ITIL expert, but it would seem that the dividing line between
an Incident request and a Change request would be whether a change to a CI
was required. For a password reset, I think Incident. Remember that Change
Management is really Configuration Management - Management of the
Configuration Items, which user accounts are not.
>
> Rick
>
> On Sep 23, 2011 10:12 AM, "Brian Pancia"  wrote:
>> Rick - very interesting. I have a situation right now where there is huge
>> debate on what to track in each of the apps. Do requests belong in
Incident
>> Management? The debate in this situation is around password resets. This
>> organization looks at them as requests and currently put them in the
Change
>> Management application. I personally would put them in the Incident
>> Management application. The question would be are there requests that
>>

OT: Age old debate - categorizations

2011-09-23 Thread Chowdhury, Tauf

There needs to be a new award for next year’s RUG for: “Wordiest Posts!”

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Marsh, Lee
Sent: Friday, September 23, 2011 11:48 AM
To: arslist@ARSLIST.ORG
Subject: Re: Age old debate - categorizations

** 

We generally use a template in remedy’s incident management for password 
unlocks and resets.  The Incident type is set to User Service Request.  An 
incident is indicated by a service restoration either at the user or 
infrastructure level.  Under ITIL and incident is characterized by a service 
disruption.   With passwords maintenance the security service is not disrupted 
it is working properly.  However, this is a highly urgent service request 
because a user cannot work until the service request is complete.   Another 
service request that generates confusion is replacing toner cartridges although 
in today’s printers service may be down,  generally nothing is broke.  We have 
a template for this in incident management that specifies this as an 
infrastructure service request which and an operation categorization of 
“Resupply consumable”.

Our rule of thumb for Change is that if it requires an active approval it needs 
to go through change management.  

Also we open security alerts as Problem Investigations because we are looking 
for root cause or to verify the existence of a reported “Known-error”.   This 
root cause may spawn a change such as a new patch release or other corrective 
action.   An incident is only opened if an actual service disruption has 
occurred.  

* 
Lee Marsh 
Remedy Administrator

BAE Systems Office Automation Systems Team
Antitrust Division, U.S. Department of Justice

Phone:  202-305-9725 

Cell:  202-203-0036
Email: lee.ma...@usdoj.gov 
*

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Gard, Richard J
Sent: Friday, September 23, 2011 11:07 AM
To: arslist@ARSLIST.ORG
Subject: Re: Age old debate - categorizations

** 

IMHO - it is neither Incident nor Change but a Service Request. The password 
function is not broken; it is doing what it is supposed to do by keeping you 
out when the password expires or is compromised. As Rick said, you are not 
managing passwords as CIs. Service Requests offer users a means to have someone 
doing something for you and provides the ability to define a workflow where 
approvals and service fulfillment tasks need to be performed separately 
(separation of duties is required in our banking environment).

For CTIs, I believe with 7.6.04 you can restrict/reduce CTIs presented to user 
based on the role of user. For example, since I do not manage mutual funds, I 
should not have to wade through mutual fund CTIs. However, with a properly 
organized Knowledge Base, I should be able to search for what I am looking to 
do, and have the KM system provide the proper URL to launch the correct form 
with the correct CTI set. This is the direction we are taking and it seems to 
be a big improvement over having the user know exactly how to code the CTI to 
get we he(she) needs to go.
Regards,
Rich
Service Technology Development Manager
State Street Bank

From: Rick Cook [mailto:remedyr...@gmail.com] 
Sent: Friday, September 23, 2011 10:31 AM
To: arslist@ARSLIST.ORG  
Subject: Re: Age old debate - categorizations 

** 

I am not an ITIL expert, but it would seem that the dividing line between an 
Incident request and a Change request would be whether a change to a CI was 
required.  For a password reset, I think Incident.  Remember that Change 
Management is really Configuration Management - Management of the Configuration 
Items, which user accounts are not. 

Rick

On Sep 23, 2011 10:12 AM, "Brian Pancia"  wrote:
> Rick - very interesting. I have a situation right now where there is huge
> debate on what to track in each of the apps. Do requests belong in Incident
> Management? The debate in this situation is around password resets. This
> organization looks at them as requests and currently put them in the Change
> Management application. I personally would put them in the Incident
> Management application. The question would be are there requests that
> belong in the Incident Management app versus the Change Management app
> versus Work Orders? What about Event Management? High CPU or memory
> utilization probably does not cause service disruption and may or may not be
> a Problem if it is only 1 occurrence that was caused by something like a
> large import of data into a database. What about Security Incident
> Handling? Security events typically start of as a request to investigate
> some type of suspicious activity. Once the investigation is complete it is
> then determined whether it is an Incident or not. Which app would this
> start off in?
> 
>

Re: Age old debate - categorizations

2011-09-23 Thread Chowdhury, Tauf

My 2 cents on this as I have had to set the strategy for our organization to 
normalize, harmonize, integrate, and de-confuse (is that even a word?) in 
understanding the difference and similarities between CTI, Service Catalog 
(front end), and CMDB service modeling. It’s a lot to type so maybe if a few of 
you want to jump on a conference call, I can arrange something with a webex so 
it can be almost a workshop. I’d love to have Rick on it. Let me know if you 
folks are interested. I think at the very least, it would be a great 
conversation to have. 

To tackle the question about password resets being recorded within 
Incident/Change management, it really is a separation in thinking about the 
tool which is Remedy and the ITIL processes of incident/change/request 
fulfillment. The first thing is to understand that everything is really a 
change. However, it all depends on how much scrutiny you want to put on certain 
changes. For example, let’s take changing a user account’s password. If that 
user account is for an individual employee, your organization may decide or 
assume that it is so low risk, that the only scrutiny it requires is of the 
technician performing the change. Hence, you may decide that changing a user’s 
password can be handled within the Incident management module as a service 
request that does not require any scrutiny or approval. However, if the user 
account for which you are changing a password is a service account that runs 
your entire SAP HR and FICO system, than you may want more scrutiny in which 
you would put the same type of password change request through the Change 
Management system because then, you have others who will scrutinize and approve 
the change and not just the technician. 

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Gard, Richard J
Sent: Friday, September 23, 2011 11:07 AM
To: arslist@ARSLIST.ORG
Subject: Re: Age old debate - categorizations

** 

IMHO - it is neither Incident nor Change but a Service Request. The password 
function is not broken; it is doing what it is supposed to do by keeping you 
out when the password expires or is compromised. As Rick said, you are not 
managing passwords as CIs. Service Requests offer users a means to have someone 
doing something for you and provides the ability to define a workflow where 
approvals and service fulfillment tasks need to be performed separately 
(separation of duties is required in our banking environment).

For CTIs, I believe with 7.6.04 you can restrict/reduce CTIs presented to user 
based on the role of user. For example, since I do not manage mutual funds, I 
should not have to wade through mutual fund CTIs. However, with a properly 
organized Knowledge Base, I should be able to search for what I am looking to 
do, and have the KM system provide the proper URL to launch the correct form 
with the correct CTI set. This is the direction we are taking and it seems to 
be a big improvement over having the user know exactly how to code the CTI to 
get we he(she) needs to go.
Regards,
Rich
Service Technology Development Manager
State Street Bank

From: Rick Cook [mailto:remedyr...@gmail.com] 
Sent: Friday, September 23, 2011 10:31 AM
To: arslist@ARSLIST.ORG  
Subject: Re: Age old debate - categorizations 

** 

I am not an ITIL expert, but it would seem that the dividing line between an 
Incident request and a Change request would be whether a change to a CI was 
required.  For a password reset, I think Incident.  Remember that Change 
Management is really Configuration Management - Management of the Configuration 
Items, which user accounts are not. 

Rick

On Sep 23, 2011 10:12 AM, "Brian Pancia"  wrote:
> Rick - very interesting. I have a situation right now where there is huge
> debate on what to track in each of the apps. Do requests belong in Incident
> Management? The debate in this situation is around password resets. This
> organization looks at them as requests and currently put them in the Change
> Management application. I personally would put them in the Incident
> Management application. The question would be are there requests that
> belong in the Incident Management app versus the Change Management app
> versus Work Orders? What about Event Management? High CPU or memory
> utilization probably does not cause service disruption and may or may not be
> a Problem if it is only 1 occurrence that was caused by something like a
> large import of data into a database. What about Security Incident
> Handling? Security events typically start of as a request to investigate
> some type of suspicious activity. Once the investigation is complete it is
> then determined whether it is an Incident or not. Which app would this
> start off in?
> 
> 
> 
> So this brings up a bit of a dilemma when defining op cats. If we look at
> just the Incident Management ap

Re: Age old debate - categorizations

2011-09-23 Thread Marsh, Lee

We generally use a template in remedy’s incident management for password 
unlocks and resets.  The Incident type is set to User Service Request.  An 
incident is indicated by a service restoration either at the user or 
infrastructure level.  Under ITIL and incident is characterized by a service 
disruption.   With passwords maintenance the security service is not disrupted 
it is working properly.  However, this is a highly urgent service request 
because a user cannot work until the service request is complete.   Another 
service request that generates confusion is replacing toner cartridges although 
in today’s printers service may be down,  generally nothing is broke.  We have 
a template for this in incident management that specifies this as an 
infrastructure service request which and an operation categorization of 
“Resupply consumable”.

Our rule of thumb for Change is that if it requires an active approval it needs 
to go through change management.  

Also we open security alerts as Problem Investigations because we are looking 
for root cause or to verify the existence of a reported “Known-error”.   This 
root cause may spawn a change such as a new patch release or other corrective 
action.   An incident is only opened if an actual service disruption has 
occurred.  

* 
Lee Marsh 
Remedy Administrator

BAE Systems Office Automation Systems Team
Antitrust Division, U.S. Department of Justice

Phone:  202-305-9725 

Cell:  202-203-0036
Email: lee.ma...@usdoj.gov 
*

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Gard, Richard J
Sent: Friday, September 23, 2011 11:07 AM
To: arslist@ARSLIST.ORG
Subject: Re: Age old debate - categorizations

** 

IMHO - it is neither Incident nor Change but a Service Request. The password 
function is not broken; it is doing what it is supposed to do by keeping you 
out when the password expires or is compromised. As Rick said, you are not 
managing passwords as CIs. Service Requests offer users a means to have someone 
doing something for you and provides the ability to define a workflow where 
approvals and service fulfillment tasks need to be performed separately 
(separation of duties is required in our banking environment).

For CTIs, I believe with 7.6.04 you can restrict/reduce CTIs presented to user 
based on the role of user. For example, since I do not manage mutual funds, I 
should not have to wade through mutual fund CTIs. However, with a properly 
organized Knowledge Base, I should be able to search for what I am looking to 
do, and have the KM system provide the proper URL to launch the correct form 
with the correct CTI set. This is the direction we are taking and it seems to 
be a big improvement over having the user know exactly how to code the CTI to 
get we he(she) needs to go.
Regards,
Rich
Service Technology Development Manager
State Street Bank

From: Rick Cook [mailto:remedyr...@gmail.com] 
Sent: Friday, September 23, 2011 10:31 AM
To: arslist@ARSLIST.ORG  
Subject: Re: Age old debate - categorizations 

** 

I am not an ITIL expert, but it would seem that the dividing line between an 
Incident request and a Change request would be whether a change to a CI was 
required.  For a password reset, I think Incident.  Remember that Change 
Management is really Configuration Management - Management of the Configuration 
Items, which user accounts are not. 

Rick

On Sep 23, 2011 10:12 AM, "Brian Pancia"  wrote:
> Rick - very interesting. I have a situation right now where there is huge
> debate on what to track in each of the apps. Do requests belong in Incident
> Management? The debate in this situation is around password resets. This
> organization looks at them as requests and currently put them in the Change
> Management application. I personally would put them in the Incident
> Management application. The question would be are there requests that
> belong in the Incident Management app versus the Change Management app
> versus Work Orders? What about Event Management? High CPU or memory
> utilization probably does not cause service disruption and may or may not be
> a Problem if it is only 1 occurrence that was caused by something like a
> large import of data into a database. What about Security Incident
> Handling? Security events typically start of as a request to investigate
> some type of suspicious activity. Once the investigation is complete it is
> then determined whether it is an Incident or not. Which app would this
> start off in?
> 
> 
> 
> So this brings up a bit of a dilemma when defining op cats. If we look at
> just the Incident Management application what do we track in there? If we
> just track incidents then why under Incident Type is there "User Service
> Request"? These are some of the questions I have

Re: Age old debate - categorizations

2011-09-23 Thread Gard, Richard J

IMHO - it is neither Incident nor Change but a Service Request. The password 
function is not broken; it is doing what it is supposed to do by keeping you 
out when the password expires or is compromised. As Rick said, you are not 
managing passwords as CIs. Service Requests offer users a means to have someone 
doing something for you and provides the ability to define a workflow where 
approvals and service fulfillment tasks need to be performed separately 
(separation of duties is required in our banking environment).

For CTIs, I believe with 7.6.04 you can restrict/reduce CTIs presented to user 
based on the role of user. For example, since I do not manage mutual funds, I 
should not have to wade through mutual fund CTIs. However, with a properly 
organized Knowledge Base, I should be able to search for what I am looking to 
do, and have the KM system provide the proper URL to launch the correct form 
with the correct CTI set. This is the direction we are taking and it seems to 
be a big improvement over having the user know exactly how to code the CTI to 
get we he(she) needs to go.
Regards,
Rich
Service Technology Development Manager
State Street Bank

From: Rick Cook [mailto:remedyr...@gmail.com]
Sent: Friday, September 23, 2011 10:31 AM
To: arslist@ARSLIST.ORG 
Subject: Re: Age old debate - categorizations

**

I am not an ITIL expert, but it would seem that the dividing line between an 
Incident request and a Change request would be whether a change to a CI was 
required.  For a password reset, I think Incident.  Remember that Change 
Management is really Configuration Management - Management of the Configuration 
Items, which user accounts are not.

Rick

On Sep 23, 2011 10:12 AM, "Brian Pancia" 
mailto:panc...@finityit.com>> wrote:
> Rick - very interesting. I have a situation right now where there is huge
> debate on what to track in each of the apps. Do requests belong in Incident
> Management? The debate in this situation is around password resets. This
> organization looks at them as requests and currently put them in the Change
> Management application. I personally would put them in the Incident
> Management application. The question would be are there requests that
> belong in the Incident Management app versus the Change Management app
> versus Work Orders? What about Event Management? High CPU or memory
> utilization probably does not cause service disruption and may or may not be
> a Problem if it is only 1 occurrence that was caused by something like a
> large import of data into a database. What about Security Incident
> Handling? Security events typically start of as a request to investigate
> some type of suspicious activity. Once the investigation is complete it is
> then determined whether it is an Incident or not. Which app would this
> start off in?
>
>
>
> So this brings up a bit of a dilemma when defining op cats. If we look at
> just the Incident Management application what do we track in there? If we
> just track incidents then why under Incident Type is there "User Service
> Request"? These are some of the questions I have faced from customers when
> defining op cats.
>
>
>
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Rick 
> Cook
> Sent: Friday, September 23, 2011 9:39 AM
> To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>
> Subject: Re: Age old debate - categorizations
>
>
>
> ** Actually, things like
>
> Update - Employee - Payroll
>
> Remove - Employee - Benefits
>
> Add - Employee - Training
>
> Update - Employee - Record
>
> In Process - Employee - Badge
>
> would be better tracked as Business Services. So the OpCats associated with
> those would be to Add/Update/Remove --> Account --> Application. The
> ProdCats would list the application, and the Service would sync up with
> those combinations to the degree that the Service Catalog had been
> configured to do so.
>
> This list:
>
> Monitor - Hardware - Server, Router, Switch
>
> Investigate - Improper Usage - Policy
>
> Remediate - Unauthorized Access - Network
>
> Mitigate - Data Spill - Classified Data
>
> don't seem like Incidents, because there is no service interruption being
> remediated. These seem like either Problems, Changes, or Requests. I hope
> one day to expand my document to cover those, but it is not in its present
> state intended for anything more than Incident.
>
> Rick
>
> On Fri, Sep 23, 2011 at 9:27 AM, Brian Pancia 
> mailto:panc...@finityit.com>> wrote:
>
> **
>
> Rick's white paper can be found here:
>
>
>
> https://communities.bmc.com/communities/docs/DOC-3231#comment-3060
>
>
>
> Rick great white pa

Re: Age old debate - categorizations

2011-09-23 Thread Rick Cook

I am not an ITIL expert, but it would seem that the dividing line between an
Incident request and a Change request would be whether a change to a CI was
required.  For a password reset, I think Incident.  Remember that Change
Management is really Configuration Management - Management of the
Configuration Items, which user accounts are not.

Rick
On Sep 23, 2011 10:12 AM, "Brian Pancia"  wrote:
> Rick - very interesting. I have a situation right now where there is huge
> debate on what to track in each of the apps. Do requests belong in
Incident
> Management? The debate in this situation is around password resets. This
> organization looks at them as requests and currently put them in the
Change
> Management application. I personally would put them in the Incident
> Management application. The question would be are there requests that
> belong in the Incident Management app versus the Change Management app
> versus Work Orders? What about Event Management? High CPU or memory
> utilization probably does not cause service disruption and may or may not
be
> a Problem if it is only 1 occurrence that was caused by something like a
> large import of data into a database. What about Security Incident
> Handling? Security events typically start of as a request to investigate
> some type of suspicious activity. Once the investigation is complete it is
> then determined whether it is an Incident or not. Which app would this
> start off in?
>
>
>
> So this brings up a bit of a dilemma when defining op cats. If we look at
> just the Incident Management application what do we track in there? If we
> just track incidents then why under Incident Type is there "User Service
> Request"? These are some of the questions I have faced from customers when
> defining op cats.
>
>
>
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook
> Sent: Friday, September 23, 2011 9:39 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Age old debate - categorizations
>
>
>
> ** Actually, things like
>
> Update - Employee - Payroll
>
> Remove - Employee - Benefits
>
> Add - Employee - Training
>
> Update - Employee - Record
>
> In Process - Employee - Badge
>
> would be better tracked as Business Services. So the OpCats associated
with
> those would be to Add/Update/Remove --> Account --> Application. The
> ProdCats would list the application, and the Service would sync up with
> those combinations to the degree that the Service Catalog had been
> configured to do so.
>
> This list:
>
> Monitor - Hardware - Server, Router, Switch
>
> Investigate - Improper Usage - Policy
>
> Remediate - Unauthorized Access - Network
>
> Mitigate - Data Spill - Classified Data
>
> don't seem like Incidents, because there is no service interruption being
> remediated. These seem like either Problems, Changes, or Requests. I hope
> one day to expand my document to cover those, but it is not in its present
> state intended for anything more than Incident.
>
> Rick
>
> On Fri, Sep 23, 2011 at 9:27 AM, Brian Pancia 
wrote:
>
> **
>
> Rick's white paper can be found here:
>
>
>
> https://communities.bmc.com/communities/docs/DOC-3231#comment-3060
>
>
>
> Rick great white paper with some sound advice for people implementing the
> ITSM Suite. I'm curious to see more examples from everyone though. The
> challenge I am seeing is that the ITSM Suite is taking a shift into
> enterprise solutions that are used by some of the groups that support IT
> like HR, Finance, Telco, and Security. In a lot of instances these
> groups/services fall under a single company or are shared across multiple
> companies. The current ITSM Suite is setup for a 1 Company or Global
> approach and isn't tied to a specific service.
>
>
>
> Based on your white paper is this how you would structure HR tickets?
>
>
>
> Update - Employee - Payroll
>
> Remove - Employee - Benefits
>
> Add - Employee - Training
>
> Update - Employee - Record
>
> In Process - Employee - Badge
>
>
>
> A common process I have seen handled in the ITSM Suite is employee In/Out
> Processing. So a lot of these are incorporated with things like:
>
>
>
> Install - Hardware - Phone
>
> Install - Hardware - Desktop
>
> Add - Access - Network
>
> Add - Access - Building
>
>
>
> Another area that has grown is web based apps/portals. Would you recommend
> things like:
>
>
>
> Repair - Website - Portal
>
> Add - Access - Portal
>
>
>
> Another challenge is incorporating SOCs and NOCs that mainly monitor
stuff.
> Would you recommend things l

Re: Age old debate - categorizations

2011-09-23 Thread Luttmann, Michael W Mr CTR DISA CD553

I have worked on systems that use both methods, and found the
"verb-noun-noun" to be most confusing for most users.  How can you be
certain that the verb you just chose will get you to the system you are
looking for by the time you reach Tier 3?  

I prefer a methodology of "General to specific":

- Start with a general category of "Application" (or "Application
Management"), "Accounts", "System", etc.
- Then branch to something more specific, such as "Maintenance", "New
Functionality", "Decommission", etc.
- Then end with a verb: Add, Modify, Delete, Troubleshoot, Upgrade, etc.

(I've also seen where the Application NAME is put in Tier 2.  That's an
option if your system is NOT big on using Product Categorizations.)

But that's just me.

Brian is also correct that the OpCats can be filtered via the Incident
type (User Service Request vs. Service Restoration, etc.), but I've not
yet seen where that helps the common end user - it just adds to the
complexity of creating the ticket.

But that's just me.

Mike Luttmann
DISA Remedy Engineer


-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Brian Pancia
Sent: Friday, September 23, 2011 8:12
To: arslist@ARSLIST.ORG
Subject: Re: Age old debate - categorizations

** 

Rick - very interesting.  I have a situation right now where there is
huge debate on what to track in each of the apps.  Do requests belong in
Incident Management?  The debate in this situation is around password
resets.  This organization looks at them as requests and currently put
them in the Change Management application.  I personally would put them
in the Incident Management application.  The question would be are there
requests that belong in the Incident Management app versus the Change
Management app versus Work Orders?  What about Event Management?  High
CPU or memory utilization probably does not cause service disruption and
may or may not be a Problem if it is only 1 occurrence that was caused
by something like a large import of data into a database.  What about
Security Incident Handling?  Security events typically start of as a
request to investigate some type of suspicious activity.  Once the
investigation is complete it is then determined whether it is an
Incident or not.  Which app would this start off in?

 

So this brings up a bit of a dilemma when defining op cats.  If we look
at just the Incident Management application what do we track in there?
If we just track incidents then why under Incident Type is there "User
Service Request"?  These are some of the questions I have faced from
customers when defining op cats. 

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook
Sent: Friday, September 23, 2011 9:39 AM
To: arslist@ARSLIST.ORG
Subject: Re: Age old debate - categorizations

 

** Actually, things like 

Update - Employee - Payroll

Remove - Employee - Benefits

Add - Employee - Training

Update - Employee - Record

In Process - Employee - Badge

would be better tracked as Business Services.  So the OpCats associated
with those would be to Add/Update/Remove --> Account --> Application.
The ProdCats would list the application, and the Service would sync up
with those combinations to the degree that the Service Catalog had been
configured to do so.

This list:

Monitor - Hardware - Server, Router, Switch

Investigate - Improper Usage - Policy

Remediate - Unauthorized Access - Network

Mitigate - Data Spill - Classified Data

don't seem like Incidents, because there is no service interruption
being remediated.  These seem like either Problems, Changes, or
Requests.  I hope one day to expand my document to cover those, but it
is not in its present state intended for anything more than Incident.

Rick

On Fri, Sep 23, 2011 at 9:27 AM, Brian Pancia 
wrote:

** 

Rick's white paper can be found here:

 

https://communities.bmc.com/communities/docs/DOC-3231#comment-3060

 

Rick great white paper with some sound advice for people implementing
the ITSM Suite.  I'm curious to see more examples from everyone though.
The challenge I am seeing is that the ITSM Suite is taking a shift into
enterprise solutions that are used by some of the groups that support IT
like HR, Finance, Telco, and Security.  In a lot of instances these
groups/services fall under a single company or are shared across
multiple companies.  The current ITSM Suite is setup for a 1 Company or
Global approach and isn't tied to a specific service.  

 

Based on your white paper is this how you would structure HR tickets?

 

Update - Employee - Payroll

Remove - Employee - Benefits

Add - Employee - Training

Update - Employee - Record

In Process - Employee - Badge

 

A common process I have seen handled in the ITSM Suite is employee
In/Out

Re: Age old debate - categorizations

Rick - very interesting.  I have a situation right now where there is huge
debate on what to track in each of the apps.  Do requests belong in Incident
Management?  The debate in this situation is around password resets.  This
organization looks at them as requests and currently put them in the Change
Management application.  I personally would put them in the Incident
Management application.  The question would be are there requests that
belong in the Incident Management app versus the Change Management app
versus Work Orders?  What about Event Management?  High CPU or memory
utilization probably does not cause service disruption and may or may not be
a Problem if it is only 1 occurrence that was caused by something like a
large import of data into a database.  What about Security Incident
Handling?  Security events typically start of as a request to investigate
some type of suspicious activity.  Once the investigation is complete it is
then determined whether it is an Incident or not.  Which app would this
start off in?

 

So this brings up a bit of a dilemma when defining op cats.  If we look at
just the Incident Management application what do we track in there?  If we
just track incidents then why under Incident Type is there "User Service
Request"?  These are some of the questions I have faced from customers when
defining op cats. 

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook
Sent: Friday, September 23, 2011 9:39 AM
To: arslist@ARSLIST.ORG
Subject: Re: Age old debate - categorizations

 

** Actually, things like 

Update - Employee - Payroll

Remove - Employee - Benefits

Add - Employee - Training

Update - Employee - Record

In Process - Employee - Badge

would be better tracked as Business Services.  So the OpCats associated with
those would be to Add/Update/Remove --> Account --> Application.  The
ProdCats would list the application, and the Service would sync up with
those combinations to the degree that the Service Catalog had been
configured to do so.

This list:

Monitor - Hardware - Server, Router, Switch

Investigate - Improper Usage - Policy

Remediate - Unauthorized Access - Network

Mitigate - Data Spill - Classified Data

don't seem like Incidents, because there is no service interruption being
remediated.  These seem like either Problems, Changes, or Requests.  I hope
one day to expand my document to cover those, but it is not in its present
state intended for anything more than Incident.

Rick

On Fri, Sep 23, 2011 at 9:27 AM, Brian Pancia  wrote:

** 

Rick's white paper can be found here:

 

https://communities.bmc.com/communities/docs/DOC-3231#comment-3060

 

Rick great white paper with some sound advice for people implementing the
ITSM Suite.  I'm curious to see more examples from everyone though.  The
challenge I am seeing is that the ITSM Suite is taking a shift into
enterprise solutions that are used by some of the groups that support IT
like HR, Finance, Telco, and Security.  In a lot of instances these
groups/services fall under a single company or are shared across multiple
companies.  The current ITSM Suite is setup for a 1 Company or Global
approach and isn't tied to a specific service.  

 

Based on your white paper is this how you would structure HR tickets?

 

Update - Employee - Payroll

Remove - Employee - Benefits

Add - Employee - Training

Update - Employee - Record

In Process - Employee - Badge

 

A common process I have seen handled in the ITSM Suite is employee In/Out
Processing.  So a lot of these are incorporated with things like:

 

Install - Hardware - Phone

Install - Hardware - Desktop

Add - Access - Network

Add - Access - Building

 

Another area that has grown is web based apps/portals.  Would you recommend
things like:

 

Repair - Website - Portal

Add - Access - Portal

 

Another challenge is incorporating SOCs and NOCs that mainly monitor stuff.
Would you recommend things like:

 

Monitor - Hardware - Server, Router, Switch

Investigate - Improper Usage - Policy

Remediate - Unauthorized Access - Network

Mitigate - Data Spill - Classified Data

 

Marcelo it does appear that the use of services is becoming more and more
import and less importance on operational categorization.  Does this mean
that with the use of the services field one can just use tier 1 of the op
cats as - Failure, Add, Remove, Modify and incorporate the prod cats for the
specific product or sub services that is provided?  Based on the product we
would know that it is Hardware - Desktop, so would we need this in the tier
2 and 3 of the op cats?

 

 

Brian

 

 

 

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook
Sent: Thursday, September 22, 2011 9:11 AM
To: arslist@ARSLIST.ORG
Subject: Re: Age old debate - categorizations

 

** 

The "I want you to Opcat1 the Opcat1 on my Opcat3" method is actual

Re: Age old debate - categorizations

2011-09-23 Thread Rick Cook

Actually, things like

Update - Employee - Payroll

Remove - Employee - Benefits

Add - Employee - Training

Update - Employee - Record
In Process - Employee - Badge

would be better tracked as Business Services.  So the OpCats associated with
those would be to Add/Update/Remove --> Account --> Application.  The
ProdCats would list the application, and the Service would sync up with
those combinations to the degree that the Service Catalog had been
configured to do so.

This list:

Monitor - Hardware - Server, Router, Switch

Investigate - Improper Usage - Policy

Remediate - Unauthorized Access - Network
Mitigate - Data Spill - Classified Data

don't seem like Incidents, because there is no service interruption being
remediated.  These seem like either Problems, Changes, or Requests.  I hope
one day to expand my document to cover those, but it is not in its present
state intended for anything more than Incident.

Rick

On Fri, Sep 23, 2011 at 9:27 AM, Brian Pancia  wrote:

> **
>
> Rick's white paper can be found here:
>
> ** **
>
> https://communities.bmc.com/communities/docs/DOC-3231#comment-3060
>
> ** **
>
> Rick great white paper with some sound advice for people implementing the
> ITSM Suite.  I'm curious to see more examples from everyone though.  The
> challenge I am seeing is that the ITSM Suite is taking a shift into
> enterprise solutions that are used by some of the groups that support IT
> like HR, Finance, Telco, and Security.  In a lot of instances these
> groups/services fall under a single company or are shared across multiple
> companies.  The current ITSM Suite is setup for a 1 Company or Global
> approach and isn't tied to a specific service.  
>
> ** **
>
> Based on your white paper is this how you would structure HR tickets?
>
> ** **
>
> Update - Employee - Payroll
>
> Remove - Employee - Benefits
>
> Add - Employee - Training
>
> Update - Employee - Record
>
> In Process - Employee - Badge
>
> ** **
>
> A common process I have seen handled in the ITSM Suite is employee In/Out
> Processing.  So a lot of these are incorporated with things like:
>
> ** **
>
> Install - Hardware - Phone
>
> Install - Hardware - Desktop
>
> Add - Access - Network
>
> Add - Access - Building
>
> ** **
>
> Another area that has grown is web based apps/portals.  Would you recommend
> things like:
>
> ** **
>
> Repair - Website - Portal
>
> Add - Access - Portal
>
> ** **
>
> Another challenge is incorporating SOCs and NOCs that mainly monitor
> stuff.  Would you recommend things like:
>
> ** **
>
> Monitor - Hardware - Server, Router, Switch
>
> Investigate - Improper Usage - Policy
>
> Remediate - Unauthorized Access - Network
>
> Mitigate - Data Spill - Classified Data
>
> ** **
>
> Marcelo it does appear that the use of services is becoming more and more
> import and less importance on operational categorization.  Does this mean
> that with the use of the services field one can just use tier 1 of the op
> cats as - Failure, Add, Remove, Modify and incorporate the prod cats for the
> specific product or sub services that is provided?  Based on the product we
> would know that it is Hardware - Desktop, so would we need this in the tier
> 2 and 3 of the op cats?
>
> ** **
>
> ** **
>
> Brian
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Action Request System discussion list(ARSList) [mailto:
> arslist@ARSLIST.ORG] *On Behalf Of *Rick Cook
> *Sent:* Thursday, September 22, 2011 9:11 AM
> *To:* arslist@ARSLIST.ORG
> *Subject:* Re: Age old debate - categorizations
>
> ** **
>
> ** 
>
> The "I want you to Opcat1 the Opcat1 on my Opcat3" method is actually from
> my white paper.  There are some frills and dressings therein, though. 
>
> Rick
>
> On Sep 22, 2011 9:05 AM, "Martinez, Marcelo A"  wrote:
> > Rick,
> > I am interested in reading your whitepaper. I will go look for it.
> >
> > We started (from BMC's recommendation) verb-noun-noun schema... then
> switched to noun-noun-verb (again per BMC's recommendation). A few months
> ago @ one of the training sessions I attended, the recommendation (from BMC)
> was "I want to   on my __."
> >
> > I always wondered how BMC really intended the Tiers to work.. after all,
> they must have built the canned reports around a few of the category
> structures.. no? There must be a reason why Tier 1 is mandatory but not Tier
> 2 or 3... many quest

Re: Age old debate - categorizations

Rick's white paper can be found here:

https://communities.bmc.com/communities/docs/DOC-3231#comment-3060

Rick great white paper with some sound advice for people implementing the
ITSM Suite.  I'm curious to see more examples from everyone though.  The
challenge I am seeing is that the ITSM Suite is taking a shift into
enterprise solutions that are used by some of the groups that support IT
like HR, Finance, Telco, and Security.  In a lot of instances these
groups/services fall under a single company or are shared across multiple
companies.  The current ITSM Suite is setup for a 1 Company or Global
approach and isn't tied to a specific service.  

Based on your white paper is this how you would structure HR tickets?

Update - Employee - Payroll

Remove - Employee - Benefits

Add - Employee - Training

Update - Employee - Record

In Process - Employee - Badge

A common process I have seen handled in the ITSM Suite is employee In/Out
Processing.  So a lot of these are incorporated with things like:

Install - Hardware - Phone

Install - Hardware - Desktop

Add - Access - Network

Add - Access - Building

Another area that has grown is web based apps/portals.  Would you recommend
things like:

Repair - Website - Portal

Add - Access - Portal

Another challenge is incorporating SOCs and NOCs that mainly monitor stuff.
Would you recommend things like:

Monitor - Hardware - Server, Router, Switch

Investigate - Improper Usage - Policy

Remediate - Unauthorized Access - Network

Mitigate - Data Spill - Classified Data

Marcelo it does appear that the use of services is becoming more and more
import and less importance on operational categorization.  Does this mean
that with the use of the services field one can just use tier 1 of the op
cats as - Failure, Add, Remove, Modify and incorporate the prod cats for the
specific product or sub services that is provided?  Based on the product we
would know that it is Hardware - Desktop, so would we need this in the tier
2 and 3 of the op cats?

Brian

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook
Sent: Thursday, September 22, 2011 9:11 AM
To: arslist@ARSLIST.ORG
Subject: Re: Age old debate - categorizations

** 

The "I want you to Opcat1 the Opcat1 on my Opcat3" method is actually from
my white paper.  There are some frills and dressings therein, though. 

Rick

On Sep 22, 2011 9:05 AM, "Martinez, Marcelo A"  wrote:
> Rick,
> I am interested in reading your whitepaper. I will go look for it.
> 
> We started (from BMC's recommendation) verb-noun-noun schema... then
switched to noun-noun-verb (again per BMC's recommendation). A few months
ago @ one of the training sessions I attended, the recommendation (from BMC)
was "I want to   on my __."
> 
> I always wondered how BMC really intended the Tiers to work.. after all,
they must have built the canned reports around a few of the category
structures.. no? There must be a reason why Tier 1 is mandatory but not Tier
2 or 3... many questions, that I never got an answer for.
> 
> BTW, ITSM 7.6.04 --- IMO, BMC has steered away from heavy use of the
categorization, instead, they rely more on "services", no?
> 
> Now to go look for that doc... (Thanks Rick!)
> 
> Marcelo
> 
> From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook
> Sent: Thursday, September 22, 2011 7:36 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Age old debate - categorizations
> 
> **
> 
> I would suggest that you read my white paper on the subject. It is
available on the BMCDN.
> 
> Rick
> On Sep 22, 2011 8:31 AM, "Brian Pancia"
mailto:panc...@finityit.com>> wrote:
>> This topic comes up every once and awhile on arslist. I talked to a few
>> people at WWRUG that have really struggled with this. I would be
interested
>> to see if we can have people submit 5 examples of operational
categorization
>> for Incident Management they use and why they chose the method. In the
end
>> we should end up with a pretty decent list that people can use when
trying
>> to define categorizations.
>>
>>
>>
>> Examples
>>
>>
>>
>> Incident - Application - Error
>>
>> Request - Password - Reset
>>
>> Request - Question - How-To
>>
>> Event - System - Approaching Threshold
>>
>> Inquiry - Suspicious Activity - Malicious Code
>>
>>
>>
>> I've used this approach to allow for reporting and setting business rules
>> per ITIL process (incident, request, event, and security management).
Tier
>> 2 is for the what under each process and lines up with an organizations
>>

Re: Age old debate - categorizations

2011-09-22 Thread Rick Cook

The "I want you to Opcat1 the Opcat1 on my Opcat3" method is actually from
my white paper.  There are some frills and dressings therein, though.

Rick
On Sep 22, 2011 9:05 AM, "Martinez, Marcelo A"  wrote:
> Rick,
> I am interested in reading your whitepaper. I will go look for it.
>
> We started (from BMC's recommendation) verb-noun-noun schema... then
switched to noun-noun-verb (again per BMC's recommendation). A few months
ago @ one of the training sessions I attended, the recommendation (from BMC)
was "I want to   on my __."
>
> I always wondered how BMC really intended the Tiers to work.. after all,
they must have built the canned reports around a few of the category
structures.. no? There must be a reason why Tier 1 is mandatory but not Tier
2 or 3... many questions, that I never got an answer for.
>
> BTW, ITSM 7.6.04 --- IMO, BMC has steered away from heavy use of the
categorization, instead, they rely more on "services", no?
>
> Now to go look for that doc... (Thanks Rick!)
>
> Marcelo
>
> From: Action Request System discussion list(ARSList) [mailto:
arslist@ARSLIST.ORG] On Behalf Of Rick Cook
> Sent: Thursday, September 22, 2011 7:36 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Age old debate - categorizations
>
> **
>
> I would suggest that you read my white paper on the subject. It is
available on the BMCDN.
>
> Rick
> On Sep 22, 2011 8:31 AM, "Brian Pancia" > wrote:
>> This topic comes up every once and awhile on arslist. I talked to a few
>> people at WWRUG that have really struggled with this. I would be
interested
>> to see if we can have people submit 5 examples of operational
categorization
>> for Incident Management they use and why they chose the method. In the
end
>> we should end up with a pretty decent list that people can use when
trying
>> to define categorizations.
>>
>>
>>
>> Examples
>>
>>
>>
>> Incident - Application - Error
>>
>> Request - Password - Reset
>>
>> Request - Question - How-To
>>
>> Event - System - Approaching Threshold
>>
>> Inquiry - Suspicious Activity - Malicious Code
>>
>>
>>
>> I've used this approach to allow for reporting and setting business rules
>> per ITIL process (incident, request, event, and security management).
Tier
>> 2 is for the what under each process and lines up with an organizations
>> services, technical areas, and key support areas. Tier 3 is a simplified
>> explanation of the issue the user is calling about.
>>
>>
>>
>> I continually try to come up with different ways to simplify the
>> categorization, so that it is useful to the business, but also easy
enough
>> for the Service Desk people to quickly chose the right categorization for
>> the ticket. I really appreciate everyone's input and insight. I know this
>> is always a burning issue for new Remedy admin/developers to seasoned.
>>
>>
>>
>>
>>
>> Brian Pancia
>> President
>>
>>
>>
>> Finity IT, LLC
>>
>> 44081 Pipeline Plaza, Suite 100-5
>>
>> Ashburn, VA 20147
>> Tel: (571) 252-5090 x301
>> Fax: (571) 222-0043
>> <mailto:brian.pan...@finityit.com<mailto:brian.pan...@finityit.com>>
brian.pan...@finityit.com<mailto:brian.pan...@finityit.com>
>>
>>
>>
>> <http://www.finityit.com/> www.finityit.com<http://www.finityit.com>
>>
>>
>>
>> Finity IT, LLC is a Service Disabled Veteran Owned Small Business
(SDVOSB).
>> Finity IT is a leading provider of IT Optimization services and
solutions.
>> Specializing in Service Management, Enterprise Architecture, and
Solutions
>> Arcitecture services.
>>
>>
>>
>> DISCLAIMER: The information contained in this e-mail and its attachments
>> contain confidential information belonging to the sender, which is
legally
>> privileged. The information is intended only for the use of the
>> recipient(s) named above. If you are not the intended recipient, you are
>> notified that any disclosure, copying, distribution or action in reliance
>> upon the contents of the information transmitted is strictly prohibited.
If
>> you have received this information in error, please delete it
immediately.
>>
>>
>>
>>
>>
>>
>>
___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<
http://www.arslist.org>
>> attend wwrug11 www.wwrug.com<http://www.wwrug.com> ARSList: "Where the
Answers Are"
> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_
>
>
___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Age old debate - categorizations

2011-09-22 Thread Martinez, Marcelo A

Rick,
I am interested in reading your whitepaper. I will go look for it.

We started (from BMC's recommendation) verb-noun-noun schema... then switched 
to noun-noun-verb (again per BMC's recommendation).  A few months ago @ one of 
the training sessions I attended, the recommendation (from BMC) was "I want to 
  on my __."

I always wondered how BMC really intended the Tiers to work.. after all, they 
must have built the canned reports around a few of the category structures.. 
no? There must be a reason why Tier 1 is mandatory but not Tier 2 or 3...  many 
questions, that I never got an answer for.

BTW, ITSM 7.6.04 --- IMO, BMC has steered away from heavy use of the 
categorization, instead, they rely more on "services", no?

Now to go look for that doc... (Thanks Rick!)

Marcelo

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook
Sent: Thursday, September 22, 2011 7:36 AM
To: arslist@ARSLIST.ORG
Subject: Re: Age old debate - categorizations

**

I would suggest that you read my white paper on the subject.  It is available 
on the BMCDN.

Rick
On Sep 22, 2011 8:31 AM, "Brian Pancia" 
mailto:panc...@finityit.com>> wrote:
> This topic comes up every once and awhile on arslist. I talked to a few
> people at WWRUG that have really struggled with this. I would be interested
> to see if we can have people submit 5 examples of operational categorization
> for Incident Management they use and why they chose the method. In the end
> we should end up with a pretty decent list that people can use when trying
> to define categorizations.
>
>
>
> Examples
>
>
>
> Incident - Application - Error
>
> Request - Password - Reset
>
> Request - Question - How-To
>
> Event - System - Approaching Threshold
>
> Inquiry - Suspicious Activity - Malicious Code
>
>
>
> I've used this approach to allow for reporting and setting business rules
> per ITIL process (incident, request, event, and security management). Tier
> 2 is for the what under each process and lines up with an organizations
> services, technical areas, and key support areas. Tier 3 is a simplified
> explanation of the issue the user is calling about.
>
>
>
> I continually try to come up with different ways to simplify the
> categorization, so that it is useful to the business, but also easy enough
> for the Service Desk people to quickly chose the right categorization for
> the ticket. I really appreciate everyone's input and insight. I know this
> is always a burning issue for new Remedy admin/developers to seasoned.
>
>
>
>
>
> Brian Pancia
> President
>
>
>
> Finity IT, LLC
>
> 44081 Pipeline Plaza, Suite 100-5
>
> Ashburn, VA 20147
> Tel: (571) 252-5090 x301
> Fax: (571) 222-0043
> <mailto:brian.pan...@finityit.com<mailto:brian.pan...@finityit.com>> 
> brian.pan...@finityit.com<mailto:brian.pan...@finityit.com>
>
>
>
> <http://www.finityit.com/> www.finityit.com<http://www.finityit.com>
>
>
>
> Finity IT, LLC is a Service Disabled Veteran Owned Small Business (SDVOSB).
> Finity IT is a leading provider of IT Optimization services and solutions.
> Specializing in Service Management, Enterprise Architecture, and Solutions
> Arcitecture services.
>
>
>
> DISCLAIMER: The information contained in this e-mail and its attachments
> contain confidential information belonging to the sender, which is legally
> privileged. The information is intended only for the use of the
> recipient(s) named above. If you are not the intended recipient, you are
> notified that any disclosure, copying, distribution or action in reliance
> upon the contents of the information transmitted is strictly prohibited. If
> you have received this information in error, please delete it immediately.
>
>
>
>
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at 
> www.arslist.org<http://www.arslist.org>
> attend wwrug11 www.wwrug.com<http://www.wwrug.com> ARSList: "Where the 
> Answers Are"
_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Age old debate - categorizations

2011-09-22 Thread Rick Cook

I would suggest that you read my white paper on the subject.  It is
available on the BMCDN.

Rick
On Sep 22, 2011 8:31 AM, "Brian Pancia"  wrote:
> This topic comes up every once and awhile on arslist. I talked to a few
> people at WWRUG that have really struggled with this. I would be
interested
> to see if we can have people submit 5 examples of operational
categorization
> for Incident Management they use and why they chose the method. In the end
> we should end up with a pretty decent list that people can use when trying
> to define categorizations.
>
>
>
> Examples
>
>
>
> Incident - Application - Error
>
> Request - Password - Reset
>
> Request - Question - How-To
>
> Event - System - Approaching Threshold
>
> Inquiry - Suspicious Activity - Malicious Code
>
>
>
> I've used this approach to allow for reporting and setting business rules
> per ITIL process (incident, request, event, and security management). Tier
> 2 is for the what under each process and lines up with an organizations
> services, technical areas, and key support areas. Tier 3 is a simplified
> explanation of the issue the user is calling about.
>
>
>
> I continually try to come up with different ways to simplify the
> categorization, so that it is useful to the business, but also easy enough
> for the Service Desk people to quickly chose the right categorization for
> the ticket. I really appreciate everyone's input and insight. I know this
> is always a burning issue for new Remedy admin/developers to seasoned.
>
>
>
>
>
> Brian Pancia
> President
>
>
>
> Finity IT, LLC
>
> 44081 Pipeline Plaza, Suite 100-5
>
> Ashburn, VA 20147
> Tel: (571) 252-5090 x301
> Fax: (571) 222-0043
> <mailto:brian.pan...@finityit.com> brian.pan...@finityit.com
>
>
>
> <http://www.finityit.com/> www.finityit.com
>
>
>
> Finity IT, LLC is a Service Disabled Veteran Owned Small Business
(SDVOSB).
> Finity IT is a leading provider of IT Optimization services and solutions.
> Specializing in Service Management, Enterprise Architecture, and Solutions
> Arcitecture services.
>
>
>
> DISCLAIMER: The information contained in this e-mail and its attachments
> contain confidential information belonging to the sender, which is legally
> privileged. The information is intended only for the use of the
> recipient(s) named above. If you are not the intended recipient, you are
> notified that any disclosure, copying, distribution or action in reliance
> upon the contents of the information transmitted is strictly prohibited.
If
> you have received this information in error, please delete it immediately.
>
>
>
>
>
>
>
___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Age old debate - categorizations

2011-09-22 Thread Brian Pancia

This topic comes up every once and awhile on arslist.  I talked to a few
people at WWRUG that have really struggled with this.  I would be interested
to see if we can have people submit 5 examples of operational categorization
for Incident Management they use and why they chose the method.  In the end
we should end up with a pretty decent list that people can use when trying
to define categorizations.

 

Examples

 

Incident - Application - Error

Request - Password - Reset

Request - Question - How-To

Event - System - Approaching Threshold

Inquiry - Suspicious Activity - Malicious Code

 

I've used this approach to allow for reporting and setting business rules
per ITIL process (incident, request, event, and security management).  Tier
2 is for the what under each process and lines up with an organizations
services, technical areas, and key support areas.  Tier 3 is a simplified
explanation of the issue the user is calling about.

 

I continually try to come up with different ways to simplify the
categorization, so that it is useful to the business, but also easy enough
for the Service Desk people to quickly chose the right categorization for
the ticket.  I really appreciate everyone's input and insight.  I know this
is always a burning issue for new Remedy admin/developers to seasoned.

 

 

Brian Pancia
President

 

Finity IT, LLC

44081 Pipeline Plaza, Suite 100-5

Ashburn, VA 20147
Tel:  (571) 252-5090 x301
Fax: (571) 222-0043
 <mailto:brian.pan...@finityit.com> brian.pan...@finityit.com



 <http://www.finityit.com/> www.finityit.com 



Finity IT, LLC is a  Service Disabled Veteran Owned Small Business (SDVOSB).
Finity IT is a leading provider of IT Optimization services and solutions.
Specializing in Service Management, Enterprise Architecture, and Solutions
Arcitecture services.

 

DISCLAIMER:  The information contained in this e-mail and its attachments
contain confidential information belonging to the sender, which is legally
privileged.  The information is intended only for the use of the
recipient(s) named above.  If  you are not the intended recipient, you are
notified that any disclosure, copying, distribution or action in reliance
upon the contents of the information transmitted is strictly prohibited.  If
you have received this information in error, please delete it immediately.

 

 


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

SRM 7.6.02 Navigational Categorizations

2011-08-05 Thread Gmail

In versions prior to SRM 7.6.00,  SRM:Navigational Category form was a
regular form that was used for bulk upload navigational categorizations. I
noticed that in SRM 7.6.02 this form is a Display only form. Is anyone aware
of which form has replaced SRM:Navigational Category? How can we bulk upload
our nav cats and which form is used to do that now?

 

Thanks,

Moe

http://remedycloud.com

 


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Restricting Operational Categorizations

2011-05-15 Thread Yair Mayer

Hey,

One possible way is setting your specific Categorization to work only under
a certain Type of incident(for example, Infrastructure Event), the one
coming through integration workflow.
Although that's a possibility only if its not used by others.

Another way would be adding a field to the join form CFG:Service Catalog
LookUp - the Description Field from CFG:Service Catalog.
then, add description to the categorizations(in Service catalog)
"integration" or "notforuse" or just "rabbits".
Last - temper with the qual for menu/table where support people select the
categorizations excluding showing them in the list(Dialog view - HPD Catalog
List if from there, CFG:CTL:S1-HPD-Q and sub menus if menus.. or whichever
of the other ways to access that list that they use)

... But really, simplest way is the "DO NOT USE" method.

Hopefully you won't break anything if you do end up trying this(let me know
how it went if you do)

Cheers,
Yair

On Sat, May 14, 2011 at 7:59 PM, James Chafin wrote:

> **
> I made Tier 1 "DO NOT USE" and moved Tier 1 to Tier 2 and combined Tier 2 >
> Tier 3 into Tier 3
>
> Sent from my Verizon Wireless BlackBerry
> --
> *From: * Gmail 
> *Sender: * "Action Request System discussion list(ARSList)" <
> arslist@ARSLIST.ORG>
> *Date: *Sat, 14 May 2011 11:04:44 -0400
> *To: *
> *ReplyTo: * arslist@ARSLIST.ORG
> *Subject: *Restricting Operational Categorizations
>
> We have created an assignment rule for one of our integrations and it works
> fine. However, support people from time to time, accidently open tickets
> against this set of operational categorizations resulting in those tickets
> being sent to the same support group that handles the tickets coming
> directly via the integration.
>
>
>
> Is there any way to hide those operational categorizations from the drop
> down and yet have them “Enabled” for the integration workflow?
>
>
>
> Regards,
>
> Mohamed Abdelaziz
> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Restricting Operational Categorizations

2011-05-14 Thread James Chafin

I made Tier 1 "DO NOT USE" and moved Tier 1 to Tier 2 and combined Tier 2 > 
Tier 3 into Tier 3 

Sent from my Verizon Wireless BlackBerry

-Original Message-
From: Gmail 
Sender: "Action Request System discussion list(ARSList)" 
Date: Sat, 14 May 2011 11:04:44 
To: 
Reply-to: arslist@ARSLIST.ORG
Subject: Restricting Operational Categorizations

We have created an assignment rule for one of our integrations and it works
fine. However, support people from time to time, accidently open tickets
against this set of operational categorizations resulting in those tickets
being sent to the same support group that handles the tickets coming
directly via the integration.

Is there any way to hide those operational categorizations from the drop
down and yet have them "Enabled" for the integration workflow?

Regards,

Mohamed Abdelaziz

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Restricting Operational Categorizations

2011-05-14 Thread Gmail

We have created an assignment rule for one of our integrations and it works
fine. However, support people from time to time, accidently open tickets
against this set of operational categorizations resulting in those tickets
being sent to the same support group that handles the tickets coming
directly via the integration.

 

Is there any way to hide those operational categorizations from the drop
down and yet have them "Enabled" for the integration workflow?

 

Regards,

Mohamed Abdelaziz


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Best practices for loading categorizations

2010-11-17 Thread SriSamSri Appecherla

Hi,

I have to implement CMDB from the scratch. Please help me with the
following:

What are the best practices for creating Product and Operational
Categorizations? How should the Product Categorizations be loaded into CMDB?
Is it possible through discovery?

CMDB 7.5

Regards,
SriSamSri Appecherla
Mobile# +91 991 610 6008

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Product Categorizations and the Elephant Rhyme

2009-04-13 Thread Gareth Oliver

I've followed this thread with interest. Although not directly related
to why categorisations should be used for assignments, there are other
reasons that Op/Prod Cats should be used.
 
- KPIs that will allow the measurement of the effectiveness & efficiency
the IT services provided, the state of the infrastructure, and the
processes themselves  e.g. avg incident response/resolution times,
assignment "bounce"
- Reporting of the KPI's
- And obviously, the assignment and workflow process. Ideally you're
using the Op/ProdCat to support the auto-assignment in order to get the
Incident to the correct place the first time, thereby reducing the need
to "bounce" the incident to another queue if it is assigned incorrectly.
 
The last thing that should be considered in the arguement is the
"initial" vs "actual" Op/Prod Cat. The initial could be considered as
the Op/ProdCat captured on the Classification tab However when the
incident was resolved, the Op/Prod Cat on the Resolution tab captures
the "actual". E.g. we initially thought the incident was caused by a
network outage, but the actual cause was the user failed to turn on
their PC (with appropriate Op/Prod Cats to support both).
 
So, although not answering your specific question around Op/Prod Cats &
Assignments, there are other benefits of why Op/Cats are useful to use.
 
BTW if you haven't seen it already, take a look at thenew Incident
screen on ITSM7.5 - the Op/Prod Cat fields are nowhere to be seen on the
new "Best Practice" view.
 



From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of Meyer, Jennifer L
Sent: Friday, 10 April 2009 12:24 AM
To: ARSList
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___ 

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"

Re: Product Categorizations and the Elephant Rhyme

2009-04-13 Thread Meyer, Jennifer L

Thank you, Don, that does help.


Jennifer Meyer

Remedy Technical Support Specialist

State of North Carolina

Office Of Information Technology Services

Service Delivery Division

ITSM & ITAM Services

Office: 919-754-6543

ITS Service Desk: 919-754-6000

jennifer.me...@its.nc.gov<mailto:jennifer.me...@its.nc.gov>

http://its.state.nc.us



E-mail correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties only by an 
authorized State Official.


From: Action Request System discussion list(ARSList) 
[mailto:arsl...@arslist.org] On Behalf Of McClure, Don
Sent: Monday, April 13, 2009 10:47 AM
To: arslist@ARSLIST.ORG
Subject: Re: Product Categorizations and the Elephant Rhyme

Hi Jennifer,

I am answering this question for Chris Strauss.

Short answer on keying off Site, is No.

We key off customer organization/department-by legacy University practice.  
Therefore, the tier-1 support will be furnished by whatever support group is 
tasked to support that department (in the usage of Organization/Department 
within a Customer company).  Added granularity is required for some 
Administration organizations, where one department among several is supported 
by, say, group 2 whereas everyone else under that higher-order entity is 
support by group 1.  Then, I have built rules for all departments within that 
organization to guarantee full apportionment.  For many groups on campus, rules 
at the Organization (or even Company!) level are sufficient.

This triage frequently aligns with physical location-but not completely, and 
'Site' is not our criteria.

I hope this helps clarify our implementation.


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

_Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"

Re: Product Categorizations and the Elephant Rhyme

2009-04-13 Thread McClure, Don

Hi Jennifer,

I am answering this question for Chris Strauss.

Short answer on keying off Site, is No.

We key off customer organization/department-by legacy University practice.  
Therefore, the tier-1 support will be furnished by whatever support group is 
tasked to support that department (in the usage of Organization/Department 
within a Customer company).  Added granularity is required for some 
Administration organizations, where one department among several is supported 
by, say, group 2 whereas everyone else under that higher-order entity is 
support by group 1.  Then, I have built rules for all departments within that 
organization to guarantee full apportionment.  For many groups on campus, rules 
at the Organization (or even Company!) level are sufficient.

This triage frequently aligns with physical location-but not completely, and 
'Site' is not our criteria.

I hope this helps clarify our implementation.


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 Meyer, Jennifer L
Sent: Monday, April 13, 2009 7:52 AM
To: arslist@ARSLIST.ORG
Subject: Re: Product Categorizations and the Elephant Rhyme

**
Chris,

Are you keying off the Site field to figure out which Tier 1 support group 
takes the incident?


Jennifer Meyer


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

If that is all that there is to the Service Catalog, then BMC has been blowing 
a lot of smoke about it in my opinion.  Our CFG:ServiceCatalogAssoc contains 
the 53 Global CTI that our helpdesk defined before we went live and Don 
imported with Data Management, plus a few I added to support campus-wide outage 
reporting.  We have another 154 non-Third Party Product CTI that we also 
imported or defined in four major categories: Computing Services, Desktop 
Software, Hardware, and Infrastructure.  Don built all of this in consultation 
with the central helpdesk, who incorporated many of these CTI into their 
Incident templates.  We gave every one of the colleges and departments, who 
each have their own Company, the ability to define their own CTIs within their 
company, but so far NO ONE has done so in almost a year of production.

To me, a Service Catalog entry should exist at a hierarchical level above CTI, 
as was hinted at but not realized in ITSM 5.x, but I have never found that 
implemented in the ITSM apps in a practical way.  The closest is the Business 
Service configuration item in Asset Management/CMDB, but like everything in the 
CMDB it is a Product categorization, not an Operational categorization.  There 
does not appear to be any place that you can tie OpCats and ProdCats together 
under a defined IT Service at what I have always perceived to be the "Service 
Catalog" level.  Whenever I have heard people talk about a "Service Catalog," I 
was looking for something where you can define an IT Service like "Payroll 
Services" and it will have some OpCats for Incidents and Changes to use, and 
some ProdCats that define the system CIs and component CIs that make up the IT 
Service.  Without the top-level connection, it's the same huge pile of 
incomprehensible categorizations that we cussed and discussed for the last 
decade, and finally discarded.

I think we actually got the closest to this in our old 5.x app when we added a 
second tier to the Summaries in the Requester Console, and the top tier 
included things like "Student Computing Services," "Distributed Computing 
Services,"  and "Administrative Computing Services" as well as more specific 
things like "Residence Networks."  Even the helpdesk staff MUCH preferred to 
use the Summary menus (which carried over into Help Desk cases just like they 
did in the Requester -New Request form) to quickly categorize a ticket than to 
wade through the CTI menus, even after we gave them a pull-right hierarchical 
menu of the CTIs to navigate.  Today they have learned to use the 40 some odd 
incident templates defined by their manager in almost the same way.

Looking back, I don't see very many support staff on our ITSM 7 system making 
use of even the existing categorizations.  I reviewed ~16,200 incidents from 
the last 11 months and the vast majority of those with populated 
categorizations (6,676) were either generated by Kinetic Request, or by the 
central helpdesk which uses incident templates wherever possible.  The rest had 
no CTI whatsoever.  Once ITSM 7 made it optional data, and without any emphasis 
from IT managers in most of our support groups to enter it for reporting, CTI 
usage plummeted.  Som

Re: Product Categorizations and the Elephant Rhyme

2009-04-13 Thread Meyer, Jennifer L

Chris,

Are you keying off the Site field to figure out which Tier 1 support group 
takes the incident?


Jennifer Meyer


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

If that is all that there is to the Service Catalog, then BMC has been blowing 
a lot of smoke about it in my opinion.  Our CFG:ServiceCatalogAssoc contains 
the 53 Global CTI that our helpdesk defined before we went live and Don 
imported with Data Management, plus a few I added to support campus-wide outage 
reporting.  We have another 154 non-Third Party Product CTI that we also 
imported or defined in four major categories: Computing Services, Desktop 
Software, Hardware, and Infrastructure.  Don built all of this in consultation 
with the central helpdesk, who incorporated many of these CTI into their 
Incident templates.  We gave every one of the colleges and departments, who 
each have their own Company, the ability to define their own CTIs within their 
company, but so far NO ONE has done so in almost a year of production.

To me, a Service Catalog entry should exist at a hierarchical level above CTI, 
as was hinted at but not realized in ITSM 5.x, but I have never found that 
implemented in the ITSM apps in a practical way.  The closest is the Business 
Service configuration item in Asset Management/CMDB, but like everything in the 
CMDB it is a Product categorization, not an Operational categorization.  There 
does not appear to be any place that you can tie OpCats and ProdCats together 
under a defined IT Service at what I have always perceived to be the "Service 
Catalog" level.  Whenever I have heard people talk about a "Service Catalog," I 
was looking for something where you can define an IT Service like "Payroll 
Services" and it will have some OpCats for Incidents and Changes to use, and 
some ProdCats that define the system CIs and component CIs that make up the IT 
Service.  Without the top-level connection, it's the same huge pile of 
incomprehensible categorizations that we cussed and discussed for the last 
decade, and finally discarded.

I think we actually got the closest to this in our old 5.x app when we added a 
second tier to the Summaries in the Requester Console, and the top tier 
included things like "Student Computing Services," "Distributed Computing 
Services,"  and "Administrative Computing Services" as well as more specific 
things like "Residence Networks."  Even the helpdesk staff MUCH preferred to 
use the Summary menus (which carried over into Help Desk cases just like they 
did in the Requester -New Request form) to quickly categorize a ticket than to 
wade through the CTI menus, even after we gave them a pull-right hierarchical 
menu of the CTIs to navigate.  Today they have learned to use the 40 some odd 
incident templates defined by their manager in almost the same way.

Looking back, I don't see very many support staff on our ITSM 7 system making 
use of even the existing categorizations.  I reviewed ~16,200 incidents from 
the last 11 months and the vast majority of those with populated 
categorizations (6,676) were either generated by Kinetic Request, or by the 
central helpdesk which uses incident templates wherever possible.  The rest had 
no CTI whatsoever.  Once ITSM 7 made it optional data, and without any emphasis 
from IT managers in most of our support groups to enter it for reporting, CTI 
usage plummeted.  Something to think about if we ever want to do really 
detailed reporting.  On the other hand, we have heard many comments over the 
last year that the support staff users like this version better than previous 
ones since they can get tickets into it quicker, so we gained in speed what we 
lost in detail.  Your mileage _will_ vary!

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 12:53 PM
To: arslist@ARSLIST.ORG
Subject: Re: Product Categorizations and the Elephant Rhyme

**
Thank you, Chris, Rick, and Don for your feedback.

Chris,

Thank you for a very well-reasoned argument.  I always value your input highly. 
 As you said, there are a number of different ways to configure assignment in 
Remedy 7.X, and keying on CTI may not be the best method to use for every 
organization.  Personally, I'd rather thoroughly train the first-level help 
desk in the business process and allow them to make intelligent decisions, but 
if that happened in the real world, we wouldn't need assignment rules.

The assignment method was decided long before I joined th

Re: Product Categorizations and the Elephant Rhyme

2009-04-10 Thread Nicky Madjarov

Christopher,

I agree that service should be somewhere above the CTI's. Given the fact that 
service is not present (directly) in most of the itsm apps/forms I am simply 
looking for a way to utilize what is given to achieve some more service-centric 
model. For me, becoming service centric is an important step for better 
utilizing the itil foundations.
Your environment is quite unique because all customers are provided the same 
packege of services (probably with few exceptions) and you have relatively low 
volume of incidents. 
I am far from saying that you guys have to make the change for the sake of 
being service centric. Apparently your support organization works well for you. 
Look ,however, in the high volume shops - 1 million plus incident per year and 
vast vatiety of services provided to different users and all the restrictions 
related to supporting different service and different skill sets needed to do 
so, especially when it comes to sensitive data - goverment, financial, telecom, 
pharma, just to name few. In my opinion, one of the the better ways to handle 
such environments to adopt the service centric model, identify the service 
managers, and let them define how do they want to handle everything withing 
their arreas of responsibility.
  
Regards,

Nicky Madjarov
phone: 973-202-4278
Find out how to bust your AR System performance @
http://www.SpeedUpARS.com
  - Original Message - 
  From: strauss 
  Newsgroups: public.remedy.arsystem.general
  To: arslist@ARSLIST.ORG 
  Sent: Thursday, April 09, 2009 6:37 PM
  Subject: Re: Product Categorizations and the Elephant Rhyme


  ** 
  If that is all that there is to the Service Catalog, then BMC has been 
blowing a lot of smoke about it in my opinion.  Our CFG:ServiceCatalogAssoc 
contains the 53 Global CTI that our helpdesk defined before we went live and 
Don imported with Data Management, plus a few I added to support campus-wide 
outage reporting.  We have another 154 non-Third Party Product CTI that we also 
imported or defined in four major categories: Computing Services, Desktop 
Software, Hardware, and Infrastructure.  Don built all of this in consultation 
with the central helpdesk, who incorporated many of these CTI into their 
Incident templates.  We gave every one of the colleges and departments, who 
each have their own Company, the ability to define their own CTIs within their 
company, but so far NO ONE has done so in almost a year of production.

   

  To me, a Service Catalog entry should exist at a hierarchical level above 
CTI, as was hinted at but not realized in ITSM 5.x, but I have never found that 
implemented in the ITSM apps in a practical way.  The closest is the Business 
Service configuration item in Asset Management/CMDB, but like everything in the 
CMDB it is a Product categorization, not an Operational categorization.  There 
does not appear to be any place that you can tie OpCats and ProdCats together 
under a defined IT Service at what I have always perceived to be the "Service 
Catalog" level.  Whenever I have heard people talk about a "Service Catalog," I 
was looking for something where you can define an IT Service like "Payroll 
Services" and it will have some OpCats for Incidents and Changes to use, and 
some ProdCats that define the system CIs and component CIs that make up the IT 
Service.  Without the top-level connection, it's the same huge pile of 
incomprehensible categorizations that we cussed and discussed for the last 
decade, and finally discarded.  

   

  I think we actually got the closest to this in our old 5.x app when we added 
a second tier to the Summaries in the Requester Console, and the top tier 
included things like "Student Computing Services," "Distributed Computing 
Services,"  and "Administrative Computing Services" as well as more specific 
things like "Residence Networks."  Even the helpdesk staff MUCH preferred to 
use the Summary menus (which carried over into Help Desk cases just like they 
did in the Requester -New Request form) to quickly categorize a ticket than to 
wade through the CTI menus, even after we gave them a pull-right hierarchical 
menu of the CTIs to navigate.  Today they have learned to use the 40 some odd 
incident templates defined by their manager in almost the same way.

   

  Looking back, I don't see very many support staff on our ITSM 7 system making 
use of even the existing categorizations.  I reviewed ~16,200 incidents from 
the last 11 months and the vast majority of those with populated 
categorizations (6,676) were either generated by Kinetic Request, or by the 
central helpdesk which uses incident templates wherever possible.  The rest had 
no CTI whatsoever.  Once ITSM 7 made it optional data, and without any emphasis 
from IT managers in most of our support groups to enter it for reporting, CTI 
usage plummeted.  Something to think about if

Re: Product Categorizations and the Elephant Rhyme

If that is all that there is to the Service Catalog, then BMC has been blowing 
a lot of smoke about it in my opinion.  Our CFG:ServiceCatalogAssoc contains 
the 53 Global CTI that our helpdesk defined before we went live and Don 
imported with Data Management, plus a few I added to support campus-wide outage 
reporting.  We have another 154 non-Third Party Product CTI that we also 
imported or defined in four major categories: Computing Services, Desktop 
Software, Hardware, and Infrastructure.  Don built all of this in consultation 
with the central helpdesk, who incorporated many of these CTI into their 
Incident templates.  We gave every one of the colleges and departments, who 
each have their own Company, the ability to define their own CTIs within their 
company, but so far NO ONE has done so in almost a year of production.

To me, a Service Catalog entry should exist at a hierarchical level above CTI, 
as was hinted at but not realized in ITSM 5.x, but I have never found that 
implemented in the ITSM apps in a practical way.  The closest is the Business 
Service configuration item in Asset Management/CMDB, but like everything in the 
CMDB it is a Product categorization, not an Operational categorization.  There 
does not appear to be any place that you can tie OpCats and ProdCats together 
under a defined IT Service at what I have always perceived to be the "Service 
Catalog" level.  Whenever I have heard people talk about a "Service Catalog," I 
was looking for something where you can define an IT Service like "Payroll 
Services" and it will have some OpCats for Incidents and Changes to use, and 
some ProdCats that define the system CIs and component CIs that make up the IT 
Service.  Without the top-level connection, it's the same huge pile of 
incomprehensible categorizations that we cussed and discussed for the last 
decade, and finally discarded.

I think we actually got the closest to this in our old 5.x app when we added a 
second tier to the Summaries in the Requester Console, and the top tier 
included things like "Student Computing Services," "Distributed Computing 
Services,"  and "Administrative Computing Services" as well as more specific 
things like "Residence Networks."  Even the helpdesk staff MUCH preferred to 
use the Summary menus (which carried over into Help Desk cases just like they 
did in the Requester -New Request form) to quickly categorize a ticket than to 
wade through the CTI menus, even after we gave them a pull-right hierarchical 
menu of the CTIs to navigate.  Today they have learned to use the 40 some odd 
incident templates defined by their manager in almost the same way.

Looking back, I don't see very many support staff on our ITSM 7 system making 
use of even the existing categorizations.  I reviewed ~16,200 incidents from 
the last 11 months and the vast majority of those with populated 
categorizations (6,676) were either generated by Kinetic Request, or by the 
central helpdesk which uses incident templates wherever possible.  The rest had 
no CTI whatsoever.  Once ITSM 7 made it optional data, and without any emphasis 
from IT managers in most of our support groups to enter it for reporting, CTI 
usage plummeted.  Something to think about if we ever want to do really 
detailed reporting.  On the other hand, we have heard many comments over the 
last year that the support staff users like this version better than previous 
ones since they can get tickets into it quicker, so we gained in speed what we 
lost in detail.  Your mileage _will_ vary!

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 12:53 PM
To: arslist@ARSLIST.ORG
Subject: Re: Product Categorizations and the Elephant Rhyme

**
Thank you, Chris, Rick, and Don for your feedback.

Chris,

Thank you for a very well-reasoned argument.  I always value your input highly. 
 As you said, there are a number of different ways to configure assignment in 
Remedy 7.X, and keying on CTI may not be the best method to use for every 
organization.  Personally, I'd rather thoroughly train the first-level help 
desk in the business process and allow them to make intelligent decisions, but 
if that happened in the real world, we wouldn't need assignment rules.

The assignment method was decided long before I joined the organization, and 
I'm not in a position to change it; however, neither is MET (Thanks, Rick!).  
The last time I had Remedy training was 6.0, (2005) so I'm learning 7.X on the 
job.  We support a very large company with multi-tenancy from a central hub, so 
keying off organization won't work for us.  In our case, generic OpCats and 
ProdCats work quite well.  We als

Re: Product Categorizations and the Elephant Rhyme

That's an excellent explanation, Don.  Thank you.

This thread is generating intense interest in my local group, so if anyone uses 
a different routing/assignment scheme, please share with us.  I may have to 
post a Wiki.

P.S.  I did manage to find a knowledgebase article referring to CTI and 
assignment for 6.X.



Jennifer Meyer


From: Action Request System discussion list(ARSList) 
[mailto:arsl...@arslist.org] On Behalf Of McClure, Don
Sent: Thursday, April 09, 2009 4:27 PM
To: arslist@ARSLIST.ORG
Subject: Re: Product Categorizations and the Elephant Rhyme

Concerning question on Distributed Environment--short answer is : yes.

By Chris' description below, our environment is characteristically different 
from many encountered in the commercial world, public entities, and maybe even 
other academic centers.  We do rely on legacy knowledge in 60-odd support 
groups to know their local environment, so central IT folks do not have to 
learn an area's specific concerns 'on-the-fly'.  And, summarizing description 
by Chris, often those group-specific items show many more peculiarities than 
similarities.  Local experience is that central support often *fails* all 
consumers equally in this diverse environment, rather than facilitating prompt 
consumer service.  We have very few applications where both installation and 
implementation is actually Enterprise-wide-as Chris mentioned, even 
backups/file-sharing/printing are more localized than centralized.

Customer-relations criteria should place the consumer first. Our support-staff 
folks are here for agile handling of consumer's needs; therefore, we rely on 
that consumer's location (logical location, specific  college/school/group) for 
placement of Incident reports, and that is how our environment is built.

Finally, we do utilize a system-wide default which will route any un-assignable 
Incidents to our central help desk for further handling-and to ensure that no 
Incident goes unhandled for lack of designation.
By my last count, I have seen four (4) such incidents out of 17,000+ records 
over the last year.


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 Meyer, Jennifer L
Sent: Thursday, April 09, 2009 2:23 PM
To: arslist@ARSLIST.ORG
Subject: Re: Product Categorizations and the Elephant Rhyme

**
This may be an excellent opportunity to compare and contrast the two approaches 
for organizational functions.

If I understand this correctly, I and Shawn have central help desks that rely 
heavily on automated routing to choose from thousands of functions.

Chris and Don seem to have a distributed system that relies on locally 
distributed service centers with a high knowledge level so uses assignment 
mappings as a fallback.

Is this an accurate summation?


Jennifer Meyer


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

Our system works for us since the vast majority of issues for faculty and staff 
are handled by their distributed computer support groups, where all of the 
Incidents are routed first by default.  Almost all of the functions you 
mentioned are administered at the distributed unit level, even if they are 
hosted on a central service (active directory accounts and permissions, 
Exchange mail, disk storage), and are only escalated to the central group when 
the distributed group cannot handle the issue.  Even backups and restores are 
distributed (local) - the colleges run their own file and print servers, in 
their own domain within the central AD system.

The central helpdesk provides the equivalent first line support to all 
students, so that is their default routing, and a lot of the centrally 
supported system tickets (student email, distance learning apps, etc.) all 
start at the central helpdesk for triage anyway.  For anything that is very 
specific, and is a routine request from customers supported by more than one 
distributed support group (like data wiring requests, which any employee can 
enter and all route first to DataComm, then TeleComm), there is a Kinetic 
Service Item that directly assigns new incidents to the appropriate central 
support group.

BTW, the majority of desktops, especially Windows machines, are deployed for 
faculty/staff by their college/departmental IT staff without admin rights for 
the end user, with a very wide variety of software packages available to them 
as needed.  Since this is very college or department specific (even the OS is 
college specific - you won't find any Macs supported in the college of 
business, or many Windows machines in visual

Re: Product Categorizations and the Elephant Rhyme

2009-04-09 Thread McClure, Don

Concerning question on Distributed Environment--short answer is : yes.

By Chris' description below, our environment is characteristically different 
from many encountered in the commercial world, public entities, and maybe even 
other academic centers.  We do rely on legacy knowledge in 60-odd support 
groups to know their local environment, so central IT folks do not have to 
learn an area's specific concerns 'on-the-fly'.  And, summarizing description 
by Chris, often those group-specific items show many more peculiarities than 
similarities.  Local experience is that central support often *fails* all 
consumers equally in this diverse environment, rather than facilitating prompt 
consumer service.  We have very few applications where both installation and 
implementation is actually Enterprise-wide-as Chris mentioned, even 
backups/file-sharing/printing are more localized than centralized.

Customer-relations criteria should place the consumer first. Our support-staff 
folks are here for agile handling of consumer's needs; therefore, we rely on 
that consumer's location (logical location, specific  college/school/group) for 
placement of Incident reports, and that is how our environment is built.

Finally, we do utilize a system-wide default which will route any un-assignable 
Incidents to our central help desk for further handling-and to ensure that no 
Incident goes unhandled for lack of designation.
By my last count, I have seen four (4) such incidents out of 17,000+ records 
over the last year.


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 Meyer, Jennifer L
Sent: Thursday, April 09, 2009 2:23 PM
To: arslist@ARSLIST.ORG
Subject: Re: Product Categorizations and the Elephant Rhyme

**
This may be an excellent opportunity to compare and contrast the two approaches 
for organizational functions.

If I understand this correctly, I and Shawn have central help desks that rely 
heavily on automated routing to choose from thousands of functions.

Chris and Don seem to have a distributed system that relies on locally 
distributed service centers with a high knowledge level so uses assignment 
mappings as a fallback.

Is this an accurate summation?


Jennifer Meyer


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

Our system works for us since the vast majority of issues for faculty and staff 
are handled by their distributed computer support groups, where all of the 
Incidents are routed first by default.  Almost all of the functions you 
mentioned are administered at the distributed unit level, even if they are 
hosted on a central service (active directory accounts and permissions, 
Exchange mail, disk storage), and are only escalated to the central group when 
the distributed group cannot handle the issue.  Even backups and restores are 
distributed (local) - the colleges run their own file and print servers, in 
their own domain within the central AD system.

The central helpdesk provides the equivalent first line support to all 
students, so that is their default routing, and a lot of the centrally 
supported system tickets (student email, distance learning apps, etc.) all 
start at the central helpdesk for triage anyway.  For anything that is very 
specific, and is a routine request from customers supported by more than one 
distributed support group (like data wiring requests, which any employee can 
enter and all route first to DataComm, then TeleComm), there is a Kinetic 
Service Item that directly assigns new incidents to the appropriate central 
support group.

BTW, the majority of desktops, especially Windows machines, are deployed for 
faculty/staff by their college/departmental IT staff without admin rights for 
the end user, with a very wide variety of software packages available to them 
as needed.  Since this is very college or department specific (even the OS is 
college specific - you won't find any Macs supported in the college of 
business, or many Windows machines in visual arts or music), any attempt to 
route a ticket for application support centrally will have to be turned back.  
We also have a number of colleges/departments in one building, with small IT 
staffs, who don't use Remedy for internal ticketing at all.  Their faculty know 
to use the Kinetic web to report a problem with the distance learning or 
PeopleSoft webs, which are centrally supported, but they generally email, call, 
or walk a few doors down to their network manager for local issue support.  We 
don't / can't MAKE them use Remedy for internal ticketing, but as soon as an

Re: Product Categorizations and the Elephant Rhyme

This may be an excellent opportunity to compare and contrast the two approaches 
for organizational functions.

If I understand this correctly, I and Shawn have central help desks that rely 
heavily on automated routing to choose from thousands of functions.

Chris and Don seem to have a distributed system that relies on locally 
distributed service centers with a high knowledge level so uses assignment 
mappings as a fallback.

Is this an accurate summation?


Jennifer Meyer


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

Our system works for us since the vast majority of issues for faculty and staff 
are handled by their distributed computer support groups, where all of the 
Incidents are routed first by default.  Almost all of the functions you 
mentioned are administered at the distributed unit level, even if they are 
hosted on a central service (active directory accounts and permissions, 
Exchange mail, disk storage), and are only escalated to the central group when 
the distributed group cannot handle the issue.  Even backups and restores are 
distributed (local) - the colleges run their own file and print servers, in 
their own domain within the central AD system.

The central helpdesk provides the equivalent first line support to all 
students, so that is their default routing, and a lot of the centrally 
supported system tickets (student email, distance learning apps, etc.) all 
start at the central helpdesk for triage anyway.  For anything that is very 
specific, and is a routine request from customers supported by more than one 
distributed support group (like data wiring requests, which any employee can 
enter and all route first to DataComm, then TeleComm), there is a Kinetic 
Service Item that directly assigns new incidents to the appropriate central 
support group.

BTW, the majority of desktops, especially Windows machines, are deployed for 
faculty/staff by their college/departmental IT staff without admin rights for 
the end user, with a very wide variety of software packages available to them 
as needed.  Since this is very college or department specific (even the OS is 
college specific - you won't find any Macs supported in the college of 
business, or many Windows machines in visual arts or music), any attempt to 
route a ticket for application support centrally will have to be turned back.  
We also have a number of colleges/departments in one building, with small IT 
staffs, who don't use Remedy for internal ticketing at all.  Their faculty know 
to use the Kinetic web to report a problem with the distance learning or 
PeopleSoft webs, which are centrally supported, but they generally email, call, 
or walk a few doors down to their network manager for local issue support.  We 
don't / can't MAKE them use Remedy for internal ticketing, but as soon as any 
IT support organization grows to several people supporting users in multiple 
buildings, or even on multiple campuses, they quickly move to a model where 
everything gets ticketed as an incident, but it is still 98% internal to that 
organization.

In our environment, where some groups want a few CTI for reporting but most 
groups don't want to have to deal with the overhead, dropping CTI-based routing 
made sense; we have always used location-based routing as our primary method, 
all the way back to Help Desk 3.  The changes in the assignment processes in 
ITSM 7 made it easy for us to just simplify everything when we migrated, and at 
this point (11 months in production) we have not found any reason to regret it. 
 Maybe if we had BMC Analytics or Dashboards we would see it differently, but 
we keep losing the budget battle for those.

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 Pierson, Shawn
Sent: Thursday, April 09, 2009 12:42 PM
To: arslist@ARSLIST.ORG
Subject: Re: Product Categorizations and the Elephant Rhyme

**
I can see how this is helpful when you have staff planted in different 
locations that act as an extended service desk, but what about issues that 
require someone in the centralized I.T. group to fix?  If someone has a problem 
with one of your enterprise-wide applications, maybe it should always be routed 
to a specific group.  For example, if you need a restore of your shared drive 
from backups, most likely there is a group that handles all backup/restore 
requests that will address it.  What about email issues, or problems with an 
application built in-house that requires a programmer to be involved?

I can see plenty of examples where using Categorizations would be helpful for 
ro

Re: Product Categorizations and the Elephant Rhyme

Our system works for us since the vast majority of issues for faculty and staff 
are handled by their distributed computer support groups, where all of the 
Incidents are routed first by default.  Almost all of the functions you 
mentioned are administered at the distributed unit level, even if they are 
hosted on a central service (active directory accounts and permissions, 
Exchange mail, disk storage), and are only escalated to the central group when 
the distributed group cannot handle the issue.  Even backups and restores are 
distributed (local) - the colleges run their own file and print servers, in 
their own domain within the central AD system.

The central helpdesk provides the equivalent first line support to all 
students, so that is their default routing, and a lot of the centrally 
supported system tickets (student email, distance learning apps, etc.) all 
start at the central helpdesk for triage anyway.  For anything that is very 
specific, and is a routine request from customers supported by more than one 
distributed support group (like data wiring requests, which any employee can 
enter and all route first to DataComm, then TeleComm), there is a Kinetic 
Service Item that directly assigns new incidents to the appropriate central 
support group.

BTW, the majority of desktops, especially Windows machines, are deployed for 
faculty/staff by their college/departmental IT staff without admin rights for 
the end user, with a very wide variety of software packages available to them 
as needed.  Since this is very college or department specific (even the OS is 
college specific - you won't find any Macs supported in the college of 
business, or many Windows machines in visual arts or music), any attempt to 
route a ticket for application support centrally will have to be turned back.  
We also have a number of colleges/departments in one building, with small IT 
staffs, who don't use Remedy for internal ticketing at all.  Their faculty know 
to use the Kinetic web to report a problem with the distance learning or 
PeopleSoft webs, which are centrally supported, but they generally email, call, 
or walk a few doors down to their network manager for local issue support.  We 
don't / can't MAKE them use Remedy for internal ticketing, but as soon as any 
IT support organization grows to several people supporting users in multiple 
buildings, or even on multiple campuses, they quickly move to a model where 
everything gets ticketed as an incident, but it is still 98% internal to that 
organization.

In our environment, where some groups want a few CTI for reporting but most 
groups don't want to have to deal with the overhead, dropping CTI-based routing 
made sense; we have always used location-based routing as our primary method, 
all the way back to Help Desk 3.  The changes in the assignment processes in 
ITSM 7 made it easy for us to just simplify everything when we migrated, and at 
this point (11 months in production) we have not found any reason to regret it. 
 Maybe if we had BMC Analytics or Dashboards we would see it differently, but 
we keep losing the budget battle for those.

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 Pierson, Shawn
Sent: Thursday, April 09, 2009 12:42 PM
To: arslist@ARSLIST.ORG
Subject: Re: Product Categorizations and the Elephant Rhyme

**
I can see how this is helpful when you have staff planted in different 
locations that act as an extended service desk, but what about issues that 
require someone in the centralized I.T. group to fix?  If someone has a problem 
with one of your enterprise-wide applications, maybe it should always be routed 
to a specific group.  For example, if you need a restore of your shared drive 
from backups, most likely there is a group that handles all backup/restore 
requests that will address it.  What about email issues, or problems with an 
application built in-house that requires a programmer to be involved?

I can see plenty of examples where using Categorizations would be helpful for 
routing.  I don't see how it is possible to have a template for every single 
scenario, especially in a situation where you are dealing with a campus full of 
people that probably have admin rights on their own machines and install all 
sorts of crazy hardware and software that is not supported by I.T.  It seems 
like by not using categorizations you will end up with the service desk doing 
more of the assignment routing manually than is necessary.

Shawn Pierson

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"

Re: Product Categorizations and the Elephant Rhyme

Thank you, Chris, Rick, and Don for your feedback.

Chris,

Thank you for a very well-reasoned argument.  I always value your input highly. 
 As you said, there are a number of different ways to configure assignment in 
Remedy 7.X, and keying on CTI may not be the best method to use for every 
organization.  Personally, I'd rather thoroughly train the first-level help 
desk in the business process and allow them to make intelligent decisions, but 
if that happened in the real world, we wouldn't need assignment rules.

The assignment method was decided long before I joined the organization, and 
I'm not in a position to change it; however, neither is MET (Thanks, Rick!).  
The last time I had Remedy training was 6.0, (2005) so I'm learning 7.X on the 
job.  We support a very large company with multi-tenancy from a central hub, so 
keying off organization won't work for us.  In our case, generic OpCats and 
ProdCats work quite well.  We also use assignment rules tied to every support 
group.

Thank you again for your excellent response.  I learned quite a bit reading it.

P.S.  Service Catalog is defined in CFG:ServiceCatalogAssoc.  We import it from 
the 25+ page Foundation Data Spreadsheet.

Don,

You put a lot of detail into your explanation; the set theory model was an apt 
method to describe it.

We create mutually exclusive assignment records.  I've learned through filter 
logging that if any support group does not have an assignment rule, some of the 
OOB workflow fails.
We also have a SPOC (Tier 1 Help Desk) for each tenancy, so all incidents are 
owned by that tenancy's SPOC and assigned to Tier 2 support by SPOC personnel.  
As I mentioned above, if Tier 1 were trained as well as we'd all like 
assignment rules would be redundant.


Rick,

I'm a huge fan of your "Generic Incident Classification" document, as you 
already know.  I keep a copy on a flash drive that's on me at all times, and 
it's come in very useful.  The chief issue with MET is that he's an individual 
(actually, two individuals) with whom we have a very cordial working 
relationship, and we'd prefer to keep him on our side.  Also, as happens too 
often in organizations, process definition and enforcement in management is 
somewhat lax.

I'm convinced this is a communication issue that we can overcome by showing MET 
more of the elephant.  I strongly suspect MET got wind of an argument similar 
to the one Chris first made, interpreted it incorrectly, and doesn't have a 
strong enough grasp of the assignment process to follow it through to its 
conclusion.  Chris's argument is really solid, but it's not the assignment 
process we're using.

Thank you, gentlemen, for putting so much thought and concern into your 
responses.



If you folks should happen to come across anything indicating Categorizations 
are a solid method for assignment, please do send it my way.  Even if it's from 
'95 to '02, and has the Remedy or P-word logo on it, at least it looks official.



Jennifer Meyer

Remedy Technical Support Specialist

State of North Carolina

Office Of Information Technology Services

Service Delivery Division

ITSM & ITAM Services

Office: 919-754-6543

ITS Service Desk: 919-754-6000

jennifer.me...@its.nc.gov<mailto:jennifer.me...@its.nc.gov>

http://its.state.nc.us



E-mail correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties only by an 
authorized State Official.

__Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"

Re: Product Categorizations and the Elephant Rhyme

2009-04-09 Thread Pierson, Shawn

I can see how this is helpful when you have staff planted in different 
locations that act as an extended service desk, but what about issues that 
require someone in the centralized I.T. group to fix?  If someone has a problem 
with one of your enterprise-wide applications, maybe it should always be routed 
to a specific group.  For example, if you need a restore of your shared drive 
from backups, most likely there is a group that handles all backup/restore 
requests that will address it.  What about email issues, or problems with an 
application built in-house that requires a programmer to be involved?

I can see plenty of examples where using Categorizations would be helpful for 
routing.  I don't see how it is possible to have a template for every single 
scenario, especially in a situation where you are dealing with a campus full of 
people that probably have admin rights on their own machines and install all 
sorts of crazy hardware and software that is not supported by I.T.  It seems 
like by not using categorizations you will end up with the service desk doing 
more of the assignment routing manually than is necessary.

Shawn Pierson

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

**
I think it depends entirely on the tools that you have deployed.  We do not 
have either SRM or Asset or anything in our CMDB, so we don't really have a 
place to define our "Service Catalog."  I haven't found an actual "place" in 
ITSM where you are supposed to define it, anyway, but maybe it is in SRM which 
we have never seen.  You can define Business Services as CIs in Asset 
Management, but we don't have that either.  If you are defining all of your 
"services" in the 2nd level of the CTI, then that does make them available at a 
uniform level for any routing rules that you want to define.  Given the way the 
ITSM 7 apps work, that sounds like a viable approach for many organizations as 
long as all of the rules are at one level and mutually exclusive.

We don't have ANY routing rules defined that use CTI, only Location.  That is 
because our routing is always organizational by default, with the only 
exceptions being defined in our Kinetic Request system.  There, the "service 
catalog" consists of four categories of service items (public, students, 
faculty/staff, and IT support staff as made visible to a user by normal ARS 
group permissions).  Almost every service item uses an Incident template to 
create the ticket, and so the CTI, Assignee Group, and Owner Group are 
explicitly defined in the service item tasks or the template.  They do not rely 
on automatic assignment rules at all.

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 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 th

Re: Product Categorizations and the Elephant Rhyme

I think it depends entirely on the tools that you have deployed.  We do not 
have either SRM or Asset or anything in our CMDB, so we don't really have a 
place to define our "Service Catalog."  I haven't found an actual "place" in 
ITSM where you are supposed to define it, anyway, but maybe it is in SRM which 
we have never seen.  You can define Business Services as CIs in Asset 
Management, but we don't have that either.  If you are defining all of your 
"services" in the 2nd level of the CTI, then that does make them available at a 
uniform level for any routing rules that you want to define.  Given the way the 
ITSM 7 apps work, that sounds like a viable approach for many organizations as 
long as all of the rules are at one level and mutually exclusive.

We don't have ANY routing rules defined that use CTI, only Location.  That is 
because our routing is always organizational by default, with the only 
exceptions being defined in our Kinetic Request system.  There, the "service 
catalog" consists of four categories of service items (public, students, 
faculty/staff, and IT support staff as made visible to a user by normal ARS 
group permissions).  Almost every service item uses an Incident template to 
create the ticket, and so the CTI, Assignee Group, and Owner Group are 
explicitly defined in the service item tasks or the template.  They do not rely 
on automatic assignment rules at all.

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 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 
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

Re: Product Categorizations and the Elephant Rhyme

2009-04-09 Thread McClure, Don

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 
versionsand 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 th

Re: Product Categorizations and the Elephant Rhyme

2009-04-09 Thread Nicky Madjarov

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  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 ca

Re: Product Categorizations and the Elephant Rhyme

2009-04-09 Thread Rick Cook

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  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 t

Re: Product Categorizations and the Elephant Rhyme

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***

Re: Product Categorizations and the Elephant Rhyme

2009-04-09 Thread Rick Cook

Jennifer, you could show Mr. Elephant Tail (MET) books and best practices
until the cows come home - if you haven't convinced him by now, you need
someone else to fight this battle.  I think I would suggest that you try
these tactics:

1)  Find the manager/director who uses the output data from the Assignments
to make forecasts for support staffing, etc., and have that person explain
the facts of life to MET.
2)  Ask MET to suggest to the Support Manager how Incidents ARE supposed to
be routed if Categorizations aren't used, and why he would want you to be
the only Remedy customer on the planet to NOT use them for assignment (make
him prove HIS concept rather than you defending yours).  Tell MET that once
he and the Support Manager work out how that would work, then you will
support their decision.  This will make MET carry his position to logical
conclusions, where it will break down.
3)  If the organization is heavily ITIL-centric, there must be a
champion/guardian of that process somewhere around - sic that person on
MET.
4)  Figure out how much doing things MET's way would cost in customizations
to product, longer MTRs, etc., and then have the Support Manager ask MET if
he would like to fund that from his budget.
5)  If it's possible (don't know his org chart relationship with you),
ignore him and continue to do it the way you know best.

The more pressure put on him to prove he's right, the more likely he is to
back down as he slowly figures out he's wrong.

Rick
On Thu, Apr 9, 2009 at 7:24 AM, Meyer, Jennifer L  wrote:

> **
>
> 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___

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

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___

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

Re: ITSM 7 Operational Categorizations

2008-11-09 Thread Rick Cook

I believe you, Kelly, and so should everyone else.  Thanks for moving it
back to where it can benefit the most people.

Rick

On Sun, Nov 9, 2008 at 2:18 PM, Kelly Deaver <[EMAIL PROTECTED]>wrote:

> ** The document was accidentally misclassified during the upgrade. It is
> publicly available now. Please realize there were hundreds of documents and
> downloads to classify and sometimes things don't go perfect. There was no
> intent to hide Rick's document.
>
> Kelly Deaver
> [EMAIL PROTECTED]
> (Yes, I work for BMC. This post reflects the opinions of the poster and not
> the official opinion of BMC)
>
>
>
>  Original Message ----
> Subject: Re: ITSM 7 Operational Categorizations
> From: "Easter, David" <[EMAIL PROTECTED]>
> Date: Fri, November 07, 2008 11:41 am
> To: arslist@ARSLIST.ORG
>
> You could also post publicly available documents created by the community
> on the public section of BMC DN. That way it would be available to anyone
> with a login on BMC DN (login access isn't restricted) and not just to BMC
> partners.
>
> The reason this issue came up is because the document was posted in the
> partner/BMC section of the BMC DN. Had it been posted in the public section,
> there wouldn't have been any issues around distribution.
>
> (Of course, I'm assuming the document was community developed and publicly
> available as per Rick's statement. Obviously, BMC or partner confidential
> documents would continue to be posted in the BMC/Partner section of BMC DN
> and thus require the restricted access.)
>
> -David J. Easter
> Sr. Product Manager, Solution Strategy and Development
> BMC Software, Inc.
>
> The opinions, statements, and/or suggested courses of action expressed in
> this E-mail do not necessarily reflect those of BMC Software, Inc. My
> voluntary participation in this forum is not intended to convey a role as a
> spokesperson, liaison or public relations representative for BMC Software,
> Inc.
>
> ____
>
> From: Action Request System discussion list(ARSList) on behalf of Thad K
> Esser
> Sent: Fri 11/7/2008 9:04 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: ITSM 7 Operational Categorizations
>
>
> **
> Perhaps a wiki. Something like Axton's http://www.arswiki.org/
>
> Thad Esser
> Remedy Developer
> "Argue for your limitations, and sure enough, they're yours."-- Richard
> Bach
>
>
>
> "Meyer, Jennifer L" <[EMAIL PROTECTED]>
> Sent by: "Action Request System discussion list(ARSList)" <
> arslist@ARSLIST.ORG>
>
> 11/07/2008 06:31 AM
> Please respond to
> arslist@ARSLIST.ORG
>
>
> To
> arslist@ARSLIST.ORG
> cc
> Subject
> Re: ITSM 7 Operational Categorizations
>
>
>
>
>
>
> **
> You know, isn't it time we started a non-BMC controlled knowledgebase?
> Maybe something MySQL-based or something similar? I remember someone
> attempting to do so several years back, but it didn't get off the ground.
> And Matt Reinfeldt's site was very busy, but difficult to maneuver-and I
> could never remember my password. Perhaps it's time to look into it again.
>
> Jennifer Meyer
> 919-995-2402
> [EMAIL PROTECTED]
>
> 
>
>
> From: Action Request System discussion list(ARSList) [mailto:arslist**
> @ARSLIST.ORG <http://email.secureserver.net/compose.php#Compose>] On
> Behalf Of Rick Cook
> Sent: Thursday, November 06, 2008 9:51 PM
> To: arslist@ARSLIST.ORG
> Subject: Re: ITSM 7 Operational Categorizations
>
> ** Well, as the author of the document, I posted it on the BMCDN for
> convenience purposes only, not as an exclusive place for you all to get to
> it or to grant BMC exclusive rights over it. If BMC has a problem with
> people getting this document from some other source, they can come talk to
> me. If BMC hassles any of you about it, also refer them to me. I'll take
> care of it.
>
> I'm very flattered that so many of you find this information valuable, and
> I see no reason to withhold helpful information from those who need it. I
> hereby give my permission for anyone to use this for their own purposes, and
> to share it with whoever else might find it useful, especially since BMC
> didn't provide anything like it themselves. If you make a buck on it, maybe
> you could share it with me, but I'm not expecting that to happen. :)
>
> If anyone from BMC has any issue with what I just said, you have my phone
> number. I would love to talk to you about it.
>
> Enjoy!
>
> Rick
> On Thu, Nov 6, 2008 at 1:13 PM, Mario Roehr [EMA

Re: ITSM 7 Operational Categorizations

2008-11-09 Thread Kelly Deaver

**
The document was accidentally misclassified during the upgrade. It is publicly available now. Please realize there were hundreds of documents and downloads to classify and sometimes things don't go perfect. There was no intent to hide Rick's document.
Kelly Deaver
[EMAIL PROTECTED]
(Yes, I work for BMC. This post reflects the opinions of the poster and not the official opinion of BMC)

Original Message Subject: Re: ITSM 7 Operational CategorizationsFrom: "Easter, David" <[EMAIL PROTECTED]>Date: Fri, November 07, 2008 11:41 amTo: arslist@ARSLIST.ORGYou could also post publicly available documents created by the community on the public section of BMC DN. That way it would be available to anyone with a login on BMC DN (login access isn't restricted) and not just to BMC partners.The reason this issue came up is because the document was posted in the partner/BMC section of the BMC DN. Had it been posted in the public section, there wouldn't have been any issues around distribution.(Of course, I'm assuming the document was community developed and publicly available as per Rick's statement. Obviously, BMC or partner confidential documents would continue to be posted in the BMC/Partner section of BMC DN and thus require the restricted access.)-David J. EasterSr. Product Manager, Solution Strategy and DevelopmentBMC Software, Inc.The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc.From: Action Request System discussion list(ARSList) on behalf of Thad K EsserSent: Fri 11/7/2008 9:04 AMTo: arslist@ARSLIST.ORGSubject: Re: ITSM 7 Operational Categorizations** Perhaps a wiki. Something like Axton's http://www.arswiki.org/ Thad EsserRemedy Developer"Argue for your limitations, and sure enough, they're yours."-- Richard Bach "Meyer, Jennifer L" <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" 11/07/2008 06:31 AM Please respond toarslist@ARSLIST.ORGToarslist@ARSLIST.ORG ccSubjectRe: ITSM 7 Operational Categorizations ** You know, isn't it time we started a non-BMC controlled knowledgebase? Maybe something MySQL-based or something similar? I remember someone attempting to do so several years back, but it didn't get off the ground. And Matt Reinfeldt's site was very busy, but difficult to maneuver-and I could never remember my password. Perhaps it's time to look into it again. Jennifer Meyer 919-995-2402 [EMAIL PROTECTED] From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick CookSent: Thursday, November 06, 2008 9:51 PMTo: arslist@ARSLIST.ORGSubject: Re: ITSM 7 Operational Categorizations ** Well, as the author of the document, I posted it on the BMCDN for convenience purposes only, not as an exclusive place for you all to get to it or to grant BMC exclusive rights over it. If BMC has a problem with people getting this document from some other source, they can come talk to me. If BMC hassles any of you about it, also refer them to me. I'll take care of it.I'm very flattered that so many of you find this information valuable, and I see no reason to withhold helpful information from those who need it. I hereby give my permission for anyone to use this for their own purposes, and to share it with whoever else might find it useful, especially since BMC didn't provide anything like it themselves. If you make a buck on it, maybe you could share it with me, but I'm not expecting that to happen. :)If anyone from BMC has any issue with what I just said, you have my phone number. I would love to talk to you about it.Enjoy!Rick On Thu, Nov 6, 2008 at 1:13 PM, Mario Roehr Roehr@computacenter.com mailto:Mario.Roehr@computacenter.com> > wrote: Listers,this stuff is confidential and does not have to be shared in other externalforums like this one.Here's the message I got from BMC a few minutes ago:Mario - It has come to my attention that a document posted on BMCDN in aPRIVATE section for BMC Elite and Premier was posted in an external forum.Remember that your company tier (Premier) allows you access to certainconfidential information that other users cannot access.Please make sure that in the future you do not share any confidentialinformation with other users.Please do not ask me further to share this document or to send you a copy.Thanks for understanding.Kind Regards,Mario __Platinum Sponsor: www.rmsportal.comARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.comARSlist: "Where the Answers Are" html___ *IMPORTANT NOTICE: This communication, inc

Re: ITSM 7 Operational Categorizations

2008-11-07 Thread Easter, David

You could also post publicly available documents created by the community on 
the public section of BMC DN.  That way it would be available to anyone with a 
login on BMC DN (login access isn't restricted) and not just to BMC partners.
 
The reason this issue came up is because the document was posted in the 
partner/BMC section of the BMC DN.  Had it been posted in the public section, 
there wouldn't have been any issues around distribution.
 
(Of course, I'm assuming the document was community developed and publicly 
available as per Rick's statement.  Obviously, BMC or partner confidential 
documents would continue to be posted in the BMC/Partner section of BMC DN and 
thus require the restricted access.)
 
-David J. Easter
Sr. Product Manager, Solution Strategy and Development
BMC Software, Inc.
 
The opinions, statements, and/or suggested courses of action expressed in this 
E-mail do not necessarily reflect those of BMC Software, Inc.  My voluntary 
participation in this forum is not intended to convey a role as a spokesperson, 
liaison or public relations representative for BMC Software, Inc.



From: Action Request System discussion list(ARSList) on behalf of Thad K Esser
Sent: Fri 11/7/2008 9:04 AM
To: arslist@ARSLIST.ORG
Subject: Re: ITSM 7 Operational Categorizations


** 
Perhaps a wiki.  Something like Axton's http://www.arswiki.org/ 

Thad Esser
Remedy Developer
"Argue for your limitations, and sure enough, they're yours."-- Richard Bach 



"Meyer, Jennifer L" <[EMAIL PROTECTED]> 
Sent by: "Action Request System discussion list(ARSList)"  

11/07/2008 06:31 AM 
Please respond to
arslist@ARSLIST.ORG


To
arslist@ARSLIST.ORG 
cc
Subject
Re: ITSM 7 Operational Categorizations  






** 
You know, isn't it time we started a non-BMC controlled knowledgebase?  Maybe 
something MySQL-based or something similar?  I remember someone attempting to 
do so several years back, but it didn't get off the ground.  And Matt 
Reinfeldt's site was very busy, but difficult to maneuver-and I could never 
remember my password.  Perhaps it's time to look into it again. 
  
Jennifer Meyer 
919-995-2402 
[EMAIL PROTECTED] 




From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Rick Cook
Sent: Thursday, November 06, 2008 9:51 PM
To: arslist@ARSLIST.ORG
Subject: Re: ITSM 7 Operational Categorizations 
  
** Well, as the author of the document, I posted it on the BMCDN for 
convenience purposes only, not as an exclusive place for you all to get to it 
or to grant BMC exclusive rights over it.  If BMC has a problem with people 
getting this document from some other source, they can come talk to me.  If BMC 
hassles any of you about it, also refer them to me.  I'll take care of it.

I'm very flattered that so many of you find this information valuable, and I 
see no reason to withhold helpful information from those who need it.  I hereby 
give my permission for anyone to use this for their own purposes, and to share 
it with whoever else might find it useful, especially since BMC didn't provide 
anything like it themselves.  If you make a buck on it, maybe you could share 
it with me, but I'm not expecting that to happen.  :)

If anyone from BMC has any issue with what I just said, you have my phone 
number.  I would love to talk to you about it.

Enjoy!

Rick 
On Thu, Nov 6, 2008 at 1:13 PM, Mario Roehr <[EMAIL PROTECTED] <mailto:[EMAIL 
PROTECTED]> > wrote: 


Listers,

this stuff is confidential and does not have to be shared in other external
forums like this one.
Here's the message I got from BMC a few minutes ago:

Mario - It has come to my attention that a document posted on BMCDN in a
PRIVATE section for BMC Elite and Premier was posted in an external forum.
Remember that your company tier (Premier) allows you access to certain
confidential information that other users cannot access.
Please make sure that in the future you do not share any confidential
information with other users.

Please do not ask me further to share this document or to send you a copy.

Thanks for understanding.

Kind Regards,
Mario 

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ 

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ 

*IMPORTANT NOTICE: This communication, including any attachment, contains 
information that may be confidential or privileged, and is intended solely for 
the entity or individual to whom it is addressed. If you are not the intended 
recipient, you should delete this message and are hereby notified that any 
disclosure, copying, or distribution of this message is strictly prohibited. 
Nothing in this email, including any

Re: ITSM 7 Operational Categorizations

2008-11-07 Thread Thad K Esser

Perhaps a wiki.  Something like Axton's http://www.arswiki.org/

Thad Esser
Remedy Developer
"Argue for your limitations, and sure enough, they're yours."-- Richard 
Bach



"Meyer, Jennifer L" <[EMAIL PROTECTED]> 
Sent by: "Action Request System discussion list(ARSList)" 

11/07/2008 06:31 AM
Please respond to
arslist@ARSLIST.ORG


To
arslist@ARSLIST.ORG
cc

Subject
Re: ITSM 7 Operational Categorizations






** 
You know, isn?t it time we started a non-BMC controlled knowledgebase? 
Maybe something MySQL-based or something similar?  I remember someone 
attempting to do so several years back, but it didn?t get off the ground. 
And Matt Reinfeldt?s site was very busy, but difficult to maneuver?and I 
could never remember my password.  Perhaps it?s time to look into it 
again. 
 
Jennifer Meyer
919-995-2402
[EMAIL PROTECTED]

From: Action Request System discussion list(ARSList) 
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Thursday, November 06, 2008 9:51 PM
To: arslist@ARSLIST.ORG
Subject: Re: ITSM 7 Operational Categorizations
 
** Well, as the author of the document, I posted it on the BMCDN for 
convenience purposes only, not as an exclusive place for you all to get to 
it or to grant BMC exclusive rights over it.  If BMC has a problem with 
people getting this document from some other source, they can come talk to 
me.  If BMC hassles any of you about it, also refer them to me.  I'll take 
care of it.

I'm very flattered that so many of you find this information valuable, and 
I see no reason to withhold helpful information from those who need it.  I 
hereby give my permission for anyone to use this for their own purposes, 
and to share it with whoever else might find it useful, especially since 
BMC didn't provide anything like it themselves.  If you make a buck on it, 
maybe you could share it with me, but I'm not expecting that to happen. :)

If anyone from BMC has any issue with what I just said, you have my phone 
number.  I would love to talk to you about it.

Enjoy!

Rick
On Thu, Nov 6, 2008 at 1:13 PM, Mario Roehr <[EMAIL PROTECTED]
> wrote:


Listers,

this stuff is confidential and does not have to be shared in other 
external
forums like this one.
Here's the message I got from BMC a few minutes ago:

Mario ? It has come to my attention that a document posted on BMCDN in a
PRIVATE section for BMC Elite and Premier was posted in an external forum.
Remember that your company tier (Premier) allows you access to certain
confidential information that other users cannot access.
Please make sure that in the future you do not share any confidential
information with other users.

Please do not ask me further to share this document or to send you a copy.

Thanks for understanding.

Kind Regards,
Mario

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" 
html___ 
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" 
html___ 

*IMPORTANT NOTICE: This communication, including any attachment, contains 
information that may be confidential or privileged, and is intended solely for 
the entity or individual to whom it is addressed.  If you are not the intended 
recipient, you should delete this message and are hereby notified that any 
disclosure, copying, or distribution of this message is strictly prohibited.  
Nothing in this email, including any attachment, is intended to be a legally 
binding signature.
*

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: ITSM 7 Operational Categorizations

2008-11-07 Thread Meyer, Jennifer L

You know, isn't it time we started a non-BMC controlled knowledgebase?  Maybe 
something MySQL-based or something similar?  I remember someone attempting to 
do so several years back, but it didn't get off the ground.  And Matt 
Reinfeldt's site was very busy, but difficult to maneuver-and I could never 
remember my password.  Perhaps it's time to look into it again.

Jennifer Meyer
919-995-2402
[EMAIL PROTECTED]

From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Rick Cook
Sent: Thursday, November 06, 2008 9:51 PM
To: arslist@ARSLIST.ORG
Subject: Re: ITSM 7 Operational Categorizations

** Well, as the author of the document, I posted it on the BMCDN for 
convenience purposes only, not as an exclusive place for you all to get to it 
or to grant BMC exclusive rights over it.  If BMC has a problem with people 
getting this document from some other source, they can come talk to me.  If BMC 
hassles any of you about it, also refer them to me.  I'll take care of it.

I'm very flattered that so many of you find this information valuable, and I 
see no reason to withhold helpful information from those who need it.  I hereby 
give my permission for anyone to use this for their own purposes, and to share 
it with whoever else might find it useful, especially since BMC didn't provide 
anything like it themselves.  If you make a buck on it, maybe you could share 
it with me, but I'm not expecting that to happen.  :)

If anyone from BMC has any issue with what I just said, you have my phone 
number.  I would love to talk to you about it.

Enjoy!

Rick
On Thu, Nov 6, 2008 at 1:13 PM, Mario Roehr <[EMAIL PROTECTED]<mailto:[EMAIL 
PROTECTED]>> wrote:


Listers,

this stuff is confidential and does not have to be shared in other external
forums like this one.
Here's the message I got from BMC a few minutes ago:

Mario - It has come to my attention that a document posted on BMCDN in a
PRIVATE section for BMC Elite and Premier was posted in an external forum.
Remember that your company tier (Premier) allows you access to certain
confidential information that other users cannot access.
Please make sure that in the future you do not share any confidential
information with other users.

Please do not ask me further to share this document or to send you a copy.

Thanks for understanding.

Kind Regards,
Mario

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: ITSM 7 Operational Categorizations

2008-11-07 Thread Meyer, Jennifer L

Kudos, Rick!

Jennifer Meyer

From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Rick Cook
Sent: Thursday, November 06, 2008 9:51 PM
To: arslist@ARSLIST.ORG
Subject: Re: ITSM 7 Operational Categorizations

** Well, as the author of the document, I posted it on the BMCDN for 
convenience purposes only, not as an exclusive place for you all to get to it 
or to grant BMC exclusive rights over it.  If BMC has a problem with people 
getting this document from some other source, they can come talk to me.  If BMC 
hassles any of you about it, also refer them to me.  I'll take care of it.

I'm very flattered that so many of you find this information valuable, and I 
see no reason to withhold helpful information from those who need it.  I hereby 
give my permission for anyone to use this for their own purposes, and to share 
it with whoever else might find it useful, especially since BMC didn't provide 
anything like it themselves.  If you make a buck on it, maybe you could share 
it with me, but I'm not expecting that to happen.  :)

If anyone from BMC has any issue with what I just said, you have my phone 
number.  I would love to talk to you about it.

Enjoy!

Rick
On Thu, Nov 6, 2008 at 1:13 PM, Mario Roehr <[EMAIL PROTECTED]<mailto:[EMAIL 
PROTECTED]>> wrote:

Listers,

this stuff is confidential and does not have to be shared in other external
forums like this one.
Here's the message I got from BMC a few minutes ago:

Mario - It has come to my attention that a document posted on BMCDN in a
PRIVATE section for BMC Elite and Premier was posted in an external forum.
Remember that your company tier (Premier) allows you access to certain
confidential information that other users cannot access.
Please make sure that in the future you do not share any confidential
information with other users.

Please do not ask me further to share this document or to send you a copy.

Thanks for understanding.

Kind Regards,
Mario

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: ITSM 7 Operational Categorizations

2008-11-06 Thread Rick Cook

Well, as the author of the document, I posted it on the BMCDN for
convenience purposes only, not as an exclusive place for you all to get to
it or to grant BMC exclusive rights over it.  If BMC has a problem with
people getting this document from some other source, they can come talk to
me.  If BMC hassles any of you about it, also refer them to me.  I'll take
care of it.

I'm very flattered that so many of you find this information valuable, and I
see no reason to withhold helpful information from those who need it.  I
hereby give my permission for anyone to use this for their own purposes, and
to share it with whoever else might find it useful, especially since BMC
didn't provide anything like it themselves.  If you make a buck on it, maybe
you could share it with me, but I'm not expecting that to happen.  :)

If anyone from BMC has any issue with what I just said, you have my phone
number.  I would love to talk to you about it.

Enjoy!

Rick

On Thu, Nov 6, 2008 at 1:13 PM, Mario Roehr
<[EMAIL PROTECTED]>wrote:

>
>
> Listers,
>
> this stuff is confidential and does not have to be shared in other external
> forums like this one.
> Here's the message I got from BMC a few minutes ago:
>
> Mario – It has come to my attention that a document posted on BMCDN in a
> PRIVATE section for BMC Elite and Premier was posted in an external forum.
> Remember that your company tier (Premier) allows you access to certain
> confidential information that other users cannot access.
> Please make sure that in the future you do not share any confidential
> information with other users.
>
> Please do not ask me further to share this document or to send you a copy.
>
> Thanks for understanding.
>
> Kind Regards,
> Mario

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: ITSM 7 Operational Categorizations



Listers,

this stuff is confidential and does not have to be shared in other external
forums like this one.
Here's the message I got from BMC a few minutes ago:

Mario – It has come to my attention that a document posted on BMCDN in a
PRIVATE section for BMC Elite and Premier was posted in an external forum.
Remember that your company tier (Premier) allows you access to certain
confidential information that other users cannot access.
Please make sure that in the future you do not share any confidential
information with other users.

Please do not ask me further to share this document or to send you a copy.

Thanks for understanding.

Kind Regards,
Mario

Re: ITSM 7 Operational Categorizations

sent Sherry a copy off list.

Mario



   
 Sherry Smith  
 <[EMAIL PROTECTED] 
 OM>To 
 Sent by: "Action  arslist@ARSLIST.ORG 
 Request System cc 
 discussion
 list(ARSList)"Subject 
 <[EMAIL PROTECTED] Re: ITSM 7 Operational  
 ORG>      Categorizations 
   
   
 06.11.2008 17:51  
   
   
 Please respond to 
 [EMAIL PROTECTED] 
RG 
   
   




**
Thanks but I can't access this from mediafire either.  Had hoped to get
this information emailed to me so that all the security junk would not be a
factor here on my job.
Thanks anyways.
~ Sherry

-Original Message-
From: Jon Chau <[EMAIL PROTECTED]>
To: arslist@ARSLIST.ORG
Sent: Thu, 6 Nov 2008 10:43 am
Subject: Re: ITSM 7 Operational Categorizations

** Due to the all the requests for this doc, I have uploaded it and it
should be available here:

http://www.mediafire.com/?sharekey=0fd89e0201d9df71d2db6fb9a8902bda

Jon

On Thu, Nov 6, 2008 at 8:29 AM, Pam Hollis <[EMAIL PROTECTED]>
wrote:
  I would like a copy also.

  -Original Message-
  From: Action Request System discussion list(ARSList)
  __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers
  Are" html___
Instant access to the latest & most popular FREE games while you browse
with the Games Toolbar - Download Now!
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: ITSM 7 Operational Categorizations

sent Pam a copy off list.

Mario

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: ITSM 7 Operational Categorizations

2008-11-06 Thread Sherry Smith


Thanks but I can't access this from mediafire either.? Had hoped to get this 
information emailed to me so that all the security junk would not be a factor 
here on my job.


Thanks anyways.

~ Sherry

-Original Message-
From: Jon Chau <[EMAIL PROTECTED]>
To: arslist@ARSLIST.ORG
Sent: Thu, 6 Nov 2008 10:43 am
Subject: Re: ITSM 7 Operational Categorizations



** Due to the all the requests for this doc, I have uploaded it and it should 
be available here:

http://www.mediafire.com/?sharekey=0fd89e0201d9df71d2db6fb9a8902bda

Jon


On Thu, Nov 6, 2008 at 8:29 AM, Pam Hollis <[EMAIL PROTECTED]> wrote:

I would like a copy also.


-Original Message-
From: Action Request System discussion list(ARSList)
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ 




___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: ITSM 7 Operational Categorizations

2008-11-06 Thread Sherry Smith

I would like to have a copy as well please.? I tried accessing the site and 
could not retrieve the document.? Thank You!


-Original Message-
From: Mario Roehr <[EMAIL PROTECTED]>
To: arslist@ARSLIST.ORG
Sent: Thu, 6 Nov 2008 10:27 am
Subject: Re: ITSM 7 Operational Categorizations



sent her a copy off list.

Cheers,
Mario

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: ITSM 7 Operational Categorizations

2008-11-06 Thread Jon Chau

Due to the all the requests for this doc, I have uploaded it and it should
be available here:

http://www.mediafire.com/?sharekey=0fd89e0201d9df71d2db6fb9a8902bda

Jon

On Thu, Nov 6, 2008 at 8:29 AM, Pam Hollis <[EMAIL PROTECTED]>wrote:

> I would like a copy also.
>
> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Pargeter, Christie :CO IS
> Sent: Thursday, November 06, 2008 10:12 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: ITSM 7 Operational Categorizations
>
> Can someone send me this doc?
>
> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Mario Roehr
> Sent: Thursday, November 06, 2008 5:58 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: ITSM 7 Operational Categorizations
>
> Listers,
>
> for anyone who is interested, the document can be found here:
>
> http://developer.bmc.com/communities/docs/DOC-3231
>
> Cheers,
> Mario
>
>
>
>
>
>
> Jon Gee
>
> <[EMAIL PROTECTED]
>
> .COM>
> To
> Sent by: "Action  arslist@ARSLIST.ORG
>
> Request System
> cc
> discussion
>
>     list(ARSList)"
> Subject
> <[EMAIL PROTECTED] Re: ITSM 7 Operational
>
> ORG>  Categorizations
>
>
>
>
>
> 06.11.2008 14:13
>
>
>
>
>
> Please respond to
>
> [EMAIL PROTECTED]
>
>RG
>
>
>
>
>
>
>
>
>
> **
>
>
>  I would love a copy of the list myself.
>
>  Please
>
>  Thanks in advance.
>
>
>
>  --- On Wed, 11/5/08, Jon Chau <[EMAIL PROTECTED]> wrote:
>
>  From: Jon Chau <[EMAIL PROTECTED]>
>
>  Subject: Re: ITSM 7 Operational Categorizations
>
>  To: arslist@ARSLIST.ORG
>
>  Date: Wednesday, November 5, 2008, 7:50 PM
>
>
>
>  ** Greetings all,
>
>
>
>  I was wondering if anyone had a copy of this that they could send to
> me.
>  It looks like BMC revamped their developer network site and I can't
> find
>  it.
>
>
>
>  Thanks in advance!
>
>
>
>  Jon
>
>
>
>  On Fri, May 2, 2008 at 10:20 AM, Rick Cook <[EMAIL PROTECTED]>
> wrote:
>** I wish I had published this last year, but better late than
>
>never, I suppose.  This is a link to a paper I just wrote up on
> how
>to set up Operational Categorizations in ITSM 7.  Not a
> procedural
>manual like BMC provides, but one that actually gives an example
> of
>values that one might use, and instructions on how to keep the
>
>lists short.
>
>
>
>I used it once at a customer site, and it seemed to work well.
> A
>few others have begun to make use of it as well, so I thought I
>
>would formalize it and make it available to anyone who might
> gain
>from it.
>
>
>
>
> http://developer.bmc.com/jiveProd/entry!default.jspa?categoryID=861<http://developer.bmc.com/jiveProd/entry%21default.jspa?categoryID=861>
>&externalID=3231&fromSearchPage=true
>
>
>
>Rick
>
>__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the
> Answers
>Are" html___
>
>
>
>  __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>
>  html___
>
>
>
>
>
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___
>
> 
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
> Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>
> 
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: ITSM 7 Operational Categorizations

2008-11-06 Thread Pam Hollis

I would like a copy also.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Pargeter, Christie :CO IS
Sent: Thursday, November 06, 2008 10:12 AM
To: arslist@ARSLIST.ORG
Subject: Re: ITSM 7 Operational Categorizations

Can someone send me this doc? 

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Mario Roehr
Sent: Thursday, November 06, 2008 5:58 AM
To: arslist@ARSLIST.ORG
Subject: Re: ITSM 7 Operational Categorizations

Listers,

for anyone who is interested, the document can be found here:

http://developer.bmc.com/communities/docs/DOC-3231

Cheers,
Mario




 

 Jon Gee

 <[EMAIL PROTECTED]

 .COM>
To 
 Sent by: "Action  arslist@ARSLIST.ORG

 Request System
cc 
 discussion

 list(ARSList)"
Subject 
 <[EMAIL PROTECTED] Re: ITSM 7 Operational

 ORG>      Categorizations

 

 

 06.11.2008 14:13

 

 

 Please respond to

 [EMAIL PROTECTED]

RG

 

 





**
 

 I would love a copy of the list myself.

 Please

 Thanks in advance.

 

 --- On Wed, 11/5/08, Jon Chau <[EMAIL PROTECTED]> wrote:

  From: Jon Chau <[EMAIL PROTECTED]>

  Subject: Re: ITSM 7 Operational Categorizations

  To: arslist@ARSLIST.ORG

  Date: Wednesday, November 5, 2008, 7:50 PM

 

  ** Greetings all,

 

  I was wondering if anyone had a copy of this that they could send to
me.  
  It looks like BMC revamped their developer network site and I can't
find  
  it.

 

  Thanks in advance!

 

  Jon

 

  On Fri, May 2, 2008 at 10:20 AM, Rick Cook <[EMAIL PROTECTED]>
wrote:  
** I wish I had published this last year, but better late than

never, I suppose.  This is a link to a paper I just wrote up on
how 
to set up Operational Categorizations in ITSM 7.  Not a
procedural  
manual like BMC provides, but one that actually gives an example
of 
values that one might use, and instructions on how to keep the

lists short.

 

I used it once at a customer site, and it seemed to work well.
A   
few others have begun to make use of it as well, so I thought I

would formalize it and make it available to anyone who might
gain   
from it.

 

 
http://developer.bmc.com/jiveProd/entry!default.jspa?categoryID=861 
&externalID=3231&fromSearchPage=true

 

Rick

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the
Answers   
Are" html___

 

  __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

  html___

 



__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: ITSM 7 Operational Categorizations

sent her a copy off list.

Cheers,
Mario

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: ITSM 7 Operational Categorizations

2008-11-06 Thread Pargeter, Christie :CO IS

Can someone send me this doc? 

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Mario Roehr
Sent: Thursday, November 06, 2008 5:58 AM
To: arslist@ARSLIST.ORG
Subject: Re: ITSM 7 Operational Categorizations

Listers,

for anyone who is interested, the document can be found here:

http://developer.bmc.com/communities/docs/DOC-3231

Cheers,
Mario

 Jon Gee

 <[EMAIL PROTECTED]

 .COM>
To 
 Sent by: "Action  arslist@ARSLIST.ORG

 Request System
cc 
 discussion

 list(ARSList)"
Subject 
 <[EMAIL PROTECTED] Re: ITSM 7 Operational

 ORG>      Categorizations

 06.11.2008 14:13

 Please respond to

 [EMAIL PROTECTED]

RG

**

 I would love a copy of the list myself.

 Please

 Thanks in advance.

 --- On Wed, 11/5/08, Jon Chau <[EMAIL PROTECTED]> wrote:

  From: Jon Chau <[EMAIL PROTECTED]>

  Subject: Re: ITSM 7 Operational Categorizations

  To: arslist@ARSLIST.ORG

  Date: Wednesday, November 5, 2008, 7:50 PM

  ** Greetings all,

  I was wondering if anyone had a copy of this that they could send to
me.  
  It looks like BMC revamped their developer network site and I can't
find  
  it.

  Thanks in advance!

  Jon

  On Fri, May 2, 2008 at 10:20 AM, Rick Cook <[EMAIL PROTECTED]>
wrote:  
** I wish I had published this last year, but better late than

never, I suppose.  This is a link to a paper I just wrote up on
how 
to set up Operational Categorizations in ITSM 7.  Not a
procedural  
manual like BMC provides, but one that actually gives an example
of 
values that one might use, and instructions on how to keep the

lists short.

I used it once at a customer site, and it seemed to work well.
A   
few others have begun to make use of it as well, so I thought I

would formalize it and make it available to anyone who might
gain   
from it.

http://developer.bmc.com/jiveProd/entry!default.jspa?categoryID=861 
&externalID=3231&fromSearchPage=true

Rick

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the
Answers   
Are" html___

  __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

  html___

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: ITSM 7 Operational Categorizations

2008-11-06 Thread Decou, Candace M

Yes, the same thing happened to me as well.  I sent an email to the address 
noted for problems with the site and received the following from them:
 
If you are trying to reach the registration page for the Solution
Partner Portal on the BMC Developer Network, the correct URL is
http://developer.bmc.com/communities/create-account.jspa 
<https://owa.vzbi.com/exchweb/bin/redir.asp?URL=http://developer.bmc.com/communities/create-account.jspa>
 

We apologize for the inconvenience and hope that you find great benefit
from our system.

This, of course, doesn't help me since I am already registered and can't seem 
to create another account using the same email address.  Go figure.  If anyone 
else can figure out how to get them to either respond to the real question (why 
can't I get in when I am already set up with an account) or to reset something, 
please let me know.
 
thanks,
Candace DeCou
 



From: Action Request System discussion list(ARSList) on behalf of Begosh, Kevin
Sent: Thu 11/06/2008 6:14 AM
To: arslist@ARSLIST.ORG
Subject: Re: ITSM 7 Operational Categorizations



I tried to access the document and I got this error message

This area of the BMC Developer Network is visible only to registered,
logged in users. If you are logged in when you receive this message,
then you might not have sufficient access privileges to view the
requested page. Please contact [EMAIL PROTECTED] if you need further
assistance.

And yes I am registered and I was logged in.


Kevin Begosh, RSP
Tech Ops
Enterprise Business Services
301-791-3540 Phone
410-422-3623 Cell
[EMAIL PROTECTED]

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Mario Roehr
Sent: Thursday, November 06, 2008 8:58 AM
To: arslist@ARSLIST.ORG
Subject: Re: ITSM 7 Operational Categorizations

Listers,

for anyone who is interested, the document can be found here:

http://developer.bmc.com/communities/docs/DOC-3231

Cheers,
Mario






 Jon Gee

 <[EMAIL PROTECTED]

 .COM>
To
 Sent by: "Action  arslist@ARSLIST.ORG

 Request System
cc
 discussion

 list(ARSList)"
Subject
 <[EMAIL PROTECTED] Re: ITSM 7 Operational

 ORG>  Categorizations





 06.11.2008 14:13





 Please respond to

 [EMAIL PROTECTED]

RG









**


 I would love a copy of the list myself.

 Please

 Thanks in advance.



 --- On Wed, 11/5/08, Jon Chau <[EMAIL PROTECTED]> wrote:

  From: Jon Chau <[EMAIL PROTECTED]>

  Subject: Re: ITSM 7 Operational Categorizations

  To: arslist@ARSLIST.ORG

  Date: Wednesday, November 5, 2008, 7:50 PM



  ** Greetings all,



  I was wondering if anyone had a copy of this that they could send to
me. 
  It looks like BMC revamped their developer network site and I can't
find 
  it.



  Thanks in advance!



  Jon



  On Fri, May 2, 2008 at 10:20 AM, Rick Cook <[EMAIL PROTECTED]>
wrote: 
** I wish I had published this last year, but better late than

never, I suppose.  This is a link to a paper I just wrote up on
how
to set up Operational Categorizations in ITSM 7.  Not a
procedural 
manual like BMC provides, but one that actually gives an example
of
values that one might use, and instructions on how to keep the

lists short.



I used it once at a customer site, and it seemed to work well.
A  
few others have begun to make use of it as well, so I thought I

would formalize it and make it available to anyone who might
gain  
from it.




http://developer.bmc.com/jiveProd/entry!default.jspa?categoryID=861
&externalID=3231&fromSearchPage=true



Rick

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the
Answers  
Are" html___



  __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

  html___





__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"



___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: ITSM 7 Operational Categorizations

2008-11-06 Thread Begosh, Kevin

I tried to access the document and I got this error message

This area of the BMC Developer Network is visible only to registered,
logged in users. If you are logged in when you receive this message,
then you might not have sufficient access privileges to view the
requested page. Please contact [EMAIL PROTECTED] if you need further
assistance. 

And yes I am registered and I was logged in. 


Kevin Begosh, RSP
Tech Ops
Enterprise Business Services
301-791-3540 Phone
410-422-3623 Cell
[EMAIL PROTECTED]

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Mario Roehr
Sent: Thursday, November 06, 2008 8:58 AM
To: arslist@ARSLIST.ORG
Subject: Re: ITSM 7 Operational Categorizations

Listers,

for anyone who is interested, the document can be found here:

http://developer.bmc.com/communities/docs/DOC-3231

Cheers,
Mario




 

 Jon Gee

 <[EMAIL PROTECTED]

 .COM>
To 
 Sent by: "Action  arslist@ARSLIST.ORG

 Request System
cc 
 discussion

 list(ARSList)"
Subject 
 <[EMAIL PROTECTED] Re: ITSM 7 Operational

 ORG>      Categorizations

 

 

 06.11.2008 14:13

 

 

 Please respond to

 [EMAIL PROTECTED]

RG

 

 





**
 

 I would love a copy of the list myself.

 Please

 Thanks in advance.

 

 --- On Wed, 11/5/08, Jon Chau <[EMAIL PROTECTED]> wrote:

  From: Jon Chau <[EMAIL PROTECTED]>

  Subject: Re: ITSM 7 Operational Categorizations

  To: arslist@ARSLIST.ORG

  Date: Wednesday, November 5, 2008, 7:50 PM

 

  ** Greetings all,

 

  I was wondering if anyone had a copy of this that they could send to
me.  
  It looks like BMC revamped their developer network site and I can't
find  
  it.

 

  Thanks in advance!

 

  Jon

 

  On Fri, May 2, 2008 at 10:20 AM, Rick Cook <[EMAIL PROTECTED]>
wrote:  
** I wish I had published this last year, but better late than

never, I suppose.  This is a link to a paper I just wrote up on
how 
to set up Operational Categorizations in ITSM 7.  Not a
procedural  
manual like BMC provides, but one that actually gives an example
of 
values that one might use, and instructions on how to keep the

lists short.

 

I used it once at a customer site, and it seemed to work well.
A   
few others have begun to make use of it as well, so I thought I

would formalize it and make it available to anyone who might
gain   
from it.

 

 
http://developer.bmc.com/jiveProd/entry!default.jspa?categoryID=861 
&externalID=3231&fromSearchPage=true

 

Rick

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the
Answers   
Are" html___

 

  __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

  html___

 



__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: ITSM 7 Operational Categorizations

2008-11-06 Thread Icarus4

Hello listers,

Anyone who can share the document with me?

Thanks


Rick Cook-3 wrote:
> 
> I wish I had published this last year, but better late than never, I
> suppose.  This is a link to a paper I just wrote up on how to set up
> Operational Categorizations in ITSM 7.  Not a procedural manual like BMC
> provides, but one that actually gives an example of values that one might
> use, and instructions on how to keep the lists short.
> 
> I used it once at a customer site, and it seemed to work well.  A few
> others
> have begun to make use of it as well, so I thought I would formalize it
> and
> make it available to anyone who might gain from it.
> 
> http://developer.bmc.com/jiveProd/entry!default.jspa?categoryID=861&externalID=3231&fromSearchPage=true<http://developer.bmc.com/jiveProd/entry%21default.jspa?categoryID=861&externalID=3231&fromSearchPage=true>
> 
> Rick
> 
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> 
> 

-- 
View this message in context: 
http://www.nabble.com/ITSM-7-Operational-Categorizations-tp17025192p20361619.html
Sent from the ARS (Action Request System) mailing list archive at Nabble.com.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: ITSM 7 Operational Categorizations