FAQs

The primary pitfall of CSV is “testing for the sake of testing,” where the focus shifts from ensuring the system truly meets its intended purpose to simply generating paperwork for auditors. This often leads to a situation where a system is deemed compliant because protocols are followed and documents are filled out, but it doesn’t necessarily guarantee that the system effectively achieves the desired business outcomes or provides real value. The emphasis is on demonstrating what the system can do through individual tests, rather than demonstrating that the system does the right thing for its intended use.

Consider a system that mixes two chemicals in a specific ratio, maintaining a certain temperature and stirring. Traditional CSV might involve individually testing the flow meters, temperature controls, and stirrer to ensure they function as specified (e.g., valve opens to 50%, flow meter reads correctly). However, it might not directly test the “intended outcome,” which is the quality and consistency of the final chemical mixture produced at the end of the process. The individual components might pass their tests, but if the valve type is incorrect (e.g., equal opening instead of linear), the intended ratio and thus the final product quality could still be wrong. Traditional CSV often tests individual equipment performance in isolation, rather than the integrated process outcome.

CSA shifts the focus from exhaustive documentation and testing of every individual component to a risk-based approach that prioritises critical aspects of the system directly impacting product quality and patient safety. Instead of testing for the sake of testing, CSA emphasises demonstrating that the system consistently achieves its intended outcomes. This involves a deeper understanding of the process and integrating testing earlier in the lifecycle, focusing on proving the end result first. The assumption is that if the desired outcome is consistently achieved, the underlying components must be functioning correctly implicitly, with less emphasis on lengthy, isolated component testing.

By focusing on intended outcomes and integrating testing earlier, CSA can significantly reduce wasted effort and rework. Traditional waterfall approaches with sequential reviews and sign-offs often lead to delays and the need for re-explanation when issues are found late in the project. CSA encourages cross-functional teams (automation, process, operations, and potentially quality) to collaborate from the initial design phase, collectively defining requirements and how the system will achieve its purpose. This early alignment and continuous informal design reviews (which are essentially testing) reduce misunderstandings and ensure everyone is on the same page, leading to faster design, development, and testing cycles. Breaking down work into smaller, testable units (like in agile “sprints”) allows for quicker feedback and earlier identification of problems, preventing large batches of code or configurations needing rework at the end.

An informal design review in this context is essentially continuous testing and verification conducted by the integrated project team throughout the development process. It’s a highly structured yet less formal than traditional validation phases, focusing on demonstrating that small, functional units of the system (often software code) achieve their intended purpose. These reviews involve explicit test steps, recording observations (similar to a lab notebook), and documenting any issues encountered and their resolutions. The goal is to iteratively build and verify the system in smaller increments, banking progress as each unit is successfully tested, rather than waiting for a large, formal validation phase at the end.

Early and continuous collaboration ensures that the automation design is driven by the actual process needs and operational requirements. This prevents situations where automation is designed in isolation and then found to be unsuitable or inefficient for the intended use. With everyone involved from the start, there’s a shared understanding of the system’s purpose and limitations, leading to a “fit for purpose” design. This reduces the likelihood of significant rework later in the project due to misunderstandings or overlooked requirements. Quality is improved by design, not just by testing at the end.

With a modular and iteratively tested system under CSA, late changes can be addressed more efficiently. Because the system is broken down into smaller, independently tested units, a change in one area is less likely to have a cascading effect on the entire validation package. Instead of having to rewrite and re-execute extensive FAT protocols and manage numerous change controls on a locked-down system, changes can be implemented by modifying the relevant code or configuration, re-testing that specific unit through the informal design review process, and ensuring the database reflects the updated and tested state. This allows for greater flexibility and faster adaptation to evolving needs without causing major project delays.

• Safety: Safety is inherently addressed through the focus on intended outcomes and critical aspects impacting the product. Early involvement of EHS considerations within the integrated team ensures safety requirements are embedded in the design.
• Quality: Higher quality outcomes are achieved through a “fit for purpose” system designed collaboratively with a focus on the actual process needs. Quality is built into the process through continuous testing and verification, leading to fewer failures in later formal testing. There is also less duplication of effort and a more aligned understanding of the system’s purpose.
• Delivery: Project delivery is accelerated by reducing waiting times between teams, enabling parallel work on smaller units, and minimising rework due to early issue detection and resolution. The iterative approach and continuous informal design reviews streamline the development and testing cycles.
• Cost: Cost savings are realised through reduced rework, less idle time for team members, and a more efficient overall project lifecycle. By focusing on value-added activities and minimising unnecessary documentation and testing, resources are used more effectively.