Validation of an Enterprise

Resource Planning (ERP) System:

An SAP Case Study
Jackelyn Rodriguez
Medtronic MiniMed Inc.

❖
edtronic MiniMed is the MiniMed selected the SAP R/3

M world’s leading provider

of external programma-
ble insulin pumps and continuous
❝…[Enterprise
Resource
enterprise software package, Version
4.6 C, to replace its current legacy
system. In this phase, the R/3 system
glucose monitoring systems. We Planning] ERP affected the following functional
are a multi-billion dollar corpora- areas: planning, scheduling, purchas-
tion which employs approximately
packages enable ing, manufacturing operations (plan-
2,000 people at the Northridge, an organization ning and production management
California, facility. There are ap- only), document control (bill of
proximately 1,600 computer users
to truly function materials and routings only), invento-
that were affected by the implemen- as an integrated ry control, inventory accounting, cost
accounting, general ledger, fixed
tation of a new Enterprise Resource
Planning (ERP) system, which
organization. ❞ assets, accounts payable, sales, and
needed to be blueprinted, config- distribution. Selected modules are
ured, installed, tested, and validated in less than 12 included in Figure 1.
months. Needless to say, this was not an easy task. SAP is the fourth largest software manufacturer
We needed to purchase an ERPsystem software ap- in the world. SAPis modular software, e.g., Sales and
plication package that is a suite of pre-engineered, ready Distribution (SD), Materials Management (MM).
to implement integrated application modules catering to These modules share common data to reduce data entry
all the business functions of an enterprise, (which in- activities, and increase information accuracy for bus-
cluded the flexibility for configuring/customizing the iness functions.
functionality of the package to suit specific require- Since this new ERPsystem tracks the movement and
ments of the enterprise) that would allow our users to inventory of a medical device product from its receipt to
electronically unite the MiniMed community by replac- placement in MiniMed’s distribution centers, and could
ing the company’s current software system with a new eventually develop the functionality for electronic batch
state-of-the-art system known as System Application records, the current Good Manufacturing Practice
and Products (SAP). This new ERP system was Regulations (cGMP) require that the R/3 system be val-
designed to deliver state-of-the-art business applica- idated. These functions are regulated by the cGMP
tions that would enable well-controlled growth through requirements defined in the Code of Federal Reg-
a consistent, real-time source of integrated information, ulations (CFR), Title 21, Parts 820, 11, 210, and 211.
and ensure timely and accurate business decisions A detailed cGMP impact assessment for the enter-
scaled to a billion dollar plus company. prise project needed to be completed.

May 2003 • Volume 9, Number 3 205

Jackelyn Rodriguez
Figure 1
Selection Modules
Module Types of Quality Records
Human Resources (HR) Training records, certifica-
tions
Material Management (MM) Bills of materials, materials
specifications, production
work orders
Sales and Distribution (SD) Customer orders, shipping
records
Production Planning (PP) Forecast plans, purchasing
documents
Financial Accounting/Asset Accounts receivable and
Accounting (FI) accounts payable
Project Team Selection and Responsibilities
At the beginning of the project, it was quite critical
that certain responsibilities and functions be assigned in
order to achieve deliverables in a timely fashion. A
multi-functional validation team was formed to oversee
and approve all software validation activities. Members
included representatives from Quality Assurance (QA),
Information Technology (IT), process owners, and busi-
ness users.
Information Technology (IT) was responsible for
the following areas, including:
• Delivery of computerized systems (computer hard-
ware, operating system, and installed standard ap-
plication software)
• Acquiring the required license agreements
• Maintaining a validated system for performing
daily network back-up and restore activities.
Process owners/business users were responsible for
the following areas, including:
• Defining the requirements for the software and
computerized systems for their intended use
• Documenting the Software Development Life-
cycle (SDVLC) process and activities for the
software and computerized system
Quality Assurance
QA was the project leader for the software valida-
tion process. They conducted the following activities:
• Identified all activities that required validation
• Generated the validation master list
206 Journal of Validation Technology
• Generated the Process Validation Plan (PVP)
and Process Validation Report (PVR) for new or
existing software systems developed to support
the manufacturing of new products with the con-
currence of QA
• Reviewed and approved all business process pro-
cedure, process flow diagrams, test scripts, busi-
ness process procedures master list (traceability
matrix)
• Witnessed all test scripts executions
• Confirmed that all test script deviations were ad-
dressed and closed.
• Managed and maintained the change control pro-
cess
Development Methodology
Through the use of the SAP product, Accelerated
SAP (ASAP) project deliverables were identified,
scheduled, and developed. All of the functional areas
generated the same type of deliverables. Careful con-
sideration was made to ensure that detailed documen-
tation was maintained for the cGMP governed areas.
Through change control, and preventing unauthorized
or undocumented modifications to the system, it was
maintained in a validated state. This system was se-
lected not only for business reasons, but also because
of the ASAP accelerated methodology.
Our enterprise validation project plan defined the
scope of the enterprise project validation effort. This
document was also used to establish an approach to ad-
dress validation requirements in order to ensure com-
pliance of the completed system with FDAand internal
guidelines. The validation project plan defined why the
validation occurred, described the validation approach,
specified the required steps and associated deliver-
ables, and defined responsibilities for performing the
validation steps.
The objectives of the validation project plan were
to formally define and document the intended oper-
ation of the R/3 system – enterprise project by:
• Identifying the documents required to support
the validation of the R/3 system
• Defining the strategy for verifying that the R/3
system – Enterprise Project performed in a reli-
able and reproducible manner through qualifica-
tion testing, based on the requirements specifica-
tion documents, including the documentation and

testing of system components, subsystems, inter-
faces, and data conversion programs defined in
the design specification documents
• Identifying the need for creating/updating Standard
Operating Procedures (SOPs), desktop procedures,
and manuals to reflect the actual use of the system
• Identifying the need for creating and implement-
ing a training program for all users of the R/3
system enterprise project
• Defining the strategy for creating a file of evidence that
demonstrated managerial control of the R/3 system
(through the use of our change control procedure).
There are five major phases needed to implement
this type of software according to what is called
“The SAP methodology.”
Phase I: Project Preparation – Project Plan and Scope
Definition
The primary focus of Phase I was placed on getting
the project started, identifying team members, and de-
veloping a high-level plan. The kickoff meeting was
extremely important – it was then that the project team
and process owners got a clear sense of what their re-
sponsibilities were to be throughout the project. Phase
I included:
• Training the ASAP principles
• Identifying key deliverables
• Defining the project team and roles
• Development of a high-level project plan
• Technical requirements planning
Phase II: Business Blueprint
The primary focus of Phase II was placed on under-
standing the business goals of the company, and deter-
mining the business requirements needed to support
those goals. Phase II included:
• Organizational structure
• Signed off business blueprint (requirements document)
• Generation of a business process master list
• Enterprise scope document
• Baseline scope document
Phase III: Realization
The purpose of Phase III was to develop a “future-
state” model into an integrated and documented solu-
Jackelyn Rodriguez
tion that would fulfill our business process require-
ments. Phase III included:
• Baseline configuration
• Company structure and business rule definition
• Business scenarios
• Confirmation and approval
• Final configuration
The configuration of each core business process
was divided into iterations or cycles of related, “busi-
ness process flows.” The business process flows were
configured in parallel with the development of reports,
user procedures, testing scenarios, and security pro-
files. The cycles not only provided milestones for the
project team, but also provided checkpoints to test a
“playback” of specific parts of the overall business pro-
cess. This approach provided immediate feedback, and
involved the entire organization throughout the project
lifecycle. At this point, our team started looking at the
process procedures, and began their training.
Additional key deliverables for this phase included:
• Developing interfaces, reports, and conversions
• Business process playback and approval
• Rapid configuration and testing of core business
processes
• Authorizations setup
• Establishing the production environment
• Establish the design, develop and test interfaces,
reports, and conversions
• Develop integrated and documented solutions
through cycles
• Authorization and system administration
Phase IV: Final Preparation
The primary focus of Phase IV was placed on com-
pleting the final system testing, training end-users, and
cutting over both the data and the system to a produc-
tion environment. Final system testing included con-
version procedures and programs, testing interface
programs, conducting volume and stress testing, and
final user acceptance testing. (User acceptance tests
were included in the final system testing.)
Another focus of this phase was developing a Go-
Live strategy. This plan specifically identified the
data conversion strategy, initial audit procedures, and
a project team support structure. The final step was to
May 2003 • Volume 9, Number 3 207
Jackelyn Rodriguez
approve the system and the readiness of the compa-
ny to go live, and to officially turn on the new ERP
system, and to fully train end-users. Phase IV includ-
ed the following items:
• Cut-over plan
• End-user training
• Integration, volume, and stress testing
• Go-live strategy (The existing ERP system was
maintained “alive” during this period in the
event that cut-over activities failed)
• Establish internal help desk
• Cut-over to production environment
• Performance Qualification (PQ)
Phase V: Go Live and Support
After “go-live,” our team focused on supporting
the end-users. Each day, the business results and sys-
tem performance were measured and reviewed per
PQ requirements. (PQ requirements included the ver-
ification of performance against intended use), and
training continued for all levels. Business process
procedures, preformatted generic process word-tem-
plates generated via ASAP, were used to provide de-
tailed instructions to the user on how to execute trans-
actions within SAP.
Development, Implementation
and System Configuration
Requirements
A documented software requirements specification
provided a baseline for both validation and verification.
The software validation process cannot be completed
without an established software requirements specifica-
tion (Ref: 21 CFR 820.3[z] and [aa] and 820.30[f] and
[g]). (http://www.fda.gov/cdrh/comp/guidance/938.pdf)
Typically, ERP packages enable an organization to
truly function as an integrated organization. This
includes integration across all functions or segments
of the traditional functions, such as sales order, pro-
duction, inventory, purchasing, quality management,
measurements systems, etc. Because these are typi-
cally included in the original requirements for the
SAP ERP package, the only real software require-
ments were developed for custom codes. Our new
ERP system handles all types of business functions,
and links their related business tasks. With its exten-
208 Journal of Validation Technology
sive functionality and high-level of integration, this
system meets a full range of business requirements,
including financial accounting and controlling, sales
and distribution, materials management, production
planning, and human resources. Each type of business
requirement was broken into what SAP refers to as a
business process module. The system can be imple-
mented with as little as one module, or a combination
of modules, and still provide the integrated business
functionality. We decided on a phased approach to
implementation, implementing several modules in
each phase.
System Environment
The new ERP system is based on client-server
architecture. The basic system environment will
remain constant over its life span at the company. It
consists of three separate physical environments, or
in SAP terminology, instances; a development
instance, a test instance, and a production instance.
Each instance contains at least one client providing
a unique access into the ERP application and its cor-
responding database.
Development Instance
The development instance contained separate
clients providing individual environments for the
functional leads, configurators, data conversion team,
security team, and the other ERPimplementation con-
sultants. (Participants in the project included consul-
tants, as well as internal staff because of manpower
issues.) The purpose of the development instance was
to provide a safe and separate environment where
development activities (configuration, data conver-
sion, interface programs, and security profiles) could
take place. The separate clients on the development
instance further ensure that individual development
activities affect only the area being developed.
Consultants configured a “baseline” R/3 system rep-
resenting the business processes identified in the busi-
ness blueprint phase. Then they would playback key
transactions to process owners. This playback of busi-
ness processes to the project team allowed for feedback,
as well as further confirmation that the requirements
defined in the business blueprint were being met.
To ensure all clients are virtually identical (devi-
ations between clients were reviewed and addressed
by the project team on a case-by-case basis), the

clients were refreshed weekly to include the latest
system configurations. All development activities
and initial unit testing took place in the development
instance.
Test Instance
The test instance contained several clients similar
to the development instance. These clients provided
separate environments for preliminary integration
testing, data conversion and interface testing, and
ultimately, the qualification testing required for vali-
dation. A client was available for use in the training
of end-users. The purpose of the test instance was to
provide an environment where only testing and train-
ing could occur. This ensured that in the event of an
error during testing, the development and production
work is never compromised.
Production Instance
The production instance contained a single client.
This client was a replica of the test instance client upon
which validation testing is performed. All updates to
the production client were handled through change
control procedures. This process involved system con-
figuration or application of software patches in the
development instance, validation testing in the test
instance, and upon successful completion of testing,
transporting the updates to the production instance
client. (In the event that a test failed, it was permissible
to allocate non critical failures to an issue-tracking sys-
tem for later resolution, the change control process
starts again, beginning in the development instance.)
The purpose of the production instance was to support
day-to-day operations. (The difference between config-
uration management and change control is that once
the system is approved, all changes must go through
the approved change control process.
Validation Approach
Although FDA’s guidance does not recommend the
use of a specific lifecycle model, we established a soft-
ware lifecycle model that was appropriate for our or-
ganization, as well as compliant with FDA’s General
Principles of Software Validation Guidance document.
Adetailed assessment of the SAPmethodology against
the design control regulation, or the software valida-
tion guidance, was completed when the master valida-
Jackelyn Rodriguez
tion plan was generated and approved.
As the new ERP system was in the developmental
stage until Phase IV, validation testing and end-user
training, and some validation deliverables, did not re-
ceive final approval signatures until the system
reached Phase IV and was considered “frozen.” Each
deliverable, however, began development in the desig-
nated phase. All documents that were developed car-
ried a computer-related system validation number and
a version number. Once approved, all changes to de-
liverables were completed in accordance with the
SOP, maintenance of the validated system, ongoing
evaluation, and change control procedures. The origi-
nals of all validation deliverables were filed in the val-
idation history file. They included the following items:
Validation Deliverables
• Project planning
• Validation project plan
• Vendor audit
• High-level requirements specification
• System requirements and design specification
(blueprint)
• Master list of business process procedures,
• Business process procedures
• Process flow diagrams
• Test scripts
• SOPs, user, and system manuals
• Installation Qualification (IQ) and Operational
Qualifications (OQ) – test instance
• Installation Qualification (IQ) and PQ – produc-
tion instance
• Data conversion protocol – test and production
instances
• Training documentation
• Summary reports
• Certificate of validation
• Change control forms and testing documentation
Validation Activities
Project Planning
During the project planning phase, the R/3 system
project and its boundaries were defined, and an im-
plementation approach was developed. A project plan
was created to outline project tasks, duration, and
responsibilities. Throughout the project implementa-
tion, the project plan was updated to reflect the cur-
rent state of project tasks.
May 2003 • Volume 9, Number 3 209
Jackelyn Rodriguez

The validation project plan was created to outline System Requirements and Design Specification (Blue-
the approach, deliverables, and responsibilities to com- print)
plete validation tasks necessary for the implementation This phase defined general system needs required
of the ERP system. of an ERP system intending to cover the functional
areas. A high-level requirements specification docu-
Vendor Audit ment was developed to outline the desired system
A software quality assurance evaluation was con- structure, operation, and system interfaces. The high-
ducted to support ongoing process
and quality improvement efforts by
SAP AG (i.e., the company) relative ❝Functional requirements specify
to the development and support of
its R/3 software product. In addi- what the system must do. They
tion, it is intended to provide docu-
mented evidence to directly and
relate to the actions that the
proactively support selected valida- system must carry out in order
tion activities required of those
SAP clients whose R/3 applications to satisfy the fundamental
are used to perform or support pro-
cess functions subject to regulation
reasons for its existence… ❞
by the Food and Drug Administra-
tion (FDA). The audit results were satisfactory. level content of this document was intended to pro-
vide a “big picture” of what was required of the sys-
High-Level Requirements Specification tem. The development of the high-level requirements
Functional requirements specify what the system specification document was the responsibility of the
must do. They relate to the actions that the system project managers and the corresponding functional
must carry out in order to satisfy the fundamental leads.
reasons for its existence. They include: The Design Specifications (DS) were prepared to
describe how the requirements specifications were
• Specifications of the system’s functionality implemented. Elements addressed in the design spec-
• Actions the system must take-check, calculate, ification included:
record, retrieve
• Derived from the fundamental purpose of the • System hardware
system. • Application servers
• Nonfunctional requirements are the properties • Database servers
that the system must have. For example, these • SAP Graphical User Interface (GUI) workstations
are the characteristics or qualities that make the • System software
system usable, fast, secure, or reliable. • Operating system
• Global requirements are broad, encompassing re- • Database
quirements, or a constraint on the system. Global • Application software
requirements may: • System performance
• Network connectivity
– Be described in a very broad language • Remote access
– Describe a characteristic of the entire system • Security
– Reflect a general need of all potential users • Physical security
– Constrain the design or use of the system • Logical (SAP application security)
• Configuration
These high-level requirements are detailed fur- • Application extensions
ther in the system requirements specification. • Business processes

210 Journal of Validation Technology


System Design
This phase included the initial design of the sys-
tem environment, a more detailed definition of re-
quirements, and the beginning of system configura-
tion. A detailed requirements and design specifica-
tions document was created as part of this phase. The
functional leads, configurators, basis administration,
and QA-Validation personnel together provided the
input to complete this document.
Detailed system requirements were defined for
each of the functional areas. The requirements then, at
a minimum, defined process descriptions and the se-
quence of operations for each of the functional areas,
and their corresponding sub-components. The outline
for the functional content was based on SAP’s defini-
tion and terminology of the make up of each of our
major ERPmodules. This approach was taken to facil-
itate the documentation of future module upgrades
within the new ERP system.
System design specifications were created to clear-
ly and completely document the new ERP system’s
operating environment, interfaces, security, and func-
tionality. Additional configurations were performed as
needed to address requirements outside of the “off-the-
shelf software package.” Any parameters that could
have an effect on the system performance were identi-
fied, including the definition of acceptable values or
characteristics for the parameters.
It was extremely important that the design speci-
fications addressed all of the defined requirements.
A one-to-one reference was established between the
requirements and the design specifications through a
traceability matrix.
Traceability Matrix
Based on the requirements specification, MiniMed
compiled a Business Process Master List (BPML),
which identified all business activities supported by the
system. This list was composed in order to develop
Business Process Procedures (BPPs), which described
the use and function of the system required to support
MiniMed’s business.
Controls were established to provide traceability of
requirements to system setup and configuration through
to testing strategy. This was achieved as follows:
• The strategy used for the Quality System Reg-
ulation (QSR) (more generally referred to as
Jackelyn Rodriguez
Good Manufacturing Practice [GMP]) impacted
transaction codes (t-codes) was as follows:
– All t-codes to be utilized by MiniMed were
reviewed for GMP impact and categorized
as high, medium, or none. This document
is generated from the BPML.
High Impact
Transaction codes (T-codes), determined to have
high GMP impact, were further reviewed at the indi-
vidual field level to identify those fields that had
GMP impact. The fields to be reviewed were only
those that would be utilized per department work
instructions for Phase I implementation.
The fields of t-codes with high GMP impact had
negative testing performed as part of the validation.
Medium Impact
T-codes with medium GMP impact were tested to
verify proper functionality, and the results recorded
for validation purposes.
No Impact
T-codes with no GMPimpact were tested for prop-
er functionality for business purposes, but the results
of this testing were not required to be part of the val-
idation package.
Testing strategies and scenarios were based on
the outcome of this assessment.
Test scripts were pre-approved, and information
contained in the BPP’s was utilized fully.
The validation test effort, including GMP/QSR
critical test scripts, any deviations or non-confor-
mances, and test results were controlled by OQ pro-
tocols. All t-codes were functionally tested for busi-
ness purposes.
Data Conversion
Data conversion programs were verified and vali-
dated as data was compared during the data conver-
sion process verification. The verification was per-
formed by teams of two who reviewed the same sam-
ples of data records.
It is important to remember that data conversions
were not part of the functionality intended for every-
day use in SAP. Instead, the data conversions were
processes performed by expert individuals in a high-
ly-controlled environment.
May 2003 • Volume 9, Number 3 211
Jackelyn Rodriguez

Our data conversion process usually involved the
following steps:
Data Mapping
During this exercise, the relationship between
data in the legacy and SAP systems were defined at
the field level. This activity resulted in a data map
for each conversion effort.
Data Cleansing
In order to ensure the quality of the data being
transferred, we examined the data undergoing con-
version for issues, such as redundant records, dupli-
cate records, referential integrity, and typographical
errors. These issues were corrected on a case-by-case
basis. This process often involved significant manual
effort.
• Statement of acceptability of the converted data.
Validation Activities
System Configuration
The system configuration phase included the con-
figuration of the system as defined in the high-level
requirements specification and detailed require-
ments and design specifications documents. System
administration procedures were developed for gen-
eral system administration, security profiles, data
retention, and change control. As individual module
configuration was completed, BPPs were developed
to define the necessary procedures for each of the
processes (i.e., detailed description of how to exe-
cute a transaction). Refer to Figure 2.

Conversion/Migration Validation Plan

The conversion process involved the transfer of
1. SOPs and System Procedures for ERP
cleansed data from the legacy system to SAP, Manuals System Administration
according to the rules defined in the data map. 2. IQ – Test Instance Documents System
Environments
Inspection/Verification 3. OQ – Test Instance ERP System – (per mod-
ule), (Forecast to Finish
After the conversion process was run, the data [FF] Goods, Purchase to
was inspected to ensure that it was properly convert- Payment [PP], Quality
ed (in accordance with business rules and the data Module [QM], Financial/
map). The inspection process was based on approved Collections Module
[FI/CO]) Security, System
methodology, and the results were recorded. Administration, and
Converted data was subjected to inspection and System Interface testing
verification. 4. OQ – Test Instance R/3 System Reporting –
Each record type (in SAP) was considered a sep- On screen and hard
copy reporting verifica-
arate population for the purpose of sampling plans. tion
A single individual, using printouts from at least 5. IQ – Production Instance Documents system envi-
the legacy and SAP systems, performed an inspec- ronment
tion of the data. The inspections were recorded by the 6. PQ – Production Instance Documents system per-
inspector’s signature on each page of these printouts. formance
7. Data Conversion Protocol Documentation and veri-
In addition to inspection of random samples from fication of automatic and
migrated data, all conversions were subject to verifi- manual data conversions
cation through record counts. Records were counted in both the test and pro-
in the legacy and SAP systems. duction instances
Installation Qualification (IQ)
Conversion Summary Report The IQs documented the system environment of
For each data conversion effort, a summary report the test instance. Hardware and software test scripts
was produced. The report included the following: were developed. This included:

• The data map • Master file documentation

• All required printouts for data conversion • Procedure verification
• Data inspection records • Hardware configuration and inventory verification

212 Journal of Validation Technology


• Connections and cabling
• Power supply requirements verification
• Disk array maintenance
• Training and documentation verification
Operational Qualification (OQ)
The OQ focused on a complete test of the system
and any of its system interfaces. This included the unit
(individual per function test scripts) and integration
(integration testing and functionality combined) test
scripts developed by the functional process owners.
(Please see attached test script example i.e., Figure 2)
The OQ consisted of verifications and tests to en-
sure that all components of the SAP R/3 system operat-
ed properly according to system specifications, change
requests (if any), and vendor documentation.
The tests to be executed under this protocol were
divided into the following categories:
• Procedure verification
• Business process procedure verification
• Process Flow Diagram (PFD) verification
• Validation database setup verification
• General functions/Transaction verification
• Personnel education and training verification
All of the personnel involved in the creation of
BPPs and test scripts underwent training on how to
develop/create such documents.
This ensured not only a greater understanding of
the systems, but also gave daily users an opportunity
to practice the use of the new transactions, as well as
provided awareness on how their transactions affect-
ed other functional areas, and to verify system con-
figuration. Also included were system administration
test scripts written by the basis administration (con-
sultants) team and QA-validation, covering the areas
of stress/volume testing, security, audit trails, archiv-
ing functionality, and backup and recovery. (The
consulting team helped generate 80% of the test
scripts).
Performance Qualification (PQ)
The PQ monitored the new ERP system perfor-
mance on the production instance, including the
ongoing data transfers from existing legacy systems
to the ERP system, (This was performed once the
system went live).
Jackelyn Rodriguez
Data Conversion Protocol
A separate protocol was developed to document
the data conversion methodologies, and verify data
transported from the existing legacy systems to the
new ERP system. In order to adequately test the new
systems functionality, the data conversions occurred
on both the test and production instances.
The conversion for the test instance included all of
the automatic data transfers, and a limited sample of
manual data conversions that mimicked (at a smaller
scale) the production environment. For the production
instance, full automatic data conversions and full man-
ual data conversions took place. In both instances, a
single sampling plan was created for each data conver-
sion to ensure data integrity. Typically, it is QA-Val-
idation that is responsible for ensuring protocols are de-
veloped with the functional leads, configurators, basis
administration, and basis conversion teams. (Please
refer to page 215 for conversion strategy details).
At the end of the system configuration phase, a dry
run (informal validation testing) was conducted on
the test instance using draft qualification protocols.
Once the dry run was completed, appropriate changes
were made to the validation deliverables, and if nec-
essary, to the system configuration.
Validation Deliverables:
Validation deliverables included:
• SOPs user manuals (SOPs were a validation de-
liverable because references to the old ERP sys-
tem transactions were included within the SOPs.
In order to ensure that all old references were
removed, the new references to the new PFD,
which included the new BPP transaction code
numbers, had to be included as a deliverable).
• Procedures for functional areas
• Training documentation showing appropriate
training materials and documentation of train-
ing for system users
• Summary report summarizes the testing results
of the qualification protocols
• Summary report summarizes entire validation effort
• Validation Certificate (a Validation Certificate
is required per ASAP methodology upon com-
pletion of this phase). The certificate states that
the R/3 system consistently performs according
May 2003 • Volume 9, Number 3 213
Jackelyn Rodriguez
to the user’s requirements for the system
• Change control forms and testing documentation.
Change control documents and supporting test
documents showing control of the change pro-
cess, as defined in the SOP, maintenance of the
validated system, ongoing evaluation, and change
control procedures
Validation Testing and End-User Training
Validation testing and training took place during
this phase. Training materials were finalized, includ-
ing the development of user manuals and modifica-
tions of any SOPs affected by the implementation of
the new ERP system. Training of end-users occurred
prior to the start of the system implementation and
ongoing support phase.
The bulk of validation testing took place on a client,
(i.e, the computer station, that was set-up for validation
testing in the test instance). This validation client was
an exact replica, with respect to system configuration,
of the production client on the production instance. An
IQ and two OQs (of the new system functionality and
reporting) were executed on the validation client of the
test instance, followed by an IQ on the production
client of the production instance.
Testing
Testing was performed to document and confirm
that the implemented system satisfied requirements
and design intent. All tests were traced to require-
ments and business processes. The testing process
included the following categories:
• SAP environment verification
• Workstation verification
• Test system verification
• Application extension verification
• GMP business process verification
• Security verification
• Operational support verification
• Production system verification
• Production evaluation verification
A release to the validation memorandum was ap-
proved before installation and verification were per-
formed in the test environment. Pertinent executed
installation tests were approved before operational
testing occurred in the test environment. A release to
214 Journal of Validation Technology
production memorandum was also approved before
installation and verifications were performed in the
production environment. Pertinent, executed installa-
tion tests were approved before performance testing
occurred in the production environment.
Test Plans and Test Cases
Our software test plans were test cases developed
using the blue printing requirement, which generat-
ed what we called the BPML. This list included
every single transaction code that was used as a
checklist to correlate transaction codes with test sce-
narios. This also included the cGMP impact assess-
ment. This list was also used for comparison to the
process flow diagrams (see Attachment 1), that were
also part of the blueprinting process. As a result, our
software validation testing appropriately matched
the risk associated with the system.
“Real World” Testing
FDA’s software validation guideline1 document
recognizes that “software is designed, developed, val-
idated and regulated in a real world environment.”
Because of that, during testing, it was important to
consider what level testing was appropriate, and if all
of the “high risk” software integration scenarios were
considered, tested, and challenged when designing the
software validation. Levels of no-impact, medium, and
low were assigned according to GMP impact. Single
unit testing was performed on transactional code out-
side the scope of validation testing.
GMP/QSR Impact and Test Script Preparation
The extent of testing for any business process or
transaction should be determined by the degree of
GMP/QSR impact for that process. The GMP/QSR im-
pact was recorded in the BPML. The following guide-
lines can be followed in the determination of extent of
validation testing for any business process or transaction:
GMP/Q Validation testing
SR impact
No Impact No validation testing performed
Medium Verify the transaction performs in nor-
mal (ideal) situations
High Verify the transaction performs in nor-
mal (ideal) situations.Also verify proper
operation of all system functions and
controls, which have GMP/QSR impact
through challenge (negative) testing.
 Jackelyn Rodriguez

GMP Business Process Verification and software configurators to address deviations and
GMP business process testing was designed to en- closure in order to complete the test script process.
sure that the integrated business processes work in
accordance with the process flows, configuration spec- GMP Business Process Verification
ifications, and the functional/design specifications. Our GMP business process testing (see Attachment
This verification included positive and negative tests. 3 for an example of a test script) was designed to en-
Positive tests challenged the normal business process. sure that the integrated business processes worked in
Negative tests introduced challenges to the execution accordance with the process flows (see Attachment 1)
of the normal business process. These challenges in- configuration specifications, and the functional/design
cluded, but were not limited to, entering invalid data specifications. This verification included positive and
and out-of-sequence transactions. negative tests. Positive tests challenged the normal
Based on the requirements specification, we com- business process. Negative tests introduced challenges
piled a BPML that identified all business activities to to the execution of the normal business process. These
be supported by the system. This list was composed challenges included, but were not limited to, entering
in order to develop BPP’s, which described the use invalid data and out-of-sequence transactions
and function of the system required to support our
business. Security Verification
The strategy that was used for QSR (generally Security testing was designed to verify that the
referred to as GMP) impacted transaction codes (t- implemented SAP security architecture functioned
codes) was as follows: in accordance with security specifications. This test-
ing was executed for the following two areas:
Business Process Master List
❶ Transaction access
Area Business Process Transaction GMP
Procedure Title ❷ Integrated business scenarios
Number Deficiencies Code Impact
Transaction access demonstrated the proper oper-
FX Convent Planned Order to ABCXX1 Med
Production Order – ation of the core transaction protection object, and
Individual configuration of activity groups. In this testing, the
FX Collective Conversion ABCXX2 Med following was demonstrated for each tested activity
of Planned Orders group (roles):
FX Conv.plan.ord.to ABCXX3 Hi
prod.ord.part.redct
• Transactions required for the activity group
FX Display Material Bills ABCXX4 Med
of Materials (BOMs) (roles) were accessible
FX Display Allocation ABCXX5 Med • Transactions not required for the activity group
to Plant (roles) were not accessible
FX Multilevel Billing of ABCXX6 Hi
Materials During security validation scenarios, the business
FX Summarized Billing ABCXX7 Med processes were executed with users assigned to the
of Materials
designed profile in the SAP user master record. This
This example was created using the BPML gener- process verified that the security model was correct-
ated as part of the ASAP implementation method- ly configured to permit the execution of SAP tasks
ology. Each business process listed is a process that using their assigned role.
was implemented during our ERP implementation
Because our software validation activities and Data Conversions
tasks were dispersed, occurring at different locations, The data conversion protocol was executed on
and were conducted by different organizations, we both the test and production instances. This was typ-
used QA teams to oversee all testing activities, inc- ically the responsibility of the functional leads, con-
luding recording deviations, working with testers, figurators, and basis administration and conversion

May 2003 • Volume 9, Number 3 215

Jackelyn Rodriguez
teams, as well as functional area super-users to assist
and execute these qualification protocols. (This in-
cluded data maps, data conversion verifications, and
record counts).
In the event a discrepancy occurred during testing,
an evaluation of the discrepancy was made as to the
level of severity, and a decision was made to contin-
ue testing using change control procedures, or to halt
testing until a resolution was found. The discrepancy,
evaluation, and decision to proceed or halt testing was
documented in the testing log of the associated quali-
fication protocol.
Upon completion of the qualification protocols, a
summary report for each protocol was developed.
The reports detailed the results of the qualification
testing.
Business Process Procedures and Test Script Training
The purpose of this was to demonstrate that BPPs
and test script writing was sufficiently understood,
and training was performed with the end users.
Training documentation for all personnel that were
tasked with writing test scripts attended the briefings
and workshops was required. The following table
included some of the minimum training requirements:
Description
Overview
• BPPs and Test Scripts
• Testing and Validation
Test Script
Test Script Control Log
BPPs and Test Script Workshop
• Business Process Procedures (See Attachment 2)
• Test Script Example (See Attachment 3)
• Template
• Sign In Sheets
• Deviation Logs
Upon successful completion of the above training
activities, test script writing commenced.
System Implementation and On-Going Support
During this phase, the project team needed to
maintain control of the system, while allowing for a
continuous improvement process. In our case, the
new ERP system was maintained in a validated state
through our change control process, as well as con-
figuration management. Required revalidation was
evaluated, and occurred for any new implementation
216 Journal of Validation Technology
phase, development of an interface from an existing
system to the new ERP system, or validation for a
new software release. In each case, the existing val-
idation deliverables were referenced with additional
deliverables created to document new features (and
corrections) and their interrelationships.
Processes for the development, use, operation, and
maintenance of the ERPcomputer system also included:
• Maintenance
• Backup
• Record retention
• Virus protection
• Startup and shutdown
• Problem reporting and tracking
• Performance monitoring
• Transports (changes to the current system)
Once the system was approved and validated, all
changes underwent a review and approval process to
ensure that all testing was completed. Additional func-
tionality testing was performed whenever changes,
updates, and/or upgrades needed to be made. Ex-
amples included:
❶ Basic functional testing of PROD (the produc-
tion environment) after a Hotpack installation is
complete
❷ A change to a transactional code configuration
Specific testing requirements needed to be identi-
fied in order to install the latest kernel update. These
types of tests must be conducted to ensure the system
is performing as expected and data integrity is not
compromised. All original documents should be filed
in the Validation History File as they are completed.
Once the system was online in the production envi-
ronment, the PQ was executed, and the system perfor-
mance was monitored for a period of no less than three
weeks. Any disruptions to the system performance
were documented in the testing log of the PQ.
Following the specified time minimum duration, the
Summary Report for the PQ was completed, which
summarized the results of the initial monitoring period.
A final Summary Report was then generated to sum-
marize the results of all validation activities for the new
ERP system. Upon approval of the final Summary
Report, a validation certificate was issued. ❏
 Jackelyn Rodriguez

➲
About the Author
Jackelyn Rodriguez is Director, Quality Systems and
Regulatory Compliance for Medtronic MiniMed. She
has 19 years experience in all facets of quality assur-
ance and regulatory compliance. She specializes in
International and U.S. regulations, which define quali- Attachments are presented on the following pages
ty systems, design control, CE-marking, risk manage-
ment, medical device reporting, post-market surveil-
lance and vigilance. She also has extensive knowl-
edge of 21 CFR Part 11, as well as HIPAA require-
ments. Ms. Rodriguez holds a BS in Business Man-
agement, and is a certified member of the Board of
Examiners for the Malcolm Baldrige National Quality
Award program, and an ASQ Certified Quality Article Acronym Listing
Auditor. She has written articles for the Journal of ASAP: Accelerated System Application and
CGMP Compliance, and has been quoted in the sev- Products
eral Medical Device related journals, such as the Gold BOM: Bill of Materials
Sheet, and the Gray/Silver Sheet. She can be reached BPML: Business Process Master List
by phone at 818-576-5624, by fax at 818-576-6266, BPP: Business Process Procedures
and by e-mail at jackelyn.rodriguez@minimed.com. CFR: Code of Federal Regulations
cGMP: Current Good Manufacturing Practice
Reference DS; Design Specification
1. FDA. Software Validation. http://www.fda.gov/cdrh/comp/ ERP: Enterprise Resource Planning
guidance/938.html.
FDA: Food and Drug Administration
Suggested Reading FF: Forecast to Finish
• FDA. General Principles of Software Validation; Final Guidance FI: Financial Accounting/Asset
for Industry and FDA Staff. January 11, 2002. Accounting
FI/CO: Financial/Collections Module
GMP: Good Manufacturing Practice
GUI: Graphical User Interface
HR: Human Resources
IQ: Installation Qualification
IT: Information Technology
MM: Material Management
OQ: Operational Qualification
PFD: Process Flow Diagram
PO: Purchase Order
PP: Production Planning
PP: Purchase to Payment
PQ: Performance Qualification
PVP: Process Validation Plan
PVR: Process Validation Report
QA: Quality Assurance
QSR: Quality System Regulation
RFQ: Request for Quotation
SAP: System Application and Products
SD: Sales and Distribution
SDVLC: Software Development Lifecycle
SOP: Standard Operating Procedure
T-Code: Transaction code

May 2003 • Volume 9, Number 3 217

Jackelyn Rodriguez

218 Journal of Validation Technology

 Jackelyn Rodriguez

Attachment 2
Display Allocation to Plant
Business Process Procedure
Revision Description ECO Number Prepared by Released By Date Released
New Release

This document contains information, which is the property of MiniMed Inc..This document may not, in whole or in part, be
duplicated, disclosed, or used for design or manufacturing purposes without the prior written permission of MiniMed Inc.
Reviewer: Date:

Requester/Author Date:

Process Owner: Date:

Quality Assurance: Date:

Overview: Display Allocation to Plant

1. Purpose and Scope
Business Process Procedures Overview
To display specific material BOM based on plant allocation.

Input – Required Fields Field Value/Comments

Material Input requested BOM Part Number
Plant Input Primary Plant Location
BOM Usage

Output – Results Comments

Displays primary plant location
for specified BOM

2.Tips and Tricks

Not Applicable.

Attachment 2 (Continued)

May 2003 • Volume 9, Number 3 219

Jackelyn Rodriguez

Attachment 2 (Continued)
Overview: Display Allocation to Plant
2.1. Step 1.1: Access transaction by:
Via Menus Logistics>Production>Master Data>Bill of Material>Material
BOM>Plant Assignment
Via Transaction Code CS09
2.2. Step 1.2: On screen “Display Plant Assignment: Initial Screen,” enter information in the fields as
specified in the table below:
Field Name Description R/O/C User Action and Values Comments
Material Part Number R Input Part Number
Plant Applicable Plant R Input Applicable
BOM Usage Indicates which R Use Drill Down to Determine
applicable BOM Application

Required/Optional/Conditional (ROC) Required (R) Optional (O) Conditional (C)

Note: All remaining fields need to be left as is.
2.3. Step 1.3: Click on the Enter Button ✓
2.4. Step 1.4: Results of the Display

CS09 Display Allocation to Plant _ Microsoft Word

Plant assignment Edit Undo Extras System Help SAP

DISPLAY PLANT ASSIGNMENT: CURRENT ALLOCATIONS

All allocs to BOM

BOM 000000016
BOM Usage 1 Production

Material allocations – BOM

1 07004110-001 1001

CS09 sapdev01 INS

2.5. Step 1.5: After viewing necessary information, click on the to return through the previous
screen to main menu

220 Journal of Validation Technology

 Jackelyn Rodriguez

Attachment 3
Unit Test Script Example
Opportunity to Cash Purchase to Payment
Monthly Finance Forecast to Finished Goods
Test Script Plan Approval
By Name (Please Print) Signature Date
Reviewed By:
Quality Assurance Approved By:
BPP Reference BPP Step Required Expected Actual Screen Tester OK
Step Description Field Results Results Print Date
Required?
BPP1ME21N.1 1.6 Adopt purchase Purchase req: Information from Y
requisition to purchase requisition
purchase order copied to purchase
order being created
BPP1ME21N.1 1.7 Add vendor Vendor Number: Document type de- N
information faults as Standard
PO. Document Date
defaults to today’s
date
BPP1ME21N.1 1.8 Enter organiza- Enter Purchasing Data entered N
tional data Group: 001
Purchasing Organ-
ization: 1000
Company Code: 0010
BPP1ME21N.1 1.9 Enter Item Data Net Price: $10.00 Other required Y
Currency: USD data defaults
Plant: 1001
BPP1ME21N.1 1.12 Enter Item Details Tax Code: PH Data entered Y
BPP1ME21N.1 1.13 Save Purchase Purchase Order Purchase Order Y
Order created Number:

Test Completion Results Passed Failed Corrected, Retested, and Passed

Test Script Results Approval
By Name (Please Print) Signature Date
Reviewed By:
Process Owner Approved By:
Quality Assurance Approved By:

May 2003 • Volume 9, Number 3 221