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"
