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"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
