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