Incident vs Service Request
I need your assistance please. I am having a debate right now with some folks here about creating an incident ticket(ICM) when a Service Request(SVR) has not been successfully completed. Why should we open an incident …this is not what ITIL says.
Why are we reworking SVR’s as ICM’s? This is incorrect from an ITIL perspective. The purpose of Incident Management is to restore service during an outage or service-affecting-issue as quick as possible.
Would this be classed as a change-related incident i.e. a SVR was not done correctly which results in an incident being created. Now the resolution of that rework is being driven through an incident.
You response will be greatly appreciated.
Rgds
Dear Rgds
I'm not sure all SVRs are a CRI? Sme SVRs are a CIIHAMP (can I have a manual please) or a MMD (move my desktop) or a GMATTFP (give me access to the portal or else). Are they CRIs? or JPRs (just plain requests)?
So is a SVR a service or at least part of one? Many would think so. If a SVR is SNAFU then is that an I2S (interruption to service) or not?
According to TSTs (The Sacred Texts) if a change fails then it is a "revised RFC" according to ST 4.2.6.7 - it does refer to "incidents arising" but I think they mean IIs (inadvertent ICMs).
So if a SVR is an RFC and gets SNAFU and causes IIs, then it should become a RRFC, but if a SVR is a JPR then when it GPS (goes pear shaped) it might arguably be an I2S and hence cause ICM.
Cheers
TIW
P.S. I like talking to you - I can IMOA (invent my own acronyms)
Made in New Zealand 
Comments
SCBWALOT!
So Confusing But With A Lot Of Truth!
Who mugged the service request?
The humble service request has been mugged and misrepresented - within IT. Any interaction between a consumer (customer or prospect) and a service provider organization and its products and services, that may consume provider resources of any kind, may I say, is a service request. This includes the 99% that goes unreported by many - such as a successful withdrawal of cash from an ATM - service in stealth mode by application systems.
An incident is but one type of service request, and frankly its overdue frameworks such as ITIL got this message. Who says so - I do in the USMBOK and in my everyday onsite work - and well received it all is may I say.
Remember - customer interactions drive provider workload and work effort. Its important to be able to simply report on ALL service requests responded to by the provider, by customer, by location, by line of business, by service and so on... splitting them out into different and disparate 'processes' just makes it all the more complex, unnecessarily...
The Evolution of the Service Request
I agree. See the article The Evolution of the Service Request. They should be managed holistically - failing to is another example of Inside-Out thinking in ITIL.
I later developed this into a list of request categories
HI! ITS USE MOR TLA
The IT Sekptice should use more three letter abbreviations! Great
Hate to say it's the tools' fault, but...
It is kinda the tools' fault. They view everything that comes in as a ticket and until recently when ITIL buzz hit the level that they had to take notice, they shifted that ticket for the end user to be either an SVR or an INCident... I just had the conversation on behalf of my customer that wanted an SVR module that addressed the delivery of a set of standard (see Service Catalog) and non-standard SVRs, tracked separately from Incidents. Their tool consultant said, sorry, that's not how we do it... Even when pushed, they then said well we could, but it will cost ... and so on.
I think on this specific discussion point, we're a bit held hostage by the maturity of our tools to 1. be flexible to meet our process and work definition needs and 2. align with the good practices most of us follow. And yet now I hear via another blog post that ITIL fervor is dying and tool vendors are saying they don't care some much about ITIL. Half a step forward, 10 back, half forward 6 more back...
As a result, I fear, we'll be back to buying the shiny tool in a box since we can't live without it and yet are held hostage by it's vision for all our operations, high costs to make it fit our 'defacto standard based' process environments, then with no upgrade path out of what we've customized to death, back into the proverbial ITSM tool death spiral. Service-now.com anyone? New technology approach, tool is meant for ease of configuration to meet our needs, guaranteed upgrade paths, etc....
Using Incidents for Failed Service Requests
Hi,
I'd like to add that if you try to solve this problem, using ITIL, you will fail or get a very limited solution that adds little to no real value...
The definition of an Incident, to the majority of the world, is: "A reported or communicated disruption to normal events or expected behavior."
If a Service, large or small ("small" such as in the case of a Service Request) does not perform properly or is disrupted in any way, most companies "would" view this as an Incident that needs to be reported against that Service.
We use Incident Reports to track disruptions to any and all Services (big, small, IT, or non-IT as in Business Services). If the Incident Reports do not contain information about any and all Services, their usefulness is limited, at best.
Keep in mind that if you follow ITIL (instead of using common sense) to try and solve such problems, you will have a hard time being successful. ITIL is very myopic. Put yourself in the CEO's position and not in the in the seat of the British OGC who has an agenda to push ITIL. Better yet, pretend it's your company. What would you do to be successful? Would you implement ITIL (a partial and confusing solution that in many cases violates common sense) or would you implement common sense?
Anyhow, I hope this helps.
My Best,
Frank
--
The International Foundation for Information Technology (IF4IT)
Open IT Standards
Incidents for Failed Service Requests
Hi guys,
this reminds me of the old chestnut about whether an Incident that breaches service level and is "serious" should be escalated into a problem. Well Incidents and incidents and problems are problems. We have separate processes such that we deliver in the interests of the customer rather than IT "Hey why don't we sit around all day and look at this very interesting occurence until we find the root cause".
Simarly requests are requests. If they go into breach they are breached requests - kicking off another process will just screw things up e.g. What priority will this be and who do we allocate it to etc. In the end it will end up as an escalation process attatched to the request.
ITIL is perfectly fit for purpose for this sort of stuff, especially in the IT Services domain - in other domains you'd also have to give it some serious consideration.
Dave