Oito equívocos comuns de gerenciamento de mudança

Sempre que menciono o gerenciamento de mudanças ao pessoal da fábrica, geralmente recebo uma das várias respostas previsíveis. Os conhecedores citarão o regulamento OSHA 1910.119 (a) (2) e me dirão que não são um "processo coberto", portanto, não se aplica a eles - geralmente com um grande suspiro de alívio. Outra resposta frequente é:“Temos um procedimento de gerenciamento de desenhos, mas estamos tão atrasados ​​que levaria anos e recursos que não temos para recuperar”. Outros ainda me dirão que têm um procedimento perfeitamente adequado para seus gerentes aprovarem pequenos projetos e alterações. E, alguns vão pensar timidamente sobre os centavos e níqueis enchendo o cinzeiro de seus carros.

Então, o que é gerenciamento de mudança (MOC)? Voltando à fonte, OSHA 1910.119 (l) (1) define os requisitos para MOC como:"O empregador deve estabelecer e implementar procedimentos escritos para gerenciar mudanças (exceto para" substituições em espécie ") para processar produtos químicos, tecnologia, equipamentos e procedimentos; e, mudanças nas instalações que afetam um processo coberto. ”

Essa breve descrição cobre muito território, mas como foi promulgada exclusivamente para aumentar a segurança do processo, ela limita a aplicabilidade legal aos “processos cobertos”. Os leitores cujas instalações atendem aos requisitos da OSHA de um “processo coberto” estão bem cientes dos requisitos detalhados do MOC. Eles têm que estar ou não estariam operando. E espero que todos vocês saibam que muitos dos piores acidentes industriais da história recente têm como causa raiz o fracasso do processo de MOC. Algumas fontes indicam que até 80% dos acidentes graves na indústria estão relacionados a mudanças não controladas. Assim, pode-se pensar no MOC como uma espécie de seguro de vida que compensa evitando acidentes.

Mas este artigo não se concentra nas complexidades do MOC para processos cobertos. E não é exclusivamente voltado para a segurança. Por que então estamos discutindo o MOC se ele não é “necessário” para o seu setor? Resumindo, é porque todo negócio, independentemente dos requisitos legais, precisa controlar as perdas potenciais. E o MOC, devidamente aplicado, é um processo de prevenção de perdas excelente e econômico para quase todos os negócios. É o processo complementar perfeito para seus processos de eliminação de perdas. E todos nós queremos ser seguros e ecologicamente corretos também, certo?

Observe que o MOC aborda apenas as alterações existentes no momento. O projeto de novos processos ou instalações é outra questão inteiramente. E, temos que assumir, para fins de discussão do MOC, que o nível de desempenho do sistema existente, se não adequado, pelo menos tem virtudes e vícios familiares e bem conhecidos.

Então, o que é o MOC em termos não regulamentares e a quem ele realmente se aplica? Vamos trabalhar com esta definição simples:MOC é um processo para prevenir ou mitigar perdas de negócios - incluindo degradação da segurança, saúde ou meio ambiente - como resultado de mudanças feitas em como você constrói, opera, gerencia ou repara suas instalações ou processos. Deixando de lado os requisitos regulamentares, nenhuma empresa com a intenção de permanecer competitiva pode se dar ao luxo de não ter um processo de MOC adequado em vigor. Resumindo, o MOC faz sentido para a segurança e financeiramente. Um processo de MOC faz sentido para o seu negócio?

O que é uma ‘mudança’?
“A parte mais difícil da gestão da mudança é reconhecer a mudança.” O ponto de partida mais importante para o programa é definir claramente para a organização o que constitui uma “mudança” que você deseja gerenciar. Ou, mais simplesmente, que mudança cai no processo de MOC e que tipo de mudança não? A falta de uma definição clara prejudica efetivamente a eficácia de um programa MOC, convidando tanto a paralisia de análise desnecessária quanto criando brechas para aqueles que desejam contornar o processo.

Existem muitas definições de mudança de muitas fontes diferentes. É responsabilidade da liderança do local definir as mudanças em termos consistentes com os interesses comerciais e quaisquer precedentes regulatórios. Que riscos você deseja controlar e que tipo de mudanças, se não controladas, aumentam esses riscos? Só então as atividades que podem ser razoavelmente definidas como "mudanças" podem ser claramente identificadas e, uma vez identificadas, devem ser transmitidas na linguagem mais simples e direta possível.
Embora um pouco confuso, o uso de listas ou tabelas de exemplos muitas vezes é necessário para transmitir os pontos. Lembre-se de que uma “mudança” não precisa ocorrer em uma peça de hardware para se qualificar. Software, procedimentos e parâmetros de processo são todos exemplos de mudanças não relacionadas ao hardware que freqüentemente devem ser rigorosamente controladas.

Ao lidar com hardware, o documento fonte OSHA 1910 refere-se indiretamente a uma alteração como não sendo uma "Substituição em espécie" (RIK) e definindo RIK como "uma substituição que satisfaz as especificações de design." RIK geralmente se refere a equipamentos ou componentes que são idênticos em forma, ajuste e função (referidos como F3). Mas há mais a mudar do que essa abordagem baseada em hardware muito restrita. A definição de mudança da OSHA também se refere a tecnologia, procedimentos e produtos químicos (mais amplamente interpretados como matérias-primas). Obviamente, mais do que apenas hardware está incluído na definição de “mudança”. Eu descobri que a melhor definição formal em uso para "mudança" no processo MOC é encontrada em um esclarecimento publicado na OSHA 3313:"Mudança é uma alteração ou ajuste a qualquer componente, variável ou propriedade dentro de um sistema existente (exceto aqueles dentro limites ou responsabilidades claramente definidos). ”

Uma vez que cada negócio tem diferentes áreas de exposição ao risco e diferentes tolerâncias a consequências indesejáveis, cabe a cada negócio avaliar o risco e definir sua tolerância para mudanças não controladas. Alguns exemplos (mas de forma alguma inclusivos) dos tipos de mudanças que uma empresa pode desejar gerenciar são:

• Adição de novo equipamento de processo ou sistema de negócios crítico (incluindo software)
• Substituição “não em espécie” de equipamentos ou peças de processo
• Modificações ou pequenas adições ao equipamento de processo
• Modificações ou pequenos acréscimos ao sistema de negócios crítico (procedimental ou software)
• Modificações ou pequenos acréscimos à infraestrutura / equipamentos não relacionados ao processo
• Mudanças no controle de processo e / ou instrumentação (inclui estratégias de controle)
• Mudanças nas especificações ou fornecimento de MRO técnico
• Mudanças nos limites operacionais dos parâmetros críticos do processo (fora dos intervalos especificados nos procedimentos operacionais padrão [SOPs])
• Alterações nos sistemas de segurança (bloqueios, desligamentos, supressão de incêndio ou explosão, etc.)
• Revisões dos procedimentos operacionais padrão (incluindo procedimentos de emergência)
• Mudanças na estrutura organizacional no nível do site
• Mudanças nos procedimentos de manutenção
• Mudanças nas especificações de matérias-primas / componentes ou fornecimento
• Alterações ou novas conexões aos sistemas de utilidades (ar, elétrico, gás, água, vapor, etc.).
• Alterações ou novas conexões com redes de dados críticas
• Mudanças nos procedimentos de controle de qualidade ou equipamentos de teste críticos

Algumas horas de brainstorming de qualidade “e se” por uma equipe multidisciplinar no início do design do processo para desenvolver as definições e os exemplos certos para o seu negócio renderão enormes dividendos.

E quanto às mudanças "temporárias"?
Lembre-se deste importante conceito a ser aplicado ao implementar o MOC:Assim como não há nada no mundo tão permanente quanto um imposto temporário, não há mudança mais permanente do que uma “mudança temporária” que escapou ao processo do MOC. A experiência mostra que existem realmente apenas mudanças permanentes que se destinam a ser temporárias até que sejam restauradas às condições originais. De todas as mudanças descontroladas que ocorrem, as mudanças “temporárias” são as mais perniciosas e as causas mais frequentes de acidentes e incidentes. Assim, as alterações “temporárias” de um sistema controlado nunca devem ser isentas do processo de MOC.

Então, o que devo fazer para lidar com as alterações temporárias que devem ser feitas para realizar negócios de rotina, como um bypass de bloqueio para realizar manutenção periódica? Se for realmente rotineiro, então o que você tem é um estado permanente de desvio periódico do SOP. E a maneira certa de lidar com isso é tratar a situação como uma mudança permanente, incorporando-a aos procedimentos aprovados com as devidas salvaguardas. Se algo foi planejado como uma mudança temporária não rotineira, trate-o como uma mudança. OSHA 3133 em um esclarecimento diz:"O procedimento MOC deve garantir que os equipamentos e procedimentos sejam devolvidos às suas condições originais no final de uma mudança temporária." A história e a prudência sugerem que as alterações “temporárias” devem ser gerenciadas como “permanentes”, com atenção especial ao procedimento MOC, porque representam o maior risco para o seu negócio.

Oito Equívocos Comuns de MOC
1) “Mas eu não estou fazendo uma modificação real. Estou apenas tornando-o um pouco melhor. ”
Se você não está deixando a peça / equipamento / sistema empresarial exatamente como estava antes de iniciar o trabalho (ausente, é claro, de qualquer dano que foi o objeto do reparo), então você fez uma alteração . Se a mudança se enquadra ou não no escopo de seu processo de MOC, é determinado pelos critérios definidos em seus procedimentos. A abordagem padrão a ser adotada é presumir que qualquer mudança na configuração, forma, ajuste, função, materiais ou procedimento é coberta pelo MOC até que um exame dos critérios no procedimento prove o contrário.

Depois das “mudanças temporárias” não controladas, pequenas melhorias bem-intencionadas são classificadas como a segunda maior causa de incidentes que se enquadram na categoria de falha de MOC. Sem uma avaliação completa do contexto operacional e ambiente total, quem pode dizer que “melhor” de uma forma não é realmente muito, muito pior de outra? O mesmo medicamento administrado a um paciente pode ser uma cura poderosa; para outro, pode ser um veneno mortal. O mesmo se aplica a pequenas “melhorias” bem intencionadas, mas não controladas, especialmente substituições de materiais que são particularmente arriscadas. Ensine seu pessoal em todos os níveis a estar ciente e evitar essa armadilha comum e, a seguir, aplique-a estritamente. Ninguém gosta de disciplinar as pessoas por quebrar as regras, especialmente quando o fazem com o espírito de melhoria. Mas é infinitamente pior ter que dizer a uma família que alguém não vai voltar para casa esta noite.

2) “Estou tão atrasado que não consigo começar a fazer MOC. Nunca vou recuperar todos aqueles desenhos não revisados. ”
Controle de documentos é um processo que complementa um processo de MOC bem projetado e geralmente é a primeira coisa em que as pessoas pensam quando você menciona o MOC. A necessidade de atualizar documentos é certamente um resultado frequente de um MOC e necessária para a integridade de longo prazo de seus processos e instalações, mas não é um MOC. É apenas um resultado frequente.

Muitas vezes, ao implementar o MOC com um processo de controle de documentos, você herda uma grande confusão daqueles que o precederam:nenhum desenho, desenhos imprecisos, documentos desatualizados. . O que você disser. Se a situação for terrível, você pode ser forçado a priorizar suas ações corretivas - se houver alguma com base na criticidade dos sistemas. Alguns podem não precisar e nunca serão corrigidos. Certamente, um método para corrigir informações vitais quando descobertas pode e deve ser facilmente incorporado em seus procedimentos de controle de trabalho. Mas não aumente a tarefa continuando com os maus hábitos.

Você não pode mudar o que aconteceu no passado. Se o caso de negócios existe para corrigir ou mitigar erros passados, faça-o. MOC é sobre prevenção de perdas futuras. Portanto, a única coisa que qualquer organização pode fazer é começar a implementar o MOC agora mesmo. Hoje é o dia de parar de criar mais problemas para amanhã. Um pedaço sucinto de sabedoria popular diz:“Se você tiver que preencher um buraco realmente grande, a primeira coisa a fazer é parar de cavar mais fundo.” O mesmo se aplica a uma lacuna criada por um MOC pobre. Pare de aumentar.

3) “Não tenho tempo para esperar pela avaliação do MOC. Esta é uma emergência! ”
Durante uma emergência é precisamente quando a autodisciplina imposta por um processo de MOC bem estabelecido é mais necessária. Quando um avião tem um problema durante o vôo, os pilotos não fazem a primeira coisa que vem à mente. Em vez disso, eles puxam a lista de verificação e pensam, depois agem. Quando houver uma “emergência”, você também deve fazer o mesmo. Essa “pequena modificação” para permitir uma substituição realmente vai economizar muito tempo de inatividade em comparação com a obtenção da peça correta? Mudanças menores costumam levar muito mais tempo do que o esperado.

Seja realista em sua avaliação de quanto tempo, quanto dinheiro e quanto risco esse "trabalho rápido" realmente levará. É bom ser otimista em uma emergência. É melhor estar preparado para o pior. Como diz o ditado:“Se você estiver em um barco furado longe no mar, é melhor orar em direção ao céu, mas remar em direção à costa”. O risco para o seu negócio associado a um desvio “temporário” compensa a economia de tempo? Você pode realmente controlar o risco a um nível aceitável por “procedimentos operacionais especiais”?

Relatórios de acidentes mostram que decisões precipitadas, feitas sob pressão, sem uma avaliação equilibrada, têm estado na raiz de muitos problemas graves . Tempo para pensar de maneira disciplinada não é tempo perdido. E se o seu processo de MOC for eficiente, ele não impedirá indevidamente o progresso nas raras ocasiões em que for uma verdadeira emergência. Assim como existe um procedimento para autorizar e emitir uma ordem de serviço de emergência quando necessário, um bom procedimento de MOC terá um mecanismo para lidar com emergências reais. Mas esse mecanismo não deve ser ignorar o MOC. Não permita a conveniência durante uma “emergência” para prepará-lo para uma segunda emergência maior e mais séria. Não desarme uma bomba apenas para plantar uma mina terrestre.

Você está enfrentando falhas frequentes que exigem uma solução alternativa, tendo que fazer substituições de peças à meia-noite constantemente para se recuperar de uma falha inesperada ou constante alterações de processo para acomodar componentes ou matérias-primas instáveis? Então, seu desafio não é ignorar o MOC ou projetar um processo de MOC que apóie a anarquia. Em vez disso, você deve concentrar seus esforços na eliminação dessas situações, implementando um processo eficaz de análise de falha de causa raiz (RCFA) e programas de manutenção preventiva / preditiva para eliminar as falhas crônicas. Em seguida, concentre-se em corrigir as deficiências em seus processos de MRO para garantir que você sempre tenha as peças certas. E, finalmente, você deve estabilizar seu processo com procedimentos de trabalho padrão e programas de qualificação de fornecedores de materiais.

4) “Encaminhar este formulário para aprovação demora tanto que nunca conseguiremos realizar nada.”
Um processo MOC eficaz requer um nível apropriado de aprovação e comunicação. Procedimentos de aprovação de MOC mal projetados confundem a necessidade de ser informado sobre uma mudança depois que ela acontecer com a necessidade de aprovar uma mudança antes que ela aconteça. Os níveis de aprovação exigidos precisam ser adequados à mudança e ao risco potencial associado a ela. Eles também precisam ser flexíveis o suficiente para que possam ser adaptados à situação em questão. Minimize o número de aprovadores e torne-os os corretos. Seu processo de MOC pode então ser agilizado com segurança.

5) “Mas meu gerente de área já tem que aprovar fundos para mudanças.”
Não confunda a autoridade para tomar uma decisão com a posse do conhecimento necessário para tomar essa decisão. Nem todas as alterações, e muitas vezes as mais críticas, passam pela aprovação de financiamento. Freqüentemente, as pessoas mais competentes para avaliar o risco de fazer uma mudança ou a validade técnica de uma mudança não são o gerente da área, mas os operadores, mecânicos, supervisores ou engenheiros mais familiarizados com ela.

Mesmo que o gerente é muito competente, é raro que uma pessoa seja competente em todos os aspectos ou consequências de uma determinada mudança. Em um processo de MOC eficaz, é responsabilidade do gerente garantir que os recursos apropriados designados estejam envolvidos em uma avaliação equilibrada da mudança proposta. A autoridade de aprovação é secundária à competência para avaliar e uma equipe bem equilibrada dará resultados consistentemente bons do que depender de um indivíduo inteligente.

6) “Somos um armazém / manufatura leve / dados centro / instalação de reparo. … Não temos nada que possa ser perigoso. ”
Lembre-se de que o MOC é um processo para prevenir ou mitigar todas as perdas de negócios autoinfligidas potenciais associadas a uma mudança. Existem outras perdas além da segurança do processo. É uma perda se uma alteração descontrolada do processo fizer com que você perca um cliente valioso por causa de um produto contaminado ou com defeito. É uma perda se o seu data center estiver inoperante e a solução de problemas levar várias horas em vez de minutos, porque os desenhos elétricos não acompanharam as mudanças. É uma perda se o empilhador automático estiver desligado e você não puder enviar o produto porque uma substituição de peça à meia-noite exigindo uma "pequena modificação" fez com que a única peça de reposição que você tem em estoque não couber mais. É uma perda se uma modificação não documentada no software de controle fizer com que sua máquina de teste automático falhe quando o patch de segurança mais recente for instalado. Todos esses são exemplos reais e a lista é interminável. Mesmo que o potencial de mudanças para criar situações perigosas em seu ambiente seja pequeno, todos nós temos algo a perder quando nossas instalações ou processos falham em suas missões principais.

7) “Mas o MOC venceu não pega todos os problemas possíveis, então por que fazer isso? ”
Você está absolutamente certo. Apesar de seus melhores esforços, alguns problemas passarão despercebidos. Mas quantos vão escapar se você não fizer o MOC? O gerenciamento de risco tem tudo a ver com mudar as chances de estar mais a seu favor. Esse argumento não se sustenta - não mais do que o argumento que algumas pessoas usam contra os airbags:“Eles podem disparar e causar um acidente, então eu os desligo”. As estatísticas simplesmente não apóiam essa linha de pensamento mais do que não apóiam a ausência de MOC.

E se você perder uma consequência não intencional? Um benefício adicional valioso do MOC em sistemas complexos é fazer um RCFA. Se houver consequências adversas de uma mudança e a causa não for imediatamente discernível, o RCFA será muito mais rápido se você tiver uma lista de todas as mudanças deliberadas que foram feitas. E esse tempo pode ser dinheiro de verdade. Em um caso, a pesquisa de registros MOC cortou semanas do tempo necessário para encontrar a causa raiz de uma série de falhas de planta de processo. Com $ 250.000 por dia em perdas evitadas por tempo de inatividade, o esforço de MOC teve um retorno sobre o investimento bastante bom, embora não tenha evitado o problema.

8) “Esta é apenas uma alteração de software / procedimento. Não é como se estivéssemos trocando um cano ou algo assim. Não precisamos aprovar ou documentar. ”
Alguns incidentes extremamente sérios e perdas graves ocorreram em vários setores devido a alterações de software ou procedimentos que não estavam sujeitos ao MOC. Além disso, só porque um documento ou código foi alterado e reflete a mudança, não significa que a mudança foi documentada. Eu sei que comentários no código e sinalizadores de revisão no documento permitem que o pesquisador procure por alterações. Mas quando ocorrem problemas inesperados porque a mudança de software ou procedimento não foi revisada adequadamente, então de que adianta? mudança que foi feita pelo engenheiro de controle dois meses antes de sair para outro trabalho? Os programadores e engenheiros de controle, em particular, tendem a “brincar” com o software sem levar em conta o MOC. Isso se aplica não apenas ao controle de processo, mas também ao software de sistemas de negócios críticos. Se o risco potencial existe e o justifica, trate a alteração de uma linha de código da mesma forma que reconectar um sistema de desligamento de segurança; deve receber o mesmo nível de escrutínio e controle.

Conclusão
Concluindo, um processo de MOC bem projetado é uma ferramenta essencial de prevenção de perdas para qualquer negócio. Não é apenas para certas indústrias perigosas. O processo se aplica a qualquer empresa que deseja evitar perdas futuras resultantes das mudanças de hoje. O MOC não precisa ser opressor ou tão difícil de usar a ponto de inibir mudanças. Não pode compensar sem esforço as omissões passadas, apenas reduz o seu risco futuro. Portanto, o momento de começar a desenvolver e implementar um processo de MOC eficaz e eficiente é hoje.

Este artigo apareceu pela primeira vez na edição de julho do boletim informativo da Life Cycle Engineering, RxToday.

Sobre o autor:
Sam McNair é consultor sênior da Life Cycle Engineering (LCE). Engenheiro profissional e profissional certificado em manutenção e confiabilidade, Sam tem mais de 32 anos de experiência em manufatura discreta, indústrias de processos químicos, mineração, processos de máquinas, automação, aviação, construção e serviços públicos. Sam é especialista em engenharia de confiabilidade com foco na integração das funções de manutenção e fabricação. Você pode entrar em contato com Sam em [email protected]. Para obter mais informações sobre a Engenharia de Ciclo de Vida, visite www.LCE.com.