A mesma falha reaparece no mesmo equipamento. A OS é aberta, o técnico atende, o chamado é encerrado. Duas semanas depois, o equipamento volta à bancada pelo mesmo sintoma. A primeira reação de muitos gestores de EC é questionar o técnico que fez o reparo anterior. O dado da OS, se estiver corretamente preenchido, frequentemente aponta para outra direção. Será necessário fazer uma análise das OS passadas.
Reincidência é o retorno de OS ao mesmo equipamento pelo mesmo tipo de falha dentro de um prazo determinado, geralmente 30 dias. A reincidência é um sinal de processo antes de ser um sinal de competência individual. Quando o mesmo padrão aparece em diferentes técnicos atendendo o mesmo modelo de equipamento, a causa está no acesso à informação, no protocolo de diagnóstico ou na disponibilidade de peça, não na habilidade de quem executou o reparo.
Causa-raiz é a falha de origem que, se corrigida, elimina a recorrência. Um monitor multiparâmetro que retorna três vezes em 90 dias com registro de "falha no sensor de SpO2″ pode ter três causas distintas: cabo com defeito de fabricação, dano mecânico por manuseio inadequado, ou versão de firmware desatualizada que produz leitura incorreta interpretada como falha de sensor. Registrar "falha de sensor" nas três OS encobre as três causas e inviabiliza qualquer análise de padrão.
A análise de causa-raiz efetiva começa no campo de diagnóstico da OS. Campos de texto livre não permitem agregação em escala — um setor com 300 OS por mês e campo de causa-raiz aberto gera 300 registros que não podem ser agrupados sem revisão manual. Categorias predefinidas como falha mecânica, falha elétrica, falha de software, erro de uso e falha de peça permitem filtrar por tipo de causa e identificar qual categoria concentra o maior volume de reincidências.
A frequência de reincidência por categoria de causa é o dado que distingue problema de treinamento de problema de estoque de peças. Se reincidências estão concentradas em falha de peça, a causa provável é peça de qualidade inferior ou incorreta para o modelo. Se estão concentradas em falha de software, a causa provável é ausência de protocolo de atualização de firmware. Nenhuma das duas tem relação com a competência do técnico que fez o atendimento.
MTTR agrega quatro tempos distintos: diagnóstico, deslocamento, espera por peça e execução do reparo. Quando o MTTR de um equipamento aumenta, o aumento pode estar em qualquer dos quatro. Registrar apenas o tempo total não permite identificar onde está o gargalo.
Suponha que dois técnicos atendam o mesmo modelo de equipamento com MTTR médio de 6 horas cada. O primeiro gasta 1 hora em diagnóstico e 4 horas aguardando peça. O segundo gasta 3 horas em diagnóstico e 1 hora aguardando peça. O MTTR agregado trata os dois como iguais. O dado desagregado revela problemas distintos: o primeiro tem problema de gestão de estoque; o segundo tem problema de acesso ao histórico do equipamento ou ao protocolo de diagnóstico para aquele modelo.
Uma gestão baseada em MTTR agregado pode interpretar o segundo técnico como menos hábil. Uma gestão baseada em dado desagregado vai investigar o que o segundo técnico não tem acesso — manual atualizado, histórico de falhas anteriores do ativo, ferramenta de diagnóstico específica para o modelo. A diferença entre as duas abordagens não é de interpretação: é do dado que cada uma coleta.
Registrar tempo de espera por peça em campo separado do tempo de execução transforma o MTTR em dado diagnóstico. Um setor que identifica que 40% do MTTR médio corresponde a espera por peça tem um problema de gestão de estoque mensurável — não um problema de desempenho de equipe.
O dado de OS produz diagnóstico de processo quando é coletado sem pressão para fechar chamado rapidamente. Em setores onde MTTR individual é monitorado como métrica de desempenho pessoal, há incentivo para encerrar OS antes da conclusão do reparo ou registrar causa genérica para reduzir o tempo de fechamento. O indicador se torna ferramenta de controle, não de análise.
A ABNT NBR ISO 55001:2014, norma de gestão de ativos, estabelece que informação sobre manutenção deve suportar decisões sobre o desempenho do ativo ao longo do seu ciclo de vida [verificar se a norma contém linguagem explícita sobre uso do dado de OS antes de publicar com essa atribuição]. O dado de tempo de reparo serve para avaliar o processo — se o ativo está sendo mantido adequadamente — não para avaliar o executante.
Os indicadores que revelam qualidade do processo de uma equipe são: first-time fix rate por tipo de falha, taxa de reincidência por categoria de causa e percentual de OS com causa-raiz categorizada. Nenhum dos três mede velocidade individual — os três medem se o processo está produzindo resultado correto na primeira tentativa.
Sistemas de gestão de manutenção com campos obrigatórios estruturados tornam a desagregação do tempo de reparo possível sem esforço manual. O dado só existe se o campo existiu antes do técnico abrir a OS.
Descubra como o CMMS da Arkmeds calcula MTTR e taxa de reincidência a partir das OS:
P: Como distinguir erro do técnico de falha de processo na análise de OS? R: Erro de técnico produz falha isolada, sem padrão por tipo de equipamento, modelo ou causa. Falha de processo produz padrão: mesmo tipo de falha recorrente em diferentes técnicos, ou mesma etapa do reparo que resulta em reincidência repetidamente. Quando três técnicos diferentes produzem reincidência no mesmo modelo de equipamento, a causa provável é ausência de informação de diagnóstico, não deficiência técnica individual.
P: Qual campo é mais importante em uma OS do ponto de vista analítico? R: O campo de causa-raiz com categorias predefinidas. Campos de texto livre geram registros não agregáveis. O campo de número de série do equipamento é o segundo mais crítico: sem ele, não é possível vincular histórico de falhas a um ativo específico e calcular indicadores por equipamento.
P: Como engajar a equipe a preencher OS corretamente sem criar resistência? R: Reduzir campos obrigatórios ao mínimo analítico: número de série, data de abertura e encerramento, categoria de causa-raiz e custo de peças. Formulários com mais de dez campos obrigatórios geram preenchimento parcial sistematicamente. Mostrar para a equipe um exemplo de análise feita com os dados deles — uma reincidência identificada, um problema de estoque detectado — aumenta a percepção de utilidade do preenchimento.
P: Faz sentido comparar MTTR entre técnicos da mesma equipe? R: A comparação só é informativa quando controlada pelo tipo de equipamento atendido. Um técnico que atende principalmente equipamentos de suporte de vida vai apresentar MTTR mais alto do que um que atende equipamentos de diagnóstico, pela diferença de complexidade e criticidade do atendimento. Comparação de MTTR individual sem esse controle produz ranking sem significado.
P: Com que frequência a análise de causa-raiz deve ser feita? R: Mensalmente para equipamentos com duas ou mais OS no período e semanalmente para equipamentos com reincidência dentro de 30 dias. A análise mensal identifica padrões de degradação; a análise semanal de reincidências identifica reparos incompletos antes que se tornem padrão.