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: JVVR
New Today: 3
New Yesterday: 60
Overall: 139329

People Online:
Visitors: 61
Members: 3
Total: 64 .

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 Change - V2 vs V3
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Standard Change - V2 vs V3

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


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

PostPosted: Sat Apr 19, 2008 12:38 am    Post subject: Standard Change - V2 vs V3 Reply with quote

Question has come up at my current organization around the implementation of standard change process. In looking at the V2 definition is rather clear least to me that would have a standard change filed. Now the V3 definition states it doesn't require an rfc and can be filed by some other means such as a service request. Now to me this is rather contradictory and i'm having a hard time wrapping my noodle around it as i can see this causing a snowball effect of confusion. What are others thoughts or how is this being handled within your organization?

Thanks

Adam

Definition was relayed: A pre-approved change that is low risk, relatively common and follows a procedure or work instruction. For example, password reset or provision of standard equipment to a new employee. RFCs are not required to implement a Standard Change, and they are logged and tracked using a different mechanism, such as a Service Request
_________________
Adam
Practitioner - Release and Control
Blue Badge

"Not every change is an improvement, but every improvement requires a change"
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Sat Apr 19, 2008 11:13 pm    Post subject: Reply with quote

Hi,

I don't have a deep knowledge about V3 but my opinion to your concern is:

1. Remember, ITIL is descriptive, not prescriptive (oh boy, not this again .. sigh). So that means if you don't feel comfortable with service fulfillment process, then you can leave it and stay with your current things.

2. Do you have pre-approved change types, or any changes that fits the pre-approved criteria but not set yet?
If you otherwise want to adopt request fulfillment, then you can remove the pre-approved change types from your change management process and place them under request fulfillment. I don't see any danger of doing so, because basically pre-approved changes are the same as service requests in terms of administrative work

Well, I guess that's my 2 Rupiah (sorry, we don't have any cents ugh)
Don't worry, there will be more to come

Cheers,
Asril
Back to top
View user's profile
ARoll
Senior Itiler


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

PostPosted: Wed Apr 23, 2008 12:26 am    Post subject: Reply with quote

Asril,

Agreed that's why i wanted to put the feelers out there on how others are approaching this. think i need to delve a bit into the request fulfillment material and that may help clarify some of my confusions. I think my hang up would be the lack of the change showing on the FSC. What i fear a fuzzy grey area going into is an approach being adopted of well some standard changes will be logged as a SR and others as an RFC. Can likely see this being a hot debate point. This angle of looking at it make sense?
_________________
Adam
Practitioner - Release and Control
Blue Badge

"Not every change is an improvement, but every improvement requires a change"
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Wed Apr 23, 2008 12:05 pm    Post subject: Reply with quote

Adam,

As long as you have firm criterias for each pre-approved (to become service request) and other standard changes you will be safe.

I can't deny that new requests will come in the future that needs to be determined to which they would fall into, there might be hot debate but you will arrive at a firm definition.

Don't worry about debates as they will enhance your company's maturity

Cheers,
Asril
Back to top
View user's profile
mredekar
Itiler


Joined: Dec 30, 2005
Posts: 21
Location: Navi Mumbai, Maharashtra, India

PostPosted: Thu Apr 24, 2008 6:18 pm    Post subject: Reply with quote

Hi Adam and Asril,

I agree with what you are discussing. I am just trying to add a little which can help resolve the dilemma between V2 or V3.

Every new type of standard change can be treated in Change Management process till the execution of the change matures. For example consider a newly setup multi-server e-mail service of an organization. Moving mail box from one server to other server (due to transfer of employee) can be treated as a standard change initially. Over a period (say N weeks) when the process of execution of this change will mature, teams will have most of the possible of obstacles identified and addressed. Now this particular standard change can be shifted to Service request process. Only added effort is the communication to the users about this shifting (change).

Based on the complexity of the standard change the criteria of maturity can be defined.

Request your comments.

Regards,
_________________
Senior Consultant - ITSM
Certified ITIL V3 Expert
Back to top
View user's profile
erfo02
Itiler


Joined: Mar 11, 2008
Posts: 21

PostPosted: Thu Apr 24, 2008 6:48 pm    Post subject: Reply with quote

For me Change Management is about control, documentation, risk management and audit. I would say that by clearly defining your standard changes and how they should be documented (incoming request and documented in your Service desk tool) you are fully comfortable with that. In my opinion the requirements on the Service Request will actually turn it into a RFC even though you are not using the approved standard template for RFC.
Back to top
View user's profile
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Fri Apr 25, 2008 2:28 pm    Post subject: Reply with quote

Hi Manoj,

My keyword is: consistency.
Think of the Change Management (as well as the others) in its life cycle: short, medium and long term.
I mean for anything you define (categories, types, procedures, policies), be consistent. The Change Management stuff will be used throughout the company, as well as it will be audited against.

Honestly I don't like giving opinions on how one would manage his/her things f.e when does a standard change become a service request because even in the simplest case like server reboot, there are different views along with valid reasons.
The example you gave contains words with relative meanings.
f.e. maturity, how do we define the level of maturity to shift a standard change to service request?
The "moving mailbox" activity is like an ongoing activity, while I think it's time based.
The most critical, are you sure that communication to the user is the only thing to do about the shifting? Think again

I hope this could give a clear picture from my side.

Cheers,
Asril
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.