an incident becomes a change...?

An open discussion on issues related directly or primarily to the service or help desk.
Post Reply
User avatar
informize
Newbie
Newbie
Posts: 1
Joined: Wed Oct 21, 2009 8:00 pm

Thu Oct 22, 2009 8:26 am

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


User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Thu Oct 22, 2009 9:24 am

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
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
nisarg
Itiler
Itiler
Posts: 11
Joined: Sat Jan 24, 2009 7:00 pm

Tue Oct 27, 2009 7:18 am

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
User avatar
rpmason
ITIL Expert
ITIL Expert
Posts: 105
Joined: Thu May 24, 2007 8:00 pm
Location: USA

Tue Oct 27, 2009 10:10 am

...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.
Ruth Mason
USA
User avatar
rpmason
ITIL Expert
ITIL Expert
Posts: 105
Joined: Thu May 24, 2007 8:00 pm
Location: USA

Tue Oct 27, 2009 10:57 am

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?
Ruth Mason
USA
User avatar
viv121
ITIL Expert
ITIL Expert
Posts: 117
Joined: Fri Dec 14, 2007 7:00 pm

Wed Oct 28, 2009 8:07 am

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.
User avatar
rpmason
ITIL Expert
ITIL Expert
Posts: 105
Joined: Thu May 24, 2007 8:00 pm
Location: USA

Wed Oct 28, 2009 10:00 am

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.
Ruth Mason
USA
User avatar
nisarg
Itiler
Itiler
Posts: 11
Joined: Sat Jan 24, 2009 7:00 pm

Sun Nov 08, 2009 5:56 am

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
User avatar
asrilrm
ITIL Expert
ITIL Expert
Posts: 441
Joined: Sat Oct 06, 2007 8:00 pm
Location: Jakarta, INA

Sun Nov 08, 2009 6:58 pm

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
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Mon Nov 09, 2009 5:46 am

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 ).
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
User avatar
asrilrm
ITIL Expert
ITIL Expert
Posts: 441
Joined: Sat Oct 06, 2007 8:00 pm
Location: Jakarta, INA

Mon Nov 09, 2009 7:45 am

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
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Mon Nov 09, 2009 9:24 am

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.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Post Reply