Part 1: It’s All About the Process
This is the first in a brief series of blogs that will look at Risk Based Software Validation, the approach that IQS takes to this (sometimes perceived to be daunting) task and in this initial blog, my own realization that it’s really ‘all about the process’.
Software Validation Is Not About the Software
I had always approached the subject of Software Validation from the perspective, albeit a relatively uneducated perspective at the time, that the validation of software was exactly that – a validation of the software. To me, that meant that I needed to validate that each function of the software worked in the way I expected it to work and that I had to develop and execute protocols to verify and document that such was the case. If I ever changed the software, guess what – I had to re-validate the software.
Risk Based Software Validation is about the Process
For the last years, I’ve been working closely with IQS strategic partner CSA and what an education I’ve received. I’ve learned about Risk Based Software Validation rather than just software validation. Working together on multiple projects, across multiple different software applications (ERP, Warehousing, Quality, LIMS etc.), I have learned that risk based software validation is not wholly about the software, but is primarily about the process; It’s about understanding the processes that your organization has in place to manage the business, it’s about defining how the software you are using interacts with those processes, and it’s about identifying the risks associated with using that software as a tool to manage those processes. As soon as I understood this it was like, to quote Emeril Lagasse, “BAM!” someone had switched on the lights and I could see what a huge difference we could make when it came to helping companies validate their software.
What Can Risk Based Software Validation Do For You?
With the knowledge and understanding that I have gained over the last few years, I now firmly believe, and have seen in practice, that Risk Based Software Validation definitely isn’t just about the software, it’s about helping you understand your processes and identifying where and how your software touches those processes. Once you know what your processes and the software touch-points are, you can further analyze those touch-points to determine the associated risks and define what mitigations you have already (or that you will need to have) in place. You can also determine if your systems are fully supporting your process. Once you have that information, NOW you know what to validate and you can take the next step. In my next blog, I’ll review the steps that we go through with our clients as they start the process of preparing the foundation of their Risk Based Software Validation. >Read Part 2: Building Blocks of Risk Based Software Validation