In the Change Control Process a lot of Lean Principals can be applied. The first step is to define the Change Control Process. Usually this is done in a Standard Operation Procedure (SOP). In a Lean approach the process is described in a Value Stream Map. For each step the value of actions, documents and signatures must be clear. Where no value is added, the action, document or signature must be eliminated.
Proper administration must be in place to monitor the process. This can also be used to monitor the performance of the Change Control process.
The diagram below shows a Value Stream Map of a Change Control process together with the involved departments or officers. Later in this section the steps are explained.
Risk based steps
The process described in the VSM shows the maximum number of steps that are executed in the process Dependent of the type of change some of these steps may be skipped. Details about using Risk Assessment to determine the required steps are described in Risk based decisions during Change Control.
Risk based signatures
Risk Assessment should determine which signatures are required for each change. An example how to determine the required signatures is shown at Risk based decisions during Change Control.
In many cases signatures are in place for reasons as: "We used to do that" or "It is required by regulations"'. Never take these answers for granted. Take a look at the regulations or procedures to see if the signature is really required. Make a reference to the regulation found if the signature is required by that regulation. When a signature is not required and does not add value to a step, avoid the signature.
Unnecessary signatures introduce a lot of muri (overdoing). To get signatures takes a lot of time running around with documents and finding the proper persons. Electronic signatures help to reduce the running around activity but will still delay the process.
When modules are being changed, it is not allowed to use that module in production. To minimize the time that the module cannot be used a test environment or test system may be required. Secure version control is required to keep track of the module version and the versions of the test environment. The module that required a change can be modified and tested on the test environment while production is using the previous version of the module. When test of the changed module are completed, in a short time the new version is installed on the production system where the qualification is completed, where after production is continued.
In the define step the change is specified. A business case must define the value of the change. A Risk Assessment, as shown in Risk based decisions during Change Control, defines the required steps in the process and the required signatures. The definition must indicate which document and modules need to be updated.
The design step describes how the change is implemented and how the change requirements are met.
Version numbers of modules or interfaces that are effected by the change must be mentioned.
The pre-approval step is required to ensure that the requirements for the change are clear to all the involved persons. When no test environment is available, from this moment on the module cannot be used for production until the new version of the module is qualified or the previous version of the module is restored.
This step indicates that the change is implemented and ready for qualification.
A test protocol must be developed to assist in qualification of the change.
Using predefined templates for these documents is useful to save on time and mistakes.
In the Installation Qualification step the new software module is installed on the system. Installation checks are performed as defined in the test protocol.
In the Operational Qualification step the new software module is functionally tested on the test system or production system. Operational tests are performed as defined in the test protocol.
In the Performance Qualification step the new software module is tested on the production system under production circumstances. Performance tests are performed as defined in the test protocol.
In this step the new version of the module is released for production. Documentation is completed and the change is documented and archived with the related test data and protocols.
After the change the system is in a validated state again.