Vitrine técnica · PCM — Planejamento e Controle de Manutenção
MTBF calculado a partir de ordem de serviço real, criticidade por pontuação auditável, matriz ABC com histórico, retrabalho com duas definições — porque quem faz PCM sabe que "retrabalho" não é um conceito único.
Esta página é escrita pra quem entende a diferença entre um indicador de verdade e um número bonito no dashboard — cada cálculo abaixo tem a fórmula exposta, não só o resultado.
As dores de quem planeja e controla manutenção raramente são sobre "não ter um sistema" — são sobre ter sistemas que tratam PCM como recurso secundário, com indicadores que não resistem a uma auditoria. As dores mais constantes:
Painéis de "risco" que mostram cor vermelha sem mostrar o cálculo por trás — e quando alguém pergunta "por que esse ativo está crítico?", ninguém no time sabe responder com precisão.
Ou o sistema não calcula MTBF nenhum, ou calcula errado — confundindo tempo de calendário com tempo de operação, ou ignorando corretivas sem horímetro associado.
"Retrabalho" vira uma palavra vaga no relatório mensal — sem separar reincidência técnica real (mesma falha, mesmo ativo) de coincidência de calendário (dois problemas diferentes, perto no tempo).
A classificação de criticidade muda com o tempo — mas a maioria dos sistemas não guarda histórico de quem mudou o nível de um ativo, quando, e por quê.
Sistemas que só disparam preventiva por data ou só por horímetro — sem cobrir ativos elétricos, onde o desgaste real está em ciclos de carga da bateria, não em horas rodadas.
"Causa da avaria" como campo de texto livre preenchido às pressas — sem cruzar com histórico do ativo, sem foto, sem nenhuma camada de análise por trás.
+1 se houver plano preventivo aplicável vencido (qualquer dimensão: hora, data ou ciclo)
+1 se houver avaria em aberto (status != cancelado)
+1 se houver reincidência do mesmo tipo de dano no mesmo ativo em 90 dias
+1 se o nível ABC do ativo estiver marcado como urgente (configurável por tenant)
pontos ≥ 3 → crítico | pontos ≥ 1 → atenção | pontos = 0 → fora da lista
Cada ponto vem de uma condição verificável — não é peso arbitrário. A tela mostra o total, mas o cálculo é reproduzível linha por linha.
Para cada OS concluída de um ativo:
busca a próxima OS Corretiva criada depois do fechamento dela
intervalo_dias = created_at(corretiva seguinte) − finished_at(OS concluída)
se houver leitura de horímetro cobrindo as duas pontas:
intervalo_horas = leitura(fim) − leitura(início)
média de todos os intervalos do ativo = MTBF simplificado (dias e, quando disponível, horas)
Chamamos de "MTBF simplificado" porque é um MTBF em dias corridos entre eventos, não um MTBF estatístico com distribuição de confiabilidade formal — mas o número vem de dado real de O.S. e horímetro, nunca de estimativa.
Definição ampla (relatório gerencial):
mesmo ativo recebe QUALQUER nova OS dentro de uma janela configurável (15/30/60/90 dias)
depois de uma OS anterior ter sido concluída — mostra os dois técnicos, sem julgar
Definição estrita (usada na análise de IA):
só conta quando OS antiga E nova são AMBAS corretivas
(preventiva seguida de corretiva é tratada à parte, como "quebra pós-preventiva")
Separar as duas definições evita o erro mais comum de relatório de retrabalho: contar como "retrabalho" uma preventiva que corretamente antecedeu uma corretiva não relacionada.
Um ativo some da lista de "atenção" e reaparece em "crítico" — vendo exatamente qual dos quatro fatores mudou, com a pontuação exposta.
Dois ativos da mesma frota: um com leitura de horímetro cobrindo o intervalo, outro sem — o sistema mostra dias em ambos, horas só onde há dado real.
Uma preventiva seguida de corretiva não relacionada não entra na conta de retrabalho estrito — mas aparece no relatório gerencial amplo, pro gestor decidir.
Hora, data ou ciclo de bateria — o mesmo plano vence pela dimensão que chegar primeiro, cobrindo tanto ativos a combustão quanto elétricos.
Foto da avaria + histórico das últimas O.S. viram diagnóstico provável, causa raiz e faixa de custo — com o aviso claro de que é sugestão, não veredito.
Arrastar um card de "A Fazer" pra "Planejado" no Kanban cria a Ordem de Serviço de verdade — não é ilustração de fluxo, é o fluxo operacional.
Todos abaixo já existem em produção, no grupo de navegação "PCM" e "Relatórios" do painel — não são mockups.
Cruza preventiva vencida, avaria em aberto, reincidência e nível ABC urgente numa pontuação de 0 a 4.
Classificação de criticidade por ativo, com histórico auditável de cada mudança de nível.
Kanban de planejamento — A Fazer, Planejado, Em Andamento, Em Revisão, Concluído — sobre dados reais.
Eventos de parada de ativo registrados, base pra cálculo de disponibilidade.
Tempo médio por técnico e por tipo de O.S., mais o relatório gerencial de retrabalho com os dois lados expostos.
Timeline única por ativo: avarias, alterações de cadastro e preventivas vencidas, cronológicas.
Avarias agrupadas por tipo, com destaque de reincidência — sem apontar causa raiz automática, só organiza os dados.
Chamados de emergência com prazo de atendimento, cor por urgência, percentual no prazo vs. vencido.
Cada mudança de nível de criticidade, com data, de/para e responsável — somente leitura.
Cada troca de status registrada automaticamente, mesmo evento usado pelo Kanban de oficina.
MTBF, atrasados e quebras pós-preventiva calculados em PHP primeiro — a IA só interpreta e prioriza por cima.
Classificação de causas de avaria e correlação de padrões em corretivas repetidas, com a definição estrita de retrabalho.