Page 1 of 1

Responsibility for Raising Changes

Posted: Tue Nov 01, 2011 12:06 pm
by markhayes
Interesting one this, surprised I havent come across it before.

We have a supplier who requires work from in-house support teams... ( Rebooting servers, reconfiguring servers and DBs etc.) Who would be responisble for raising those changes - would it be

1. The support teams who know what the work involves and can put those details into the change.
2. The suppliers should raise the change as they want the work doing and they should speak to the suppliers to get data from them to put into the change record.

Posted: Tue Nov 01, 2011 12:38 pm
by Diarmid
This does not feel like a new question, but I cannot find any previous threads with a quick skim.

One way of looking at this is to consider that when the change has been fully applied, it is ultimately the requestor who has been satisfied and the primary concern of the requestor is outcome rather than specification.

Where the detailed specification of the change comes from is a separate matter. You would not expect a customer driven change to come all nicely tied up with CIs identified. Would you? Perhaps most of the information is required by the time the request reaches CAB, but not for the request to be made in the first place.

If there is information required that your supplier is not party to, then you simply build a process that will collect and assimilate that information on the way to CAB.

If your support teams request changes in areas of your suppliers responsibility, you need evidence that the request came from the supplier and was not off their own bat. Or to put it another way the supplier must have made the original request.

Posted: Tue Nov 01, 2011 6:02 pm
In our organization internal IT support staff work in conjunction with external IT suppliers.The internal IT staff generate RFC's on behalf of the external suppliers as they do not have access to the change management system. The external supplier is given a blank RFC form to complete which is a mirror image of the RFC template on the change management system.
The RFC template is then emailed to the internal IT support staff for them to "cut and paste" the information directlly into the change management system.
Dedicated internal IT support teams are assigned to specific external suppliers to ensure that all proposed change requests are managed effectively.

Posted: Wed Nov 02, 2011 4:14 am
by Diarmid
So really your external suppliers raise the RFC but your staff key it into the system. Is this fact recorded in the system?

Posted: Wed Nov 02, 2011 5:27 am
Diarmid wrote:So really your external suppliers raise the RFC but your staff key it into the system. Is this fact recorded in the system?
Yes of course.
“Example Wording”
This RFC has been generated on behalf of company XYZ
The external supplier is invited to attend the Cab in order answer any questions relating to the proposed change, however the internal IT support staff would normally represent the supplier as they are fully aware of all aspects of the change.
The entire operation runs as though both internal IT and external IT organisation are one. The external IT supplier is fully aware of the change management process and what is expected of them.

Posted: Wed Nov 02, 2011 3:00 pm
by Sunny60in

I believe, By 'raising the change' you mean feeding it into the system

If your process says that implementer team should raise the change, then, it shouldn't change if requester changes i.e. it should be transparent if requester is customer, another support team or a vendor.

We expect answers to few basic questions from change requester and a template is published in our change management process document. Different groups take different ways to provide this information.

Customer / vendors: Mostly they use the template --> SD create the change record, attach the template, assigns it to the implementer team.
Sometimes customer just sends an email. As far as email has the answers to the required questions, we accept that.

Another support team --> Uses template OR as they have access to the system, create the change ticket, provide the answers to the questions and assign it to the implementer team --> Team take it from there & complete the change record.