I'm about to build the workflow for all Global Infrastructure Change.
We are currently using a process which was initially designed on an IT development model.
Lots of steps are not relevant for the Infrastructure process.
I made one proposition which looks like it: Change Request---> Initial Approval (Only for large change, done by IT Managers)--->Technical Analysis---> Analysis review (done by IT managers)--->Production Readyness Check---> Change Control (Change manager)--->Implementation---> review and close.
I tried to make it very simple, however my colleagues from the US would like to add few steps:
1) a Security manager approval
2) a final approval
The test results may not be satisfactory.
The final implementation date may be in conflict with other changes that were not foreseen when initially approve the current change
In every methodology and Auditing process this final “go-no-go” step is a must. The risk involved in skipping this step may defeat the main purpose of the Change Management process.
To avoid bottleneck that can stop Production, we suggest the following rule for this Final Approval: Approvers have 2 business days time to Approve. After that time, the change is automatically approved.

So my questions are:
Do I need the approval of the Security Manager for Infrasructure changes?
Should i add a final approval?
Is the Change Control step shouldn't be this final approval?
Could you give me your opinion on Infrastructure change process and give me some example?
I'm looking forward to hear your comments and suggestions based on your experience.
King regards.

Infrastructure changes are all the change regarding servers (new, decomissioning, upgrade..), patching, network...
Those changes are submitted (or part of the IT strategy), by an engineer, who will do the analysis, testing and implementation.
For the IT development process, several teams are involved (developer, Business analyst, QA, release management team).
For Infrastructure, some stages were not relevant, no QA in this process, testing is carried by the engineer, sometimes the testing is not even possible (No testing environment applicable)
So basically i'm trying to simplify and shorten the workflow, so the engineers start to keep their changes up to date and are not stopped by some stage that they will not use.
And i'd like to have an initial approval (IT manager) and the Change Control (CAB) which will be the final approval, before implementation.
Regarding the categorisation, that's still remain the same as for any other type of change.
Basically, i'd like to know if you have a different process for the Infrastructure changes or if you use only one?

If the dev world creates something which has to go into the operational world.... treat it as Release Management and run it through change management...

follow the change process and then test the build before releasing it in to the live.

The objective is change management is control and management of changes on the live environment so that the work being done does not screw up the services provided or impact the users at least to the point that the users and services are informed /aware that there will be impacts to the services they use

There should be some sort of approval process for all changes. Even the lowest form of changes - standard ITIL Changes - have approval, they are just pre-approved based on the work being done

The other thing is to make sure that what is being done is a change according to your definitions of changes etc.

As to the security group / manager getting a say in the change request, what is his / her / their role in the IT organization and why should he get to sign off on all changes.

If there is sensitive data or security issues about doing work - remote sites, closed system, classified work etc - there need to be a document from the security manager defining what and why the sec mgr wants to put his finger in the change pie.

As to the additional person approving the change... why... Either the role being done by the Change Manager is at a level where the role is Change manager vice change clerk or admin person and therefore has the backing and cojones to do the role and the company has given the gravitas to the individual

or the company does not see the change manager in the correct light

I am a Change Manager. When I do a role as the Change Manager, if I dont have the authority in writing and in process.. that I am the final arbiter on Operational changes in the Operational world; then the Change mgmt process is not strong enough to resist interference from interested parties - project managers and senior mgrs who are pushing projects w/o regard to the effect on IT. I dont accept that role or job.

I think one of the regular posted did a good defintion of change manager. The only addenda I would say is that the Change Mgr needs to always be objective like doctors in Triage_________________John Hardesty
ITSM Manager's Certificate (Red Badge)