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" <[email protected]> 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:[email protected]] On Behalf Of Rick Cook > Sent: Friday, September 23, 2011 9:39 AM > To: [email protected] > 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 <[email protected]> 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:[email protected]] On Behalf Of Rick Cook > Sent: Thursday, September 22, 2011 9:11 AM > To: [email protected] > 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" <[email protected]> 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:[email protected]] On Behalf Of Rick Cook >> Sent: Thursday, September 22, 2011 7:36 AM >> To: [email protected] >> 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" > <[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>> > [email protected]<mailto:[email protected]> > > > _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"
