Quem já tentou calcular indicadores de confiabilidade a partir de planilhas herdadas, ordens de serviço preenchidas em texto livre ou cadernos de campo conhece o problema: os números existem, mas não sustentam uma decisão. A dificuldade raramente está na fórmula — está na base que a alimenta. Este artigo mostra como estruturar o histórico de falhas para análise de confiabilidade, tratando dos campos obrigatórios, da taxonomia aplicada ao cadastro, dos critérios de validação e da recuperação de registros legados.
O que é histórico de falhas e por que ele é a base da análise de confiabilidade
Histórico de falhas é o conjunto estruturado de registros sobre eventos em que um ativo deixou de desempenhar a função esperada, com dados de identificação, tempo, causa e ação corretiva. Sem esse repositório organizado, qualquer cálculo de MTBF, MTTR ou disponibilidade vira exercício de adivinhação com números que parecem precisos, mas nascem de uma base frágil. A diferença entre uma operação que aprende com as falhas e outra que apenas apaga incêndios está exatamente na qualidade do acervo que documenta cada ocorrência.
Na prática, a análise de confiabilidade é um processo estatístico e de engenharia que depende de amostras representativas do comportamento real dos equipamentos. Um histórico incompleto, duplicado ou com terminologia inconsistente introduz viés antes mesmo da primeira fórmula ser aplicada. Por isso, estruturar o histórico não é burocracia: é a etapa que transforma a experiência dispersa da equipe em um ativo de conhecimento mensurável e auditável.
Histórico de falhas, registro de manutenção e diagnóstico: fronteiras entre os conceitos
O registro de manutenção documenta qualquer intervenção planejada ou corretiva, incluindo preventivas, lubrificações, inspeções e calibrações — mesmo quando nada falhou. Já o histórico de falhas é um subconjunto específico: reúne apenas os eventos de perda de função, com o detalhamento necessário para entender por que a falha ocorreu e como se comportou ao longo do tempo. O diagnóstico, por sua vez, é o resultado da investigação técnica sobre uma falha específica, geralmente expresso como causa provável ou causa raiz.
Confundir essas três camadas gera um erro clássico: a equipe registra a troca de um rolamento como “manutenção executada”, mas não registra que o rolamento falhou por desgaste prematuro, em qual posição, após quantas horas de operação e sob qual condição de carga. O histórico de falhas exige esse segundo nível de detalhe, porque é ele que permite distinguir uma falha isolada de um padrão sistêmico.
- Registro de manutenção: qualquer intervenção, inclusive preventiva
- Histórico de falhas: apenas eventos de perda de função, com causa e contexto
- Diagnóstico: investigação técnica de uma falha específica
O que muda quando o histórico é estruturado em vez de narrativo
Um histórico narrativo é aquele em que o técnico escreve um texto livre do tipo “máquina parou de manhã, trocamos a correia e voltou a funcionar”. Esse formato impede agrupamento, filtragem e cálculo automatizado, porque a informação relevante está presa em frases ambíguas. O histórico estruturado substitui a narrativa por campos padronizados com tipo de dado definido, permitindo que cada registro seja comparável aos demais.
A estruturação também muda a governança do dado: um campo “modo de falha” preenchido a partir de uma lista controlada pode ser contado, cruzado e priorizado. Um parágrafo de texto livre não. A NBR ISO 14224, norma de referência para coleta e troca de dados de confiabilidade e manutenção, parte exatamente desse princípio: dados só têm valor analítico quando são coletados de forma consistente, com taxonomia definida e limites claros de fronteira entre equipamentos.
Quais campos um registro de falha precisa ter para virar dado analisável
Um registro de falha só vira dado analisável quando cada campo tem definição operacional, tipo de dado e regra de obrigatoriedade. Não basta listar “data, equipamento e descrição” em um formulário: é preciso definir o formato da data, o identificador único do ativo e o vocabulário controlado da descrição. Campos vagos geram registros vagos, e registros vagos contaminam qualquer indicador que dependa deles.
Os campos essenciais se organizam em três blocos: identificação e contexto, linha do tempo e investigação. Cada bloco responde a uma pergunta diferente da análise de confiabilidade — “onde e em que condições falhou?”, “quanto tempo durou a indisponibilidade?” e “por que falhou e o que foi feito?”. A ausência de um bloco inteiro inviabiliza uma família inteira de análises.
Identificação do ativo, modo de falha e contexto operacional
O campo de identificação do ativo deve usar um código único, geralmente derivado de uma estrutura hierárquica do tipo planta > área > sistema > equipamento > componente, conhecida como tag ou functional location. Sem esse identificador estável, o mesmo equipamento pode aparecer com três nomes diferentes ao longo dos anos, fragmentando o histórico e impedindo a análise de reincidência. O modo de falha descreve a forma observável da perda de função — como “vazamento externo”, “vibração excessiva”, “não parte” ou “perda de vazão”.
O contexto operacional completa o bloco com dados que afetam diretamente a interpretação da falha: condição de operação no momento do evento, carga, ambiente, fluido processado e regime de trabalho. Uma falha de rolamento sob carga nominal tem significado estatístico diferente de uma falha sob sobrecarga declarada. Sem esse contexto, a análise tende a atribuir ao equipamento problemas que na verdade vieram da operação.
- Tag ou código único do ativo, ligado à hierarquia de equipamentos
- Modo de falha observado, em vocabulário controlado
- Condição operacional, carga e ambiente no momento da falha
Campos de tempo: detecção, início da intervenção, retorno à operação
Os campos de tempo definem a base de cálculo do MTTR, do tempo de indisponibilidade e da disponibilidade. O ideal é registrar três marcos: o instante em que a falha foi detectada, o instante em que a intervenção efetivamente começou e o instante em que o ativo voltou a operar em condição normal. A diferença entre detecção e início da intervenção revela o tempo de espera por equipe, peça ou decisão; a diferença entre início e retorno revela o tempo ativo de reparo.
Muitas organizações registram apenas a data, sem hora, o que torna impossível calcular MTTR com precisão para falhas de curta duração. Para ativos críticos, a granularidade recomendada é de minutos; para ativos de baixa criticidade, a hora pode ser suficiente. O importante é que a regra seja uniforme, para que um registro em horas não se misture a outro em dias dentro da mesma base.
Causa provável, ação executada e evidências anexadas
O campo de causa provável registra a conclusão técnica do diagnóstico no momento do fechamento da ocorrência, distinguindo-se da causa raiz, que pode demandar uma análise mais profunda como RCA ou 5 Porquês. A ação executada descreve o que foi feito para restaurar a função: substituição de componente, ajuste, limpeza, reparo ou reconfiguração. Esse campo alimenta diretamente a análise de Pareto e a revisão de planos preventivos.
Evidências anexadas — fotos, laudos, curvas de tendência, relatórios de análise de óleo ou termografia — transformam o registro em material auditável. Um histórico com evidências permite reabrir casos antigos quando um padrão emerge, sem depender da memória de quem atendeu a ocorrência. A ausência de evidência, por outro lado, reduz o registro a uma opinião não verificável.
Taxonomia e padronização: como classificar falhas sem criar um dicionário inútil
A taxonomia de falhas é o vocabulário controlado que permite agrupar eventos semelhantes e comparar o comportamento de ativos diferentes. O erro mais comum é criar listas enormes com dezenas de modos de falha sobrepostos, que ninguém consegue usar no campo e que geram classificações inconsistentes. Uma boa taxonomia é pequena o suficiente para ser memorizável e específica o suficiente para separar eventos que exigem respostas diferentes.
A padronização deve cobrir três níveis: a hierarquia do equipamento, os modos de falha e as causas. Cada nível tem regras próprias de granularidade e fronteira, e a NBR ISO 14224 oferece um modelo de referência consolidado para o setor de petróleo e gás, adaptável a outros segmentos industriais. O objetivo não é seguir a norma por obrigação, mas usar sua lógica de fronteiras e definições para evitar ambiguidade.
Estrutura hierárquica de equipamento e limites de fronteira
A estrutura hierárquica organiza os ativos em níveis, como planta, unidade, sistema, equipamento e componente, e cada nível tem uma fronteira definida por limites físicos ou funcionais. A NBR ISO 14224 define boundary como o conjunto de limites que determina o que pertence e o que não pertence a cada item da hierarquia. Sem essa definição, uma falha na vedação de uma bomba pode ser registrada como falha da bomba, do selo ou do sistema de bombeamento, dependendo de quem preenche.
Na prática, a fronteira mais útil é a do nível “equipamento”, que concentra a maior parte das análises de confiabilidade: a bomba é um equipamento; seu selo mecânico é um componente dela. Falhas no selo são registradas no equipamento bomba, com o componente identificado em campo próprio. Isso permite calcular o MTBF da bomba sem que cada detalhe de componente fragmente a amostra em grupos pequenos demais para análise estatística.
Modos de falha padronizados e o papel da NBR ISO 14224
Modo de falha é a forma observável da perda de função, e a NBR ISO 14224 propõe categorias como falha estrutural, vazamento, desvio de parâmetro, falha de instrumentação e falha funcional. O valor dessa padronização está em permitir que a mesma linguagem seja usada por equipes diferentes, plantas diferentes e até empresas diferentes, viabilizando comparações de desempenho e benchmarks setoriais.
Para uma operação específica, a lista de modos deve ser enxuta — tipicamente entre dez e vinte opções por classe de equipamento —, cobrindo os eventos que de fato ocorrem. Um modo como “falha mecânica genérica” não agrega valor analítico e deve ser evitado; se a equipe não consegue classificar melhor, o problema é de diagnóstico, não de taxonomia. A regra prática é: cada modo de falha precisa apontar para um tipo de ação preventiva ou preditiva diferente.
Codificação de causas e a diferença entre sintoma, mecanismo e causa raiz
Sintoma é o que se observa — vibração, ruído, aquecimento, vazamento. Mecanismo é o processo físico que produz o sintoma — fadiga, corrosão, erosão, desgaste adesivo. Causa raiz é o fator originário que desencadeou o mecanismo — erro de montagem, lubrificação inadequada, sobrecarga, especificação incorreta. Um histórico bem estruturado separa esses três níveis, porque cada um exige uma resposta diferente da engenharia de manutenção.
O campo de causa no registro de falha deve capturar pelo menos o mecanismo, com um campo opcional para a causa raiz quando a investigação avançar. Classificar a causa apenas pelo sintoma — “causa: vibração” — é um erro que impede qualquer análise de recorrência por mecanismo. A codificação de causas, assim como a de modos, deve usar lista controlada e ser validada por quem executa o diagnóstico, não por quem apenas abre a ordem de serviço.
Do registro solto ao histórico confiável: captura, validação e qualidade de dados
O histórico confiável nasce de um processo de captura disciplinado, passa por validação e só então alimenta indicadores. Tratar o registro como obrigação administrativa no fechamento da ordem de serviço gera dados de baixa qualidade; tratar como insumo de decisão muda o comportamento de quem preenche. A diferença operacional está em definir quem valida, o que é validado e o que acontece quando um registro não passa na checagem.
A captura deve estar integrada ao fluxo de manutenção, preferencialmente dentro do CMMS ou sistema de gestão de ordens de serviço, para que o técnico não precise preencher dois formulários. A validação, por sua vez, é uma etapa separada da captura: um supervisor, planejador ou engenheiro de confiabilidade revisa o registro antes de liberá-lo para a base analítica. Essa revisão verifica consistência de taxonomia, completude dos campos de tempo e coerência entre causa e ação executada.
Integração com ordens de serviço e o que preencher no fechamento da OS
A ordem de serviço é o veículo natural de captura do registro de falha, porque já contém ativo, data, equipe e descrição do trabalho. No fechamento, o técnico deve preencher os campos específicos de falha: modo de falha observado, causa provável, componente afetado, horários de detecção, início e fim da intervenção, e ação executada. O campo “descrição do serviço” continua existindo para o relato livre, mas não substitui os campos estruturados.
Um ponto crítico é impedir o fechamento da OS sem os campos obrigatórios de falha preenchidos — quando a OS é de natureza corretiva. Sistemas que permitem fechamento com campos vazios geram lacunas silenciosas no histórico. A regra de obrigatoriedade deve ser configurada no fluxo do sistema, não depender da boa vontade do técnico no fim do turno.
- OS corretiva exige campos de falha obrigatórios no fechamento
- Campos estruturados convivem com descrição livre, mas não são substituídos por ela
- Validação por supervisor ou engenheiro antes de liberar para análise
Erros de preenchimento que destroem o histórico e como tratá-los
Os erros mais destrutivos são sistemáticos, não eventuais: escolher sempre o primeiro modo de falha da lista, usar “outros” como categoria padrão, registrar apenas a data sem hora, e confundir causa com sintoma. Esses padrões indicam que o formulário é difícil, a taxonomia não faz sentido para o campo ou não há consequência para o preenchimento incorreto. Tratar o erro exige identificar o padrão por amostragem e corrigir a causa do padrão, não apenas reclassificar registros antigos.
Erros aleatórios, como digitação incorreta de horário ou seleção equivocada de componente, podem ser mitigados com validação por faixa — por exemplo, rejeitar MTTR negativo ou superior a um limite plausível. A auditoria periódica do histórico, com amostragem de registros e confronto com ordens de serviço e relatórios de turno, é o instrumento que mantém a qualidade ao longo do tempo. Sem auditoria, a qualidade degrada silenciosamente em poucos meses.
Dados censurados, falhas não registradas e o efeito no cálculo de confiabilidade
Dado censurado é aquele em que o evento de interesse não foi observado até o fim do período de análise — por exemplo, um equipamento que ainda não falhou quando o estudo é encerrado. Na análise de confiabilidade, esses dados são informação valiosa e devem ser incluídos com métodos estatísticos próprios, como estimadores de Kaplan-Meier. Descartar equipamentos que não falharam, considerando apenas os que falharam, superestima a taxa de falha e distorce o MTBF.
Falhas não registradas são um problema diferente e mais grave: eventos que ocorreram, mas não entraram no histórico, seja por reparo informal, seja por registro em sistema paralelo ou em papel. Cada falha omitida reduz artificialmente o numerador de falhas e infla o MTBF calculado, passando uma impressão de confiabilidade que não existe. A estimativa do percentual de sub-registro pode ser feita cruzando o histórico com consumo de peças, relatórios de produção e registros de turno.
Como o histórico estruturado alimenta MTBF, MTTR e disponibilidade
MTBF, MTTR e disponibilidade são indicadores derivados diretamente dos campos de tempo e identificação do histórico. O MTBF (tempo médio entre falhas) usa o tempo total de operação dividido pelo número de falhas no período; o MTTR (tempo médio para reparo) usa a soma dos tempos de reparo dividida pelo número de intervenções corretivas; a disponibilidade combina tempo de operação e tempo de indisponibilidade. A precisão de cada um depende da consistência com que os campos de tempo foram registrados.
As premissas de cálculo precisam ser explícitas e uniformes: o MTBF considera apenas falhas funcionais ou também paradas operacionais? O MTTR conta desde a detecção ou desde o início da intervenção? A disponibilidade inclui paradas programadas? Cada escolha muda o número final, e misturar premissas entre períodos ou entre áreas torna a comparação inválida.
Cálculo dos indicadores a partir do histórico: premissas que mudam o resultado
Uma premissa decisiva é o denominador do MTBF: tempo calendário, tempo de operação real ou tempo de operação equivalente. Usar tempo calendário quando o equipamento opera apenas um turno penaliza o indicador; usar tempo de operação real exige medição confiável de horas trabalhadas. A escolha deve ser documentada e mantida estável, para que a evolução do indicador reflita mudança real de desempenho, não mudança de critério.
No MTTR, a premissa central é o marco inicial: detecção, diagnóstico, chegada da equipe ou início efetivo do reparo. Cada definição mede uma coisa diferente — tempo logístico, tempo de diagnóstico ou tempo de execução —, e a equipe de confiabilidade precisa saber qual delas está sendo usada. O ideal é registrar os três marcos e calcular variantes do MTTR, como MTTR logístico e MTTR ativo, para direcionar a ação correta.
Análise de tendência, reincidência e priorização por Pareto
A análise de tendência acompanha a evolução do MTBF e do MTTR ao longo do tempo, preferencialmente em janelas móveis, para detectar degradação antes que ela vire indisponibilidade crônica. Uma queda consistente do MTBF em três janelas consecutivas sinaliza mudança de condição operacional ou fim de vida útil, mesmo que nenhuma falha isolada seja grave. O histórico estruturado permite essa leitura porque os dados são comparáveis entre períodos.
A reincidência é a repetição do mesmo modo de falha no mesmo ativo ou componente, e sua análise exige taxonomia consistente — sem ela, a mesma falha aparece com nomes diferentes e o padrão fica invisível. O Pareto, aplicado sobre modos de falha e causas, revela que tipicamente poucos modos concentram a maioria das paradas e custos. Essa priorização orienta a revisão de planos preventivos e os esforços de priorização de equipamentos críticos com base em evidência, não em percepção.
Do histórico à decisão: RCM, planos preventivos e reparar ou substituir
O histórico estruturado é o insumo primário das decisões de manutenção centrada em confiabilidade (RCM), da revisão de intervalos preventivos e da análise de substituição versus reparo. Cada falha registrada com modo, causa e consequência é um ponto de evidência sobre a eficácia da estratégia atual. Decisões tomadas sem essa base tendem a perpetuar intervalos herdados de manuais antigos e a substituir equipamentos por pressão operacional, sem análise econômica.
O uso do histórico para decisão exige que a base tenha maturidade mínima: taxonomia estável, campos de tempo completos e validação ativa. Um histórico de seis meses com qualidade alta pode orientar decisões táticas; para decisões de substituição ou revisão de estratégia, o ideal é contar com pelo menos dois a três anos de dados consistentes.
Revisão de intervalos de manutenção com base em falhas registradas
O padrão de falhas registrado mostra se o intervalo preventivo atual está adequado, curto demais ou longo demais. Se falhas ocorrem sistematicamente antes do intervalo programado, a preventiva não está protegendo o ativo e o intervalo precisa ser reduzido ou a tarefa substituída por preditiva. Se o histórico mostra zero falhas entre preventivas por anos, o intervalo pode estar excessivamente conservador, gerando custo e indisponibilidade desnecessários.
A revisão de intervalos usa a distribuição dos tempos entre falhas para estimar a probabilidade de falha em função do tempo, permitindo escolher um intervalo que equilibre risco e custo. Essa abordagem substitui a regra de “fazer igual ao ano passado” por uma decisão baseada em evidência, alinhada ao processo de definição de periodicidade da manutenção preventiva. O mesmo histórico indica quando a manutenção preditiva — termografia, análise de vibração, análise de óleo — é mais adequada que a preventiva por tempo.
O que define o custo de uma falha mal registrada
O custo de uma falha mal registrada se materializa em decisões erradas tomadas com base em dados distorcidos. Um MTBF inflado por sub-registro leva a intervalos preventivos longos demais, que resultam em mais paradas não programadas, perda de produção e risco de segurança. Um modo de falha classificado incorretamente desvia o esforço de análise para um componente que não é o problema real.
Há também o custo de retrabalho analítico: quando a equipe de confiabilidade precisa reclassificar manualmente centenas de registros antigos antes de qualquer análise, o tempo de engenharia consumido é custo direto. E, quando a base é considerada inconfiável, decisões de substituição são tomadas com critério puramente financeiro ou operacional, sem o suporte técnico que o histórico deveria fornecer. O custo da má qualidade de dado é, portanto, o custo das decisões piores que ela produz.
Modelo prático de estrutura de histórico de falhas
Um modelo prático de histórico de falhas combina tabela de campos, regras de preenchimento e fluxo de validação. A tabela organiza os campos em obrigatórios e opcionais, com tipo de dado e fonte de preenchimento; o fluxo define quem captura, quem valida e o que acontece com registros reprovados. Esse modelo pode ser implementado em planilha, CMMS ou sistema próprio, desde que as regras sejam as mesmas.
O ponto de partida é definir a unidade de registro: cada linha do histórico representa uma falha funcional de um equipamento, não uma ordem de serviço. Uma OS pode conter mais de uma falha; uma falha pode demandar mais de uma OS. Manter a correspondência um-para-um entre falha e registro é o que permite contar falhas corretamente para o cálculo de MTBF.
Tabela de campos mínimos e opcionais
Os campos mínimos são aqueles sem os quais o registro não pode ser validado: identificação do ativo, data e hora de detecção, data e hora de retorno, modo de falha e ação executada. Os campos opcionais enriquecem a análise sem bloquear a captura: causa raiz, componente afetado, condição operacional, evidências anexadas e custo da intervenção. A obrigatoriedade deve ser progressiva: começa-se com o mínimo e amplia-se conforme a equipe amadurece.
- Obrigatórios: tag do ativo, data/hora de detecção e retorno, modo de falha, ação executada
- Recomendados: causa provável, componente, condição operacional, horário de início da intervenção
- Opcionais: causa raiz, evidências, custo, tempo de espera por peça
Fluxo de trabalho: da ocorrência ao registro validado
O fluxo começa na detecção da falha, com a abertura de uma ocorrência ou ordem de serviço corretiva contendo os marcos de tempo iniciais. Durante a intervenção, o técnico registra a ação executada e o componente afetado; no fechamento, preenche modo de falha e causa provável a partir das listas controladas. O registro segue então para validação, onde um revisor verifica consistência e completude.
Registros aprovados entram na base analítica; registros reprovados voltam ao responsável com apontamento do problema, em um ciclo curto de correção. A validação deve ocorrer em prazo definido — por exemplo, até cinco dias úteis após o fechamento — para que a base analítica não acumule pendências. Esse fluxo, quando disciplinado, transforma o fechamento da OS de tarefa burocrática em etapa de geração de conhecimento, e a adesão da equipe de campo ao sistema deixa de ser o principal gargalo.
Perguntas frequentes sobre estruturar histórico de falhas
As dúvidas mais comuns sobre estruturação de histórico de falhas giram em torno de ferramenta, tamanho de amostra e recuperação de dados legados. As respostas dependem menos de tecnologia e mais de disciplina de processo: a ferramenta define a escala, mas a qualidade do dado define o valor da análise. A seguir, os três questionamentos mais frequentes em implementações reais.
Preciso de um CMMS para começar ou uma planilha resolve?
Uma planilha bem estruturada resolve o início, especialmente para uma planta piloto ou um conjunto pequeno de ativos críticos. O essencial é que a planilha reproduza os mesmos campos, listas controladas e regras de obrigatoriedade que um sistema faria — validação por lista suspensa, bloqueio de células e auditoria periódica. O risco da planilha é a proliferação de versões e a perda de integridade por edição manual, que cresce com o número de usuários.
O CMMS se torna necessário quando o volume de ordens de serviço cresce, quando há múltiplas equipes registrando em turnos diferentes ou quando a validação precisa ser automatizada. A transição da planilha para o sistema deve preservar o modelo de dados, migrando os campos e a taxonomia, não recomeçando do zero. O investimento em sistema sem modelo de dados definido apenas informatiza a desordem.
Quantas falhas são necessárias para uma análise estatística confiável?
Não existe um número mágico universal, porque a confiabilidade estatística depende do tipo de análise e da variabilidade dos dados. Para análises descritivas — Pareto, reincidência, tendência —, algumas dezenas de registros por classe de equipamento já permitem priorização útil. Para estimar curvas de confiabilidade com métodos paramétricos como Weibull, amostras com menos de dez a quinze falhas tendem a produzir intervalos de confiança largos demais para decisão.
Mais importante que o número absoluto é a representatividade: as falhas registradas precisam refletir a população real de falhas, sem viés de sub-registro. Uma base com trinta falhas bem registradas e sem omissão relevante vale mais que uma base com duzentas falhas contaminadas por classificação inconsistente e dados censurados descartados. Por isso, a prioridade inicial deve ser qualidade e cobertura, não volume.
Como recuperar um histórico antigo em papel ou em texto livre?
A recuperação de histórico legado começa com a definição do escopo: não é necessário — nem viável — digitalizar décadas de ordens de serviço em papel. O critério é selecionar os ativos críticos e o período relevante, geralmente os últimos dois a cinco anos, e extrair apenas os campos que sustentam a análise: ativo, data, modo de falha, causa e tempo de parada. O restante do texto livre pode ser arquivado sem digitação integral.
Para o texto livre em sistemas antigos, a estratégia é criar regras de classificação por palavras-chave — por exemplo, “vazamento” mapeia para o modo “vazamento externo” — e aplicar a classificação em lote, com amostragem de validação. O resultado não terá a precisão de um registro novo, mas permite construir uma linha de base histórica para comparação. O esforço de recuperação deve ser tratado como projeto com prazo e responsável, não como tarefa contínua indefinida, e o legado recuperado entra na mesma base dos registros novos para não criar dois históricos paralelos.
