Planning of ERP SAGE X3 Validation activities on a risk-based

approach for a new pharmaceutical plant

Diogo António Camoesas Ramos

Thesis to obtain the Master of Science degree in

Master in Pharmaceutical Engineering

Supervisor(s): Prof. Dr. José Monteiro Cardoso de Menezes

MSc. Mara Diana Saavedra Cardoso Doria

Examination Committee

Chairperson: Prof. Dr. Pedro Paulo De Lacerda e Oliveira Santos

Supervisor: MSc. Mara Diana Saavedra Cardoso Doria

Member of the Committee: Prof. Dr. Rui Miguel Dias Loureiro

December 2019
Preface

The work presented in this thesis was developed at the company Labatec Farmacêutica S.A. (Sintra, Portugal),
during the period March to September 2019, under the supervision of MSc. Mara Doria. The thesis was co-
supervised by Prof. Dr. José Cardoso Menezes.

I declare that this document is an original work of my own authorship and that it fulfills all the requirements
of the Code of Conduct and Good Practices of the Universidade de Lisboa.

I
Acknowledgements

First, I would like to thank my supervisor Prof. Dr. José Cardoso Menezes for the work accomplished during the
pharmaceutical engineering master's degree and for the opportunity to develop this dissertation.
To Mara Doria, thank you for providing me with the opportunity to perform this thesis in Labatec Farmacêutica
S.A, for the support, availability and guidance during this Project.
To Marcella Santi, thank you for all the support, availability and patience, guidance and teaching provided
throughout this project.
To all Labatec Farmacêutica S.A team, thank you for welcoming me, for always being there to support and for
trusting me to contribute to the Labatec project.
Moreover, Thanks to all my friends who cared about me and helped me during the development of this
dissertation, especially to Raquel Saborano, Vasco Batista, Flávia Magalhães and Daniel Tavares.
A special thanks to my girlfriend Inês Correia, who contributed to everything, with availability, support,
guidance and friendship during all stages of this phase. This effort and dedication were very helpful to me.
Finally, I would like to thank my parents and brother for being the reason why I am finishing this phase of my
life, thank you for all your support, for trusting me and for always giving me the opportunity to continue to
develop this path to a successful future.
I dedicate this dissertation to my grandmothers, Adília and Fernanda, who are extraordinary women and who
take care of their families very well, as they have always done. It was the values you instilled in your children and
grandchildren that made them who they are, I am very proud. Thank you for everything.

“Trust, but verify” - Ronald Reagan

II
Abstract

The overall objective of this dissertation is to support the validation phase of a computerised system in the
pharmaceutical industry in order to ensure that the system will always function as expected without
compromising the quality of the product.
This dissertation aims to provide a guide on how to plan the validation activities of a computerised system,
highlighting its importance in an extremely regulated environment such as the pharmaceutical industry. The
computerised system referred in this work consists of the Enterprise Resource Planning SAGE X3 that manages
various activities of a pharmaceutical company, from the purchase of raw materials to the distribution of
products.
This dissertation presents a risk-based methodology that categorizes the risks of the different functionalities
of the system, establishing a framework for the planning of the qualification activities in order to provide a guide
for future implementation of computerised systems in the pharmaceutical industry. The application of this
methodology in the practical case of an Enterprise Resource Planning system for Labatec Farmacêutica S.A.,
allows to determine the impact of the system, to define the user requirements and to evaluate the functionalities
through a risk management tool (Failure Mode Effects Analysis). This resulted in a detailed sequence of tests and
actions to be performed in the appropriate qualification phases.
In conclusion, this thesis allowed to develop a risk-based validation plan to be applied in the validation of a
computerised system in a pharmaceutical company.

Keywords:
Computerised System Validation, Enterprise Resource Planning, User Requirements Specification, Risk-Based
Approach, Failure Mode Effects Analysis, Functional Risk Assessment

III
Resumo

O objetivo geral desta dissertação é apoiar a fase de validação de um sistema computorizado na indústria
farmacêutica de forma a garantir que o sistema irá funcionar sempre como esperado sem comprometer a
qualidade do produto.
Esta dissertação tem como objetivo fornecer um guia sobre como planear as atividades de validação de um
sistema computorizado, realçando a sua importância num ambiente extremamente regulamentado como é o da
indústria farmacêutica. O sistema computorizado referido no âmbito desta dissertação consiste no sistema de
planeamento de recursos empresariais SAGE X3 que gere várias atividades de uma empresa farmacêutica, desde
a compra de matérias-primas à distribuição dos produtos.
Esta dissertação apresenta uma metodologia baseada no risco que categoriza os riscos das diferentes
funcionalidades do sistema, permitindo o planeamento estruturado das atividades de qualificação a fim de
fornecer um guia para futuras implementações de sistemas computorizados na indústria farmacêutica. A
aplicação desta metodologia no caso prático de um sistema de planeamento de recursos empresariais para a
Labatec Farmacêutica S.A., permite determinar o impacto GxP, definir os requisitos do utilizador e avaliar
funcionalidades através de uma ferramenta de gestão de risco (Failure Mode Effects Analysis). Isso resultou numa
sequência detalhada de testes e ações a serem realizados nas fases de qualificação apropriadas.
Em conclusão, esta tese permitiu desenvolver um plano de validação baseado no risco a aplicar na validação
de um sistema computorizado numa empresa farmacêutica.

Palavras-Chave:
Validação de Sistemas Computorizados, Planeamento de Recursos Empresariais, Especificação de Requisitos
de Utilizador, Abordagem baseada no risco, Análise de modo e efeito da falha, Avaliação de riscos funcionais.

IV
Index
Preface ................................................................................................................................................................. I

Acknowledgements ............................................................................................................................................ II

Abstract .............................................................................................................................................................. III

Resumo .............................................................................................................................................................. IV

List of Figures ..................................................................................................................................................... VI

List of Tables ..................................................................................................................................................... VII

List of Abbreviations ........................................................................................................................................ VIII

1. Introduction .................................................................................................................................................. 1

Labatec Group .......................................................................................................................................... 1

Objective ................................................................................................................................................... 2

Computerised System............................................................................................................................... 2
1.3.1 Enterprise Resource Planning........................................................................................................... 3
1.3.2 ERPs in the Pharmaceutical Industry ................................................................................................ 4
1.3.3 SAGE X3............................................................................................................................................. 5

Computerised System Validation ............................................................................................................. 6

1.4.1 Regulatory Considerations ............................................................................................................... 6
1.4.2 Regulatory Requirements ............................................................................................................... 10
1.4.3 Good Automated Manufacturing Practices (GAMP®5) .................................................................. 13
1.4.4 Qualification Activities .................................................................................................................... 15
1.4.5 System Testing ................................................................................................................................ 16

Quality Risk Management ...................................................................................................................... 18

2. Methodology followed in the dissertation ................................................................................................. 21

3. Case Study: Planning of the ERP System Validation in Labatec Farmacêutica S.A. ................................... 22
ERP in Labatec Farmacêutica S.A. ........................................................................................................... 22

System Impact Assessment .................................................................................................................... 23

Validation Plan ........................................................................................................................................ 25

Development of the User Requirement Specifications .......................................................................... 27

Functional Risk Assessment.................................................................................................................... 39

4. Conclusions and Future work ..................................................................................................................... 56

5. Bibliography ................................................................................................................................................ 57

6. Annexes ...................................................................................................................................................... 61

V
List of Figures

Figure 1 – Labatec logo ....................................................................................................................................... 1

Figure 2 - Labatec geographic expansion ........................................................................................................... 1
Figure 3 – Structure of a Computerised System in his Operating Environment ................................................ 2
Figure 4 – Evolution of the Enterprise Resource Planning Systems ................................................................... 4
Figure 5 – ERP modules....................................................................................................................................... 5
Figure 6 – Relationship between areas in a general pharmaceutical company ................................................. 5
Figure 7 – SAGE X3 Logo ..................................................................................................................................... 6
Figure 8 – ALCOA+ principles .............................................................................................................................. 9
Figure 9 – Gamp®5 Software Categories .......................................................................................................... 14
Figure 10 – V-Diagram for Validation of a Configured Product (Category 4) ................................................... 15
Figure 11 – Overview of a typical Quality Risk Management process ............................................................. 18
Figure 12 – Methodology of the dissertation ................................................................................................... 21
Figure 13 – Main ERP functionalities according to Labatec Farmacêutica SA processes ................................. 22
Figure 14 – Risk-based approach for CSV ......................................................................................................... 25
Figure 15 – Risk Class Assessment .................................................................................................................... 40
Figure 16 – Risk Priority Assessment ................................................................................................................ 41

VI
List of Tables

Table 1 – Regulations & Guidelines .................................................................................................................... 7

Table 2 – 21 CFR Part 11 and Annex 11: Comparisons ..................................................................................... 10
Table 3 - Summary of WLs related to CSV / Data Integrity between 2016 to 2018 ......................................... 11
Table 4 – Example of FDA Observations (483s) ................................................................................................ 12
Table 5 – Specifications..................................................................................................................................... 15
Table 6 – Qualification Activities ...................................................................................................................... 16
Table 7 – Scope of Application for System Testing Phases............................................................................... 16
Table 8 – Risk Analysis Methodologies ............................................................................................................. 20
Table 9 – Impact Assessment Result................................................................................................................. 23
Table 10 – Roles and Responsabilities for the validation of ERP System ......................................................... 26
Table 11 – DO and DONT’s when writing URS .................................................................................................. 27
Table 12 – URS reference for type of requirement .......................................................................................... 28
Table 13 – General Requirements .................................................................................................................... 29
Table 14 – URS for user Interface ..................................................................................................................... 29
Table 15 – URS for operation ............................................................................................................................ 30
Table 16 – URS for Access Control, Security & Safety ...................................................................................... 35
Table 17 – URS for data acquisition and recording .......................................................................................... 36
Table 18 – URS for Interfaces ........................................................................................................................... 37
Table 19 – URS for documentation and training .............................................................................................. 37
Table 20 – URS for maintenance ...................................................................................................................... 38
Table 21 – Risk Control Strategy ....................................................................................................................... 41
Table 22 – Risk Analysis Matrix ......................................................................................................................... 43

Table a-1 – Recommended Tests ...................................................................................................................... 61

Table a-2 – Example of FMEA template for FRA ............................................................................................... 63

VII
List of Abbreviations

API – Active Pharmaceutical Ingredient ICH – International Conference on

Harmonisation
BOM – Bill of Materials
IQ – Installation Qualification
cGxP – Current Good Practices
MRP – Material Resource Planning
CoA – Certificate of Analysis
NEG – Distribution Product
COTS – Commercially off-the-shelf
OQ – Operational Qualification
CS – Computerised System
PFI – Finished Product
CSV - Computerised System Validation
PIC/S - Pharmaceutical Inspection Co-operation
DQ – Design Qualification
Scheme

ERP – Enterprise Resource Planning

PQ – Performance Qualification

FDA – Food and Drug Administration

PSV – Bulk Product

FEFO - First Expire, First Out

QRM – Quality Risk Management

FIFO - First In, First Out

SOP – Standard Operational Procedure

FMEA – Failure Mode Effects Analysis

URS – User Requirements Specification

FRA – Functional Risk Assessment

VP – Validation Plan

GDocP – Good Documentation Practices

WHO – World Health Organization

GMP – Good Manufacturing Practices

WL – Warning Letter

GxP – Good Practices (where “x” stands for

Laboratory, Manufacturing, Documentation,
Distribution, etc.)

VIII
1. Introduction
In order to survive in highly competitive business environments, pharmaceutical companies have to
continuously improve their manufacturing and, equally important, their business processes 1. The evolution of
the markets and the need to reach the target public more quickly led to the development of global distribution
networks, product expansion, competitive sales conditions and the commitment of companies to meet the
individual needs of the customer. As a result, the improvement of business flexibility is fundamental for their
development and positioning in the market, as well as for the high level quality standards as a differential factor2.

Labatec Group

Figure 1 – Labatec logo3

Labatec (Figure 1) is a pharmaceutical group based in Geneva, Switzerland, founded in 1957, with over 50
years of experience in producing and distributing quality pharmaceutical products for the European and
emerging markets.
With the desire to increase production levels, Labatec group decided to proceed with an expansion project
leading to the implementation of the new pharmaceutical plant in Portugal (Labatec Farmacêutica S.A.) and thus
explore the possibility to increase its presence in the European market.
Currently, Labatec covers both the retail and hospital sectors and has a portfolio of approximately 65 products
with the ambition to continue to expand. Its portfolio consists on injectable and solid oral products with
application in multiple therapeutic areas, including anti-infectives, oncology, women’s health, between others.
The factory production consists of tablets and oral capsules3.
The geographical presence of Labatec in 2019 is shown in figure 2. Red represents its headquarters in Geneva,
Switzerland. In brown, are the offices for the Middle East and North Africa markets in Amman, Jordan and the
new pharmaceutical plant in Sintra, Portugal. The markets where Labatec’s medicines are present, including
Switzerland and Jordan, are represented in blue.

Figure 2 - Labatec geographic expansion3

1
 Objective
The objective of this dissertation is the development of a validation plan (VP) for an Enterprise Resource
Planning (ERP) for Labatec Farmacêutica S.A.
With the implementation of Labatec Farmacêutica S.A. in Portugal, there was the need to implement a
resource management system that could support all production and business-related processes for the new plant
and continue to manage those of the existing plant in Switzerland.
Therefore, in this phase of implementation of the ERP system, the validation activities were initiated in order
to ensure the quality and compliance of the system with the regulatory requirements for pharmaceutical industry
and according to the expected use for the system.
In order to understand the concepts of ERP, the validation of computerised systems (CS) and their importance
in relation to the regulations present in the pharmaceutical industry, a literature search was conducted to
support the case study presented in this dissertation.

Computerised System
In order to contextualize the components of a CS, it is important to enhance the concepts of software and
hardware. A software is defined as an organized information in the form of operating systems, utilities, programs,
and applications that enable computers to work. The hardware consists of the physical components that
constitute a computer on which the software is hosted4.
A CS comprises all the components of a specific system, including the software and hardware on which it is
installed (i.e. the computer system), the associated equipment (if applicable) and all external influences that
interfere with the CS in its operating environment (i.e. users, training, standard operating procedure (SOP) and
quality management of the system)5. Figure 3 schematically shows the hierarchical structure of the CS and its
components.

Figure 3 – Structure of a Computerised System in his Operating Environment

Adapted from PIC/S5

2
 1.3.1 Enterprise Resource Planning
In order to better understand the definition of an ERP system, it is necessary to start by defining and clarifying
two concepts: ERP software and ERP system. An ERP software is a commercially available packaged enterprise
computing software, that can be standard, configured or customized, with applicability in different areas such as
finance, supply chain, manufacturing management, quality, sales and marketing6.
An ERP system is a CS composed of an ERP software and all the necessary infrastructure for the software to
function properly: hardware, operating system, SOPs, users, database and network.
The main goal of an ERP system is to manage all the administrative and operational processes in order to
improve the organization, processes and flow of information within the company, leading to an increase of
productivity, quality and income6–8. Some benefits of its implementation are data organization, integration of
different areas and improvements in resource management6.

Evolution of ERP systems

The concept of a system that manages the business processes began to emerge in the 1960s, when the
priority of manufacturing companies was to manage their inventory using computerised technologies as a
solution to optimize the inventory management9,10.
In the 1970s, companies began to realize that maintaining large amounts of inventory represented a waste
of resources. This led to the introduction of material resource planning (MRP) systems, allowing companies to
use a master production schedule supported by a bill of materials (BOM) that identify the specific materials and
their quantities to perform a certain manufacturing operation. This allowed companies to start managing the
manufacturing process with manufacturing orders, creating a production priority mechanism that resulted in a
significant increase in productivity and process quality9,10.
Over the years, more features were included in the MRP systems, such as tools to manage sales and
production levels, forecasting, sales planning and customer-order. In the 1980s, companies began to take
advantage of the technology performance to incorporate financial accounting and management systems along
with the manufacturing and materials management systems. This incorporation enabled the integration of
different areas in the same business, resulting in the so-called MRP II9,10.
In the early 1990s, improvements were implemented which allowed MRP II to incorporate even more areas,
such as product design, warehouse management, materials planning, capacity planning, communication system,
human resources, and project management. Hence, the term ERP was introduced to enable this technology to
be used by any company that intends to increase its competitiveness and quality of processes 6,9–11.
Currently, the evolution of technology continued to change ERP in terms of architecture and services. The
goal now is for each ERP company to offer the best customer service in terms of system operability and service
conditions. Figure 4 summarizes the described evolution of ERP systems over the years.

3
 (2000-
ERP in Cloud 2010s)

ERP 1990's

MRP II 1980's

MRP 1970's
Inventory
Control 1960's

Figure 4 – Evolution of the Enterprise Resource Planning Systems

1.3.2 ERPs in the Pharmaceutical Industry

Nowadays, the pharmaceutical industry is facing numerous business challenges such as strict regulatory
demands, global competition, individualized products, product expanding, technological innovation, R&D
development and unpredictable market trends12. Consumers and producers are looking for healthcare products
with high quality at compelling prices, which propels pharma manufacturers and distributors to develop solutions
to reduce production cost and maximize organization and efficiency1,13–15.
The ERPs in the pharmaceutical industries have a wide applicability, supporting several processes and
allowing an effective management of the company's resources. These systems have several functionalities in the
form of modules that are implemented according to the needs of the user. The main activities that an ERP system
can address in a pharmaceutical industry are represented below9,16:

• Manufacturing: Trace the materials to be used in the process in a BOM, plan the manufacturing process,
product life cycle management and quality control;
• Inventory & Material Management: Control material wastage and monitoring inventory levels. This module
identifies material requirements for manufacturing process, creates triggers for procurement and replenishment
and formulates inventory status reports;
• Distribution management: Batch tracking module allows manufacturers to monitor a batch work-in-
process and delivery status remotely;
• Purchasing: Purchase of raw materials, placing orders with suppliers, billing and support for continuous and
integrated active processing of purchase orders and entry of goods receipts;
• Finance & Accounting: Analysis and reporting of financial transactions;
• Human Resources: This module organizes the payroll, the roster, recruiting and training;
• Customer Relationship Management: Customer and supplier service, sales and marketing.
• Sales & Marketing Management: This module enables contract management and sales order processing
instantly. It can be used to record customer records and history and to create automated marketing workflows.

4
 Figure 5 – ERP modules17

An ERP system in a manufacturing unit “works like the central nervous system in the human body”13 by
integrating several areas within a company as schematically represented in figure 6. This enables cooperation
between all departments, enhances transparency and improves the productivity of operations. These advantages
justify the increasing need for ERP systems in the pharmaceutical manufacturing industry.

Figure 6 – Relationship between areas in a general pharmaceutical company

Addapted from18

1.3.3 SAGE X3
SAGE X3 is the ERP implemented by Labatec Farmacêutica S.A. by strategic reasons, since this software is
already in use at Labatec Switzerland. SAGE X3 was developed by Adonix, an ERP software company founded by
Emile Hamou, in 1979 in Paris, France19. In 2005 the SAGE group acquired Adonix, including X3 in its portfolio.
Under Sage's ownership, the Sage X3 product (previously named Adonix X3) prospered with large investments in
user interface and other functionalities that enabled X3 to become the global ERP solution it is today19.
SAGE X3 is a standard, commercially available, configurable ERP software used to manage most of a
company's functions, for example purchasing, sales, production and quality. Is a highly recommended ERP with
multiple functionalities in different types of industries16,20.
Since the pharmaceutical industry is one of the most regulated industries, and the demand to validate the
CS, this option facilitates the process by offering features such as Audit Trail (i.e. a secure, computer generated,
chronologial record evidence of a sequence of activities that have affected at any time a specific operation),

5
Validation Scripts, Security Features (e.g.: automatic logoff after a period of inactivity, management of access
control), among others20.

Figure 7 – SAGE X3 Logo16

Computerised System Validation

Validation is the process of establishing documented evidence that an equipment/utility or system will
consistently produce a result that meets predetermined specifications and quality attributes 21.
CSs shall be validated in accordance with the principles of quality risk management and the validation shall
be prepared in accordance with the potential impact for the quality, the complexity and the intended use5,22.
Thus, systems that are considered to have an impact in the good practices (GxP) must be validated23,24. The
extension of the validation is defined according to the risk associated with the system22. Validation allows a better
understanding of the system, to exploit its full capabilities and to ensure that all necessary technical and
procedural controls are implemented in compliance with the applicable good practices, guidelines and
regulations21.

1.4.1 Regulatory Considerations

Several entities, such as EudraLex, World Health Organization (WHO), Pharmaceutical Inspection Co-
operation Scheme (PIC/S), International Conference on Harmonisation (ICH) among others, have published
guidelines with the objective of harmonizing the concepts and providing guidance to the industries implementing
quality processes. In order to understand the regulatory and industrial guidance rationale for the risk-based
approach outlined for the Computerised System Validation (CSV) in this dissertation, some sections of these
documents are cited in table 1.

6
 Table 1 – Regulations & Guidelines

Regulation or
Scope of the Document
Guideline

This document applies to all CSs used as part of regulated Good Manufacturing Practices
(GMP) activities. It defines what a computer system is, recommends how risk
management, validation and the operational phase of the system should be done.
EU GMP Annex 11:
“A computer system is a set of software and hardware components which together fulfill
Computerised
certain functionalities…The application should be validated”
Systems25
“As part of a risk management system, decisions on the extent of validation and data
integrity controls should be based on a justified and documented risk assessment of the
computerised system”.

This document describes the principles of qualification and validation. This annex refers
that “Computerised systems used for the manufacture of medicinal products should also
EU GMP Annex 15:
be validated according to the requirements of Annex 11”.
Qualification and
The definitions of User Requirements Specification (URS), Design Qualification (DQ),
Validation21
Installation Qualification (IQ), Operational Qualification (OQ), Performance Qualification
(PQ)) are defined in this annex.
This document presents guidelines for the validation of CS: “Computerized systems should
WHO Guidelines on
be validated in accordance with quality risk management principles and the level of
Validation:
validation should be commensurate to identified risks, complexity and intended use. This
Appendix 5 –
guide applies to systems used in GMP but may be extended to systems used in all good
Validation of
practice activities, as appropriate.”
Computerised
In this guideline different concepts related to computer systems are presented, and the
Systems24
qualification phases are defined.
“When electronic, photographic or other data processing systems are used instead of
EU Directive written documents, the manufacturer shall first validate the systems by showing that the
2003/94/EC (Good data will be appropriately stored during the anticipated period of storage. The
Manufacturing electronically stored data shall be protected, by methods such as duplication or back-up
Practice)26 and transfer on to another storage system, against loss or damage of data, and audit trails
shall be maintained.”

7
 Regulation or
Scope of the Document
Guideline
The U.S Food and Drug Administration (FDA) in the validation section recommends:
“… that your decision to validate computerized systems, and the extent of the validation,
21 CFR Part 11 – take into account the impact the systems have on your ability to meet predicate rule
Electronic Records requirements. You should also consider the impact those systems might have on the
& Electronic accuracy, reliability, integrity, availability, and authenticity of required records and
Signatures – Scope signatures” In this section the FDA adopts the same risk-based approach as EU Annex 11
and Application27 for the validation of computer systems: “… that you base your approach on a justified and
documented risk assessment and a determination of the potential of the system to affect
product quality and safety, and record integrity.“
21 CFR 820.70 – (i) Automated Processes: "When computers or automated data processing systems are
Quality System used as part of production or the quality system, the manufacturer shall validate computer
Regulation: Subpart software for its intended use according to an established protocol. All software changes
G - Production and shall be validated before approval and issuance. These validation activities and results shall
Process Controls28 be documented. “
ICH Q7 – Good The ICH Q7 refers the CSs in section 5.4, stating that:
Manufacturing “GMP related computerized systems should be validated. The depth and scope of
Practice guide for validation depends on the diversity, complexity and criticality of the computerized
active application.” “Appropriate installation qualification and operational qualification should
pharmaceutical demonstrate the suitability of computer hardware and software to perform assigned
ingredients23 tasks.”

This document provides recommendations and background information concerning

the implementation, operation and inspection of CS.
Section 4.3 refers that: “Commercial ‘off the shelf’, ‘standard’, or proprietary systems
can be particularly difficult to assess from a quality and performance point of view. For
GxP regulated applications it is essential for the regulated user to define a requirement
PIC/S – Good
specification prior to selection and to carry out a properly documented supplier assessment
Practices for
and risk analysis for the various system options.”
computerised
Section 5.2 refers that: “The business/GxP criticality and risks relating to the
systems in
application will determine the nature and extent of any assessment of suppliers and
regulated “GxP”
software products.”
environment5
Section 23.7 defines that “GxP critical computerised systems are those that can affect
product quality and patient safety, either directly (e.g. control systems) or the integrity of
product related information (e.g. data/information systems relating to coding,
randomization, distribution, product recalls, clinical measures, patient records, donation
sources, laboratory data, etc.).”

8
 Regulation or
Scope of the Document
Guideline
The GAMP®5 is a document that provides direction in applying different concepts in
the development, implementation, validation and maintenance of CS. This document
GAMP®522
presents a risk-based approach to software categorization, criticality of the system, to
define system risks and a validation strategy accordingly.

This research aims to introduce the concepts of CSV, risk management and to highlight their importance in
the pharmaceutical industry. As can be verified in Table 1, regulations and guidelines focus on risk management
methodologies in CSV and how the extent of validation should take into account the criticality of the system (i.e.
GxP Impact). Compliance with the requirements imposed by regulatory agencies is extremely important, and the
knowledge and application of these guides enable to attain the requirements demanded by these entities.

Good Documentation Practices and Data Integrity

As a regulatory requirement for CS, it is essential that there is an effective control and management of
documentation as it is a critical part of every system that is supported by GxP data and is related to the creation
of records within the organization5,29.
If a company wants to be compliant with the requirements of regulatory entities, evidence that the Good
Documentation Practices (GDocP) are followed is key. Good documentation is an integral part of the quality
assurance system. Data can be present in different formats, such as in paper or electronic (e.g.: ERP)30.
Amongst the aspects regulated by GxP guidance, those related to data should be a priority for a company.
Data integrity is defined as all the proceedings that enable the maintenance of, and the assurance of the accuracy
and consistency of data from initial generation, use, retention, archiving, retrieval and destruction 29. To comply
with the GDocP, it is required that the documentation follows the Data Integrity ALCOA+ principles29,31 (in Figure
8) to ensure reliability and integrity of information and data throughout all aspects of their lifecycle 29,32.

Figure 8 – ALCOA+ principles

Adapted from 31

9
 1.4.2 Regulatory Requirements
A risk-based approach is referenced in both FDA regulations 21 CFR Part 11 and EMA EU GMP guide Annex
11, as a useful resource for the current use of the CS as well as for its validation13.
Title 21, Part 11 of the FDA Code of Federal Regulations is a regulatory document for using electronic records
and electronic signatures. The code requires pharmaceutical companies, medicinal device manufacturers,
biotech companies and other FDA-regulated industries (except food manufacturers) to implement controls that
include audits, system validation and documentation33. This includes software and systems involved in
processing many forms of data as part of business operation and product development such as an ERP
system20,33.
EudraLex Annex 11 is a guideline that applies to all forms of CSs used as part of a GMP regulated activities.
This annex refers that when a CS replaces a manual operation, there must be no decrease in product quality,
process control or quality assurance, nor any increase in the risk in the process 25.
For companies to be compliant with this annex they must perform an appropriate validation to guarantee the
quality of its processes, considering the significance of the CS to be implemented, as is related to any GxP
regulated activities (e.g., GxP data management or batch release)25.
The main difference between these two documents is that while the scope of FDA Part 11 details more on
digital signatures, electronic records and CS that employ these features for regulated activities, EudraLex Annex
11 scope applies to all forms of CS used as part of GxP regulated activities and focus on a risk-based quality
management of the CS34. Together, they provide a robust and applicable guide to CSV activities that lead to
compliant practices in regard to regulatory and customer requirements35. A general comparison between the
two guides is summarized in table 2.
Table 2 – 21 CFR Part 11 and Annex 11: Comparisons 34

FDA CFR Part 11 EudraLex Annex 11

CSs as part of GMP-regulated activities.
Defines requirements for electronic records All CSs automating any regulated function,
Scope
and electronic signatures used in FDA creating, modifying, and maintaining electronic
regulated industries. records and managing electronic signatures
must be validated for its intended use.
Using electronic records and signatures in Risk-based quality management of
Focus
computer systems. computerised systems.
Electronic records and signatures must be as
trustworthy and reliable as paper records
Using a CS should ensure there is no decrease in
and handwritten signatures and be
quality, process control and quality assurance
Objective permanently linked to their respective
and there should be no increase in the overall
records.
risk.
These should include the time and date of
the activity and the signature of the user.

10
Warning Letters
FDA conducts inspections to regulated companies, and when FDA detects a failure during an inspection, an
observation in the form of warning letter (WL) is issued listing significant violations of current good practices
(cGxPs)36.
The observations made in the scope of an FDA inspection are referred to as 483s. "Inspection observations"
is a form used by the FDA to document and report non-conformities detected during inspections37.
This search of WLs38 is primarily intended to raise awareness of the importance of pharmaceutical companies
to comply with regulations and guidelines and to understand the position of regulators.
This section highlights some examples of WLs related to the validation and use of software and/or CS in the
pharmaceutical industry (Table 3), reinforcing the importance of the subject of this dissertation, issued between
2016 and 2018 and accessible in the FDA database39.

Table 3 - Summary of WLs related to CSV / Data Integrity between 2016 to 2018

2016 2017 2018

WLs 31 22 14

Failure to validate regulated software/system and/or have validation procedures.

Most frequently non-conformities committed

10 (32%) 6 (27%) 3 (21%)

Failure to ensure data integrity (data security, data manipulation, deletion, back-dating, audit
by pharmaceutical industries

trail, access levels, user management)

16 (52%) 14 (63%) 10 (72%)

Failure to control/use GxP related spreadsheets

2 (6%) 1 (5%) 1 (7%)

Failure to document the software version used

3 (10%) - -

Failure to follow change control process and document the adequacy of the tool used to transfer
software changes

- 1 (5%) -

11
 Table 4 presents some examples of WLs issued to pharmaceutical companies.

Table 4 – Example of FDA Observations (483s)

Examples of FDA 483s (2016-2018)

Ipca Laboratories Limited 29/01/201640

“Failure to have computerised systems with sufficient controls to prevent unauthorized access or changes
to data. Your firm relied on incomplete records to evaluate the quality of your drugs and to determine whether
your drugs conformed with established specifications and standards” … “We found that laboratory analysts
had PC administrator access that they utilized to manipulate raw data and test results.”
“We found that controls on your computerized chromatographic instrumentation were not adequate to
prevent analysts from manipulating processing parameters in order to obtain passing results. We also found
that your computerised systems lacked controls to prevent the backdating of test data. In addition to these
examples of computerised systems that permitted inappropriate manipulation of integration parameters and
backdating, our investigators also found several instances of computerized data systems that failed to prevent
the deletion of original injections.”
Bedfont Scientific, 04/02/2016 41
“Failure to ensure that when computers or automated data processing systems are used as part of
production or the quality system, the manufacturer shall validate computer software for its intended use
according to an established protocol, as required by 21 CFR 820.70(i). For example, your firm has not validated
the software, (b)(4), used to manage various activities such as complaints, Corrective actions, Preventive
action, repairs, servicing, internal and external audits, and warranty service. Your firm has been utilizing this
software since January 2011.”
Polydrug Laboratories Pvt. Ltd. 14/04/201642
“Failure of computerised systems to have sufficient controls to prevent unauthorized access or changes to
data. Your firm’s computer system for entering test results and storing certificates of analysis (CoA), which
document whether a drug meets specifications, does not have sufficient controls to prevent unauthorized
changes to a CoA after quality unit approval. A manager demonstrated for our investigator how results on an
already finalized CoA could be manipulated after the formal quality unit approval. Also, the quality unit’s
electronic signatures on these CoA were uncontrolled images of signatures rather than certificate-based
electronic signatures.”
F.P. Rubinstein Y Cia SR 05/05/201643
“Failure to validate computer software for its intended use according to an established protocol, when
computers or automated data processing systems are used as part of production or the quality system, as
required by 21 CFR 820.70(i). For example, your firm has not validated the following software used in its quality
system: a. (b)(4), used for complaint handling; b. (b)(4), used for complaint handling by your firm's sales force;
and c. (b)(4), used for data analysis.”

12
 Examples of FDA 483s (2016-2018)

USV Limited 10/03/201744

“Your firm failed to exercise appropriate controls over computer or related systems to assure that only
authorized personnel institute changes in master production and control records, or other records (21 CFR
211.68(b)). Your systems allowed operators to delete files. You had no procedure to control this practice or to
ensure a backup file was maintained. No restricted access to the microbial identification instrument. Further,
you lacked restricted access to the external hard drive used for backup of this instrument. All users could
delete or modify files.”
Dynavision International LLC 09/05/2017 45
“Failure to perform a risk analysis for the Dynavision D2 device, as required by 21 CFR 820.30.
Failure to establish and maintain adequate procedures for the identification, documentation, validation,
or where appropriate, verification, review, and approval of design changes before their implementation, as
required by 21 CFR 820.30(i). Specifically, the “VALIDATION AND CONTROL OF COMPUTER SOFTWARE”
procedure, #DYN-OP-VDC-01, dated 5/24/13, has not been implemented, and there is no validation for the
software revisions you have made to the Dynavision D2 since 2011.”
Becton Dickinson & Company 11/01/201846
“Failure to validate computer software for its intended use according to an established protocol when
computers or automated data processing systems are used as part of production or the quality system, as
required by 21 CFR 820.70(i). For example, during the inspection, your firm’s World Wide Vice President for
Quality Management explained that your firm has no written procedures for validating the use of (b)(4).”

1.4.3 Good Automated Manufacturing Practices (GAMP®5)

GAMP®5 “A Risk-Based Approach to Compliant GxP Computerised Systems”22 was published in 2008, and is a
guidance document which provides a framework for risk-based approach to CSV where the system and the extent
of the validation activities are defined according to the category of the software complexity. Categorizing the
software helps to guide the writing of the system documentation (including user requirements specification and
test scripts). Currently there are four categories (the second category has been discontinued in the new version
of GAMP®5).

Nature of the Software: GAMP®5 Software Categories 22

• Category 1: Infrastructure Software
This category includes the Infrastructure software tools (batch job scheduling, anti-virus) and established or
commercially available layered software (operating systems, databases managers…).
• Category 3: Non-Configured Products
This category includes commercially off-the-shelf (COTS) products used for business purposes, including the
systems that cannot be configured and systems that can have a simple configuration, but for which only one type
of default configuration is used. In such cases, and based on risk and supplier assessment, a simple one-step

13
testing approach is normally applicable. Tests usually check the correct installation, if the software meets the
fulfills the requirements and any further test derived from risk assessment. Depending on the complexity and
risk of the configurable COTS software in the business, can be included in category 4.
• Category 4: Configured Products
This category includes configurated COTS products which provide standard interfaces and functions that
allow modulation of the software to fulfill user-specific business processes. This typically involves simple
configuration of predefined software modules (i.e. configuration or parameterization) or a complex configuration
of the application (i.e. modification of the application source-code). The approach should reflect the result of the
supplier assessment, GxP impact, intended use and complexity. Strategies should be defined for mitigating any
identified risks.
• Category 5: Custom Applications
This category includes systems or subsystems that are developed to meet specific needs. The risk of these
customizable software is high.
The product lifecycle approach and validation activities should take into account this increased risk, since the
system was developed from the start, there is no prior knowledge about the functionalities and possible risks of
the system. The approach should address the software layers involved and their respective categories. It should
reflect the supplier's assessment and any audit observations, GxP impact, intended use, size and complexity.
Strategies for mitigating any identified risk should be defined.

GAMP standards have developed five (currently four) software categories (Figure 9) based on the level of
software complexity.

Figure 9 – Gamp®5 Software Categories22

According to GAMP®5 categorization, ERP configured software fits in the category 4. Therefore, it will be in
this category that this work will be focused on.
GAMP®5 approach can be summed up by a V-model diagram (Figure 10) according to the respective
category22. The diagram (category 4) places in juxtaposition the specifications produced for a system to the
testing performed as part of the qualification process.

14
 Figure 10 – V-Diagram for Validation of a Configured Product (Category 4)
Adapted from GAMP®522

The specifications produced for the system represent the configuration, including the settings and
parameters of the system, the functionalities and the requirements the users expect to be represented in the
system. The specifications and their definitions are represented in Table 5.
Table 5 – Specifications22

Specifications Description
Configuration Specifications may cover the configuration of the software products
Configuration that comprise the system. This includes the definition of all settings and parameters.
Specification These specifications are often developed by the supplier and reviewed, tested and
approved by the validation team of the user company.
Functional Specifications are usually developed by the supplier and describe the
detailed functions of the system, i.e. what and how the system will do to fulfill the
Functional
business requirements. The user company must review, test and approve the
Specification
Functional Specifications. These specifications are often referred to as a contract
document.
Requirement Specifications are developed by the user company and should cover
User Requirements all the requirements the users expect to be represented in the system. These
Specification requirements should be developed considering the intended use and the
compliance with the applicable regulations.

1.4.4 Qualification Activities

Qualification is described as the action of assuring that a certain equipment/utility or system works as
intended and lead to the expected results. The different qualification phases address the testing of a component
or function of the system to be validated against a specific outcome21,25.
Qualification activities should consider all stages from initial development of the user requirements
specification to the discontinuation of the system21,25. The main phases of the qualification process and their
definitions, according to Eudralex is represented in Table 6.

15
 Table 6 – Qualification Activities

Qualification Description21,25
Documented verification that all documented specifications suggested for the
Design Qualification system by the supplier are verified and compared with the URS, guaranteeing that
the system is suitable for the intended purpose.
Installation Documented verification that the system is installed according to pre-approved
Qualification specifications.
Operational Documented verification that the system operates according to pre-approved
Qualification specifications and within the specified operating ranges.
Documented verification that the system is capable of performing the activities of
Performance
the processes it is intended to perform, according to pre-approved specifications,
Qualification
within the scope of the business process and operating environment.
Lifecycle overview of the system to ensure that qualification status is maintained. If
Requalification such a change has a significant impact, a requalification shall be performed to
confirm that the CS remains in a state of control.

1.4.5 System Testing

The pharmaceutical industrial policies and strict regulations require that systems are developed, documented
and tested following the different GxP’s47,48.
The software products, such as ERP software that are described within the scope of this dissertation, are
usually classified as GAMP Category 4 (products configured for a specific business process). For the ERP according
to the “GAMP Good Practice Guide: Testing GxP Systems” a testing approach based on configuration verification,
functionality and performance test is applicable (Table 7).

Table 7 – Scope of Application for System Testing Phases

Qualification
Test Phase Scope of Application
Phase

Verification of configuration against the configuration specifications. These

tests are intended to verify the correct installation of49:
• Hardware and software installation (if applicable);
• Interface connections (e.g.: printers);
Installation Configuration • Software backup functionality;
Qualification Verification
• Safety and Security features (e.g. Audit trail functionality);
• Access levels definitions (including profile levels and functions);
• Availability of Supplier documentation, prints, drawings and manuals;
• Availability of Software and hardware documentation.

16
 Qualification
Test Phase Scope of Application
Phase
Verification of functional elements and ensure that the system meets all user-
defined requirements under all approved conditions by conducting user
acceptance tests. These tests are intended to force the system into extreme
and stressful conditions and are aimed to check49:
• Invalid values and inputs;

Operational Functional • System functionalities;

Qualification Test • Error messages;
• Functional and data validity;
• Transactions validity;
• Availability of SOPs for maintenance, backup and restore, user
operation, system security…;
• Training in system operation (e.g.: training in applicable procedures).
This phase of testing is intended to demonstrate that the system will
consistently produce an acceptable output under normal operating
conditions. These tests should cover50:
• Use of actual computerised parameters and procedures established in
OQ and used during in operation;
• Reconfirm acceptability of the computerised processes as established in

Performance Performance OQ;

Qualification Test • Reconfirm process repeatability and assure process stability when used
in the field with trained operators;
• Data conversion and migration to the new platform;
• Simulate conditions that will be encountered during routine operation;
• Include the ranges of conditions covered by the SOPs;
• Repeat tests enough times to assure that the results are meaningful and
consistent;
*DQ also considered in GAMP®5 as Design Review phase consists of the revision of the specifications and
documentation associated with the development of the software design. As the ERP is a configured software,
this qualification phase does not apply once Design Review activities are usually performed by the developer
during the development of the product. This should be verified during supplier assessment. Design Reviews
typically are conducted for customized applications to a level of detail of specification, i.e for customizations that
involves changes to standard features such as the creation of software's programming code22.

The scope and extension of testing should be determined by a justified and documented risk assessment,
taking into account both the potential effect on good practices and the complexity of the system. These tests
should be considered when conducting the assessment of the system functionalities (i.e. Functional Risk

17
Assessment (FRA)), and it is suitable to conduct the test at the most appropriate qualification phase22 (the
categories of the tests to perform are described in detail in Annex #1).

Acceptance Criteria
The result of each test is compared to the respective acceptance criteria defined in each qualification phase
to determine whether the result meets the criteria with no deviations. Final test results should be documented
as passed, not applicable, or failed.
• Passed – the test result meets the acceptance criteria, without any deviations with impact.
• Failed - the test result does not meet the acceptance criteria. The results of these tests must be resolved
before an overall conclusion can be made about the validation of the system.
• Not Applicable - it is not necessary to test the functionality in question and document the justification (e.g.
functionalities without any GxP impact).

Quality Risk Management

The introduction of any large-scale integrated information system (i.e. ERP) can lead to significant changes in
processes, tasks and people-related issues51–53. The possibility of risks in the implementation and operation of
the system leads to the deployment of risk management approaches during the system lifecycle54. Application
of risk management focuses on critical aspects of CS in a controlled and justified approach. It is important to
understand the concepts of risk management as it is the basis for an efficient risk-based validation.
ICH Q9 recommends55 that a quality risk management (QRM) should include systematic processes (Figure 11)
designed to coordinate, facilitate and improve decision-making according to the risk.

Figure 11 – Overview of a typical Quality Risk Management process55

18
 There are some necessary steps in order to initiate and plan a QRM process such as:
• Define the problem and/or risk question identifying the potential for risk;
• Assemble background information and/or data relevant to the risk assessment.
The second step of a QMR process is a risk assessment to identify hazards and evaluate the risks associated
with exposure to those hazards. In ICH Q9 there are three questions that help identify (what might go wrong?),
analyze (what is the likelihood it will go wrong?) and evaluate (what are the consequences?) the risk 55.
The third step is risk control, which aim on decision-making to reduce the risk to an acceptable level and/or
accept the risk. Risk reduction focuses on the mitigation or avoidance of the severity and probability of harm.
Risk acceptance is applied when the risk has no effect on quality and in the cases QRM practices might not entirely
eliminate the risk55.
The output/result of the QRM should be appropriately communicated and documented among involved
areas (e.g., regulators/regulatory entity and industry, industry and the patient or within the company). This
sharing of information about risk and risk management is defined as risk communication 55. The company must
include in their QRM a mechanism to risk review or monitor events to gain new knowledge and experience that
might redefine the previous risk acceptance decisions55.
Pharmaceutical industry and regulators can assess and manage risk using internal procedures (i.e., SOPs) and
with recognized and recommended risk management tools such as those referred to in table 855,56.

19
 Table 8 – Risk Analysis Methodologies

Risk Analysis
Functionality Applicability to CSV57
Methodology
Hazard Analysis Limited use since this methodology implies a
Analyze, evaluate, prevent, and
and Critical knowledge of the critical points of the system,
control the risk or the adverse
Control Points which is not always available (documentation or
hazard consequences.
(HACCP) source code) in many commercial applications.
Hazard One of the success factors of this methodology is
Uses guide words to structure the
Operability the completeness and accuracy of the system
evaluation of process safety
Analysis specification documentation, therefore, its use is
hazards.
(HazOp) limited to configured or customized CS.
Identification of real or potential Top-down structured failure analysis, deductive to
Fault Tree
problems displaying the results as a identify the causes/modes of failure and how their
Analysis
tree of faults with the failure may have been caused.
(FTA)
corresponding failure mode. Little application for CSV.
Uses previous experience or
Preliminary Conducted at the beginning of a new project when
knowledge of hazards and failures
Hazard Analysis information of similar projects is available;
to identify future ones and estimate
(PHA) Little application for CSV of new systems.
their probability of occurrence.

Failure Mode
Effects Analysis
Methodologies well established and highly
(FMEA) Evaluation of failure modes and
recommended in pharmaceutical industry;
Failure Mode, their potential outcomes.
Methodology recommended (FMEA) by GAMP®5
Effects and Classify the risk.
(Appendix M3 of GAMP);
Criticality Identify mitigation measures.
Suitable for CSV (GAMP Category 4 and 5).
Analysis
(FMECA)

20
2. Methodology followed in the dissertation
The methodology adopted for this dissertation consisted mainly of three stages, which are related to the
theme addressed in this work and are illustrated in figure 12:

Definition of system Functional Risk

System characterization

System assessment
ERP systems
Literature review

functionalities Assessment
Computerised System
Validation GxP Impact Assessment
Guidelines & User Requirements
Regulations specification
Warning Letters

Figure 12 – Methodology of the dissertation

This work was based on a literature review, which intended to contextualize the concepts of this subject,
highlighting the importance of regulations in the pharmaceutical industry.
An analysis of the system's functionalities was performed in order to assess the various processes that the
system will support, in conjunction with the different user areas of Labatec Farmacêutica S.A followed by a GxP
impact analysis. The URS for the ERP were defined according to a developed methodology.
Lastly, a validation plan was developed following a risk-based approach, employing a risk analysis
methodology (FMEA) to identify and evaluate risks in order to plan the qualification activities to be applied to
the ERP SAGE X3 system.

21
3. Case Study: Planning of the ERP System Validation in Labatec Farmacêutica S.A.
ERP in Labatec Farmacêutica S.A.
The selection of an ERP the Labatec Farmacêutica S.A project arose from the desire to implement a system
that covers all the business and manufacturing needs.
An initial study of the ERP already implemented in Swiss facility (SAGE X3) was performed in order to
understand which system functionalities were being used to support the processes. For this purpose, an
assessment of the operating procedures was done and possible improvements that were not being explored
were evaluated.
Along with the relevant user areas, the ERP main functions were defined (figure 13), and the processes where
it could be applied were identified. Thus, it was possible to establish a rationale for the development of the URS.

Figure 13 – Main ERP functionalities according to Labatec Farmacêutica S.A. processes

22
 System Impact Assessment
Once the system is identified and their functions determined, the impact of the system on product quality
and in the applicable good practices was assessed58. This assessment should categorize whether the system has
direct impact, indirect impact or no impact.
In order to determine if the ERP system should be subjected to validation, a methodology to document the
rationale for the GxP impact assessment was developed and performed, as represented in Table 9.
Table 9 – Impact Assessment Result

Computerised System Name Enterprise Resource Planning

Assessment YES NO

No. (A) Intended use

The system is used to create, to control, to modify purchase or receipt data of material
1 classified as GxP (i.e. supplier/manufacturer approved, name, code, concentration, X
specification)?
The system is used to create, to control or to modify the batches identification (i.e.
2 X
item code, batch number, quantities, measures units, conversion factors and etc)?
The system is used to create, to control, to modify or to store information used in a
3 production or packaging process (i.e. formulas, batch status for release, equipment X
status, packaging material status, raw material status, tests specification)?
The system is used to create, to store data or is used for Quality Control activities
4 X
(tests, analysis, analysis methods) for the manufacturing or packaging process?
The system is used to control the warehouse or the distribution activities with GxP
5 impact or is used to store information about batch distribution than can be used in X
Recalls?
The system supports the maintenance of instruments/equipment considered critical
6 X
(i.e. calibration, preventive maintenance)
The system supports, stores or changes product data or reports used by Quality
7 X
Assurance to make decision about processes approvals?
8 The system is used for batch record or batch approval? X

9 Does the system manage critical manufacturing control parameters? X

10 Does the system manage controlled documents? X

23
 Assessment YES NO
No. (B) User Area

1 Quality Control X

2 Quality Assurance X

3 Maintenance X

4 Production X

5 Warehouse X

6 Finances X
7 Other: _______________________________________________________________ X
No. (C) GAMP®5 Software Category

1 Category 1- Infrastructure Software X

2 Category 3 – Non-Configured Products X

3 Category 4 – Configured Products X

4 Category 5 – Custom Applications X

No. (D) Associated Infrastructure

1 Hosted in a hardware computer system. X

2 Hosted in a web-cloud infrastructure. X

3 Other: _______________________________________________________________ X
GxP Impact Assessment Result
[ X ] Direct Impact [ ] Indirect Impact [ ] No impact
Required documents/activities:
[ X ] User Requirements Specifications [ X ] Installation Qualification
[ X ] Functional Risk Assessment [ X ] Operational Qualification
[ ] Design Qualification [ X ] Performance Qualification
[ ] The system do not need to be qualified [ X ] Final Validation Report
Comments:
Since the system is already implemented at Swiss Labatec, and the intended ERP is a configurable
commercially available standard software, Design Qualifiction may be omitted as the Installation
Qualification, Operational Qualification and Performance Qualification may be a sufficient indicator of its
suitability.

This assessment was conducted by a multi-disciplinary team consisting of representatives of Quality

assurance, Validation and IT supplier. Considering the intended use for the software, the user areas and the
functions related to GxP activities, the system was categorized as a direct impact system considering the
affirmative answers in the field A. Validation was planned according to the impact of the system and a risk-based
approach strategy was developed.

24
 Validation Plan
The VP should consider the main potential risks, and according to the identified risks, establish a methodology
that ensures that the system operates in a controlled manner and that will always produce the expected results.
A risk-based validation strategy was developed with the objective of making validation more appropriate and
targeted. By identifying possible failures, performing risk analysis and developing controls to mitigate them, the
validation team is able to control the risks more effectively.
In the following flowchart (figure 14) is represented a risk-based approach outlined for this work in order to
plan the validation activities for the ERP System, developed in accordance with the principles established in
GAMP®5, ICH Q9 and other applicable guidelines.

Figure 14 – Risk-based approach for CSV

25
Roles and Responsibilities
The activities for the validation of ERP system in Labatec Farmacêutica S.A., will be conducted by a specialized
team containing elements of the production, warehouse, quality and validation areas. Represented in table 10
are the different roles and responsibilities of each area.

Table 10 – Roles and Responsibilities for the validation of ERP System

Roles Description of Activities

• Define the requirements for the functionalities of the system;
User Area
• Participate in risk analysis when necessary.
• Identify and analyze carefully the risks identified;
• Develop controls and measures to manage risks;
Validation Team
• Carry out the appropriate tests in the System;
• Write, review and approve the validation documentation.
• Initiate the Change Control to start the validation;
• Evaluate deviations that may arise during system validation;
Quality Assurance
• Identify, analyze and assess the risks associated with regulatory requirements;
• Manage risks as per internal SOP’s.
• Make available, whenever required, all information and documents related to the CS,
Supplier such as user manuals, configuration and functional specifications;
• Provide the necessary support and control in deviation investigations.

26
 Development of the User Requirement Specifications
URS should describe the required functions of the CS and be based on a the GxP impact and applicable
regulations. User requirements should be traceable throughout the lifecycle. The URS should be written in a way
to ensure that the requirements are understood by the system developer and reliably represent the intended
functions.
URS is a key document where all the risk management and validation activities will be supported. The URS
must be clear, concise, testable, comprehensive and categorized. They should reflect specifications and not
design solutions.
In Table 11 are some recommendations to consider when writing URS.

Table 11 – DO and DONT’s when writing URS

DO DON’Ts
Working in conjunction with the validation team, the
Avoid the use of vague requirements such as "must
VP should be planned concurrently with the
be 21 CFR Part 11, Annex 11 or GMP compliant"59.
development of the URS59.
Each requirement must be realistic, complete, unique Points should not be listed in the URS indicating that
(to avoid conflicts between requirements) and must “the system should be compliant with the
be objectively verifiable by an authorized method, regulations”, but rather it should be designed in such
e.g. inspection, analysis or test5. a way that it complies with the regulations.
Shall be written in a suitable manner so that data will
meet regulatory requirements, as well as the WHO
Avoid issuing URS without prior knowledge of the
Guidance on Good Data and Record Management
functions of the system and its applicability to the
Practices 24.
business. The quality of the system is defined at this
The URS should be understood and approved by both
point, if certain requirements are not considered, the
user and supplier as these demonstrate the intention
system may be compromised in the following stages.
of how the system should be provided by the
supplier.

At Labatec Farmacêutica S.A. the URS were coded according to their category in order to facilitate their
identification and allow a better interpretation of the requirements. Thus, the coding of the URS consisted of the
criteria: AAA_XXX.
Where:
AAA – Is the reference of the type of requirement as describe on Table 12.
XXX – is a three-digit sequential number starting from 001.

27
 Table 12 – URS reference for type of requirement

Reference Category Name

GEN_XXX General Requirements
VIS_XXX User Interface (Visualization)
OPE_XXX Operation of the System
SEC_XXX Access Control, Security & Safety
REC_XXX Data acquisition and recording
INT_XXX Interface
DOC_XXX Documentation and training
MNT_XXX Maintenance

In order to establish the importance of the requirements according to the needs of the user, and in order to
assist in the selection of the supplier, the requirements were prioritized into mandatory (M) or desirable (D).
A mandatory requirement is essential to be present in the system to ensure its functions operability and to
ensure compliance with the regulatory requirements and applicable guidelines.
A desirable requirement is a "nice to have" or a custom function that does not need to be present for the
system to operate as intended.
The requirements were defined during a meeting with all relevant user areas, where all the requirements
that each area wanted to have in the system and how these requirements will support the business operations
were discussed.
It is important for all members present at the meeting to have a prior knowledge of the functionalities of the
system to be implemented, reason why a previous mapping of the functions already running in Switzerland ERP
system has been executed.
All applicable and required GxP specifications (such as data integrity, access control or audit trail) were
included, among others required by the user departments and Quality Assurance.
The user requirements developed for the ERP system in Labatec Farmacêutica are represented in tables 13
to 20. Based on the developed URS, the ERP selected was SAGE X3.

28
 Table 13 – General Requirements

Priority
Nr. Requirement
(M/D)
GEN_001 Graphical interface must be user-friendly D
GEN_002 The language of the system should be English and Portuguese. M
GEN_003 The system should be supported on a Windows 10 computer or other similar versions. M
GEN_004 The system should be available as a web-based and allow access through a web browser
M
(such as Google Chrome, Internet Explorer or similar browser).
GEN_005 The system should be able to operate in different platforms such as, computer, tablets
D
and smartphones.

Table 14 – URS for user Interface

Priority
Nr. Requirement
(M/D)
The system should allow to visualize and trace customers information, such as, name,
VIS_001 M
address, phone number and/or fax/e-mail.

VIS_002 The system should be able to allow traceability of batches. M

The system should allow to trace full reconciliation for products &/or batches involved
within the recall from stored information stored such as date of receipt, shipper, internal
VIS_003 article code, product name, batch number, manufacturing date, expiry date, quantity M
recalled per batch, quantity released per batch, release date, distribution start date,
distribution end date, quantity consumed on the market.
VIS_004 The system should allow the visualization of an updated inventory of all articles. M
The system should allow the visualization of a stock of articles (materials, products,
VIS_005 M
consumables, etc.).
The system should allow simple visualization of the stocks of an item per storage
VIS_006 M
location.
The system must allow the visualization of movements, article code, date and storage
VIS_007 M
location of articles.
The system should allow the visualization the articles according to First Expire First Out
VIS_008 M
(FEFO) and First In First Out (FIFO).
The system should allow the visualization and analysis of movements between storage
VIS_009 M
locations.
VIS_010 The system should allow visualization by storage location. M
The system should allow the visualization of all the orders (work orders, purchase
VIS_011 M
orders…), and select by status of approval, article code or date.

29
 Priority
Nr. Requirement
(M/D)
The system should allow the visualization and printing of the consumption per
VIS_012 M
production/packaging order.
VIS_013 The system should allow the visualization of the consumption by bottom up and down. D
The system should allow the visualization of a summary per item with description,
VIS_014 D
vendor, and cost (last cost, average cost).
VIS_015 The system should provide a forecast by item (article) M
VIS_016 The system should provide a list of existing batches (Stock Batch) M
VIS_017 The system should allow the visualization of production debits M
VIS_018 The system should allow the visualization of debits from production per operation M
The system should allow the visualization of the monthly movements and status
VIS_019 D
changes.
VIS_020 The system should allow to visualize a history of all batch and article movements. M
VIS_021 The system should allow the visualization of a list of daily movements D
VIS_022 The system should allow the visualization of the registration of returns to the supplier M
VIS_023 The system should allow the visualization of the supplier purchasing values D
The system should allow the visualization of the status of the batches / articles (such as
VIS_024 product bulk, raw material, packaging material, finished product) with the status of M
approved, rejected, re-analyzed, re-analyzed for shelf life, quarantined)
The system should issue a warning within a defined time of an article expiring its shelf
VIS_025 D
life.
The system should allow to issue a list with the articles approaching the end of their shelf
VIS_026 M
life.
VIS_027 The system should issue an alert when there is an article stock shortage; D

Table 15 – URS for operation

Priority
Nr. Requirement
(M/D)
The system must assign an article code to the article when there is a new entry
OPE_001 according with a predefined rule (e.g., XXXYYYY) where XXX is the category of the article M
and YYYY is a sequential number.
The system should be able to characterize the articles according to their scope (GxP
scope: raw materials, packaging materials, consumables, bulk product, finished product
OPE_002 M
manufactured, semi finish product, samples, or only distributed) or non GxP scope
(office material)).

30
 Priority
Nr. Requirement
(M/D)

The system should be able to assign a code by product category (e.g., Active
OPE_003 M
Pharmaceutical Ingredient (API), Distribution product (NEG), Finished Product (PFI),
Semi-packaged Product - PSC, Bulk Product (PSV)
The system should allow the introduction of specifications for each new article (such as
OPE_004 code, name, date, quantity, shelf-life, storage and security conditions, retest date, M
effectivity date, potency, and other relevant information).
The system should allow that each article code have a unique code linked to a supplier
OPE_005 M
and to a manufacturer.
The system should allow to set different status to the article code, such as active, in
OPE_006 M
development, not usable, not renewed, obsolete, shortage.
The system should allow to set a batch number, sequential and unique per each code
article according with a predefined rule (e.g., YYXXXX) where YY is the current year of
OPE_007 M
the manufactured batch and XXXX is a sequential number or in a manual way (for
external batches)
The system should allow to enter manually an expiry date and manufacturing date per
OPE_008 M
each article code.
The system should generate an expiry date for each batch generated. It shall add a
OPE_009 M
predefined shelf life as defined in the article from the date of manufacture.
The system should generate an expiry date for PFI according to the PSV worst case
OPE_010 M
(shorter validity).
The system should generate an expiry date for certain articles according to their
OPE_011 M
category specifications (e.g, packaging material).
The system should allow to set different status to supplier / clients, such as approved,
OPE_012 M
qualified or disqualified and in process.
The system should allow to trace some information for the supplier / manufacturer,
OPE_013 M
such as address, qualification status, contact, lead time.
The system should only allow the use of qualified suppliers (such as issue purchase
OPE_014 M
orders) and approved clients (such as accept orders).
The system should allow the entry of different status such as for destruction ("R" for
OPE_015 Rejected) and the motive (e.g. expired); In case of approved or restocking of incoming M
materials in the ERP (status "A" for Accepted).
The system should allow the returned product to be received in “Q” for Quarantine
OPE_016 M
status.
The system should allow to update the status of a batch number for “R” - rejected after
OPE_017 M
reaching the expire date.

31
 Priority
Nr. Requirement
(M/D)
OPE_018 The system must manage the articles stock according to FEFO and FIFO. D
The system should allow to change the status assign to a batch number only to users
OPE_019 M
with authorized profile.
The system should allow the correction of data according to the designed profiles/
OPE_020 M
access privileges and the change must be justified.
The system should allow only the users with a restricted privilege profile (high-level
profile) to change locations, quantities and release operations for article codes
OPE_021 M
identified as products like narcotic, cold chamber, falsified medicines and with special
conditions for storage and handling.
The system should allow a differentiated flow for returned product that requires an
OPE_022 additional approval of Quality Assurance/Qualified Person to be re-integrated on the D
stock.
The system should allow to configurate displays with selected information to be printed
OPE_023 M
on labels including barcodes and numbering.
The system should allow stock inventory and adjustments on locations and quantities
OPE_024 M
by designed profiles/ access privileges.
The system should have a stock management function according to diverse categories
OPE_025 M
of material management (list of articles for analysis and analyzed)
The system should allow the creation of an inventory of the materials and products used
OPE_026 M
in manufacturing and distribution activities.
OPE_027 The system should restrict the correction of quantities for Finished product on A status. M
The system should allow the requisition of reference and retest samples with assigned
OPE_028 D
location with a field to justify
The system should allow to configurate based on specific information the creation,
OPE_029 D
visualization and printing of a sampling Plan with the articles and quantities to analyze.
The system should allow the requisition and traceability of medical samples with a field
OPE_030 D
to justify.
The system should request the status approval for Launched production order and BOM
OPE_031 M
receipt before it goes to active status.
The system should allow to request a retest date and a expire date for articles codes
OPE_032 M
related to raw materials
The system should allow the creation of storage area locations with specifications (ex:
OPE_033 D
warehouse, pharmacotheque, intermediate zone between production and warehouse)
The system should allow the creation of storage locations according to a predefined
OPE_034 M
code.

32
 Priority
Nr. Requirement
(M/D)
The system should be able to enter detailed specifications of storage locations (narcotic,
OPE_035 M
cold chamber, special conditions, falsified products and others).
The system should allocate articles according to their specifications in the respective
OPE_036 D
storage location.
The system must allow the reversal of a material receipt and to be recorded in an audit
OPE_037 M
trail.
The system must allow the reversal/correction of quantities of articles and to be
OPE_038 M
recorded in an audit trail.
The system must allow transfer of articles between different storage locations (material
OPE_039 to be destroyed, exits of material that does not follow the normal path, returns, etc.) D
according to the authorization of the user.
OPE_040 The system should be able to print transfer orders. M
The system should allow transfer of articles between production, laboratory and
OPE_041 M
warehouse locations.
The system must allow the printing of labels of the identification of the material
OPE_042 M
volumes with a barcode and numbered.
The system shall allow the reprinting of labels of the identification of material volumes
OPE_043 with a barcode and numbered, depending on the access level, indicating that it is a M
reprint.
The system should allow the reversal of a movement between storage/other locations
OPE_044 M
and to be recorded in an audit trail.
The system should automatically issue an inspection plan and sampling plan when a
OPE_045 D
material receipt is made.
According to the result of the inspection plan the system should constrain the
OPE_046 D
movement of the article.
The system shall automatically print out the inspection plan and sampling plan when a
OPE_047 D
new inspection lot is opened.
The system shall automatically print the labels of the respective sampling plan
OPE_048 D
numbered.
The system must block quarantined items (“Q”) to be moved to other locations such as
OPE_049 M
production locations.
OPE_050 The system should automatically block selected articles in inventory. M
The system should be able to print transport guides and export labels according to the
OPE_051 D
product information.

33
 Priority
Nr. Requirement
(M/D)
The system shall communicate with the weighing area by transferring the
OPE_052 D
requirements/batch to be weighed associated with the production order number.
The system should receive the information from the scales terminal whenever each raw
OPE_053 D
material reaches the need value.
The system should allow the creation of suggestion orders - WOS, planned orders - WOP
OPE_054 M
and firm order - WOF.
The system must control when creating a manufacturing order, all raw materials used
OPE_055 M
in the manufacturing order are in status A and have valid shelf life.
OPE_056 The system must allocate the dispatched items to the production/packaging order. M
The system must allow the consumption of materials in each production/packaging
OPE_057 order and to change the quantities in case of returns (material reintegration in the M
order).
The system must allow the following phase time to be inserted in each
OPE_058 D
production/packaging order.
The system should be able to record the recipe name, all machine including the auxiliary
OPE_059 D
equipment and production timings for each batch/manufacturing order.
The BOM must perform the potency correction according to the article information (i.e.
OPE_060 D
API information).
OPE_061 The system should block the consumption of materials that are not defined in the BOM. D
The system shall allow the quantity of finished product to be entered in each
OPE_062 M
production/packaging order.
The system shall allow the quantity of finished product to be corrected before its final
OPE_063 M
approval.
The system must allow the correction of consumption before the order is financially
OPE_064 M
closed.
The system shall allow the printing of pallet labels according to the product information
OPE_065 M
in the system, barcode and numbered.
The system should block the consume material that does not belong to the respective
OPE_066 D
order.
OPE_067 The system should be able to manage customer returns; D
OPE_068 The system should record supplier and customer master data; D
OPE_069 The system should be able to print on-screen data to the printer; D

34
 Table 16 – URS for Access Control, Security & Safety

Priority
Nr. Requirement
(M/D)
SEC_001 System access via authorized user ID and password. M
SEC_002 The system must have a hierarchical access control. M
The system should allow to set differentiate levels of access within the system. Upon
SEC_003 to request to the administrator access to specific functions or modules should be M
attributed.
The system should allow to have a basic user profile only to consult the modules but
SEC_004 M
without any possibility to enter data, delete or modify data.
The system should allow to create unique users identified by a username and
SEC_005 M
password.
The system should allow to have an unlimited number of user accounts and access
SEC_006 M
profiles.
The system must support access at least to 6 user accounts at the same time in the
SEC_007 M
system.
SEC_008 The system must ensure uniqueness in the usernames. M
The system must require passwords to have complexity requirements such as
SEC_009 minimum of characters, not contain the user’s account name, uppercase and M
lowercase letters and non-alphanumeric characters.
The system must require the user to change his password within a period of time
SEC_010 M
defined in internal company procedure.
The system must lock the user account if an incorrect password is entered three
SEC_011 M
consecutive times.
The system must have an administration user level that is able to create users, delete
SEC_012 M
users and unlock user accounts.
SEC_013 The system should record accesses and report attempted entries; M
SEC_014 The system should link the audit trail with the user that have made the change. M
SEC_015 The user identification on the audit trail should be unique and unmistakable. M
SEC_016 The system must be able to perform periodic and robust back-ups of data. M
SEC_017 The system should archive all data when is no longer needed; M
SEC_018 The system should be able to perform data migration; D
SEC_019 The system should have an anti-virus protection mechanism deployed; D
SEC_020 The system should include automatic logoff after a period of inactivity of 10 minutes; D
The system must have safety measures for data security and ensure that information
SEC_021 M
remains confidential;

35
 Table 17 – URS for data acquisition and recording

Priority
Nr. Requirement
(M/D)
The system should allow extracting a comprehensive audit trail with first entry, new
REC_001 M
entry, date and author of the change.
The system must generate an automatic audit trail of any modification, creation or
REC_002 M
deletion on GxP data.
REC_003 The system should not allow the users to disable the audit trail function. M
The system must ensure that audit trail records are read only, and not editable,
REC_004 M
protected from accidental or intentional deletion or modification.
REC_005 The system should allow viewing and exporting selected parts of the audit trail. M
The system should allow to extract list to an industry standard formats like Adobe
REC_006 M
PDF and XML in a human readable format.
REC_007 The system must prevent modification of validated documents. M
The system should allow to do an inventory with a list of article codes and batches
in stock, their location and status, receipt date, expire date should be extracted from
REC_008 M
the system to an industry standard formats like Adobe PDF and XML in a human
readable format.
The system should generate Date and hour in a consistent in all documentation
generated by the system.
REC_009 M
Date format must be Day Month Year “DD MM YYYY”.
Hour format must be Hour Minute “HH:MM”.

The system should record every activity with the real date and time expressed in
REC_010 M
hour & minutes with the user ID of the person who was logged on to the system;

REC_011 The system should record article (product) master data in the format of a BOM. M

The system should have a MRP system for warning and/or (semi)automatic
REC_012 D
generation of purchase orders.
REC_013 The system should issue alerts to email address or in a dashboard as requested; D
The system should be able to create and approve purchase orders according to the
REC_014 M
data in the system;

REC_015 The system should be able to create a customer order; M

Creation of work centers for each manufacturing room/process to build product

REC_016 D
receipt associated to the BOM (with setup time and production time)

REC_017 The system should have an editable planning scheme for different work centers. D

36
 Priority
Nr. Requirement
(M/D)
The system should record crucial information like manufacturing date, final bulk
expiry date and storage conditions, and if exists the same information for production
REC_018 M
in process should be associated with the bulk product code and printed in the order.
The same with routine sampling.
Existence of a system location exclusive for delivery of finish bulk batches prior to
REC_019 D
packaging that finishes the process
Existence of a system location for bulk packaging materials for the consumption
REC_020 D
batch by batch
The system should record, and store information of the production orders
REC_021 manufactured, and to be manufactured in the future according to the D
client/headquarters necessities

Table 18 – URS for Interfaces

Priority
Nr. Requirement
(M/D)
INT_001 The system should be compatible with android terminals to be used on the
D
warehouse.
INT_002 The system should be able to establish an interface with the weighing terminals. D

Table 19 – URS for documentation and training

Priority
Nr. Requirement
(M/D)
DOC_001 Confidential Agreement M
DOC_002 Manuals with Glossary M
DOC_003 User Training on the System M
DOC_004 Configuration File M
DOC_005 Installation File M
DOC_006 Functional and Configuration Specifications M

37
 Table 20 – URS for maintenance

Priority
Nr. Requirement
(M/D)
In the event of a power failure, the system shall ensure no compromise of the data
MNT_001 M
currently being used;
If power loss is maintained for a long period of time, the system shutdown must be
MNT_002 M
performed in a controlled manner;
The system must have a flexible architecture to introduce improvements, new
MNT_003 M
modules (with new functionalities) or later adjustments;
The system must have a Quality Environment where the necessary improvements
MNT_004 M
are tested prior deployment to production environment.
MNT_005 Procedures for Change Control Management related to CSV shall exist. M
MNT_006 Procedures for Periodic Review of the system shall exist. M
MNT_007 Procedures for problem resolution shall exist. M
Procedures for system security shall exist. These procedures shall include Physical
MNT_008 M
Security, Application Security, and Network Security.
MNT_009 Procedures for Shutdown/Start-up shall exist. M
MNT_010 Procedures for system administration shall exist. M
MNT_011 Procedures for Maintenance shall exist M
MNT_012 Procedures for Back-up and restore shall exist. M

38
 Functional Risk Assessment
The FRA documents the measures identified to be taken to mitigate the system risks on product quality,
process or in the applicable good practices. Control measures defined in the FRA are verified during the
qualification activities. In order to conduct a risk analysis, a qualitative FMEA was used in accordance with the
GAMP®5 approach to risk analysis22, and the criteria used in the different steps are represented below. A FMEA
template to apply in functional risk assessments is presented in Annex #2.

Failure Mode Effects Analysis 60

This risk analysis intends to:
• Identify the risks associated to the critical functions and parameters of a system;
• Evaluate the impact of the risks on product/process quality;
• Define the measures to be taken to minimize the impact of the risks.

Risk Identification
In this phase, the potential risks are identified. These risks are related to the critical functions and parameters
of the system according to their business and regulatory compliance. The following questions should be used:
• What can fail?
• What is the impact on the fail?
• What external fails may occur?
• What control systems may fail?

Risk Analysis
To be comparable, the risk must be measure. In order to measure the risk, it is necessary to attribute a level
to make possible to quantify the risks. The following parameters should be evaluated to each failure mode
identified:
• Probability [P]
It is the occurrence probability of a risk scenario or event. It can be classified as:
Low: The failure event is rare, happening once at 100 000 cycles;
Medium: The failure may happen at each 1 000 cycles;
High: The failure may happen at each 100 cycles.

• Severity [S]
It is the potential impact that the occurrence of a failure can has on the quality of the product, process or in
the applicable good practices. It can be classified as follows:
Low: the severity of the fault has a low impact on quality; the impact of the fault does not extend in
time;
Medium: failure has moderate severity in quality and may have an effect in the medium term;
High: failure has a high impact on the quality of the product. It has catastrophic consequences that
may extend in time.

39
 • Risk Class [RC]
The risk class of each failure is classified by plotting the probability of occurrence (low, medium or high) versus
the severity of the failure (low, medium or high) using a 3x3 Boston grid.

Risk Probability

Low Medium High

High Level 2 Level 1 Level 1

Severity
of Medium Level 3 Level 2 Level 1
Impact

Low Level 3 Level 3 Level 2

Figure 15 – Risk Class Assessment

Level 1: High impact risk.

Level 2: Medium impact risk.
Level 3: Low impact risk.

• Detectability [D]
It is the evaluation of how a failure can be detected. It can be classified as follows:
High: Detection highly likely.
Medium: Moderate probability of detection.
Low: Detection is unlikely.

• Risk Priority [RP]

The Risk Priority is the classification given to the risk associated to a failure, where control measures will be
assigned. Risk prioritization is determined by plotting the Risk Class (Level 1, 2 or 3) versus the probability of
detection (low, medium and high) using a 3x3 Boston grid.

40
 Detection Probability

Low Medium High

Level 1 High High Medium

Level 2 High Medium Low

Risk Class

Level 3 Medium Low Low

Figure 16 – Risk Priority Assessment

High risk: it represents a level of risk that recommends taking actions to mitigate the risk, as well
actions to demonstrate their control.
Medium risk: it is a risk that implies actions to demonstrate that risk is controlled.
Low risk: It is an acceptable level of risk. Action may be taken to mitigate or control the risk, but it is
not mandatory.

Risk Control
Based on the Risk Priority, actions can be taken to demonstrate the control and prevention of failure. The risk
control strategy22 shall be developed taking into account the points referred in Table 21.
Table 21 – Risk Control Strategy

Risk Control Strategy

Identify the root cause that can cause a failure and set a control that prevents that root cause from occurring.
Reduce risk by reducing the probability of failure:
• Introduction of automated checks of data quality;
• Development of operating standard procedures to business process to counter possible failures;
Reduce the risk by increasing the mechanisms for fault detection:
• Introduction of automated controls within the CS being assessed, e.g:
- Data verification checks within the system to reduce the likelihood of data entry errors (input ranges)
- User prompts to verify inputs and alert messages to increase the detectability of user error.
Increase the rigor of verification testing to demonstrate that the CS performs as intended and handle possible
failure events.
Appropriate training and operating procedures for users and system operation.

41
 In other cases, the risk identified may be reasonably low or easily detectable and therefore specific controls
are not mandatory. Controls for a given process can be configured in the system when necessary (according to
the user requirements) at the project development stage, such as alerts, data field restrictions, required data
fields or input field prompts for verification. According to the control, the most appropriate test shall be applied
to the respective qualification activity (IQ, OQ or PQ).
For this case study, the functions and parameters of the system that are related to good practices, such as
access control, audit trail, GxP data management, among others, were assessed. For each
functionality/parameter, risks were identified and analyzed following the qualitative risk criteria for FMEA,
assessing the probability of occurrence, severity of failure and its detectability, classifying each failure mode as
high, medium or low. As defined in the validation plan, for each failure mode, controls to decrease the probability
or increase detectability were indicated. For system operation control, tests have been specified to verify the
effectiveness of the controls in place. For control of the risk associated with the user, actions such as proper
training, creation of operating procedures, check the audit trail, review or approval by a user with higher level
profile were also specified. The result of the functional risk assessment is shown in table 22.

42
 Table 22 – Risk Analysis Matrix

Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy

Detectability

Risk Priority
Severity [S]
Probability

Risk Class
No. Parameter / Function Failure Mode Actions/Tests: Qualification

[RC]

[RP]
[D]
[P]
(Possible Failure) Risk Mitigation/Reduction Strategy Activities

• Perform backup of normal operating

In case of the need for a recall, information of the batch and data according to approved procedure
Perform the tracking of batches released Missing information; Data
1 distributor/market must be accurately stored and available. (including periodicity). PQ
for each distributor/market corruption.
• Perform recover of data according to

Low High Level 2 Low High approved procedure.

• Perform backup of normal operating

The information of the customer or the batch related to the data according to approved procedure
Support in Customer Return (return of a Missing information; Data
2 return is not available and the batch can’t be traceable. (including periodicity). PQ
product) corruption.
• Perform recover of data according to
Low Medium Level 3 Low Medium approved procedure.

The information of the customer/supplier, such as the

qualification status must be available or it’s not possible to
Visualize and trace customer and Missing information; Wrong • Perform recover of normal operating
3 ensure that the product is only distributed/order to/from PQ
supplier information information; Data corruption. data according to approved procedure.
approved customers/supplier.

Low Medium Level 3 High Low

43
 Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy

Detectability

Risk Priority
Severity [S]
Probability

Risk Class
No. Parameter / Function Failure Mode Actions/Tests: Qualification

[RC]

[RP]
[D]
[P]
(Possible Failure) Risk Mitigation/Reduction Strategy Activities

• The qualification status of the supplier or

Disqualified or in process client must be confirmed by a second
Purchase orders can be issued/accepted for a disqualified or
supplier or customer are authorized person in order to improve the
in process supplier/customer. PQ
entered into the system as detectability.
Allow only the use of qualified suppliers
qualified. • Perform audit trail to confirm who
(such as issue purchase orders) and
4
approved customer (such as accept Low High Level 2 Low High added the information in the system.

orders)
The system fails to control and • Define purchase or client order approval
IQ
allows the use of unapproved System is not capable of control function. only for user with higher level profile.
or in process of approval • Perform Accuracy test to check system
OQ
suppliers and customers. Low High Level 2 Medium Medium capability to control this function.

•Test network connection with fault

IQ
tolerance test.

• Verify the availability of a SOP for backup

Stock & inventory of manufacturing and Connection failure and no real- Unrealistic data in relation to current stock and inventory. OQ
5 (including periodicity).
distribution articles time update.

• Perform inventory & stock reconciliation

PQ
according to an approved procedure.
Medium Medium Level 2 Medium Medium

System automatically block selected Article is not blocked when Compromises the real-time status of the inventory. • Perform accuracy test to verify the
6 OQ
articles in inventory selected in inventory. system accuracy of control.
Low Medium Level 3 Medium Low

44
 Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy

Detectability

Risk Priority
Severity [S]
Probability

Risk Class
No. Parameter / Function Failure Mode Actions/Tests: Qualification

[RC]

[RP]
[D]
[P]
(Possible Failure) Risk Mitigation/Reduction Strategy Activities

Movements are not recorded by the System; • Record the movements manually and
Connection failure and no real-
Loss of traceability of movements. then update them in the system. OQ
time update.
7 Movements (article code, date, location) Medium Medium Level 2 Medium Medium • Perform fault tolerance test.

Movement is not performed Movement to the wrong location, or for the wrong article. • Verify the availability of an operating
OQ
properly. Medium Medium Level 2 Medium Medium procedure and training.

• Perform fault tolerance test. OQ

Connection failure and no real-
Status of the articles (batches, raw Unrealistic data in relation to current stock and inventory.
8 time update of the article • In case of connection failure record the
materials, materials…)
status. status updates manually and then enter PQ
Low Medium Level 3 Low Medium the data in the system.

• Define a high-level profile approval for

IQ
GxP data entry.

• Ensure that the user has adequate

training to avoid errors in the operation of
Entry of information for each article such During the initial entry of data into the system it is possible the system functions.
Entry of information in a wrong that the user by inexperience in the use of the system can OQ
9 as name, date, quantity, shelf-life, • Perform data validity test and invalid
field. enter data in the wrong field
storage, retest date, effective date case test in order to decrease the
probability of errors to happen.

• Perform an audit trail to confirm who

PQ
added the information in the system.
Medium High Level 1 Medium High

45
 Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy

Detectability

Risk Priority
Severity [S]
Probability

Risk Class
No. Parameter / Function Failure Mode Actions/Tests: Qualification

[RC]

[RP]
[D]
[P]
(Possible Failure) Risk Mitigation/Reduction Strategy Activities

• Ensure that the user has adequate

Characterize the article according to
training to avoid errors in the operation of
their scope (raw material, packaging Article is allocated in the wrong User misintroduces the article in the wrong category.
10 the system functions. OQ
material, bulk product, finished category.
• Verify the availability of an operating
product…)
Low Low Level 3 Medium Low procedure and training.

In case of recall, return or customer/supplier complaint the • Verify the availability of an operating
Each article has a unique code linked to a Article code is incorrectly supplier and the manufacturer of the article must be procedure and adequate user training.
11 OQ
supplier and/or to a manufacturer entered. traceable. • Perform data validity test and invalid case
Low Medium Level 3 Medium Low test.

• Perform data validity test and invalid case

test (such as testing if the system accepts the OQ
The system should detect once the article expires expiry date before the manufacturing date).
User mixes expiry date field
immediately.
with manufacturing date. • Confirm if the expiry date is in accordance
Enter manually an expiry date and
12 with the manufacturing date (in batch PQ
manufacturing date per each batch code
record) and with the shelf life of the article.
Low Medium Level 3 Low Medium

The article may become invalid earlier than the system • Verify the availability of an operating
Expiry or manufacturing date
indicates. procedure and adequate user training. OQ
are incorrectly entered.
Low High Level 2 Medium Medium • Perform Invalid case testing.

46
 Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy

Detectability

Risk Priority
Severity [S]
Probability

Risk Class
No. Parameter / Function Failure Mode Actions/Tests: Qualification

[RC]

[RP]
[D]
[P]
(Possible Failure) Risk Mitigation/Reduction Strategy Activities

• Perform output test and input combination

OQ
The expiry date is incorrectly generated which may lead test.

The expiry date is incorrectly to incorrect use of the article or to rejection of a good • The expiry date shall be revised and/or re-
generated by the system. condition article. entered into the system in accordance with
PQ
the batch record by user with higher level
Low High Level 2 Medium Medium profile.

• Define a high-level profile approval for

Shelf life introduction in order to improve the IQ
detectability.
The system assigns an expiry date
according to a predefined shelf life The expiry date can be incorrectly generated which may • Verify the availability of an operating
13 The shelf life defined for the lead to incorrect use of the article or to rejection of a good procedure for generating expiry date.
defined for the article starting from the condition article.
article is incorrectly entered. • Ensure that the user has adequate training
date of manufacture.
to avoid errors in the operation of the system OQ
functions.
• Perform data validity test and invalid case
Low High Level 2 Low High test.

• Perform data validity test and invalid case

User must confirm manufacturing date in batch record. OQ
test.
The date of manufacture is The initial manufacturing date must be counted from the
• Confirm if the expiry date is in accordance
incorrectly entered. date of the first granulation.
with the manufacturing date (in batch PQ
Low High Level 2 Low High record) and with the shelf life of the article.

47
 Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy

Detectability

Risk Priority
Severity [S]
Probability

Risk Class
No. Parameter / Function Failure Mode Actions/Tests: Qualification

[RC]

[RP]
[D]
[P]
(Possible Failure) Risk Mitigation/Reduction Strategy Activities

• Verify the availability of an operating

Wrong barcode and/or article code introduced can lead to the
Configured Labels according to data in The information in the label is procedure and adequate user training.
14 use of the wrong material. OQ
the system incorrectly entered. • Perform data validity test and invalid
case test.
Low High Level 2 Low High

• Perform accuracy test to check audit

OQ
Special handling conditions User does not categorize the article or introduce it into a wrong trail accuracy and security test.
location.
Visualization of locationsand article is not characterized as • Verify the availability of an operating
management of quantities of articles such. OQ
procedure for warehouse management
15 identified as narcotic, cold chamber,
Low High Level 2 Medium Medium and adequate user training.
falsified medicines and with other
The function is available for all users, or all user profiles have
storage and handling conditions. Any user is able to change the • Perform audit trail to confirm who
access to change the location/quantity of the article.
location and/or quantities of added the information in the system. PQ
Problems with the reconciliation of articles.
articles.
Low High Level 2 Medium Medium

• Define BOM approval only for users

IQ
A BOM containing incorrect information can have with higher level profile.
Record article master data in the format BOM consisting of incorrect
16 consequences at the manufacturing level. •Verify the availability of an operating
of a BOM. information.
procedure for record of BOM and OQ

Medium High Level 1 Medium High adequate user training.

48
 Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy

Detectability

Risk Priority
Severity [S]
Probability

Risk Class
No. Parameter / Function Failure Mode Actions/Tests: Qualification

[RC]

[RP]
[D]
[P]
(Possible Failure) Risk Mitigation/Reduction Strategy Activities

• Ensure that the user has adequate

Rejected or in quarantine article can be used for production training to avoid errors in the operation OQ
Article status is misintroduced
purposes which could seriously compromise the quality of the of the system functions.
“R or Q” status is intered as
product and the process. • The status must be confirmed by a
“A”.
second authorized person in order to PQ

Low High Level 2 Low High improve the detectability.

• Ensure that the user has adequate

Entry of different status and the motive, training to avoid errors in the operation OQ
Article status is misintroduced Approved article is considered as rejected or in quarantine and
according to profile/access privileges. of the system functions.
“A” status article is entered as its use is not authorized.
17 • The status must be confirmed by a
“R” or “Q”.
A: Approved PQ
second authorized person in order to
R: Rejected
Low Medium Level 3 Low Medium improve the detectability.
Q: Quarantine
• Verify the availability of a SOP
describing the levels of privileges to
Any user without the approved The function is available for all users, or all user profiles have access certain functions.
profile can change the status of access to change the status of the article. • Perform an audit trail to confirm who OQ
the article. added the information in the system.
• Perform accuracy test to check audit
trail accuracy and security test.
Low High Level 2 Low High

49
 Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy

Detectability

Risk Priority
Severity [S]
Probability

Risk Class
No. Parameter / Function Failure Mode Actions/Tests: Qualification

[RC]

[RP]
[D]
[P]
(Possible Failure) Risk Mitigation/Reduction Strategy Activities

The system fails to update the An expired material can be use in the manufacturing process.
Update the status of an article for “R” • Perform Accuracy test to verify the
18 status and a rejected article is User need to confirm the expiry date of the article before use. OQ
after reaching the expire date system capability to control this function.
considered “A” status. Low High Level 2 Medium Medium

• Perform fault tolerance test to verify

The transfer order is not Printer failure or the connection with the printer failed.
19 Issue and print transfer orders the connection between the printer and IQ
printed.
the hardware.
Low Low Level 3 High Low

Authorised user can’t access User cannot access, contacts support. High detectability. • Perform usability test to verify the
OQ
the system. authorized access control.
System access via authorised User ID and Low Low Level 3 High Low
20
password High security breach that can compromise data confidentiality • Perform security test (simulate non-
Unauthorised user accesses
and integrity. authorized entry to check the system OQ
the system.
Low High Level 2 Low High detection).

Error in the definition of user profile/access privileges which • Test the access levels by performing
OQ
Basic user profile can enter, may lead to any user having access to functionalities outside security test.
modify or delete GxP data. the scope of their training. • Perform audit trail to confirm who
PQ
21 Hierarchical access control Low High Level 2 Medium Medium added the information in the system.

User cannot access, need to contact support. High • Perform usability test to verify if the
Authorised user can’t access
detectability. user is able to access and respond to OQ
specific module or function.
Low Low Level 3 High Low information.

50
 Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy

Detectability

Risk Priority
Severity [S]
Probability

Risk Class
No. Parameter / Function Failure Mode Actions/Tests: Qualification

[RC]

[RP]
[D]
[P]
(Possible Failure) Risk Mitigation/Reduction Strategy Activities

Difficulty in using the system, can crash, increases the

Allow multiple accesses to the system • Perform stress test and environmental
22 System overload. probability of failure. OQ
simultaneously test (define user access limits).
Medium Medium Level 2 High Low

Failure to control forced User force entry and compromises safety and quality of the
• Perform security test (the system can
23 Unauthorised access block attempts to enter the system system. OQ
only allow 3 wrong access attempts).
with multiple attempts. Low High Level 2 Low High

• Check the Audit Trail data safe storage. IQ

Lack of data integrity;
• Perform security test to evaluate
Record accesses and attempted entries Incorrect or unavailable Audit Impossible to consult data; OQ
24 attempted entries.
in an audit trail Trail. Unawareness of attempted or successful intrusion.
• Perform accuracy test to check audit
OQ
Low High Level 2 Low High trail accuracy.

Lack of data integrity; • Check the Audit Trail data safe storage. IQ
Record user activities (changes, access
Incorrect or unavailable Audit Impossible to consult data;
25 functions) with date and ID user • Perform accuracy test to check audit
Trail. Unawareness of user activities. OQ
identification in an audit trail trail accuracy and security test.
Low High Level 2 Low High

• Perform accuracy test to check backup

Data loss or corruption of GxP data.
accuracy.
26 Periodic backup of data Backup is not properly done. It is only detectable when the data is lost. OQ
• Verify the availability of a SOP for
backup (including periodicity)
Low High Level 2 Low High

51
 Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy

Detectability

Risk Priority
Severity [S]
Probability

Risk Class
No. Parameter / Function Failure Mode Actions/Tests: Qualification

[RC]

[RP]
[D]
[P]
(Possible Failure) Risk Mitigation/Reduction Strategy Activities

• Perform test to verify if system

performs auto-save until the moment of
Only detectable when the fault occurs.
System shutdown in a controlled manner failure decreasing the probability of
27 Data loss or corruption. Risk of compromising GxP data. OQ
in case of power failure losing data.
• Perform fault tolerance test to
Low High Level 2 Low High evaluate the data recovery.

• Verify the availability of a SOP for the

Maintenance failures increase the probability of failures
maintenance of the system (including OQ
occurring.
The maintenance of the system
28 Perform Maintenance of the system Operation of the system can be compromised. periodicity).
is not performed.
• Check if maintenance is performed
PQ
Low Medium Level 3 Medium Low properly.

Documentation not available

Improper installation.
Functional and Configuration or updated; • Check the availability of the supplier
29 Improper or inadequate maintenance. IQ
Specifications. Lack of information available; documentation.

Lack of IT knowledge. Medium Medium Level 2 High Low

Documentation not available

or updated; Improper system installation. • Check in the installation the
Lack of information available; Improper or inadequate maintenance.
30 System technical documentation availability and update of the system IQ
Lack of IT knowledge; Without documentation work cannot be done (low severity).
technical documentation.
Lack of legalization and / or
evidence required. Medium Low Level 3 High Low

52
 Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy

Detectability

Risk Priority
Severity [S]
Probability

Risk Class
No. Parameter / Function Failure Mode Actions/Tests: Qualification

[RC]

[RP]
[D]
[P]
(Possible Failure) Risk Mitigation/Reduction Strategy Activities

Procedure to control of username types, The operation and security of the system are not carried out as
Lack of procedure(s); • Verify the availability of a SOP for user
31 password and recurrence of password intended. OQ
Procedure(s) not updated. and password management.
update Low Medium Level 3 Medium Low

• Verify the availability of a SOP for

Procedure to Change Control Lack of procedure(s); The operation is not carried out as intended.
32 change control management with OQ
Management Procedure(s) not updated.
Low Medium Level 3 Medium Low reference to the assess for CSV.

Procedure for Periodic Review of the Lack of procedure(s); The operation is not carried out as intended. • Verify the availability of a SOP for
33 OQ
System Procedure(s) not updated. Low Medium Level 3 Medium Low periodic review (including periodicity).

Procedure for system security (including

Lack of procedure(s); The operation and security is not carried out as intended. • Verify the availability of a SOP for
34 physical security, application security OQ
Procedure(s) not updated. system security.
and network security) Low Medium Level 3 Medium Low

Lack of procedure(s); The operation is not carried out as intended. • Verify the availability of a SOP for
35 Procedure for system administration OQ
Procedure(s) not updated. system administration.
Low Medium Level 3 Medium Low

• Verify the availability of a SOP for

Lack of procedure(s); The operation is not carried out as intended.
36 Procedure for system maintenance system maintenance (including OQ
Procedure(s) not updated.
Low Medium Level 3 Medium Low periodicity).

53
 Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy

Detectability

Risk Priority
Severity [S]
Probability

Risk Class
No. Parameter / Function Failure Mode Actions/Tests: Qualification

[RC]

[RP]
[D]
[P]
(Possible Failure) Risk Mitigation/Reduction Strategy Activities

Lack of procedure(s); The operation is not carried out as intended. • Verify the availability a SOP for backup
37 Procedure for backup and restore OQ
Procedure(s) not updated. and restore (including periodicity).
Low Medium Level 3 Medium Low

• Verify the availability a SOP for system

Lack of procedure(s); The operation is not carried out as intended.
38 Procedure for system operation operation, including instructions on OQ
Procedure(s) not updated.
Low Low Level 3 High Low system functionalities.

• Verify the availability of SOPs that

support the user’s training, such as
system operation.
Inadequate system operation.
39 Training Lack of training. • Ensure that users of the system have OQ

adequate training and the planned

training program is in accordance with
Low High Level 2 Medium Medium the intended use for the system.
Web-based application accessed via browser is likely to be
• Identify system users and register the
Web-based software is not compatible in normal hardware devices (PC, laptop,
40 Hardware compatibility main hardware and operating system IQ
compatible on hardware. smartphone).
configuration and version.
Low Low Level 3 High Low

54
 As demonstrated, system parameters such as the management of training and operational procedures do
not represent a significant risk associated with the operation of the system since the probability of the absence
of these parameters in the qualification phase is low and easily detectable. The correct implementation and use
of these parameters have to be assessed since they are essential and help to ensure that good practices are
constantly followed.
Possible failures were identified, such as in the generation of data by the system, with an associated risk,
usually medium, and which can be evaluated by performing tests that evaluate the capacity of the system to
generate data accurately and the implementation of review phases by high-level users.
Possible failures related to access control and GxP data management, such as GxP data entry, which in case
of user mistake, can indicate flawed information about the quality status, identification or location of an article,
were also identified. These faults have a high associated risk and therefore, controls must be in place in the
system for detect any failure, such as security measures (for access control), confirmation of the data by the
primary data source (batch record, CoA), review of data entry or with the introduction of restrictions to
functionalities only for users with high levels profiles.
From this risk analysis it can be concluded that risks exist associated with the different functionalities and
parameters of the system and that controls to mitigate these risks should be implemented. The tests that verify
the effectiveness of these controls will be defined and performed in the following qualification phases.

55
4. Conclusions and Future work
The main purpose of the validation is to assure consistent quality in a company's processes. Validation should
be planned considering the overall risks related to the system to be validated, taking into account its complexity,
novelty, intended use and the impact on quality. A risk-based VP should then be followed, according to applicable
methodologies that allow us to determine and characterize the different risks that the system may have.
The strong pressure that the pharmaceutical industries are subject to under regulatory agencies, demands
that all processes are strictly compliant with the applicable guidelines and regulations. This leads the industries
to define their quality management system in order to demonstrate that their internal processes present the
expected quality.
It is important for each company to have a strategic VP, taking into consideration the complexity and risk of
the system, to make use of the guidelines, to have an extensive knowledge of the regulations applicable to CSs
in the pharmaceutical industry.
This dissertation was written in order to be used as a guide for planning the validation of CSs and as a case
study on how the validation of the ERP SAGE X3 was planned in the initial phase of Labatec Farmacêutica S.A. in
Portugal.
During this work, the system was characterized according to its GxP impact, determining that it has a direct
impact. A risk-based validation plan was established defining the validation phases to be followed. The system
requirements were developed based on the needs of the user areas. Moreover, a risk analysis taking into account
possible failures identified for the system's functionalities, was performed, allowing the creation of a baseline
for the qualification activities.
Due to the complexity of the initial phase of the Labatec project, unexpected events, delays and unrealistic
expectations usually occur. Any validation process is a time-consuming activity that requires testing, creation of
documentation and achieve results. Since it was not possible to perform the tests on the system in a timely
manner, for future work I would propose to implement the operational procedures and the preparation of
qualification protocols, as well as the reports. This should be performed based on the tests proposed in this
dissertation, following the risk assessment analysis.

56
5. Bibliography
(1) Vuksic, V. B.; Spremic, M. Case Study of PLIVA Pharmaceuticals Inc. - Aligning ERP System Implementation
with Business Process Change. 6.
(2) Ruivo, P.; Johansson, B.; Oliveira, T.; Neto, M. Commercial ERP Systems and User Productivity: A Study
Across European SMEs. Procedia Technol. 2013, 9, 84–93. https://doi.org/10.1016/j.protcy.2013.12.009.
(3) Labatec Website http://www.labatecpharma.com/ (accessed Feb 21, 2019).
(4) Introduction to Computers: Hardware and Software
http://cs.sru.edu/~mullins/cpsc100book/module02_introduction/module02-03_introduction.html
(accessed Oct 19, 2019).
(5) PHARMACEUTICAL INSPECTION CONVENTION. PIC/S Guidance - Good Practices for Computerised
Systems in Regulated “GxP” Environments. 2007.
(6) Kumar, K.; van Hillegersberg, J. Enterprise Resource Planning: Introduction. Commun. ACM 2000, 43 (4),
22–26. https://doi.org/10.1145/332051.332063.
(7) Panorama Consulting Solutions. 2017 Report on ERP Systems & Enterprise Software; 2017.
(8) Panorama Consulting Solutions. 2018 ERP Report; 2018.
(9) Umble, E. J.; Haft, R. R.; Umble, M. M. Enterprise Resource Planning: Implementation Procedures and
Critical Success Factors. Eur. J. Oper. Res. 2003, 146 (2), 241–257. https://doi.org/10.1016/S0377-
2217(02)00547-7.
(10) Rashid, M. A.; Hossain, L.; Patrick, J. D. The Evolution of ERP Systems: A Historical Perspective. 16.
(11) Watson, E. E.; Schneider, H. Using ERP Systems in Education. Commun. Assoc. Inf. Syst. 1999, 1.
https://doi.org/10.17705/1CAIS.00109.
(12) Pharma 2020: Challenging Business Models - Which Path Will You Take? 24.
(13) ERP, O. 6 Reasons Why Pharmaceutical Companies Need an ERP System. 3i infotech, 2017.
(14) Lumenia Consulting Ltd. ERP in the Pharmaceutical Industry - Complex Functional Requirements Create
Significant Challenges for ERP Systems.
(15) Markus, M. L.; Axline, S.; Petrie, D.; Tanis, C. Learning from Adopters’ Experiences with ERP: Problems
Encountered and Success Achieved. J. Inf. Technol. 2000, 15 (4), 245–265.
https://doi.org/10.1080/02683960010008944.
(16) Sage Group. Enterprise Management Solution Capabilities - SAGE X3; 2017; p 54.
(17) MRP, ERP or MIS? A quick refresher course https://www.voortman.net/pl/company/news/448-mrp-erp-
or-mis (accessed Sep 23, 2019).
(18) Spine Software Systems Pvt. Ltd. Process Flow of Pharma Companies & Need of ERP, 12:45:21 UTC.
(19) SAGE ENTERPRISE MANAGEMENT HISTORY – E2b Teknologies.
(20) RKL eSolutions Staff. Managing 21 CFR Part 11 Compliance with Sage X3.
(21) European Commission. EudraLex Annex 15: Qualification and Validation; 2015.
(22) GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems; ISPE Headquarters [u.a.]:
Tampa, Fla, 2008.
(23) Abraham, J. International Conference On Harmonisation - Good Manufacturing Practice Guide for Active

57
 Pharmaceutical Ingredients Q7. In Handbook of Transnational Economic Governance Regimes; Tietje, C.,
Brouder, A., Eds.; 2010.
(24) World Health Organization. Guidelines on Validation - Appendix 5: Validation of Computerized Systems.
2018.
(25) European Commission. EudraLex Annex 11: Computerised Systems; 2011.
(26) Comission of the European Communities. COMMISSION DIRECTIVE 2003/94/EC; 2003.
(27) CFR - Code of Federal Regulations Title 21 - Part 11
https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=11 (accessed Sep
11, 2019).
(28) CFR - Code of Federal Regulations Title 21 - 820.70
https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=820.70 (accessed Sep 11,
2019).
(29) PHARMACEUTICAL INSPECTION CONVENTION. PIC/S Guidance - Good Practices for Data Management
and Integrity in Regulated GMP/GDP Environments. 2018.
(30) European Commission. EudraLex Volume 4 - Chapter 4: Documentation; 2011.
(31) Data Integrity is the New BUZZ Word for Regulated Companies
https://www.researchgate.net/institution/Waters_Corporation/post/59a6d83adc332d2a6e666b4e_Da
ta_Integrity_is_the_New_BUZZ_Word_for_Regulated_Companies (accessed Feb 21, 2019).
(32) IPA Innovation, Quality and Global Reach. Good Documentation Practice (GDP) Guideline; 2018.
(33) Guidance for Industry - Part 11, Electronic Records; Electronic Signatures — Scope and Application. 12.
(34) Annex 11 and 21 CFR Part 11: Comparisons for International Compliance. In EU Annex 11 Guide to
Computer Validation Compliance for the Worldwide Health Agency GMP; CRC Press, 2015; pp 253–262.
https://doi.org/10.1201/b18315-28.
(35) EduQuest, Inc. Comparison of FDA’s Part 11 and the EU Annex 11.
(36) Commissioner, O. of the. About Warning and Close-Out Letters. FDA 2019.
(37) Encyclopedia of Biopharmaceutical Statistics, Fourth edition.; Chow, S.-C., Ed.; Taylor & Francis: Boca
Raton, 2018.
(38) FDA Warning Letters Archives https://validationcenter.com/product-category/library/fda-warning-
letters/ (accessed Sep 22, 2019).
(39) Commissioner, O. of the. Warning Letters http://www.fda.gov/inspections-compliance-enforcement-
and-criminal-investigations/compliance-actions-and-activities/warning-letters (accessed Sep 22, 2019).
(40) Center for Drug Evaluation and Research. Ipca Laboratories Limited - 01/29/2016
http://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-
letters/ipca-laboratories-limited-01292016 (accessed Sep 19, 2019).
(41) Center for Drug Evaluation and Research. Bedfont Scientific, Ltd. - 02/04/2016
http://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-
letters/bedfont-scientific-ltd-02042016 (accessed Sep 19, 2019).
(42) Center for Drug Evaluation and Research. Polydrug Laboratories Pvt. Ltd. - 04/14/2016

58
 http://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-
letters/polydrug-laboratories-pvt-ltd-04142016 (accessed Sep 19, 2019).
(43) Center for Drug Evaluation and Research. F.P. Rubinstein Y Cia SRL - 05/05/2016
http://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-
letters/fp-rubinstein-y-cia-srl-05052016 (accessed Sep 19, 2019).
(44) Center for Drug Evaluation and Research. USV Limited - 510159 - 03/10/2017
http://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-
letters/usv-limited-510159-03102017 (accessed Sep 19, 2019).
(45) Center for Drug Evaluation and Research. Dynavision International LLC - 525321 - 09/05/2017
http://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-
letters/dynavision-international-llc-525321-09052017 (accessed Sep 19, 2019).
(46) Center for Drug Evaluation and Research. Becton Dickinson & Company - 535770 - 01/11/2018
http://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-
letters/becton-dickinson-company-535770-01112018 (accessed Sep 19, 2019).
(47) Jotwani, R. Process ERP, an Ideal Software Solution for Life Science Industries. 2015, 23.
(48) Pharmaceutical Computer Systems Validation: Quality Assurance, Risk Management and Regulatory
Compliance, 2nd ed.; Wingate, G., Ed.; Informa Healthcare: New York, 2010.
(49) Software Validation in a Nutshell! The 5 Minute Guide to Understanding the Principles - Learnaboutgmp:
Accredited Online Life Science Training Courses https://learnaboutgmp.com/computer-system-
validation-csv/software-validation-in-a-nutshell-the-5-minute-guide-to-understanding-the-principles/
(accessed Oct 17, 2019).
(50) ICCBBA. Software Validation.
(51) Common ERP Implementation Challenges and How to Overcome Them. MBAF, CPAs and Advisors.
(52) Kraemmerand, P.; Møller, C.; Boer, H. ERP Implementation: An Integrated Process of Radical Change and
Continuous Learning. Prod. Plan. Control 2003, 14 (4), 338–348.
https://doi.org/10.1080/0953728031000117959.
(53) Dey, P. K.; Clegg, B.; Cheffi, W. Risk Management in Enterprise Resource Planning Implementation: A New
Risk Assessment Framework. Prod. Plan. Control 2013, 24 (1), 1–14.
https://doi.org/10.1080/09537287.2011.597038.
(54) Aloini, D.; Dulmin, R.; Mininno, V. Risk Management in ERP Project Introduction: Review of the Literature.
Inf. Manage. 2007, 44 (6), 547–567. https://doi.org/10.1016/j.im.2007.05.004.
(55) Abraham, J. International Conference On Harmonisation - Quality Risk Management Q9. In Handbook of
Transnational Economic Governance Regimes; Brouder, A., Tietje, C., Eds.
(56) Reddy, V. V.; Gupta, N. V.; Raghunandan, H. V.; Kashyap, U. N. Quality Risk Management in
Pharmaceutical Industry: A Review. 8.
(57) McDowall, R. D. Effective and Practical Risk Management Options for Computerised System Validation.
Qual. Assur. J. 2005, 9 (3), 196–227. https://doi.org/10.1002/qaj.339.
(58) Northeast Biomanufacturing Center & Collaborative (NBC). Introduction to Biomanufacturing - Chapter

59
 4: Validation; Global Biomanufacturing Curriculum, 2016.
(59) The five dos and don’ts of writing a URS | Healthcare Packaging
https://www.healthcarepackaging.com/article/five-dos-and-donts-writing-urs (accessed Sep 20, 2019).
(60) International Organization for Standardization. ISO 31010:2009 - Risk Assessment Techniques.
(61) Black-Box Testing - BPM Glossary https://www.businessprocessglossary.com/13107/black-box-testing
(accessed Sep 17, 2019).

60
6. Annexes
Annex #1 – Recommended tests for Risk Control/Mitigation Strategy Tests.
Table a-1 – Recommended Tests

Type of
Scope of the Test Description
Test
Structural Testing is conducted based on the source code knowledge. These test cases challenge
Structural Testing

the control decisions made by the software and the software’s data structures including any
configuration settings.
Structural Testing is usually performed within the unit or module test phase i.e. this type of tests
is carried out by the developer of the application for configured products.

Functional Testing is conducted to evaluate the compliance of a system or component with

specified functional requirements and corresponding predicted results61.
Functional testing therefore identifies Test Cases based on the definition of what the software
is intended to do.

Testing to demonstrate the response to the normally expected

Normal Case Testing inputs; (e.g., checking that a calculation gives the correct result in
Functional Testing

response to the expected inputs);

Invalid Case Testing
Special Case Testing
Output Testing
Testing to demonstrate the response to specified invalid inputs;
(e.g., giving the correct error message in response to an out-of-
range input);
Testing to demonstrate the response to input values that seem
likely to cause program errors; (e.g., "0", "1", NULL, empty string);
Choosing test inputs to ensure that all software outputs are
generated at least once during testing;

Input Combination Testing Testing combinations of inputs to ensure correct outputs.

61
Type of
Scope of the Test Description
Test

Performance Testing is performed to evaluate the compliance of a system or component with

specified performance requirements.

Testing to demonstrate that the system is capable of operating

Environmental Tests
reliably in the specified environment;
Testing to demonstrate that the system meets the required
Accuracy Tests
accuracy of measurement or control;
Performance Testing

Testing to demonstrate that the system is capable of repeatedly

Repeatability Tests
meeting the required performance;
Testing to demonstrate that the system meets the required
Timing or Response Tests
timing, throughput or response.;
Testing to demonstrate that the system meets the required
Load Tests performance whilst operating under realistic high load conditions;
e.g., many users logged at the same time;
Testing to evaluate the combined performance of the system and

Usability Tests user; e.g., check if the user is able to access and respond to
information.

Challenge Testing is performed to evaluate the robustness of a system or a component under

abnormal operating conditions.

Testing to demonstrate that system is capable of avoiding or

Data Validity Tests detecting invalid inputs; (e.g., user entries in the wrong format,
values outside of the allowed range);
Security Tests Testing to show that the system offers protection against control
Challenge Testing

actions or data access by unauthorized users;

Fault Tolerance Tests Testing to evaluate the system’s ability to continue operations in
the presence of faults and to recover when the fault condition
clears; (e.g., network failure, printer failure, recovery of deleted
data);
Stress Tests Testing to evaluate the system’s ability to continue operation
under abnormally high load conditions and to recover when the
condition clears; (e.g., high network traffic);
Environmental Tests Testing to evaluate the system’s ability to continue operation
under extreme environmental conditions.

62
 #Annex 2 – FMEA template for Functional Risk Assessment

Table a-2 – Example of FMEA template for FRA

Risk Identification Risk Analysis & Classification Risk Mitigation/Control Strategy

Risk Priority [RP]

Detectability [D]
Probability [P]

Risk Class [RC]

Severity [S]
No. Parameter / Function Failure Mode Actions/Tests: Qualification
(Possible Failure) Risk Mitigation/Reduction Strategy Activities

[Refer the
[Write down considerations/observations on the [write down all the points and/or factors
Qualification
impact] that is either implemented, planned, or
Phase the
[Write down the what might go wrong?] proposed for implementation in order to
test should
[write down the function / system reduce this risk & /or eliminate the risk]
1 P S RC D RP be
parameter] performed]

…
… … …

P S RC D RP

…
…
2 … … …
P S RC D RP

63