最新糖心Vlog

Change management is a controlled process for introducing changes into the IT production environment in order to minimise disruption. When the approved change management process is used, many benefits are realised:

• Changes occur at times both convenient and appropriate to the 最新糖心Vlog
• Affected users receive appropriate and timely communication
• There are no conflicts with changes being made by other TS teams
• If a change does not go according to plan, the reasons for the problem are investigated and actions are taken to prevent the issue occurring in the future.

The Change Manager:

• Chairs the weekly ITDS Change Advisory Board meeting
• Reviews RFCs for completeness and accuracy prior to passing to the CAB
• Provides/updates/creates documentation and advice on the change process
• Prevents potential conflict by maintaining the Forward Schedule of Change
• Is an escalation point for problems with changes
• Controls the processes for both normal and emergency changes

The CAB is comprised of representative(s) from each Information Technology and Digital Services team and includes the Service Delivery team as the convenor. The CAB meets once听a week (Wednesday) to review and assess any requests for change prior to implementation.

The CAB is responsible for the co-ordination of all changes to IT production systems including:

• Reviewing and authorising/rejecting RFCs not already approved at the CAB level
• Generating action items for ITDS staff
• Discussing procedures and improvements to the change process
• Approving procedures to allow a change to be standard (pre-approved)

RFCs must be submitted and set as "approval" status before 2pm on each Monday for review on Wednesday.

Follow the Emergency Change Procedure and notify the Change Manager to request an Emergency CAB (ECAB).

If a Priority 1 or Major Incident is declared by the Service Desk, Emergency Changes can be actioned immediately and logged retrospectively once the Major Incident is resolved.

Any change made to a production IT system that is managed by ITDS will require a Request for Change (RFC). An RFC is logged via the .

Other changes, while not changes to the way our production systems work, require TS approval. These buildings may have communications or server infrastructure in them.

• All text boxes must be completed with appropriate information
• A good title: a short (A clear brief description of the changeA reason why the change must happen
• A proposed time for implementation
• Any risks that you foresee during implementation (and any mitigations you have made to reduce those risks)
• Identify what Configuration Item(s) will be changed and ensure they are linked to the RFC correctly
• Record what service(s) are affected by this change
• What happens if this change is not implemented
• A back-out plan and resources required (if applicable)
• Communication text (aimed at appropriate audience)
• Correct team, urgency, impact and type of change selected

Most importantly, ensure that you have submitted your RFC and a technical CAB representative has assessed/progressed the request to the approval status prior to the CAB deadline.

Unless otherwise arranged, the requestor logging an RFC assumes responsibility for co-ordinating an RFC. This co-ordination includes the following tasks:

• Asking other teams for any required staff (with sufficient notice)
• Preparing any communications to be sent by the Service Desk
• Making sure communication gets sent with appropriate notice (ten business days for changes happening outside of maintenance windows, two business days for changing happening during maintenance windows).

The CAB will create Action Item(s) for each issue it has with your RFC in the Notes section of the record and will advise the requestor via email or in person.

Before a change can proceed, the action items must be completed or addressed to the satisfaction of either the AI requester or the TS CAB. Action Item updates should be added to the notes section of the RFC for tracking purposes.

A manager or the ITDS CAB can request a formal PIR (Post Implementation Review). This is a process run by the Change Manager and involves calling a meeting with;

• The implementer(s)
• Any CAB representatives who would like to have input
• Any necessary technical expert(s)
• Any representatives from a customer group that may have been adversely affected

The aim of the process is to:

• Identify the cause of failure
• Identify any processes/procedures that can be improved to stop this from occurring again
• Create Action Items (AI) against Team Leaders/Managers to reduce the likelihood of this occurring in the future

The Change Manager will provide a copy of the PIR report to all attendees of the meeting to gain feedback and/or comments. The report will then be made available to the TS Managers mailing list and/or manager meeting.