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 ? (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?

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

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.

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.

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.

@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?

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

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

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

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