Management of Change (MOC): gestão de mudanças e riscos

Entenda Management of Change, replacement in kind, mudanças temporárias, análise de riscos, MOC em SIS e automação, PSSR, documentação e governança.

Confira!

Management of Change — MOC é o processo formal usado para identificar, avaliar, autorizar, implementar e encerrar mudanças capazes de alterar perigos, riscos, barreiras de proteção ou condições operacionais de uma instalação. Em Segurança de Processo, o MOC existe para impedir que uma modificação aparentemente simples — um novo setpoint, uma substituição de equipamento, uma alteração de matéria-prima, uma revisão de lógica ou uma condição temporária — invalide silenciosamente premissas técnicas que sustentam a operação segura.

Um MOC eficaz não é apenas um formulário de aprovação. Ele conecta a base técnica da mudança à análise de riscos, documentação, treinamento, testes, prontidão para partida e encerramento. A mudança só é considerada concluída quando os impactos foram tratados e a configuração real da instalação voltou a estar representada nos documentos, procedimentos e sistemas de gestão aplicáveis.

O que é Management of Change

Management of Change pode ser entendido como uma disciplina de governança aplicada à mudança técnica e operacional. Seu objetivo é responder, antes da implementação, se a alteração modifica o risco e quais controles precisam ser atualizados para que a instalação continue operando dentro de condições conhecidas e autorizadas.

A OSHA 29 CFR 1910.119, uma das referências internacionais mais utilizadas em Process Safety Management, exige procedimentos escritos para gerenciar mudanças em produtos químicos de processo, tecnologia, equipamentos, procedimentos e instalações que afetem processos cobertos, excetuando replacements in kind. O requisito também determina avaliação da base técnica, impactos de segurança e saúde, alterações em procedimentos, prazo e autorizações antes da mudança.

No Brasil, esse requisito não deve ser apresentado como obrigação legal automática para toda instalação. A OSHA é uma referência técnica estrangeira. A aplicabilidade regulatória brasileira deve ser analisada segundo as NRs, legislação e requisitos setoriais pertinentes. Ainda assim, o princípio de controlar tecnicamente mudanças é plenamente compatível com boa prática de engenharia e com a necessidade de manter análises de risco, procedimentos e documentação coerentes com a instalação real.

Lógica básica para decidir se uma alteração deve entrar no processo de MOC

Por que mudanças são uma fonte relevante de risco

Grande parte das instalações industriais evolui continuamente. A produção aumenta, campanhas mudam, fornecedores descontinuam componentes, novos produtos são introduzidos, automação é modernizada, linhas são desviadas, equipamentos recebem upgrades e procedimentos são adaptados para responder a necessidades operacionais.

Cada mudança pode parecer local, mas seus efeitos podem atravessar várias disciplinas. A substituição de uma válvula pode alterar tempo de fechamento; uma nova bomba pode mudar pressão de shutoff; um novo setpoint pode reduzir margem operacional; uma modificação de software pode alterar uma sequência de intertravamento; uma nova matéria-prima pode introduzir incompatibilidade química.

O risco surge quando a organização gerencia a execução física, mas não reavalia as premissas. É por isso que MOC é um elemento central do framework de Risk-Based Process Safety do CCPS.

O que deve acionar um MOC

Um programa maduro precisa de critérios claros para reconhecer mudanças. Sem essa definição, cada área decide informalmente o que considera significativo e alterações importantes escapam do processo.

Exemplos típicos de gatilhos incluem:

mudança de matéria-prima, composição, concentração ou fornecedor quando características relevantes podem variar;
alteração de temperatura, pressão, vazão, nível, inventário ou capacidade;
troca de material de construção, classe de pressão ou especificação de equipamento;
alteração de rota de tubulação ou conexão de processo;
modificação de PLC, DCS, SIS, software, lógica, permissivo, intertravamento ou alarme;
mudança de setpoint, tempo de atraso ou estratégia de controle;
alteração de procedimentos de partida, parada, emergência ou manutenção;
instalação temporária de bypass, mangueira, jumper, linha provisória ou equipamento alugado;
substituição por componente que não seja tecnicamente equivalente;
mudança de layout que afete acesso, ventilação, drenagem, segregação ou resposta a emergências;
alteração de condições de utilidades ou infraestrutura crítica;
mudança organizacional que afete responsabilidades essenciais de Segurança de Processo.

A lista não substitui julgamento técnico. O objetivo é criar gatilhos suficientemente claros para que a dúvida seja encaminhada à avaliação, em vez de resolvida informalmente.

Replacement in kind: quando uma troca não é mudança

Replacement in kind é uma substituição que preserva especificação, função, desempenho, materiais, interfaces e demais características relevantes para o risco. O conceito não significa simplesmente “colocar outro equipamento no mesmo lugar”.

Se uma válvula antiga é substituída por modelo diferente, é preciso verificar Cv, classe, material, tempo de atuação, fail position, certificações, acessórios e comportamento dinâmico. Se qualquer característica relevante mudar, a substituição deixa de ser claramente in kind.

O mesmo vale para instrumentos e componentes de automação. Um transmissor de nova geração pode possuir faixa, tempo de resposta, diagnóstico, protocolo ou comportamento de falha diferentes. A equivalência precisa ser técnica, não apenas comercial.

A OSHA Appendix C reforça essa lógica ao diferenciar replacements in kind de mudanças em processo, equipamento, instrumentação e condições de operação.

MOC temporário também precisa de governança

Mudanças temporárias são particularmente perigosas porque frequentemente nascem de uma urgência: equipamento indisponível, parada parcial, falha de componente, necessidade de produção ou contingência. O caráter provisório cria a percepção de que a mudança pode receber menos rigor.

Na prática, uma condição temporária pode permanecer meses ou anos. Por isso, o MOC deve registrar validade, responsável, condições de operação, compensações de risco, inspeções, prazo de reversão e critérios para extensão.

Bypasses, overrides e inibições em sistemas de proteção exigem atenção especial. O período em que uma barreira está indisponível deve ser gerenciado com controles compensatórios e autorização proporcional ao risco.

Mudanças emergenciais

Emergência não elimina a necessidade de análise; ela altera o fluxo. Um procedimento de emergency MOC pode prever aprovação simplificada e avaliação rápida, mas precisa preservar os elementos críticos: justificativa, risco, responsáveis, condição temporária, comunicação e revisão posterior.

Após a estabilização, a mudança deve ser regularizada ou revertida. O maior erro é transformar uma exceção emergencial em condição permanente sem completar a engenharia, documentação e aprovação necessárias.

Como funciona o fluxo de MOC

Quando mudanças acontecem por e-mail, conversa de campo ou aprovação informal, o problema não é falta de formulário: é ausência de governança técnica capaz de conectar decisão, risco, documentação e aceite.

Conheça a Consultoria Técnica de Engenharia

O processo deve começar com uma solicitação suficientemente clara. A proposta precisa explicar o problema, a condição atual, a condição desejada e a base técnica da mudança. Solicitações vagas dificultam identificar interfaces e riscos.

Em seguida ocorre a classificação. A organização determina se a alteração é in kind, temporária, permanente, emergencial ou de outra categoria interna e define o nível de avaliação proporcional à criticidade.

A análise técnica identifica documentos, disciplinas, sistemas e barreiras afetados. Dependendo do caso, pode ser necessária revisão de HAZOP, LOPA, SIL, classificação de áreas, alívio, hidráulica, integridade, elétrica, cibersegurança ou outros estudos.

Depois das aprovações, a mudança é detalhada, adquirida e implementada. Antes da entrada em serviço, devem ser concluídos os testes, atualizações documentais, treinamento e PSSR quando aplicável. O fechamento confirma que todas as ações foram concluídas ou formalmente tratadas.

Fluxo de governança de uma mudança técnica em ambiente industrial

Base técnica da mudança

Toda MOC precisa de uma razão técnica compreensível. “Melhorar processo” ou “trocar equipamento” são justificativas insuficientes. A base deve registrar o problema, premissas, dados utilizados, alternativas avaliadas e limites da solução.

Esse registro é importante porque futuras equipes precisam entender por que a mudança foi feita. Sem contexto, decisões podem ser revertidas anos depois sem perceber que determinado detalhe existia para controlar um risco específico.

A base técnica também reduz decisões puramente comerciais. Uma substituição de fornecedor pode ser vantajosa em preço e prazo, mas precisa preservar os requisitos de engenharia que originaram a especificação.

Análise de riscos dentro do MOC

Uma mudança só deve avançar depois que seus impactos sobre cenários, barreiras e condições temporárias forem compreendidos e registrados com rigor proporcional à criticidade.

Veja o Gerenciamento de Riscos de Engenharia

Nem toda mudança exige um HAZOP completo. O nível de análise deve ser proporcional ao impacto potencial. Mudanças simples podem ser avaliadas por checklist técnico e revisão multidisciplinar; alterações significativas podem exigir HAZID, HAZOP, What-If, LOPA ou estudos especializados.

A decisão sobre a técnica deve considerar natureza da alteração, consequências potenciais, novidade, complexidade, interações com barreiras e qualidade das informações disponíveis.

Quando a mudança afeta um cenário já analisado, a equipe precisa verificar se causas, frequências, consequências ou salvaguardas foram alteradas. Uma revisão de LOPA pode ser necessária se o desempenho de uma IPL mudar.

A análise também deve identificar novos cenários criados pela própria transição, como riscos durante cutover, operação em paralelo, testes ou retorno à configuração original.

MOC e HAZOP

O HAZOP fornece uma base valiosa para MOC porque registra desvios, causas, consequências e salvaguardas. Quando uma alteração modifica um nó ou premissa relevante, o estudo precisa ser revisitado.

Não é necessário reexecutar integralmente o HAZOP para qualquer alteração. O importante é determinar o impacto sobre os nós e cenários afetados e registrar a decisão.

Em projetos de grande porte, uma matriz de rastreabilidade pode conectar MOC a recomendações de HAZOP, LOPA e documentos de engenharia.

MOC e SIL

Mudanças em sensores, logic solver, elementos finais, intervalos de teste, arquitetura, setpoints, tempos de resposta ou independência podem afetar o desempenho de uma SIF. Por isso, o MOC deve avaliar impacto sobre o SIL requerido e verificado.

Uma troca de válvula de shutdown por modelo com comportamento diferente, por exemplo, pode modificar PFDavg, tempo de atuação e cobertura de proof test. Uma alteração aparentemente de manutenção pode exigir nova verificação.

A regra prática é preservar a rastreabilidade entre cenário, SRS, arquitetura instalada, dados de confiabilidade e testes periódicos.

MOC em Sistemas Instrumentados de Segurança

A IEC 61511-1 incorporou requisito explícito de management of change em sua segunda edição. O ciclo de Segurança Funcional precisa controlar modificações realizadas durante operação e manutenção do SIS.

No SIS, mudanças de aplicação, hardware, instrumentos, lógica, interfaces e procedimentos podem afetar funções críticas. O MOC deve assegurar avaliação, autorização, verificação e atualização de documentação antes do retorno ao serviço.

A existência de software torna o controle de versão e configuração especialmente importante. Uma alteração pequena em código pode atingir múltiplas funções se bibliotecas, blocos compartilhados ou variáveis comuns estiverem envolvidos.

Setpoints, alarmes e intertravamentos

Setpoints são um dos exemplos clássicos de mudança subestimada. Alterar um limite de alarme ou trip pode reduzir margem entre operação e condição perigosa, modificar tempo disponível para resposta ou criar interação com outra proteção.

O MOC deve exigir base técnica para alterações de setpoint e verificar consistência com causa e efeito, filosofia de alarmes, SRS, procedimentos e telas de operação.

Intertravamentos e permissivos também não devem ser desabilitados informalmente para facilitar manutenção ou produção. Bypass precisa de controle próprio, prazo e compensações.

Mudanças em BPCS, SCADA e redes OT

Sistemas de automação industrial evoluem por atualizações de firmware, servidores, switches, controladores, virtualização, integração com sistemas corporativos e novas funções analíticas. Essas mudanças podem afetar disponibilidade, latência, redundância, segurança e independência.

A gestão precisa incluir backup, rollback, compatibilidade, testes, cybersecurity e plano de cutover. Quando interfaces com SIS ou barreiras críticas existem, a revisão precisa ser multidisciplinar.

Mudanças de rede também podem alterar caminhos de comunicação, sincronização de tempo e capacidade de diagnóstico. Não devem ser tratadas apenas como atividade de TI.

Mudanças de processo e capacidade

Aumento de produção é uma das mudanças mais comuns em plantas existentes. Ele pode alterar velocidades, inventários, tempos de residência, carga térmica, geração de vapor, capacidade de alívio e margens de equipamentos.

Debottlenecking exige revisar o processo como sistema. A bomba pode suportar a vazão desejada enquanto o vaso seguinte, a válvula de controle ou o flare não suportam a nova condição.

A MOC deve evitar otimizações locais que transfiram risco para outro ponto da planta.

Mudanças de matéria-prima e produto

Trocar matéria-prima pode alterar corrosividade, inflamabilidade, toxicidade, viscosidade, ponto de fulgor, tendência a polimerização ou incompatibilidade com materiais existentes. Mesmo variações de impurezas podem ser relevantes.

A avaliação precisa considerar SDS, dados de processo, materiais de construção, equipamentos de proteção, detecção, emergência, resíduos e qualidade do produto.

Mudanças de fornecedor também podem exigir revisão quando especificações comerciais permitem variações com impacto técnico.

MOC em equipamentos mecânicos

Equipamentos rotativos, válvulas, tubulações e vasos possuem características que interagem com o processo. Alterar bomba, impelidor, motor, selo, material ou diâmetro pode modificar condições hidráulicas e de integridade.

A análise deve considerar design conditions, materiais, compatibilidade, esforços, vibração, pressão, temperatura, proteção contra sobrepressão e mantenabilidade.

Para válvulas de segurança e dispositivos de alívio, substituições precisam preservar capacidade, set pressure, contrapressão e demais premissas de dimensionamento.

MOC em sistemas elétricos

Mudanças elétricas também podem ter impacto de Segurança de Processo. Substituição de motor pode alterar carga, partida, proteção e desempenho do processo. Mudanças em UPS, geradores ou alimentação de sistemas críticos podem afetar disponibilidade de controle e proteção.

A análise deve considerar seletividade, curto-circuito, coordenação, aterramento, classificação de áreas, cargas críticas e tempo de autonomia quando relevantes.

A integração entre disciplinas é essencial porque a consequência final pode aparecer no processo, não no sistema elétrico isoladamente.

MOC e classificação de áreas

Uma mudança de substância, ventilação, inventário, equipamento ou layout pode alterar a classificação de áreas potencialmente explosivas. A revisão precisa verificar se equipamentos instalados continuam adequados à zona, grupo e temperatura aplicáveis.

Mudanças físicas também podem criar confinamentos ou obstruções que modificam dispersão e ventilação.

Esse tipo de impacto frequentemente passa despercebido quando a mudança é analisada apenas pela disciplina que a solicitou.

MOC em procedimentos operacionais

Alterações procedimentais também podem modificar risco. Mudar sequência de partida, lógica de alinhamento, método de drenagem ou forma de transição entre produtos pode criar estados não analisados.

A organização precisa diferenciar melhoria editorial de mudança operacional. Corrigir ortografia não requer MOC; alterar uma instrução que modifica a condição do processo pode exigir avaliação.

Quando procedimentos mudam, os trabalhadores afetados precisam ser informados e treinados antes da nova condição entrar em serviço.

Documentos que podem ser afetados

Uma única MOC pode exigir revisão de diferentes documentos. Entre os mais comuns estão:

PFD e P&ID;
datasheets e especificações;
lista de equipamentos e linhas;
causa e efeito;
lista de alarmes e setpoints;
filosofia de controle;
SRS e documentos de SIS;
classificação de áreas;
procedimentos operacionais e de manutenção;
desenhos elétricos e de instrumentação;
plano de inspeção e manutenção;
lista de sobressalentes;
plano de resposta a emergências;
As Built e base de ativos.

O fechamento deve confirmar quais documentos foram atualizados e em qual revisão.

Principais interfaces documentais de um Management of Change

MOC e controle de configuração

O MOC decide e governa a mudança; configuration management garante que a configuração aprovada esteja identificada e controlada. São processos complementares.

Uma mudança pode estar tecnicamente aprovada, mas ainda ser mal gerenciada se desenhos, códigos, backups ou listas de ativos não refletirem o resultado. Inversamente, controlar revisões sem avaliar risco não substitui MOC.

Essa distinção é especialmente importante em automação, onde hardware, firmware, application program, parâmetros e rede formam uma configuração conjunta.

MOC x Engineering Change Management

O Engineering Change Management — ECM trata principalmente do controle de mudanças durante o desenvolvimento de engenharia: requisitos, escopo, documentos, interfaces, baseline e impactos em custo e prazo.

MOC em Segurança de Processo tem como centro a pergunta: a alteração modifica perigos, risco ou barreiras da instalação?

Os processos podem se conectar. Uma MOC aprovada pode originar Engineering Change Notice e revisões de projeto. Uma mudança de engenharia pode exigir MOC antes de ser implantada em uma planta existente. A integração deve evitar duplicidade sem perder os objetivos distintos.

Procurement e substituições de fornecedor

Procurement é uma fonte frequente de mudanças. Durante aquisição, fornecedores podem propor equivalentes, desvios técnicos ou modelos alternativos para reduzir custo ou prazo.

A aprovação comercial não deve encerrar a análise. O desvio precisa ser avaliado contra o requisito original e, quando afetar risco ou configuração da instalação, deve entrar no processo de MOC ou change control correspondente.

Uma Technical Bid Evaluation bem estruturada ajuda a identificar desvios antes da compra, reduzindo alterações tardias em campo.

Contratadas e mudanças em campo

Empresas contratadas frequentemente identificam interferências durante montagem e propõem soluções práticas. A execução imediata de uma alteração em campo sem análise é um dos principais mecanismos de perda de configuração.

Field changes devem ser formalizados por RFI, TQ, redline ou processo equivalente e avaliados quanto à necessidade de MOC. O fato de uma solução “funcionar” mecanicamente não demonstra que preserva segurança, operação e manutenção.

A Engenharia de Campo precisa ter autoridade para interromper alterações não aprovadas.

Brownfield, cutover e rollback

Projetos brownfield concentram mudanças porque novos sistemas precisam conviver com instalações existentes. Cutover é uma condição transitória que pode criar combinações de equipamentos e lógicas não presentes nem no estado antigo nem no novo.

O MOC deve incluir plano de migração, sequência, responsáveis, testes, critérios de go/no-go e rollback. A reversão precisa ser tecnicamente viável e documentada, não apenas uma frase genérica no plano.

Em automação, backups e imagens de configuração precisam ser testados ou ao menos verificados antes da intervenção.

PSSR depois da mudança

Nem toda MOC exige PSSR formal, mas modificações significativas precisam de uma revisão de prontidão antes da partida. A PSSR verifica se instalação, procedimentos, treinamento, documentação, ações de risco e demais condições estão prontas para operação.

A relação é direta: MOC autoriza e governa a mudança; PSSR confirma que a condição resultante está pronta para entrar em serviço.

Uma MOC encerrada administrativamente antes da conclusão das ações de PSSR é uma falha de governança.

Testes e comissionamento

A mudança precisa de critérios de aceitação definidos antes do teste. Loop checks, testes funcionais, SAT, testes de intertravamento, calibração, verificação de alarmes, ensaios elétricos ou outros procedimentos devem ser escolhidos conforme o escopo.

O comissionamento gera evidência de que a solução implantada atende aos requisitos. Em sistemas críticos, o registro deve permitir rastrear requisito, teste, resultado e pendência.

Falhas encontradas durante testes podem gerar nova revisão da mudança e não devem ser simplesmente corrigidas em campo sem controle.

Treinamento e comunicação

Pessoas afetadas precisam conhecer a nova condição antes da partida. Isso inclui operação, manutenção e contratadas quando suas tarefas forem modificadas.

Treinamento não deve se limitar a comunicar “houve uma mudança”. É necessário explicar novos limites, riscos, resposta a alarmes, procedimentos, condições temporárias e responsabilidades.

Quando a mudança altera interface homem-máquina, telas e alarmes precisam ser atualizados junto com o treinamento.

Fechamento de MOC

O fechamento não é a data em que a montagem terminou. Ele ocorre quando requisitos técnicos, documentos, treinamentos, testes, ações de risco e pendências foram concluídos ou formalmente transferidos para um sistema controlado.

Uma boa lista de fechamento inclui:

documentação As Built emitida;
procedimentos atualizados;
treinamentos concluídos;
testes aprovados;
ações críticas encerradas;
PSSR concluída quando aplicável;
mudança temporária revertida ou convertida formalmente;
ativos e planos de manutenção atualizados;
responsáveis e aprovações registrados.

MOCs permanentemente abertas indicam que o processo não está completando o ciclo.

Indicadores de desempenho do MOC

Indicadores devem mostrar qualidade e exposição, não apenas quantidade. Métricas úteis incluem tempo médio de fechamento, número de MOCs temporárias vencidas, percentual de ações críticas em atraso, MOCs implementadas antes da aprovação, reincidência de desvios e documentação pendente.

Também é útil acompanhar distribuição por tipo de mudança e área. Um crescimento repentino de emergency MOC pode revelar problemas de planejamento, manutenção ou Procurement.

KPIs precisam gerar decisão. Um dashboard sem tratamento de backlog apenas torna a falha visível.

Auditoria de MOC

A auditoria deve amostrar mudanças concluídas e verificar se a instalação real corresponde ao registro. Não basta conferir se campos foram preenchidos.

Uma auditoria robusta pode rastrear uma mudança desde a solicitação até o campo e comparar P&ID, especificação, lógica, procedimento, treinamento, testes e configuração final.

Mudanças não registradas encontradas em campo são um indicador importante de fragilidade do sistema.

Governança corporativa e padronização

Empresas com múltiplas unidades precisam padronizar princípios sem tornar o processo excessivamente burocrático. O procedimento corporativo pode definir categorias, responsabilidades, critérios de risco, campos mínimos, gates e indicadores, enquanto anexos locais tratam particularidades da instalação.

Templates devem facilitar análise, não substituir pensamento técnico. Um formulário com dezenas de caixas marcadas pode gerar falsa sensação de controle se não houver revisão competente.

Matrizes de aprovação devem ser proporcionais à criticidade. Mudanças simples não precisam do mesmo nível de governança de uma modificação que afeta SIS, alívio ou inventário perigoso.

Papel da Engenharia Consultiva em MOC

A Engenharia Consultiva pode apoiar diagnóstico, desenho do processo, padronização, facilitação de análises, revisão independente e auditoria do sistema de MOC. Esse papel é particularmente útil quando a organização possui mudanças acumuladas, baixa rastreabilidade ou múltiplos fornecedores.

Entregáveis possíveis incluem procedimento corporativo, fluxograma, matriz RACI, critérios de classificação, checklists multidisciplinares, templates, workflow de aprovação, matriz de documentos afetados, indicadores e auditoria de maturidade.

A Consultoria Técnica de Engenharia pode estruturar esse trabalho como governança, sem precisar assumir fornecimento de equipamentos ou execução da mudança.

Gerenciamento de riscos aplicado à mudança

MOC não substitui o processo mais amplo de gestão de riscos. Ele funciona como gatilho para revisar riscos sempre que a configuração muda.

A integração com o Gerenciamento de Riscos de Engenharia permite priorizar ações, definir responsáveis, tratar riscos temporários e verificar eficácia.

Mudanças de alta criticidade podem exigir governança adicional, com revisão independente e gates antes da implantação e partida.

Owner’s Engineering e MOC em projetos contratados

Em projetos com múltiplos contratos, o MOC precisa atravessar fronteiras de escopo. A Engenharia do Proprietário ajuda a verificar interfaces e preservar a visão do ativo como sistema.

Conheça a Engenharia do Proprietário

Em ambientes com EPC, EPCM, integradores e fornecedores especializados, mudanças podem nascer em qualquer contrato. O proprietário precisa de um processo único para evitar que cada fornecedor trate alterações apenas dentro de seu escopo.

Owner’s Engineering pode funcionar como camada de integração, verificando impacto entre disciplinas, documentos, contratos e sistemas. A responsabilidade de cada projetista ou fornecedor permanece definida, mas a mudança é analisada sob a ótica do ativo como um todo.

Esse papel é especialmente importante em brownfield, onde uma alteração do novo projeto pode afetar sistemas existentes fora do contrato principal.

Erros recorrentes em Management of Change

Alguns padrões reduzem a efetividade do processo:

tratar MOC apenas como formulário administrativo;
usar “replacement in kind” sem demonstrar equivalência técnica;
implementar antes da análise por pressão de prazo;
esquecer mudanças temporárias e bypasses;
alterar setpoints ou lógica sem registrar base técnica;
não revisar HAZOP, LOPA ou SIL quando aplicável;
fechar sem atualizar documentos e procedimentos;
deixar ações críticas abertas após a partida;
usar MOC para toda pequena revisão e burocratizar o sistema;
não diferenciar ECM, configuration management e MOC;
não auditar se o campo corresponde ao registro.

O objetivo não é aumentar o número de MOCs, mas garantir que mudanças relevantes sejam reconhecidas e tratadas com rigor proporcional ao risco.

Como implantar ou recuperar um sistema de MOC

Uma organização sem processo maduro pode começar com diagnóstico de gaps. É preciso mapear como mudanças acontecem hoje, onde são aprovadas, quais documentos são atualizados e onde alterações informais escapam do controle.

Depois, define-se o escopo e a taxonomia de mudanças, criteria de in kind, temporárias e emergenciais, papéis, níveis de aprovação e integração com manutenção, projetos, Procurement, automação e Segurança de Processo.

A implantação deve incluir treinamento com exemplos reais. Casos práticos ajudam equipes a reconhecer o gatilho e evitam dois extremos: subnotificação e burocracia excessiva.

Por fim, auditorias iniciais devem testar a eficácia do processo e ajustar critérios conforme experiência.

Considerações finais

Management of Change é uma das principais disciplinas que preservam a validade das decisões de engenharia depois que a instalação começa a mudar. Ele conecta a necessidade operacional à base técnica, análise de riscos, aprovação, projeto, Procurement, implementação, testes, documentação, treinamento e prontidão para operação.

Seu valor aparece justamente nas mudanças que parecem pequenas. Setpoints, componentes equivalentes, bypasses temporários, revisões de software e alterações de procedimento podem modificar a arquitetura de risco sem produzir uma obra visível.

Um MOC maduro não procura impedir mudanças; ele permite mudar com rastreabilidade. A organização sabe o que foi alterado, por que foi autorizado, quais riscos foram revistos, quais documentos mudaram, como a solução foi testada e quem aceitou a condição final.

Para a Engenharia Consultiva, o maior espaço está em governança e padronização: construir um processo proporcional ao risco, integrar disciplinas, reduzir mudanças informais e assegurar que o ativo real continue coerente com as premissas técnicas que sustentam sua operação segura.

Referências técnicas

[1] UNITED STATES. Occupational Safety and Health Administration — OSHA. 29 CFR 1910.119 — Process Safety Management of Highly Hazardous Chemicals, item 1910.119(l) Management of Change. Disponível em: https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.119

[2] UNITED STATES. Occupational Safety and Health Administration — OSHA. Appendix C to §1910.119 — Compliance Guidelines and Recommendations for Process Safety Management. Disponível em: https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.119AppC

[3] CENTER FOR CHEMICAL PROCESS SAFETY — CCPS. Guidelines for Risk Based Process Safety. New York: AIChE/Wiley, 2007. Disponível em: https://ccps.aiche.org/publications/books/guidelines-risk-based-process-safety

[4] INTERNATIONAL ELECTROTECHNICAL COMMISSION — IEC. IEC 61511-1:2016+AMD1:2017 CSV — Functional safety — Safety instrumented systems for the process industry sector — Part 1. Disponível em: https://webstore.iec.ch/en/publication/61289

[5] BRASIL. Ministério do Trabalho e Emprego. NR-20 — Segurança e Saúde no Trabalho com Inflamáveis e Combustíveis. Disponível em: https://www.gov.br/trabalho-e-emprego/pt-br/acesso-a-informacao/participacao-social/conselhos-e-orgaos-colegiados/comissao-tripartite-partitaria-permanente/normas-regulamentadora/normas-regulamentadoras-vigentes/norma-regulamentadora-no-20-nr-20

Perguntas frequentes

O que significa MOC em Segurança de Processo?

MOC significa Management of Change. É o processo formal para avaliar, autorizar, implementar e encerrar mudanças que possam afetar perigos, riscos, barreiras, procedimentos ou configuração de uma instalação.

Qual a diferença entre MOC e Engineering Change Management?

Engineering Change Management controla mudanças de requisitos, escopo, documentos e configuração durante projetos de engenharia. MOC concentra-se no impacto de uma alteração sobre perigos, riscos e barreiras da instalação. Os processos podem se integrar, especialmente em projetos brownfield.

O que é replacement in kind?

É uma substituição tecnicamente equivalente que preserva função, especificação, desempenho, materiais, interfaces e demais características relevantes para o risco. Colocar um equipamento diferente no mesmo lugar não é suficiente para caracterizar replacement in kind.

Mudanças temporárias precisam de MOC?

Sim, quando alteram condições relevantes de processo, equipamento, proteção, procedimento ou operação. Mudanças temporárias devem ter prazo, responsável, controles compensatórios e critério de reversão ou formalização.

Toda MOC precisa de HAZOP?

Não. A técnica de análise deve ser proporcional ao risco e à complexidade. Mudanças simples podem ser tratadas por revisão técnica estruturada; mudanças mais significativas podem exigir HAZOP, What-If, LOPA ou estudos especializados.

Alteração de setpoint precisa de MOC?

Pode precisar. Se o setpoint influencia limites operacionais, alarmes, intertravamentos, SIFs ou margens de segurança, a alteração deve possuir base técnica, avaliação de impacto e atualização dos documentos correspondentes.

Qual a relação entre MOC e PSSR?

MOC governa a mudança; PSSR verifica a prontidão da instalação modificada antes da partida quando a alteração é significativa. A PSSR confirma que montagem, procedimentos, treinamento, documentação e ações de risco estão adequados para entrada em serviço.

Uma consultoria pode implantar um processo de MOC sem executar as mudanças?

Sim. A consultoria pode atuar em diagnóstico, padronização, procedimentos, matriz RACI, critérios de classificação, workflows, auditoria, facilitação de análises e revisão independente, enquanto projeto detalhado e execução permanecem com os responsáveis definidos.