If BMC spent 10% of the Money they spend in toiletpaper on Srm once! This product would be sweet! Unfortunately we are... where we are... Even in 7.6.04.01. There are all kinds of shortfalls: we have 952 Srms (don't shoot the business design I didn't do it!!) I wish I had kinetic! BMC spend a couple of dollars on en Enginner to help SRM ... Please!!! The recommended BMC practice for upgrade in N O T. Import export!!!! It is upgrade the whole db!!! all kinds of issues getting just from 7.6 to 7.6.04 ... They have me changing the Db tables and doing hot patches and all kinds of stuff just to export and then it fails on import!!! Errrrrrrrrr
If I had a chance I'd tell you how I really feel! Lol Tired ... I love remedy but I hope management starts using their brains rather than a calculator ($) to do business!!! Sent from my iPhone so typo's or funky words can and do happen! On Sep 24, 2011, at 9:17 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"_ > > _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"
