Our conservative industry has taken time to catch up with other industries when it comes to reaping the benefits of cloud computing. For heavily regulated Life Science companies, the challenge lies in proving to regulators that they are in-control, even in the cloud. In this article, we share the experience we have gained over many years helping Life Science clients achieve success with their cloud transitions.
In the past, the cost and execution of the implementation project was the flagship activity of an ERP system’s lifecycle. This changes when moving to a cloud-based ERP system. Now, the implementation project must lay the groundwork to efficiently maintain the validated state of the system during operations. The validation plan must enable efficient regression testing of the system patches and upgrades that will come three to four times per year. With that in mind, here’s a brief overview of our methodology to help you to stay in control in the cloud and ensure your ERP system continues to support your business goals.
There are four disciplines you must master to ensure the system is always compliant and remains in-tune with your business needs:
Business processes
For an ERP system, it is critical that either you, your ERP vendor, or your implementation partner know all the GxP critical processes that apply to your company, and how to implement them in an optimized and compliant manner.
Applications
Most ERP systems are not specifically built for the Life Science industry. Still, most of them (including Microsoft Dynamics 365 and SAP S/4HANA) have Life Science best practice tools. Take advantage of these for most (though not all) of the considerations you’ll need to support your implementation.
Validation
Validate intelligently. Know that a rigid validation setup will kill you in the operations phase. Use vendor documentation and apply a thorough risk assessment. De-risk as much as you can and validate only what’s important.
Operation
Start preparing for the operation phase already in the beginning of the implementation phase. Create a robust model for forced changes because the system will change, not only during operations - but also during implementation! From the very beginning, there should be a focus on regression testing, change management, risk management, and test automation.
When we talk about vendors, we’re actually referring to two different roles. One of those roles is the software provider and the other is the implementation partner. These roles could both be filled by the same company, but are often not.
The software vendor provides the system software. In the cloud, you must rely on this vendor’s documentation to prove to the regulators that you are in control. These days, most ERP vendors have Life Science related whitepapers that can be used as part of the validation cycle.
The implementation partner will configure your ERP software, and thus will need to understand your business and GxP requirements and take you through several preparatory workshops. Implementation partners, like software vendors, are most often not industry specific, meaning they do not focus solely on the heavily regulated Life Science industry. Their quality management systems, whose repeatability are not up to Life Science standards, aren’t suited to be directly adopted into a Life Science company. An efficient way to solve this challenge is to provide your implementation partner with a quality plan. This will address the part of the process framework they are using, how they handle document management, and much more. Once they have received the quality plan, you can audit their project implementation methodology. This will tell you which part of their QMS they’re using to deliver your Life Science project. It’s a good way to qualify the implementation partner to ensure they’re capable of delivering.
Here is a suggested checklist to qualify potential ERP vendors. These are good questions to ask when you’re going into the planning phase for an ERP project. The results of these questions (and many more, of course) can be used as input for your validation plan.
Business Processes
Applications
Validation
Operation
Between the software vendor, the implementation vendor, and you – how do you ensure that everyone understands what they need to do before the project starts? We recommend a small preparation phase, which we call Phase 0. Create your RFP and find the relevant providers. Spend some time understanding the documentation that the software vendor brings to the table. Create the quality plan for the implementation partner. This very early version of the validation plan is key to the project’s success.
How do you create this early version of the validation plan? Start with an extended risk assessment. Over the years, we’ve developed a very efficient (and low-tech) methodology to do this. It starts with evaluating the software vendor’s and the implementation partner’s capabilities and mapping them against the regulatory requirements that apply to your company - 21 CFR Part 11, EU Annex 11, SOX, or others.
We suggest you make this risk assessment based on ITIL (Information Technology Infrastructure Library), and any other processes you have during operations, and map these to the relevant regulations. This creates a powerful tool to understand how to build control around the operation of your platform.
There are 9 dimensions to consider. Record this list in Excel (yes, low-tech), mark who is responsible for each process – either you, the software vendor, or the integration partner. Create mitigation actions for any gaps. Use these mitigation actions to create an annual control wheel.
Click here to see an example of the Cloud Control Matrix methodology for change management and configuration management. At Epista, we’ve adopted whitepapers from SAP S/4HANA, Microsoft Dynamics 365, and Oracle for this cloud qualification spreadsheet. It’s a powerful and efficient strategy for operating cloud base systems – and a great tool for showing an inspector you are in-control.
Regulatory bodies around the world are beginning to recognize the changing requirements for computerized system validation of cloud systems. This new attention enables the Life Science industry to take advantage of cloud computing, with a greater focus on critical thinking and less on generating documentation. The FDA is currently working on new guidance - CSA – Computer Software Assurance. The CSA guidance from the FDA gives us a more common sense two-dimensional approach to looking at risk.
On one dimension, CSA looks at whether the software is out of the box, configured, or custom built. This fits very well with cloud-computing. On the other dimension lies patient risk. A typical ERP system will be in the green fields for ‘ERP FITS’ (out of the box) and yellow fields for ‘ERP GAPS’ (configured). Even for high patient risk, ERP systems will stay in risk ratings 3 and 4.
Looking at the Assurance Activities associated with each risk rating, you’ll have to validate requirements through unscripted testing (automated) or through limited scripting tested (which can be on paper, automated, or a combination).
The idea is not to use less time on validation. The idea is to spend your time better. This makes a lot of sense when you think about the forced system patches and upgrades that will come three to four times per year from the ERP software vendors. You’ll have to test these changes in a much more intelligent way than before, or you won’t be able to keep up. Use this risk assessment to minimize documentation and maximize automation.
.png)
Let’s take a specific example from Microsoft Dynamics 365, using an efficient two-dimensional risk assessment that divides the requirements into a 2x2 matrix. On the functional dimension, there is GxP or non-GxP. On the technical dimension there is either ERP FIT or ERP GAP. Look at the right-hand side of the V model and find which of the four categories your requirement falls into.
Example: Non-GxP / ERP FIT - A non-GxP requirement that is classified as a fit does not require much documentation. You’ll need a URS and end up in a UAT. Note: We use the term UAT rather than PQ, so as not to confuse the vendor.
Example: GxP / ERP GAP - A GxP critical requirement with a gap is a more complex scenario and should be treated differently. You’ll need a URS, a process description, a functional design document with a test case, deployment procedure reports, unit test protocol, etc.
Bottom line: Identify the GxP critical processes in your company. Some will be fits and some will be gaps. Do less documentation for fits and more for gaps.
Tip #1: Remember to use the vendor documentation on both the design and test sides of the V-model. Your implementation partner will have experience doing ERP implementations, including specifications that make sense for their implementation. Use them instead of reinventing the wheel. And then you can beef up the validation side by strengthening the UAT tests compared to what the implementation partner would normally do, on the GxP / ERP GAPS.
Tip #2: We recommend that you automate OQ and PQ, so they can be used for regression testing during the operations phase. Specifically, automate testing for GxP / ERP GAPS. Then, when you are in the operational phase, this automation will help you ease the validation burden of forced updates.
Tip #3: Realize that the implementation phase of your project will probably last at least 12 months, maybe more. As SaaS, your cloud-based ERP system will change during the course of your project. This needs to be incorporated into your project model. Be aware that your baseline may be based on a previous release.
Tip #4: Use the tools you have in the ERP project to control the builds. DevOps for Microsoft Dynamics 365 and Solution Manager for SAP S/4HANA. Use these wisely for the different control configuration elements of your solution, as well as traceability. We often encounter people who try to update DevOps and Solution Manager to incorporate Document Management features, but this becomes extremely complicated. Reuse all the documentation you can, but we strongly advise against using these systems as document management systems. We advise using the tools for what they are built for – maintaining technical configuration items. Some will argue that the tools are also built for documentation. This is correct, but we stress that you may lose to control because they are also agile.
As mentioned, the challenge with a cloud-based ERP system is to maintain the validated state through the system’s annual forced updates and patches. It is true that the vendor governs the actual platform. But now, you’ve learned how to put the necessary controls in place, via your Excel-based cloud control matrix, to know if the vendor loses control. You can show regulators you are in control with your annual control wheel, which details what you need to do on a daily, weekly, monthly, quarterly, and yearly basis. And with regression testing, some of which is hopefully automated, you are also capable of maintaining the validated state with high certainty and good quality.
Final tip: For Change Management and Release Management, make sure you have a team member who understands GxP requirements and criticality. This will aid the evaluation of new functions and software changes, as well as allow you to know which related documentation to update.
Looking back, we must admit that large, on-prem ERP systems didn’t always serve Life Science businesses well in the long run. Because the systems were so cumbersome to update and re-validate, work arounds and customizations were often grandfathered into the systems. Anything to avoid making changes. This is not the recipe for a system that fits your business needs.
Yes, going cloud is a big change. It means doing things differently and losing some control. There will be forced updates and other challenges. But don’t overlook the fact that this is a huge opportunity. You’ll efficiently adopt new functionality, and continuously adjust the system to stay in tune with your business.
This is just a small peek under the hood of how to successfully transition to a cloud-based ERP system. We might not have answered all your questions, but we hope you’ve learned some of the right questions to ask! Get in touch if Epista can help you with your transition.
We enjoy sharing our knowledge. Get in touch to find out how Epista can add value to your Life Science company.
