How Telia is modernizing performance testing with Tricentis NeoLoad
Hear from Telia, one of Sweden’s largest telecommunications companies, how they use Neoload for their performance testing.
Over the years, we have seen a steady increase in companies moving away from paper-based validation to electronic-based approaches after the FDA introduced 21 CFR Part 11, which addresses the use and control of electronic signatures and electronic records. When utilized correctly, 21 CFR Part 11 opens the door to numerous potential process and solution improvements in computer systems validation, yet many teams have failed to take full advantage of these improvements. Understanding Part 11 and moving to electronic-based systems is a step in the right direction, but it’s important to understand that not all variants of electronic-based CSV methodologies are created equal.
The conversion from a paper document to an electronic document is a pitfall that many teams have fallen into under the false hope of making forward progress in CSV. While it is an improvement in many ways versus paper documentation, the reality is that the shift from a paper document to an electronic document-based approach to CSV is not nearly as much of a leap as one would hope.
When distilled down, little new is being achieved other than simply moving the same paper-based process and documents to a computer screen instead of a physical piece of paper, and perhaps adding some templates and workflow. It’s putting a slightly modern spin on the inefficient, antiquated paper-based methodology and brings with it many of the same downsides.
From our perspective, this approach does not offer the fullest potential for modernizing CSV processes or solutions, nor does it facilitate the fullest utilization of what an effective application of 21 CFR Part 11 can allow.
So, why have so many teams opted to leverage this variant of electronic-based approaches to meet their CSV requirements?
To start, moving to an electronic document-based system comes with a certain sense of familiarity, and with familiarity comes comfort. Adopting the electronic document looks and feels much the same as processes that were already in place, so in theory, it would not take a huge revision in SOPs, nor would it require a large investment in retraining employees.
After all, introducing change into a regulated environment can be a difficult task in and of itself. An electronic document with an electronic signature feels like just enough evolution without having to introduce revolution, so the burden of positioning internal buy-off is lessened.
As an added bonus, the electronic document does remove some of the more obvious headaches of the paper-based approach by allowing for a simplified method of review and approval, document retrieval, and document sharing. No more printing and signing documents, storing boxes of binders filled with validation documentation, scouring the annals of storage facilities looking for pieces of the validation puzzle at an auditor’s request, etc. Couple these (small) benefits with the power of something familiar and comfortable in a regulated environment and it becomes easy to understand the appeal.
However, these benefits are relatively insignificant in contrast to the limitations of the document, and familiarity and comfort should not be reason enough to shy away from necessary innovations. As mentioned earlier, the electronic document carries with it many of the negative characteristics and limitations of the paper document. The operative word in both methodologies being “document.”
Whether it’s a piece of paper with wet signatures or a PDF with electronic signatures, the static document simply does not lend itself to modern demands on development and testing teams.
Whether paper or electronic, the document-based approach was designed and implemented to align with a more traditional waterfall approach to development and testing. Defined schedules with phases mapped out and executed in a serial fashion could more easily account and plan for the document-based approach to CSV during the planning phases. This approach also allowed for the validation documentation to be drafted with a certain level of accuracy as each phase would, for the most part, maintain the requirements outlined in the planning phase.
The nature of an Agile or DevOps-oriented methodology – or even a framework that leverages components of those approaches – requires flexibility in a fast-moving, cross-team structure in which requirements can change quickly and often. Iterative-based sprints and releases of functional components of the full application require that teams be nimble enough to adapt to ongoing changes based on feedback from business groups and end users.
To maintain ever-moving targets and schedules, ongoing reporting across projects and teams at a granular level is required to sustain cohesion across the software development lifecycle. A static validation document with pre-defined requirements and phases quickly falls down in this approach.
Without constant maintenance and revision attention, validation documentation soon becomes far out of sync with changing project requirements. This constant change in requirements and reauthoring of the validation documentation then requires more rounds of review and approval. More rounds of review and approval then require more downtime and delays before the rest of the team can start to execute or incorporate those requirements into tests.
Requirement traceability becomes an onerous, manual task that is in a perpetual state of change, review, and confirmation. Project reporting when relying on a static document does not allow for a holistic view of project status. Validation and QA teams are constantly at odds with development, business, and SW IT teams.
All of this adds up to incredibly inefficient use of resources, time, and budget – not to mention it detracts from what should be the ultimate objective, which is software quality.
Unfortunately, the inefficiency doesn’t end there. When the FDA comes knocking, teams need to have their ducks in a row and that means well-organized, accessible controlled validation information. But the use of documents makes it difficult to quickly find specific information that an auditor may be looking for. However, once the focus shifts from “documents” to the underlying validation “data,” filters and queries can be used to quickly find what you are looking for.
The importance of validation and compliance in a regulated environment cannot be understated. No matter how much of an impedance maintaining a document-based approach may be, if it has been leveraged to maintain relatively good standing with the FDA, then it becomes very difficult to persuade compliance/validation and QA teams to deviate or adopt any major changes to the status quo. After all, no matter how inefficient the document-based approach to validation may be, we are talking about a regulated environment, and introducing major changes in methodologies and solutions comes with considerations and implications that all teams need to weigh out.
As difficult as proposing changes in a regulated environment may be, remaining tied to outdated methodologies should not be an option. The document’s place in modern CSV is proving to be nothing short of limiting, if not altogether impeding, to today’s development and software quality requirements. Organizations must start having dialogue among their teams to formulate and promote an exit strategy from the document.
In any organization, regardless of industry or areas of focus, implementing change can be a daunting task filled with objections, arguments, cost analysis, ROI studies, and a seemingly never-ending series of meetings. It’s a shared story across any organization, but it becomes especially complex when evaluating the implementation of new methodologies and technologies into a regulated environment. The more significant the proposed change, the more difficult the process of making that change a reality can potentially become. Advocating change to a computer systems validation program is no exception.
Introducing new methodologies to CSV is an undertaking that should not be approached lightly and there will be plenty of internal stakeholders that will be sure to make this abundantly clear. In fact, many will be very vocal or downright obstinate in their objections to shifting from the status quo. In their arsenal, objectors will have numerous valid concerns, as well as several potential roadblocks at their disposal, so expect to hear things like …
“If we roll out a new process and use new solutions, we’ll have to re-author all of our SOPs. Who is going to handle that?”
“New SOPs will mean that everyone will have to be retrained accordingly. We simply don’t have the time or resources to dedicate to something like that.”
“Quality is pretty set with their current solutions and process, and they are pretty staunch in their rigidity when it comes to how things are done. They will never sign off on this.”
“Introduce a new system into our environment? That means we’ll have a whole new validation lifecycle to account for moving forward. I don’t think we have the resources or budget to take something like that on.”
“We’ve spent years and countless hours building what we are currently using. It feels like it would be a waste to throw it all away to implement something new.”
“We will have to completely change how we handle audits. I don’t think that’s a risk we want to take.”
“Why would we change how we’re doing things now? It works.”
These are all valid items that need to be addressed, but that doesn’t mean that current solutions and processes are meeting those challenges effectively either. This is the type of pushback that has really handcuffed the life sciences industry. It’s why technology teams at many life sciences companies are generally many years behind other industries when it comes to adopting methodology and technology standards. Forget about being at the forefront of innovation and trends, I’m talking years behind widely utilized standards.
In order to overcome those objections to introduce change and forward progress in CSV, planning and execution must be well thought out. Teams championing those changes need first to be able to identify shortcomings of current solutions and processes. They must then be prepared to demonstrate a solution that will not only address those shortcomings but will decrease risk while improving operational efficiency.
Swapping paper documents for electronic documents has marginal benefits and wrapping additional solutions around electronic documents only further complicates an already complex and risk heavy methodology.
So, what addresses the flaws we’ve discussed in a document-based CSV framework? What can replace the document that addresses all the most common objections teams face when proposing this shift? What achieves all this while bringing organizations into the modern era of software development and quality technology standards?
The answer lies in moving beyond the document and shifting to digital validation; a more dynamic, controlled and efficient approach to CSV that supports the needs of modern testing teams.
If digital validation is something you would like to learn more about, please download the white paper below to get a more in-depth view of the drivers of change in life sciences that are leading organizations to undergo modernization strategies, as well as the benefits that can be obtained when leaving the document behind and adopting digital validation with Tricentis Vera™.