Page 1 of 1

an incident becomes a change...?

Posted: Thu Oct 22, 2009 8:26 am
by informize
Hello all itil-gurus !
im sorry if i post this question in the wrong forum, its my first post here

i have a fairly simple question

in itil, can an incident becoming a change?

i always thought of them being two seperate processes.



thanks alot

greetings Informize

Posted: Thu Oct 22, 2009 9:24 am
by UKVIKING
NOPE

An incident is an incident
a change is a change

It may be to restore service and close an open incident a change may be generated and implemented but that is it

Does that answer the exam like question

Posted: Tue Oct 27, 2009 7:18 am
by nisarg
further to what Mr UKVIking said, i would just like to add that

change can be initiated as an implementation of solution for an Incident or problem , but it has to follow its regular workflow of coming via a change request.

An incident ticket can never be replaced with a change request .

However in few organizations some preapproved changes can be treated as user requests, example password resets

Posted: Tue Oct 27, 2009 10:10 am
by rpmason
...some preapproved changes can be treated as user requests, example password resets
What part of the infrastructure did you change? Do I need to create an RFC when I change my own password? Does the CI need to be updated with my new password?

A password reset is a Service Request not a Request for Change.

Posted: Tue Oct 27, 2009 10:57 am
by rpmason
Nisarg, I'll be more gentle.

I think maybe you might be just using some misleading wording... "pre-approved change" = user request (aka Service Request); when actually "pre-approved change" = Standard Change.

Homework assignment: Do a little more reading about Service Requests and Standard Changes. Which process does each belong to? Compare and contrast them. What are the benefits and problems of each? What are the requirements for each?

Posted: Wed Oct 28, 2009 8:07 am
by viv121
Ruth,

Shouldn't we leave Informize do the way he wants to do? When you say RFC for password required, why do you need one when you are already saying pre-approved change. Don't we raise RFCs to get the changes approved. When we change password of people who come to office with a a weekend hangover, are we not changing something in the production environment? How is it a service request by the way? If the user calls and tells that the computer is broken, isn't it a service request where the user is requesting a service for his machine. I think you are confusing between a service request and a new service request. What we call as incidents are also service requests in more ways than one.

It depends how we wan to take it. More than we, its Informize's call I guess.

Posted: Wed Oct 28, 2009 10:00 am
by rpmason
Hi Viv. I wasn't clear. This was my point:
...when actually "pre-approved change" = Standard Change.
I was responding to Nisarg, not Informize--and only about Nisarg's last sentence. It might have just been loose wording. But I'm seeing more and more confusion between Service Requests and Standard Changes, even in my own organization.

Like John said, an incident is an incident and a change is a change. A user request (aka Service Request) might generate a Request for Change or it might not.

Change Management doesn't care whether an agent reset a password. However, the Service Desk does care; they might even want a Problem ticket generated if the volume of calls for resets warranted it.

Standard Disclaimer. If someone has a *good* reason to use Change Management to track the resetting of passwords, then good.

P.S. I had my 12-character-that-follows-complex-rules desktop password reset two times in as many days this week. :oops: I'd love to see the Service Desk call metrics on those Service Requests.

Posted: Sun Nov 08, 2009 5:56 am
by nisarg
Ruth,

Apologies for the delayed reply

As adviced Home work Done.

As per ITIL V3 Service Operation Book

Service request is defined as

"Service Request
"A service request is a request from a user for information or
advice, or for a standard change, or for access to an IT service.""

So concluded even a pwd reset which is a service request and it is a standard aka pre approved change

Posted: Sun Nov 08, 2009 6:58 pm
by asrilrm
Hi,

By no means of interfering,

- password reset, server reboot, etc. as pre-approved changes (requested via Incident Management though) are in V2 because Service Request is not there yet.

- password reset, server reboot, etc. as Service Requests are in the V3, requested via Request Fulfillment.

I guess in V3 pre-approved change has morphed into Service Request.

As usual, it depends on what ITIL version you are using.

Cheers,
Asril

Posted: Mon Nov 09, 2009 5:46 am
by Diarmid
asrilrm wrote:As usual, it depends on what ITIL version you are using.
The only time it matters which version of ITIL you are using is when you are preparing for or sitting an exam.

We have to get away from dissecting the words in the manuals and get more into understanding the nature of good service management. As informize's initial question illustrates, there are many coming here thinking that ITIL is authoritative and specific in areas that it is no more than a provider of concepts, guiding principles and examples.

I have dug out my course work from my manager course in 1994, blown the dust away, and tried to work out what the original ITIL said on the subject. As far as I can determine, it didn't. Nevertheless I had catered for what later were covered by the concepts of "pre-approved" or "standard" change long before I read ITIL v2. I am sure many others did the same, solving the problem in a way that suited their circumstances.

Irrespective of which of the three ITILs you have access to, your objective is always the same and what you do to achieve it has to be informed not only by the books but by the management system you are working within, the nature of your organization and your experience and understanding of IT service management. In the end, we should only care what ITIL says until we have fully grasped it for ourselves and then we should care about how to achieve the best system we can.

Essentially concepts like "standard change" need to be regarded in the first instance as just that - concepts - and not as formulae. All changes require control and must be subject to change management, including ensuring that they are properly announced and recorded consistently, and how that is achieved needs to be clearly defined in policies and procedures all of which must be subject to regular review.

There are practical reasons why many such changes are best handled by a "Change Management Process" and, at least for some organizations, there are practical reasons why some changes are best handled by their own specific process which will lie slightly to the side of the general process but relate to it in order to maintain consistency and integrity of the overall management system.

Big words and phrases perhaps (well they are for me, being only 5'4" :D ), but the essence is that ITIL matters when you are trying to design or improve your management system, but not when you are running it or auditing it (ISO2000 helps you there).
asrilrm wrote:I guess in V3 pre-approved change has morphed into Service Request.
To avoid some possible misconstruction of this statement, I want to make the following two points:

- So called "pre-approved" or "standard" changes are not dependent on a request unless you prefer to generate an artificial request when the stimulus is an event or a date or a time of day or an incident.

- Service requests do not necessarily imply a change requirement (even if you do consider a server reboot to be a change :D ).

Posted: Mon Nov 09, 2009 7:45 am
by asrilrm
Thanks for the detail explanation Diarmid.

At first, we also tried not to strictly bound to definitions and be more flexible.
But then it appeared that there were so many gray areas and (I wondered why) people got creative in abusing definitions to force their change requests.
The not-so-clear distinction between standard and pre-approved change is one critical area, that most people tried to categorize their RFCs into pre-approved in order to speedup the process, or to bypass CAB.

Nevertheless, I agree with you.
Have a nice day, yesterday I just saw the Dancing Superstar Competition on television. One amazing Australian dancer (Reed something..) had lost by just one point from his rival from India and had to leave the arena.
A fantastic show it was

Posted: Mon Nov 09, 2009 9:24 am
by Diarmid
asrilrm wrote:At first, we also tried not to strictly bound to definitions and be more flexible.
But then it appeared that there were so many gray areas and (I wondered why) people got creative in abusing definitions to force their change requests.
The not-so-clear distinction between standard and pre-approved change is one critical area, that most people tried to categorize their RFCs into pre-approved in order to speedup the process, or to bypass CAB.
Asrilrm,

I did not mean that a system should be "flexible" (it should, of course, but in a very different way); rather that the design should treat ITIL as just one input. You do need to be strictly bound by definitions, but they must be your own. Even where you want to use an ITIL term as ITIL has defined it, you should state the definition within your system.

Your procedures and policies should be sufficiently complete and clear that it would be irrelevant and wrong to refer to ITIL (or COBIT or anything else external) in the day to day activities of delivering service.

You should only open these reference books again when you are reviewing your processes/procedures to pursue improvement.

Reference to ITIL as some kind of higher authority than your organization's rules is absolutely wrong and should be totally unacceptable behaviour.

I did not see any interesting television yesterday, but, on a rare visit to Scotland a fortnight back I was able to watch my team live on telly beating one half of the Old Firm.

cheers.