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: DWhitwort
New Today: 73
New Yesterday: 72
Overall: 143820

People Online:
Visitors: 65
Members: 4
Total: 69 .

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

Change / Release Management

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


Joined: Aug 04, 2006
Posts: 16

PostPosted: Fri Aug 04, 2006 7:05 pm    Post subject: Change / Release Management Reply with quote

Hi

I'm writing a paper for university. It's for a medium sized company (about 1000 employees worldwide). They have their own ERP system and want the process for change management (which basicly only concerns changes that the users want) remodelled introducing a release management, as changes at the moment get implemented, tested and released separatly. This has to be done according to ITIL.

My questions are

- Is it possible only implementing one or two aspects of ITIL (release & change management)
- Does that make any sense Wink ? (my prof. says it could convince the company to organize the whole SW development according to ITIL)
- The development manager hopes to reduce the ammount of daily business
- The guys in the development department aren't really convinced. They can't see any advantage execpt that the can't be loaded with loads of change requests to implement. How can you get them to see the advantage.
- Is there any reference work concerning the introducing of releasemanagement that I could back my work and theories?
Back to top
View user's profile
outager
Newbie
Newbie


Joined: Aug 01, 2006
Posts: 7

PostPosted: Fri Aug 04, 2006 10:32 pm    Post subject: Reply with quote

1. It depends on what you mean by "implementing". If you do not formaly "implement" ITIL there will always be forms of different ITIL processen. You cannot *not* have some sort of ITIL-like working.
2. There are 2 other processen that have a strong relationship to config and release: Incidentmanagement and configurationmanagement.
But I think from "theory" you cannot say "you need to implement all of ITIL in SW dev.". Always start with the question "what's the problem?" Try to keep that in mind always. And only later you can say "We can solve this problem by implementing this proces" (or part of proces).
3. I'm not sure what your question is. What is the "daily business"?
4. The advantage of what? Having releasemanagement?
Again, look for problems to solve. Then think of a solution, and then you will surely have your arguments for advantage.

I will not leave you behind puzzeled Wink I can give you some of the general advantages of releasemanagement:
- By concentrating more changes in one moment, the chance of servicedisruption is concentrated in one moment. (If you do 5 changes on monday, you only have (a higher) chance of errors on monday. If you have 1 change every day, you have the chance every day.)
- Organising a test with users is much easier to do that for several changes at once opposed to organising a test for every change.
- Much more stability in the dev / test / production environment.
If several developpers are working on defferent changes, they need to take different situations (versions) into account.
- Easier (thus better) communication to users when releasing a release to production.
Back to top
View user's profile
Avalanche
Newbie
Newbie


Joined: Aug 04, 2006
Posts: 16

PostPosted: Fri Aug 04, 2006 11:23 pm    Post subject: Reply with quote

Thanks

1. Well my exact task is creating / remodelling the business process for handling change request and that the process is as new to the ITIL Framework as possible.

2. Yes at the moment I think I mainly have to consider change, release and config management.

3. Well daily business is handling bugs etc. which actually does go into incident management. The problem is this company differantiate between bugs and changes. Bugs are fixed immediately and changes are to be released in packages. A change is an improvement to the system that user/s wish, nice to have but not vital.

4. Yes that's what I wanted, if I need more later I'll contact you Wink
Back to top
View user's profile
outager
Newbie
Newbie


Joined: Aug 01, 2006
Posts: 7

PostPosted: Thu Aug 10, 2006 6:46 pm    Post subject: Reply with quote

I think it is important to differentiate incidents from changes. Bugs are not incidents. The system is tested, and accepted inclusive the bugs.

Incidents are disruptions in the system "as developed". I would consider handling bugs in changemanagement. Reason is that there are bugs that should be resolved immidiatly, some do not need to be resolved immidiatly. The assesment of resolving or not should be done by the same person(s) that asses RFC's.

Paul
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Fri Aug 11, 2006 5:05 pm    Post subject: Reply with quote

Hi Avalanche

I think it might be wise to be careful about the words being used here.
Remember that in ITIL a Change is

The authorized addition, modification, or removal of approved, supported or base lined: hardware, network, software, environment, system, desktop build, or associated documentation.

Wordy but precise, so your bugs result in Changes that deserve the term as much as your 'Planned Changes'.

Outager is spot on when he says that Config, Change and Release work closely together. It seems that you want some help setting up these three processes together, or are you looking to implement just Change and Release?

I presume that you are planning a paper system as there is no mention of tools? If so I can help here, as we did this four years ago and are still using it.

Regards

Ed
Back to top
View user's profile
Avalanche
Newbie
Newbie


Joined: Aug 04, 2006
Posts: 16

PostPosted: Fri Aug 18, 2006 12:14 am    Post subject: Reply with quote

Hi guys, thanks for your replies and your patient (as I'm a total newbie)

@outager
I understand your point, but it seems some problems (bugs) that occur have to be fixed immediately (as people can't work otherwise) and I can't see how that can be done if you work with a release management which bundles changes and releases them together.

I get the point that bugs have been accepted, but the user doesn't really care about that if he can't work because of a severe problem. And as this is a pretty large ERP system it is difficult to test the whole system now, and it seems that was neglected when the system was first developed.

@Ed
Yes I see that a bug result in changes that are equally to the "User Requested Change Request". But how do you include such a change into a release, if it has to be solved on the spot?
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Fri Aug 18, 2006 5:07 pm    Post subject: Reply with quote

Hi Avalanche

When a bug fix is imperative i.e. fix me NOW my Service is down - then a Retrospective Change can be allowed.
We classify these as Emergency Changes - I will give verbal authorisation by phone or E-Mail for the Change to go ahead on the proviso that the Implementer:
1) Makes Notes of what was done to facilitate the Change.
2) At least does some rudimentary Testing of the Change and Regression and documents it
3 Completes my paper Documents within a specified period (usually the next day)
4) Obtains the normal Sign-off.

Normally the Implementer or the person requesting the Change will communicate the needs for the Change to the Change Team explaining what they think needs to be done, why etc. and then we would make our requirements plain to them.

I have educated my users (over time) to understand that the process must be completed either before / during / or after a Change, without exception, and now they comply.

I hope this helps

Regards

Ed
Back to top
View user's profile
m_croon
Senior Itiler


Joined: Aug 11, 2006
Posts: 262
Location: Netherlands

PostPosted: Fri Aug 18, 2006 5:52 pm    Post subject: Reply with quote

Hi Avalanche,

Still in the ERP business?? Very Happy

I agree with outager that ITIL being only a means (not a goal), you should only adopt/implement those parts/processes of ITIL that can help you solve a problem. Leave the rest behind. One of the worst mistakes you can make is to implement all processes at the same time, and / or to implement them "just to have ITIL".

It is very realistic to focus on specific processes as compared to all of them at the same time. On the other hand, you will find that when you have "lifted" any process to a more mature level, chances are that you might need to improve another process before you can effectualy make more gains on the first one. Processes that play a particularly central role are config. management and service level management. Maybe CMM can help you out to establish the level of your process quality. Consultancy firms such as my own have standardized scans to help you out.

Regarding ERP, one particular thing comes in mind (I am not sure whether you have anything to do with this, as you are from the devt. dept). I know that SAP (but maybe all ERP systems) have a thing called "transporten". These are very frequent data-transfers, that (from a functional / impact point of view) might very well be regarded as changes. Their number and frequency is so high however, that you do not want to bother your customer, your organisation and your system with discussing these in a CAB. Try and build these in a standard change - procedure, where the aim is to have them all registered as opposed to having them all 100% controlled.
Back to top
View user's profile Visit poster's website
outager
Newbie
Newbie


Joined: Aug 01, 2006
Posts: 7

PostPosted: Fri Aug 18, 2006 10:19 pm    Post subject: Reply with quote

I understand there are bugs that need to be fixed immidiately. Those changes cannot wait to the next release, but should be implemented through a fix.

As Ed explains that the time you need for correction can also be very short in changemanagement. (CM is done by phone / email / in person)

In my opinion key is that you should have person(s) assesing change requests and other(s) for resolving incidents.

By implementin a fix (a change) you always have a risk in more failure, so the person assesing the emergency change should have the authority to decide.
Back to top
View user's profile
Avalanche
Newbie
Newbie


Joined: Aug 04, 2006
Posts: 16

PostPosted: Mon Sep 18, 2006 11:58 pm    Post subject: Reply with quote

@Ed

Do I get you right, say I've got a problem with a sales form that has to be resolved immediately.
- Create a RfC and have it authorrise by the CAB or Change Manager
- Implement the Change and Test it.
- Install the Change on the Live System
- Documentate all the changes done
- Fully Test with the next release package and complete it like a "normal" RfC
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Tue Oct 03, 2006 5:38 pm    Post subject: Reply with quote

Avalanche

First off Apologies for the late reply - I have been on vacation in the Carribean, so missed your post.

Essentially yes.

All changes must follow the same path, however, what I allow (in emergencies) is for the implementer to explain why it is needed now! now! now!, and accept retrospective paperwork, but only after I have given a verbal authorisation.

We take the position that an authorisation, either written or verbal - from me as Change Manager at the least, must be granted before any change is implemented.

As far as the testing is concerned, I want it to be as 'full' as circumstances allow. If possible, tested fully before emergency implementation. Each case is treated on it's merits, and according to the circumstances (obviously).

This area is almost, suck it and see, but I do take advantage of my experiences in the business to assist me (33 years + and counting).

I hope this helps clarify what I was saying

Regards

Ed
Back to top
View user's profile
Globis
Itiler


Joined: Apr 17, 2007
Posts: 36
Location: Cape Town

PostPosted: Fri Apr 27, 2007 5:19 pm    Post subject: Reply with quote

Quote:
..Bugs are not incidents. The system is tested, and accepted inclusive the bugs.

Incidents are disruptions in the system "as developed". ...


Sorry, but I'd strongly disagree with that statement. In ITIL anything that causes an interruption to a service to the user is an incident. So to say that a bug is part of a release and hence the service, and so that any user problem related to the bug is not an incident is very convoluted logic, and nonsensical in the real world. Especially from the user's perspective.

In fact in the real world anything that a user calls in because they have a problem is an incident.

Quote:
I would consider handling bugs in change management. Reason is that there are bugs that should be resolved immidiatly, some do not need to be resolved immidiatly. The assesment of resolving or not should be done by the same person(s) that asses RFC's.


Again I'm not sure that that is entirely the full process. If incidents are reported that indicate a severe bug stopping people working that should then become a problem, and dealt with by problem management. If the outcome of the problem management process is a change to the service, this a change request is raised.

If there are bugs so severe that the service cannot be used, this must of course be resolved urgently, but this also highlights a severe problem with release management, particularly testing. And in this case the service manager raise another problem, namely to investigate why release management failed in its job to release a stable servivce.

Dave
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.