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
<tommy.mor...@radioshack.com> 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 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 <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" <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] 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
<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 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"
<marc...@cpchem.com> 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"
> <panc...@finityit.com<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 <tel:%28571%29%20252-5090%20x301>
<tel:%28571%29%20252-5090%20x301>
>>> Fax: (571) 222-0043 <tel:%28571%29%20222-0043>
<tel:%28571%29%20222-0043>
>>>
<mailto:brian.pan...@finityit.com<mailto:brian.pan...@finityit.com>>
> brian.pan...@finityit.com<mailto:brian.pan...@finityit.com>
>
>
> _attend WWRUG11 www.wwrug.com <http://www.wwrug.com/>
ARSlist: "Where the Answers Are"_
>
>
>
________________________________________________________________________
_______
> 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 <http://www.wwrug.com/> ARSlist:
"Where the Answers Are"_
_attend WWRUG11 www.wwrug.com <http://www.wwrug.com/> ARSlist:
"Where the Answers Are"_
_attend WWRUG11 www.wwrug.com <http://www.wwrug.com/> ARSlist:
"Where the Answers Are"_
________________________________
This e-mail and its attachments may contain Forest Laboratories,
Inc. proprietary information that is privileged, confidential or subject
to copyright belonging to Forest Laboratories, Inc. This e-mail is
intended solely for the use of the individual or entity to which it is
addressed. If you are not the intended recipient of this e-mail, or the
employee or agent responsible for delivering this e-mail to the intended
recipient, you are hereby notified that any dissemination, distribution,
copying or action taken in relation to the contents of and attachments
to this e-mail is strictly prohibited and may be unlawful. If you have
received this e-mail in error, please notify the sender immediately and
permanently delete the original and any copy of this e-mail and any
printout.
_attend WWRUG11 www.wwrug.com <http://www.wwrug.com/> ARSlist:
"Where the Answers Are"_
_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"
