Duarte_Marques_2007100447_2009_rf

Validao de Sistemas Informticos na Indstria Farmacutica

Duarte Augusto Marques

Dissertao para obteno do Grau de Mestre em: Engenharia e Gesto Industrial

Jri Presidente: Prof. Jos Lus Afonso Orientador: Prof. Cristvo Silva

Vogal: Prof. Norberto Pires

Julho de 2009


Pgina 1 de 72

Agradecimentos Os meus agradecimentos vo antes de mais para a Bluepharma na pessoa do seu CEO,

Dr. Paulo Barradas pela oportunidade e recursos que disponibilizou para a realizao do

estgio curricular, e aos colaboradores da empresa, em especial aos dos departamentos da

Garantia de Qualidade e IT, que no dia-a-dia permitiram-me no s apreender

competncias tcnicas, mas tambm as competncias organizacionais essenciais minha

boa integrao na empresa.

Um obrigado muito especial ao meu orientador na empresa, o Eng Srgio Boticrio que

manteve uma grande proximidade e do qual obtive uma orientao diria na realizao

deste trabalho, ao Prof. Cristvo Silva que se revelou sempre prestvel e clere a

esclarecer todas as dvidas que foram surgindo no decorrer dos ltimos meses.

No posso tambm deixar de referir as pessoas que me deram uma ajuda preciosa e

guiaram num tema que era novo para mim e que exigiu esforo de todas partes para que o

processo fosse levado a bom termo, revelando profissionalismo e muita experincia no

campo da validao de sistemas informticos, essas pessoas foram a Dr Teresa Murta e o

Eng Rui Pires da Garantia de Qualidade.

Gostaria ainda de prestar um agradecimento muito especial minha famlia que sempre

me deu o apoio e compreenso necessrios ao longo destes anos que culminam na

realizao deste trabalho.


Pgina 2 de 72

Resumo Esta dissertao foi realizada no mbito da validao de sistemas informticos na

Indstria Farmacutica. O principal objectivo das actividades de validao de um sistema

informtico na indstria farmacutica o de salvaguardar a segurana do paciente, a

qualidade do produto, e a integridade dos dados. A segurana dos pacientes afectada

pela integridade dos registos crticos, dados e decises, bem como pelos aspectos que

afectam os atributos fsicos do produto.

Este documento pretende, portanto, dar a conhecer de uma maneira geral do que trata a

validao de sistemas informticos dando nfase especial aplicao deste processo no

ambiente altamente regulamentado da indstria farmacutica. Aplicando esta abordagem

na empresa Bluepharma, foi definido o mbito desta validao atravs de uma avaliao

de riscos e de um plano mestre de validao, que identificaram o software ERP

implementado e as infra-estruturas que o suportam como sendo os mais crticos. O

sistema em causa o MySAP ERP 2005 e gere toda a actividade na empresa desde a

compra de matria-prima at venda e distribuio de produto acabado. A validao

ainda um processo de ciclo de vida, tendo comeado em 2002 aquando da introduo da

primeira verso do software SAP na empresa, mdulos MM, FI/CO, QM, SD e PP-PI.

Em 2006 foi feita a actualizao para a verso MySAP ERP 2005 com a adio dos

mdulos PM e WM com os respectivos interfaces de rdio-frequncia. Surge ento a

necessidade de conduzir todos estes mdulos ao longo do processo de validao, que

inclui a qualificao e teste das suas funcionalidades, uma vez que existe interaco e

ligao entre os seus processos. Assegurando que a documentao que suporta a

manuteno deste sistema a adequada.

Palavras-Chave Sistema Informtico; Validao; Especificaes Funcionais; Qualificao de Instalao

(QI); Qualificao Operacional (QO); Qualificao de Performance (QP)


Pgina 3 de 72

Abstract This dissertation was performed within the scope of computer systems validation in the

Pharmaceutical Industry. The main objective of the validation activities of a computer

system in the pharmaceutical industry is to safeguard patient safety, product quality, and

integrity of data. The safety of patients is affected by the integrity of critical records, data

and decisions, and the aspects that affect the physical attributes of the product.

This document intends therefore to make known in a general way the process of

validation of a computer system giving special emphasis to the application of this process

in the highly regulated environment of the pharmaceutical industry. Applying this

approach in the company Bluepharma, the validation scope was defined using a risk

assessment and a validation master plan, which identified the implemented ERP software

and infrastructure of support the most critical. The system in question is the MySAP ERP

2005 and manages all activities in the company since the purchase of raw materials to the

sale and distribution of finished product. Validation is a life cycle process, having started

in 2002 at the time of introduction of the first version of the SAP software in the

company, modules MM, FI/CO, QM, SD and PP-PI. In 2006 the upgrade to MySAP ERP

2005 version was made, with the addition of PM and WM modules and the radio-

frequency interfaces. From this arises the need to drive all these modules through the

validation process, which includes the qualification and test of its functionalities, since

there is interaction and connection between their processes. Ensuring that the

documentation that supports the maintenance of this system is appropriate.

Keywords Computer Systems; Validation; Functional Specifications; Installation Qualification (IQ);

Operational Qualification (OQ); Performance Qualification (PQ)


Pgina 4 de 72

ndice Agradecimentos .................................................................................................................. 1 Resumo ............................................................................................................................... 2 Palavras-Chave ................................................................................................................... 2 ndice ................................................................................................................................... 4 Lista de quadros e figuras ................................................................................................... 6 Lista de abreviaes ............................................................................................................ 7 1. Prembulo ................................................................................................................... 8

1.1 Ambiente actual .............................................................................................. 9 1.2 Leis e normas ................................................................................................ 10

2. mbito da Validao de Sistemas Informticos ....................................................... 10 2.1 Software MySAP ERP 2005 ............................................................................. 12

3. Avaliao de Risco ................................................................................................... 14 3.1 Propsito ........................................................................................................... 15 3.2 mbito .............................................................................................................. 16 3.3 Estratgia ........................................................................................................... 16 3.4 Metodologia ...................................................................................................... 17

3.4.1 Anlise Funcional ..................................................................................... 17 3.4.1.1. Avaliao do risco ................................................................................. 18 3.4.1.2. Classe do Risco ..................................................................................... 19 3.4.1.3. Nvel de risco ........................................................................................ 20 3.4.1.4. Actividades de Validao ..................................................................... 21

3.5 Mtodo Risk Failure Mode and Effects Analysis (RFMEA) ............................ 22 3.6 Resumo ............................................................................................................. 31

4. Qualificao .............................................................................................................. 32 4.1 Qualificao e Especificaes de Desenho ....................................................... 32

4.1.1 Especificao dos Requisitos do Utilizador (ERU) .................................. 33 4.1.2 Especificao Funcional ........................................................................... 33 4.1.3 Avaliao do Fornecedor .......................................................................... 34

4.2 Qualificao de Instalao ................................................................................ 36 4.3 Qualificao Operacional .................................................................................. 37 4.4 Qualificao de Performance ............................................................................ 39

5. Relatrio de Validao .............................................................................................. 40 6. Plano Mestre de Validao (PMV) ........................................................................... 41

6.1. Sobre este documento ....................................................................................... 41 6.1.1. Finalidade .................................................................................................. 41 6.1.2. Audincia .................................................................................................. 42 6.1.3. mbito ...................................................................................................... 42 6.1.4. Incluses ................................................................................................... 42

6.2. Viso Geral do Sistema ..................................................................................... 43 6.2.1. Funcionalidades MySAP .......................................................................... 43 6.2. 2 Arquitectura do Sistema ............................................................................ 45

6.3 mbito da Validao ........................................................................................ 46 6.4 Processo de Validao e Resultados ................................................................. 47


Pgina 5 de 72

6.4. 1 Processo .................................................................................................... 47 6.4. 2 Resultados ................................................................................................. 47

6.5 Planeamento de Testes ...................................................................................... 49 6.5. 1 Estratgia de Teste .................................................................................... 49 6.5. 2 Categorias de Teste ................................................................................... 49 6.5. 3 Execuo dos Testes ................................................................................. 50 6.5. 4 Matriz de Testes ........................................................................................ 50 6.5. 5 Falhas de Testes e Resoluo .................................................................... 51

6.6 Aceitao ........................................................................................................... 51 6.7 Gesto de Documentos ..................................................................................... 52 6.8 Formao ........................................................................................................... 52

7. Abordagem de Ciclo de Vida .................................................................................... 52 8. Manuteno do Estado de Validao ........................................................................ 56

8.1 Manuteno Preventiva e Calibrao ................................................................ 56 8.2 Instalao e Validao/Revalidao ................................................................. 56 8.3 Gesto de Alteraes e Controlo de Configuraes ......................................... 56 8.4 Audit Trail ......................................................................................................... 59 8.5 Backup e Restore .............................................................................................. 59 8.6 Planeamento de Continuidade de Negcio ....................................................... 59 8.7 Segurana .......................................................................................................... 60 8.8 Registos Electrnicos e Assinaturas Electrnicas ............................................. 61 8.9 Revalidao ....................................................................................................... 61 8.10 Testes ................................................................................................................ 62

8.10.1 Testes s Unidades .................................................................................... 63 8.10.2 Testes de Integrao .................................................................................. 63 8.10.3 Testes de Aceitao de Sistema ................................................................ 63 8.10.4 Testes de Esforo ...................................................................................... 64 8.10.5 Resultados dos Testes ............................................................................... 64

8.11 Documentao ................................................................................................... 65 8.11.1 Documentao na Empresa ....................................................................... 66 8.11.2 Aprovao da documentao .................................................................... 68

9. Concluso .................................................................................................................. 69 10. Referncias Bibliogrficas .................................................................................... 71 11. Anexos .................................................................................................................. 71


Pgina 6 de 72

Lista de quadros e figuras

Quadro 1 Categorias GAMP ....................................................................................... 11 Quadro 2 Mdulos SAP implementados .................................................................... 17 Quadro 3 Mdulos SAP versus relevncia GxP ........................................................ 18 Quadro 4 Classe de Risco ............................................................................................ 20 Quadro 5 Nvel de Risco .............................................................................................. 21 Quadro 6 Actividades de Validao a realizar .......................................................... 22 Quadro 7 Representao de alguns dos processos analisados. ................................ 25 Quadro 8 Sumrio dos processos de falha e actividades de validao a realizar .. 27 Quadro 9 Risco do Fornecedor versus Risco do Produto ......................................... 35 Quadro 10 Categorias GAMP versus Nvel de Risco ................................................ 38 Quadro 11 - Utilizao de clientes na paisagem do sistema MySAP .......................... 46

Figura 1 Sistema Informtico ..................................................................................... 10 Figura 2 Actividades desenvolvidas e respectiva documentao gerada para cada fase .................................................................................................................................... 13 Figura 3 Fluxograma de processos para avaliao de riscos ................................... 15 Figura 4 Grficos Pareto do Risk Score (em cima) e RPN (em baixo) para os processos de 51 a 112 ...................................................................................................... 28 Figura 5 Risk Score versus RPN dos processos de falha .......................................... 29 Figura 6 Risk Score versus RPN dos processos de falha e destaque daqueles cuja validao prioritria .................................................................................................... 30 Figura 7 - Aspecto do Sistema ERP MySAP ................................................................ 46 Figura 8 - Modelo V - Ciclo de Vida ............................................................................. 53 Figura 9 - Modelo 4Q - Ciclo de Vida ........................................................................... 54 Figura 10 Ciclo de vida do sistema informtico SAP ............................................... 55 Figura 11 Fluxograma seguido quando existem alteraes a ser implementadas . 58 Figura 12 Representao do processo de execuo dos testes .................................. 62 Figura 13 Hierarquia da documentao na empresa ............................................... 67


Pgina 7 de 72

Lista de abreviaes AR Avaliao de Risco

SAP Systeme, Anwendungen und Produkte in der Datenverarbeitung ("Systems,

Applications and Products in Data Processing") refere-se ao software de ERP.

IT Information Technology

GQ Garantia de Qualidade

QI Qualificao de Instalao

QO Qualificao Operacional

QP Qualificao de Performance

PMV Plano Mestre de Validao

cGMP Abreviatura de current Good Manufacturing Practice.

GAMP Abreviatura de Good Automated Manufacturing Practices

GxP Abreviatura de Good Manufacturing/Laboratory/Clinical/Distribution Practice

MRP Material Requirements Planning.

MRP II Manufacturing Resource Planning.

ERP Enterprise Resource Planning

ID Identificao


Pgina 8 de 72

1. Prembulo A criao de sistemas informticos validados , em primeira instncia, em grande parte

uma questo do programador de software, que adopta os princpios bsicos de boas

prticas em engenharia de software sob a superviso formal e documentada da garantia de

qualidade. A validao destes sistemas informticos consiste no processo de

estabelecimento de dados documentados que proporcionem um elevado grau de

segurana de que o software e infra-estrutura associada iro cumprir consistentemente as

suas especificaes e atributos de qualidade predeterminados, esta abrangente definio

engloba todos os usos de sistemas informticos e tem sido amplamente adoptada, embora

com modificaes, pelas diversas autoridades reguladoras ao nvel GxP (Good

Manufacturing/Laboratory/Clinical/Distribution Practice) de todo o mundo.

As empresas farmacuticas, devem, ento, elas prprias validar todos os sistemas

informticos utilizados para atender s operaes regidas pelos regulamentos GxP. O

software e hardware devem cumprir os requisitos GxP para os registos de fabricao e

equipamentos, respectivamente.

Isso normalmente afecta os sistemas informticos que monitorizam e/ou controlam a

produo de medicamentos cujo mau desempenho poderia eventualmente afectar a

segurana, qualidade e eficcia (durante o fabrico), ou rastreio do lote (durante a

distribuio) de produtos farmacuticos. Outras aplicaes de sistemas informticos, no

entanto, tambm podero ser afectadas. Os exemplos incluem os sistemas informticos

usados para armazenar e distribuir os procedimentos, os sistemas informticos usados

para agendar a formao e/ou determinar se os indivduos tm as competncias

necessrias para cumprir uma determinada funo, e os sistemas informticos utilizados

para a emisso das credenciais de utilizador para controlar o acesso a outros sistemas

informticos. assim claro que a lista de potenciais aplicaes de sistemas informticos

que exigem validao extensa.

O trabalho apresentado neste relatrio decorreu numa empresa de produo de produtos

farmacuticos e teve como principal objectivo acompanhar o processo de validao dos

sistemas informticos dessa empresa. Nesse sentido foram desenvolvidas vrias

actividades. Entre as quais um Plano Mestre de Validao baseado numa Avaliao de


Pgina 9 de 72

Riscos, onde foi feito um levantamento dos sistemas crticos que precisam de ser

validados, de seguida partiu-se para as Qualificaes e respectivos testes das

funcionalidades consideradas crticas, que se apresentam mais tarde neste trabalho. Ao

longo deste processo surgiu a necessidade de elaborao de documentos para utilizao

na empresa que garantam a boa utilizao do sistema, e por motivos de confidencialidade

feita apenas uma breve referncia neste trabalho.

1.1 Ambiente actual

Actualmente esto em uso generalizado em toda a indstria farmacutica Sistemas

Informticos que ilustram ou controlam processos de qualidade relevantes. Eles esto

sujeitos s exigncias das vrias coleces de regulamentao farmacutica para a

validao desses sistemas, e desde 1997 a autoridade americana FDA estabelece

requisitos relativos aos registos electrnicos / assinaturas electrnicas no artigo 21 CFR

Part 11i.

Os sistemas informticos tm uma grande probabilidade de se danificarem: dados

importantes que desaparecem que tm como causa provvel erro humano, redes que se

desligam e vrus que corrompem ficheiros apesar das solues que as organizaes

utilizam para proteger os mltiplos acessos de que dispem. Por conseguinte, no fcil

manter a integridade dos dados.

Daqui nasce a necessidade de Validar. Produzindo a evidncia documental que garanta,

com um alto grau de segurana, o correcto funcionamento de todas as partes de um

sistema informtico.

Os benefcios de validar um sistema informtico so:

Compliance (Cumprir com a regulamentao vigente);

Sistemas bem definidos, mais fceis de serem mantidos e com maior

disponibilidade;

O sistema ajusta-se ao seu propsito;

Os requisitos de utilizador so satisfeitos;

Amplo conhecimento do sistema e processos por parte dos utilizadores e IT;

O risco de falha do sistema reduzido;


Pgina 10 de 72

Os padres de qualidade so mantidos;

Maior planeamento e facilidade de recuperao de catstrofe.

1.2 Leis e normas

Os processos de validao de sistemas informticos neste tipo de indstria so regidos

por um conjunto de normas e regulamentos das quais se destacam:

EU GMP Annex 11 (91/412/EEC/Annex 11)

21 CFR 210, 211 (current Good Manufacturing Practice)

21 CFR Part 11 (Electronic Records Electronic Signatures)

21 CFR 820 (medical devices, blood establishment)

GCP Directive 775/318/EEC (1997/01/01)

2. mbito da Validao de Sistemas Informticos A validao de sistemas informticos inclui a validao de sistemas informticos novos e

j implementados.

O processo de validao consiste na produo de provas de que um sistema ir satisfazer

as suas especificaes. Esta definio no se refere apenas a uma aplicao informtica

ou a um sistema informtico (Figura 1), mas a um processo. As principais implicaes

disto so que a validao deve abranger todos os aspectos do processo, incluindo a

aplicao, qualquer hardware que usa a aplicao, as interfaces com outros sistemas, os

utilizadores, o treino e documentao, bem como a gesto do sistema aps este ser

colocado em uso.

Sof

twar

e

Har

dwar

e

Figura 1 Sistema Informtico


Pgina 11 de 72

Para os novos sistemas a validao comea quando um departamento tem necessidade de

um novo sistema de informao e reflecte sobre a forma como o sistema pode resolver

um problema existente. Para um sistema implementado comea quando o supervisor do

sistema recebe a tarefa de elevar o sistema a um estado validado. A validao termina

quando o sistema completamente alienado e todos os dados cuja qualidade de grande

importncia so migrados para o novo sistema com xito. Importantes passos na

validao so o planeamento, a definio dos requisitos dos utilizadores, as

especificaes funcionais, especificaes de concepo, validao durante o

desenvolvimento, avaliao do fornecedor para sistemas adquiridos, instalao, a

realizao de testes no incio e ao longo do tempo e o controlo de alteraes. Por outras

palavras, os sistemas informticos devem ser validados durante todo o ciclo de vida do

sistema.

A extenso da validao depende da complexidade do sistema informtico e, no local do

utilizador depende tambm da utilizao generalizada do produto e verso do software.

Quanto mais um software standard utilizado e menos parametrizao feita para esse

software menos testes sero exigidos. As normas GAMPii tm desenvolvido categorias de

software com base no nvel de parametrizao. No total, existem cinco categorias. A

categoria um e dois definem sistemas operacionais e firmware de sistemas automatizados.

Neste contexto apenas as categorias trs a cinco so de interesse. Elas esto descritas no

Quadro 1. Cada sistema informtico deve estar associado a uma das trs categorias:

Categoria Descrio

GAMP 3 Pacote de software standard. Sem customizao. Exemplo: MS Word (sem scripts VBA).

GAMP 4

Pacote de software standard. Customizao ou configurao. Exemplos: LIMS, Folhas de clculo Excel onde as frmulas e/ou dados de input esto ligados a clulas especficas. Sistemas de dados ligados em rede. ERP SAP customizado na parte dos equipamentos de pesagem.

GAMP 5 Pacote de software customizado. Todo ou parte do pacote completo de software foi desenvolvido para um utilizador especfico e aplicao. Exemplos: Adicionar categorias GAMP 3 e 4, Excel com scripts VBA.

Quadro 1 Categorias GAMP


Pgina 12 de 72

2.1 Software MySAP ERP 2005

O objectivo de validao deste software delinear os requisitos que iro demonstrar e

documentar que todos os componentes, sistema(s) de controlo e funcionalidades

associadas ao SAP ERP 2005 so adequados para os processos cGMP regulamentados.

As qualificaes delineadas baseiam-se nas polticas, procedimentos e regulamentos

aplicveis da Bluepharma, nas directrizes e prticas da indstria aceites para validao.

Os computadores e programas instalados na empresa so amplamente utilizados durante o

desenvolvimento e fabricao de medicamentos e produtos farmacuticos. Da, o bom

funcionamento e desempenho do software e dos sistemas informticos terem um papel

importante na obteno da consistncia, confiabilidade e preciso dos dados. Portanto, a

validao de sistemas informticos (VSI) deve ser parte de qualquer bom

desenvolvimento e prticas de fabrico. tambm solicitado pela FDA atravs de

regulamentaes e directrizes globais a exigncia de que "o equipamento deve ser

adequado para a sua utilizao". Os requisitos especficos para os computadores podem

ser encontrados na seco 211,68 dos regulamentos E.U. cGMPiii.

O mtodo de validao do sistema informtico apresentado neste trabalho, no nico.

Pelo contrrio, a validao de um sistema informtico muito complexa e vrias

alternativas podem ser utilizadas. O mbito de qualquer validao depende de diversos

factores como o tamanho, complexidade e a natureza das suas funes (se so ou no

crticas). O mtodo de validao descrito foi o utilizado para a validao do Sistema

Informtico MySAP ERP 2005, sistema de gesto que controla todo o processo produtivo

desde a encomenda das matrias-primas, manipulao, anlise, passando pelo fluxo de

materiais e produto desde que este chega s instalaes, at distribuio do produto

acabado. Controla ainda processos da empresa no directamente relacionados com a

gesto da produo, tais como o controlo das reas financeira e de recursos humanos.

Neste trabalho sero identificados os factores que foram considerados e os passos

tomados para a validao do referido sistema e infra-estrutura associada. H no entanto,

fases do processo (ver Figura 2) que j foram realizadas, e portanto no esto

contempladas, um exemplo disto a fase de Desenho, Construo, e avaliao do

fornecedor que foi realizada aquando da compra do sistema ERP em 2002 e antes da sua


Pgina 13 de 72

instalao na empresa. Na figura que se segue, podemos ver as vrias actividades de

validao desenvolvidas e respectiva documentao que foi gerada, como exemplo disso

foi a elaborao do documento Especificao Funcional dos Sistemas (EFS), onde foi

feito um levantamento e caracterizao dos sistemas instalados no departamento de

Controlo da Qualidade, Produo e Embalagem. Este documento pode ser consultado no

CD de suporte informtico a esta dissertao.

Figura 2 Actividades desenvolvidas e respectiva documentao gerada para cada fase


Pgina 14 de 72

3. Avaliao de Risco A avaliao de riscos realizada para analisar os efeitos de operao e confiabilidade do

sistema. Os aspectos identificados como crticos devem ser verificados especialmente

durante a validao do ciclo de vida, em todas as suas diversas fases.

O documento Avaliao de Riscos (AR) foi desenvolvido na empresa e aqui

apresentado um excerto. Inclui as actividades de avaliao de riscos aplicadas sobre as

funes especficas do sistema em causa. Todas as funes do sistema sero avaliadas e

classificadas de acordo com o seu nvel de risco, seguindo a metodologia descrita no guia

GAMP, representada na Figura 3. Este documento, juntamente com os Manuais do

Utilizador e os Testes Funcionais existentes ir fornecer o enquadramento e mbito de

aplicao do sistema que ser utilizado para definir a validao adicional de actividades

necessrias para assegurar o cumprimento das normas GxP. O seu objectivo concentrar

os esforos da equipa de validao nos processos crticos que representam maior risco.


Pgina 15 de 72

Identificao do Processo

Identificar os cenrios de Risco

Determinar as aces a tomar

Avaliar a probabilidade de

detectar a condio de falha

Avaliar o Nvel de Risco

Avaliar a Severidade de

Impacto

Avaliar a probabilidade da condio de falha

Risco para GxP/Negcio

Documentar na matriz da AR

Documentar na matriz de AR

Documentar o risco na matriz de

AR

No

Sim

Justificao para o status no GxP relevante

Descrio da funo e relevncia GxPprobabilidade de riscoprobabilidade de detecocalculo do nvel de risco

Sumrio da resposta

Figura 3 Fluxograma de processos para avaliao de riscos

3.1 Propsito O objectivo da avaliao de riscos o de realizar um estudo das funes estabelecidas

para os vrios elementos que constituem o mbito da validao deste projecto, a fim de

identificar quais so considerados os aspectos crticos a partir de uma perspectiva cGxP e,

devem portanto, ser submetidos a validao.

A avaliao dos riscos deve ser capaz de responder s seguintes perguntas, alm de

fornecer as informaes fundamentais para a identificao de todos os potenciais factores

de risco do sistema:

- O software SAP precisa de ser validado?

- Que nvel de validao necessria para o SAP?


Pgina 16 de 72

- Que aspectos do SAP ou dos seus processos so crticos para o produto ou para a

segurana do paciente?

A avaliao do risco um instrumento adequado para identificar as reas de processo

com uma real ou potencial fraqueza, a fim de implementar contramedidas e planos de

aco correctiva adequados.

3.2 mbito O processo de avaliao de risco necessrio no decurso de um projecto para focar a

validao naquelas funcionalidades que comportem o maior risco relativamente

qualidade, eficcia e pureza do produto farmacutico.

No dispondo de recursos infinitos e por limitaes de tempo necessrio analisar os

riscos associados a cada processo e estabelecer prioridades entre eles.

O mbito ou campo de aplicao desta avaliao de riscos a aplicao SAP ERP para a

gesto dos processos de negcio atravs da implementao dos mdulos que constituem a

aplicao, o que permitir a gesto das actividades de produo dos produtos

farmacuticos e outras funes empresariais dentro das instalaes da Bluepharma

localizada em So Martinho do Bispo (Coimbra, Portugal).

O alvo desta validao o upgrade do SAP R/3 (a partir da verso 4.6C para MySAP

ERP 2005), dos mdulos FI, CO, MM, SD, PP-PI e QM e dotar a Bluepharma das novas

funes dos mdulos WM (Warehouse Management) e PM (Plant Maintenance).

3.3 Estratgia O principal objectivo desta Avaliao de Riscos o de assegurar o cumprimento GxP em

todos os processos geridos a partir do sistema ERP SAP R/3. Uma vez que cada

funcionalidade foi identificada e avaliada, as concluses obtidas a partir da Avaliao de

Riscos dever deixar o Supervisor do Sistema e o departamento de Garantia de Qualidade

focalizarem as actividades de validao nas questes mais crticas ao nvel GxP,

minimizando o tempo necessrio para a validao e optimizando a aplicao do sistema.

Desde que o sistema utilizado na Bluepharma, ano de 2002, a estratgia seguida na

avaliao dos riscos baseia-se nos mdulos SAP R/3 instalados e na documentao

existente:


Pgina 17 de 72

Mdulos SAP Implementao Documentos de validao existentes FI, CO, MM, PP-PI, SD, QM

Ano 2002: - SAP R/3 4.6c - Oracle 8i - Interface de escalas de Produo

- Os requisitos dos utilizadores (ERU) - Business Blueprint (BBP) - Manuais do Utilizador - Testes funcionais para operaes GMP relevantes

WM, PM Modificao dos outros mdulos de modo a integrar WM e PM

Ano 2006: - Upgrade para MySAP ERP 2005 - Upgrade para Oracle 10i - Interface terminais RF - Melhoramento de Hardware e rede

- Business BluePrint (BBP) - Manuais do utilizador

Quadro 2 Mdulos SAP implementados

Nota: os testes funcionais realizados para os mdulos implementados no ano de 2002

foram executados na base documentada e incidiram sobre as operaes GxP. Este facto

tido em conta na avaliao de risco das funes correspondentes.

3.4 Metodologia

3.4.1 Anlise Funcional Nesta fase, todas as funes e operaes do sistema, sero identificadas, a fim de analisar

o seu impacto GxP. O SAP R/3 um software ERP padro configurvel, disponvel no

mercado, usado para manipular e gerir a maioria das funes de uma empresa, por

exemplo compras, vendas, produo e qualidade.

A tabela seguinte mostra o sistema de mdulos SAP R/3, de acordo com a Especificao

dos Requisitos do Utilizador (ERU), e aps uma primeira crivagem de acordo com a sua

relevncia ao nvel GxP. Os mdulos que so considerados como GxP no relevantes no

sero considerados para a identificao e avaliao de risco.


Pgina 18 de 72

Mdulo Principais temas GxP Relevncia GxP Material Management (MM) Rastreabilidade de fornecedores e de compras,

matrias-primas e dados mestre dos produtos Sim

Warehouse Management (WM) Fluxo de materiais do armazm, materiais atribudos ao picking e ordens de encomenda, rotulagem Sim

Sales Distribution (SD) Rastreabilidade dos dados dos clientes de produtos farmacuticos entregues Sim

Production Planning (PP-PI) Controlo e rastreabilidade da execuo das ordens de produo Sim

Quality Management (QM) Controlo de qualidade, IPC (In Process Control) Sim Plant Maintenance (PM) Planeamento e controlo da manuteno preventiva e

outras operaes crticas (por exemplo, calibrao) Sim

Financial and Controlling (FI, CO)

Financeira e contabilidade de custos No

Quadro 3 Mdulos SAP versus relevncia GxP

De acordo com o processo de especificaes descrito no manual do utilizador, cada

funo dos mdulos relevantes GxP do sistema ser analisada na coluna "Anlise

Funcional" da Matriz de Avaliao dos Riscos (Quadro 7).

3.4.1.1. Avaliao do risco

Nesta fase, cada funo identificada na anlise funcional ser avaliada e classificada,

considerando as falhas previstas. O modelo definido com base nos seguintes

parmetros:

- Severidade: Nvel de impacto em questes GxP, impacto GxP

- Probabilidade de falha: a probabilidade da falha ocorrer

- Detectabilidade: probabilidade de que a falha vai ser notada antes de ocorrer o no

cumprimento GxP

Usando a documentao do sistema como referncia, as funcionalidades do sistema so

identificadas, os parmetros de riscos so avaliados e dada uma pontuao relativa.

A pontuao relativa para cada funcionalidade do sistema documentada na matriz de

avaliao de risco.


Pgina 19 de 72

3.4.1.2. Classe do Risco

O primeiro passo a pontuao da Classe de Risco como uma funo do impacto GxP e a

probabilidade de falha. Os seguintes critrios GxP determinam o impacto de uma

funcionalidade do Sistema:

Impacto GxP

1 Baixo: a funcionalidade avaliada no gere os dados relevantes ou operaes GxP

2 Mdio: a funcionalidade avaliada gere indirectamente os dados relevantes ou operaes GxP

3 Alto: a funcionalidade avaliada gere directamente dados relevantes ou operaes GxP

Dois factores determinam a probabilidade de falha:

- O estado de validao da funo, avaliada a partir do sistema de documentao. A

probabilidade de funes validadas considerado baixo.

- Como a funo tem sido implementada: utilizando operaes SAP standard ou

transaces personalizadas. Sendo o SAP R/3 software standard configurvel (classe 4,

no guia GAMP) considera-se que a probabilidade de falha alta apenas para operaes

customizadas.

Probabilidade de falha

1 Baixo: funcionalidades validadas

2 Mdio: funcionalidades no validadas, implementado utilizando operaes do SAP R/3 standard

3 Alto: funcionalidades no validadas, implementadas usando transaces/tabelas parametrizadas


Pgina 20 de 72

A tabela seguinte mostra como calculada a Classe de Risco:

Classe de Risco Probabilidade

Baixo Mdio Alto

Impa

cto

GxP

Alto

Classe de Risco 2

Classe de Risco 1

Classe de Risco 1

Mdio Classe de Risco 3

Classe de Risco 2

Classe de Risco 1

Baixo Classe de Risco 3

Classe de Risco 3

Classe de Risco 2

Quadro 4 Classe de Risco

3.4.1.3. Nvel de risco

O nvel de risco calculado permite classificar as funes como de alto risco, mdio risco e

baixo risco, no que diz respeito aos valores normais estabelecidos. O nvel de risco

calculado a partir da classe de risco e da probabilidade de deteco da falha. Dois factores

determinam a probabilidade de deteco da falha:

- Estado da validao da funo. Trata-se de considerar que os testes de esforo

realizados na validao verificam que a funo fivel e que o operador avisado

quando a funo no utilizada correctamente.

- O tempo, que a funo est operacional, possvel considerar que a maioria dos erros

seria detectada durante um longo perodo de tempo.

Detectabilidade, probabilidade de deteco da falha

1 Alto: funcionalidades validadas

2 Mdio: funcionalidades no validadas, mas utilizadas desde a primeira implementao do SAP R/3 (2002) 3 Baixo: funcionalidades no validadas, implementado mais recentemente


Pgina 21 de 72

A tabela a seguir mostra como calculado o nvel de risco:

Nvel de risco Detectabilidade

Alto Mdio Baixo

Cla

sse

de R

isco

1

Nvel

Mdio

Nvel

Alto

Nvel

Alto

2 Nvel

Baixo

Nvel

Mdio

Nvel

Alto

3 Nvel

Baixo

Nvel

Baixo

Nvel

Mdio

Quadro 5 Nvel de Risco

Neste ponto, o nvel de risco das diferentes funes do SAP R/3 foi determinado. Para

reduzir o nvel de risco, devem ser realizados numa primeira instncia, os testes de

validao. Dependendo dos resultados obtidos na validao, pode ser necessrio fazer

alteraes no sistema, a fim de garantir conformidade GxP.

3.4.1.4. Actividades de Validao

Esta avaliao dos riscos centra-se no cumprimento das questes GxP, assim, as aces a

tomar sero fixadas pelo nvel de risco, mas tambm pelo Impacto GxP da

funcionalidade. Trata-se de considerar que, mesmo quando atribudo um baixo nvel de

risco, algumas actividades de validao podem ser necessrias para funes GxP

relevantes. Por outro lado, e, para funes GxP no-relevantes no devem ser realizadas

actividades de validao mesmo quando o nvel de risco elevado.

A prioridade de actividades de validao classificada como se segue:

No prioritrio: no necessrio tomar uma aco, a fim de assegurar o cumprimento GxP Baixa prioridade: so recomendados testes de revalidao para confirmar que a documentao existente actualizada, bem como o sistema actua como est especificado Alta prioridade: devem ser realizados testes de validao a fim de assegurar o cumprimento GxP


Pgina 22 de 72

E a tabela a seguir mostra como so determinadas as actividades de validao a serem

realizadas:

Actividades de validao

Nvel de Risco Baixo Mdio Alto

Impa

cto

GxP

Alto Considerar revalidao

Validao requerida

Validao requerida

Mdio Nenhuma aco requerida

Considerar revalidao

Validao requerida

Baixo Nenhuma aco requerida

Nenhuma aco requerida

Nenhuma aco requerida

Quadro 6 Actividades de Validao a realizar

3.5 Mtodo Risk Failure Mode and Effects Analysis (RFMEA)

De seguida apresentam-se os resultados da aplicao do mtodo RFMEAiv associado a

esta avaliao de riscos descrita para o sistema MySAP ERP implementado na

Bluepharma.

Esta anlise de riscos prope a extenso da Failure Mode and Effects Analysis (FMEA)

para um formato que quantifica e analisa os projectos de gesto de riscos. A nova tcnica

chamada de projecto de gesto de Risco FMEA (RFMEA). Os benefcios da RFMEA

incluem uma maior ateno sobre os riscos mais iminentes, dando prioridade ao

planeamento de contingncia dos riscos, uma melhor participao da equipa no processo

de gesto de riscos, e o desenvolvimento de melhores controlos do risco.

Para a RFMEA associada uma classificao com valor de (1 a 3) a cada atributo. O

primeiro atributo o Impacto. O segundo atributo etiquetado como Probabilidade, e o

terceiro a Detectabilidade. Finalmente, a multiplicao do valor do impacto e do valor

de probabilidade para um risco especfico definido aqui como o risk score. E a

multiplicao destes trs valores conduz ao que conhecido como o ndice de Risco ou

Risk Priority Number (RPN). RPN = Impacto* Probabilidade * Detectabilidade.


Pgina 23 de 72

A RFMEA uma ferramenta avanada de risco, que simples e intuitiva. Expande o

conceito de um simples risk score, baseado unicamente sobre o impacto e a probabilidade

de falha, adicionando um atributo para a deteco da falha. Ao adicionar o valor de

deteco, foi possvel melhorar a priorizao do risco. A RFMEA baseia-se na avaliao

tanto do risk score como do valor de RPN para encontrar os riscos crticos que exigem

resposta imediata de planeamento. Se for bem utilizada, a RFMEA pode reduzir bastante

os riscos num projecto, possibilitar por parte da equipa o domnio no planeamento de

riscos, e agir como um recurso para projectos futuros em termos de gesto do

conhecimento.

O valor de deteco contribui para melhorar a classificao dos riscos, a fim de lidar com

aqueles que requerem ateno imediata. Assim, o valor de deteco uma medida da

capacidade de prever o risco especfico. Esses riscos com valores de deteco elevados

podem precisar de mais controlos ou monitorizao para alertas antecipados. O objectivo

detectar o risco o mais cedo possvel.

A tcnica RFMEA foi introduzida como uma forma de sistematicamente captar eventos

de risco, classific-los, e em seguida, responder queles que colocam maior ameaa para

o projecto. Ver (Quadro 7).

Uma vez que os riscos sejam identificados, acrescenta-se os sintomas conhecidos para o

risco e atribui-se os valores de impacto, probabilidade e deteco. No (Quadro 8),

encontra-se um resumo das Identificaes (ID) das falhas e respectiva anlise global em

termos de risco e actividade de validao.


Pgina 24 de 72

N Operaes SAP ActividadesBluepharma Dados ou Operaes Impacto Probabilidade Probabilidade de Nvel de ndice de Validao

manipulados GxP de falha deteco da falha Risco de Risco

1 FI Contabiblidade Baixo 1 Mdio, 2 Mdio, 2 Baixo 4 Nenhuma acoFinanceira funcionalidade funcionalidade requerida

SAP standard operacional desde2002

2 CO Contabiblidade de Baixo 1 Mdio, 2 Mdio, 2 Baixo 4 Nenhuma acoCustos funcionalidade funcionalidade requerida


3 MM-Dados XK01 Dados Mestre de Fornecedor Rastreabilidade de Alto 3 Baixo, 1 Alto, 1 Baixo 3 Considerar Mestre Fornecedor funcionalidade funcionalidade revalidaoFornecedor validada validada teste QP

para MM4 MM-Fornecedor ME61 Avaliao de Fornecedor Homologao Alto 3 Baixo, 1 Alto, 1 Baixo 3 Considerar

Fornecedor funcionalidade funcionalidade revalidaovalidada validada teste QP

para MM

Descrio da funo, transaces relacionadas

Mdulo Finances (FI)

ANLISE DE RISCOANLISE FUNCIONAL

Mdulo no relevante ao nvel GxP

Mdulo Controlling (CO)Mdulo no relevante ao nvel GxP

Mdulo Materials Management (MM)


manipulados GxP de falha deteco da falha Risco de Risco5 MM-Ordens ME11 Gravao de ordens de compra Rastreabilidade Alto 3 Baixo, 1 Alto, 1 Baixo 3 Considerar

de aquisio de ME1E Relatrios de Itens comprados de materiais funcionalidade funcionalidade revalidaodados ME41/ME43/ME9A Requisies de compra adquiridos validada validada teste QP

ME21N/ME9F Ordens de compra para MMME21N/ME51N Libertao de ordens de compra

6 MM-Gesto ME51 Processamento de Gesto de Mdio 2 Mdio, 2 Mdio, 2 Mdio 8 Considerar de ordens de requisies de compra requisies e funcionalidade funcionalidade revalidaoencomenda ME56 Atribuir fontes req. de compra ordens de compra SAP standard operacional desde teste QP

ME54 Libertao de req. de compra 2002 para MMME21/ME25 Criar ordens de compraME28 Ordens de libertao de comprasME18 Enviar informaes de compras

Relatrios7 MM-Gesto de MIRx Processamento de facturas Gesto de Baixo 1 Mdio, 2 Mdio, 2 Baixo 4 Nenhuma aco

Facturas Verificao de facturas Facturas funcionalidade funcionalidade requeridaLibertao de pagamento de SAP standard operacional desdefacturas 2002

8 MM-Cotao MEQx Manter arranjo contingente Cotao de materiais Baixo 1 Mdio, 2 Mdio, 2 Baixo 4 Nenhuma aco funcionalidade funcionalidade requerida


9 MM-Contratos de ME3x Manter contratos de compra Gesto Baixo 1 Mdio, 2 Mdio, 2 Baixo 4 Nenhuma acoCompra de contractos de funcionalidade funcionalidade requerida

compra SAP standard operacional desde2002




Pgina 25 de 72


manipulados GxP de falha deteco da falha Risco de Risco91 PM - Peas e Controlo dos tempos, centros de custo, facturamento ... Tarefas de Baixo 1 Mdio, 2 Mdio, 2 Baixo 4 Nenhuma aco

Materiais manuteno funcionalidade funcionalidade requeridado processo standard administrativa SAP standard operacional desde

2002

92 PM - Relatrios CONTROLO DE EXECUO DA MANUTENO Execuo de Alto 3 Mdio, 2 Baixo, 3 Alto 18 Validaocontrolo da funcionalidade funcionalidade requeridamanuteno SAP standard no validada

93 CONTROLO DE CUSTOS Controlo dos custos e Baixo 1 Mdio, 2 Baixo, 3 Mdio 6 Nenhuma acodos recursos de funcionalidade funcionalidade requeridamanuteno SAP standard no validada

94 Controlo de Controlo de acesso Alto 3 Mdio, 2 Mdio, 2 Alto 12 Teste QPAcesso dos de dados GMP e funcionalidade funcionalidade requeridoUtilizadores operaes GMP SAP standard operacional desde

geridas a partir do 2002SAP R / 3

95 Backup & Restore Gesto da informao de backup e restore Backup e restore Alto 3 Alto, 3 Mdio, 2 Alto 18 Teste de QPregistado pelo sistema SAP R / 3 de informao GMP o restore das processo Back-up requerido para

armazenados cpias backup operacional desde cpias backupno SAP R / 3 no est 2002 e restore

validado96 Gesto de Controlo de Alto 3 Baixo, 1 Baixo, 3 Alto 9 Teste QI

Configuraes Alteraes um controlo de nenhum controlo requeridoalteraes foi de alteraesaprovado para foi reportadoa empresa para SAP R/3

Administrao do sistema, no uma funcionalidade SAP R\3

Para as actividades de manuteno, essas operaes no diferem do

Relatrios e estatsticas utilizadas para controlar a manuteno e asordens de calibrao executadas e pendentes a serem executadas

Gesto do Sistema dos perfis de utilizador

Relatrios e estatsticas utilizadas para controlar o tempo e os custos dastarefas de manuteno de equipamentos,


Gesto de Sistemas ITparagens programadas das instalaes...


N Processo/ Actividades deProblema Impacto Probabilidade Probabilidade de Nvel de ndice Validao

GxP de falha deteco da falha Risco de Risco

Erweka102 QM046 - Interface A carga de trabalho e o Baixo 1 Mdio 2 Alto 1 Baixo 2 Nenhuma aco

com o Erweka tempo que os utilizadores requeridalevam a fazer a introduode resultados manualmente

Falhas de Hardware103 Servidor Prever falha de sistema e recriar o sistema de Todas as actividades do Alto 3 Alto 3 Alto 1 Mdio 9 Validao

Produo na mquina de Desenvolvimento sistema cessam. requerida(este procedimento demora em mdia 1 a 2 dias) Realizao manual de

todas as tarefas crticasFalhas de Rede104 Falha de Rede Falha Total - no h forma de contornar o problema Todas as actividades do Alto 3 Mdio 2 Alto 1 Mdio 6 Validao

Falha Parcial - partilha de estaes de trabalho sistema cessam. requeridapelos utilizadores Realizao manual de

todas as tarefas crticas

atravs da transaco QE51N


Descrio da funo, transaces relacionadas Consequncias

manualmente a introduo de resultadosSe o sistema falhar os utilizadores podem efectuar

Quadro 7 Representao de alguns dos processos analisados.

Nota: Os restantes processos no se encontram aqui representados. (Apenas em ficheiro Excel)


Pgina 26 de 72

ID d

a Fa

lha

Classe do Risco

Nvel do Risco

Impa

cto

GxP

Prob

abili

dade

de

Falh

a

Ris

k Sc

ore

Det

ecta

bilid

ade

da F

alha

ndi

ce d

e R

isco

(RPN

)

Actividade de Validao 51 2 Baixo 3 1 3 1 3 Considerar revalidao 52 2 Baixo 3 1 3 1 3 Considerar revalidao 53 2 Baixo 3 1 3 1 3 Considerar revalidao 54 2 Baixo 3 1 3 1 3 Considerar revalidao 55 2 Baixo 3 1 3 1 3 Considerar revalidao 56 2 Baixo 3 1 3 1 3 Considerar revalidao 57 2 Baixo 3 1 3 1 3 Considerar revalidao 58 3 Baixo 1 2 2 2 4 Nenhuma aco requerida 59 2 Baixo 3 1 3 1 3 Considerar revalidao 60 3 Baixo 1 2 2 2 4 Nenhuma aco requerida 61 3 Baixo 1 2 2 2 4 Nenhuma aco requerida 62 2 Baixo 3 1 3 1 3 Considerar revalidao 63 2 Baixo 3 1 3 1 3 Considerar revalidao 64 2 Baixo 3 1 3 1 3 Considerar revalidao 65 3 Baixo 1 2 2 2 4 Nenhuma aco requerida 66 2 Baixo 3 1 3 1 3 Considerar revalidao 67 3 Baixo 1 2 2 2 4 Nenhuma aco requerida 68 2 Baixo 3 1 3 1 3 Considerar revalidao 69 3 Baixo 1 2 2 2 4 Nenhuma aco requerida 70 2 Baixo 3 1 3 1 3 Considerar revalidao 71 3 Alto 2 2 4 3 12 Validao requerida 72 1 Alto 3 2 6 3 18 Validao requerida 73 1 Alto 3 2 6 3 18 Validao requerida 74 1 Alto 3 2 6 3 18 Validao requerida 75 1 Alto 3 2 6 3 18 Validao requerida 76 1 Alto 3 2 6 3 18 Validao requerida 77 2 Alto 2 2 4 3 12 Validao requerida 78 3 Mdio 1 2 2 3 6 Nenhuma aco requerida 79 3 Mdio 1 2 2 3 6 Nenhuma aco requerida 80 3 Mdio 1 2 2 3 6 Nenhuma aco requerida 81 3 Mdio 1 2 2 3 6 Nenhuma aco requerida 82 3 Mdio 1 2 2 3 6 Nenhuma aco requerida 83 2 Alto 2 2 4 3 12 Validao requerida 84 3 Mdio 1 2 2 3 6 Nenhuma aco requerida 85 1 Alto 3 2 6 3 18 Validao requerida 86 1 Alto 3 2 6 3 18 Validao requerida 87 1 Alto 3 3 9 3 27 Validao requerida 88 1 Alto 3 2 6 3 18 Validao requerida 89 2 Baixo 3 1 3 1 3 Considerar revalidao 90 3 Baixo 1 2 2 2 4 Nenhuma aco requerida


Pgina 27 de 72

91 3 Baixo 1 2 2 2 4 Nenhuma aco requerida 92 1 Alto 3 2 6 3 18 Validao requerida 93 3 Mdio 1 2 2 3 6 Nenhuma aco requerida 94 1 Alto 3 2 6 2 12 Validao requerida 95 1 Alto 3 3 9 2 18 Validao requerida 96 2 Alto 3 1 3 3 9 Validao requerida 97 1 Mdio 3 2 6 1 6 Validao requerida 98 1 Mdio 3 2 6 1 6 Validao requerida 99 3 Baixo 1 1 1 2 2 Nenhuma aco requerida 100 3 Baixo 1 2 2 1 2 Nenhuma aco requerida 101 3 Baixo 1 2 2 1 2 Nenhuma aco requerida 102 3 Baixo 1 2 2 1 2 Nenhuma aco requerida 103 1 Mdio 3 3 9 1 9 Validao requerida 104 1 Mdio 3 2 6 1 6 Validao requerida 105 1 Mdio 3 3 9 1 9 Validao requerida 106 1 Mdio 3 3 9 1 9 Validao requerida 107 3 Baixo 1 2 2 1 2 Nenhuma aco requerida 108 3 Baixo 1 2 2 1 2 Nenhuma aco requerida 109 1 Alto 3 3 9 2 18 Validao requerida 110 1 Alto 3 3 9 2 18 Validao requerida 111 3 Baixo 1 2 2 1 2 Nenhuma aco requerida 112 3 Baixo 1 2 2 1 2 Nenhuma aco requerida

Quadro 8 Sumrio dos processos de falha e actividades de validao a realizar

Nota: Os processos de 1 a 50 no se encontram neste quadro. Apenas em ficheiro Excel.

A seguir, a partir destes valores foram gerados grficos Pareto do risk score e dos valores

de RPN por cada ID de falha. (Figura 4)

Uma vez inseridos os valores para os trs factores, ambos os valores de risk score e de

RPN so calculados. O prximo passo rever o grfico Pareto de risk score para

determinar o valor crtico de risk score. Depois, gerado para o RPN um Pareto

semelhante, e determinado por esta medida um valor crtico. O ponto que se deve

manter em mente que este apenas um ponto de partida. Os valores crticos

simplesmente fornecem uma orientao para priorizar o planeamento da resposta aos

riscos.


Pgina 28 de 72

Valores do Risk Score II

0123456789

10

51 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81 83 85 87 89 91 93 95 97 99 101

103

105

107

109

111

ID da Falha

R

i

s

k

S

c

o

r

e

Valores de ndice de Risco II (RPN)

0

5

10

15

20

25

30

51 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81 83 85 87 89 91 93 95 97 99 101

103

105

107

109

111

ID da Falha

n

d

i

c

e

d

e

R

i

s

c

o

(

R

P

N

)

Figura 4 Grficos Pareto do Risk Score (em cima) e RPN (em baixo) para os processos de 51 a 112

Nota: Os processos de 1 a 50 no se encontram representados nesta figura. (Apenas em ficheiro Excel)


Pgina 29 de 72

Aps serem conhecidos os valores crticos, tanto para o RPN como para o risk score, criado um

diagrama de disperso risk score versus RPNs. (Figura 5)

O objectivo desta etapa o de encontrar a interseco dos dois valores crticos para definir o

conjunto inicial de riscos que exigem que seja gerado desde incio um plano de resposta. Aos

eventos de risco que tm um risk score e um RPN acima dos valores crticos dada prioridade

para o planeamento da validao. Existem riscos que podem ter uma classificao de elevado risk

score, mas porque previsvel que o risco pode ser detectado suficientemente cedo, eles recebem

um valor baixo de deteco e consequentemente um baixo RPN.

Os processos de falha que tm risk score alto no tm necessariamente elevados RPNs. A

primeira revelao foi a de que os riscos crticos iniciais a serem abordados com base nas duas

medidas eram diferentes. Percebe-se que, abordando os riscos simplesmente com base apenas no

risk score, pode-se estar a abordar os riscos que poderiam ser facilmente detectados e tratados

muito mais tarde ou de uma maneira diferente, porm, pode-se no estar a abordar os riscos que

poderiam ser uma completa surpresa, dada a menor prioridade destes com base isoladamente no

risk score.

Risk Score vs RPN

2; 42; 4 3; 33; 33; 3

4; 8

2; 42; 42; 4 3; 33; 33; 33; 32; 4

6; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 18

3; 33; 33; 32; 4 3; 32; 2 3; 33; 3

6; 12

3; 33; 33; 32; 6

6; 18

3; 33; 33; 33; 33; 33; 33; 33; 32; 4 3; 32; 42; 4 3; 33; 33; 32; 4 3; 32; 4 3; 32; 4 3; 3

4; 12

6; 186; 186; 186; 186; 18

4; 12

2; 62; 62; 62; 62; 6

4; 12

2; 6

6; 186; 18

9; 27

6; 18

3; 32; 42; 4

6; 18

2; 6

6; 12

9; 18

3; 96; 66; 6

1; 2 2; 22; 22; 2

9; 96; 6

9; 99; 9

2; 22; 2

9; 189; 18

2; 22; 20

5

10

15

20

25

30

0 2 4 6 8 10

Risk Score

RPN

Figura 5 Risk Score versus RPN dos processos de falha


Pgina 30 de 72

Na sequncia do cruzamento dos valores de risk score com os valores de RPN obtm-se um

grfico (Figura 6) que ilustra claramente a relevncia da validao de alguns processos

relativamente a outros. Conclui-se da anlise, que h processos que podem dar origem a falhas

crticas, e que portanto exigem uma resposta antecipada no seu planeamento, sendo estes os

processos cujo risk score e RPN correspondem aos valores que se mostram na parte superior

direita, dentro do quadrado.

Figura 6 Risk Score versus RPN dos processos de falha e destaque daqueles cuja validao prioritria

Risk Score vs RPN

2; 42; 4 3; 33; 33; 3

4; 8

2; 42; 42; 4 3; 33; 33; 33; 32; 4

6; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 186; 18

3; 33; 33; 32; 4 3; 32; 2 3; 33; 3

6; 12

3; 33; 33; 32; 6

6; 18

3; 33; 33; 33; 33; 33; 33; 33; 32; 4 3; 32; 42; 4 3; 33; 33; 32; 4 3; 32; 4 3; 32; 4 3; 3

4; 12

6; 186; 186; 186; 186; 18

4; 12

2; 62; 62; 62; 62; 6

4; 12

2; 6

6; 186; 18

9; 27

6; 18

3; 32; 42; 4

6; 18

2; 6

6; 12

9; 18

3; 96; 66; 6

1; 2 2; 22; 22; 2

9; 96; 6

9; 99; 9

2; 22; 2

9; 189; 189; 18

2; 22; 20

5

10

15

20

25

30

0 2 4 6 8 10

Risk Score

RPN


Pgina 31 de 72

3.6 Resumo

Aces altamente prioritrias

As funcionalidades SAP R/3 implementadas em 2006 (mdulos WM e PM) no foram validadas

de forma documentada. As correspondentes funcionalidades GxP identificadas na presente

avaliao de riscos devem ser validadas para garantir o cumprimento GxP. No que diz respeito

gesto dos sistemas de IT, o controlo de acesso dos utilizadores no foi validado de forma

documentada. O processo de backup foi validado, mas no o restauro dos dados a partir dos

backups. Estas operaes no SAP R/3 devem ser validadas para garantir o cumprimento GxP. As

melhorias de hardware e actualizaes de software realizadas em 2006 no foram apoiadas num

controlo de alteraes. Devem ainda ser realizados testes na Qualificao de Instalao (QI) para

actualizar a documentao de instalao do sistema.

Aces pouco prioritrias

As funcionalidades GxP relevantes implementadas em 2002 foram identificadas e validadas de

forma documentada, o seu nvel de risco considerado baixo. No entanto, nenhum controlo de

alteraes tem sido relatado durante todo este tempo, mesmo quando o sistema foi melhorado e

novos mdulos foram implementados. Deve ser considerado para os mdulos MM, PP, QM e SD

um teste de revalidao QP, para garantir que o dispositivo das principais funcionalidades GxP

est em conformidade com a documentao existente.

Comentrios adicionais

Uma vez que esta anlise de riscos est centrada nas questes de conformidade GxP, as

funcionalidades avaliadas como no-relevantes a nvel GxP, no necessitam de ser validadas.


Pgina 32 de 72

4. Qualificao Consiste de quatro actividades sequenciais, conforme ilustrado na Figura 9: Qualificao de

Desenho (QD), Qualificao de Instalao (QI), Qualificao Operacional (QO) e Qualificao

de Performance (QP). As Qualificaes so responsabilidade da empresa farmacutica, embora

os fornecedores tenham um maior envolvimento na fase (QD). A QI, QO, e QP devem ser

aplicadas aos sistemas informticos, como indicado pelos principais regulamentos.

A relao entre as qualificaes e especificaes do sistema indicada na Figura 8. A

Qualificao de Desenho garante que os requisitos para a configurao do sistema informtico

esto completos; a QI verifica a instalao, configurao, e calibrao de equipamentos entregues

ao Desenho de Software e Hardware; a QO verifica a capacidade operacional das especificaes

do sistema; e a QP verifica o funcionamento robusto e confivel do sistema informtico.

Deve ser preparado um relatrio de testes para concluir cada actividade de qualificao (QI, QO e

QP), resumindo os resultados dos testes. Qualquer falha nos testes, ou concesses para aceitar o

software apesar dos testes sobre ele terem falhado devem ser discutidas. Nem todos os testes tm

de ser aprovados, sem reservas, desde que todas as autorizaes para prosseguir sejam

justificadas nos relatrios e as aces correctivas para resolver quaisquer problemas sejam

iniciadas, pode permitir-se que a prxima actividade de qualificao comece. Cada relatrio ir

terminar tipicamente com uma declarao autorizando a progresso para a prxima actividade de

qualificao.

4.1 Qualificao e Especificaes de Desenho

A qualificao de desenho (QD) define as especificaes funcionais e operacionais do sistema e

as decises conscientes detalhadas na seleco do fornecedor. A QD deve assegurar que os

sistemas informticos tm todas as funes necessrias e os critrios de desempenho que lhes

permita ser implementados com sucesso para a sua aplicao e para satisfazer os requisitos

empresariais. Erros na QD podem ter um impacto empresarial e tcnico tremendo, por

conseguinte, devem ser investidos uma quantidade suficiente de tempo e recursos na fase QD.

Por exemplo, a definio de especificaes funcionais erradas pode aumentar substancialmente a

carga de trabalho dos testes da QO, adicionar funes no existentes numa fase posterior, ser


Pgina 33 de 72

muito mais caro do que inclu-las nas primeiras especificaes, e seleccionar um fornecedor com

capacidade de assistncia insuficiente pode diminuir o estado de actualizao dos instrumentos

com um impacto negativo no negcio.

4.1.1 Especificao dos Requisitos do Utilizador (ERU)

O objectivo do negcio a ser cumprido pelo sistema informtico expresso numa ERU, que deve

proporcionar uma base slida para o projecto. A ERU no deve mergulhar no detalhe do desenho,

que deve ser adiado para a especificao funcional. Isto pode ser difcil quando se trate de

sistemas personalizados, como a concepo muitas vezes antecipada quando se desenvolve a

ERU.

As especificaes exigidas pelos utilizadores descrevem os requisitos de funcionalidade dos

utilizadores, o nvel de interaco do utilizador, interfaces com outros sistemas e equipamentos, o

ambiente operacional, e quaisquer limitaes. Devem ser includas as exigncias regulamentares

especficas, por exemplo, as exigncias relativas utilizao de registos electrnicos e assinaturas

electrnicas. A documentao que compe a ERU dever:

Permitir que o fabricante compreenda as necessidades do utilizador

Definir claramente qualquer constrangimento de desenho

Fornecer detalhes suficientes para facilitar os testes de aceitao

Apoiar a explorao e manuteno do sistema informtico

Antecipar e facilitar a retirada de servio do sistema informtico

4.1.2 Especificao Funcional

Descreve a funcionalidade do sistema escolhido ou desenvolvido e como ir cumprir os

requisitos dos utilizadores. Este documento a especificao contra a qual a operacionalidade do

sistema ser testada e mantida. Pode ser referenciado o hardware e software especfico do

produto. A especificao funcional no deve duplicar as informaes disponveis na

documentao standard previamente publicada pelo fornecedor se o software/hardware comercial

est em uso.


Pgina 34 de 72

4.1.3 Avaliao do Fornecedor

Esta exigncia normalmente satisfeita por meio da auditoria realizada pela empresa

farmacutica. A auditoria examina os atributos de garantia da qualidade dos processos do

fornecedor, a maturidade, bem como a adequao do seu servio ou equipamento sugerido para

uso no projecto de desenvolvimento do produto. O fornecedor neste contexto pode ser entendido

como o vendedor de equipamentos, fornecedor de servios, ou a empresa farmacutica se esta

decide desenvolver software in-house.

Factores de risco do fornecedor incluem:

Tamanho da empresa

Histria da empresa

Perspectivas futuras

Representao na indstria alvo, por exemplo, Farmacutica

Experincia

Factores de risco do produto incluem:

Complexidade do Sistema

Nmero de sistemas a ser comprado

Maturidade do sistema

Nvel de rede

Influncia sobre outros sistemas, por exemplo, atravs de redes

Impacto do sistema na qualidade dos medicamentos

Impacto do sistema na continuidade empresarial

Integrao do sistema com outras interfaces

Nvel de customizao


Pgina 35 de 72

Os factores de risco so estimados para o fornecedor e sistema informtico (produto), como no

Quadro 10.

Quadro 9 Risco do Fornecedor versus Risco do Produto

A rea mais crtica a vermelha com elevado risco de produto e de fornecedor. Este cenrio iria

requerer uma auditoria ao fornecedor quer atravs da empresa utilizadora quer atravs de uma

terceira empresa confivel. Por outro lado as reas verdes podero ser tratadas por um documento

sucinto descrevendo quem o fornecedor e o porqu da sua escolha.

Na rea amarela os fornecedores poderiam ser avaliados atravs de uma auditoria, suportada por

boas referncias internas ou externas. Os resultados das auditorias ao fornecedor devem ser

documentadas na sequncia de um esquema de ranking padronizado.

Quando esto disponveis sistemas comerciais standard as Especificaes dos Requisitos do

Sistema (ERS) so enviadas para um ou mais fornecedores. Estes por sua vez respondem a cada

exigncia com um conjunto de especificaes funcionais de um sistema que mais adequado

para as necessidades do utilizador. Os utilizadores comparam as respostas do fornecedor com as

suas prprias necessidades. Se nenhum dos fornecedores cumpre todos os requisitos dos

utilizadores, os requisitos podem ser ajustados para uma melhor adequao ou criado software

adicional para atender s necessidades dos utilizadores seguindo o ciclo de desenvolvimento. O

fornecedor que melhor atenda aos requisitos tcnicos e de negcio do utilizador seleccionado e

qualificado.

A validao de software e sistemas informticos abrange todo o ciclo de vida dos produtos, que

inclui a validao durante a concepo e desenvolvimento. Quando o software e sistemas

informticos so comprados a fornecedores, o utilizador ainda responsvel pela validao.

O objectivo de qualificao do fornecedor obter a garantia de que o desenvolvimento de

produtos e prticas de fabrico do fornecedor satisfazem as exigncias de qualidade da empresa

utilizadora. Para o desenvolvimento de software isto normalmente significa que o software

Ris

co d

o Fo

rnec

edor

Baixo Mdio Alto Alto Mdio Baixo Risco do Produto


Pgina 36 de 72

desenvolvido e validado seguindo procedimentos documentados. No presente caso este processo

j tinha sido realizado em 2002, quando a primeira verso do software SAP foi adquirida.

Portanto, e uma vez que foi feita uma actualizao e upgrade do sistema, esta fase de qualificao

no necessria.

4.2 Qualificao de Instalao

A qualificao de Instalao estabelece que o sistema informtico recebido como projectado e

especificado, que instalado correctamente no ambiente seleccionado, e que este ambiente

adequado para o funcionamento e utilizao dos equipamentos. A QI fornece verificao

documentada de que um sistema informtico instalado de acordo com especificaes escritas e

previamente aprovadas.

A integrao do sistema informtico (hardware, software e instrumentao) deve ser confirmada

na preparao para a posterior actividade de QO. Alguns profissionais referem-se a isso como os

testes estticos dos atributos do sistema informtico. QI portanto a verificao documentada de

que todos os principais aspectos de instalao do hardware e software aderem a cdigos

adequados e a intenes de concepo aprovadas e que as recomendaes do fabricante foram

devidamente consideradas.

A Instalao e Qualificao de Instalao (QI) de sistemas maiores normalmente realizada por

um representante do fornecedor. Os representantes do fornecedor e um representante da empresa

utilizadora devem assinar os documentos de QI.

Documentos da Qualificao de Instalao (QI)

Foi gerado um protocolo de QI (em Anexo), aprovado e executado para fornecer provas

documentais de que o equipamento foi instalado de acordo com requisitos especficos de

concepo. E tambm um relatrio final resumindo os resultados, as deficincias observadas e as

aces correctivas que tm de ser abordadas. Este relatrio no divulgado por razes de

confidencialidade.


Pgina 37 de 72

4.3 Qualificao Operacional

A Qualificao Operacional (QO) prov verificao documental de que um sistema informtico

funciona de acordo com especificaes escritas e previamente aprovadas ao longo de todas as

suas gamas de funcionamento no ambiente seleccionado. A QO s deve comear aps a

concluso bem sucedida da QI. Em suma, inclui os testes de utilizador, para os quais necessrio

demonstrar que o sistema informtico funciona em conformidade com as Especificaes

Funcionais de (Desenho), estes testes individuais devem fazer referncia adequada s

Especificaes Funcionais. Os testes devem ser concebidos de modo a demonstrar que as

operaes iro funcionar como especificado em condies normais de funcionamento e, se for

caso disso, sob condies de esforo realistas.

Os sistemas informticos mais simples podem combinar as etapas de validao de QI e QO numa

nica actividade e document-lo de acordo. Quanto a sistemas informticos mais complexos,

podem ser divididos em subsistemas e submetidos a distintas QO. Os testes devem ento ser

complementados por uma QO colectiva demonstrando que a plena integrao do sistema

funciona como se pretende.

Documentos da Qualificao Operacional (QO)

QO a verificao documentada de que os equipamentos relacionados com o sistema ou

subsistema cumprem inteiramente com os limites operacionais especificados anteriormente.

Portanto, foi produzido um protocolo de QO (em Anexo), aprovado e executado parcialmente

para fornecer provas documentais de que o equipamento opera de acordo com os requisitos

funcionais especficos. O relatrio final que resume os resultados desta etapa no foi produzido,

uma vez que esta fase no foi completada. O relatrio sntese de QO ser emitido aps a

concluso das actividades de QO, e todas as deficincias observadas e as aces correctivas sero

abordadas nesse relatrio.

Os critrios dos testes realizados nesta fase so:

Impacto sobre a qualidade dos produtos

Impacto sobre a continuidade das actividades

Complexidade do sistema


Pgina 38 de 72

Informao do vendedor sobre o tipo de testes e ambiente de teste

Nvel de customizao

O factor de risco de um sistema deve ser avaliado com base nos factores de risco acima. A

extenso dos testes definida para cada nvel de risco na seco Avaliao de Riscos referida

anteriormente ou na seco de "risco" do plano mestre de validao. Um exemplo mostrado no

quadro abaixo. O nvel de personalizao expresso atravs das Categorias 3, 4 ou 5 das GAMP.

A categoria trs um software standard sem personalizao e sem ajustes de configurao. A

categoria 4 um sistema configurvel e a categoria 5 corresponde a um sistema totalmente

customizado. A extenso dos testes aumenta a partir do canto inferior esquerdo (baixo risco,

sistema standard) para o canto superior direito (de alto risco, personalizao completa), ilustrado

no Quadro 11.

Sistema GAMP 3 GAMP 4 GAMP 5

Alto risco

Teste de funes crticas. Link de testes de requisitos.

Teste crtico Funes normalizadas. Teste a todas as funes padro Link de testes de requisitos

Teste crtico a funes normalizadas. Teste a todas as funes padro Link de testes de requisitos.

Mdio risco

Teste de funes crticas.

Teste de todos os dados crticos da norma padro. Link de testes de requisitos.

Teste crtico a funes normalizadas. Teste a todas as funes padro Link de testes de requisitos.

Baixo risco

No necessita testes Teste padro crtico

Teste padro crtico

Quadro 10 Categorias GAMP versus Nvel de Risco

O bom funcionamento do backup e recuperao e as funes de segurana como o controlo de

acessos aos sistemas informticos e aos dados tambm foram testadas, devem ainda ser

realizados testes completos de QO, em intervalos regulares, por exemplo, para sistemas de dados

cromatogrficos, uma vez por ano e aps actualizaes importantes do sistema. Os testes parciais

de QO devero ser realizados aps actualizaes menores do sistema, devendo ser quantitativos.

Isto significa que os inspectores no s esperam um protocolo de testes com itens de teste e


Pgina 39 de 72

informao de que passou/falhou, mas tambm os resultados esperados, os critrios de aceitao

e os resultados reais.

4.4 Qualificao de Performance

Refere-se verificao de que um sistema informtico apropriado para a sua finalidade.

Significa muitas vezes projectar testes que esto directamente ligados ao fabrico de produtos

farmacuticos. A QP prov, portanto, verificao documentada de que um sistema informtico

capaz de executar e supervisionar as actividades necessrias para efectuar o controlo dos

processos, de acordo com as especificaes escritas e previamente aprovadas, enquanto opera no

seu ambiente produtivo especificado. Trata-se portanto do processo de demonstrar que um

sistema tem um desempenho consistente, de acordo com a especificao apropriada para o seu

uso habitual.

A QP s deve comear aps a concluso com xito da fase QO. Compreende a performance do

produto e/ou qualificao de performance do processo. Nesta fase, a empresa farmacutica tem

de demonstrar que a instalao no local do sistema informtico foi concluda e est em

funcionamento, em conformidade com os intentos da ERU. Por vezes a QP tambm referida

como a parte do processo de validao, onde o sistema informtico suporta um processo de

produo. A condio fundamental na QP que as alteraes podem ser feitas para o sistema

informtico durante os testes. Se a necessidade de mudana surge como um resultado de testes

falhados, a QP deve ser repetida na sua totalidade. O princpio subjacente que a alterao pode

ter perturbado a estabilidade do sistema e a reprodutibilidade.

Na prtica, a QP pode significar testar o sistema com todas as aplicaes. Para um sistema

informtico analtico isso pode significar, por exemplo, executar os testes de aptido do sistema,

onde as caractersticas crticas de desempenho do sistema so medidas e comparadas com limites

predefinidos e documentados.

Documentos da Qualificao de Performance (QP)

QP a verificao documentada de que o processo e/ou o sistema relacionado com o processo

global actua como pretendido ao longo de todas as gamas de funcionamento previsveis.


Pgina 40 de 72

Aquando da finalizao da QO e uma vez emitido o respectivo relatrio desta fase, ser ento

gerado um protocolo QP. Que ser executado e aprovado para fornecer provas documentais de

que o equipamento satisfaz os requisitos especficos do utilizador. Um relatrio final deve ser

produzido, resumindo os resultados, quaisquer deficincias observadas e as aces correctivas.

5. Relatrio de Validao O relatrio de Validao elaborado em resposta ao Plano Mestre de Validao. Pretende

fornecer gesto uma reviso do sucesso do exerccio de validao e quaisquer concesses feitas

durante a mesma. O objectivo do relatrio o de procurar a sua aprovao da concluso e

aceitao da validao conduzida. Os Relatrios de Validao tambm podem documentar

validaes falhadas e instruir modificaes de desenho ou mais testes.

Sempre que haja desvios do Plano de Validao, ou incidentes no resolvidos, devem ser

documentados e justificados. Se houver questes crticas que continuam por resolver, o sistema

informtico no pode ser considerado vlido ou apto para a finalidade que se prope.

O Relatrio de Validao de um sistema no deve ser aprovado at que todos os documentos

relevantes definidos no seu Plano de Validao tenham sido aprovados. A aprovao do Relatrio

de Validao marca a concluso do processo de validao. O Relatrio de validao deve,

portanto, incluir uma declarao clara confirmando ou no que todos os sistemas informticos

esto validados e so adequados sua finalidade.

Quando o projecto de validao estiver concludo o Supervisor do Sistema deve gerar um

relatrio sumrio da validao. O relatrio deve espelhar e documentar os resultados a que o

projecto de validao se propunha. Estes documentos devem ser revistos, aprovados e assinados

pela GQ, bem como pelo supervisor do sistema.

Este Relatrio de Validao deve tambm identificar todos e cada problema no resolvido por

uma aco correctiva durante o projecto, e deve fornecer detalhes da varincia, por que ela

ocorreu, e como foi resolvida. Ele tambm fornece uma justificao escrita para as situaes em

que uma aco correctiva no possvel ou adequada. Do mesmo modo, os fornecedores podem

facultar um relatrio resumindo os seus prprios trabalhos de validao, o que tambm pode ser

referenciado por este documento. O Relatrio de Validao autoriza a utilizao do sistema

informtico e no deve ser emitido at que todos os requisitos de operao e manuteno,


Pgina 41 de 72

incluindo os documentos de gesto, calibrao, manuteno, controlo de alteraes, segurana,

etc, tenham sido postos em prtica.

6. Plano Mestre de Validao (PMV) Todas as actividades de validao devem ser descritas num Plano Mestre de Validao (PMV)

que dever fornecer um quadro exaustivo e coerente para a validao. O plano mestre de

validao exigido oficialmente pelo Anexo 15 do EU GMPv. Os regulamentos e orientaes da

FDA no ordenam a elaborao de um plano mestre de validao, porm, os inspectores querem

saber qual a abordagem da empresa em relao validao. O plano mestre de validao uma

ferramenta ideal para comunicar esta abordagem, tanto a nvel interno como aos inspectores. Ele

tambm garante a aplicao coerente de prticas de validao e torna as actividades de validao

muito mais eficientes. No caso de haver alguma dvida quanto razo pela qual as coisas tm

sido ou no foram feitas, o plano mestre de validao deve dar a resposta.

Em resumo, um plano escrito que expe como se levar a cabo a validao, incluindo os

parmetros dos testes, as caractersticas do sistema, o equipamento de produo e os pontos de

deciso sobre os quais os resultados so aceitveis para os testes. Consiste num documento de

sntese que explica o mtodo, os meios e a planificao colocada em marcha para validar a

unidade. Actua como sumrio ou resumo da validao e por isso contm referncias a outros

documentos. Este documento foi criado na empresa, e apresentada aqui uma parte.

6.1. Sobre este documento

6.1.1. Finalidade

Este plano de validao descreve os resultados de validao que sero fornecidos para as

actividades que recaem no mbito da validao. Ele descreve como ser feita a validao e define

a abordagem para fornecer elementos de prova documental.

Pretende-se com este plano fornecer provas documentais de que o sistema ERP MySAP 2005,

ECC verso 6.0 e infra-estrutura associada tem atributos de boa qualidade, opera com exactido e


Pgina 42 de 72

fiabilidade em conformidade com as suas especificaes pr-determinadas, e continuar a faz-lo

no futuro.

O objectivo deste plano de validao descrever os resultados e responsabilidades dessa

validao, que sero fornecidos para as actividades que recaem no mbito da validao. Ele

descreve como o ERP MySAP ser validado e define a abordagem para fornecer provas

documentais de que o MySAP ERP ir cumprir sempre as suas especificaes predeterminadas e

possuir os atributos de qualidade.

Este plano de validao foi produzido de acordo com a Avaliao de Riscos e de acordo tambm

com o anterior processo de validao para o MySAP ERP, verso 4.6C.

6.1.2. Audincia

A audincia do plano de validao sero os membros da equipa do projecto, que so responsveis

pela implementao e utilizao da aplicao em ambiente de teste e de produo.

6.1.3. mbito

Este plano abrange o processo de validao de todos os componentes do sistema ERP MySAP

que esto dentro do alcance de validao (ver seco 6.1.4 - Incluses, com os principais

componentes includos). O plano prev tambm uma viso geral do sistema, e define as

prestaes de validao necessrias para assegurar que o sistema foi instalado e mantido num

estado validado.

6.1.4. Incluses

Foram includas neste plano mestre de validao as plataformas de Teste e de Produo com os

seguintes componentes:

Software

o Sistemas Operativos Cliente e Servidor

o Oracle DataBase

o Mdulos SAP GxP (MM, SD, WM, PP-PI, QM)

o Desenvolvimentos in-house que afectam estes mdulos

Hardware

o Servidores de Teste e Produo

o PCs Clientes


Pgina 43 de 72

o Elementos de Rdio Frequncia (RF)

o Equipamentos de pesagem

o Principais componentes LAN

Documentos

o Procedimentos de gesto do sistema

o Controlos de Acesso e registos de segurana

o Processos de backup e restore

Pessoal

o Registos e Procedimentos de Formao

6.2. Viso Geral do Sistema

O sistema MySAP ERP um software ERP standard configurvel, disponvel no mercado e

usado para gerir e lidar com a maior parte das funes de uma empresa, por exemplo, aquisio,

armazenamento, distribuio e vendas, produo e qualidade. As Finanas, Recursos Humanos e

Imobilizado so outras funes no relevantes ao nvel GxP ger

Duarte_Marques_2007100447_2009_rf

Documents

Transcript of Duarte_Marques_2007100447_2009_rf