Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: DPalmerst
New Today: 18
New Yesterday: 72
Overall: 143765

People Online:
Visitors: 70
Members: 2
Total: 72 .

Languages
Select Interface Language:


Major ITIL Portals
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

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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 - Standard Changes - How to submit
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Standard Changes - How to submit

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
dsemeniuk
Itiler


Joined: Feb 06, 2007
Posts: 41

PostPosted: Wed Feb 07, 2007 6:04 am    Post subject: Standard Changes - How to submit Reply with quote

How do people log and submit Standard changes?

As in, we still want people to submit RFCs but they would classified as "Standard" and already have a status of approved.

We want to automate this process in our tool so that you can select the type of "Standard" change you are doing and fill out most of the known information for the requestor and just have them fill in the maybe the time they are doing it?

Anyone else take this approach or how do you handle submitting and tracking Standard changes?
Back to top
View user's profile
ARoll
Senior Itiler


Joined: Apr 10, 2006
Posts: 86
Location: Boise Idaho

PostPosted: Thu Feb 08, 2007 3:28 am    Post subject: Reply with quote

dsemeniuk,

I can let you know how we've done this with our toolset and i suppose there really won't be a right answer i could give that isn't dependent how you have that setup.

I may jump this around a bit but hopefully it will be followable. Our Change Owners(CO) go through the normal RFC process, and in our form we have a check box in which they can check if they believe the change should be considered for a standard change. This is a trigger for us when generating Cab agenda's to pull this in as a stndard change consideration. If at the cab we determine that yes this will be a standard change we do the following in our toolset. We create what's called, by our organization, a Standard Group Change. (In our toolset we cannot relate an RFC to an RFC so these group changes are how we relate an RFC, like a hierarchy). We have UI/Role rules setup that only members of change management can create this Standard group change. Once this is create the CO has the ability to make a copy of the original change, update necessary fields and select a pre-approved status. by UI rules we have in place it has to be related to this Standard Group Change. Then we review it post implementation to ensure that the approved standard was followed etc.

Hope this makes sense. Some other options that i have seen/heard of is having an web api into your tool set for these standard changes in which the CO basically fills in the blank. But again this tends to depend on your org/tool and how you implement standard changes.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3307
Location: London, UK

PostPosted: Thu Feb 08, 2007 5:50 am    Post subject: Reply with quote

If you are talking about Standard (ITIL defined) chanegs, this is how we are going about

We define what the criteria are for each type

Emergency
Urgent
Normal
Standard

We define the Normal process as the primary process through a policy document

We have an shorter process which auto-dealing with certain aspects for Emergency, Urgent and Standard.

Each type of Standard changes need to be explicitly defined so that the definition is quite clear.

For example All the details risk impact, imp plan test plan, backout plan, are the same except for the specific work for the change
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
skeptic
Newbie
Newbie


Joined: Feb 20, 2007
Posts: 14

PostPosted: Tue Feb 20, 2007 7:15 pm    Post subject: Reply with quote

Dear me ARoll, seesm to me you are defeating the purpose of standard change, which is to get out of the way of the business and let things happen. Once a category of change has been judged to be sufficiently low risk to be Standard changes, people should be able to just request one and it happens.

having an approval or pre-review process adds bureacracy that is not in the spirit of a standard change. To be precise, having approval by the Change management process is not cool. other stakeholders may well want to review a standard change, for example if someone requests access to a new service then security and/or the service owner may want to approve that change first. but Change Management should butt out - that is the whole point of standard change.

For this to happen, you need a few things:
- standard changes must have templates that rigorously pre-define the implementation process, the test plan, the backout plan etc...
- there must be audits of standard change to ensure the mechanism is not being abused to smuggle through non-standard change, and there must be cruel and unusual punishment for those caught. Fire the first one, I say.
- have a report so you can track usage of standard changes
- some standard changes may trigger a PIR, especially if they are big. Remember standard changes don't have to be small, just low risk. The two do tend to correlate but not always.
_________________
The IT Skeptic
see you at itskeptic.org
Back to top
View user's profile Visit poster's website
goitilcouk
Newbie
Newbie


Joined: Feb 24, 2007
Posts: 19

PostPosted: Sat Feb 24, 2007 7:26 pm    Post subject: Reply with quote

All,

for what its worth, here is my take on it (or certainly how we have approached standard changes....)

Our motive following a complete review of our change process was to get the average lead time for a change to 8 days. This allows the process to be followed to meet our senior manager objectives of showing an increase in core service uptime. One of the biggest issues we found that was driving outages was short lead time changes not being discussed and evaluated enought.

So to get the buy in, we allowed "pre approved" standard changes to have a 3 day lead time.

All standard changes are documented around the technical steps, impact, testing, backout etc but we noticed that most standard changes have a variable element (eg restores may have a file directory that changes each time, SAP transfers may have a variable account code etc). The variable aspect of the change is clearly defined in the RFC (ie an RFC is raised with an agreed set of fast track approvers, the standard change form is attached into the RFC and the only "type" information is the variable elements).

It seems to work and clearly demonstrates that ITIL is a framework that should not be taken as "the only way to do it" but offers guidance and best practice to mould to each individual organisations aims

Rob
_________________
Pondering the question:
Why dont small companies get it ??
Back to top
View user's profile Send e-mail Visit poster's website
skeptic
Newbie
Newbie


Joined: Feb 20, 2007
Posts: 14

PostPosted: Sun Feb 25, 2007 6:37 am    Post subject: Reply with quote

if a change has been classified as low risk (highly controlled, highly defined, well understood) and designated as "standard" as a result, why should it wait at all? Standard-change notification should be after the fact as a FYI for change and config managers and reporting.

that's the whole point of standard change, I think.
_________________
The IT Skeptic
see you at itskeptic.org
Back to top
View user's profile Visit poster's website
goitilcouk
Newbie
Newbie


Joined: Feb 24, 2007
Posts: 19

PostPosted: Mon Feb 26, 2007 4:54 am    Post subject: Reply with quote

skeptic wrote:
Standard-change notification should be after the fact as a FYI for change and config managers and reporting.

that's the whole point of standard change, I think.


what you are talking about is tiping into the realms of a "retrospective chage". The problem when you get into that type of culture is firstly they dont assist the problem manager if an outage is caused by a standard change going wrong (normaly the change management db being one of the first points of reference) but secondly the culture ends up propogating other changes as the people raising the changes feel it is acceptable to rasie the change after the event ?
Back to top
View user's profile Send e-mail Visit poster's website
Ivy
Newbie
Newbie


Joined: Mar 06, 2007
Posts: 2
Location: Boise, ID

PostPosted: Wed Mar 07, 2007 8:57 am    Post subject: Reply with quote

We too log and submit standard changes, although we call them MAC's (Move, Add, Change)
We define it to our users as a routine activity involving low risk and impact to production services and is performed on a recurring basis. To utilize the MAC, the process to perform the activity must be certified through the normal change process for a Major Change Order. Once certified, a MAC can be performed according the approved process and with the appropriate change record without additional approvals for the individual change orders.

The process flow we use is:
IT Member evaluates if the process routine, benign occurs on a regular basis.
If so, they submit a major change order to the CAB requesting certification.
The certification must include:
 Documented implementation procedures
 A verified test plan from past implementations
 A verified backout plan from past implementations
The CAB confirms risk, process, test plan, backout plan and frequency of occurrence.
The above step is a 1 time deal (unless the process changes... then it needs to be updated via the same process)

After the one time certification...

IT Member Enters a MAC change order.
IT Member Implements MAC change order.
IT Member Sets the change order status to “closed”.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops © 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest © 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.