Applying GAMP 5 to Validate an ERP System
ISPE’s GAMP 5 explains the methodology for implementing an ERP system, either new or existing, in a regulated environment. Here is a discussion of an actual implementation.
Stephen R. Ferrell
Editor’s note: This article was originally published in the November/December 2010 issue of Pharmaceutical Engineering, the official publication of ISPE (www.ispe.org). Normally this content is only available to society members, but is reprinted here in abridged form by special arrangement. The full text, including all related references, is available online. ISPE has its Tampa Conference, February 21-24, 2011: www.ispe.org/2011tampaconference.
Risk management concepts in the pharmaceutical industry are maturing and harmonizing as reflected in ICH Q9 (International Conference on Harmonization) Quality Risk Management. GAMP 5 (Good Automated Manufacturing Practice 5) provides direction in applying these concepts in the development, implementation, and maintenance of computerized systems. Risk to the patient and product quality continue to be the primary areas of concern. This article shows how such risk-based approaches can be effectively applied to ERP validation and compliance.
Typically, commercial off-the-shelf software (COTS) packages, including those used as the basis for most ERP implementations, will be carefully tested by the suppliers before commercial release. Therefore, there is no intrinsic value in attempting to test every mouse click or every submenu in this context and it is not a regulatory requirement. The focus should be rather on ensuring that the configuration of the product is defined, holistic (in terms of GxP1, 2 and Part 113 compliance), follows actual business processes, and is verified to be fit for intended use.
The regulated company should focus on managing potential risk to patient safety and product quality, and ensuring compliance with the relevant GxP regulations, including 21 CFR Part 11. Additionally, they also should consider the impact to the overall business process.
GAMP 5 defines a computerized system as: “A computerized system consists of the hardware, software, and network components, together with the controlled functions and associated documentation.” Based on this definition, a holistic approach was used in the implementation of the ERP system as described below.
Case study overview
The ERP system discussed in this article, SAP, was a legacy system. The system had not been previously used for GMP purposes. Therefore, the documentation surrounding the system was essentially non-existent in that it did little to support the use of the system in a regulated environment.
An important element when purchasing a computer product or service is supplier assessment, which may include supplier audit. In this case, however, while the system was new to the GMP manufacturing plant, it had been in use supporting the business for 15 years. As a result, a decision was made, justified, and documented with the rationale for why an audit would not occur. The organization acknowledged that the vendor is an established and recognized business solution provider with a large user base in the industry. The project team defined and included relevant intended use risks in the risk assessment.
Creating a computerized system validation plan is a fundamental building block of any validation project because it outlines the strategy for the entire project. Keep in mind, however, that every system, implementation, organization, and site is different, so rather than focus on “what goes in a validation plan,” focus rather on the various document components that do exist based on the legacy history of the ERP system to determine the rationale, and the approach used to outline a testing strategy. This strategy can be incorporated into any validation plan or equivalent.
GAMP 5-based risk assessment
For the purpose of this case study, the risk was broken down into the following three components:
1. System risks;
2. Criticality of user requirements; and
3. GMP T-Codes (transaction codes).
Each function in the system has an associated code. Using a transaction code enables quicker access to any task in the system.
A system risk assessment (RA) was prepared early in this project before the URS (user requirement specification) was written. It was essential that the project team agreed on the specific high level risks and functions that one would expect an ERP system to control. The project team used the SAP whitepaper “Complying with US FDA Title 21 CFR Part 11 for the Life Sciences Industry,” as a starting point for the team providing insight into SAP functionality. The concepts in the whitepaper were easily translated by the non-SAP specialist business units and then filtered for applicability to our business model. It is very beneficial to leverage what is available from the vendor on the specifics of the ERP system as the requirements are created.
Risk assessment workshops were formed and risk was discussed in the context of the functions that would be relevant to the business units going forward. Representation at the workshops included manufacturing, production planning, quality assurance, quality control, distribution, sales, customer service, IT, and validation.
Ultimately, the following four themes repeated themselves as potential remedial actions were developed:
1. Ensure configuration is well defined;
2. Ensure configuration is adequately tested;
3. Ensure configuration is managed post-go live; and
4. Ensure users are trained on said configuration.
The company was able to apply the four themes in the context of their own business model to develop the following:
• Define - create the user, configuration, functional and design specification;
• Test - build validation scripts;
• Manage - create ERP friendly SOPs; and
• Train - teach the business how to use the system.
The risk assessment included key GMP risks and other business risks, including those related to Sarbanes-Oxley (SOX). All risk considerations were evaluated and where applicable, remedial actions were identified based on criticality. Each risk identified was clearly designated as GMP or otherwise. As the project progressed, the risk assessment was revisited twice; once after the user requirements were defined and again after the business blueprinting or functional specifications were written.
One of the challenges with any risk assessment process is the assignment of H/M/L (high/medium/low) and the dependencies between justifying one risk as higher than any other. GAMP 5 provided the following error occurrence by transaction: 100 = L; 1,000 = M; and 10,000 = H. GAMP 5 suggests that a scientific approach to risk assessment be applied. After much debate, the approach agreed upon was to rely on the knowledge and collective experience of the workshop teams to create a baseline for H/M/L assignation and then to consistently apply it to the system.
This assessment was additionally used to provide priority targeting for remediation, and the results broke down as follows: 105 High / 84 Medium / 57 Low priority for remediation. Ultimately, the RA was revisited at the conclusion of the project to ensure all remedial actions were traced regardless of priority.
Risk-based criticality of user requirements
The seven step process below describes how the team leveraged the regulations and utilized the existing system documentation to aid in building the User Requirements. This process aided in the risk analysis and testing required to execute the project.
Step 1: The regulations—Many regulations clearly apply in this case, including: 21 CFR Part 11, Part 210 Part 211, Part 820, and EU Vol. 4 Annex 11.
An ERP system plugs into almost every part of the business process. The project team reviewed the functionality of the system and assessed the functions and filtered through the main GMP (Part 820). This early exercise enabled the development of very low level GMP-centric user requirements that the system would have to conform to be compliant. This activity was done internally by the validation team prior to user requirement workshops. This created a first pass “must haves” that the business could build the system around to be GMP compliant.
Step 2: Recycle—Most GMP regulated operating companies will already have an ERP or similar system in place. If a company has been regulated for a while, there may already be a validation package from a previous system that could be recycled, and perhaps a number of change control packages to use. In this case study, using a high level risk assessment system, the company was able to discern which parts and pieces of our original URS (which was system neutral) were applicable to the current business process.
Step 3: Business needs/user requirement workshops—In order to make the process as focused as possible, user requirements workshops were formed with the various functional groups. All user groups were given the skeleton URS two weeks in advance of the first workshop and were encouraged to add, subtract, edit, and comment. The commented URSs were consolidated and ultimately yielded in excess of 3,000 user requirements, some duplicated, some ambiguous, some bizarre.
Next, three half-day workshops per week for four weeks were scheduled, each and every URS was reviewed, and a unique identifier for traceability (like PP-164 or OH-23) was captured. Each URS was given a criticality number directly correlating to its impact on the GMPs and Part 11. These were:
• Mandatory URS ranked as a “1” – GMP or GMP and business critical;
• Beneficial URS ranked as a “2” – non-GMP, but business critical; and
• “Nice to have” URS ranked as a “3” – non-GMP, non-business critical.
At the end of the four weeks, the following user requirements were captured:
• 396 level 1;
• 1,157 level 2; and
• 198 level 3.
This approach achieved two key goals. First, by virtue of the risk and criticality process, the GMP testing burden was reduced to a little less than 400 requirements and second, a requirements document was now available for the ERP analysts to build from. This document was developed by all key stakeholders, including QA.
Step 4: Blue printing—In order to translate the neutral user requirements into ERP-centric functional requirements, a suite of PDDs (process design documents or functional specifications) was created. The goal of the PDDs was to define the system in a way that could be understood by both the analysts and business. Each PDD was traceable back to as many as 30 URSs and all business processes were defined graphically using MS Visio.
The process flows integrated into PDDs gradually formed a picture of what the system would look like post go-live, and the use of the ERP integrated into our business process started to take shape. Later, the flows were used as a basis for PQ and the PDDs were tied to the new SOPs, which then in turn formed the baseline for process change control.
In addition to the process flows, the ERP implementation team translated URS into functional processes broken down by functions, data, or interfaces.
Step 5: Functions—Each collection of URSs was translated into the appropriate function set in the ERP; any inputs, outputs, calculations, configuration, or security considerations were captured here.
Step 6: Data—The data section was mainly focused on those data elements necessary to be considered for the function set in scope to execute correctly. Within SAP, master data plays a very important role and can cause significant system issues if not formatted or defined correctly. Where possible, master data considerations were included in this section.
Step 7: Interfaces—Beyond a bar-coding system, the ERP instance does not have any major peripheral interfaces; due to the nature of the formation of sub teams (by ERP module); however, there was reference to the ERP modules that any particular function set was or could impact. This facilitated the sub team communications as cross functional processes were developed.
GAMP 5-based system configuration
This posed a challenge as the legacy ERP system was already in place. As previously described, the system had been used for non-GMP purposes; therefore, documentation that had been created while valuable to the ERP team was not easily translated into the regulated context.
The configuration definition process was split into two parts. For the servers, operating systems, and core ERP build, system configuration specification (core SCS) was created. This allowed verification to occur simultaneously thereby qualifying the hardware and core software, while the ERP analysts were translating the user requirements. For the actual configuration or customization of the ERP, the decision was made to use the legacy system as a baseline, documenting all changes that were necessitated by our compliance requirements utilizing additional configuration documents (CFD).
Part 1 – Hardware and core software SCS16
GAMP 5 Appendix D3 provides a check list for SCS content. Also, the team utilized the “IT Infrastructure Control and Compliance Guide.” Depending upon the roles and responsibilities defined in your organization, the documentation can be managed effectively with well defined roles and responsibilities assigned to each business unit within the company. For this project, splitting the configuration documentation allowed the team to engage a completely separate resource pool at the component level and frame a schematic of the system. Specific sections of the SCS have been chosen to highlight some key information that was gathered and documented.
ERP infrastructure hardware configuration
The server setup is considered standard and consists of the following four environments:
3. Quality (test); and
Note that this vendor recommends installing the application server and central database server on separate machines and placing them in a separate subnet. It is beneficial to seek affirmation and supporting information from the vendor on installation requirements.
ERP infrastructure environmental conditions
It may seem redundant to capture and verify environmental conditions, especially considering the servers had already been used in support of the application. However, failure to ensure a temperate and sustained environment for your servers can have a significant business impact.
Physical security—All of the physical security attributes were defined and later formally verified for the various data centers around the globe.
Database security profiles—An important and easily overlooked component to any client/server system is database security, i.e., who has access to your back-end tables. Typically, application security will not address those accessing your servers from outside the application. For this ERP system, the administrator accounts, administrator’s roles, role mapping, data exchange account, and Unix access were defined. Again, the “buckets” are not as important as the content, and who can access the data. It is important to understand who can do what, define it, and control the access to the data.
Transport management—Transport process flow should be managed from sandbox to development, from development to QA, and then ultimately into production. It is important to define and control the transport method and flow. This should be incorporated into the change control system.
Peripheral system interfaces—The last key element to discuss in the core SCS are peripheral systems. It is important to understand the data input into the ERP, the data source, and the controls around that source. Equally, one must understand what system the ERP output data is sent to for use. Those interfaces and the associated systems should be carefully evaluated to determine GMP use and subsequently their validation status. Examples from this implementation included a barcode system, a LIMS, and a labeling system.
The full text includes additional discussion on:
• Customizing the application and configuration documents;
• Strategies for the qualification process;
• Charts and graphics; and
• Related references.
Stephen Ferrell is a certified information systems auditor with more than 12 years of progressive IT experience emphasizing computer system and software compliance, QA auditing, and quality strategies. He is currently a member of the GAMP North America Steering Committee and chairs the GAMP IT Infrastructure SIG.
Case Study Database
Get more exposure for your case study by uploading it to the Plant Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.
2012 Salary Survey
In a year when manufacturing continued to lead the economic rebound, it makes sense that plant manager bonuses rebounded. Plant Engineering’s annual Salary Survey shows both wages and bonuses rose in 2012 after a retreat the year before.
Average salary across all job titles for plant floor management rose 3.5% to $95,446, and bonus compensation jumped to $15,162, a 4.2% increase from the 2010 level and double the 2011 total, which showed a sharp drop in bonus.