Qualidade do pedido de intervenção de manutenção: 7 campos essenciais

Um pedido de intervenção de manutenção (uma notificação no SAP PM, um pedido de intervenção no Maximo ou no Oracle) é o único momento no ciclo de vida da ordem de trabalho em que a pessoa que detetou o problema ainda está envolvida no processo. Tudo o que um planeador, um responsável pela programação, um comprador e um engenheiro de fiabilidade fazem posteriormente baseia-se no que essa pessoa introduziu. Um pedido em que falte o estado do equipamento, as competências técnicas necessárias ou uma descrição útil não pode ser resolvido através de um melhor planeamento. Só pode ser devolvido, adivinhado ou executado de forma errada.

Um responsável pela manutenção e fiabilidade de uma importante operadora norte-americana do setor do petróleo e gás expressou-se da seguinte forma durante as nossas sessões de conceção de produtos: se a notificação for enviada com qualidade e a execução for confirmada com qualidade, a maior parte do que se passa entretanto pode ser automatizada. Se as duas extremidades estiverem bem feitas, o meio resolve-se por si só. Se a parte inicial estiver errada, nada a jusante poderá salvá-la.

Pontos-chave

• A ordem de trabalho é o documento com maior impacto na manutenção. Um minuto dedicado à qualidade na fase de receção poupa horas de trabalho adicional ao planeador, evita prioridades erradas e a aquisição de peças inadequadas.
• Sete campos determinam se um pedido pode ser planeado sem necessidade de uma chamada telefónica: equipamento e localização funcional, «está em baixo neste momento», desvio ou redundância, horas estimadas, ofícios, ferramentas especializadas e impacto na segurança.
• Os técnicos não elaboram pedidos incorretos por descuido. Fazem-no porque o ecrã do ERP foi concebido para o planeador, e não para alguém que se encontra diante de uma bomba avariada.
• Os pedidos duplicados e mal codificados não se limitam a sobrecarregar a lista de pendências. Corrompem os indicadores MTBF, MTTR e a análise de «agentes problemáticos» durante anos.
• A maioria das empresas tenta resolver esta situação através de formação e de campos obrigatórios. Ambas as medidas falham pela mesma razão: criam obstáculos para a pessoa que tem menos tempo e menos motivação.
• A solução consiste em transferir a responsabilidade pela qualidade do técnico para o processo de receção, e é aí que a gestão de ordens de trabalho baseada em IA ganha o seu lugar.

Por que é que um pedido de intervenção mal feito custa mais do que uma ordem de trabalho mal feita?

Uma ordem de trabalho incorreta afeta uma única tarefa. Um pedido de trabalho incorreto afeta todas as decisões tomadas relativamente a essa tarefa, porque cada etapa subsequente herda essa falha. O planeador define o âmbito de forma errada, o motor de priorização atribui-lhe uma pontuação errada, a reserva de peças está errada e o registo de falhas que chega ao engenheiro de fiabilidade está errado. O erro agrava-se a cada transferência de responsabilidade.

Pense no que acontece quando chega um pedido que diz apenas “a bomba está a verter, é preciso resolver o problema”.”

• O planeador pára. Não conseguem avaliar o âmbito do trabalho sem saber qual é a bomba, o que está a verter, se a unidade está a funcionar ou avariada e se existe uma unidade de reserva em serviço. Ou ligam ao autor da solicitação (se o conseguirem localizar, se estiver de serviço, dias depois) ou têm de adivinhar.
• A prioridade está errada. Sem um sinal a indicar se o sistema está em baixo, o pedido é colocado na fila de pendências, como de costume. Se o equipamento estiver a causar perdas na produção, ninguém se apercebe disso até que o departamento de operações intervenha.
• As peças não estão reservadas. A ausência de um modo de falha implica que não é necessário consultar a lista de materiais. O trabalho é agendado, a equipa chega, o kit de vedantes não está em stock e um trabalho $400 transforma-se num trabalho urgente $9 000.
• A execução é adiada. A equipa não pode avançar sem a autorização, o isolamento ou a segunda embarcação, que ninguém assinalou. A ordem de trabalho é devolvida ao departamento de planeamento com uma nota.
• O registo de falhas não serve para nada. Quando o trabalho é finalmente encerrado, o código de avaria é aquele que o técnico selecionou num menu suspenso às 16h00 de uma sexta-feira. Posteriormente, o engenheiro de fiabilidade realiza uma análise de fatores de falha com base em dados que nunca foram verdadeiros.

O profissional com quem trabalhámos descreveu isto como a diferença entre uma ordem de trabalho que é previsto e um que é aberto. A maioria das listas de pendências está repleta de ordens de trabalho em aberto. É o pedido que determina qual delas lhe é atribuída.

A relação custo-benefício é desequilibrada. O autor gasta cerca de um minuto adicional a preencher os sete campos abaixo. O planeador poupa entre 20 e 45 minutos de trabalho de acompanhamento por pedido. Num local que gera entre 300 e 500 pedidos por mês, a diferença equivale a um ou dois postos de trabalho de planeador, sem contar com os pedidos urgentes, os trabalhos adiados e os dados de fiabilidade corrompidos.

O que inclui um pedido de intervenção de manutenção de alta qualidade?

Um pedido de intervenção programável responde a sete perguntas antes de um planeador o abrir. Não se trata dos 40 campos do ecrã de notificação do SAP. São os sete que, quando faltam, impedem um planeador de fazer o seu trabalho, extraídos diretamente do que um líder experiente na área da fiabilidade afirmou ser necessário logo no primeiro dia. Pergunte o suficiente, não tudo.

Dois destes merecem uma análise mais aprofundada, pois são aqueles que o ecrã padrão do ERP trata de forma menos eficaz.

Está fora de serviço neste momento? SAP distingue estado do sistema (qual será o impacto enquanto os trabalhos estiverem a decorrer) a partir do indicador de avaria (o equipamento avariou-se agora). A maioria dos locais não utiliza nenhuma das duas opções de forma consistente. O profissional com quem trabalhámos referiu que a lacuna entre as duas era a solução alternativa personalizada mais comum que tinha observado entre os operadores: cada local cria o seu próprio campo para “fora de serviço neste momento” e nenhum deles comunica entre si. Abordamos este tema em profundidade no nosso artigo sobre a lacuna de impacto na produção na priorização das ordens de trabalho.

Derivação ou redundância. É nos sistemas auxiliares que isto se faz sentir mais. Uma bomba de água de arrefecimento ou um conjunto de lubrificação raramente dispõe de redundâncias, e uma avaria num deles provoca o encerramento total da unidade. No entanto, a questão da redundância quase nunca é colocada em relação à admissão, porque não há espaço para isso. A informação fica na cabeça do autor e, se este se lembrar, num texto extenso. Um pedido que a capture altera, num único passo, a prioridade, o calendário e a estratégia de armazenamento desse equipamento.

A norma a que a maioria dos locais sujeita os técnicos prevê dois campos: uma localização funcional e uma descrição. Isso é suficiente para abrir uma ordem de trabalho. Não é, porém, suficiente para a planear.

Por que razão os técnicos redigem pedidos de intervenção mal elaborados e por que razão a formação não resolve o problema?

Os técnicos redigem pedidos sucintos porque o ecrã de pedido foi concebido para quem o lê, e não para quem o redige. O autor do pedido encontra-se numa fábrica ruidosa, muitas vezes com luvas, com um equipamento avariado à sua frente e um turno para terminar. O ERP exige que encontrem um terminal, naveguem por uma transação, selecionem a partir de listas de códigos que não utilizam diariamente e digitem textos longos com dois dedos. Racionalmente, digitam o mínimo necessário.

O especialista em fiabilidade com quem trabalhámos foi muito direto: as equipas no terreno não gostam do ERP, e ele nem esperava que gostassem. Os casos de melhor adoção que ele tinha observado eram os locais que deixaram de esperar que os técnicos fossem meros operadores de introdução de dados.

As três soluções padrão esbarram todas no mesmo obstáculo.

Formação. O efeito mantém-se durante os três meses seguintes à sessão e vai diminuindo à medida que o grupo formado é substituído. As equipas contratadas, que são responsáveis por uma grande parte dos pedidos em muitos locais, raramente recebem qualquer formação.

Campos obrigatórios. Tornar um campo obrigatório garante que este seja preenchido. Não garante, porém, que o valor introduzido esteja correto. Os sites que exigem um código de dano acabam por acumular um atraso, em que as avarias são codificadas como “outro” ou como a primeira opção da lista. Os campos obrigatórios transferem o problema da qualidade dos dados de em falta para errado, o que é pior, porque os dados errados parecem estar completos.

Triagem do planeador. Muitos locais aceitam o pedido sumário e pedem aos planeadores que o completem. Isto funciona, mas à custa de uma semana de trabalho do planeador. Um planeador que passa 40 por cento do seu tempo a perseguir os responsáveis pela elaboração do pedido é um planeador que não está a elaborar planos de obra, a verificar kits nem a inspecionar as obras. É a pessoa mais cara da cadeia que está a fazer o trabalho mais barato.

Há mais um custo que raramente é tido em conta. Cada pedido que é reenviado ou sobre o qual se liga por telefone a um professor faz com que o técnico sinta que abrir um pedido é um incómodo. Da próxima vez, resolvem o problema por conta própria e não comunicam nada. O volume de trabalho em atraso parece mais razoável. No histórico do equipamento falta agora registar uma avaria.

De que forma os pedidos de intervenção duplicados e mal codificados comprometem a fiabilidade dos dados?

Cada pedido de intervenção constitui também um registo de fiabilidade, quer tenha sido essa a intenção ou não. O registo temporal começa com o MTTR relógio. Os códigos de equipamento e de avaria alimentam o MTBF e a análise de «fatores de falha». Um pedido duplicado, mal codificado ou registado para o equipamento errado não se limita a desperdiçar o tempo do planeador esta semana. Distorce o histórico de falhas que a unidade irá utilizar para definir as frequências de manutenção preventiva, justificar investimentos de capital e decidir quais os ativos que receberão atenção ao longo dos anos.

As duplicatas são o caso mais evidente. Quando uma bomba começa a vibrar, três pessoas em três turnos podem apresentar um pedido de intervenção. Se todos os três forem convertidos em ordens de trabalho, ou se for encerrado o pedido errado, a unidade regista três falhas onde, na realidade, houve apenas uma. O equipamento atinge um limiar de «mau funcionamento» que nunca mereceu. O profissional com quem trabalhámos foi preciso quanto à regra: manter a solicitação mais antiga, porque foi aí que o contador de falhas começou, e cancelar as posteriores com um código de motivo que indique duplicado, não concluído ou não foi detetada qualquer avaria. Uma duplicada encerrada como concluída é uma reparação fantasma.

A codificação incorreta é mais discreta e mais comum. Um pedido registado para a localização funcional principal, em vez de para o equipamento, significa que a avaria é atribuída à unidade e não à bomba. Um código de dano “outro” significa que a avaria não é atribuída a nada. Ambas as situações fazem com que o ativo pareça estar em melhor estado do que realmente está. A unidade prolonga então o intervalo de manutenção preventiva num ativo que está a apresentar falhas, porque os dados indicam que está em bom estado.

É por isso que a qualidade dos pedidos é um problema de fiabilidade, e não um problema administrativo. As pessoas mais prejudicadas por pedidos incompletos não são os planeadores que os tentam satisfazer. São os engenheiros de fiabilidade, dois anos mais tarde, a realizar análises sobre um histórico de falhas que nunca correspondeu à realidade, e o armazém que guarda peças sobressalentes erradas para os ativos que falham. Abordamos o problema das notificações duplicadas e o seu efeito no MTBF num artigo separado.

Em que consiste o princípio “qualidade na entrada, qualidade na saída” no ciclo de vida de uma ordem de trabalho?

O ciclo de vida de uma ordem de trabalho tem dois pontos em que a intervenção humana é imprescindível: o pedido inicial e a confirmação final. Tudo o que se passa entre elas (definição do âmbito, priorização, agrupamento, reserva de peças, agendamento, obtenção de licenças) consiste na aplicação de regras aos dados fornecidos por esses dois pontos. Se a solicitação estiver completa e o encerramento for correto, a parte intermédia pode ser sistematizada. Se qualquer uma das extremidades for deficiente, por mais sofisticada que seja a parte intermédia, isso não adianta nada.

Foi esta observação que reformulou a nossa forma de pensar sobre a gestão de ordens de trabalho. O profissional com quem trabalhámos não pediu um sistema de planeamento mais inteligente. Pediu que as solicitações chegassem já prontas para serem planeadas e que o encerramento registasse o que tinha acontecido. Com estas duas coisas, estava confiante de que a maior parte do trabalho manual do planeador poderia ser eliminada.

Isso também explica por que razão tantos investimentos em CMMS e EAM se revelam decepcionantes. O dinheiro é investido na parte intermédia: painéis de controlo, quadros de planeamento, aplicações móveis para os responsáveis pelo planeamento. A interface do utilizador, o momento em que um técnico decide o que introduzir, permanece exatamente como estava. O sistema torna-se mais rápido a processar entradas incorretas.

Para um responsável pela manutenção, este princípio oferece um diagnóstico simples. Selecione aleatoriamente 50 pedidos de intervenção recentes e pergunte, para cada um deles, se um planeador teria conseguido definir o âmbito do trabalho sem ter de fazer uma chamada telefónica. Se menos de 30 passarem neste teste, a unidade não tem um problema de planeamento nem de agendamento. Tem um problema na fase de receção dos pedidos, e a solução está na própria fase de receção.

A parte relativa ao encerramento é igualmente importante e, muitas vezes, apresenta resultados piores. Uma ordem de trabalho confirmada com “concluída” e um código de avaria predefinido regista uma reparação, mas não uma falha. O par «pedido-encerramento» constitui a unidade de dados de fiabilidade; se qualquer uma das partes estiver em branco, o registo fica em branco.

De que forma é que o processo de registo nativo de IA melhora a qualidade dos pedidos de trabalho sem adicionar campos?

A única abordagem que tem funcionado em grande escala consiste em transferir a responsabilidade pela qualidade do técnico para o próprio processo de receção. O técnico descreve o problema tal como o faria a um colega, por voz ou com uma fotografia, e o sistema encarrega-se da estruturação: identifica o equipamento a partir da localização e da imagem, redige o texto detalhado, propõe os códigos de avaria e de objeto a partir da biblioteca de listas de tarefas e faz as poucas perguntas que um bom planeador faria. O técnico limita-se a verificar, em vez de escrever.

É assim que o módulo de ordens de trabalho do MRO360 gere o registo de pedidos. Na prática, realiza quatro ações na fase de solicitação.

• Imagens captadas no terreno, não no terminal. Entrada de voz e fotografia; saída de uma notificação completa e codificada, com a localização funcional, o equipamento e o texto descritivo já preenchidos, para que o autor confirme.
• Faz as sete perguntas, e apenas essas. Já está desligado? Existe um desvio? Horário de pico? Que equipamentos? Alguma ferramenta especializada? Algum impacto na segurança? As perguntas adaptam-se à classe do equipamento, pelo que não se perguntam a um corpo de iluminação sobre o isolamento energético.
• Verifica se existem duplicados antes de os criar. Se já existir um pedido em aberto relativo a esse equipamento, o novo pedido é integrado nesse pedido, em vez de ser criado, mantendo-se a data e hora mais antigas, para que o contador do MTTR esteja correto.
• Carrega previamente o plano de trabalho. Quando o operador dispõe de listas de tarefas associadas a códigos de objeto e de danos, o plano correspondente, a lista de materiais e os requisitos de autorização são anexados no momento do pedido, pelo que o planeador abre um rascunho de ordem de trabalho em vez de uma ordem em branco.

O profissional com quem trabalhámos referiu que este tipo de «comunicação com o sistema» captava exatamente o que acabaria por levar as equipas no terreno a utilizar o CMMS de forma adequada. Referiu ainda que vários fornecedores estão a competir para alcançar esse objetivo, razão pela qual consideramos a captura sem atritos como um requisito mínimo e o questionário de admissão de sete perguntas e a regra de duplicação como os elementos que alteram a carga de trabalho dos planeadores.

O que isto não faz é isentar ninguém da obrigação de cumprir as regras. As perguntas continuam a exigir respostas sinceras e o encerramento do serviço continua a exigir um código de avaria válido. O sistema elimina a necessidade de digitar e a navegação, que são as razões pelas quais os técnicos ignoram esses campos. Não elimina, porém, a necessidade de tomar decisões.

Perguntas frequentes

Qual é a diferença entre um pedido de intervenção e uma ordem de trabalho? Um pedido de intervenção (uma notificação no SAP PM) regista que foi detetado um problema que requer atenção. Uma ordem de trabalho autoriza e planeia o trabalho necessário para resolver o problema, incluindo mão-de-obra, peças, autorizações e um calendário. Cada ordem de trabalho deve ser atribuída a uma solicitação; nem todas as solicitações se transformam em ordens de trabalho, porque algumas são duplicadas, outras são recusadas e outras ainda são tratadas como rondas de inspeção do operador.

O que é uma notificação de manutenção no SAP PM? Uma notificação de manutenção é o termo utilizado pela SAP para designar um pedido de intervenção. Inclui o objeto de referência (local de instalação ou equipamento), um texto breve e um texto descritivo, a prioridade, o indicador de avaria e códigos opcionais relativos ao objeto, ao dano e à causa. Os tipos de notificação M1 (relatório de avaria), M2 (pedido de manutenção) e M3 (relatório de atividade) são os três tipos padrão, embora a maioria dos operadores configure os seus próprios tipos.

Que campos deve incluir um trabalho de manutenção? No mínimo: o equipamento ou local de instalação, se o ativo se encontra atualmente fora de serviço, se existe um desvio ou uma unidade redundante disponível, uma estimativa do número de horas, as especialidades técnicas necessárias, quaisquer ferramentas especializadas e o impacto em termos de segurança ou ambientais. Estes sete elementos permitem que um planeador avalie o âmbito do trabalho sem ter de contactar o autor da solicitação.

O que é o indicador de avaria no SAP e por que é importante? O indicador de avaria é uma caixa de seleção na notificação do SAP que assinala o equipamento como avariado no momento da comunicação. É o único campo padrão que indica ao responsável pelo planeamento que o ativo se encontra fora de serviço neste momento, e é o que o SAP utiliza para calcular o MTBF e o MTTR. As instalações que não o definem de forma consistente não podem confiar em nenhuma destas métricas.

Por que razão os planeadores dedicam tanto tempo aos pedidos de trabalho? Como a maioria dos pedidos chega apenas com uma localização e uma descrição de uma linha, os responsáveis pelo planeamento têm de contactar o autor do pedido, inspecionar o bem ou fazer suposições antes de poderem definir o âmbito do trabalho. Os inquéritos aos responsáveis pelo planeamento da manutenção revelam, de forma consistente, que a sua semana é dedicada a este tipo de tarefas, em vez de à elaboração de planos de trabalho.

De que forma é que os pedidos de intervenção duplicados afetam o MTBF? Cada pedido convertido numa ordem de trabalho é contabilizado como uma falha. Se forem registados três pedidos relativos a um mesmo evento e todos os três forem processados ou encerrados como concluídos, o local regista três falhas e o seu MTBF para esse ativo diminui em dois terços. A solução consiste em manter o pedido mais antigo e cancelar os restantes com um código de motivo de duplicação.

Todas as solicitações de trabalho devem ser convertidas em ordens de trabalho? Não. Os pedidos devem ser analisados primeiro para verificar se existem duplicados, se o trabalho já está abrangido por uma ordem em aberto ou por uma manutenção preventiva agendada e se há itens que possam ser tratados como tarefas do operador. Converter tudo aumenta o volume de trabalho pendente e prejudica a deteção de falhas.

Os campos obrigatórios melhoram a qualidade dos pedidos de intervenção? Normalmente, não. Os campos obrigatórios garantem que seja introduzido um valor, mas não que esse valor esteja correto. Nos sites que exigem a indicação de códigos de danos, é comum que uma grande parte dos casos seja classificada como “outros” ou como a primeira opção da lista. Os dados parecem completos, mas estão errados, o que é mais difícil de detetar do que a falta de dados.

Como é que se avalia a qualidade dos pedidos de trabalho? O teste mais simples é a taxa de planificabilidade: a percentagem de pedidos que um planificador consegue avaliar sem contactar o autor do pedido. Selecione 50 pedidos recentes e atribua uma pontuação a cada um. Outros indicadores de apoio são a taxa de duplicados, a percentagem de pedidos apresentados relativamente a um local principal, em vez de a um equipamento, e a percentagem de ordens de trabalho encerradas com um código de dano por defeito ou “outro”.

A IA pode redigir o pedido de intervenção para o técnico? O sistema de registo nativo de IA pode redigir o documento. A partir de uma descrição oral e de uma fotografia, o sistema consegue identificar o equipamento, sugerir o texto detalhado e os códigos, verificar se existem duplicados e fazer ao autor as poucas perguntas que um planeador faria. O técnico limita-se a confirmar, em vez de ter de escrever. Esta é a abordagem utilizada no módulo de ordens de trabalho do MRO360.

Quem é responsável pela qualidade dos pedidos de intervenção: as operações ou a manutenção? Ambos, mas o poder de decisão recai sobre as operações, porque são os operadores e os técnicos que apresentam a maioria dos pedidos. A manutenção é responsável pela norma (o que um pedido planificável deve conter) e pelo processo de receção que facilita o cumprimento dessa norma. Nas instalações onde apenas a manutenção se preocupa com a qualidade dos pedidos, a triagem feita pelos planeadores acaba por se tornar a solução permanente.

Veja quanto lhe estão a custar os seus pedidos de trabalho

Se mais de um terço da sua carteira de trabalhos necessitar de uma chamada telefónica antes de poder ser planeado, o problema está a montante dos seus planeadores. Iremos realizar o teste de planificabilidade numa amostra das suas notificações recentes, mostrar-lhe a taxa de duplicados e de codificação incorreta e explicar-lhe como o processamento de entradas baseado em IA no MRO360 altera o que chega à secretária do planeador.

Marque uma avaliação de 30 minutos para um pedido de trabalho. Traga 50 notificações recentes; nós encarregamo-nos da pontuação.