MTBF e MTTR na manutenção: como calcular, exemplo resolvido e os erros que inflam a disponibilidade

MTBF vem de mean time between failures: tempo médio entre falhas. Mede confiabilidade — quanto tempo, em média, o ativo cumpre a função antes de parar por falha.

MTBF = tempo em operação ÷ número de falhas

O que decide se o número serve para alguma coisa são três definições que quase ninguém escreve:

1. A base de tempo. Câmara fria e expositor refrigerado precisam cumprir a função 24 horas por dia: a base é o tempo de calendário menos o tempo parado por falha. Para um compressor dentro de um rack com rodízio, pode fazer sentido usar o horímetro, porque é o funcionamento que desgasta. Na climatização do salão, só conta o horário de loja aberta.
2. O que é falha. Falha é perda de função não planejada: câmara que sai da faixa, compressor que para e não volta sozinho, equipamento que exigiu intervenção. Preventiva programada não é falha. Degelo não é falha — degelo que trava é.
3. O nível do ativo. MTBF da câmara, do compressor ou da loja inteira são três números diferentes. Misturar níveis no mesmo relatório produz comparação sem sentido.

E um aviso que evita decisão errada: MTBF é média, não prazo. Um MTBF de 1.200 horas não quer dizer que o compressor vai quebrar na hora 1.200. Boa parte das falhas em refrigeração não segue calendário — vem de condensador sujo, vazamento lento, degelo mal ajustado — e dá aviso antes em corrente, pressão e temperatura. Quem quer saber quando intervir olha para os sinais de que o compressor vai quebrar, não para a média.

MTTR vem de mean time to repair — há quem use restore, restabelecer, que descreve melhor o que interessa. Mede quanto tempo, em média, o ativo fica fora de função cada vez que falha.

MTTR = tempo total parado por falha ÷ número de falhas

A discussão toda está nas duas pontas do relógio.

• O relógio começa na falha real. Não quando o gerente percebeu, não quando alguém ligou, não na abertura da OS. Se o compressor parou à 1h e a OS foi aberta às 6h, as cinco horas entre uma coisa e outra são tempo parado — o produto estava lá dentro, esquentando.
• O relógio para quando a função volta. Para uma câmara fria, isso é temperatura de volta à faixa, não técnico guardando a ferramenta. Depois de horas parada, uma câmara de congelados pode demorar a voltar ao setpoint, conforme a carga que está dentro e a capacidade do sistema.

Muita equipe chama de MTTR o tempo de mão na ferramenta. Esse número existe e é útil, mas é um pedaço. Se a fórmula de disponibilidade receber só o pedaço, ela vai dizer que o ativo estava disponível durante horas em que a câmara estava fora de faixa e ninguém sabia.

O tempo parado completo tem quatro partes: detecção (da falha até alguém saber), resposta e deslocamento (até o técnico estar no ativo), reparo (diagnóstico, espera de peça e execução) e recuperação (até a temperatura voltar à faixa). Somadas, entram no MTTR. Separadas, dizem onde agir.

Disponibilidade = MTBF ÷ (MTBF + MTTR)

É a fração do tempo requerido em que o ativo cumpriu a função. Com o MTBF definido como tempo em operação, a conta é equivalente a outra, mais intuitiva:

Disponibilidade = (tempo requerido − tempo parado por falha) ÷ tempo requerido

Os dois caminhos dão o mesmo número. Dois cuidados de convenção:

• Há literatura que define MTBF como o intervalo entre o início de uma falha e o início da seguinte, com o reparo dentro. Nesse caso a fórmula vira 1 − MTTR ÷ MTBF. As duas convenções estão corretas; misturar as duas no mesmo relatório não está.
• Se o MTTR usado for só o tempo de reparo, a fórmula entrega uma disponibilidade teórica — a que o ativo teria se a falha fosse descoberta no instante em que acontece e a peça estivesse ao lado. Para saber quanto tempo a câmara realmente ficou fora de função, o MTTR precisa ser o tempo parado inteiro.

A fórmula mostra as duas alavancas, com orçamentos diferentes: falhar menos (estado do parque, preventiva, antecipar a falha) ou restabelecer mais rápido (detecção, plantão, peça em estoque, diagnóstico).

E um aviso sobre o percentual: disponibilidade alta engana em refrigeração. Um mês de 30 dias tem 720 horas; 99,5% de disponibilidade são 3,6 horas de câmara parada. Com a câmara de congelados cheia, essas horas podem decidir o destino de um lote — e não aparecem no percentual. Reporte as horas junto com a porcentagem; para transformá-las em reais diante da diretoria, veja o business case de monitoramento.

Exemplo hipotético, com números redondos para a conta ficar visível. Suponha uma operação com 10 câmaras frias, cada uma com sua unidade condensadora, todas exigidas 24 horas por dia. Período de apuração: 30 dias. No mês, a manutenção registrou seis falhas:

A coluna de detecção saiu do histórico de temperatura e corrente de cada câmara, comparado com a hora de abertura da OS. As falhas 1 e 3 aconteceram de madrugada — e na mesma câmara.

Passo a passo

1. Tempo requerido: 10 câmaras × 720 h = 7.200 h.
2. Tempo parado por falha: soma da coluna Total = 36 h.
3. Tempo em operação: 7.200 − 36 = 7.164 h.
4. MTBF: 7.164 ÷ 6 = 1.194 h por câmara.
5. MTTR: 36 ÷ 6 = 6 h.
6. Disponibilidade: 1.194 ÷ (1.194 + 6) = 1.194 ÷ 1.200 = 99,5%. Conferindo pelo outro caminho: 7.164 ÷ 7.200 = 99,5%.

O mesmo mês, contado pela OS

Se o relógio começa na abertura da OS e para no fechamento, detecção e recuperação somem. Sobram deslocamento e reparo: 18 h. O MTTR cai para 3 h e a disponibilidade sobe para 99,75%. Metade do tempo parado desapareceu do relatório — justamente a metade em que ninguém estava agindo.

O mesmo mês, com a preventiva contada como falha

Suponha que no mesmo período houve quatro preventivas programadas de 3 h cada. Se entram como falha, são 10 "falhas" e 48 h paradas. O MTBF despenca para cerca de 715 h e o MTTR cai para 4,8 h. O indicador passa a dizer que a operação falha mais e conserta mais rápido — as duas coisas falsas — e pune a equipe por fazer preventiva.

A média da frota esconde o pior ativo

A câmara de congelados 1 teve duas das seis falhas e 15 h parada. Sozinha, o MTBF dela é (720 − 15) ÷ 2, cerca de 350 h, e a disponibilidade, 97,9%. A frota inteira mostra 1.194 h. Quem olha só a média não abre a câmara de congelados 1.

E uma leitura que o MTBF da frota não entrega sozinho: seis falhas em 720 horas de calendário são uma falha a cada cinco dias para a equipe atender, mesmo com cada câmara falhando, em média, a cada 1.194 horas de operação.

A tabela cobre o ciclo inteiro da falha, até a câmara voltar à faixa. A coluna que mais importa é a da origem do dado: fórmula certa com dado errado continua errada.

Os quatro tempos do meio — detecção, resposta e deslocamento, reparo e recuperação — somados dão o MTTR. Por isso vale registrar separado: o MTTR diz quanto; os componentes dizem onde.

Separar os componentes exige marcar sete momentos em cada falha — e eles não vêm da mesma fonte.

1. T0 — falha real. O momento em que a corrente do compressor zerou, em que a temperatura começou a subir com a porta fechada, em que o degelo passou do tempo programado. Só existe com histórico contínuo; sem ele, é estimativa.
2. T1 — detecção. Alarme reconhecido, ligação da loja, alguém que viu o display.
3. T2 — acionamento. OS aberta, técnico próprio ou prestador chamado.
4. T3 — chegada ao ativo. Apontamento do técnico.
5. T4 — diagnóstico concluído. Causa identificada. Se precisa de peça, a espera começa aqui.
6. T5 — reparo concluído. Equipamento religado.
7. T6 — função restabelecida. Temperatura de volta à faixa, lida no histórico.

Com os marcos, cada intervalo ganha um dono e uma alavanca:

• Detecção (T0 → T1) depende de alarme e de alguém olhando fora do horário. Técnico a mais não reduz um minuto dela.
• Resposta e deslocamento (T1 → T3) dependem de plantão, rota e distância entre endereços — e do quanto dá para resolver remotamente antes de alguém sair.
• Reparo (T3 → T5) depende de diagnóstico, capacitação e peça em estoque. Quando o técnico chega sabendo a causa provável, o trecho T3 → T4 encolhe. Espera de peça é logística, não mão de obra: registre à parte.
• Recuperação (T5 → T6) depende da carga térmica dentro da câmara e da capacidade do sistema. Se, para eventos parecidos, a recuperação demora mais do que demorava meses atrás, o sistema perdeu capacidade.

No exemplo da seção anterior, detecção e reparo somam 12 horas cada. Contratar mais um técnico ataca deslocamento e reparo; não toca nas 12 horas em que a câmara estava parada e ninguém sabia.

Quase nenhum desses erros está na fórmula. Estão na regra de apontamento — e, por isso, passam anos sem ninguém perceber.

• Contar parada planejada como falha. Preventiva programada, limpeza de condensador agendada, desligamento para inventário e degelo não são falha. Misturados, derrubam o MTBF e melhoram o MTTR ao mesmo tempo, como no exemplo. Parada planejada tem indicador próprio; o peso de cada modelo está em o custo real da corretiva, da preventiva e da preditiva.
• Usar a abertura da OS como hora da falha. É o erro que mais distorce, porque a diferença é maior justamente nas falhas de madrugada e de fim de semana — as mais caras.
• MTTR que ignora o tempo de detecção. Consequência direta do erro anterior. O número passa a medir a eficiência da equipe depois de avisada, não o tempo que o ativo ficou fora de função.
• Parar o relógio no fechamento da OS. A câmara ainda estava longe do setpoint. A recuperação some do indicador, não do produto.
• Não registrar o desarme que rearma sozinho. O compressor que desarma toda tarde e volta sozinho não gera OS. Pode nem ser falha pela regra da operação, mas precisa ser contado como evento: costuma ser o aviso da próxima OS.
• Fechar OS com "ajustado" ou "normalizado". Sem modo de falha, a reincidência não é calculável e a mesma falha volta como se fosse nova.
• Olhar só a média da frota. O ativo que concentra falhas se dilui nos que não falham. Apure por ativo e cruze com o custo de cada parada — a lógica de priorizar manutenção por criticidade financeira começa exatamente nessa lista.
• Decidir com a janela curta. Com seis falhas no mês, uma a mais ou a menos move o MTBF em algo como 15% a 20%. Apure todo mês, mas decida olhando a janela móvel de 12 meses.
• Comparar lojas ou plantas com regras diferentes. Uma conta degelo como falha, outra não; uma começa na OS, outra no alarme. O ranking que sai daí mede a regra, não a manutenção.

Antes de qualquer sistema, definições escritas e alguns campos na OS resolvem boa parte do problema.

• Escreva o que é falha e o que é evento. Perda de função não planejada — câmara fora da faixa, ativo que exigiu intervenção — é falha; desarme que rearmou sozinho sem tirar a câmara da faixa é evento, contado à parte.
• Defina a base de tempo por tipo de ativo. Calendário para câmaras e expositores, horário de funcionamento para a climatização do salão, horímetro para compressor em rodízio, se fizer sentido.
• Defina onde o relógio começa e onde para. Falha real e volta à faixa.
• Acrescente campos na OS: hora real da falha e a fonte dessa hora (histórico, alarme ou estimativa), chegada ao ativo, fim do diagnóstico, chegada da peça, fim do reparo, volta à faixa e modo de falha em lista fechada.
• Deixe as estimativas visíveis no relatório: mostram quanto do indicador é palpite.
• Apure todo mês, por ativo e por frota, com a janela móvel de 12 meses ao lado.
• Reporte horas e percentual juntos, e os componentes do MTTR separados.

O campo que mais vai faltar é o primeiro: hora real da falha. Sem dado contínuo, ele vai ser preenchido com a hora da abertura ou com um palpite — e é aí que a apuração precisa de outra fonte.

A ordem de serviço é um registro administrativo: diz quando alguém pediu, foi e fechou. A falha acontece antes, no equipamento, e deixa rastro em variáveis que ninguém está olhando naquela hora. Com medição contínua, a hora exata vem do histórico. Por exemplo: a corrente do compressor zerou à 1h10, a temperatura do ar de retorno começou a subir à 1h15, a OS foi aberta às 6h30. O MTTR deixa de começar às 6h30.

Três coisas mudam no indicador quando essa fonte entra:

1. O MTTR piora nos primeiros meses. A detecção, que era invisível, aparece. Avise a diretoria antes: a manutenção não ficou pior; o indicador ficou honesto.
2. O MTBF pode cair. Falhas que nunca viraram OS — o compressor que o encarregado rearmou de manhã sem avisar ninguém, a câmara que saiu da faixa de madrugada e voltou antes de a loja abrir — passam a ser registradas.
3. A causa entra na OS com evidência. Com corrente, tensão, pressão e temperatura no histórico, o modo de falha deixa de ser "ajustado" e a reincidência passa a ser calculável. É o mesmo dado que sustenta a manutenção preditiva de compressores: a curva que mostra quando a falha aconteceu costuma mostrar também que ela vinha avisando.

É esse dado que a Bit Energy coloca na mão da manutenção. Os dispositivos próprios — Seed para temperatura; Bee e Tree para temperatura, corrente e tensão, com pressões no Tree — ou a integração com os supervisórios que já existem (CAREL, Emerson, Danfoss, Full Gauge, entre outras) alimentam o histórico numa plataforma web. Uma central de monitoramento humana 24/7, com alarmes inteligentes e suporte técnico remoto, trabalha no intervalo que a OS não enxerga: entre a falha e alguém saber. E há API aberta para ERP e software de ordem de serviço, para o histórico conversar com o sistema onde a OS já é aberta. Veja como funciona o serviço de monitoramento 24/7 com gestão técnica.

A hora da falha é um dado de campo. Enquanto ela vier da ordem de serviço, o MTTR mede a burocracia, não a manutenção.