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<%28571%29%20252-5090%20x301>> > > >>> Fax: (571) 222-0043 <tel:%28571%29%20222-0043 <%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 ARSlist: "Where the Answers Are"_ > > > > > > > _______________________________________________________________________________ > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"**** > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ **** > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ **** > > _attend WWRUG11 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 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"
