MP Saf 005
MP Saf 005
MP Saf 005
1.1.1.1. Responsabilidades
1.1.1.1.1. Desenvolvedores
• Indicar aos coordenadores e gerentes de possíveis atividades com
impactos a segurança ocupacional que não tenham gerenciamento de risco
operacional prévio;
• Desenvolver as análises preliminares de risco de forma técnica,
independente, seguindo a metodologia descrita neste capítulo;
• Utilizar, e se necessário, fomentar a lista de consequências deste manual;
• Classificar os índices de risco conforme as diretrizes e matriz de risco
apontadas neste capítulo;
• Apontar corretamente os responsáveis e os prazos pelas mitigações
propostas;
• Monitorar e acompanhar a implementação de mitigações;
• Reavaliar as informações periodicamente, conforme indicado neste manual;
• Monitorar periodicamente o painel de erros no processo do módulo de risco
e realizar as correções, caso necessário.
(NR):
a. NR 12 - Segurança no Trabalho em Máquinas e Equipamentos
b. NR 20 - Segurança e Saúde no Trabalho com Inflamáveis e Combustíveis
c. NR 33 - Segurança e Saúde no Trabalho em Espaços Confinados
d. NR 35 - Trabalho em Altura
1.1.1.4. Processo decisório para realização de uma análise preliminar de risco não
requerida por legislação
1.1.1.8. Perigo
1.1.1.9. Consequências
• Queda
XXXX
• Queda de objetos
XXXX
• Esmagamento
XXXX
• Sufocamento
XXXX
• Queimadura
XXXX
• XXXX
XXXX
• XXXX
XXXX
• Outros
Caso a consequência identificada não se englobe em nenhuma das
categorias elencadas acima, então esta pode ser utilizada de forma livre
ficando categorizada como “Outros”.
• Índice de risco atual: O índice de risco atual deve ser a análise hipotética
da probabilidade e severidade de uma consequência considerando
apenas as barreiras de mitigação atualmente implementadas, ou seja, o
status quo das operações.
a. Probabilidade
A probabilidade é definida como a possibilidade que uma consequência ou
resultado possa a vir acontecer. Para aprimorar a classificação da
probabilidade do risco ocupacional, as perguntas listadas abaixo auxiliarão
a identificar de forma mais assertiva.
• Existe histórico de ocorrências similares a que está sob consideração
ou somente em casos isolados?
• Quais outros equipamentos ou componentes do mesmo tipo podem
ter preocupações similares?
• Quantos funcionários estão seguindo ou estão sujeitados ao
procedimento ou atividade em questão?
• Qual é a exposição ao perigo em consideração? (Ex: Qual a
porcentagem de tempo que o equipamento ou atividade está em uso
durante a operação?)
• O quão efetivo são as barreiras atualmente implementadas?
• O ambiente operacional da Azul pode favorecer a consequência?
• Condições do ambiente podem impactar a probabilidade?
• Novos trabalhadores, recém treinados, podem impactar a
probabilidade?
b. Severidade
A severidade é definida como a extensão de prejuízos materiais e
humanos que podem, possivelmente, ocorrer como consequência de
algum perigo identificado. A severidade é mais simples de ser classificada
baseada nos critérios da matriz, porém algumas perguntas podem ser
reutilizadas.
• Quantos funcionários estão seguindo ou estão sujeitados ao
procedimento ou atividade em questão?
• O quão efetivo são as barreiras atualmente implementadas?
• O ambiente operacional da Azul pode ampliar a consequência?
• Condições do ambiente podem ampliar a severidade?
• Novos trabalhadores, recém treinados, podem ampliar a severidade?
A reavaliações das APR’s serão feitas após 1 ano de sua publicação, durante
este processo é decidido se uma nova reavaliação deve ser realizada no
futuro e quando, ou, se a análise será fechada e o monitoramento irá
continuar por meio dos programas implementados pela DQS (Reportes,
LOSA, FOQA, etc). Após a publicação da análise, o desenvolvedor deve
marcar uma reunião 1 ano à frente da data de publicação, com as
coordenações da DQS envolvidas, para realização da reavaliação, para cada
revisão publicada.
O acompanhamento das mitigações abertas continua independentemente do
processo de revisão. A reavaliação de uma ARO será estendida caso ocorra
mudanças no cenário operacional baseado no julgamento das pessoas
responsáveis pela revisão, podendo ser estendido por mais 3 meses, 6 meses
ou 1 ano.
Para que seja possível gerenciar o risco dentro do módulo de risco o sistema
funciona com cinco caracterizações de utilização: os perigos, riscos, barreiras,
ações e a análise de risco. Todos estes recebem um ID quando são criados
no módulo de risco, sendo “Rx-xx” para riscos, “Hx-xx” para perigos, “Bxx”
para barreiras e “xx/APR/xx” para análises de risco operacional. Estes estarão
demonstrados no cabeçalho de cada item.
O módulo de risco não foi criado com um fluxo de trabalho ajustado para
gestão de mudança como utilizamos no desenvolvimento de análises de risco
operacional. Desta maneira se faz necessário indicar para o sistema quais IDs
estão relacionados a cada análise, se não, ficam "soltos" dentro do sistema.
Para que o sistema possa identificar quais perigos, riscos, barreiras e ações
Glossário Voltar para o índice
21/03/2023 Revisão: 03 MP-MSO-15
DOCUMENTO NÃO CONTROLADO QUANDO IMPRESSO OU OBTIDO COMO CÓPIA ELETRÔNICA. VERIFIQUE O AD-DOCS PARA A VERSÃO ATUALIZADA.
Manual de Processos
MANUAL DE PROCESSOS DE SEGURANÇA OPERACIONAL
Capítulo 1: Gerência de Segurança Operacional
Seção:
A análise se inicia por meio da criação dos perigos, por conseguinte a criação
dos riscos, ambos estes ID’s no sistema devem ser criados a cada realização
de uma análise, portanto são chamados de “ID’s únicos”. Consequentemente
o próximo passo é elencar as barreiras, não as criar, pois estas são
consideradas “ID’s reutilizáveis” no sistema, desta forma, devem ser
reutilizados em cada análise. Apenas deve-se criar uma barreira caso esta não
exista previamente no sistema, portanto se faz de grande importância a
verificação das barreiras existentes antes da criação de uma nova afim de
evitar a criação e utilização de duas barreiras iguais.
O gerente patrocinador das análises deve ser sempre o facilitador que dentro da
Azul está responsável pela atividade / mudança / operação a ser analisada. O
departamento deve ser o departamento responsável pela execução da análise.
Nenhuma pessoa de fora de diretoria de qualidade e segurança deve estar
incluída na análise, salvo na função de observer. Os setores fora da DQS
envolvidos devem estar elencadas no campo de texto livre “partes
interessadas”, já entidades terceiras que eventualmente fizeram parte do
desenvolvimento da análise devem estar elencadas no campo “outras pessoas
presentes”. É estritamente proibido associar ocorrências nas análises de risco.
O perigo deve ser cadastrado a cada análise, mesmo que já tenho sido
cadastrado no sistema anteriormente durante a execução de outras análises,
pois este é um ID único, como previamente apontado.
O risco deve ser cadastrado a cada análise, mesmo que já tenho sido
cadastrado no sistema anteriormente durante a execução de outras análises,
pois este é um ID único, como previamente apontado. Obrigatoriamente o risk
owner deve estar apontado seguindo o descrito no capítulo X.X.X.X. No módulo,
o ID de risco deve sempre estar no estágio de workflow como aprovado, com
a aprovação pelo risk owner responsável em anexo, caso a aprovação não
tenha sido feita dentro do AQD.
Na avaliação de risco, o campo “probabilidade” indicado por um símbolo de
porcentagem, deve ser preenchido somente se tivermos um cálculo
probabilístico realizado por uma entidade fidedigna como o desenvolvedor de
um sistema ou órgão regulador. A classificação do índice de risco sempre
deve conter as consequências qualitativas indicando qual critério de
severidade foi utilizado para chegar naquela classificação de índice de risco.
As ações devem ser criadas especificamente para cada risco, mesmo que
uma mesma ação mitigue mais de um risco, pois o sistema não permite
vincular ações a diferentes riscos. As mitigações advindas de uma análise de
risco operacional dentro do módulo podem ter 2 tipos:
Caso sejam endereçadas ações para pessoas externas à Azul, a ação deve
ser vinculada ao desenvolvedor da análise e o campo contato deve apontar o
maior número possível de contatos da pessoa em que a ação será
direcionada, ficando de responsabilidade do desenvolvedor encaminhá-la para
o responsável pela execução fora da Azul e atualizá-la caso sejam recebidas
as evidências de implementação, ou não.