oracle r12 opm vmp 0.1

Document Title Oracle R12 e-Business Suite OPM Validation (Master) Plan

Filename/Document Identifier Ver Ver Date Type System Page No

0.1 12 Apr 2011 VP Oracle OPM for < Site > -1 of 1 7 -

OPM Validation Master Plan

Oracle R12 Process e-Business suite

Validation (Master) Plan

for

Oracle Process Manufacturing

Approval

Completion of the following signature blocks signifies the approver has read, understands, and agrees with the content of this document and that the document has been produced in accordance with applicable Quality Standards.

Name Job Title Signature Date (dd-mmm-yyyy)

Prepared by:

Validation Consultant

Approved by:

Project Manager

Approved by:

Quality Assurance Manager





Revision History Date Version Revised By Reason For Revision

12 Apr 2011 0.1 Laila Rasmy First Draft





Table of Contents

1. Introduction ........................................................................................................ 4 1.1. Purpose ............................................................................................................... 4 1.2. Objectives ............................................................................................................ 4 1.3. Scope .................................................................................................................. 4 1.4. System Description .............................................................................................. 4 1.5. OPM Overview .................................................................................................... 5 1.6. Oracle Methodology ............................................................................................ 5

2. Vendor Status .................................................................................................... 6

3. Validation Lifecycle ........................................................................................... 7 3.1. Design Phase ...................................................................................................... 8 3.1.1. Validation Master Plan (VMP) ........................................................................................ 8 3.1.2. User Requirement Specification (URS) .......................................................................... 8 3.1.3. Functional Specification (FS) ......................................................................................... 9 3.1.4. Hardware Design Specification (HDS) ........................................................................... 9 3.1.5. System Design Specification (SDS) ............................................................................... 9 3.1.6. Code Review (CR) ....................................................................................................... 10 3.2. Risk Management .............................................................................................. 10 3.3. Testing Phase .................................................................................................... 11 3.3.1. System Acceptance Test Specification (SATS) ............................................................ 11 3.3.2. Hardware Acceptance Test Specification (HATS) ........................................................ 11 3.3.3. Functional Test Specification (FTS) ............................................................................. 12 3.3.4. User Acceptance Test Specification (UATS) ................................................................ 12 3.3.5. Hardware Acceptance Testing (HAT) .......................................................................... 12 3.3.6. System Acceptance Testing (SAT) .............................................................................. 13 3.3.7. Functional Testing (FT) ................................................................................................ 13 3.3.8. User Acceptance Testing (UAT) .................................................................................. 13 3.3.9. Validation Reporting (VR) ............................................................................................ 14

4. On-going Operational Phase .......................................................................... 14 4.1. Maintenance Plan .............................................................................................. 14 4.2. Change Management ........................................................................................ 14 4.3. System Administration, Security and Access ..................................................... 14 4.4. System Backup, Restore and Archiving ............................................................ 14 4.5. Training and Operating ...................................................................................... 14 4.6. CAPA Management ........................................................................................... 15 4.7. Performance Monitoring .................................................................................... 15

5. Periodic Reviews ............................................................................................. 15

6. Glossary ........................................................................................................... 15

7. Regulations and Guidelines ........................................................................... 16

Appendix A - Specific Project Roles, Responsibilities and Key Deliverables Table . 17





1. Introduction

This document is the Validation Master Plan (VMP), containing all key validation activities for the implementation of the Oracle R12 Process Manufacturing System (OPM).

1.1. Purpose

The purpose of this document is to detail the scope of validation activities that are to be undertaken on the OPM System. In particular the boundaries of the validation and the work content of the various activities will be detailed.

This document has been written in accordance with Appendix M1 in ISPE GAMP5* [1].

1.2. Objectives

The prime objective of this document is to provide an organised and logical approach, which helps to demonstrate a fully working, validated and compliant system.

In addition, documentation produced as a result will assist internal Management and Regulatory Inspectors with future audit processes in order to ensure that the system complies with all the latest relevant regulatory practices for example FDA, EU and GMP practices.

1.3. Scope

The scope of this document is to identify deliverables and responsibilities required for the Oracle R12 Process Manufacturing (OPM) system validation.

1.4. System Description

Oracle E-Business Suite is a complete set of business applications enabling you to cut costs; increase revenues across front and back-office functions; and access current, accurate, and consistent data.

The applications in Oracle E-Business Suite are built on a unified information architecture that consolidates data from Oracle and non-Oracle applications and allows a consistent definition of customers, suppliers, partners, and employees across the entire enterprise. The result is a suite of integrated business applications, covering Financials, Logistics, Manufacturing, and ancillary departments that can give you current performance metrics, financial ratios, profit and loss summaries, and other types of information that roll up across all departments, products, and geographies.

*GAMP is a registered trademark of the ISPE www.ispe.org





DefinitionOperations

Analysis

Solution

DesignBuild Transition Production

Business Process Architecture (BP)

Business Requirements Definition (BR)

Business Requirements Mapping (RD)

Application & Technical Architecture (TA)

Module Design & Build (MD)

Data Conversion (CV)

Documentation (DO)

Business System Testing (TE)

Performance Testing (PT)

Application & Learning (AP)

Production Migration

1.5. OPM Overview

Oracle Process Manufacturing (OPM) automates the entire product lifecycle for recipe-based manufacturing, from new product development, recipe management and production, to cost, quality, and regulatory management.

It enables you to formulate products to individual customer specifications, manage variability, optimize capacity, and drive continuous process improvement.

1.6. Oracle Methodology

Oracles uses its own implementation methodology (AIM). The diagram below denotes the format for the Alfa prefix for the document identification number & at what time the relevant document is generally used during an implementation.

During Definition phase the Oracle project team plan the project, review the organizations business objectives, analyze the business processes, and evaluate the feasibility of meeting those objectives under time, resource and budget constraints.





2. Vendor Status

Oracle is an industry renowned supplier of computerised systems software founded in 1977 and currently estimated to be employing over 118,000 personnel globally with its main headquarters in Redwood Shores, California USA.

Oracle Corporation (NASDAQ: ORCL) is recognised as the worlds largest enterprise software company, providing enterprise software to more than 390,000 customersincluding 100 of the Fortune 100and with deployments across a wide variety of industries in more than 145 countries around the globe. With annual revenues of more than $37 billion, the company offers its database, tools and application products, along with related consulting, education, and support services.

Oracle Egypt has been involved with over 170 E-Business Suite system implementations, which includes pharmaceutical companies in Egypt either directly or through one of its officially approved and trained partners.

Oracle Egypt is a branch office of Oracle, which also operates one of the Oracle global support centres.

Due to the strong global position of Oracle and its wide usage of its software in the global market place, consider it a low risk in line with ISPE GAMP5 Appendix M2 and therefore unnecessary to conduct a formal audit on the company in either USA or Egypt at this stage.





3. Validation Lifecycle

Below is the Validation Lifecycle Model adopted for the Oracle OPM system.

VMPValidation Master

Plan

URSUser Requirements

Specification

FSFunctional

Specification

HDSHardware Design

Specification

CRCode Review

HATHardware Acceptance

Testing

FTFunctional Testing

UATUser Acceptance

Testing

VR

Validation

Report(s)

RA 2Risk Analysis

PQPProject Quality Plan

(Standards Applied)

SOPStandard

Operating

Procedures

Training

SDSSystem Design

Specification

SATSystem Acceptance

Testing

RA 1Risk Analysis

DE

SIG

N P

HA

SE

(DQ

)

TE

ST

ING

PH

AS

E

(IQ

\OQ

\PQ

)

Co

mb

ine

d

The deliverables specified in the above model are covered in the following sections of this plan. Deviations will be reported on within the Validation Report(s).

This section therefore defines the validation programme. The programme is divided into phases according to the validation life cycle.

Each phase is divided into tasks and for every task there are actions, responsibilities and associated procedures. The personnel identified, according to the procedures will undertake the actions.

In the following tables R denotes prime responsibility for ensuring that a task is completed according to the indicated procedure, and * denotes involvement with the task.





The following roles are identified by the action plan:

PM: Project Management

USER: User Representative(s)

ORC: Oracle Specialists and/or Oracle Project Manager

IT: IT Specialist(s)

CV: Computer Systems Validation Representative

QA: Quality Assurance Representative(s)

Each activity should be conducted in accordance with a specified procedure from ISPE GAMP 5[1], as appropriate.

3.1. Design Phase

This phase covers planning and production of documentation required to support the system.

Oracle documentation standards and\or internal policies or procedures are adopted, where appropriate.

3.1.1. Validation Master Plan (VMP)

The VMP (this document) identifies key activities, roles and responsibilities.

Responsibility

Action PM USER ORC IT CV QA

Prepare R

Review * R

Approve * R

3.1.2. User Requirement Specification (URS)

The URS will consist of High-level User Requirements outlined listing GMP and Non GMP within each Functional Business Area; it will be produced using ISPE GAMP 5 Appendix D1 [1].

Oracle documentation standards referred to in RD030, BP080 and BP090 will be adopted where appropriate.

Responsibility


Prepare R *

Review * * R

Approve * * R





3.1.3. Functional Specification (FS)

The Functional Specification describes the core functions of the system.

Oracle documentation standards to support the functional deliverables of the system will be adopted where appropriate , referring to BR030

Responsibility


Prepare * R *

Review * R *

Approve * R * *

3.1.4. Hardware Design Specification (HDS)

This document will define the design of the Hardware including Network and any Infrastructure requirements in order to support the system.

Responsibility


Prepare R

Review * R * *

Approve R *

3.1.5. System Design Specification (SDS)

Any bespoke developments, as part of the system or its interfaces to other systems, will be documented in an appropriate SDS.

Oracle documentation standards to support development of specific deliverables of the system for will be adopted where appropriate. Referred to in MD050 and MD070 (if appropriate)

Responsibility


Prepare * R *

Review * R *

Approve * R * *





3.1.6. Code Review (CR)

This section will focus upon bespoke software developments, which will be subject to Code Reviews and will focus on GMP critical bespoke developments

Responsibility


Prepare R

Review R * *

Approve R

3.2. Risk Management

Risk Management is defined as Risk Assessment plus Risk Control.

An effective FMEA risk based approach to elements of Design and Testing as per ISPE GAMP 5 [1] will be adopted throughout.

risk assessment guide in place will be updated to include procedure for Conducting a Failure Mode Effect Analysis as per ISPE GAMP5.

Results from the FMEA assessment will be utilised to focus validation-testing effort at a sub-process level during implementation.

Each specific element identified is therefore assessed for its risk and its controlling identifier and tested\checked accordingly.

Responsibility


Prepare * R

Review * * R

Approve * * * R

A TRACEABILITY MATRIX for the URS>FS>SDS which also has GxP criticality will be produced and refer to risks identified.

Particular reference to key regulatory requirements such as US FDA 21 CFR Part 11 covering Electronic Records, Electronic Signatures and recent proposed updates to EU Directives 2003/94/EEC Annex 11 Computerised Systems will be taken into consideration during the Risk Assessment process.





3.3. Testing Phase

Specifications will be produced and testing conducted against them accordingly, in conjunction with previously approved documentation specified in the Design Phase in section 3.1

In addition, consideration will be given to aligning or combining tests (for example Functional Testing or User Acceptance Testing) to the project methodology as specified in the V-model diagram in section 3.

Installation Qualification (IQ) is a combination of Hardware and System Configuration testing. Operational Qualification (OQ) is a combination of System design and Functional testing. Performance Qualification will represent the User Acceptance Testing.

3.3.1. System Acceptance Test Specification (SATS)

This section will cover all aspects of system acceptance testing and will be conducted in accordance with test specifications (SATS) exclusively on bespoke developments defined in the corresponding SDS document.

Test scripts within the SATS will refer to the details contained in the SDS document.

All bespoke developments, as part of the system or its interfaces to other systems, deemed to be of a GxP critical nature or to have an impact on the GxP or regulatory

aspects of the system will be tested.

Responsibility


Prepare R *

Review * * R * *

Approve R

3.3.2. Hardware Acceptance Test Specification (HATS)

This section will cover Hardware (and system software) acceptance tests will be conducted in accordance with a test specification (HATS) against the details within the HDS.

Responsibility


Prepare R *

Review * R *

Approve R





3.3.3. Functional Test Specification (FTS)

Functional Testing will be conducted against Functional Specification(s) to challenge the delivered functionality required by the Users.

Responsibility


Prepare R *

Review * * R

Approve R

3.3.4. User Acceptance Test Specification (UATS)

User Acceptance Testing will verify that all requirements of the system have been met. This will include Business Scenario Testing, where appropriate.

Responsibility


Prepare R * *

Review * * R

Approve R

3.3.5. Hardware Acceptance Testing (HAT)

Hardware Acceptance Testing verifies the installation of all computer systems and any input/output links or interfaces.

Responsibility


Prepare R *

Review * R

Approve * R





3.3.6. System Acceptance Testing (SAT)

System Acceptance Testing verifies all bespoke system software functions as specified.

Responsibility


Prepare R

Review R *

Approve R

3.3.7. Functional Testing (FT)

Verifies that all core functionality of the system meets it specification.

Responsibility


Prepare R * *

Review * * R *

Approve * R

3.3.8. User Acceptance Testing (UAT)

Verifies that all business processes have been comprehensively tested and that relevant SOPs are operational.

Responsibility


Prepare R * *

Review * * R *

Approve * R





3.3.9. Validation Reporting (VR)

There will be validation report for the project, which includes the validated status of the system.

Responsibility


Prepare R

Review R * * * *

Approve R R

4. On-going Operational Phase

The following elements will be assessed as part of the process that determines the on-going validated status of the system:

4.1. Maintenance Plan

The maintenance plan for the control of the system, data and supporting activities will be created / reviewed.

4.2. Change Management

Changes to the system will be conducted in accordance with procedure reference which should include change control , patch management and configuration management and will be subject to review.

4.3. System Administration, Security and Access

All aspects of system administration including security and access to the system will be conducted in accordance with a defined procedure.

4.4. System Backup, Restore and Archiving

All aspects of system backup, restore and archiving will be conducted in accordance with procedure reference and will be subject to review.

4.5. Training and Operating

All users will be trained in accordance with company requirements and training records will be maintained as per requirements detailed in procedure reference .





4.6. Incident , Deviation and CAPA Management

Any incident or deviation raised against Oracle OPM R12 functionalities will be conducted in accordance with procedure reference .

Corrective and preventive actions (CAPA) will be conducted in accordance with procedure reference

(if not exists : A procedure describes the corrective and preventive actions (CAPA) system including a number of CAPA initiators such as incident management will be identified and approved. )

4.7. Performance Monitoring

All aspects of systems performance monitoring based on Key Performance Indicators (KPIs) will be managed and monitored in accordance with defined procedure.

5. Periodic Reviews

SOPs and records, produced as a result of system use and support, will be audited on a regular basis to evaluate the effectiveness of controlling procedures. Details of reviews will be formally recorded and approved in accordance with procedure reference and will be subject to review.

Documentation updates are covered within change control reference 4.2

6. Glossary

Term Definition

AIM Application Implementation Method

CAPA Corrective Action Preventive Action

CFR Code of Federal Regulation

DQ Design Qualification

EU European Union

FMEA Failure Mode and Effects Management

FS Functional Specification

FDA US Food and Drug Administration

FT Functional Testing

FTS Functional Test Specification

GAMP Good Automated Manufacturing Practice

GMP Good Practice Processes, which must ensure the safe control of product. These are general processes associated with the acquisition, conversion, shipment and tracking of component materials and manufactured items.

GxP Good Practices, including Manufacturing etc.

HAT Hardware Acceptance Testing

HATS Hardware Acceptance Test Specification

IQ Installation Qualification

ISPE International Society of Pharmaceutical Engineering

KPI Key Performance indicators

OPM Oracle Process Manufacturing





Term Definition

OQ Operational Qualification

PQ Performance Qualification

SAT System Acceptance Testing

SDS Software Design Specification

SOPs Standard Operating Procedures

UAT User Acceptance Testing

UATS User Acceptance Test Specification

URS User Requirements Specification

7. Regulations and Guidelines

The following guidelines and regulatory requirements are taken into consideration:

[1] ISPE GAMP 5. Good Automated Manufacturing Practice. Guide for Validation of Automated Systems in Pharmaceutical Manufacture, Version 5.0 March 2008.

[2] USA FDA 21 Code of Federal Regulation {CFR} Part 11, 1997.

[3] USA FDA 21 Code of Federal Regulation {CFR} Parts 210 and 211 GMP.

[4] 2001/83/EC. Manufacture and Importation with European Directives 2003/94/EEC and 91/412/EEC laying down the principles and guidelines of GMP

[5] Egyptian Ministry of Health (MOH) regulation and authorities.





Appendix A - Specific Project Roles, Responsibilities and Key Deliverables Table

The following key personnel have been identified:

Affiliation/Job Title/Function

Acronym Name Responsibility

Project Manager PM Project Manager and System Owner

Quality Assurance QA Project Quality Assurance

Computer System Validation

CSV Validation Project Manager

Oracle ORC Software Vendor

Information Technology

IT Validation Support Co-Ordinator

Validation Project Technical Support

User USER Inventory

Purchasing

Planning

Quality Control

Production

You can add appendices from the project charter ,, like Project team and Gantt Chart

oracle r12 opm vmp 0.1

Documents

vp oracle opm

validation master plan

validation consultant

validation lifecycle

opm overview

oracle methodology

system description

functional specification