Very good points. Thank you! Jason On Sep 24, 2011 6:18 AM, "Brian Pancia" <panc...@finityit.com> wrote: > Christopher, > > > > That was a great post and is where some people are confused. One of my > customers is convinced that the SRM app is going to handle all Service > Requests. I just started there and I have a little damage control on some > miss guided advice over there. For anyone who is not familiar with SRM. > SRM is merely a customer facing portal. The customer will submit Service > Requests that are defined for them on the portal. These defined requests > are then passed to Incidents, Work-Orders, Changes, or your own custom form. > This is dependent on the business rules that have been established for each > service request. There is no Service Request Management application for > support staff to work service requests. > > > > Another area of miss understanding is the Incident Management application > itself. In ITILv2 Incident Management, Request Fulfillment, and Event > Management all fell under Incident Management. In ITILv3 these were split > out. The naming of the Incident Management app comes from ITILv2. This is > where confusion and water boarding happens. > > > > Another area that is common is what applications organizations own and have > licensed. BMC's license model use to be each app had to be purchased > separately in addition to their user licenses. Now you get the whole suite > for one great low price, plus of coarse user licenses. Most organizations > have transferred from the old model to the new. However, they have not > bought user licenses for all the applications and continue to put everything > in the Incident Management application. So many organizations have become > creative with how they use Incident Management app to incorporate all there > processes. In a perfect world they would own all the apps and everyone in > the organization from the janitor all the way up to the executive management > would understand ITIL inside and out. > > > > This is why everyone has different ways of setting up categorization and > huge debates on what should be there. It really doesn't matter if you use > Tier 1- Blue, Tier 2-Green, and Tier 3-Purple for your categorization. As > long as the organization knows what that means and it is import to them. > This is the whole premise behind ITIL. Standardize on Processes, > Procedures, Services, and Terminology. It's not necessarily about industry > best practices, it's about an organizations best practices. A lot of > organizations have focused on industry best practices and completely forgot > about theirs. The problem here is that they got rid of what really worked > for them and replaced it with what is considered industry best practices, > which may or may not work for them. Seems a little silly. > > > > So another example of categorization could be: > > > > Blue, Green, Purple > > > > Brian > > > > > > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of strauss > Sent: Friday, September 23, 2011 10:06 PM > To: arslist@ARSLIST.ORG > Subject: Re: Age old debate - categorizations > > > > ** > > Rambling thoughts on applying ITSM to the real world, after a long, grueling > week spent in multi-hour WebEx's diagnosing and fixing problems in > 7.6.04.01. > > > > You shouldn't think of Requests as alternatives to Incidents. Think of SRM > (or Kinetic Request in our case) as your customer self-service portal, where > you gently extract information from the Requester with which to create an > Incident (no water-boarding, please) . They display the IT services that > someone is eligible to request, and create Incidents (normally - or other > types of requests if you want them to) from customer responses, but since > most IT helpdesks and support staff do their work in the Incident Console, > the requests have to end up there at some point. By most standards and our > interpretation of ITIL best practices, everything starts as an Incident from > the IT support staffer's point of view, but remember that an Incident comes > in different types as mentioned by "moe." Our SLAs (response times and > resolution times) are dramatically different for the four Incident types, so > they really are handled differently (if for no other reason than the > escalations range from 2 hours to 4 days). If you need to spawn a Problem, > Change, Task, or other similar ticket, those should be created by the IT > support staff working on the Incident, NOT the customer. The way ITSM 7.x > works, just about every other form is fed from an incident, and they are > much less customer-centered in their design. > > > > If you, as a customer or a support staffer who gets lost in the Incident > interface (more prevalent in the pre-best-practice multi-tabbed interface), > want to enter a request quickly, on your own, or at 3 in the morning, you go > to Kinetic (or SRM, I guess) and enter it yourself. If you call the > helpdesk (while they are open), they will enter an incident for you - > directly; they use the same Incident Templates that the Kinetic Requests use > for consistency. Sometimes they walk the customer through entering it > themselves so that they know how in the future. Our Kinetic interface will > allow a customer to update their Incident's work log even if they did not > enter the incident through Kinetic (which the Requester Console/SRM will not > do - they need the request record to work through), so once a request is > translated into an Incident the original Request is of less or no importance > - in the Requester Console or SRM it is a surrogate to the Incident for > customers who have no access to the actual Incident. > > > > I say this based on what I _think_ SRM does since we never had access to it > until we got suite licensing, never installed it until 7.6.04.01, and still > haven't touched it (and the docs have no screen shots so I have no idea what > it really looks like). We used the Requester Console in 4.x and 5.5 and > tested it for 7.0 so my practical concepts come from there. We did > configure it to create the surrogate Request for each Incident, which may > still be an option in 7.6.x, but our users hated it and would not use it due > to the myriad browser problems with early mid-tiers. Setting Incidents to > create corresponding Request records might fit your model better, if they > are required for the customer interface. > > > > As to new, unique features in SRM, I think the Work Orders function would be > best used for a specific process that cannot be confused with Incidents, but > again, I never have seen it in action. If it weren't for the fact that our > Telecomm has its own work order application, microcomputer maintenance and > classroom support and Facilities all have their own systems too (welcome to > academia), I would consider using the Work Order portion of SRM for those > types of discreet services. > > > > So, the Requests (SRM or Kinetic) are your customer interface; IT support > staff will never look at them or use them to work their issues - they will > use Incidents as a rule, and Problems/Known > Errors/Solutions/Changes/Tasks/Releases/Activities as second/third level > tools to manage the work behind those Incidents. You can get as fancy and > sophisticated as you want with your customer portal (good luck with that > next SRM upgrade), but in the end, it's just a way to take customer input > and create Incidents for the IT Staff to work on. > > > > Or not. ITIL is only a framework, isn't it?? > > > > BTW, forcing a customer to look at in Incident form, especially the Classic > View, is considered worse than water-boarding in some circles. > > > > Christopher Strauss, Ph.D. > Call Tracking Administration Manager > University of North Texas Computing & IT Center > http://itsm.unt.edu/ > > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of Jan Lindhardsen > Sent: Friday, September 23, 2011 4:59 PM > To: arslist@ARSLIST.ORG > Subject: Re: Age old debate - categorizations > > > > ** > > God how I love these discussions, there is always so many ways to do this, > and only a couple of them is dead wrong... > > It's always very useful to see how other people have solved this! > > > > Richard, Im completely on your track in regard to what is an Incident and > what is a Service Request. But... > > Consider that we, as some will argue, should register Incidents in IM, and > Service Requests in SRM > > Consider that we have a service desk, acting as a single point of contact, > answering customers on the phone. > > When a customer calls in with "printer not printing" issue, this is clearly > an incident, and we will register it in IM. > > When the customer calls in an says that he has forgotten his password, this > should then be registered in SRM, but how? As we do not have a "backend" for > registering Service Requests. > > Also say that we would register this as work orders (not the same as a > service request), it will be confusing and time consuming for the CSR to > decide, and alway choose to start out in the right application. > > > > Using IM to register both Incidents and Service Requests solves part of this > issue, but from a pragmatic point of view, SR's has got nothing to do, being > mixed up with my Incidents... > > > > I had a long discussion with a customer a year back, where the customer > argued that everything should start out as a service request, and then after > the call (or during), the CSR has to decide if the SR should be "escalated" > to an Incident, Change etc... Thank god I managed to talk him out of this! > Not because he necessarily is wrong in his view on things, but because it > would be more or less impossible to handle in ITSM/SRM as it is today, and > it would just ad a huge extra layer of complexity and administration to the > whole solution ;-) > > > > And again, it will be interesting to see how the rest of you think around > this, and how you have solved it in real life! > > > > Best > > /Jan > > > > On Sep 23, 2011, at 17:06 , Gard, Richard J wrote: > > > > ** 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). > > > > _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"
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
