Change Management 3 rd party vendors

Size: px

Start display at page:

Download "Change Management 3 rd party vendors"

Joel Goodman
8 years ago
Views:

1 Change Management 3 rd party vendors 3 rd party vendors working with Wolseley or DT group must conform to the Wolseleys Change process. Wolseley will have Change control on all modification not defined as Business as usual (BAU). BAU activities are activities that don t have an operational impact on Wolseley systems. The BAU activities needs to be agreed by Change Management in Wolseley and the 3 rd party vendor when these have been agreed Changes follows the setup described below. Types of Changes: Preapproved Change Standard Change Standard Change with CAB Emergency Change Preapproved Change WNO CAB approves a preapproved template supplied by the 3 rd party vendor. Whenever the template is used it should generate an directly into the Change manager inbox so TCA will be aware of the Change, if anything untoward is discovered. Transition office has access to the Change manager mailbox on address: change.manager@wolseley.dk. Standard Change A standard Change should be done by filling out the MIR for 3 rd party vendors located at Transition\15 Change Management\Change 3 rd party Vendors, and forwarding it to the relevant persons in Application Maintenance who will enter it into SM9, after which the Change follow standard change procedures in Wolseley Nordic. It s the responsibility of the Application Maintenance team to inform 3 rd party vendor on the status of the change and whether or not it s ready for implementation. Standard Change with CAB Standard Change with CAB follows the guide lines for Standard Change however the time is somewhat more critical here. Going forward the WNO CAB meetings will be held every Wednesday at GMT +1. It s suggested that Changes to be discussed on WNO CAB meetings are entered into SM9 no later than Friday the week before. As with standard Changes it s the responsibility of the Application Maintenance team to inform 3rd party vendor on the status of the change and whether or not it s ready for implementation. Emergency Change Emergency Changes are done the same way as in TCA. IE. The Change is implemented and the Change record is filled out and approved immediately afterwards. As with standard changes the responsibility to enter the Change into SM9 resides with the Application Maintenance team. When an Emergency change is entered please inform Transition office directly by phone if at all possible as well. The Service desk should be advised as well on mail_wos_servicedesk@wolseley.dk. Page 1 of 5

The BAU activities needs to be agreed by Change Management in Wolseley and the 3 rd party vendor when these have been agreed Changes follows the setup described below.

2 To carry out a change which will affect the use of Information Technology services consumed by Wolseley and DT Group, the following information is needed for change records and further approvals. In cases where additional information is relevant, ad hoc coordination is required from all parties. Page 2 of 5

needed for change records and further approvals.

3 Change - Minimum Information Requirements (MIR) for 3 rd party vendors Title: The title is used in summary views, for reporting and to aid in the assessing the nature of the change Title: Description: Describe the purpose of the change in common language that non-technical persons can understand Enter a more detailed explanation of the change requirement, including: Purpose, objective and justification for the change Desired outcomes Any additional supporting information not captured in another field Implementation and back-out plans, risk and impact assessment and testing details are specifically covered in separate fields and need not be referenced here. Description: Assignment Group: This is the group at TCA that is responsible for implementing the change request. If you know the person s name, but do not know the workgroup, enter the person s name. Assignment Group: Planned Start / Planned End: Enter the Planned Start and Planned End date, taking care to enter the correct start and finish time. Planned Start / Planned End: Downtime: State how many minutes the service will be unavailable during the implementation of the change. If no downtime is required put in 0 Downtime: Reason for Urgency: Any change submitted with less than 5 days notice will automatically be defined as urgent. The Reason for Urgency field will be required. Enter a clear explanation justifying the reason for the urgency of making the change. Urgent changes must be implemented based upon justified business necessity and not for the sake of convenience or poor planning. Reason for Urgency: Implementation Plan: Include sufficient implementation plan details to allow technically and non-technically oriented approvers and reviewers to make informed judgments on whether to authorize the work. This may be entered directly into the field or attached to the change as a separate document and noted in the implementation plan. Generally, it is not necessary to provide full technical details for approval but detailed plans may be noted and attached within the change for reference and convenience. Implementation Plan: Page 3 of 5

and justification for the change Desired outcomes Any additional supporting information not captured in another field Implementation and back-out plans, risk and impact assessment and testing details

4 Communication Plan: Consideration should be given to the following: Is any communication required? If it is required, what communication has been prepared or carried out? If you have not made any plans, what will be done to ensure that communication is carried out? For changes where business-affecting downtime is expected, communication should be arranged though the locally agreed route (eg Datahot for DT Group) Communication Plan: Back-out Plan: Clearly outline the approach to backing out the change in case of full or partial change failure. If it is genuinely not possible to back the change out, clear justification must be included with details of how any resulting service impacts will be resolved. Some evidence of testing and/or proof of the effectiveness of the proposed approach is valuable, including reference to pre-implementation back-ups and checks. This plan should also define: Who makes the call to back-out What are the tests to prove the back-out has been successful Is there any comms required post the back-out that needs to go out. Back-out Plan: No. Of Systems Affected: Select 1 or >=2 No. Of Systems Affected: Backout Strategy Tested?: Backout Strategy Tested?: Failed Change will extend agreed Change window?: Failed Change will extend agreed Change window?: Change failure could cause system degradation or downtime?: Change failure could cause system degradation or downtime?: Components affected: List the servers or software components that it in-scope for this change. Components affected: Page 4 of 5

For changes where business-affecting downtime is expected, communication should be arranged though the locally agreed route (eg Datahot for DT Group) Communication Plan: Back-out Plan: Clearly

5 When the form is filled please send it to your contact person in TCA who will enter the information into the Wolseley service management system to get the change approved for implementation. Allow the approval process min 3 days to get the change approved. Detailed implementation plans or technical drawings can be send to further document the change but can be send without the filled out form. Once formal approval is obtained, the change can be implemented. Regards Change Management (Nordic) Group IT Wolseley Group IT Tech Center Aarhus Daugbjergvej 15A 8000 Aarhus C Denmark Page 5 of 5

Detailed implementation plans or technical drawings can be send to further document the change but can be send without the filled out form.

Change Submitter: The person or business requesting or filing the Request For Change (RFC) notice.

ROLES, RESPONSIBILITIES, PROCEDUREs Change Submitter: The person or business requesting or filing the Request For Change (RFC) notice. IT Operations Change Manager: The steward of the Change Management