Uma boa migração de dados para um CMMS leva para o sistema novo a estrutura que faz a manutenção funcionar (cadastro de ativos, planos preventivos, peças e saldos de estoque) já limpa e padronizada, e deixa para trás o histórico que não vai ser consultado. A regra prática é simples: se o dado não vai mudar uma decisão nos próximos 12 meses, ele não precisa entrar no primeiro dia.
Parece óbvio, mas a tentação na implantação é o contrário. Alguém sugere “importar tudo para não perder nada”, e a equipe passa dois meses tentando encaixar dez anos de planilhas em campos que não conversam entre si. O resultado é um sistema novo com os mesmos defeitos da base antiga, só que agora com uma interface bonita.
Por que a migração de dados define o sucesso do CMMS?
O técnico julga o sistema nas primeiras semanas. Se ele lê o QR Code de uma bomba e aparece o equipamento errado, ou se o plano de preventiva gera uma OS para um motor que foi sucateado em 2021, a confiança vai embora rápido. Depois disso, ele volta para o caderno e o sistema vira um lugar onde o PCM digita coisas.
Por isso a migração não é tarefa de TI. É trabalho de manutenção, feito com apoio de TI. Quem sabe que o “MB-03” e a “bomba 3 do caldo” são o mesmo equipamento é o encarregado que está há 15 anos na planta, não o analista que vai rodar a importação.
O que levar para o CMMS (e o que deixar)
A tabela abaixo resume o que costuma valer a pena migrar. Cada planta tem suas particularidades, mas o raciocínio serve para quase todas.
| Dado | Levar? | Como tratar |
|---|---|---|
| Cadastro de ativos e localizações | Sim, obrigatório | Revisar um a um, montar a hierarquia e padronizar TAG antes de importar |
| Planos de preventiva e lubrificação | Sim | Migrar só planos que estão sendo executados; revisar frequência e tarefas |
| Cadastro de peças e saldo de estoque | Sim | Saldo só depois de inventário físico; eliminar códigos duplicados |
| Fornecedores e contratos de serviço | Sim, os ativos | Contratos vencidos ficam no arquivo |
| Equipe, especialidades e turnos | Sim | Cadastro simples; costuma ser rápido |
| Histórico de OS dos últimos 2 a 3 anos | Depende | Levar resumido para ativos críticos (data, falha, peça, horas) |
| Histórico antigo em texto livre | Não | Arquivar em PDF ou planilha de consulta, fora do sistema |
| Peças sem movimento há anos | Não, até revisar | Separar para análise de obsolescência |
O histórico é o ponto que mais gera discussão. Ele tem valor, sim, principalmente para calcular MTBF e identificar os equipamentos que mais quebram. O problema é a qualidade: OS antigas costumam ter descrições como “arrumado”, “trocado peça”, “ok”, sem causa nem tempo de reparo. Importar isso polui os indicadores do sistema novo. Uma saída que funciona bem é montar um resumo por ativo crítico (número de falhas por ano, principais modos de falha, últimas trocas relevantes) e deixar o detalhe bruto arquivado para consulta.
Como limpar a base antes de importar?
Limpeza é onde vai a maior parte do tempo. Em uma implantação típica, é comum a preparação dos dados levar mais horas do que a configuração do sistema. Vale planejar isso desde o início.
1. Cadastro de ativos
Comece pela árvore de ativos: planta, área, linha, equipamento, e só depois componentes, se fizer sentido. Defina o padrão de TAG antes de mexer em qualquer linha da planilha (o artigo sobre cadastro de equipamentos e padrão de TAG detalha esse passo). Depois disso:
- Elimine duplicados. O mesmo motor aparece com nomes diferentes em planilhas de setores diferentes.
- Marque equipamentos desativados e não os importe como ativos em operação.
- Preencha os campos mínimos: TAG, descrição, localização, fabricante, modelo e criticidade.
- Deixe para depois os campos que ninguém vai usar no primeiro ano. Vinte colunas vazias não ajudam ninguém.
Um exemplo para dar escala: uma planta de alimentos com uma planilha de 3.900 linhas de equipamentos. Depois de uma semana de revisão com dois encarregados, sobraram 2.650 ativos reais. Das 1.250 linhas eliminadas, a maior parte era duplicidade entre a planilha da elétrica e a da mecânica, e o restante era equipamento que já não existia. Se essas linhas tivessem entrado no sistema, cada uma viraria um ativo fantasma com plano de preventiva gerando OS.
2. Planos de manutenção
Migrar plano preventivo é a hora certa de revisar o plano. Pergunte para cada um: está sendo executado? A frequência faz sentido para o histórico de falhas? As tarefas estão escritas de forma que um técnico novo entenda? Planos que existem só no papel, e que ninguém executa há meses, não devem ir para o sistema como se estivessem vivos. Se o plano está em formato de plano de 52 semanas, confira se a distribuição de cargas por semana é realista antes de importar.
3. Peças e estoque
Aqui o erro clássico é importar o saldo do sistema antigo sem inventário. Se o saldo estava errado na planilha, vai continuar errado no CMMS, e o técnico vai descobrir isso no pior momento: com a máquina parada e o sistema dizendo que tem duas unidades na prateleira. Faça o inventário físico das peças de maior valor e das peças sobressalentes críticas antes da data de corte. Itens sem movimento há muito tempo podem ficar fora da primeira carga e passar por uma análise separada, como descrito em peças obsoletas no almoxarifado.
Passo a passo de uma migração que não trava a operação
- Defina o dono de cada base. Ativos com o PCM, peças com o almoxarifado, equipe com o RH ou a supervisão. Cada dono responde pela qualidade do que entrega.
- Use os modelos de importação do fornecedor. Peça os modelos de planilha logo no início e preencha neles, não no formato antigo.
- Faça uma carga piloto. Escolha uma área (por exemplo, utilidades) e importe tudo dela primeiro. Os erros aparecem rápido e com volume pequeno.
- Valide no campo. Leve o celular para a área piloto, leia as etiquetas e confira se o equipamento, a localização e os planos batem com a realidade.
- Corrija o modelo, não só o dado. Se a carga piloto mostrou que um campo foi mal definido, ajuste o padrão antes de carregar o restante da planta.
- Escolha uma data de corte. A partir dela, OS novas só no sistema novo. Manter os dois funcionando por meses cria duas verdades e ninguém sabe qual vale.
- Congele o sistema antigo como consulta. Deixe a planilha ou o sistema antigo em modo somente leitura por um período combinado.
Num CMMS como o Sismetro, essa estrutura vira a base de tudo: os planos preventivos geram as OS automaticamente, o estoque trabalha com mínimo e máximo e o custo das peças fica vinculado à OS. Por isso, um cadastro bem feito na migração aparece depois em indicadores confiáveis, e um cadastro ruim aparece em retrabalho do PCM.
Quer tirar isso da planilha?O Sismetro junta ordens de serviço, preventivas, estoque e indicadores num só lugar, com app para os técnicos e integração com o ERP Senior.
Quanto histórico vale a pena migrar?
Não existe número certo, mas existe um teste útil: para cada tipo de dado histórico, pergunte quem vai usar e para quê. Se a resposta é “o engenheiro de confiabilidade vai usar para analisar os bad actors da moagem”, leve o histórico dos ativos daquela área, tratado. Se a resposta é “pode ser que alguém precise um dia”, arquive.
Uma alternativa que costuma funcionar é começar o histórico do zero no CMMS e registrar, no cadastro de cada ativo crítico, um campo de observação com o resumo do passado: falhas recorrentes, última reforma, peças que costumam dar problema. Em seis meses de uso disciplinado, o sistema novo já tem mais informação utilizável do que a planilha de dez anos. Para aproveitar esse histórico novo, vale entender como identificar as falhas repetitivas desde cedo.
Erros comuns na migração para um CMMS
- Migrar antes de padronizar. TAG, nomes de causas de falha e tipos de OS precisam estar definidos antes da primeira importação. Mudar depois custa muito mais.
- Delegar tudo ao fornecedor. O fornecedor conhece o sistema; quem conhece a planta é a sua equipe. A revisão do cadastro não pode ser terceirizada por completo.
- Importar listas de causa enormes. Lista de modos de falha com 200 opções termina com todo mundo escolhendo “outros”. Comece curta. A ISO 14224 ajuda a estruturar essas listas.
- Não reservar horas da equipe. Revisão de cadastro feita “nas horas vagas” não acontece. Bloqueie agenda dos encarregados.
- Esquecer a criticidade. Sem a classificação de criticidade, o sistema não ajuda a priorizar, e todas as OS parecem igualmente urgentes.
Para o desenho completo do projeto, incluindo treinamento e piloto, veja o guia de como implantar um software de manutenção. Um próximo passo prático: abra hoje a planilha de equipamentos, escolha uma linha de produção e conte quantos ativos estão duplicados, sem TAG ou já desativados. Esse número dá uma estimativa honesta do tamanho da limpeza que vem pela frente.
Perguntas frequentes
Quanto tempo leva uma migração de dados para CMMS?
Depende muito do estado da base. Uma planta com cadastro organizado em uma planilha única pode migrar em poucas semanas; uma planta com várias planilhas por setor e sem padrão de TAG pode precisar de alguns meses só de limpeza. O cadastro de ativos costuma ser a etapa mais demorada.
Devo migrar todo o histórico de ordens de serviço?
Na maioria dos casos, não. Leve um resumo do histórico dos ativos críticos (falhas, datas e peças trocadas) e arquive o restante para consulta fora do sistema. Histórico mal preenchido distorce os indicadores do sistema novo.
Quem deve ser responsável pela migração de dados?
A manutenção, com apoio da TI e do fornecedor. O PCM costuma coordenar, cada base tem um dono (ativos, peças, equipe) e os encarregados validam o cadastro no campo. A TI cuida da parte técnica da importação e dos acessos.
Posso usar o sistema antigo e o novo ao mesmo tempo?
Por um período curto e definido, apenas como consulta. Manter os dois recebendo OS gera duas versões da verdade e atrapalha a adesão ao sistema novo. Defina uma data de corte e deixe o antigo somente para leitura.
