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?

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.

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.

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

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

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