Validation of an Enterprise Resourse Planning System ERP

May 2003 • Volume 9, Number 3

Medtronic MiniMed is theworld’s leading providerof external programma-

ble insulin pumps and continuousglucose monitoring systems. Weare a multi-billion dollar corpora-tion which employs approximately2,000 people at the Northridge,California, facility. There are ap-proximately 1,600 computer usersthat were affected by the implemen-t a tion of a new Enterprise ResourcePlanning (ERP) system, whichneeded to be blueprinted, config-ured, installed, tested, and validated in less than 12months. Needless to say, this was not an easy task.

We needed to purchase an ERPsystem software ap-plication package that is a suite of pre-engineered, r e a d yto implement integrated application modules catering toall the business functions of an enterprise, (which in-cluded the flexibility for configuring/customizing thefunctionality of the package to suit specific require-ments of the enterprise) that would allow our users toelectronically unite the MiniMed community by replac-ing the company’s current software system with a newstate-of-the-art system known as System A p p l i c a t i o nand Products (SAP). This new ERP system wasdesigned to deliver state-of-the-art business applica-tions that would enable well-controlled growth througha consistent, real-time source of integrated information,and ensure timely and accurate business decisionsscaled to a billion dollar plus company.

MiniMed selected the SAP R / 3enterprise software package, Ve r s i o n4.6 C, to replace its current legacysystem. In this phase, the R/3 systema ffected the following functionalareas: planning, scheduling, purchas-ing, manufacturing operations (plan-ning and production managementonly), document control (bill ofmaterials and routings only), invento-ry control, inventory accounting, costaccounting, general ledger, fixedassets, accounts payable, sales, anddistribution. Selected modules are

included in Fi g u re 1.SAP is the fourth largest software manufacturer

in the world. SAPis modular software, e.g., Sales andDistribution (SD), Materials Management (MM).These modules share common data to reduce data entryactivities, and increase information accuracy for bus-iness functions.

Since this new ERPsystem tracks the movement andinventory of a medical device product from its receipt toplacement in MiniMed’s distribution centers, and couldeventually develop the functionality for electronic batchrecords, the current Good Manufacturing PracticeRegulations (cGMP) require that the R/3 system be val-idated. These functions are regulated by the cGMPrequirements defined in the Code of Federal Reg-ulations (CFR), Title 21, Parts 820, 11, 210, and 211.A detailed cGMP impact assessment for the enter-prise project needed to be completed.

205

❝…[EnterpriseResource

Planning] ERPpackages enablean organizationto truly functionas an integratedorganization. ❞

Validation of an EnterpriseResource Planning (ERP) System:

An SAP Case StudyJackelyn Rodriguez

Medtronic MiniMed Inc.

❖

Journal of Validation Technology

Jackelyn Rodriguez

Project Team Selection and ResponsibilitiesAt the beginning of the project, it was quite critical

that certain responsibilities and functions be assigned inorder to achieve deliverables in a timely fashion. Amulti-functional validation team was formed to overseeand approve all software validation activities. Membersincluded representatives from Quality Assurance (QA),Information Technology (IT), process owners, and busi-ness users.

Information Technology (IT) was responsible forthe following areas, including:

• Delivery of computerized systems (computer hard-ware, operating system, and installed standard a p-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 forthe following areas, including:

• Defining the requirements for the software andcomputerized systems for their intended use

• Documenting the Software Development Life-cycle (SDVLC) process and activities for thesoftware and computerized system

Quality AssuranceQ A 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

• Generated the Process Validation Plan (PVP)and Process Validation Report (PVR) for new orexisting software systems developed to supportthe 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 (traceabilitymatrix)

• Witnessed all test scripts executions• Confirmed that all test script deviations were ad-

dressed and closed.• Managed and maintained the change control pro-

c e s s

Development MethodologyThrough the use of the SAP product, A c c e l e r a t e d

SAP (ASAP) project deliverables were identified,scheduled, and developed. All of the functional areasgenerated 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 unauthorizedor undocumented modifications to the system, it wasmaintained in a validated state. This system was se-lected not only for business reasons, but also becauseof the A S A P accelerated methodology.

Our enterprise validation project plan defined thescope of the enterprise project validation effort. T h i sdocument was also used to establish an approach to ad-dress validation requirements in order to ensure com-pliance of the completed system with FDAand internalguidelines. The validation project plan defined why thevalidation occurred, described the validation approach,specified the required steps and associated deliver-ables, and defined responsibilities for performing thevalidation steps.

The objectives of the validation project plan wereto formally define and document the intended oper-ation of the R/3 system – enterprise project by:

• Identifying the documents required to supportthe validation of the R/3 system

• Defining the strategy for verifying that the R/3system – 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

206

Figure 1

Selection ModulesModule Types of Quality RecordsHuman Resources (HR) Training records, certifica-

tions

M a t e rial Management (MM) Bills of materials, materialsspecifications, productionwork orders

Sales and Distri bution (SD) Customer orders, shippingrecords

Production Planning (PP) Forecast plans, purchasingdocuments

Financial Accounting/Asset Accounts receiva ble and Accounting (FI) accounts payable


Jackelyn Rodriguez

testing of system components, subsystems, inter-faces, and data conversion programs defined inthe design specification documents

• Identifying the need for creating/updating StandardOperating 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/3system enterprise project

• Defining the strategy for creating a file of evidence thatdemonstrated managerial control of the R/3 system(through the use of our change control procedure).

There are five major phases needed to implementthis type of software according to what is called“The SAP methodology.”

Phase I: P roject Pre p a ration – Project Plan and ScopeD e fi n i t i o n

The primary focus of Phase I was placed on gettingthe project started, identifying team members, and de-veloping a high-level plan. The kickoff meeting wasextremely important – it was then that the project teamand process owners got a clear sense of what their re-sponsibilities were to be throughout the project. PhaseI 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 BlueprintThe primary focus of Phase II was placed on under-

standing the business goals of the company, and deter-mining the business requirements needed to supportthose 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: RealizationThe purpose of Phase III was to develop a “future-

state” model into an integrated and documented solu-

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 processwas divided into iterations or cycles of related, “busi-ness process flows.” The business process flows wereconfigured in parallel with the development of reports,user procedures, testing scenarios, and security pro-files. The cycles not only provided milestones for theproject team, but also provided checkpoints to test a“playback” of specific parts of the overall business pro-cess. This approach provided immediate feedback, andinvolved the entire organization throughout the projectlifecycle. At this point, our team started looking at theprocess 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

p r o c e s s e s• 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 PreparationThe primary focus of Phase IV was placed on com-

pleting the final system testing, training end-users, andcutting over both the data and the system to a produc-tion environment. Final system testing included con-version procedures and programs, testing interfaceprograms, conducting volume and stress testing, andfinal user acceptance testing. (User acceptance testswere included in the final system testing.)

Another focus of this phase was developing a Go-Live strategy. This plan specifically identified thedata conversion strategy, initial audit procedures, anda project team support structure. The final step was to

207


Jackelyn Rodriguez

approve the system and the readiness of the compa-ny to go live, and to officially turn on the new ERPsystem, and to fully train end-users. Phase IV i n c l u d-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 theevent that cut-over activities failed)

• Establish internal help desk • Cut-over to production environment• Performance Qualification (PQ)

Phase V: Go Live and SupportAfter “go-live,” our team focused on supporting

the end-users. Each day, the business results and sys-tem performance were measured and reviewed perPQ requirements. (PQ requirements included the ver-ification of performance against intended use), andtraining continued for all levels. Business processprocedures, preformatted generic process word-tem-plates generated via A S A P, were used to provide de-tailed instructions to the user on how to execute trans-actions within SAP.

Development, Implementation and System Configuration

RequirementsA documented software requirements specification

provided a baseline for both validation and verification.The software validation process cannot be completedwithout an established software requirements specifica-tion (Ref: 21 CFR 820.3[z] and [aa] and 820.30[f] and[g]). (http://www. f d a . g o v / c d r h / c o m p / g u i d a n c e / 9 3 8 . p d f )

Ty p i c a l l y, ERP packages enable an organization totruly function as an integrated organization. T h i sincludes integration across all functions or segmentsof 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 theS A P E R P package, the only real software require-ments were developed for custom codes. Our newE R P system handles all types of business functions,and links their related business tasks. With its exten-

sive functionality and high-level of integration, thissystem meets a full range of business requirements,including financial accounting and controlling, salesand distribution, materials management, productionplanning, and human resources. Each type of businessrequirement was broken into what SAP refers to as abusiness process module. The system can be imple-mented with as little as one module, or a combinationof modules, and still provide the integrated businessf u n c t i o n a l i t y. We decided on a phased approach toimplementation, implementing several modules ineach phase.

System EnvironmentThe new ERP system is based on client-server

architecture. The basic system environment willremain constant over its life span at the company. Itconsists of three separate physical environments, orin SAP t e r m i n o l o g y, instances; a developmentinstance, a test instance, and a production instance.Each instance contains at least one client providinga unique access into the ERP application and its cor-responding database.

Development InstanceThe development instance contained separate

clients providing individual environments for thefunctional 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 manpowerissues.) The purpose of the development instance wasto provide a safe and separate environment wheredevelopment activities (configuration, data conver-sion, interface programs, and security profiles) couldtake place. The separate clients on the developmentinstance further ensure that individual developmentactivities 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 keytransactions to process owners. This playback of busi-ness processes to the project team allowed for feedback,as well as further confirmation that the requirementsdefined in the business blueprint were being met.

To ensure all clients are virtually identical (devi-ations between clients were reviewed and addressedby the project team on a case-by-case basis), the

208


Jackelyn Rodriguez

clients were refreshed weekly to include the latestsystem configurations. All development activitiesand initial unit testing took place in the developmentinstance.

Test InstanceThe test instance contained several clients similar

to the development instance. These clients providedseparate environments for preliminary integrationtesting, data conversion and interface testing, andu l t i m a t e l y, the qualification testing required for vali-dation. A client was available for use in the trainingof end-users. The purpose of the test instance was toprovide an environment where only testing and train-ing could occur. This ensured that in the event of anerror during testing, the development and productionwork is never compromised.

Production InstanceThe production instance contained a single client.

This client was a replica of the test instance client uponwhich validation testing is performed. All updates tothe production client were handled through changecontrol procedures. This process involved system con-figuration or application of software patches in thedevelopment instance, validation testing in the testinstance, and upon successful completion of testing,transporting the updates to the production instanceclient. (In the event that a test failed, it was permissibleto allocate non critical failures to an issue-tracking sys-tem for later resolution, the change control processstarts again, beginning in the development instance.)The purpose of the production instance was to supportday-to-day operations. (The difference between config-uration management and change control is that oncethe system is approved, all changes must go throughthe approved change control process.

Validation Approach

Although FDA’s guidance does not recommend theuse 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 GeneralPrinciples of Software Validation Guidance document.Adetailed assessment of the SAPmethodology a g a i n s tthe design control regulation, or the software valida-tion guidance, was completed when the master valida-

tion plan was generated and approved. As the new ERP system was in the developmental

stage until Phase IV, validation testing and end-usertraining, and some validation deliverables, did not re-ceive final approval signatures until the systemreached Phase IV and was considered “frozen.” Eachdeliverable, however, began development in the desig-nated phase. All documents that were developed car-ried a computer-related system validation number anda version number. Once approved, all changes to de-liverables were completed in accordance with theS O P, maintenance of the validated system, ongoingevaluation, 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 ActivitiesProject Planning

During the project planning phase, the R/3 systemproject and its boundaries were defined, and an im-plementation approach was developed. A project planwas created to outline project tasks, duration, andresponsibilities. Throughout the project implementa-tion, the project plan was updated to reflect the cur-rent state of project tasks.

209


Jackelyn Rodriguez

The validation project plan was created to outlinethe approach, deliverables, and responsibilities to com-plete validation tasks necessary for the implementationof the ERP s y s t e m .

Vendor AuditA software quality assurance evaluation was con-

ducted to support ongoing processand quality improvement efforts byS A PAG (i.e., the company) relativeto the development and support ofits R/3 software product. In addi-tion, it is intended to provide docu-mented evidence to directly andproactively support selected valida-tion activities required of thoseS A P clients whose R/3 applicationsare used to perform or support pro-cess functions subject to regulationby the Food and Drug A d m i n i s t r a-tion (FDA). The audit results were satisfactory.

High-Level Requirements SpecificationFunctional requirements specify what the system

must do. They relate to the actions that the systemmust carry out in order to satisfy the fundamentalreasons for its existence. They include:

• Specifications of the system’s functionality• Actions the system must take-check, calculate,

record, retrieve• Derived from the fundamental purpose of the

system.• Nonfunctional requirements are the properties

that the system must have. For example, theseare the characteristics or qualities that make thesystem usable, fast, secure, or reliable.

• Global requirements are broad, encompassing re-quirements, or a constraint on the system. Globalrequirements may:

– Be described in a very broad language– Describe a characteristic of the entire system– Reflect a general need of all potential users– Constrain the design or use of the system

These high-level requirements are detailed fur-ther in the system requirements specification.

System Requirements and Design Specification (Blue-p r i n t )

This phase defined general system needs requiredof an ERP system intending to cover the functionalareas. A high-level requirements specification docu-ment was developed to outline the desired systemstructure, operation, and system interfaces. The high-

level content of this document was intended to pro-vide a “big picture” of what was required of the sys-tem. The development of the high-level requirementsspecification document was the responsibility of theproject managers and the corresponding functionall e a d s .

The Design Specifications (DS) were prepared todescribe how the requirements specifications wereimplemented. Elements addressed in the design spec-ification included:

• System hardware• Application servers• Database servers• SAPGraphical User Interface (GUI) workstations• System software• Operating system• Database• Application software• System performance• Network connectivity• Remote access• Security• Physical security• Logical (SAP application security)• Configuration• Application extensions• Business processes

210

❝Functional requirements specifywhat the system must do. They

relate to the actions that the system must carry out in order

to satisfy the fundamental reasons for its existence… ❞


Jackelyn Rodriguez

System DesignThis 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. T h efunctional leads, configurators, basis administration,and QA-Validation personnel together provided theinput to complete this document.

Detailed system requirements were defined foreach of the functional areas. The requirements then, ata minimum, defined process descriptions and the se-quence of operations for each of the functional areas,and their corresponding sub-components. The outlinefor the functional content was based on SAP’s defini-tion and terminology of the make up of each of ourmajor ERPmodules. This approach was taken to facil-itate the documentation of future module upgradeswithin the new ERP s y s t e m .

System design specifications were created to clear-ly and completely document the new ERP s y s t e m ’soperating environment, interfaces, security, and func-t i o n a l i t y. Additional configurations were performed asneeded to address requirements outside of the “off - t h e -shelf software package.” Any parameters that couldhave an effect on the system performance were identi-fied, including the definition of acceptable values orcharacteristics 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 therequirements and the design specifications through atraceability matrix.

Traceability MatrixBased on the requirements specification, MiniMed

compiled a Business Process Master List (BPML),which identified all business activities supported by thesystem. This list was composed in order to developBusiness Process Procedures (BPPs), which describedthe use and function of the system required to supportM i n i M e d ’s business.

Controls were established to provide traceability ofrequirements to system setup and configuration throughto testing strategy. This was achieved as follows:

• The strategy used for the Quality System Reg-ulation (QSR) (more generally referred to as

Good Manufacturing Practice [GMP]) impactedtransaction codes (t-codes) was as follows:

– All t-codes to be utilized by MiniMed werereviewed for GMP impact and categorizedas high, medium, or none. This documentis generated from the BPML.

High ImpactTransaction codes (T-codes), determined to have

high GMP impact, were further reviewed at the indi-vidual field level to identify those fields that hadG M P impact. The fields to be reviewed were onlythose that would be utilized per department workinstructions for Phase I implementation.

The fields of t-codes with high GMP impact hadnegative testing performed as part of the validation.

Medium ImpactT-codes with medium GMP impact were tested to

verify proper functionality, and the results recordedfor validation purposes.

No ImpactT-codes with no GMPimpact were tested for prop-

er functionality for business purposes, but the resultsof this testing were not required to be part of the val-idation package.

Testing strategies and scenarios were based onthe outcome of this assessment.

Test scripts were pre-approved, and informationcontained in the BPP’s was utilized fully.

The validation test effort, including GMP/QSRcritical 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 ConversionData conversion programs were verified and vali-

dated as data was compared during the data conver-sion process verification. The verification was per-f o r m e d by teams of two who reviewed the same sam-ples of data records.

It is important to remember that data conversionswere not part of the functionality intended for every-day use in SAP. Instead, the data conversions wereprocesses performed by expert individuals in a high-ly-controlled environment.

211


Jackelyn Rodriguez

Our data conversion process usually involved thefollowing steps:

Data MappingDuring this exercise, the relationship between

data in the legacy and SAP systems were defined atthe field level. This activity resulted in a data mapfor each conversion effort. Data Cleansing

In order to ensure the quality of the data beingtransferred, we examined the data undergoing con-version for issues, such as redundant records, dupli-cate records, referential integrity, and typographicalerrors. These issues were corrected on a case-by-casebasis. This process often involved significant manuale ffort.

Conversion/MigrationThe conversion process involved the transfer of

cleansed data from the legacy system to SAP,according to the rules defined in the data map.

Inspection/VerificationAfter the conversion process was run, the data

was inspected to ensure that it was properly convert-ed (in accordance with business rules and the datamap). The inspection process was based on approvedm e t h o d o l o g y, and the results were recorded.

Converted data was subjected to inspection andverification.

Each record type (in SAP) was considered a sep-arate population for the purpose of sampling plans.

A single individual, using printouts from at leastthe legacy and SAP systems, performed an inspec-tion of the data. The inspections were recorded by thei n s p e c t o r’s signature on each page of these printouts.

In addition to inspection of random samples frommigrated data, all conversions were subject to verifi-cation through record counts. Records were countedin the legacy and SAP systems.

Conversion Summary ReportFor each data conversion effort, a summary report

was produced. The report included the following:

• The data map• All required printouts for data conversion• Data inspection records

• Statement of acceptability of the converted data.

Validation Activities

System ConfigurationThe system configuration phase included the con-

figuration of the system as defined in the high-levelrequirements specification and detailed require-ments and design specifications documents. Systemadministration procedures were developed for gen-eral system administration, security profiles, dataretention, and change control. As individual moduleconfiguration was completed, BPPs were developedto define the necessary procedures for each of theprocesses (i.e., detailed description of how to exe-cute a transaction). Refer to Figure 2.

Validation Plan

Installation Qualification (IQ)The IQs documented the system environment of

the test instance. Hardware and software test scriptswere developed. This included:

• Master file documentation• Procedure verification• Hardware configuration and inventory verification

212

1. SOPs and System Procedures for ERP Manuals System Administration

2. IQ – Test Instance Documents SystemEnvironments

3. OQ – Test Instance ERP System – (per mod-ule), (Forecast to Finish[FF] Goods, Purchase toPayment [PP], QualityModule [QM], Financial/Collections Module[FI/CO]) Securi t y, SystemA d m i n i s t ration, andSystem Interface testing

4. OQ – Test Instance R/3 System Reporting –On screen and hardcopy reporting verifica-tion

5 . IQ – Production Instance Documents system envi-ronment

6 . PQ – Production Instance Documents system per-formance

7 . Data Conversion Protocol Documentation and veri-fication of automatic andmanual data conversionsin both the test and pro-duction instances


Jackelyn Rodriguez

• 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) testscripts developed by the functional process owners.(Please see attached test script example i.e., Fi g u re 2)

The OQ consisted of verifications and tests to en-sure that all components of the SAP R/3 system opera t-ed properly according to system specifications, changerequests (if any), and vendor documentation.

The tests to be executed under this protocol weredivided 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 ofBPPs and test scripts underwent training on how todevelop/create such documents.

This ensured not only a greater understanding ofthe systems, but also gave daily users an opportunityto practice the use of the new transactions, as well asprovided awareness on how their transactions aff e c t-ed other functional areas, and to verify system con-figuration. Also included were system administrationtest scripts written by the basis administration (con-sultants) team and QA-validation, covering the areasof stress/volume testing, security, audit trails, archiv-ing functionality, and backup and recovery. (Theconsulting team helped generate 80% of the tests c r i p t s ) .

Performance Qualification (PQ)The PQ monitored the new ERP system perfor-

mance on the production instance, including theongoing data transfers from existing legacy systemsto the ERP system, (This was performed once thesystem went live).

Data Conversion ProtocolA separate protocol was developed to document

the data conversion methodologies, and verify datatransported from the existing legacy systems to thenew ERP system. In order to adequately test the newsystems functionality, the data conversions occurredon both the test and production instances.

The conversion for the test instance included all ofthe automatic data transfers, and a limited sample ofmanual data conversions that mimicked (at a smallerscale) the production environment. For the productioninstance, full automatic data conversions and full man-ual data conversions took place. In both instances, asingle 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 d e-veloped with the functional leads, configurators, basisadministration, and basis conversion teams. (Pleaserefer to page 215 for conversion strategy details).

At the end of the system configuration phase, a dryrun (informal validation testing) was conducted onthe test instance using draft qualification protocols.Once the dry run was completed, appropriate changeswere made to the validation deliverables, and if nec-e s s a r y, to the system configuration.

Validation Deliverables:

Validation deliverables included:

• SOPs user manuals (SOPs were a validation de-liverable because references to the old ERP s y s-tem transactions were included within the SOPs.In order to ensure that all old references wereremoved, the new references to the new PFD,which included the new BPP transaction codenumbers, 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 resultsof the qualification protocols

• Summary report summarizes entire validation eff o r t• Validation Certificate (a Validation Certificate

is required per ASAP methodology upon com-pletion of this phase). The certificate states thatthe R/3 system consistently performs according

213


Jackelyn Rodriguez

to the user’s requirements for the system• Change control forms and testing documentation.

Change control documents and supporting testdocuments showing control of the change pro-cess, as defined in the SOP, maintenance of thevalidated system, ongoing evaluation, and changecontrol procedures

Validation Testing and End-User TrainingValidation 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 ofthe new ERP system. Training of end-users occurredprior to the start of the system implementation andongoing support phase.

The bulk of validation testing took place on a client,(i.e, the computer station, that was set-up for validationtesting in the test instance). This validation client wasan exact replica, with respect to system configuration,of the production client on the production instance. A nIQ and two OQs (of the new system functionality andreporting) were executed on the validation client of thetest instance, followed by an IQ on the productionclient of the production instance.

TestingTesting was performed to document and confirm

that the implemented system satisfied requirementsand design intent. All tests were traced to require-ments and business processes. The testing processincluded 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 executedinstallation tests were approved before operationaltesting occurred in the test environment. A release to

production memorandum was also approved beforeinstallation and verifications were performed in theproduction environment. Pertinent, executed installa-tion tests were approved before performance testingoccurred in the production environment.

Test Plans and Test CasesOur software test plans were test cases developed

using the blue printing requirement, which generat-ed what we called the BPML. This list includedevery single transaction code that was used as achecklist to correlate transaction codes with test sce-narios. This also included the cGMP impact assess-ment. This list was also used for comparison to theprocess flow diagrams (see Attachment 1), that werealso part of the blueprinting process. As a result, oursoftware validation testing appropriately matchedthe risk associated with the system.

“Real World” TestingF D A’s software validation guideline1 d o c u m e n t

recognizes that “software is designed, developed, val-idated and regulated in a real world environment.”Because of that, during testing, it was important toconsider what level testing was appropriate, and if allof the “high risk” software integration scenarios wereconsidered, tested, and challenged when designing thesoftware validation. Levels of no-impact, medium, andlow were assigned according to GMP impact. Singleunit testing was performed on transactional code out-side the scope of validation testing.

GMP/QSR Impact and Test Script PreparationThe extent of testing for any business process or

transaction should be determined by the degree ofGMP/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 ofvalidation testing for any business process or transaction:

214

GMP/Q Validation testingSR impactNo Impact No validation testing performedMedium Ve rify the transaction perfo rms in nor-

mal (ideal) situationsHigh Ve rify the transaction perfo rms in nor-

mal (ideal) situations.Also ve rify propero p e ration of all system functions andc o n t r o l s, which have GMP/QSR impactthrough challenge (negative) testing.


Jackelyn Rodriguez

GMP Business Process VerificationG M P business process testing was designed to en-

sure that the integrated business processes work inaccordance with the process flows, configuration spec-ifications, and the functional/design specifications.This verification included positive and negative tests.Positive tests challenged the normal business process.Negative tests introduced challenges to the executionof the normal business process. These challenges in-cluded, but were not limited to, entering invalid dataand out-of-sequence transactions.

Based on the requirements specification, we com-piled a BPMLthat identified all business activities tobe supported by the system. This list was composedin order to develop BPP’s, which described the useand function of the system required to support ourbusiness.

The strategy that was used for QSR (generallyreferred to as GMP) impacted transaction codes (t-codes) was as follows:

This example was created using the BPML g e n e r-ated as part of the A S A P implementation method-o l o g y. Each business process listed is a process thatwas implemented during our ERP i m p l e m e n t a t i o n

Because our software validation activities andtasks were dispersed, occurring at different locations,and were conducted by different organizations, weused QA teams to oversee all testing activities, inc-luding recording deviations, working with testers,

and software configurators to address deviations andclosure in order to complete the test script process.

GMP Business Process VerificationOur GMP business process testing (see A t t a ch m e n t

3 for an example of a test script) was designed to en-sure that the integrated business processes worked inaccordance with the process flows (see A t t a chment 1)configuration specifications, and the functional/designspecifications. This verification included positive andnegative tests. Positive tests challenged the normalbusiness process. Negative tests introduced challengesto the execution of the normal business process. T h e s echallenges included, but were not limited to, enteringinvalid data and out-of-sequence transactions

Security VerificationSecurity testing was designed to verify that the

implemented SAP security architecture functionedin accordance with security specifications. This test-ing was executed for the following two areas:

❶ Transaction access❷ Integrated business scenarios

Transaction access demonstrated the proper oper-ation of the core transaction protection object, andconfiguration of activity groups. In this testing, thefollowing was demonstrated for each tested activitygroup (roles):

• Transactions required for the activity group(roles) were accessible

• Transactions not required for the activity group(roles) were not accessible

During security validation scenarios, the businessprocesses were executed with users assigned to thedesigned profile in the SAP user master record. Thisprocess verified that the security model was correct-ly configured to permit the execution of SAP tasksusing their assigned role.

Data ConversionsThe data conversion protocol was executed on

both the test and production instances. This was typ-ically the responsibility of the functional leads, con-figurators, and basis administration and conversion

215

Business Process Master List

Number Deficiencies Code I m p a c tFX Conve n t Planned Order to ABCXX1 Med

Production Order – Individual

FX C o l l e c t i ve Conve r s i o n ABCXX2 Medof Planned Orders

FX Conv.plan.ord.to ABCXX3 Hiprod.ord.part.redct

FX Display Material Bills ABCXX4 Medof Materials (BOMs)

FX Display Allocation ABCXX5 Medto Plant

FX Multilevel Billing of ABCXX6 HiMaterials

FX Summarized Billing ABCXX7 Medof Materials

A r e a Business Process Tra n s a c t i o n G M PProcedure T i t l e


Jackelyn Rodriguez

teams, as well as functional area super-users to assistand execute these qualification protocols. (This in-cluded data maps, data conversion verifications, andrecord counts).

In the event a discrepancy occurred during testing,an evaluation of the discrepancy was made as to thelevel of severity, and a decision was made to contin-ue testing using change control procedures, or to halttesting until a resolution was found. The discrepancy,evaluation, and decision to proceed or halt testing wasdocumented in the testing log of the associated quali-fication protocol.

Upon completion of the qualification protocols, asummary report for each protocol was developed.The reports detailed the results of the qualificationtesting.

Business Process Pro c e d u res and Test Script Tra i n i n gThe 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 weretasked with writing test scripts attended the briefingsand workshops was required. The following tableincluded some of the minimum training requirements:

Upon successful completion of the above trainingactivities, test script writing commenced.

System Implementation and On-Going SupportDuring this phase, the project team needed to

maintain control of the system, while allowing for acontinuous improvement process. In our case, thenew ERP system was maintained in a validated statethrough our change control process, as well as con-figuration management. Required revalidation wasevaluated, and occurred for any new implementation

phase, development of an interface from an existingsystem to the new ERP system, or validation for anew software release. In each case, the existing val-idation deliverables were referenced with additionaldeliverables created to document new features (andcorrections) and their interrelationships.

Processes for the development, use, operation, andmaintenance 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, allchanges underwent a review and approval process toensure 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 isc o m p l e t e

❷ A change to a transactional code configuration

Specific testing requirements needed to be identi-fied in order to install the latest kernel update. T h e s etypes of tests must be conducted to ensure the systemis performing as expected and data integrity is notcompromised. All original documents should be filedin 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 threeweeks. Any disruptions to the system performancewere documented in the testing log of the PQ.

Following the specified time minimum duration, theSummary Report for the PQ was completed, whichsummarized 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 newE R P system. Upon approval of the final SummaryReport, a validation certificate was issued. ❏

216

Description Overview

• BPPs and Test Scripts• Testing and Validation

Test Script Test Script Control LogBPPs and Test Script Workshop

• Business Process Procedures (See Attachment 2)• Test Script Example (See Attachment 3)• Template• Sign In Sheets• Deviation Logs


Jackelyn Rodriguez

About the AuthorJa ckelyn Rodriguez is Director, Quality Systems andR e g u l a t o ry Compliance for Medtronic MiniMed. S h ehas 19 years ex p e rience in all facets of quality assur-ance and regulatory compliance. She specializes inI n t e rnational and U. S. r e g u l a t i o n s, which define quali-ty systems, design control, CE-marking, risk manage-ment, medical device reporting, post-market surve i l-lance and vigilance. She also has ex t e n s i ve know l-edge of 21 CFR Pa rt 11, as well as HIPAA require-m e n t s. M s. R o d riguez holds a BS in Business Man-agement, and is a certified member of the Board ofExaminers for the Malcolm Baldrige National QualityAward program, and an ASQ Certified QualityAu d i t o r. She has written articles for the Journal ofCGMP Compliance, and has been quoted in the sev-e ral Medical Device related journ a l s, such as the GoldSheet, and the Gray / S i l ver Sheet.She can be reachedby phone at 818-576-5624, by fax at 818-576-6266,and by e-mail at jacke l y n . r o d ri g u e z @ m i n i m e d . c o m .

Reference1. FDA. Software Validation. http://www. f d a . g o v / c d r h / c o m p /

guidance/938.html.

Suggested Reading• FDA. G e n e ral Principles of Software Validation; Final Guidance

for Industry and FDA Staff. January 11, 2002.

217

ASAP: Accelerated System Application andProducts

BOM: Bill of MaterialsBPML: Business Process Master ListBPP: Business Process ProceduresCFR: Code of Federal RegulationscGMP: Current Good Manufacturing PracticeDS; Design SpecificationERP: Enterprise Resource Planning FDA: Food and Drug AdministrationFF: Forecast to FinishFI: Financial Accounting/Asset

AccountingFI/CO: Financial/Collections ModuleGMP: Good Manufacturing Practice GUI: Graphical User InterfaceHR: Human ResourcesIQ: Installation QualificationI T: Information Te c h n o l o g yMM: Material Management OQ: Operational QualificationPFD: Process Flow DiagramPO: Purchase Order PP: Production PlanningPP: Purchase to PaymentPQ: Performance QualificationPVP: Process Validation PlanPVR: Process Validation ReportQA: Quality Assurance QSR: Quality System RegulationRFQ: Request for QuotationSAP: System Application and Products SD: Sales and DistributionS D V L C : Software Development LifecycleSOP: Standard Operating Procedure T-Code: Transaction code

Article Acronym Listing

➲Attachments are presented on the following pages


Jackelyn Rodriguez

218


Jackelyn Rodriguez

219

Attachment 2

Display Allocation to PlantBusiness 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, beduplicated, 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 Plant1. 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)


Jackelyn Rodriguez

220

Attachment 2 (Continued)

Overview: Display Allocation to Plant2.1. Step 1.1: Access transaction by:

Via Menus Logistics>Production>Master Data>Bill of Material>MaterialBOM>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

May 2003 • Volume 9, Number 3 221

Jackelyn Rodriguez

Attachment 3

Unit Test Script Example

Opportunity to Cash Purchase to PaymentMonthly Finance Forecast to Finished Goods

Test Script Plan ApprovalBy Name (Please Print) Signature Date

Reviewed By:

Quality Assurance Approved By:

BPP Refe r e n c e BPP Step Required E x p e c t e d A c t u a l S c r e e n Te s t e r O KS t e p D e s c r i p t i o n F i e l d R e s u l t s R e s u l t s P r i n t D a t e

R e q u i r e d ?BPP1ME21N.1 1.6 Adopt purchase Purchase req: Information from Y

requisition to purchase requisitionpurchase order copied to purchase

order being created

BPP1ME21N.1 1.7 Add vendor Vendor Number: Document type de- Ninformation faults as Standard

PO. Document Datedefaults to today’sdate

BPP1ME21N.1 1.8 Enter organiza- Enter Purchasing Data entered Ntional data Group: 001

Purchasing Organ-ization: 1000C o m p a ny Code: 0 0 1 0

BPP1ME21N.1 1.9 Enter Item Data Net Price: $10.00 Other required YCurrency: USD data defaultsPlant: 1001

BPP1ME21N.1 1.12 Enter Item Details Tax Code: PH Data entered Y

BPP1ME21N.1 1.13 Save Purchase Purchase Order Purchase Order YOrder created Number:

Test Completion Results Passed Failed Corrected, Retested, and Passed

Test Script Results ApprovalBy Name (Please Print) Signature Date

Reviewed By:

Process Owner Approved By:

Quality Assurance Approved By:

Validation of an Enterprise Resourse Planning System ERP

Documents

Transcript of Validation of an Enterprise Resourse Planning System ERP