Professional Documents
Culture Documents
na Indstria Farmacutica
Duarte Augusto Marques
Jri
Presidente: Prof. Jos Lus Afonso
Orientador: Prof. Cristvo Silva
Vogal: Prof. Norberto Pires
Julho de 2009
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 radiofrequency 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
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
Hardware
Software
colocado em uso.
Pgina 10 de 72
funcionais,
especificaes
de
concepo,
validao
durante
Categoria
GAMP 3
GAMP 4
GAMP 5
Descrio
Pacote de software standard. Sem customizao.
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
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
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
Pgina 12 de 72
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
Risco para
GxP/Negcio
No
Documentar na
matriz da AR
Documentar o
risco na matriz de
AR
Descrio da funo e
relevncia GxP
probabilidade de risco
probabilidade de deteco
calculo do nvel de risco
Sim
Identificar os
cenrios de Risco
Avaliar a
probabilidade da
condio de falha
Avaliar a
Severidade de
Impacto
Avaliar o Nvel de
Risco
Avaliar a
probabilidade de
detectar a
condio de falha
Determinar as
aces a tomar
Documentar na
matriz de AR
Sumrio da resposta
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
Ano 2002:
- SAP R/3 4.6c
- Oracle 8i
- Interface de escalas de
Produo
Ano 2006:
- Upgrade para MySAP ERP
2005
- Upgrade para Oracle 10i
- Interface terminais RF
- Melhoramento de Hardware
e rede
WM, PM
Modificao dos
outros mdulos de
modo a integrar
WM e PM
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
GxP
Mdulo
Sim
Sim
Sim
Sim
Sim
Sim
No
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
2
3
Pgina 19 de 72
Impacto GxP
Classe de Risco
Baixo
Mdio
Alto
Alto
Mdio
Baixo
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
2
3
Pgina 20 de 72
Classe de Risco
Alto
Mdio
Baixo
Nvel
Nvel
Nvel
Mdio
Alto
Alto
Nvel
Nvel
Nvel
Baixo
Mdio
Alto
Nvel
Nvel
Nvel
Baixo
Baixo
Mdio
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
Impacto GxP
Alto
Nvel de Risco
Baixo
Considerar Validao
revalidao requerida
Nenhuma
Mdio aco
requerida
Baixo
Mdio
Nenhuma
aco
requerida
Alto
Validao
requerida
Considerar Validao
revalidao requerida
Nenhuma
aco
requerida
Nenhuma
aco
requerida
Pgina 22 de 72
Pgina 23 de 72
N Operaes SAP
Bluepharma
ANLISE FUNCIONAL
Descrio da funo, transaces relacionadas
Actividades
ANLISE DE RISCO
Dados ou Operaes
Impacto
Probabilidade
Probabilidade de
Nvel de
manipulados
GxP
de falha
deteco da falha
Risco
ndice
de Validao
de Risco
Contabiblidade
Baixo
Financeira
1 Mdio,
2 Mdio,
funcionalidade
funcionalidade
SAP standard
operacional desde
Baixo
Nenhuma aco
requerida
2002
Mdulo Controlling (CO)
2 CO
Contabiblidade de
Baixo
Custos
1 Mdio,
2 Mdio,
funcionalidade
funcionalidade
SAP standard
operacional desde
Baixo
Nenhuma aco
requerida
2002
Mdulo Materials Management (MM)
3 MM-Dados
XK01
Mestre
Rastreabilidade de
Alto
Fornecedor
Fornecedor
3 Baixo,
1 Alto,
funcionalidade
funcionalidade
validada
validada
Baixo
Considerar
revalidao
teste QP
para MM
4 MM-Fornecedor
ME61
Avaliao de Fornecedor
Homologao
Alto
Fornecedor
3 Baixo,
1 Alto,
funcionalidade
funcionalidade
validada
validada
Baixo
Considerar
revalidao
teste QP
para MM
N Operaes SAP
Bluepharma
5 MM-Ordens
ANLISE FUNCIONAL
Descrio da funo, transaces relacionadas
Impacto
Probabilidade
Probabilidade de
Nvel de
manipulados
GxP
de falha
deteco da falha
Risco
ME11
Rastreabilidade
de aquisio de
ME1E
de materiais
funcionalidade
funcionalidade
dados
adquiridos
validada
validada
ME21N/ME9F
6 MM-Gesto
Alto
3 Baixo,
1 Alto,
Baixo
ndice
de Validao
de Risco
3
Considerar
revalidao
teste QP
Ordens de compra
para MM
ME21N/ME51N
ME51
Processamento de
Gesto de
requisies de compra
requisies e
funcionalidade
funcionalidade
ME56
ordens de compra
SAP standard
operacional desde
teste QP
ME54
2002
para MM
ME21/ME25
de ordens de
encomenda
Actividades
ANLISE DE RISCO
Dados ou Operaes
ME28
ME18
MIRx
Processamento de facturas
Gesto de
Verificao de facturas
Facturas
Mdio
2 Mdio,
2 Mdio,
2 Mdio
Considerar
revalidao
Relatrios
7 MM-Gesto de
Facturas
Baixo
Libertao de pagamento de
1 Mdio,
funcionalidade
SAP standard
operacional desde
facturas
8 MM-Cotao
MEQx
2 Mdio,
funcionalidade
Baixo
Nenhuma aco
requerida
2002
Cotao de materiais
Baixo
1 Mdio,
2 Mdio,
funcionalidade
funcionalidade
SAP standard
operacional desde
Baixo
Nenhuma aco
requerida
2002
9 MM-Contratos de ME3x
Compra
Gesto
Baixo
1 Mdio,
2 Mdio,
de contractos de
funcionalidade
funcionalidade
compra
SAP standard
operacional desde
Baixo
Nenhuma aco
requerida
2002
Pgina 24 de 72
ANLISE FUNCIONAL
Actividades
ANLISE DE RISCO
Dados ou Operaes
manipulados
Impacto
GxP
Probabilidade
Probabilidade de
de falha
Baixo
Nvel de
deteco da falha
Tarefas de
1 Mdio,
manuteno
funcionalidade
funcionalidade
do processo standard
administrativa
SAP standard
operacional desde
Risco
2 Mdio,
ndice
de Validao
de Risco
Baixo
Nenhuma aco
requerida
2002
92 PM - Relatrios
93
Execuo de
controlo da
funcionalidade
funcionalidade
manuteno
Alto
3 Mdio,
SAP standard
no validada
Baixo
2 Baixo,
CONTROLO DE CUSTOS
dos recursos de
1 Mdio,
funcionalidade
funcionalidade
manuteno
SAP standard
no validada
Alto
18
Validao
requerida
2 Baixo,
Mdio
Nenhuma aco
requerida
Controlo de acesso
Alto
3 Mdio,
2 Mdio,
Acesso dos
de dados GMP e
funcionalidade
funcionalidade
Utilizadores
operaes GMP
SAP standard
operacional desde
geridas a partir do
Alto
12
Teste QP
requerido
2002
SAP R / 3
95 Backup & Restore
Backup e restore
Alto
3 Alto,
3 Mdio,
Alto
18
Teste de QP
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
Controlo de
Configuraes
3 Baixo,
Alteraes
N Processo/
Problema
Alto
1 Baixo,
um controlo de
alteraes foi
de alteraes
aprovado para
foi reportado
a empresa
ANLISE FUNCIONAL
Descrio da funo, transaces relacionadas
Alto
requerido
Actividades de
ANLISE DE RISCO
Consequncias
Impacto
Probabilidade
GxP
Probabilidade de
de falha
Teste QI
nenhum controlo
Nvel de
deteco da falha
Risco
ndice
Validao
de Risco
Erweka
102 QM046 - Interface
com o Erweka
A carga de trabalho e o
Baixo
Mdio
Alto
Baixo
Nenhuma aco
requerida
de resultados manualmente
Falhas de Hardware
103 Servidor
Todas as actividades do
sistema cessam.
Realizao manual de
Alto
Alto
Alto
Mdio
Validao
requerida
Todas as actividades do
sistema cessam.
pelos utilizadores
Realizao manual de
Alto
Mdio
Alto
Mdio
Validao
requerida
Pgina 25 de 72
2
2
2
2
2
2
2
3
2
3
3
2
2
2
3
2
3
2
3
2
3
1
1
1
1
1
2
3
3
3
3
3
2
3
1
1
1
1
2
3
Baixo
Baixo
Baixo
Baixo
Baixo
Baixo
Baixo
Baixo
Baixo
Baixo
Baixo
Baixo
Baixo
Baixo
Baixo
Baixo
Baixo
Baixo
Baixo
Baixo
Alto
Alto
Alto
Alto
Alto
Alto
Alto
Mdio
Mdio
Mdio
Mdio
Mdio
Alto
Mdio
Alto
Alto
Alto
Alto
Baixo
Baixo
3
3
3
3
3
3
3
2
3
2
2
3
3
3
2
3
2
3
2
3
4
6
6
6
6
6
4
2
2
2
2
2
4
2
6
6
9
6
3
2
1
1
1
1
1
1
1
2
1
2
2
1
1
1
2
1
2
1
2
1
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
1
2
Nvel do
Risco
Detectabilidade da Falha
Classe do
Risco
Risk Score
Impacto GxP
ID da Falha
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
Probabilidade de Falha
Actividade de Validao
3
3
3
3
3
3
3
4
3
4
4
3
3
3
4
3
4
3
4
3
12
18
18
18
18
18
12
6
6
6
6
6
12
6
18
18
27
18
3
4
Considerar revalidao
Considerar revalidao
Considerar revalidao
Considerar revalidao
Considerar revalidao
Considerar revalidao
Considerar revalidao
Nenhuma aco requerida
Considerar revalidao
Nenhuma aco requerida
Nenhuma aco requerida
Considerar revalidao
Considerar revalidao
Considerar revalidao
Nenhuma aco requerida
Considerar revalidao
Nenhuma aco requerida
Considerar revalidao
Nenhuma aco requerida
Considerar revalidao
Validao requerida
Validao requerida
Validao requerida
Validao requerida
Validao requerida
Validao requerida
Validao requerida
Nenhuma aco requerida
Nenhuma aco requerida
Nenhuma aco requerida
Nenhuma aco requerida
Nenhuma aco requerida
Validao requerida
Nenhuma aco requerida
Validao requerida
Validao requerida
Validao requerida
Validao requerida
Considerar revalidao
Nenhuma aco requerida
Pgina 26 de 72
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
3
1
3
1
1
2
1
1
3
3
3
3
1
1
1
1
3
3
1
1
3
3
Baixo
Alto
Mdio
Alto
Alto
Alto
Mdio
Mdio
Baixo
Baixo
Baixo
Baixo
Mdio
Mdio
Mdio
Mdio
Baixo
Baixo
Alto
Alto
Baixo
Baixo
2
6
2
6
9
3
6
6
1
2
2
2
9
6
9
9
2
2
9
9
2
2
2
3
3
2
2
3
1
1
2
1
1
1
1
1
1
1
1
1
2
2
1
1
4
18
6
12
18
9
6
6
2
2
2
2
9
6
9
9
2
2
18
18
2
2
Pgina 27 de 72
99
10
1
10
3
10
5
10
7
99
10
1
10
3
11
97
97
10
95
95
93
91
89
87
85
83
81
79
77
75
73
71
69
67
65
63
61
59
57
55
53
10
9
8
7
6
5
4
3
2
1
0
51
Risk Score
ID da Falha
30
25
20
15
10
5
1
11
9
10
10
10
93
91
89
87
85
83
81
79
77
75
73
71
69
67
65
63
61
59
57
55
53
51
ID da Falha
Figura 4 Grficos Pareto do Risk Score (em cima) e RPN (em baixo) para os processos de 51 a 112
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.
25
RPN
20
6; 18
9; 18
15
4; 12
10
3; 9
2; 6
2; 4
2; 2
5
1; 2
0
0
6; 12
9; 9
4; 8
6; 6
3; 3
4
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.
25
RPN
20
6; 18
9; 18
15
6; 12
4; 12
10
3; 9
2; 6
2; 4
2; 2
5
1; 2
0
0
9; 9
4; 8
6; 6
3; 3
4
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.
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
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
Pgina 33 de 72
Pgina 34 de 72
Risco do
Fornecedor
Quadro 10.
Baixo
Mdio
Alto
Alto
Mdio
Baixo
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
Pgina 36 de 72
Pgina 37 de 72
Alto
risco
Mdio
risco
Baixo
risco
Teste de
funes
crticas.
Link de testes
de requisitos.
Teste de
funes
crticas.
GAMP 4
GAMP 5
No necessita
Teste padro crtico
testes
Pgina 38 de 72
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
Pgina 41 de 72
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
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.
Pgina 45 de 72
HEWLETT
PACKARD
HEWLETT
PACKARD
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
Teste Funcional, Teste s Unidades e
de Aceitao do utilizador
Teste do Sistema
Sistema Produtivo
Operao real
Qualificao de Performance
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. 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
Projecto
Resultado
Descrio do Resultado
Identificao do
Resultado
Requisitos
Requisitos Especficos
Especificao de
Requisitos
Fase de Risco
Avaliao de Riscos
AR SAP
Fase de
Planeamento
Plano de Validao
Qualificao da
Instalao
Plano de Teste
Plano de Testes QI
BLUEP-QI (em
anexo)
Scripts de Teste
Relatrio de Teste
Plano de Teste
Plano de Testes QO
BLUEP-QO (em
anexo)
Scripts de Teste
Relatrio de Teste
Plano de Teste
Scripts de Teste
Relatrio de Testes
Matriz de Rastreabilidade
Relatrio de Validao
Qualificao
Operacional
Qualificao de
Performance
Lanamento
Relatrio de Validao
- BLUEP-RV (a ser
gerado)
Pgina 48 de 72
Pgina 49 de 72
Qualificao de Performance (QP), em ambiente de Produo para mdulos GxP (MM, SD, PPPI, 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.
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.
Menor
No 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.8 Formao
Todo o pessoal associado com a administrao e utilizao para produo do sistema deve ser
devidamente
treinado
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.
Pgina 52 de 72
Pgina 53 de 72
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.
Pgina 55 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
Pgina 58 de 72
Pgina 59 de 72
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.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
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
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.
8.10.4
Testes de Esforo
8.10.5
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.
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
Pgina 66 de 72
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
8.11.2
Aprovao da documentao
Ttulo
Investigao e tratamento de erros ocorridos nos sistemas Informticos
Imp.(NG-21-002)-01A Ocorrncia de erros nos sistemas informticos
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.
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
FDA, Guidance for Industry: General Principles of Software Validation. Draft Guidance,
Version 1.1. June 9, 1997.
ii
iii
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
vii
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
www.fda.gov
www.ispe.org
www.labcompliance.com
www.mhra.gov.uk
www.pda.org
www.phrmafoundation.org
www.picscheme.org
www.psiweb.org
11. Anexos
Descrio do Documento
Referncia do Documento
BLUEP QI
BLUEP QO
Pgina 72 de 72
Sntese do Documento
Este documento descreve o plano para qualificar os principais componentes de hardware e software do MySAP ERP.
Detalhes do Documento
Projecto
Status / Verso
1.0
Cdigo de Referncia
BLUEP-QI
Contedo
1.
FINALIDADE ................................................................................................................. 3
1.2
AUDINCIA................................................................................................................... 3
1.3
MBITO ....................................................................................................................... 3
2.
INTRODUO ................................................................................................................. 4
3.
4.
4.2
4.3
4.4
TESTES A EXECUTAR.................................................................................................... 6
4.4.1
Desvios ............................................................................................................... 8
4.4.2
Aceitao ............................................................................................................ 8
4.4.3
4.5
4.6
5.
6.
BLUEP-QI
Pgina 2 de 10
1.
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
BLUEP-QI
Pgina 3 de 10
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.
BLUEP-QI
Pgina 4 de 10
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:
BLUEP-QI
Pgina 5 de 10
4.
Estratgia de Teste
BLUEP-QI
Pgina 6 de 10
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 #
1.
Tipo
Descrio
Teste 1: Verificar os
documentos aprovados
2.
3.
4.
5.
6.
7.
SAP
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.
BLUEP-QI
Pgina 7 de 10
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:
Tudo o que no coincide com os resultados esperados ou uma falha que
Maior
Menor
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
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 (NP07-04). Este procedimento ser aplicado para cada alterao, modificao ou melhoria para essas
plataformas depois de iniciar a qualificao de instalao.
BLUEP-QI
Pgina 8 de 10
BLUEP-QI
Pgina 9 de 10
5.
Funes e Responsabilidades
Funo
Responsabilidades
SVS
Gestor do Projecto
URS (IT)
Garantia de Qualidade
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.
BLUEP-QI
Pgina 10 de 10
Sntese do Documento
Este documento descreve o plano para qualificar os principais componentes de hardware e software mySAP ERP.
Detalhes do Documento
Projecto
Status / Verso
1.0
Cdigo de Referncia
BLUEP-QO
Contedo
1.
FINALIDADE ................................................................................................................. 3
1.2
AUDINCIA................................................................................................................... 3
1.3
MBITO ....................................................................................................................... 3
2.
INTRODUO ................................................................................................................. 4
3.
4.
4.2
4.3
4.4
TESTES A EXECUTAR.................................................................................................... 5
4.4.1
Desvios ............................................................................................................... 6
4.4.2
Aceitao ............................................................................................................ 7
4.4.3
4.5
4.6
5.
6.
BLUEP-QO
Pgina 2 de 9
1.
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,
BLUEP-QO
Pgina 3 de 9
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 prdefinidos.
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.
BLUEP-QO
Pgina 4 de 9
4.
Estratgia de Teste
BLUEP-QO
Pgina 5 de 9
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 #
1.
Tipo
Descrio
2.
3.
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.
BLUEP-QO
Pgina 6 de 9
Maior
Menor
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
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).
BLUEP-QO
Pgina 7 de 9
5.
Funes e Responsabilidades
Funo
Responsabilidades
SVS
Gestor de Projecto
URS (IT)
Garantia de Qualidade
BLUEP-QO
Pgina 8 de 9
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.
BLUEP-QO
Pgina 9 de 9