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.
Posted: Wed Sep 05, 2007 11:54 pm Post subject: Standard Change Process
Does anyone have a documented process on how an RFC can become classified as a Standard Change? You always hhear it stated that it should be a repeatable and low risk process, but how do you write a procedure for submitting a change to become a Standard?
We just started to implement the process on how to submit a Standard change.
Basically, what we did is was added a check box to our RFC form for requestors to check if they feel the type of change they are requesting should be reviewed as a standard change.
We, change management get automatic notifcation of this and will review the change at the next CAB meeting to see if all agree. The submitted change still goes through the normal change process though at this point.
Once approved, this RFC, type of change, will be added to our Standard Change List document to formally record all changes that are standard and as well, add this type of change to our tool so they can automatically select it when they do the same type of change again, it will automatically be set to Standard and have most of the information filled out on the RFC, they would just have to put the actual scheduled time of the change and then enter the actual implementation time when the RFC is completed and set the RFC status to implemented.
We will have these automatically closed/completed by a bathc process after 7 days to ensure that no problems were encountered after the change.
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Thu Sep 06, 2007 5:59 pm Post subject:
In order to define Standard changes, you first have to define what is not a standard change or the other types of changes
emergency, immediate, normal and STANDARD
This should be in the change management policy document and spelled out in detail in process and procedure documents
The Change Management team should recommend to mgmt that certain types of work can be standard. They should be low risk and low impact and has been done frequently _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
A change that is defined, contains repeatable procedures and historically has produced zero negative impact to an IT service. The implementation steps will be well documented and versed along with solid testing performed prior to implementation and is typically classified as a minor change. (this is my non-official definition but gets the idea across)
Now far as a process for a standard change. A change will go through the normal rfc process one time to receive initial approval to be implemented. During this lifecycle can have a box with marks to potentially be a standard change(just marking this box does not make it so). As a apart of the PIR a review of those that are requested to become a standard change are evaluated and decided upon to be granted a standard status. For those that are not, they will continue the normal process in the future but will have the feedback on why it will not be a standard change and can improve their own process or documentation for that change to get to a standard status. For those that are granted depending on your tool set will depict how you would implement. However as apart of normal PIR activities a regular review of those standard changes that were implemented should be performed to ensure that no incidents arose from them. Apart this will require the developing of a policy for those Standard changes that do fail or cause an impact a process for re-evaluation of their standard status. _________________ Adam
Practitioner - Release and Control
Blue Badge
"Not every change is an improvement, but every improvement requires a change"
Joined: Feb 28, 2006 Posts: 411 Location: Coventry, England
Posted: Mon Sep 10, 2007 5:06 pm Post subject:
To add to Adam's reply
If the requestor has a rock solid written procedure to perform the task, then I would consider making the Change a Standard Change - we ask for notification of a repeat of Standard Changes in order that we can keep track of what is happening. This is then put on the FSoC and also published to interested parties (via E-Mail). One of my questions to the requestor is 'Can you write a procedure for this Change?' If not, the Change remains a Basic Change.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Tue Sep 11, 2007 12:53 pm Post subject: Re: Standard Change Process
Hi Buddy,
Buddy wrote:
Does anyone have a documented process on how an RFC can become classified as a Standard Change? You always hhear it stated that it should be a repeatable and low risk process, but how do you write a procedure for submitting a change to become a Standard?
In the enterprises we deal with, the categorizations are as follows:
Standard Change: Must follow formal and planned Release schedules including rigorous testing, along with a holding period in a staging environment. Such Changes usually have a structured period of time before they can move into the next environment. For example, some firms release to production every Thursday night and require that all Standard Changes are fully tested and put into a staging environment, at least one week before deployment. "Standard" Changes are planned for, well in advance.
Expedited Change: Important enough that it must be rushed into the "next" Release schedule/day.
Emergency Change: Important enough that it must be deployed sometime that same day, regardless of when the next Release day may be. This is purely a reactive scenario, because of how critical such a Change may be to a business.
In addition to these categories, there is the concept of a Pre-Approved Change, which is a change that requires no review by the CAB. What no one will tell you is that this is just a form of a pre-approved Service-Request that can be executed by appropriate personnel, without any review or approval by the CAB. Most enterprises are loaded with such Changes.
Anyhow, I hope this helps.
My Best,
Frank Guerino, CEO
TraverseIT
On-Demand ITIL Platform
Posted: Thu Nov 29, 2007 1:02 am Post subject: Re: Standard Change Process
Hi
I am Confused between Standard and Pre-Approved Changes - I thought they are one and the same ?
Thanks in Advance
Tintin
Guerino1 wrote:
Hi Buddy,
Buddy wrote:
Does anyone have a documented process on how an RFC can become classified as a Standard Change? You always hhear it stated that it should be a repeatable and low risk process, but how do you write a procedure for submitting a change to become a Standard?
In the enterprises we deal with, the categorizations are as follows:
Standard Change: Must follow formal and planned Release schedules including rigorous testing, along with a holding period in a staging environment. Such Changes usually have a structured period of time before they can move into the next environment. For example, some firms release to production every Thursday night and require that all Standard Changes are fully tested and put into a staging environment, at least one week before deployment. "Standard" Changes are planned for, well in advance.
Expedited Change: Important enough that it must be rushed into the "next" Release schedule/day.
Emergency Change: Important enough that it must be deployed sometime that same day, regardless of when the next Release day may be. This is purely a reactive scenario, because of how critical such a Change may be to a business.
In addition to these categories, there is the concept of a Pre-Approved Change, which is a change that requires no review by the CAB. What no one will tell you is that this is just a form of a pre-approved Service-Request that can be executed by appropriate personnel, without any review or approval by the CAB. Most enterprises are loaded with such Changes.
Anyhow, I hope this helps.
My Best,
Frank Guerino, CEO
TraverseIT
On-Demand ITIL Platform
I am Confused between Standard and Pre-Approved Changes - I thought they are one and the same ?
Thanks in Advance
Tintin
In my view yes they are the same. in experiences organizations have called it one or the other but was one in the same. _________________ Adam
Practitioner - Release and Control
Blue Badge
"Not every change is an improvement, but every improvement requires a change"
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Thu Nov 29, 2007 8:09 am Post subject:
They are the same however, Change Management shoudl always review the pre approved changes to make sure that all the known stuff is still relevent _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Standard changes are usually pre-approved, well known, low impact and low risk changes. They are the kind of changes that as a Change Mgr you let happen as long as they are recorded.
Then there are Change Models. A Model is a change for which there is a very clear and approved procedure. The change is not necessarily pre-approved, but the procedure is known and approved. The purchase of approved equipment, for instance, is often modeled that way. "Here is a procedure to purchase a new laptop..." sort of thing. Each purchase needs to be approved, but it follows a well-defined process that is not your generic Significant, CAB-driven, Change.
A Change Model is an ITIL concept that is often overlooked or mistaken for a standard change. _________________ BR,
Fabien Papleux
Accenture
Technology Consulting | Service Excellence
Red Badge Certified
Joined: Feb 28, 2006 Posts: 411 Location: Coventry, England
Posted: Thu Nov 29, 2007 6:05 pm Post subject:
Sorry Fabien
I cannot agree that purchase of hardware should come anywhere near my Change process - My thought process is as follows
I am protecting the 'Production' or 'Live' environment!
Until such time as a laptop is configured, set-up and given an IP Address/ set up for DHCP it cannot connect to a VPN or Wan that constitutes part of my 'protected' environment.
Therefore, I don't care if Purchasing go out and buy 1,000 machines. When they are out of their boxes and ready to be configured - then I want to know - by Standard Change Release notification.
PS Change Models encompass all the Change types from Bl**dy Ginormous (Major) to tichy(Minor) The model is what has been agreed with the business for that classification. (I couldn't remember this being taught in my Practitioner Course so I went back to the Blue Book Section 8.3 to confirm)
I woukd recommend keeping the status to a minimun - don't have any just for the sake of it. The more admin your support teams have to do withthe CR's the more of their time is taken up.
Build a workflow to suit your needs. I would recommend an approved status or at the very least and approved flag that can be filtered on.
In some cases you may not need an "assigned" status. If the support tool has the option to assign to users this can be taken as the CR is assigned - but ensure there is a workflow for accepting assignments or returning them -- ownership of the CR moves to the current "assignee" _________________ Mark O'Loughlin
ITSM / ITIL Consultant
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
