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" <tauf.chowdh...@frx.com> 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 <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> >>>> Fax: (571) 222-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 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. > > > _______________________________________________________________________________ > 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"
