changes in a decentralized environment

[AndyW]

Hi,
I'm working for a global company as change manager. Yesterday the question came up how to handle changes which are coming from local applications in other countries.

In the past there were a few concerns regarding change approval for emergency changes coming from local applications. The application owners argue that they don't want to wait for an official change approval by the change manger because of:
- the change manager does not know the details of the application and can not contribute any value to the change
- the impact of the change is only local and can be best assessed by the local change owner
- the change manager lives in a different time zone and waiting for his approval would take too long.

Any best practice approach ITIL would propose for this issue?

[Skinnera]

Hi AndyW,

Don't know if it is ITIL best practice, but in my org RFCs can arise in other territories for applications that are hosted and supported in those territories but used across all territories.

In those circumstances the following happens;

the owning territory raises the RFC and notifies the CM funtions in the other territories.
those CM functions then raise 'info only' RFCs in their own FSCs and notify them out for awraeness.
the RFCs are tagged as 'cannot be challenged', for all the reasons you state above.

This is because we don't have an integrated toolset, having become global by acquisition rather than organic growth.

[asrilrm]

Hi,
The question is are the other territories included in the CMDB?
If they are, then they are all subject to Change Management process, and the RFC should come to you

[m_croon]

[asrilrm]

I could have been mistaken.
We serve an airline that has many domestic branches. Each branch run their own sales and financial applications (because of different accounting reqs). However, to ensure compatibility, the specifications came from Head Quarters, in terms of hardware, systems software, network, and line communication.
Because of this, we include them in our CMDB, so every change in a branch (hardware, etc, but not application) should come to Change Management process.
I don't know if this is a proper practice but we haven't got any problem so far

[m_croon]

Hi asrilrm,

Why see it as a mistake. Whatever works, works. ITIL does not state you should follow either your or my suggested path. If yours works for your organisation, excellent.

My point is that you can (could) make a difference between:
1. determining certain "starting points" (such as architecture, product choice, proces workflow) from a centralised perspective, and at the same time:
2. allowing local parts of your organisation to act locally, yet according to the starting points as determined above.

For this combination to work, you need certain agreements (OLA?) in place re. periodic reports from the local parties involved.

This would be my choice. It means that steering the process is more difficult, yet it gives more flexibility to your organisation and therefor more acceptance of change management.

[asrilrm]

Of course, and you've made a good opinion, thanks!
*adding to his knowledge database*