For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
The Itil Community Forum: Forums
ITIL :: View topic - an incident becomes a change...?
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
...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
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
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.
...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. I'd love to see the Service Desk call metrics on those Service Requests. _________________ Ruth Mason
USA
Joined: Oct 07, 2007 Posts: 441 Location: Jakarta, INA
Posted: Mon Nov 09, 2009 9:58 am Post subject:
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.
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Mon Nov 09, 2009 8:46 pm Post subject:
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" ), 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 ). _________________ "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
Joined: Oct 07, 2007 Posts: 441 Location: Jakarta, INA
Posted: Mon Nov 09, 2009 10:45 pm Post subject:
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
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Tue Nov 10, 2009 12:24 am Post subject:
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
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
I'd love to see the Service Desk call metrics on those Service Requests.
), 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).
