2A+ Cosmética Portal de notícias
As regras de boas práticas de fabricação são claras e determinam a validação do sistema enquanto está sendo implementado, quando normalmente existe atenção da equipe de projeto e os esforços do time está focado na fase de implementação. Mas, e depois que o sistema é entregue para o usuário? E as mudanças? E os eventuais desvios? E a melhoria contínua? Pois bem, é aí que a maioria das empresas enfrentam tamanho desafio. Como manter o estado de validado dos vários sistemas na rotina dinâmica do dia-a-dia?
Controle de Mudanças
O primeiro passo para dar andamento em uma mudança é abrir o documento de Controle de Mudanças de acordo com o procedimento da empresa. Normalmente, as mudanças da área de Sistemas Computadorizados também são relatadas no POP (Procedimento Operacional Padrão) de CM (Controle de Mudanças), ou seja, pode não ser controlada por formulário de CM específico. De qualquer forma, o conteúdo deve descrever as ações a serem tomadas para execução da alteração ou correção do sistema após o término da Validação. A criticidade da mudança deve determinar a extensão e a verificação das atividades e documentações necessárias sempre baseada na Análise de Riscos e na complexidade da alteração a ser implementada.
O procedimento de Controle de Mudanças da empresa deve contemplar o gerenciamento e controle de todas as alterações relacionadas a sistemas computadorizados validados com o objetivo de assegurar que estes permaneçam neste estado.
As mudanças necessárias em um sistema computadorizado validado devem ser aprovadas por equipe multidisciplinar que envolva a Garantia de Qualidade. Em caso de mudanças emergenciais, estas devem ser registradas e, ainda assim, analisadas quanto ao seu impacto e aprovadas pela Garantia de Qualidade. Critérios para considerar casos emergenciais devem estar descritos no procedimento de controle de mudanças da empresa.
Testes de Regressão
O Testes de Regressão é uma técnica que consiste na aplicação de testes à versão mais recente do software, para garantir que não surgiram novos defeitos em componentes críticos já testados. Se surgirem novos defeitos em componentes inalterados, então considera-se que o sistema regrediu. Quando a mudança é aplicável para mais de um site/país que não é requerida para todas unidades, os testes de regressão também são importantes para verificar que não houve impacto nos demais sites.
Para desafio da nova versão do aplicativo devido à uma mudança, o Controle de Mudança deve prever Testes de Regressão e uma Análise de Riscos Funcional para definir o impacto nas funções críticas do sistema, e assim direcionar testes quando existe a possibilidade de impacto indireto em funções críticas “inalteradas”.
Normalmente, há muitas dúvidas no conteúdo destes testes. Uma boa estratégia é definir que os Testes de Regressão devem abranger todos os cenários de riscos classificados como “Alto” na Análise de Riscos realizada durante a validação, por serem os pontos mais frágeis no sistema. Assim, minimamente os testes referentes à própria mudança, adicionados aos Testes de Regressão poderão garantir a entrada da mudança em ambiente de produção com riscos altos sob controle, demonstrando robustez no processo, sem necessidade de repetir completamente a Qualificação de Operação do sistema cada vez que ocorre uma mudança no sistema (o que muitas vezes seria inviável no dia-a-dia).
CAB – Change Advisory Board
Para implementação e/ou melhoria do processo de gerenciamento das mudanças, recomenda-se que seja formada equipe que seja responsável por aprovar e gerenciar as mudanças, suportando análise de impacto e priorização. Normalmente faz parte da equipe: gestor da CAB, especialistas técnicos (Tecnologia da Informação e Tecnologia da Automação), usuários, Engenharia, Manutenção, Garantia da Qualidade e/ou Validação (GxP).
Os membros da CAB são responsáveis por entender as necessidades e impactos da mudança pelas perspectivas técnica, negócio e Qualidade. Reuniões rápidas semanais para tomadas de decisões são importantes (nem sempre presenciais). Os membros da CAB também são responsáveis por monitorar o processo de desenvolvimento, testes e aprovação de migração da mudança de um ambiente para outro.
O CAB deve analisar mudanças de perfis, funcionais, hardware, software, configurações, patches, atualizações, etc. É uma prática de ITIL (Information Technology Infrastructure Library) – conjunto de boas práticas para governança de TI. Dependendo do tamanho da empresa, algumas medidas de controle têm que ser implementadas para adequada gestão das mudanças que podem ser muito numerosas, tais como: a.) determinar regra de entrada da mudança no comitê somente após aprovação do custo e b.) utilizar um sistema para gestão das mudanças desde a solicitação da alteração até a confirmação do adequado funcionamento da mesma.
Sistemas para Controle de Mudanças no ERP SAP
Muitas empresas de Ciências da Vida utilizam a plataforma SAP como ERP (Enterprise Resource Planning). Faz parte do produto (incluído no custo das licenças), a plataforma ChaRM Solution que faz parte do software Solution Manager, produto SAP que auxilia no controle e gestão dos projetos de implementações e mudanças do produto principal, o ERP.
Muitos profissionais de validação de sistemas não tem a ciência que este software já está normalmente instalado na empresa, com o custo de licenciamento já absorvido pela companhia. É interessante ressaltar que a implementação do ChaRM se trata de um projeto à parte exigindo esforços de configuração para adequação dos processos de gerenciamento de mudanças da empresa e regras de BPF (Boas Práticas de Fabricação) aderente às indústrias de Ciências da Vida.
Revisão Periódica
Independentemente do tratamento das mudanças, periodicamente as validações dos sistemas devem ser revisadas. No geral, nesta área, evitamos o termo ‘revalidação’, e normalmente utilizamos a atividade de Revisão Periódica para proceder a verificação da atualização da validação do sistema para, ao fim desta tarefa, checar se o sistema continua com o status de validado. A revisão periódica de sistemas computadorizados deve ser realizada com o objetivo de garantir que possíveis mudanças de processo, de componentes do sistema ou de manutenções, por exemplo, não tenham impactado no seu estado de validado. Deve ser determinado um cronograma de revisões para todos os sistemas. A frequência de revisão das validações deve ser baseada na criticidade do sistema.
Não é produtivo estabelecer a mesma frequência de revisão periódica para todos os sistemas da empresa, visto que alguns deles são mais dinâmicos e mais instáveis que outros. É interessante utilizar abordagem da frequência variável para o mesmo sistema e mais interessante ainda, definir a primeira revisão periódica relativamente próximo ao término da validação do sistema (aproximadamente 6 meses), justamente para estudar a estabilidade pós implementação. Se esta primeira revisão periódica for conduzida sem intercorrências, sistema se mostrar estável, mudanças e administração de usuários e backups atualizados, a revisão periódica pode ser postergada para 1 ano e assim ter a frequência aumentada na próxima, dependendo do resultado deste último processo de revisão periódica.
A revisão deve levar em consideração vários aspectos, como:
Documentação de validação do sistema;
Documentação da revisão anterior;
Controles de mudanças emitidos;
Desvios ocorridos;
Procedimentos operacionais;
Controle de acesso ao sistema;
Execução correta do backup do sistema;
Status do sistema computadorizado (ex. espaço em disco, utilização RAM);
Status dos arquivos de histórico e trilhas de auditoria.
Caso seja encontrado algum problema no sistema, um plano de ação deve ser estabelecido.
Durante avaliação da documentação de validação, é importante dar especial atenção à Análise de Riscos Funcionais e verificar se os cenários de riscos, classificações e mitigações que foram necessários na ocasião da implementação ainda estão vigentes e se são necessários. Novos cenários de riscos podem surgir se mudanças não foram bem controladas. Neste caso, é necessário revisar a Análise de Riscos e assim prosseguir como se fosse uma ‘mini validação’ buscando novas mitigações (controles para baixar os novos riscos) e testes que comprovem que a validação está de acordo com o processo atual. O Relatório de Revisão Periódica não deve ser finalizado até que todas as pendências estejam sanadas.
Autores:
Silvia Martins, João Gomes, Frederico Quintão, João Monteiro e Felipe Fogaça – FIVE Consulting
