Professional Documents
Culture Documents
❖
edtronic MiniMed is the MiniMed selected the SAP R/3
testing of system components, subsystems, inter- tion that would fulfill our business process require-
faces, and data conversion programs defined in ments. Phase III included:
the design specification documents
• Identifying the need for creating/updating Standard • Baseline configuration
Operating Procedures (SOPs), desktop procedures, • Company structure and business rule definition
and manuals to reflect the actual use of the system • Business scenarios
• Identifying the need for creating and implement- • Confirmation and approval
ing a training program for all users of the R/3 • Final configuration
system enterprise project
• Defining the strategy for creating a file of evidence that The configuration of each core business process
demonstrated managerial control of the R/3 system was divided into iterations or cycles of related, “busi-
(through the use of our change control procedure). ness process flows.” The business process flows were
configured in parallel with the development of reports,
There are five major phases needed to implement user procedures, testing scenarios, and security pro-
this type of software according to what is called files. The cycles not only provided milestones for the
“The SAP methodology.” project team, but also provided checkpoints to test a
“playback” of specific parts of the overall business pro-
Phase I: Project Preparation – Project Plan and Scope cess. This approach provided immediate feedback, and
Definition involved the entire organization throughout the project
The primary focus of Phase I was placed on getting lifecycle. At this point, our team started looking at the
the project started, identifying team members, and de- process procedures, and began their training.
veloping a high-level plan. The kickoff meeting was Additional key deliverables for this phase included:
extremely important – it was then that the project team
and process owners got a clear sense of what their re- • Developing interfaces, reports, and conversions
sponsibilities were to be throughout the project. Phase • Business process playback and approval
I included: • Rapid configuration and testing of core business
processes
• Training the ASAP principles • Authorizations setup
• Identifying key deliverables • Establishing the production environment
• Defining the project team and roles • Establish the design, develop and test interfaces,
• Development of a high-level project plan reports, and conversions
• Technical requirements planning • Develop integrated and documented solutions
through cycles
Phase II: Business Blueprint • Authorization and system administration
The primary focus of Phase II was placed on under-
standing the business goals of the company, and deter- Phase IV: Final Preparation
mining the business requirements needed to support The primary focus of Phase IV was placed on com-
those goals. Phase II included: pleting the final system testing, training end-users, and
cutting over both the data and the system to a produc-
• Organizational structure tion environment. Final system testing included con-
• Signed off business blueprint (requirements document) version procedures and programs, testing interface
• Generation of a business process master list programs, conducting volume and stress testing, and
• Enterprise scope document final user acceptance testing. (User acceptance tests
• Baseline scope document were included in the final system testing.)
Another focus of this phase was developing a Go-
Phase III: Realization Live strategy. This plan specifically identified the
The purpose of Phase III was to develop a “future- data conversion strategy, initial audit procedures, and
state” model into an integrated and documented solu- a project team support structure. The final step was to
approve the system and the readiness of the compa- sive functionality and high-level of integration, this
ny to go live, and to officially turn on the new ERP system meets a full range of business requirements,
system, and to fully train end-users. Phase IV includ- including financial accounting and controlling, sales
ed the following items: and distribution, materials management, production
planning, and human resources. Each type of business
• Cut-over plan requirement was broken into what SAP refers to as a
• End-user training business process module. The system can be imple-
• Integration, volume, and stress testing mented with as little as one module, or a combination
• Go-live strategy (The existing ERP system was of modules, and still provide the integrated business
maintained “alive” during this period in the functionality. We decided on a phased approach to
event that cut-over activities failed) implementation, implementing several modules in
• Establish internal help desk each phase.
• Cut-over to production environment
• Performance Qualification (PQ) System Environment
The new ERP system is based on client-server
Phase V: Go Live and Support architecture. The basic system environment will
After “go-live,” our team focused on supporting remain constant over its life span at the company. It
the end-users. Each day, the business results and sys- consists of three separate physical environments, or
tem performance were measured and reviewed per in SAP terminology, instances; a development
PQ requirements. (PQ requirements included the ver- instance, a test instance, and a production instance.
ification of performance against intended use), and Each instance contains at least one client providing
training continued for all levels. Business process a unique access into the ERP application and its cor-
procedures, preformatted generic process word-tem- responding database.
plates generated via ASAP, were used to provide de-
tailed instructions to the user on how to execute trans- Development Instance
actions within SAP. The development instance contained separate
clients providing individual environments for the
Development, Implementation functional leads, configurators, data conversion team,
and System Configuration security team, and the other ERPimplementation con-
sultants. (Participants in the project included consul-
Requirements tants, as well as internal staff because of manpower
A documented software requirements specification issues.) The purpose of the development instance was
provided a baseline for both validation and verification. to provide a safe and separate environment where
The software validation process cannot be completed development activities (configuration, data conver-
without an established software requirements specifica- sion, interface programs, and security profiles) could
tion (Ref: 21 CFR 820.3[z] and [aa] and 820.30[f] and take place. The separate clients on the development
[g]). (http://www.fda.gov/cdrh/comp/guidance/938.pdf) instance further ensure that individual development
Typically, ERP packages enable an organization to activities affect only the area being developed.
truly function as an integrated organization. This Consultants configured a “baseline” R/3 system rep-
includes integration across all functions or segments resenting the business processes identified in the busi-
of the traditional functions, such as sales order, pro- ness blueprint phase. Then they would playback key
duction, inventory, purchasing, quality management, transactions to process owners. This playback of busi-
measurements systems, etc. Because these are typi- ness processes to the project team allowed for feedback,
cally included in the original requirements for the as well as further confirmation that the requirements
SAP ERP package, the only real software require- defined in the business blueprint were being met.
ments were developed for custom codes. Our new To ensure all clients are virtually identical (devi-
ERP system handles all types of business functions, ations between clients were reviewed and addressed
and links their related business tasks. With its exten- by the project team on a case-by-case basis), the
clients were refreshed weekly to include the latest tion plan was generated and approved.
system configurations. All development activities As the new ERP system was in the developmental
and initial unit testing took place in the development stage until Phase IV, validation testing and end-user
instance. training, and some validation deliverables, did not re-
ceive final approval signatures until the system
Test Instance reached Phase IV and was considered “frozen.” Each
The test instance contained several clients similar deliverable, however, began development in the desig-
to the development instance. These clients provided nated phase. All documents that were developed car-
separate environments for preliminary integration ried a computer-related system validation number and
testing, data conversion and interface testing, and a version number. Once approved, all changes to de-
ultimately, the qualification testing required for vali- liverables were completed in accordance with the
dation. A client was available for use in the training SOP, maintenance of the validated system, ongoing
of end-users. The purpose of the test instance was to evaluation, and change control procedures. The origi-
provide an environment where only testing and train- nals of all validation deliverables were filed in the val-
ing could occur. This ensured that in the event of an idation history file. They included the following items:
error during testing, the development and production
work is never compromised. Validation Deliverables
• Project planning
Production Instance • Validation project plan
The production instance contained a single client. • Vendor audit
This client was a replica of the test instance client upon • High-level requirements specification
which validation testing is performed. All updates to • System requirements and design specification
the production client were handled through change (blueprint)
control procedures. This process involved system con- • Master list of business process procedures,
figuration or application of software patches in the • Business process procedures
development instance, validation testing in the test • Process flow diagrams
instance, and upon successful completion of testing, • Test scripts
transporting the updates to the production instance • SOPs, user, and system manuals
client. (In the event that a test failed, it was permissible • Installation Qualification (IQ) and Operational
to allocate non critical failures to an issue-tracking sys- Qualifications (OQ) – test instance
tem for later resolution, the change control process • Installation Qualification (IQ) and PQ – produc-
starts again, beginning in the development instance.) tion instance
The purpose of the production instance was to support • Data conversion protocol – test and production
day-to-day operations. (The difference between config- instances
uration management and change control is that once • Training documentation
the system is approved, all changes must go through • Summary reports
the approved change control process. • Certificate of validation
• Change control forms and testing documentation
Validation Approach
Validation Activities
Although FDA’s guidance does not recommend the Project Planning
use of a specific lifecycle model, we established a soft- During the project planning phase, the R/3 system
ware lifecycle model that was appropriate for our or- project and its boundaries were defined, and an im-
ganization, as well as compliant with FDA’s General plementation approach was developed. A project plan
Principles of Software Validation Guidance document. was created to outline project tasks, duration, and
Adetailed assessment of the SAPmethodology against responsibilities. Throughout the project implementa-
the design control regulation, or the software valida- tion, the project plan was updated to reflect the cur-
tion guidance, was completed when the master valida- rent state of project tasks.
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
Our data conversion process usually involved the • Statement of acceptability of the converted data.
following steps:
Validation Activities
Data Mapping
During this exercise, the relationship between System Configuration
data in the legacy and SAP systems were defined at The system configuration phase included the con-
the field level. This activity resulted in a data map figuration of the system as defined in the high-level
for each conversion effort. requirements specification and detailed require-
Data Cleansing ments and design specifications documents. System
In order to ensure the quality of the data being administration procedures were developed for gen-
transferred, we examined the data undergoing con- eral system administration, security profiles, data
version for issues, such as redundant records, dupli- retention, and change control. As individual module
cate records, referential integrity, and typographical configuration was completed, BPPs were developed
errors. These issues were corrected on a case-by-case to define the necessary procedures for each of the
basis. This process often involved significant manual processes (i.e., detailed description of how to exe-
effort. cute a transaction). Refer to Figure 2.
to the user’s requirements for the system production memorandum was also approved before
• Change control forms and testing documentation. installation and verifications were performed in the
Change control documents and supporting test production environment. Pertinent, executed installa-
documents showing control of the change pro- tion tests were approved before performance testing
cess, as defined in the SOP, maintenance of the occurred in the production environment.
validated system, ongoing evaluation, and change
control procedures Test Plans and Test Cases
Our software test plans were test cases developed
Validation Testing and End-User Training using the blue printing requirement, which generat-
Validation testing and training took place during ed what we called the BPML. This list included
this phase. Training materials were finalized, includ- every single transaction code that was used as a
ing the development of user manuals and modifica- checklist to correlate transaction codes with test sce-
tions of any SOPs affected by the implementation of narios. This also included the cGMP impact assess-
the new ERP system. Training of end-users occurred ment. This list was also used for comparison to the
prior to the start of the system implementation and process flow diagrams (see Attachment 1), that were
ongoing support phase. also part of the blueprinting process. As a result, our
The bulk of validation testing took place on a client, software validation testing appropriately matched
(i.e, the computer station, that was set-up for validation the risk associated with the system.
testing in the test instance). This validation client was
an exact replica, with respect to system configuration, “Real World” Testing
of the production client on the production instance. An FDA’s software validation guideline1 document
IQ and two OQs (of the new system functionality and recognizes that “software is designed, developed, val-
reporting) were executed on the validation client of the idated and regulated in a real world environment.”
test instance, followed by an IQ on the production Because of that, during testing, it was important to
client of the production instance. consider what level testing was appropriate, and if all
of the “high risk” software integration scenarios were
Testing considered, tested, and challenged when designing the
Testing was performed to document and confirm software validation. Levels of no-impact, medium, and
that the implemented system satisfied requirements low were assigned according to GMP impact. Single
and design intent. All tests were traced to require- unit testing was performed on transactional code out-
ments and business processes. The testing process side the scope of validation testing.
included the following categories:
GMP/QSR Impact and Test Script Preparation
• SAP environment verification The extent of testing for any business process or
• Workstation verification transaction should be determined by the degree of
• Test system verification GMP/QSR impact for that process. The GMP/QSR im-
• Application extension verification pact was recorded in the BPML. The following guide-
• GMP business process verification lines can be followed in the determination of extent of
• Security verification validation testing for any business process or transaction:
• Operational support verification
• Production system verification GMP/Q Validation testing
SR impact
• Production evaluation verification
No Impact No validation testing performed
Medium Verify the transaction performs in nor-
A release to the validation memorandum was ap- mal (ideal) situations
proved before installation and verification were per- High Verify the transaction performs in nor-
formed in the test environment. Pertinent executed mal (ideal) situations.Also verify proper
installation tests were approved before operational operation of all system functions and
controls, which have GMP/QSR impact
testing occurred in the test environment. A release to through challenge (negative) testing.
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
teams, as well as functional area super-users to assist phase, development of an interface from an existing
and execute these qualification protocols. (This in- system to the new ERP system, or validation for a
cluded data maps, data conversion verifications, and new software release. In each case, the existing val-
record counts). idation deliverables were referenced with additional
In the event a discrepancy occurred during testing, deliverables created to document new features (and
an evaluation of the discrepancy was made as to the corrections) and their interrelationships.
level of severity, and a decision was made to contin- Processes for the development, use, operation, and
ue testing using change control procedures, or to halt maintenance of the ERPcomputer system also included:
testing until a resolution was found. The discrepancy,
evaluation, and decision to proceed or halt testing was • Maintenance
documented in the testing log of the associated quali- • Backup
fication protocol. • Record retention
Upon completion of the qualification protocols, a • Virus protection
summary report for each protocol was developed. • Startup and shutdown
The reports detailed the results of the qualification • Problem reporting and tracking
testing. • Performance monitoring
• Transports (changes to the current system)
Business Process Procedures and Test Script Training
The purpose of this was to demonstrate that BPPs Once the system was approved and validated, all
and test script writing was sufficiently understood, changes underwent a review and approval process to
and training was performed with the end users. ensure that all testing was completed. Additional func-
Training documentation for all personnel that were tionality testing was performed whenever changes,
tasked with writing test scripts attended the briefings updates, and/or upgrades needed to be made. Ex-
and workshops was required. The following table amples included:
included some of the minimum training requirements:
Description
❶ Basic functional testing of PROD (the produc-
Overview tion environment) after a Hotpack installation is
• BPPs and Test Scripts complete
• Testing and Validation ❷ A change to a transactional code configuration
Test Script
Test Script Control Log Specific testing requirements needed to be identi-
BPPs and Test Script Workshop fied in order to install the latest kernel update. These
• Business Process Procedures (See Attachment 2) types of tests must be conducted to ensure the system
• Test Script Example (See Attachment 3) is performing as expected and data integrity is not
• Template compromised. All original documents should be filed
• Sign In Sheets
in the Validation History File as they are completed.
• Deviation Logs
Once the system was online in the production envi-
Upon successful completion of the above training ronment, the PQ was executed, and the system perfor-
activities, test script writing commenced. mance was monitored for a period of no less than three
weeks. Any disruptions to the system performance
System Implementation and On-Going Support were documented in the testing log of the PQ.
During this phase, the project team needed to Following the specified time minimum duration, the
maintain control of the system, while allowing for a Summary Report for the PQ was completed, which
continuous improvement process. In our case, the summarized the results of the initial monitoring period.
new ERP system was maintained in a validated state A final Summary Report was then generated to sum-
through our change control process, as well as con- marize the results of all validation activities for the new
figuration management. Required revalidation was ERP system. Upon approval of the final Summary
evaluated, and occurred for any new implementation Report, a validation certificate was issued. ❏
➲
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
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:
Attachment 2 (Continued)
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
BOM 000000016
BOM Usage 1 Production
1 07004110-001 1001
2.5. Step 1.5: After viewing necessary information, click on the to return through the previous
screen to main menu
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: