Duarte Marques 2007100447 2009 RF PDF

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
Validao de Sistemas Informticos na Indstria Farmacutica
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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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.
Hardware
Software
Figura 1 Sistema Informtico
Pgina 10 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
Pacote de software standard. Sem customizao.
GAMP 3
Exemplo: MS Word (sem scripts VBA).
Pacote de software standard. Customizao ou configurao.
Exemplos: LIMS, Folhas de clculo Excel onde as frmulas e/ou dados
GAMP 4
de input esto ligados a clulas especficas. Sistemas de dados ligados
em rede. ERP SAP customizado na parte dos equipamentos de pesagem.
Pacote de software customizado. Todo ou parte do pacote completo de
GAMP 5 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 11 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 12 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 13 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 14 de 72
Identificao do
Processo
Documentar na Justificao para o status

Risco para no GxP relevante
No matriz da AR
GxP/Negcio
Sim
Identificar os
cenrios de Risco
Avaliar a
probabilidade da
condio de falha
Avaliar a
Severidade de
Impacto
Avaliar o Nvel de
Risco
Descrio da funo e
Avaliar a Documentar o relevncia GxP
probabilidade de risco na matriz de probabilidade de risco
detectar a AR probabilidade de deteco
condio de falha calculo do nvel de risco
Documentar na Sumrio da resposta

Determinar as
matriz de AR
aces a tomar
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 15 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 16 de 72
Mdulos SAP Implementao Documentos de validao existentes

FI, CO, MM, Ano 2002: - Os requisitos dos utilizadores (ERU)
PP-PI, SD, QM - SAP R/3 4.6c - Business Blueprint (BBP)
- Oracle 8i - Manuais do Utilizador
- Interface de escalas de - Testes funcionais para operaes GMP
Produo relevantes
WM, PM Ano 2006: - Business BluePrint (BBP)
Modificao dos - Upgrade para MySAP ERP - Manuais do utilizador
outros mdulos de 2005
modo a integrar - Upgrade para Oracle 10i
WM e PM - Interface terminais RF
- Melhoramento de Hardware
e rede
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 17 de 72
Relevncia
Mdulo Principais temas GxP
GxP
Material Management (MM) Rastreabilidade de fornecedores e de compras,
Sim
matrias-primas e dados mestre dos produtos
Warehouse Management (WM) Fluxo de materiais do armazm, materiais atribudos
Sim
ao picking e ordens de encomenda, rotulagem
Sales Distribution (SD) Rastreabilidade dos dados dos clientes de produtos
Sim
farmacuticos entregues
Production Planning (PP-PI) Controlo e rastreabilidade da execuo das ordens de
Sim
produo
Quality Management (QM) Controlo de qualidade, IPC (In Process Control) Sim
Plant Maintenance (PM) Planeamento e controlo da manuteno preventiva e
Sim
outras operaes crticas (por exemplo, calibrao)
Financial and Controlling Financeira e contabilidade de custos
No
(FI, CO)
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 18 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
Mdio: a funcionalidade avaliada gere indirectamente os dados relevantes ou
2
operaes GxP
Alto: a funcionalidade avaliada gere directamente dados relevantes ou operaes
3
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
Mdio: funcionalidades no validadas, implementado utilizando operaes do
2
SAP R/3 standard
Alto: funcionalidades no validadas, implementadas usando transaces/tabelas
3
parametrizadas
Pgina 19 de 72
A tabela seguinte mostra como calculada a Classe de Risco:
Probabilidade
Classe de Risco
Baixo Mdio Alto
Classe Classe Classe
Alto de de de
Risco 2 Risco 1 Risco 1
Impacto GxP

Mdio de de de
Baixo de de de
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
Mdio: funcionalidades no validadas, mas utilizadas desde a primeira
2
implementao do SAP R/3 (2002)
3 Baixo: funcionalidades no validadas, implementado mais recentemente
Pgina 20 de 72
A tabela a seguir mostra como calculado o nvel de risco:
Detectabilidade
Nvel de risco
Alto Mdio Baixo
Nvel Nvel Nvel
1
Mdio Alto Alto
Classe de Risco
Nvel Nvel Nvel

2
Baixo Mdio Alto
Nvel Nvel Nvel

3
Baixo Baixo 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 21 de 72
E a tabela a seguir mostra como so determinadas as actividades de validao a serem

realizadas:
Actividades Nvel de Risco

de validao Baixo Mdio Alto
Considerar Validao Validao
Alto revalidao requerida requerida
Impacto GxP
Nenhuma Considerar Validao

Mdio aco revalidao requerida
requerida
Nenhuma Nenhuma Nenhuma
Baixo aco aco aco
requerida requerida 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 22 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 23 de 72
N Operaes SAP ANLISE FUNCIONAL ANLISE DE RISCO Actividades

Bluepharma Dados ou Operaes Impacto Probabilidade Probabilidade de Nvel de ndice de Validao
Descrio da funo, transaces relacionadas
manipulados GxP de falha deteco da falha Risco de Risco
Mdulo Finances (FI)
1 FI Mdulo no relevante ao nvel GxP Contabiblidade Baixo 1 Mdio, 2 Mdio, 2 Baixo 4 Nenhuma aco
Financeira funcionalidade funcionalidade requerida
SAP standard operacional desde
2002
Mdulo Controlling (CO)
2 CO Mdulo no relevante ao nvel GxP Contabiblidade de Baixo 1 Mdio, 2 Mdio, 2 Baixo 4 Nenhuma aco
Custos funcionalidade funcionalidade requerida
2002
Mdulo Materials Management (MM)
3 MM-Dados XK01 Dados Mestre de Fornecedor Rastreabilidade de Alto 3 Baixo, 1 Alto, 1 Baixo 3 Considerar
Mestre Fornecedor funcionalidade funcionalidade revalidao
Fornecedor validada validada teste QP
para MM
4 MM-Fornecedor ME61 Avaliao de Fornecedor Homologao Alto 3 Baixo, 1 Alto, 1 Baixo 3 Considerar
Fornecedor funcionalidade funcionalidade revalidao
validada validada teste QP
para MM

5 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 revalidao
dados ME41/ME43/ME9A Requisies de compra adquiridos validada validada teste QP
ME21N/ME9F Ordens de compra para MM
ME21N/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 revalidao
encomenda ME56 Atribuir fontes req. de compra ordens de compra SAP standard operacional desde teste QP
ME54 Libertao de req. de compra 2002 para MM
ME21/ME25 Criar ordens de compra
ME28 Ordens de libertao de compras
ME18 Enviar informaes de compras
Relatrios
7 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 requerida
Libertao de pagamento de SAP standard operacional desde
facturas 2002
8 MM-Cotao MEQx Manter arranjo contingente Cotao de materiais Baixo 1 Mdio, 2 Mdio, 2 Baixo 4 Nenhuma aco
funcionalidade funcionalidade requerida
2002
9 MM-Contratos de ME3x Manter contratos de compra Gesto Baixo 1 Mdio, 2 Mdio, 2 Baixo 4 Nenhuma aco
Compra de contractos de funcionalidade funcionalidade requerida
compra SAP standard operacional desde
2002
Pgina 24 de 72

91 PM - Peas e Controlo dos tempos, centros de custo, facturamento ... Tarefas de Baixo 1 Mdio, 2 Mdio, 2 Baixo 4 Nenhuma aco
Materiais Para as actividades de manuteno, essas operaes no diferem do manuteno funcionalidade funcionalidade requerida
do 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 Validao
Relatrios e estatsticas utilizadas para controlar a manuteno e as controlo da funcionalidade funcionalidade requerida
ordens de calibrao executadas e pendentes a serem executadas manuteno SAP standard no validada
93 CONTROLO DE CUSTOS Controlo dos custos e Baixo 1 Mdio, 2 Baixo, 3 Mdio 6 Nenhuma aco
Relatrios e estatsticas utilizadas para controlar o tempo e os custos das dos recursos de funcionalidade funcionalidade requerida
tarefas de manuteno de equipamentos, manuteno SAP standard no validada
paragens programadas das instalaes...
Gesto de Sistemas IT
94 Controlo de Gesto do Sistema dos perfis de utilizador Controlo de acesso Alto 3 Mdio, 2 Mdio, 2 Alto 12 Teste QP
Acesso dos de dados GMP e funcionalidade funcionalidade requerido
Utilizadores operaes GMP SAP standard operacional desde
geridas a partir do 2002
SAP 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 QP
registado pelo sistema SAP R / 3 de informao GMP o restore das processo Back-up requerido para
armazenados cpias backup operacional desde cpias backup
no SAP R / 3 no est 2002 e restore
validado
96 Gesto de Administrao do sistema, no uma funcionalidade SAP R\3 Controlo de Alto 3 Baixo, 1 Baixo, 3 Alto 9 Teste QI
Configuraes Alteraes um controlo de nenhum controlo requerido
alteraes foi de alteraes
aprovado para foi reportado
a empresa para SAP R/3
N Processo/ ANLISE FUNCIONAL ANLISE DE RISCO Actividades de

Problema Impacto Probabilidade Probabilidade de Nvel de ndice Validao
Descrio da funo, transaces relacionadas Consequncias
GxP de falha deteco da falha Risco de Risco
Erweka
102 QM046 - Interface Se o sistema falhar os utilizadores podem efectuar A carga de trabalho e o Baixo 1 Mdio 2 Alto 1 Baixo 2 Nenhuma aco
com o Erweka manualmente a introduo de resultados tempo que os utilizadores requerida
atravs da transaco QE51N levam a fazer a introduo
de resultados manualmente
Falhas de Hardware
103 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 crticas
Falhas de Rede
104 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. requerida
pelos utilizadores Realizao manual de
todas as tarefas crticas
Quadro 7 Representao de alguns dos processos analisados.
Nota: Os restantes processos no se encontram aqui representados. (Apenas em ficheiro Excel)
Pgina 25 de 72
Detectabilidade da Falha
Probabilidade de Falha
ndice de Risco (RPN)

Impacto GxP
ID da Falha
Risk Score
Classe do Nvel do
Risco Risco Actividade de Validao
51 2 Baixo 3 1 3 1 3 Considerar revalidao
58 3 Baixo 1 2 2 2 4 Nenhuma aco requerida
71 3 Alto 2 2 4 3 12 Validao requerida
78 3 Mdio 1 2 2 3 6 Nenhuma aco requerida
Pgina 26 de 72

97 1 Mdio 3 2 6 1 6 Validao 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 27 de 72
Valores do Risk Score II
10
9
8
7
Risk Score 6
5
4
3
2
1
0
1
3
5
7
9
1
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
10
10
10
10
10
11
ID da Falha
Valores de ndice de Risco II (RPN)
30
25
ndice de Risco (RPN)
20
15
10
1
3
5
7
9
1
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
10
10
10
10
10
11
ID da Falha
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 28 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
30
9; 27
25
20
6; 18 9; 18
RPN
15
4; 12 6; 12
10 3; 9 9; 9
4; 8
5 2; 6 6; 6
2; 4 3; 3
1; 2 2; 2
0
0 2 4 6 8 10
Risk Score
Figura 5 Risk Score versus RPN dos processos de falha
Pgina 29 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.
Risk Score vs RPN
30
9; 27
25
20
6; 18 9; 18
RPN
15
4; 12 6; 12
10 3; 9 9; 9
4; 8
5 2; 6 6; 6
2; 4 3; 3
1; 2 2; 2
0
0 2 4 6 8 10
Risk Score
Figura 6 Risk Score versus RPN dos processos de falha e destaque daqueles cuja validao
prioritria
Pgina 30 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 31 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 32 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 33 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 34 de 72
Os factores de risco so estimados para o fornecedor e sistema informtico (produto), como no

Quadro 10.
Baixo Mdio Alto
Fornecedor
Risco do
Alto
Mdio
Baixo
Risco do Produto
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
Pgina 35 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 36 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 37 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

Teste crtico Funes
Teste de
normalizadas. Teste crtico a funes
funes
Alto Teste a todas as funes normalizadas.
crticas.
risco padro Teste a todas as funes padro
Link de testes
Link de testes de Link de testes de requisitos.
de requisitos.
requisitos
Teste de todos os dados
Teste de Teste crtico a funes
crticos da norma
Mdio funes normalizadas.
padro.
risco crticas. Teste a todas as funes padro
Link de testes de
Link de testes de requisitos.
requisitos.
Baixo
No necessita Teste padro crtico
risco Teste padro crtico
testes
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 38 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 39 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 40 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 41 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 42 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 geridas pelo sistema. Estes mdulos
no so includos no mbito desta validao.
O sistema possui uma interface com as balanas para pesar as matrias-primas atravs do mdulo
PP-PI. Esta uma interface standard fornecida pela SAP AG. So tambm utilizados dispositivos
de rdio frequncia para ler os rtulos de cdigo de barras anexados ao material de embalagem e
aos bulks de matrias-primas. A empresa SAP AG uma multinacional bem introduzida na
Indstria Farmacutica com muitas instalaes em todo o mundo e tem certificao ISO 9001 e
27001 para os seus produtos e servios.
6.2.1. Funcionalidades MySAP

Os principais mdulos do sistema ERP MySAP que esto em utilizao so:
QM Quality Management fornece instrues e os dados relativos medio e controlo de
qualidade. Esta funo fornece instrues para o utilizador indicando que itens deve analisar e
quais os atributos a inspeccionar, em etapas definidas do processo de fabrico. Os resultados so
registados e analisados no sistema.
MM - Material Management. O mdulo MM fornece suporte para as actividades do dia-a-dia
que impliquem o consumo de materiais. A funo do MRP (Material Requirements Planning) a
Pgina 43 de 72
monitorizao dos stocks no final de cada dia e gerar automaticamente propostas de compra para
serem enviadas ao Departamento de Compras. O mdulo oferece funes componentes para
Compras, Gesto de Inventrio, Gesto de Armazm e Verificao de Facturas.
SD Sales Distribution. O mdulo SD manipula a procura dos clientes por meio do
processamento das ordens de vendas e pela gerao da documentao associada ao facturamento.
Mantm informao sobre clientes e preos, e a integrao com os mdulos de gesto de
armazm para lidar com as funcionalidades de picking, embalagem e transporte para satisfazer a
procura dos clientes.
WM - Warehouse Management. O mdulo WM prov suporte automatizado, flexvel para
permitir o processamento dos movimentos de mercadorias e para manter um registo actual de
todos os materiais armazenados nas estruturas de armazenamento. Utilizando tcnicas avanadas
de picking, o WM optimiza o fluxo de materiais e a capacidade no armazm, armazenando
mercadorias nas localizaes mais favorveis para que elas estejam sempre disponveis quando
necessrio. O mdulo WM tem a capacidade de ter interfaces com aparelhos de leitura de cdigos
de barras, por exemplo dispositivos de rdio-frequncia de terminais manuais.
PP Production Planning. O Manufacturing Resource Planning (MRPII) toma como seu
ponto de partida um plano de aces a realizar, em termos de vendas, de encomendas e de
projectos. O sistema prov o planeamento e controlo de materiais at entrega dos produtos. Os
detalhes das ordens de encomenda dos clientes so transmitidos automaticamente para o Sistema
de Informao de Vendas e para a componente de anlise de rentabilidade. O sistema de
Planeamento de Operaes e Vendas selecciona as informaes necessrias a partir do Sistema de
Informao de Vendas e da componente de anlise de rentabilidade. O Plano de Operaes e
Vendas , em seguida, passado para a componente do Material Requirements Planning, que inicia
o MRPII - Cadeia de Planeamento que termina com as necessrias propostas de encomenda. Os
clculos do planeamento do MRPII so baseados na programao da capacidade de produo
finita.
PI Process Industries um mdulo de produo especializado adequado s exigncias da
indstria transformadora. Este mdulo oferece funes adaptadas ao processamento contnuo de
lotes e ao controlo da produo.
PM Plant Maintenance / Sistema de gesto do ciclo de vida de activos. O mdulo PM
apoia e controla a manuteno efectiva dos equipamentos e edifcios. atribudo um registo
Pgina 44 de 72
mestre a cada item a ser mantido e qualificado, e os sub-componentes podem ser organizados
numa estrutura complexa de dados que representa a componente do equipamento.
FI - Financial o mdulo de planeamento dos fluxos de valor numa organizao e, do registo
dos valores reais para posterior comparao com o plano. Fornece o processamento de contas a
receber, contas a pagar, contabilidade de bens e despesas.
CO - Controlling inclui o planeamento de valores tais como custos e receitas que sero
exibidos em documentos financeiros. O desempenho da empresa monitorizado e controlado em
relao a estes valores planeados. Isto inclui Contabilidade de Custos, Contabilidade de Ordem e
Projecto, Custeio de Produto, Anlise de Rentabilidade e Contabilidade de Lucros.
Durante a configurao do pacote SAP standard todos os requisitos que no foram satisfeitos pelo
pacote standard foram identificados e documentados separadamente em documentos dos
Requisitos do Sistema como melhorias funcionais e modificaes.
6.2. 2 Arquitectura do Sistema
6.2.2.1 mbito da Infra-estrutura

O mbito da infra-estrutura inclui todo o hardware, software e firmware que necessrio para
apoiar a implementao do MySAP. O mbito de aplicao inclui servidores, dispositivos de
leitura de cdigos de barras RF, softwares, impressoras de rede, impressoras de etiquetas.
Os desktops/laptops controlados que tm sido testados em termos de integrao, foram munidos
com aplicaes aprovadas, e incluem a configurao final do SAP R/3 7.10 GUI (ou posterior)
que funciona com o MySAP ERP 2005 verso ECC 6.0.
Para efeitos de desenvolvimento e testes, sero disponibilizados ambientes separados do sistema.
Pgina 45 de 72
6.2.2.2 Aspecto do Sistema

Haver um nico servidor de produo ERP MySAP, que gerido pelo IT e est localizado no
Data Center (Sala de Servidores) em So Martinho do Bispo (Coimbra, Portugal).
HEWLETT HEWLETT
PACKARD PACKARD
Figura 7 - Aspecto do Sistema ERP MySAP
O MySAP ERP constitudo por um ou mais clientes. Os clientes devem ser estabelecidos em
cada sistema, a fim de facilitar as actividades do projecto no Quadro 11.
GQ/Sistema de Teste Sistema Produtivo
Teste Funcional, Teste s Unidades e

Operao real
de Aceitao do utilizador
Teste do Sistema Qualificao de Performance
Quadro 11 - Utilizao de clientes na paisagem do sistema MySAP
6.2.2.3 Desenvolvimento da Segurana

A segurana no MySAP consiste em adoptar uma abordagem baseada na funo para definir a
segurana do utilizador final como definido na Norma de Acessos NG-21-005 (norma interna da
empresa revista durante esta validao). A sala de servidores provida de uma unidade
electrnica UPS, deteco de incndio e sistema de ar condicionado, est ainda protegida contra
acesso no autorizado que salvaguardado pela aplicao da norma NG-21-007, que foi tambm
actualizada.
6.3 mbito da Validao

A equipa de projecto responsvel pela instalao e validao do sistema, por testes de aceitao
dos utilizadores, qualificao das infra-estruturas relacionadas com o MySAP, e qualificao de
Pgina 46 de 72
performance. A definio das fases de teste deve ser definida nos planos de teste para QI, QO e
QP para o sistema SAP.
Aps a aprovao dos diferentes planos, os utilizadores formados devem executar os testes
seguindo as etapas consecutivas, e aplicando o mtodo descrito na seco 6.5 - Planeamento de
Testes.
Aps a execuo de um Plano de teste, o executante deve escrever um relatrio sumrio com os
principais resultados, e desvios se houver, encontrados durante a execuo dos testes. Um
representante da GQ deve rever e assinar o relatrio, juntamente com o executante.
A ltima fase o Relatrio de Validao com as concluses do projecto de validao e com a
aprovao do sistema para ser utilizado em ambiente de produo de uma forma controlada.
6.4 Processo de Validao e Resultados

A execuo deste projecto e a validao do ERP MySAP so regidas pelo presente Plano Mestre
de Validao.
6.4. 1 Processo
Sempre que qualquer alterao seja feita ao nvel do negcio, obrigao do IT e da Garantia de
Qualidade garantir que estes componentes adicionais aderem aos regulamentos adequados de
qualidade.
Nenhuma alterao dever ser feita para o sistema SAP sem que seja feita uma gesto de
alteraes, para que estas no comprometam o estatuto de validao do sistema.
6.4. 2 Resultados
Inserido neste ponto esto os produtos de validao que estejam dentro do mbito deste projecto e
cuja responsabilidade de concluso da equipa do projecto. Os planos de teste e Scripts de Teste
podem ser combinados num documento ou divididos em vrios, dependendo dos critrios do
autor. Isso deve ser feito sem diminuir a qualidade do processo de teste. Por exemplo, o Plano de
QI pode ser dividido em Plano QI e Scripts QI; a rastreabilidade entre ambos os documentos deve
ser mantida em cada caso.
Pgina 47 de 72
Fase do Resultado Descrio do Resultado Identificao do

Projecto Resultado
Requisitos Requisitos Especficos Uma lista detalhada dos requisitos recolhida a Especificao de
partir da fonte original da procura Requisitos
Fase de Risco Avaliao de Riscos Documento que avalia os potenciais riscos AR SAP
funcionais e operacionais
Fase de Plano de Validao Documenta como a equipa tem a inteno de BLUEP PMV (este
Planeamento fornecer a prova documental, em suporte da captulo)
validao
Qualificao da Plano de Teste A QI estabelecer que a instalao do sistema Plano de Testes QI
Instalao foi concluda em conformidade com as BLUEP-QI (em
especificaes do sistema e as instrues do anexo)
fabricante.
Scripts de Teste Scripts detalhados que descrevem como os -
requisitos originais sero comprovados
comparando com o sistema implementado.
Relatrio de Teste Resume as actividades de teste para reviso da -
gesto
Qualificao Plano de Teste A QO ir demonstrar que o sistema funciona Plano de Testes QO
Operacional correctamente dentro dos seus limites BLUEP-QO (em
operacionais previstos. Deve assegurar que os anexo)
testes so concebidos e realizados de modo que
seja adequado complexidade e criticidade do
sistema. A QO identifica quaisquer questes
pendentes ou riscos.
Scripts de Teste Scripts detalhados que descrevem como os -
requisitos originais sero comprovados contra o
sistema de teste.
Relatrio de Teste Resume as actividades de teste para a reviso da -
gesto
Qualificao de Plano de Teste A QP tem por base a garantia obtida durante as Plano de Testes QP -
Performance anteriores fases de QI e QO e projectada de tal BLUEP-QP (a ser
forma a garantir que o sistema desempenha de gerado)
uma forma integrada e compatvel, no ambiente
de produo.
Scripts de Teste Scripts detalhados que descrevem como os
requisitos originais sero comprovados em
comparao com o sistema de produo.
Relatrio de Testes Resume as actividades de teste para reviso da
gesto
Lanamento Matriz de Rastreabilidade Uma lista detalhada de todos os testes realizados
bem como das especificaes dos utilizadores
Relatrio de Validao Explica como o plano de validao foi cumprido Relatrio de Validao
e conclui que as actividades do projecto tal - BLUEP-RV (a ser
como exigido por este PMV foram realizadas de gerado)
uma forma controlada e que os resultados
exigidos foram devidamente produzidos,
inspeccionados e eram adequados finalidade.
O relatrio de validao indica a aceitao do
sistema informtico para uso de rotina.
Pgina 48 de 72
6.5 Planeamento de Testes

Ser gerado para cada fase (QI, QO e QP) um plano de testes de nvel programado, que descreve
uma viso geral do nvel de teste para cada componente. Os planos de teste sero, ento, gerados,
e iro descrever as fases de teste. Os nveis de teste em cada fase so de unidade e integrao e os
tipos de testes abrangidos sero detalhados no(s) plano(s) de teste. O mdulo WM instalado aps
o ltimo processo de validao e as novas funcionalidades PP-PI tm especial interesse, de modo
que, a QO dever incluir uma ampla gama de testes para verificar as especificaes aceites
definidas nos documentos Business Blueprint - WM Warehouse Management e PP-PI.
6.5. 1 Estratgia de Teste

Deve ser criado um plano de testes e os seus correspondentes grupos de Scripts de Teste para
verificar aspectos tcnicos e funcionais do sistema. Os resultados dos testes sero documentados
nos Scripts de Teste, documentando os resultados reais e comparando-os com os resultados
esperados, anexando ou referenciando qualquer documentao de suporte (evidncias ou provas).
Deve escrever-se uma seco de Sntese e Concluses, onde o executante avaliar se os
resultados do teste cumprem ou no com os resultados esperados e indicar que caminho o
processo de validao dever seguir. A GQ deve aprovar o resultado final de cada grupo de
testes.
Os critrios para aceitao dos resultados dos testes devem ser definidos no Plano de testes e/ou
nos Scripts de Teste. Qualquer desvio ou anomalia que um examinador possa encontrar ao correr
diferentes scripts de testes deve ser documentado de acordo com o ponto 6.5.5 Falhas de Testes
e Resoluo e com os Planos de Teste. Os testes funcionais sero executados no ambiente de
Teste para a Qualificao Operacional e no ambiente de Produo para a Qualificao de
Performance.
Os seguintes grupos de teste devem ser aprovados antes da sua execuo:
6.5. 2 Categorias de Teste

Qualificao da Instalao (QI) para as plataformas de Teste e Produo;
Qualificao Operacional (QO), no ambiente de Teste para o mdulo WM e interface com
dispositivos RF, mdulo PP-PI (transaces GMP), para funcionalidades de backup e restore e de
Controlo de Acesso;
Pgina 49 de 72
Qualificao de Performance (QP), em ambiente de Produo para mdulos GxP (MM, SD, PP-
PI, QM e WM);
Uma matriz de rastreabilidade ir verificar que as necessidades GxP dos utilizadores foram
testadas nas fases anteriores, de acordo com a Avaliao de Riscos.
6.5. 3 Execuo dos Testes

Os Scripts de Testes devem ser utilizados para verificar as diferentes especificaes do sistema e
sero definidos nos documentos do Plano de Testes ou nos apndices a estes planos, em grupos
homogneos de testes. Uma vez aprovados, os testes realizados sero documentados nos prprios
Scripts de Teste.
Em cada Script de Teste ser definido o objectivo principal, os critrios de aceitao e os pr-
requisitos para a execuo do teste.
Cada especificao (funcional ou tcnica) ser testada atravs de um teste. Cada teste (associado
a cada especificao) ser referenciado por uma nica identificao de teste e ser traduzido em
etapas de teste e resultados esperados. Uma ou vrias etapas podem representar cada
especificao.
Cada Script de teste deve ser referenciado com um nmero, e a execuo dos testes ser feita
numa cpia controlada do script de teste aprovado.
As evidncias devem ser anexadas a algumas etapas cruzando referncias entre as etapas dos
scripts e respectivas evidncias. As referncias das evidncias devem ser indexadas aos
resultados reais, juntamente com o veredicto do teste: Passou, Falhou ou No Aplicvel (N/A).
Cada passo deve ser executado (com as excepes das instrues a seguir ou comentrios) e os
resultados esperados devem ser atingidos para passar no teste. O executante deve assinar e
carimbar cada passo. Aps analisar os Scripts de Teste executados e suas evidncias, o
examinador deve assinar os grupos de teste e atribuir a sua deciso: aceite ou rejeitado.
Os testes que devem ser novamente realizados devem ser executados com o prximo nmero de
iterao e devem ser includos no Resumo e Concluses dos Scripts de teste e no Relatrio de
Qualificao.
6.5. 4 Matriz de Testes

Uma matriz de testes ser includa em cada um dos scripts de testes funcionais. Tais matrizes
devero incluir as identificaes dos requisitos, os resultados esperados e um espao para o
Pgina 50 de 72
executante gravar os resultados efectivos. Cada matriz ir tambm incluir uma coluna para
qualquer referncia a um Log de Falhas de Teste (desvios) e para a gravao do veredicto da
etapa: Passou, Falhou ou No Aplicvel (N/A). Isto ir identificar claramente as medidas a serem
tomadas para resolver qualquer falha durante os testes. Finalmente, o executante deve assinar e
carimbar cada passo.
6.5. 5 Falhas de Testes e Resoluo

Qualquer falha ocorrida durante os testes ser identificada num Formulrio e Log de Falhas de
Testes. Cada passo do script de teste ir proporcionar um espao para incluir uma referncia ao
Formulrio das Falhas de Teste. Este formulrio dever incluir as medidas necessrias para
corrigir o problema ou uma declarao em como a falha no afectar o lanamento para
produo.
As Falhas de Teste sero categorizadas como:
Maior Tudo o que no coincide com os resultados esperados ou uma

falha que impede a concluso do teste, e que vai tornar o
componente no operacional sem um maior desenvolvimento e
novo teste.
Menor Uma falha registada que no impede a realizao do teste, e
que no ir impedir que o produto seja libertado. Tambm
pode ser um incidente que ocorre fora do controlo do
executante/teste. Pode ser emitida uma declarao de
constrangimento
(NB: mltiplas falhas Menores podem tambm impedir a
libertao)
No Testado O teste no pde ser concludo, e este item no foi testado.
Todas as falhas de teste sero gravadas num Formulrio e Log de Falhas de Teste.
6.6 Aceitao
Os critrios de aceitao desta validao e evidncias da sua realizao sero apresentados
atravs da gerao e aprovao dos resultados da validao listados no ponto 6.4.2 - Resultados
deste plano.
Pgina 51 de 72
6.7 Gesto de Documentos

As assinaturas de aprovao sero obtidas em verses em papel de todos os documentos e estes
sero armazenados na rea de arquivo da GQ/IT. As verses electrnicas sero armazenadas pela
Gesto de IT numa pasta segura no servidor de arquivos BLUESERVER.
6.8 Formao
Todo o pessoal associado com a administrao e utilizao para produo do sistema deve ser
devidamente treinado e qualificado para desempenhar as suas responsabilidades.
O pessoal deve receber formao nas funes a que se exige acesso, e antes do supervisor do
sistema lhes dar acesso.
7. Abordagem de Ciclo de Vida

Os passos na validao do ciclo de vida no so necessariamente executados pela ordem indicada
anteriormente. Pelo contrrio, os passos so normalmente executados como um processo
iterativo, em que diferentes funes podem ser executadas simultaneamente. Se necessrio,
podem ser repetidas. Por exemplo, o Plano Mestre de Validao pode ser desenvolvido depois,
ou concomitantemente com, a Especificao dos Requisitos do Utilizador (ERU) e no antes,
como indicado. Da mesma forma, uma auditoria ao fornecedor geralmente envolve uma srie de
passos que podem no estar completos at bem perto do projecto de validao.
Algumas das etapas do ciclo de vida da validao no vo ser necessrias em alguns projectos de
validao. Por exemplo, a utilizao preferencial de fornecedores de hardware e software para
produtos ou servios elimina a necessidade de repetidas apreciaes e seleces de fornecedor.
H no entanto, etapas do ciclo de vida que no podem ser eliminadas no caso de se tratar de
sistemas informticos feitos por encomenda com um contrato definido com o fornecedor. O grau
de redundncia para o modelo de ciclo de vida utilizado para a validao de sistemas
informticos existentes foi especificado no Plano Mestre de Validao.
Neste caso, em que os sistemas tm sido utilizados h algum tempo, constatou-se ser suficiente
uma compilao e anlise da documentao e uma reviso dos dados histricos complementado
por uma srie de testes funcionais para demonstrar que o sistema executa a funo pretendida. As
evidncias de que o software estruturalmente slido e seguro podem ser prestadas por uma
Pgina 52 de 72
avaliao formal do desenvolvimento de software do fornecedor, pelos procedimentos de teste e

por uma anlise do histrico de dados relacionados com o sistema. Quando dados histricos,
relacionados com o sistema no estiverem disponveis, por qualquer motivo, podem ser
necessrios testes funcionais adicionais.
Devido complexidade e ao longo do perodo de tempo da validao informtica o processo

normalmente repartido em fases do ciclo de vida. Vrios modelos do ciclo de vida tm sido
descritos na literatura. Um modelo que frequentemente utilizado o Modelo-Vvi, como
mostrado na Figura 8.
Figura 8 - Modelo V - Ciclo de Vida
Este modelo compreende as Especificaes dos Requisitos dos Utilizadores (ERU), as

Especificaes Funcionais (EF), Especificaes de Desenho (ED), desenvolvimento e teste de
cdigo, Qualificao de Instalao (QI), Qualificao Operacional (QO) e Qualificao de
Performance (QP).
O Modelo-V, como descrito acima muito bom se o processo de validao tambm inclui o
desenvolvimento de software. No entanto, no aborda alguns passos muito importantes, como por
exemplo, a avaliao do fornecedor. Tambm parece muito complexo para uma plataforma
comercial sem desenvolvimento de cdigo personalizado. Neste caso, fases como a especificao
Pgina 53 de 72
de desenho ou desenvolvimento de cdigo e testes de cdigo no so necessrias. Para estes

sistemas recomendado o Modelo 4Qvii, com apenas quatro fases: Qualificao de Desenho
(QD), Qualificao de instalao (QI), Qualificao Operacional (QO) e Qualificao de
Performance (QP). O processo ilustrado na Figura 9.
Figura 9 - Modelo 4Q - Ciclo de Vida
QD:
Especificaes dos Requisitos do Utilizador
Especificaes Funcionais
Especificaes Operacionais
Especificaes do Fornecedor
QI:
Verificar sistema chegada
Verificar instalao de hardware e software
QO:
Teste de funes-chave operacionais
Teste de funes de segurana
Pgina 54 de 72
QP:
Teste de aplicaes especficas
Manuteno preventiva
Testes contnuos de performance
Tanto o Modelo-V como o 4Q no abordam a fase de alienao.

A validao do sistema informtico considerado deve ento incluir todos os seus componentes
(software, hardware, procedimentos e equipamentos adicionais) assim como deve englobar e
manter-se durante todo o ciclo de vida do mesmo. No pode ser feita s durante o
desenvolvimento e instalao, deve ser mantida durante todas as fases do seu ciclo de vida. O
modelo de ciclo de vida do sistema informtico SAP engloba de uma maneira geral as fases
representadas na Figura 10.
Figura 10 Ciclo de vida do sistema informtico SAP
O ciclo de vida do sistema acaba quando o software, hardware ou os processos se tornam

obsoletos, e se procede sua retirada.
Pgina 55 de 72
8. Manuteno do Estado de Validao
8.1 Manuteno Preventiva e Calibrao

Foram incorporadas nos procedimentos aprovados actividades de rotina de reparao e
manuteno. Sero abrangidos no mbito da manuteno os equipamentos informticos, de
instrumentao, e elementos de comunicao em rede.
A frequncia de manuteno dever estar definida nestes procedimentos e, devem cumprir as
recomendaes. As frequncias de manuteno podem ser determinadas por requisitos de
recalibrao e centrados na confiabilidade de clculos de manuteno preventiva. Devero
registar-se as justificaes para intervalos de inspeco peridica, lembrando que elas podem ser
modificadas em funo da experincia operacional. Qualquer alterao aos perodos das
recalibraes ou aos intervalos de manuteno preventiva devem, no entanto ser controlados.
8.2 Instalao e Validao/Revalidao

Quando uma grande actualizao est a ser planeada vale a pena considerar a antecipao da
prxima reviso peridica para determinar se qualquer revalidao pode ser combinada com o
esforo de actualizao. As correces de erros, necessrias, normalmente so geridas com base
na Gesto de Alteraes na Qualificao de Instalao (QI). Em ambos os casos o alcance da
alterao deve ser entendido antes da instalao e validao. Devem ser consultadas as notas do
fornecedor.
Algumas actividades de Qualificao Operacional (QO) podem ser necessrias para verificar a
actualizao, confirmando que velhas e novas funcionalidades esto disponveis e funcionam.
8.3 Gesto de Alteraes e Controlo de Configuraes

Um pr-requisito para a validao a existncia de processos de controlo para assegurar que
qualquer mudana num sistema em primeiro lugar documentada e avaliada antes de ser
implementada. A gesto de alteraes deve assegurar que o processo de revalidao executado
quando necessrio.
Todas as alteraes que podem afectar a qualidade do produto ou reprodutibilidade do processo
devero ser formalmente solicitadas, documentadas e aceites. O provvel impacto da alterao
Pgina 56 de 72
das instalaes, sistemas e equipamento sobre o produto deve ser avaliado, e includo na anlise
de riscos. A necessidade de, e a extenso de requalificao e revalidao deve ser determinada.
Durante o processo de desenvolvimento, construo, validao, uso e alienao de sistemas

informticos, dever estar em vigor um sistema de procedimentos de controlo das alteraes. O
objectivo assegurar que qualquer alterao nas aplicaes do sistema informtico controlada
de forma a que ele permanecer em conformidade com os regulamentos GMP. Isto pode incluir o
hardware, software, autorizaes, formao e documentos.
Quaisquer alteraes ao caderno de especificaes, cdigos de programao ou hardware devem

seguir procedimentos escritos e ser documentadas. As alteraes podem ser iniciadas porque
foram encontrados erros no programa ou porque so desejveis funes diferentes ou adicionais
do software ou hardware. Os pedidos de alterao devero ser apresentados pelos utilizadores e
autorizados pelo supervisor do sistema (IT) e director da GQ. Para iniciar, e autorizar a
documentao de alteraes devem ser utilizados impressos prprios. O mais importante que as
alteraes devem seguir procedimentos uniformes para o incio, autorizao, execuo, anlise e
documentao. Todas as actividades devem ser planeadas no projecto de validao e
documentadas no relatrio de validao.
Aps qualquer alterao o programa deve ser testado. Devem ser feitos testes completos para a
parte do programa que foi alterado e o teste de regresso ser feito para todo o programa.
Ser mantido e utilizado na Bluepharma um sistema de Gesto de Alteraes (NP-07-04) para
rever, aprovar, e documentar as alteraes antes da instalao. Ir identificar a finalidade e
descrio das alteraes, a aprovao da alterao, e quem realizou a alterao. Se for necessria
uma alterao para qualquer um dos produtos da validao, ser exigida aprovao pelos
signatrios originais ou seus equivalentes.
Pgina 57 de 72
Figura 11 Fluxograma seguido quando existem alteraes a ser implementadas
Pgina 58 de 72
8.4 Audit Trail

As informaes de Audit Trail que apoiam os registos de controlo de alteraes devero ser
mantidas com ou como parte dos seus respectivos registos de controlo de alteraes. Os Audit
Trails devem incluir informaes sobre quem fez a alterao de dados, a natureza da alterao, e
a data/hora a que a alterao foi feita. As informaes de Audit Trail podem ser mantidas em
formato de papel, electrnico, ou hbrido. Seja qual for o meio escolhido, as informaes de
Audit Trail devem ser conservadas em conjunto com os respectivos dados e devem estar
disponveis em forma legvel para fins de inspeco. As medidas de segurana devem ser
equivalentes s usadas para proteger os dados mestre e ficheiros. Esta funcionalidade encontra-se
disponvel no sistema informtico, e o procedimento que regula o seu funcionamento vai ser
concludo.
8.5 Backup e Restore

A regulamentao GxP exige s empresas farmacuticas cuidados para manter backups de
programas de software, incluindo configurao, dados introduzidos, e dados operacionais de
acordo com procedimentos definidos. Os backups proporcionam um meio de recuperao de
sistemas informticos e restauro de registos GxP, de perdas, corrupo, danos fsicos, e alteraes
no autorizadas. Sem uma capacidade de backup e restore, a maioria das empresas no pode
recuperar de uma catstrofe de grandes propores, independentemente de outras preparaes
que tenha feito.
O procedimento para backup e restore (NG-21-004) foi actualizado, e deve ser usado para
produzir cpias de dados e para restore do sistema. Devem ser documentados os procedimentos
que descrevem a rotina de emergncia e manuteno do sistema. Os procedimentos definem a
gesto e integridade dos registos electrnicos.
8.6 Planeamento de Continuidade de Negcio

O plano de continuidade de negcio define como perturbaes significativas no planeadas para
as operaes comerciais (por vezes referidas como catstrofes) podem ser geridas a fim de
permitir a recuperao do sistema e retomar a actividade. As interrupes podem ocorrer como
Pgina 59 de 72
resultado da perda de dados ou interrupo da totalidade ou parte da funcionalidade do sistema

informtico. A srie de circunstncias que causam perturbao pode variar da eliminao
acidental de um nico arquivo de dados at perda de todo um Data Center (Sala de Servidores),
devido por exemplo, a incndio.
Os planos de continuidade de negcio so por vezes referidos como planos de recuperao de
desastres ou de planos de contingncia. H dois cenrios bsicos:
Suspender operaes at que o sistema informtico seja restaurado.
Utilizar meios alternativos para continuar as operaes comerciais at o sistema informtico
ser restaurado.
Suspender as operaes comerciais pode implicar a remoo do trabalho em curso ou a
continuao do trabalho em curso at concluso usando meios alternativos. Pode ser possvel
utilizar meios alternativos para apoiar as operaes comerciais por algum tempo at sua
suspenso final enquanto se aguarda pelo restauro do sistema informtico original.
Foi criado o procedimento para garantir a continuidade das operaes em caso de falha do
sistema. O planeamento de recuperao de desastre que aborda a recuperao tcnica de
hardware de computao, software, comunicaes e dados o procedimento Plano de
Emergncia (NG-21-003) e deve ser utilizado.
8.7 Segurana
O hardware, software e dados (locais e remotos), devem ser protegidos contra a perda, a
corrupo, e o acesso no autorizado. A segurana uma considerao importante para todos os
sistemas, e envolve a proteco geral do hardware, software e dados de alteraes no
autorizadas ou acidentais, perda ou divulgao. Devem existir procedimentos de segurana para
garantir a integridade dos sistemas, dados, processos e documentao associada.
A segurana fsica necessria para impedir o acesso fsico no autorizado por pessoal interno e
externo ao sistema de hardware. Limitando o acesso instalao/sistema a pessoas autorizadas
por meio de, por exemplo, chaves ou cartes de acesso.
A segurana lgica necessria para prevenir o acesso no autorizado rede, dados e aplicaes
de software. o conjunto de medidas destinadas a limitar acesso ao sistema, de acordo com
responsabilidades laborais, atravs do controlo de passwords ou similar. A norma (Organizao
Pgina 60 de 72
da Autorizao de Acesso aos Sistemas Informticos, NG-21-005, foi actualizada e deve ser
utilizada).
Foi estabelecido o procedimento para a utilizao correcta do sistema e evitar a introduo de
vrus informticos, garantindo a conformidade para a proteco de informaes nos sistemas
electrnicos e est em vigor na empresa designando-se NG-21-010.
8.8 Registos Electrnicos e Assinaturas Electrnicas

Muitos pases j introduziram regulamentos que regem a utilizao de registos electrnicos e o
equivalente jurdico das assinaturas manuscritas, as assinaturas electrnicas. Os requisitos bsicos
so estabelecidos com base nas expectativas GxP. A interpretao dos regulamentos dos registos
e assinaturas electrnicas e dos mtodos adequados para atingir a conformidade, tm sido objecto
de muito debate e discusso na indstria. H que definir os aspectos prticos do cumprimento
com a U.S. 21 CFR Part 11viii sobre os registos/assinaturas electrnicas e outros requisitos
regulamentares internacionais. Foi criado um procedimento criterioso de controlo de acessos aos
sistemas, com registo do utilizador e nvel de acesso. A autenticao e controlo feita por meio
de username e password.
8.9 Revalidao
Os Sistemas Informticos sofrem mudanas at mesmo para sustentar as suas intenes originais
de desenho. Os Sistemas Operativos e pacotes de software standard, vo exigir actualizaes
enquanto que os vendedores iro retirar apoio a produtos mais antigos. As novas tecnologias
podem levar a alteraes de hardware do sistema informtico e das infra-estruturas de rede. Salvo
se a documentao for completamente revista para incorporar as alteraes, o documento ter de
ser redigido em conjugao com os registos de controlo de alteraes. Como progressivamente
mais mudanas sero feitas, tornar-se- mais difcil compreender com preciso o sistema actual
como um todo, e estabelecer o rigor de um futuro controlo de alteraes, porque o impacto das
alteraes propostas sobre o sistema existente ser mais difcil de avaliar.
A revalidao pode ser sincronizada para coincidir com as actualizaes do sistema informtico
de maneira a fazer uma utilizao mais eficaz dos recursos. Estas estratgias devem ser definidas
e aprovadas previamente.
Pgina 61 de 72
A revalidao muitas vezes pode ser realizada sem restringir a libertao de produtos cujo
fabrico, apoiado por um sistema informtico. O pessoal autorizado da Garantia de Qualidade
deve aprovar a libertao de produtos farmacuticos durante a revalidao.
8.10 Testes
Os Testes servem o propsito de treino e verificao do status dos componentes e subsistemas do
sistema informtico isoladamente, utilizando inputs conhecidos, para gerar outputs reais que so
posteriormente comparados com os outputs esperados. Os testes devem ser executados baseados
nos erros e nas falhas, e devero ser aplicados tal como descrito anteriormente.
Figura 12 Representao do processo de execuo dos testes
importante que as empresas farmacuticas tenham confiana nos testes estruturais, bem como
nos testes funcionais do sistema informtico. Um complementa o outro, e juntos fornecem a
medida da qualidade global do sistema. Os registos dos testes s Unidades e dos testes de
Integrao (incluindo as especificaes e resultados) devem ser mantidos pelo fornecedor e
conservados para fins de inspeco, se tal lhe for solicitado, pela empresa farmacutica.
Quaisquer emulaes, e simulaes usadas durante a fase de testes deve ser especificada, e
demonstrada a garantia nas suas capacidades.
Recomenda-se que cerca de 80% do esforo de desenvolvimento de testes seja centrada em
Testes s Unidades e em Testes de Integrao de modo a estabelecer a inerente correco
estrutural do sistema informtico. O restante esforo de teste aplicado para executar Testes ao
Sistema.
Uma boa metodologia e plano de qualidade iro garantir que, vrios tipos de testes sejam
realizados ao longo de todo o desenvolvimento do ciclo de vida. Este tpico analisa os seguintes
tipos de teste:
Testes s Unidades
Pgina 62 de 72
Testes de Integrao
Testes de Aceitao de Sistema
Testes de Esforo
8.10.1 Testes s Unidades

Estes testes so vulgarmente conhecidos como testes de mdulos e so os teste realizado ao nvel
de uma nica rotina funcional ou mdulo de software. A um nvel simples, e independente do
sistema como um todo, o teste s unidades verifica se a rotina fornece outputs correctos para um
determinado conjunto de inputs. So realizados Testes s Unidades para verificar se o sistema
opera, tal como definido no caderno de especificaes.
8.10.2 Testes de Integrao

Verificam que o sistema funciona correctamente como um todo. Fazendo prova de que todos os
mdulos do software interagem correctamente uns com os outros para formar o sistema de
software, tal como definido na especificao de desenho e especificaes funcionais.
realizado inteiramente sobre o sistema construdo, medida que este est a ser utilizado pelos
utilizadores finais. Os dados provenientes de outros sistemas externos podem, contudo, ser
fornecidos por interfaces simulados.
Exemplo: Um sistema de planeamento de recursos da produo poderia ser testado com os dados
fornecidos a partir de um arquivo morto, simulando a interface com o sistema de inventrio, sem
necessidade do sistema de inventrio ser envolvido nos testes.
Do mesmo modo, um sistema de controlo de processo pode ser testado por entradas e sadas
simuladas a partir de instrues na fbrica.
8.10.3 Testes de Aceitao de Sistema

o teste do sistema que testa as interfaces com outros sistemas no ambiente informtico. Dever
abranger tanto o teste dos requisitos do utilizador como da funcionalidade do sistema. Isto no s
verifica que o sistema aceita dados correctamente a partir de outros sistemas, mas tambm que os
Pgina 63 de 72
dados so transferidos com preciso para sistemas a jusante e que estes so processados
correctamente dentro do prprio sistema.
Os testes de aceitao do sistema geralmente so feitos separadamente dos testes de integrao, a

fim de minimizar os requisitos de tempo e especializao para os demais sistemas. Os testes
podem ser realizados:
Aos fornecedores (e depois repetidos no local do utilizador)
Exclusivamente no local do utilizador
8.10.4 Testes de Esforo

Envolve a catalogao do facto de o sistema falhar de formas esperadas que no so catastrficas,
mas ainda assim so facilmente reconhecidas como erros.
Existem duas categorias de testes de esforo:

Introduo de dados que esto fora do intervalo aceitvel de dados do sistema e garantir que os
dados so sinalizados como erros
Testando o sistema com um elevado volume de transaces. O objectivo determinar o valor
mximo da sua capacidade operacional no qual o sistema pode ser executado sem o perigo de
perda ou corrupo de dados. Com base neste tipo de teste, o responsvel por projectar o sistema
ir definir a capacidade mxima operacional do sistema.
Estes dois tipos de testes de esforo devem ser realizados pelo responsvel por projectar o
sistema como parte do teste s unidades e teste de integrao, e no como uma actividade
separada. Testes semelhantes do sistema relacionados com as operaes planeadas do utilizador e
do ambiente devem ser includos como parte da Qualificao de Performance.
8.10.5 Resultados dos Testes

O resultado de cada teste comparado a critrios de aceitao para determinar se o resultado
cumpre os critrios, sem desvios. Os resultados de testes finais so documentados e aprovados
como Passou, No Aplicvel, ou Falhou.
Pgina 64 de 72
Passou - significa que o resultado do teste preenche os critrios de aceitao na ntegra, como
especificado no script de teste, sem desvios de qualquer modo.
No Aplicvel - significa que no necessrio testar a funcionalidade em causa, justificando o

porqu dessa classificao. Ex: no caso de testes s transaces SAP, estas podem no estar em
uso na empresa, no sendo portanto aplicvel a execuo dos testes.
Falhou - significa que o resultado do teste no cumpre os critrios de aceitao. Os resultados

destes testes devem ser resolvidos antes de uma concluso geral poder ser extrada da qualidade
do produto que est a ser testada.
8.11 Documentao
A regulamentao GxP exige s empresas farmacuticas manter um sistema de documentao, e
isso inclui todos os sistemas informticos de apoio gesto e controlo dos registos electrnicos.
Vejamos, por exemplo, o Artigo 9 do EU GMP. O artigo 9.1 requer que os documentos sejam
claros, legveis, actualizados, e mantidos durante o perodo adequado, e o artigo 9.2 passa a
antecipar os registos electrnicos, sendo o requisito principal que os sistemas informticos de
apoio sejam validados. A FDA espera que os sistemas que mantm os registos sejam validados
quando exigido pelas regras ou se tm impacto directo sobre a qualidade do produto, segurana
do produto, ou integridade dos registos.
A validao deve demonstrar que o sistema informtico capaz de guardar os registos
electrnicos durante o tempo necessrio, que os dados esto prontamente disponveis em forma
legvel, e que os registos electrnicos esto protegidos contra perda ou dano. Ambos os controlos
tcnicos e processuais devero ser validados, incluindo a funcionalidade de Audit Trail e a
aplicao bem sucedida das assinaturas electrnicas aos registos.
As empresas farmacuticas devem garantir que tm um plano de conformidade que abranja toda a
parte da sua organizao sujeita 21 CFR Part 11ix.
Pgina 65 de 72
8.11.1 Documentao na Empresa

O seu objectivo definir o Sistema de Documentao da Bluepharma, Indstria Farmacutica
S.A.. No caso da validao, a documentao essencial para definir todos os componentes e
procedimentos relacionados com o IT.
Pretende estabelecer os requisitos mnimos a que o sistema de documentao deve obedecer no
formato, preparao, aprovao, distribuio e arquivo de todos os documentos no mbito das
normas em vigor na empresa ao abrigo das GMP referncia da indstria e s normas especficas
do mercado norte-americano estabelecidas pela FDA referentes aos sistemas electrnicos.
O Sistema de Documentao inclui todo o tipo de documentos/registos que descrevem a forma
como executar e registar as operaes relacionadas com a actividade da empresa. Os documentos
so aprovados, assinados e datados pelas pessoas autorizadas de acordo com a norma NP-04-07.
A documentao tratada atravs de mtodos electrnicos de processamento de dados, apenas est

acessvel a pessoas autorizadas a entrar ou modificar os dados nos Sistemas Informticos,
existindo um registo das alteraes e supresses; o acesso efectuado atravs de username e
password, e o resultado da entrada de dados crticos verificado. Os dados dos registos dos lotes
armazenados electronicamente so protegidos, por intermdio de cpia para fita magntica,
microfilme, papel ou outro meio. particularmente importante o acesso pronto aos dados durante
o perodo em que so conservados. O sistema de documentao da empresa est disponvel em
rede com acesso restrito, no sendo permitida a sua alterao a no ser com autorizao para o
efeito.
Pgina 66 de 72
Tipo, hierarquia e aprovao dos documentos:
Figura 13 Hierarquia da documentao na empresa
Normas Gerais: Esto relacionadas com as Normas Padro sendo mais detalhadas, aplicveis a
vrios Sectores e servem de base elaborao dos Procedimentos dos vrios Sectores.
Descrevem em sentido lato o mecanismo, sistema, ou modo como os respectivos Sectores devem
proceder. Esto codificadas sequencialmente com inicio em NG-QQ-SSS-EE em que os
primeiros 2 dgitos (QQ) dizem respeito ao elemento da qualidade em questo, os 3 dgitos
seguintes (SSS) indicam a sequncia e os 2 ltimos dgitos (EE) identificam a edio.
Procedimentos: Determinam com especificidade como so executadas as tarefas de dado Sector

e do indicaes sobre a realizao de certas operaes, como por exemplo: PI-SSS-EE
Impressos: So independentes da restante documentao, mas esto relacionados com os

documentos de hierarquia superior. Destinam-se a preenchimento de dados, o qual, quando
manual deve ser feito preferencialmente com tinta azul. So preparados pela Garantia de
Qualidade ou directamente pelos sectores e aprovados pela GQ e sectores onde a utilizao dos
impressos cause algum impacto. As assinaturas de quem elabora/aprova esto no verso do
Pgina 67 de 72
documento original que se encontra na Garantia da Qualidade. A codificao dos impressos

semelhante descrita para as normas, e a designao sempre referente norma que lhe est
associada.
8.11.2 Aprovao da documentao

O Departamento de Informtica (IT) elabora os procedimentos e respectivos impressos que tm
em vista assegurar uma correcta manuteno do sistema informtico, de seguida entrega-os
garantia da qualidade para reviso. No caso de haver alteraes a realizar regressam novamente
informtica para correco. Quando estes se encontrarem nas condies definidas pela garantia
de qualidade so aprovados para implementao na empresa.
A garantia da qualidade responsvel pela documentao de toda a empresa (p.ex. Normas
Padro, Normas Gerais, Procedimentos, Impressos etc..).
No decorrer deste trabalho revelou-se evidente a necessidade da realizao de reunies entre estes
dois sectores da empresa de modo a definir objectivos na realizao da documentao
nomeadamente no que refere ao objectivo desta servir os propsitos da validao dos sistemas
informticos, seguindo o caminho mais eficiente para o concretizar.
Documentao criada e/ou revista durante esta validao:

Documento Ttulo
NG-21-002-02 Investigao e tratamento de erros ocorridos nos sistemas Informticos
Imp.(NG-21-002)-01A Ocorrncia de erros nos sistemas informticos
NG-21-003-02 Elaborao de um plano de continuidade e de emergncia para os Sistemas Informticos
NG-21-004-02 Arquivo e segurana de dados dos Sistemas Informticos (Backup e Restore)
Imp.(NG-21-004)-02A Recuperao de dados dos Sistemas Informticos
NG-21-005-02 Organizao da autorizao de acesso aos Sistemas Informticos
Imp.(NG-21-005)-01 Autorizao de acessos aos Sistemas Informticos
NG-21-006-02 Dirios dos Sistemas Informticos e PCs Aplicados
Imp.(NG-21-006)-01A Dirio de ocorrncias
NG-21-007-02 Caracterizao da Sala de Servidores
Imp.(NG-21-007)-01A Impresso de controlo da temperatura na Sala de Servidores
NG-21-008-01 Documentao dos pedidos para os Sistemas Informticos
NG-21-009-01 Ligao de computadores a sistemas especficos
Imp.(NG-21-009)-01 Ligao de computadores a sistemas especficos
Imp.(NG-21-009)-02 Aprovao de um computador ligado a um sistema especfico
NG-21-010-01 Boas prticas na utilizao de recursos informticos
NG-21-011-01 Caracterizao dos Sistemas Informticos
Imp.(NG-21-011)-01 Caracterizao dos Sistemas Informticos
NG-21-012-01 Polticas de Passwords
Pgina 68 de 72
9. Concluso
O processo de validao deve ser ponderado e adequar-se ao risco global colocado pelo sistema
informtico, que funo da complexidade do sistema, do impacto no paciente/produto, e nvel
de personalizao do software. Um sistema de baixo risco deve portanto merecer uma abordagem
menos profunda de especificao, experimentao e validao. Existe, no entanto, por parte das
entidades reguladoras a crescente exigncia de mais documentao e testes, que no do garantia
adicional de segurana ou qualidade do produto. Surgindo numa tentativa desesperada para
garantir que os documentos referentes a todos os cantos, cada porca e parafuso, e cada boto da
bata de laboratrio so assinados, aprovados e entregues ao olhar frio dos auditores.
O resultado pode ser que mesmo o esforo que feito para tornar a validao uma verdadeira
ferramenta de controlo do processo seja contrariado. Na sua forma mais perversa a validao
pode mesmo tornar-se cara, ineficiente, ineficaz e inbil. Impede progressos e impede que surjam
outros sistemas credveis para uma boa produo de frmacos.
Deve perguntar-se se toda esta actuao necessria ou benfica e se um mtodo melhor pode ser
encontrado. Mas acima de tudo deve procurar entender-se como realmente funciona e aplicada
a validao, talvez ento a opinio de todos fosse a de que a validao funciona se for bem feita.
Esta opinio generalizada levou a que surgissem melhores formas de desenvolver e realizar a
validao. O que inclui movimentos no sentido de implementar medidas de Custo da Qualidade e
de Avaliao de Risco para fornecer sistemas que executam e controlam o trabalho com
suficiente garantia de qualidade e segurana, sem o nus da documentao e planeamento
desnecessrios.
As actividades de validao exigidas para qualquer sistema informtico quer central ou local,
devem ainda ter o apoio activo e visvel da direco para alcanar o sucesso. Esta adeso d um
sinal claro aos colaboradores de que a validao satisfatria do software e componentes do
sistema uma preocupao da gesto e uma prioridade, e que dever trazer benefcios concretos
para a organizao, a longo prazo.
Assim sendo, as organizaes no devem esperar por uma inspeco para detectar ou corrigir
quaisquer problemas decorrentes da validao dos seus sistemas informticos. O
Pgina 69 de 72
acompanhamento regular das actividades de validao, medida que estas tm lugar deve ser
usado como uma base para determinar a eficcia do Plano Mestre de Validao.
Quaisquer incidentes ou desvios relacionados com o sistema devem ser investigados e utilizados
como parte do processo de melhoria contnua que uma parte da documentao e dos
procedimentos operacionais que devem ser criados para apoiar o desenvolvimento do ciclo de
vida do software em todas as organizaes farmacuticas.
portanto fundamental que a empresa tenha uma boa compreenso do sistema/equipamento e da
sua utilizao para que a quantidade correcta de validao seja executada, garantindo a qualidade
do medicamento e sem comprometer ou pr em risco a segurana do paciente.
Pgina 70 de 72
10. Referncias Bibliogrficas
i
FDA, Guidance for Industry: General Principles of Software Validation. Draft Guidance,
Version 1.1. June 9, 1997.
ii
International Society of Pharmaceutical Engineers, Good Automated Manufacturing Practice,
GAMP Guide for Validation of Automated Systems, (GAMP 4), December 2001.
iii
EU GMP Guide for Medicinal Products - Computerised Systems, - Annex 11.
iv
Engineering Management Journal, Project Risk Management Using the Project Risk FMEA,
Thomas A. Carbone, Donald D. Tippett, - Vol. 16 No. 4 December 2004
v
EU GMP Guide for Medicinal Products - Final Version Qualification and validation -
Annex 15
vi
EU GMP in Practice Computer Validation, Chapter 9
vii
Computer Systems Validation: Quality Assurance, Risk Management, and Regulatory
Compliance for Pharmaceutical and Healthcare Companies, Wingate, G.A.S. (2004)
viii
Food and Drug Administration, Guidance for Industry, Part 11, Electronic Records;
Electronic Signatures Scope and Application, August 2003.
ix
Food and Drug Administration, General Principles of Software Validation; Final Guidance
for Industry and FDA Staff, January 11, 2002.
ICH Harmonised Tripartite Guideline, International Conference on Harmonisation of Technical

Requirements for registration of pharmaceuticals for human use Pharmaceutical Quality
System Q10 - Current Step 4 version, 4 June 2008
Institute of Electrical and Electronics Engineers, IEEE Standards Collection: Software

Engineering, 1994 Edition
Pharmaceutical Manufacturers Association, Validation Concepts for Computer Systems Used in

the Manufacture of Drug Products Pharmaceutical Technology, Vol. 10(5). 1987. pp. 24-34
GAMP Forum, Supplier Guide: Version 2.0. May 1996.
International Society of Pharmaceutical Engineering, GAMP Guide for Validation of Automated

Systems in Pharmaceutical Manufacture: Version 3.0. Vols. 1-2. March 1998.
Risk-Based Validation of Computer Systems Used In FDA-Regulated Activities, September 2

2003
Meeting the Challenge of Computer System Validation (1998)
Pgina 71 de 72
Websites
www.21part11.com Viso da Indstria da U.S. CFR Part 11

www.fda.gov FDA Home Page
www.ispe.org ISPE Home Page (GAMP Forum)
www.labcompliance.com Ludwig Hubers Compliance Home Page
www.mhra.gov.uk MHRA Home Page
www.pda.org PDA Home Page
www.phrmafoundation.org PhRMA Home Page
www.picscheme.org PIC/S Home Page
www.psiweb.org Estatsticas na Indstria Farmacutica
11. Anexos
Descrio do Documento Referncia do Documento
[1.] Plano QI MySAP ERP BLUEP QI
[2.] Plano QO MySAP ERP BLUEP QO
Pgina 72 de 72
Plano de Qualificao de Instalao (QI) - MySAP ERP 2005, ECC 6.0
Sntese do Documento
Este documento descreve o plano para qualificar os principais componentes de hardware e software do MySAP ERP.
Detalhes do Documento
Projecto MySAP ERP 2005
Status / Verso 1.0
Cdigo de Referncia BLUEP-QI

Contedo
1. SOBRE ESTE DOCUMENTO .......................................................................................... 3

1.1 FINALIDADE ................................................................................................................. 3
1.2 AUDINCIA................................................................................................................... 3
1.3 MBITO ....................................................................................................................... 3
2. INTRODUO ................................................................................................................. 4
3. MBITO DE TESTE ......................................................................................................... 5
4. ESTRATGIA DE TESTE ................................................................................................ 6

4.1 CONDIES PRVIAS DE TESTE ................................................................................... 6
4.2 PESSOAS ENVOLVIDAS NA EXECUO ........................................................................... 6
4.3 EXECUO DA QUALIFICAO ...................................................................................... 6
4.4 TESTES A EXECUTAR.................................................................................................... 6
4.4.1 Desvios ............................................................................................................... 8
4.4.2 Aceitao ............................................................................................................ 8
4.4.3 Estado da Qualificao ....................................................................................... 8
4.5 AMBIENTE UTILIZADO ................................................................................................... 9
4.6 TIPOS DE TESTE .......................................................................................................... 9
5. FUNES E RESPONSABILIDADES .......................................................................... 10
6. RELATRIO DE QUALIFICAO ................................................................................ 10
BLUEP-QI Pgina 2 de 10
1. Sobre este documento
1.1 Finalidade
O objectivo deste documento definir as actividades e responsabilidades para levar a cabo a

qualificao dos principais componentes do sistema MySAP ERP 2005.
O propsito dos testes fornecer provas documentais de que as prestaes dos testes listadas no Plano
Mestre de Validao foram realizadas correctamente.
O principal objectivo deste plano obter provas documentais que comprovem que:
A instalao do mySAP na plataforma de teste e de produo est a funcionar correctamente.
Os servidores, base de dados e aplicao esto operacionais,
Os principais componentes LAN e aparelhos de Rdio Frequncia, e
A instalao da aplicao tem sido documentada seguindo as regras das boas prticas de
documentao.
Este documento foi escrito de acordo com os critrios estabelecidos no Plano Mestre de Validao, E
de acordo com a Avaliao de Riscos.
1.2 Audincia
Este documento para uso das pessoas envolvidas na fase de testes.
1.3 mbito
Este documento abrange as plataformas de teste e de produo com os seguintes componentes:
Software
Servidores e sistemas operativos dos clientes
Oracle DB
Mdulos SAP GxP (MM, SD, WM, PP-PI, QM)
Desenvolvimentos que afectam estes mdulos
Interfaces
Hardware
Servidores de Teste e de Produo
PCs Clientes, portteis
Elementos de Rdio Frequncia (RF)
Impressoras
Principais componentes LAN
Outros
Sala de Servidores
2. Introduo
Este teste ser realizado no departamento de IT, de acordo com processos e protocolos predefinidos.
O objectivo do plano de testes explicar a abordagem planeada para todas as actividades de teste de
um determinado projecto. Inclui informaes sobre o mbito de aplicao do teste, o tipo de teste e o
ambiente a ser utilizado para a realizao dos testes. A natureza exacta de um determinado plano de
teste depender do sistema a ser testado. Os planos de teste devem ser aprovados antes dos testes
poderem comear. As pessoas, que aprovam o documento devem ser identificadas na capa, pelo nome
e funo. Normalmente, ser o Gestor de Projecto e Director da Garantia de Qualidade ou delegado.
3. mbito de Teste
Os scripts de teste devem ser definidos para cada componente dos grupos indicados no ponto 1.3
mbito, plataformas de Teste e Produo. O seguinte esquema representa um resumo desses
ambientes:
Figura 1: Esquema MySAP ERP
4. Estratgia de Teste
4.1 Condies Prvias de Teste
Os seguintes documentos so aprovados pela GQ antes de se executarem os scripts de teste de QI:
O Plano Mestre de Validao,
O Plano de Teste de QI (este documento),
Os Scripts de Teste de QI.
4.2 Pessoas envolvidas na execuo
Identificar todos os participantes e os seus papis ou seja o Executante, Revisor e garantia de

qualidade associados execuo do teste QI.
4.3 Execuo da Qualificao
A Qualificao da instalao (QI), ser realizada na sequncia deste documento, bem como as
instrues gerais da seco 5 - Planeamento de Testes no captulo 6 - Plano Mestre de Validao.
Aps todos os testes serem executados, deve ser escrito como um resumo do processo QI, um relatrio
de Testes de QI. Este relatrio deve mostrar que os critrios de aceitao foram atingidos e por isso a
aplicao pode ser considerada instalada de acordo com os parmetros pr-fixados.
4.4 Testes a executar
Os testes a executar devem ser usados a fim de verificar as diferentes especificaes do sistema e
sero definidos num apndice a este plano, em grupos homogneos de testes. Uma vez aprovados, os
testes realizados sero eles prprios documentados nos Scripts de Teste. Antes de iniciar a execuo, o
executante e o revisor devem assinar o presente documento, e devem verificar se os testes cumprem
com as condies estabelecidas. Em cada Script de Teste ser definido o objectivo principal, os
critrios de admisso e os pr-requisitos para a execuo do teste.
Cada especificao tcnica ser testada ao longo do teste. Cada teste (associado a cada especificao)
ser referenciado por uma nica ID do teste e ser traduzido em medidas de teste e em resultados
esperados. Um ou vrios passos podem representar cada especificao.
Cada Script de Teste deve ser referenciado com um nmero. A execuo do teste ser feito numa
cpia controlada do Script de Teste de QI aprovado.
As evidncias (provas), sero anexadas a algumas etapas com referncias cruzadas entre os scripts de
cada etapa e as respectivas evidncias. As referncias das evidncias devem ser registadas nos
resultados reais, juntamente com o veredicto do teste: Passou, Falhou ou No Aplicvel (N/A).
Para verificar se a instalao foi bem feita, os seguintes grupos de testes devem ser executados:
Teste # Tipo Descrio
Teste 1: Verificar os Identificar as datas de aprovao dos documentos necessrios

1.
documentos aprovados para a execuo QI.
Identificar os servidores instalados e registar o principal

2. Teste 2: Verificar Servidores
hardware, software e configurao de dados.
Identificar os clientes SAP (PCs, portteis) e registar o principal

3. Teste 3: Verificar PCs Clientes
hardware, software e configurao de dados.
Teste 4: Verificar elementos de Identificar os elementos RF e registar o principal hardware,

4.
Rdio Frequncia software e configurao de dados.
Identificar as impressoras, componentes LAN e anotar os

Teste 5: Verificar componentes
5. principais componentes de hardware, software e configurao
LAN e impressoras
de dados.
Teste 6: Verificar Software Identificar os mdulos SAP, interfaces e registar o principal

6.
SAP software de configurao e dados.
Teste 7: Verificar Sala de Identificar as caractersticas da Sala de Servidores e gravar os

7.
Servidores principais elementos.
Tabela 1: Testes a ser executados
Cada passo deve ser executado (com a excepo das instrues a seguir ou comentrios) e os
resultados esperados devem ser cumpridos para passar no teste. O executante deve assinar e datar cada
etapa. Aps analisar os Scripts dos Testes executados e as suas evidncias, o revisor deve assinar os
grupos de teste e dar a sua sentena: Aceite ou Rejeitado.
Os testes que devem ser novamente efectuados devem ser executados com o prximo nmero de
iterao e devem ser includos no Resumo e Concluses dos Scripts de Testes e no Relatrio de
Qualificao.
4.4.1 Desvios
Conforme estabelecido no Plano Mestre de Validao, qualquer falha ocorrida durante os testes ser
identificada num Formulrio ou Registo de Falhas de Teste. Cada etapa no script de teste ir incluir
um espao para uma referncia no Formulrio de Falhas de Teste. Este formulrio dever incluir as
medidas necessrias para corrigir o problema ou uma declarao justificando a razo por que a falha
no afectar a libertao do sistema para produo.
As falhas de Teste sero categorizadas como:
Maior Tudo o que no coincide com os resultados esperados ou uma falha que
impede a concluso bem sucedida do teste, e que vai tornar o componente
no apto sem um maior desenvolvimento e novo teste.
Menor Uma falha registada que no impede a realizao do teste, e que no ir

impedir que o produto seja libertado. Isso tambm poder ser um incidente
que ocorre fora do controlo do executante/teste. Pode ser emitida uma
declarao com constrangimento.
(NB: Mltiplas falhas menores podem tambm impedir a libertao)
No testada O teste no pde ser concludo, e este item no foi testado.
Todas as falhas de teste sero gravadas num formulrio e registo de Falhas
4.4.2 Aceitao
Uma vez que o Executante tenha realizado um script de teste, o Revisor deve verificar a sua execuo
e as evidncias, e deve assinar os grupos de teste e dar a sua sentena: Aceite ou Rejeitado.
4.4.3 Estado da Qualificao
A manuteno da qualificao deve ser gerida aplicando o procedimento de Gesto de Alteraes (NP-
07-04). Este procedimento ser aplicado para cada alterao, modificao ou melhoria para essas
plataformas depois de iniciar a qualificao de instalao.
4.5 Ambiente utilizado
Devem ser apresentadas para os testes informaes completas sobre o ambiente utilizado. No esquema
da figura 1, o ambiente de teste representado pela plataforma BlueDevl-BLDADM e o ambiente de
produo representado pelo BlueReal-BLPADM. O resto dos componentes sero qualificados nos
Scripts de Teste de QI.
4.6 Tipos de Teste
Os seguintes grupos de teste devem ser definidos nos Scripts de Teste de QI:
Condies prvias de teste
Servidor de teste
Teste de PCs Clientes e portteis
Teste de aparelhos de Rdio Frequncia
Teste de impressoras LAN, balanas e outros dispositivos
Teste da Sala de Servidores
5. Funes e Responsabilidades
Funo Responsabilidades
SVS Elabora os scripts de teste. Realiza testes utilizando

scripts de teste. Garante que os scripts de teste e os
Formulrios de Falhas de Testes esto correctamente
preenchidos e assinados, produz Logs de Resoluo
de Teste e o relatrio de teste de QI.
Gestor do Projecto Assegura que os ambientes de teste esto disponveis

e controlados, garante que os scripts de teste so
produzidos, aprovados e executados, processa os
Formulrios de Falhas. Garante que os prazos de teste
so cumpridos.
URS (IT) Leva a cabo testes utilizando scripts de teste.

Assegura que os scripts de teste so concludos
correctamente, e que qualquer formulrio de falhas
de Teste est correctamente preenchido.
Garantia de Qualidade Verifica a documentao formal, tal como acordado

com o Coordenador de Teste. Aprova o plano de teste
e scripts de teste, o Formulrio das Falhas de Teste e
o relatrio de teste QI.
6. Relatrio de Qualificao
A finalidade do Relatrio de Qualificao QI, confirmar que a estratgia tem sido implementada, tal
como definido no Plano de Qualificao (este documento) e que os resultados dos testes confirmam
que o sistema funciona como se pretende. As variaes relativas ao Plano de Qualificao, sero
documentadas, com a justificao, no Relatrio de Qualificao QI. A aceitao do relatrio de
Qualificao QI deve indicar que possvel continuar com a prxima fase do processo de validao,
de modo a poder ser iniciada a Qualificao Operacional QO.
Plano de Qualificao Operacional (QO) - MySAP ERP 2005, ECC 6.0
Sntese do Documento
Este documento descreve o plano para qualificar os principais componentes de hardware e software mySAP ERP.
Detalhes do Documento
Projecto MySAP ERP 2005
Status / Verso 1.0
Cdigo de Referncia BLUEP-QO

Contedo
1. SOBRE ESTE DOCUMENTO .......................................................................................... 3

1.1 FINALIDADE ................................................................................................................. 3
1.2 AUDINCIA................................................................................................................... 3
1.3 MBITO ....................................................................................................................... 3
2. INTRODUO ................................................................................................................. 4
3. MBITO DO TESTE ........................................................................................................ 4
4. ESTRATGIA DE TESTE ................................................................................................ 5

4.1 CONDIES PRVIAS DE TESTE ................................................................................... 5
4.2 PESSOAS ENVOLVIDAS NA EXECUO ........................................................................... 5
4.3 EXECUO DA QUALIFICAO ...................................................................................... 5
4.4 TESTES A EXECUTAR.................................................................................................... 5
4.4.1 Desvios ............................................................................................................... 6
4.4.2 Aceitao ............................................................................................................ 7
4.4.3 Estado da Qualificao ....................................................................................... 7
4.5 AMBIENTE UTILIZADO ................................................................................................... 7
4.6 TIPOS DE TESTE .......................................................................................................... 8
5. FUNES E RESPONSABILIDADES ............................................................................ 8
6. RELATRIO DE QUALIFICAO .................................................................................. 9
BLUEP-QO Pgina 2 de 9
1. Sobre este documento
1.1 Finalidade
O objectivo deste documento definir as actividades e responsabilidades para realizar a verificao

das especificaes definidas para o sistema de ERP: as novas especificaes para os mdulos
Warehouse Management e suas interfaces com RF e Controlo de Produo, os restantes mdulos
(MM, SD, FI, CO e QM) foram instalados e validados numa fase anterior, e sero verificados na
Qualificao de Performance. A segurana lgica e o processo para restaurar os dados tambm sero
includos neste processo de qualificao.
O objectivo dos testes fornecer provas documentais de que os testes de validao listados no Plano
de Validao tm sido executados correctamente.
O principal objectivo deste plano obter provas documentais que comprovem que:
As especificaes aprovadas devem ser verificadas com as funcionalidades do MySAP num

ambiente de teste.
A documentao operacional concluda.
Todos os potenciais desvios crticos encontrados durante a qualificao operacional devem ser
fechados antes de terminar o processo QO, e
Os critrios para a aceitao da fase QO sero aceites pela rea da Qualidade.

Este documento foi escrito de acordo com os critrios estabelecidos no Plano de Validao, e de
acordo com a Avaliao de Riscos.
1.2 Audincia
Este documento para uso das pessoas envolvidas na fase de testes da QO.
1.3 mbito
Este documento abrange os testes relacionados com as funcionalidades GMP dos mdulos:
WM incluindo as interfaces com os elementos RF,
PP-PI,
A segurana lgica,
O processo de restauro do sistema.
As funcionalidades para os outros mdulos GMP (MM, SD e QM) foram verificadas na validao
anterior (ver o captulo 6 - Plano de Validao e os seus documentos associados, e sero verificadas na
Qualificao de Performance).
Os mdulos FI, CO esto fora deste plano, pois estes mdulos no so relevantes em termos GMP
(eles no gerem dados que podem afectar a qualidade, identificao, segurana e caractersticas dos
produtos).
2. Introduo
Este plano de testes ser realizado em ambiente de teste, de acordo com processos e protocolos pr-
definidos.
O objectivo do plano de testes explicar a abordagem planeada para todas as actividades de teste de
um determinado projecto. Ele inclui informaes sobre o mbito de aplicao do teste, o tipo de teste e
o ambiente a ser utilizado para a realizao do teste.
A natureza exacta de um determinado plano de teste depender do sistema a ser testado.
O plano de testes deve ser aprovado antes de os testes poderem comear. As pessoas, que aprovam o
documento devem ser registadas na capa, pelo nome e funo. Normalmente, ser o Gestor de Projecto
e o Responsvel pela Garantia da Qualidade ou seu delegado.
3. mbito do Teste
Os scripts de Testes devem ser definidos para cada mdulo SAP, como indicado na seco 1.3 -
mbito de aplicao para os diferentes grupos de especificaes.
As especificaes devem ser verificadas contra a funcionalidade do MySAP para assegurar a

qualidade, solidez e segurana dos produtos acabados durante todas as operaes correspondentes aos
mdulos na seco 1.3 - mbito de aplicao.
4. Estratgia de Teste
4.1 Condies Prvias de Teste
Os seguintes documentos devem ser aprovados pela GQ antes de executar os scripts de teste de QI:
O Relatrio de Teste de QI,
O Plano de Teste de QO (este documento),
Os Scripts de Teste de QO.
4.2 Pessoas envolvidas na execuo
Deve identificar-se todos os utilizadores e os seus papis ou seja Executante, Revisor e Garantia de
Qualidade associados execuo do teste QO.
4.3 Execuo da Qualificao
A qualificao operacional (QO) dever ser realizada na sequncia deste documento, bem como as
instrues gerais da seco 5 - Planeamento de Teste no captulo 6 - Plano Mestre de Validao. Aps
todos os testes terem sido executados, deve ser escrito um relatrio de testes de QO como resumo do
processo QO. Esse relatrio deve mostrar que os critrios de aceitao foram atingidos e por isso que a
aplicao pode ser considerada aceite para ser introduzida em ambiente de produo de acordo com os
parmetros previstos.
4.4 Testes a executar
Os testes a executar devem ser usados para verificar as diferentes especificaes do sistema e ser
definido num apndice a este plano, em grupos de testes homogneos. Uma vez aprovados, os testes
realizados sero documentados nos Scripts de Teste.
Em cada Script de teste ser definido o objectivo principal, os critrios de admisso e os pr-requisitos
para a execuo do teste.
Cada especificao tcnica ser testada atravs de um teste. Cada teste (associado a cada
especificao) ser referenciado por uma nica ID de teste e ser traduzido em medidas de teste e
resultados esperados. Uma ou vrias etapas podem representar cada especificao.
Cada Script de teste deve ser referenciado com um nmero. A execuo dos testes ser feita numa
cpia controlada dos Script de Teste de QO aprovados.
As evidncias (provas), sero anexadas a algumas etapas com referncias cruzadas entre os scripts das
etapas e respectivas evidncias. As referncias das evidncias devem ser registadas em resultados
reais, juntamente com o veredicto do teste: Passou, No Passou (Falhou) ou No Aplicvel (N/A).
Para verificar se a funcionalidade da aplicao abrange as especificaes, os seguintes grupos de teste

devem ser executados:
Teste # Tipo Descrio
Teste 1: Verificar Precondies Identificar as datas de aprovao dos documentos necessrios

1.
de Teste para a execuo da QO.
A manuteno do mestre de dados indicado nas etapas descritas

nos quadros do teste deve ser adequado.
2. Teste 2: Verificar Funes
Gerais A lgica da segurana e da valorizao do processo tem de
cumprir os passos descritos no teste.
Os processos descritos neste ponto devem ser executados

Teste 3: Verificar Warehouse
3. correctamente (recibos, ordens de produo, locais, grupos,
Management
ordens de vendas, ...).
Tabela 1: Testes a ser executados
Cada etapa deve ser executada (com as excepes de instrues a seguir ou comentrios) e os
resultados esperados devem ser cumpridos para passar no teste. O executante deve assinar e datar cada
etapa. Aps analisar os Scripts de Teste executados e suas evidncias, o revisor deve assinar os grupos
de teste e dar a sua sentena: aceite ou rejeitado.
Os testes que devem ser novamente executados devem ficar com o prximo nmero de iterao e tal
deve ser includo no Resumo e Concluses dos Scripts de testes e no Relatrio de Qualificao.
4.4.1 Desvios
Conforme estabelecido no Plano Mestre de Validao, qualquer falha ocorrida durante os testes ser
identificada num Formulrio e Registo de Falhas de Teste. Cada etapa no script de teste ir
proporcionar um espao para incluir uma referncia ao Formulrio de Falhas de Teste. Este formulrio
dever incluir as medidas necessrias para corrigir o problema ou uma declarao justificando porque
a falha no afectar a libertao do sistema para produo.
As falhas de Teste sero categorizadas como:
Maior Tudo o que no coincide com os resultados esperados ou uma falha que
impede a concluso bem sucedida do teste, e que vai tornar o componente
no apto sem um maior desenvolvimento e novo teste.
Menor Uma falha registada que no impede a realizao do teste, e que no ir

impedir que o produto seja libertado. Isso tambm poder ser um incidente
que ocorre fora do controlo do executante/teste. Pode ser emitida uma
declarao com constrangimento.
(NB: Mltiplas falhas menores podem tambm impedir a libertao)
No testado O teste no pde ser concludo, e este item no foi testado.
Todas as falhas de teste sero gravadas num formulrio e registo de Falhas
4.4.2 Aceitao
Uma vez que o executante do teste tenha realizado um script de teste, o Revisor deve verificar a sua
execuo e respectivas evidncias, e deve assinar os grupos de teste e dar a sua sentena: aceite ou
rejeitado.
4.4.3 Estado da Qualificao
A manuteno da qualificao deve ser gerida aplicando o procedimento Gesto de Alteraes. Este
procedimento ser aplicado para cada alterao, modificao ou melhoria para estas plataformas
depois de iniciada a qualificao de instalao (ver esta seco no Plano QI).
4.5 Ambiente utilizado
Foi fornecida na qualificao de instalao uma descrio completa do ambiente de teste utilizado para
os testes. Os detalhes dos testes so definidos em pormenor nos Scripts de Teste QO.
4.6 Tipos de Teste
Os seguintes grupos de teste devem ser definidos nos Scripts de Teste QO:
Condies prvias de Teste
Funes Gerais
Gesto de Armazm
Controlo de produo
5. Funes e Responsabilidades
Funo Responsabilidades
SVS Elabora os scripts de teste. Realiza testes utilizando

scripts de teste. Garante que os scripts de teste e os
Formulrios de Falhas de Testes esto correctamente
preenchidos e assinados, produz Logs de Resoluo
de Teste e o relatrio de teste de QO.
Gestor de Projecto Assegura que os ambientes de teste esto disponveis

e controlados, garante que os scripts de teste so
produzidos, aprovados e executados, processa os
Formulrios de Falhas. Garante que os prazos de teste
so cumpridos.
URS (IT) Leva a cabo testes utilizando os scripts de teste.

Assegura que os scripts de teste so concludos
correctamente, e que qualquer formulrio de falhas
de Teste est correctamente preenchido.
Garantia de Qualidade Verifica a documentao formal, tal como acordado

com o Coordenador de Teste. Aprova o plano de teste
e scripts de teste, o Formulrio das Falhas de Teste e
o relatrio de teste QO.
6. Relatrio de Qualificao
A finalidade do Relatrio de Qualificao QO, confirmar que a estratgia tem sido implementada, tal
como definido no Plano de Qualificao (este documento) e que os resultados dos testes confirmam
que o sistema funciona como se pretende. As Variaes relativas ao Plano de Qualificao, devem ser
documentadas, com a justificao, no Relatrio de Qualificao QO. A aceitao do relatrio de
Qualificao QO indica que possvel continuar com a prxima fase do processo de validao, para
que a Qualificao de Performance QP possa ser iniciada.

Duarte Marques 2007100447 2009 RF PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Duarte Marques 2007100447 2009 RF PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Validao de Sistemas Informticos

Duarte Augusto Marques

Dissertao para obteno do Grau de Mestre em:

6.4. 1 Processo .................................................................................................... 47

Lista de quadros e figuras

Quadro 1 Categorias GAMP....................................................................................... 11

Figura 1 Sistema Informtico ..................................................................................... 10

1.1 Ambiente actual

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

Os benefcios de validar um sistema informtico so:

Os padres de qualidade so mantidos;

1.2 Leis e normas

2. mbito da Validao de Sistemas Informticos

Figura 1 Sistema Informtico

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

2.1 Software MySAP ERP 2005

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

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

Figura 2 Actividades desenvolvidas e respectiva documentao gerada para cada fase

Documentar na Justificao para o status

Documentar na Sumrio da resposta

Figura 3 Fluxograma de processos para avaliao de riscos

Mdulos SAP Implementao Documentos de validao existentes

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

3.4.1 Anlise Funcional

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

3.4.1.1. Avaliao do risco

3.4.1.2. Classe do Risco

Dois factores determinam a probabilidade de falha:

A tabela seguinte mostra como calculada a Classe de Risco:

Classe Classe Classe

Quadro 4 Classe de Risco

3.4.1.3. Nvel de risco

Detectabilidade, probabilidade de deteco da falha

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

Nvel Nvel Nvel

Nvel Nvel Nvel

Quadro 5 Nvel de Risco

3.4.1.4. Actividades de Validao

A prioridade de actividades de validao classificada como se segue:

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

Actividades Nvel de Risco

Nenhuma Considerar Validao

3.5 Mtodo Risk Failure Mode and Effects Analysis (RFMEA)

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

N Operaes SAP ANLISE FUNCIONAL ANLISE DE RISCO Actividades

N Operaes SAP ANLISE FUNCIONAL ANLISE DE RISCO Actividades

N Operaes SAP ANLISE FUNCIONAL ANLISE DE RISCO Actividades

N Processo/ ANLISE FUNCIONAL ANLISE DE RISCO Actividades de

Quadro 7 Representao de alguns dos processos analisados.

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

ndice de Risco (RPN)

91 3 Baixo 1 2 2 2 4 Nenhuma aco requerida

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

Valores do Risk Score II

Valores de ndice de Risco II (RPN)

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

Risk Score vs RPN

Figura 5 Risk Score versus RPN dos processos de falha

Risk Score vs RPN

Aces pouco prioritrias

4.1 Qualificao e Especificaes de Desenho

4.1.1 Especificao dos Requisitos do Utilizador (ERU)