Appendix O4 Operational Change Control.pdf

(17 KB) Pobierz
Appendix O4:
Guideline for Operational Change Control
1.
Introduction
This is a Guideline for the control of changes to automated systems during operational use. This is Change
Control from the point in the development life cycle when the user company starts to use its pre-defined and
formal Change Control processes, which will continue thereafter through the life of the system. It should be
started at the beginning of formal qualification (IQ, OQ, PQ), but in no case should it be started any later than
handover for operational use. Handover is defined as the point that the System Owner accepts the system from
the project team into operational use, given that the system, its documentation, and support arrangements are
agreed and in place.
Project Change Control is the process of controlling change during development and is usually managed by the
supplier and the implementation team. Project Change Control should be one of the topics of the Supplier
Assessment.
The point at which the transfer from Project Change Control to Operational Change Control happens should be
clearly defined and documented, e.g., in the Validation Plan, Validation Report, system release documentation,
or other means as defined in Standard Operating Procedures (SOPs).
Change Control is fundamental to maintaining the validated status of systems and processes. The Change
Control process is closely related to Configuration Management. When changes are proposed, both Change
Control and Configuration Management activities need to be considered in parallel, particularly when
evaluating impact of changes.
Guidelines for Project Change Control and for Configuration Management are given in Appendix M8 and
Appendix M9, respectively.
2.
Scope
This Guideline applies to changes to controlled documentation, application software, operating system
software, firmware, hardware and system, master and configuration data for a system in use, or during
qualification and acceptance in a user company.
3.
Guidelines
3.1
General
All changes should be reviewed, impact and risk assessed, authorized, documented, tested, and approved
before implementation. The following changes, however, are exempt:
•
Like-for-like replacements: these changes can be controlled by maintenance procedures designed to
control materials usage and record system history. Like-for-like is not always easy to assess and
consideration should be given to the impact of any change.
•
· Emergency repairs: these changes should be subsequently reviewed, tested, documented, and
approved in a timely fashion according to the appropriate procedure. What constitutes an emergency
change should be clearly defined.
Changes made during approved experimental work may be recorded in experimental programmes. Examples
include changes to PLC logic to modify process sequences in Process Control Systems. Provided such
changes are adequately described and controlled in the experimental programme then it may not be necessary
to utilize a separate automated system Change Control procedure. Computer validation documentation,
however, must clearly point to the documentation for the experimental programme.
3.2
Request for Change
Any proposed change should be requested by completing the Request For Change Section of the Change
Request Form (Attachment I to this Appendix). Each Change Request should be assigned a unique reference
number and logged in the Change Request Index (Attachment 2 to this Appendix).
3.3
Change Disposition and Authorization
Each system should have a designated System Owner or manager responsible for ensuring that all changes to
the system are implemented in a controlled manner. Each Change Request raised should be reviewed for
impact and its disposition (accept or reject) determined by management. At least two people are normally
required to accept or reject a change, and for GxP regulated systems one of these must represent Quality
Assurance.
3.3.1
Reject Changes
Those responsible for rejecting the Change Request should complete and sign the Change Disposition and
Authorization Section of the Change Request, stating the reasons for rejection in the Change Details Section of
the Change Request. The Change Request should be filed, the index updated, and the originator informed of
the decision.
3.3.2
Accepted Changes
Those responsible for authorizing the Change Request should complete and sign the Change Disposition and
Authorization Section of the Change Request. They should also confirm the following:
•
Which controlled items are affected by the Change Request, e.g., hardware, software, documentation,
or other similar automated systems (e.g., systems on a different site)
•
The re-testing required to ensure that satisfactory performance is maintained
•
The risks associated with making the change and any back out plans if the change fails at
implementation
•
The effect on users, e.g., training plans
•
To whom to communicate the change
These decisions should be recorded in the Change Details Section of the Change Request.
If more than one controlled item is to be changed as a result of the Change Request then each change should
be tracked to completion. The use of a Change Note (Attachment 3 to this Appendix) for each item should be
considered, defining the particular changes to be made to that item.
A Change Plan may be required for multiple activities and resources and, if produced, should be attached to
the Change Request and cross-referenced from it.
3.4
Change Completion and Approval
When all changes have been implemented and re-testing is complete the Change Request should be passed
to management for final review and approval. Where the change impacts GxP, QA should be included in the
approval panel.
The completed Change Request should be filed and the index updated.
4.
Attachments
Attachment 1:
Change Request
REQUEST FOR CHANGE
Automated System Change no:
Plant Date:
Location: Telephone no:
Originator:
Proposed change:
Reason for change: Required by date:
CHANGE DISPOSITION & AUTHORIZATION
Disposition:
Authorized / Rejected* * Delete as appropriate
Signature: Job title: Date:
Signature: Job title: Date:
Signature: Job title: Date:
CHANGE DETAILS
Comments: (Include either reasons for rejections, details of re-testing, Change Plan reference)
Number of Change Notes attached:
CHANGE COMPLETION AND APPROVAL
Completed Signature: Job title: Date:
Approved by Signature: Job title: Date:
Signature: Job title: Date:
989352457.045.png 989352457.046.png 989352457.047.png 989352457.048.png 989352457.001.png 989352457.002.png 989352457.003.png 989352457.004.png 989352457.005.png 989352457.006.png
 
Attachment 2:
Change Request Index
System:
Sheet:
Change
number
Description
Disposition
acc / rej date
Number of
Change Notes
Date
closed
989352457.007.png 989352457.008.png 989352457.009.png 989352457.010.png 989352457.011.png 989352457.012.png 989352457.013.png 989352457.014.png 989352457.015.png 989352457.016.png 989352457.017.png 989352457.018.png 989352457.019.png 989352457.020.png 989352457.021.png 989352457.022.png 989352457.023.png 989352457.024.png 989352457.025.png 989352457.026.png 989352457.027.png 989352457.028.png 989352457.029.png 989352457.030.png 989352457.031.png 989352457.032.png 989352457.033.png 989352457.034.png 989352457.035.png
 
Attachment 3:
Change Note
System:
Change number:
Change Note number:
Item number:
Item reference:
Item version / issue number:
Details of Change to perform:
Implemented by: Print name:
Signature: Date:
989352457.036.png 989352457.037.png 989352457.038.png 989352457.039.png 989352457.040.png 989352457.041.png 989352457.042.png 989352457.043.png 989352457.044.png
 

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin