Resposta direta
Um cadastro só sobrevive à troca de sistema quando o significado dos campos não depende do software que os hospeda. Na prática, isso exige três definições antes da migração: quem responde por cada campo, qual regra determina que um registro é válido e onde fica o histórico das alterações. Sem dono, o cadastro vira cópia do sistema antigo. Sem regra escrita, cada área recria a sua. Enquanto essas definições moram dentro do sistema atual, qualquer substituição carrega junto as ambiguidades que ninguém documentou. O trabalho é separar dado, regra e operação antes de escolher a ferramenta.
- Objetivo
- Organizar um processo
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata o cadastro como ativo fora do sistema, definindo dono, semântica e histórico em vez de conferir campos exportados.
O que a troca de sistema revela
Uma troca de sistema raramente quebra os campos. Quebra o significado deles. A exportação sai com colunas, valores e códigos, mas não leva junto a regra que dizia o que preencher ali e por quê.
Na operação antiga, parte dessa regra vivia na tela, parte no hábito de quem digitava e parte em planilhas paralelas. Nenhuma dessas três sobrevive à substituição. O arquivo parece intacto e a divergência reaparece quando o trabalho recomeça no sistema novo.
Dono, regra e histórico como parte do cadastro
Antes de escolher o sistema novo, três definições precisam sair de dentro do sistema atual. A primeira é o dono de cada campo crítico. Sem nome, a decisão volta para a área que reclamar mais alto no momento da dúvida.
A segunda é a regra escrita que valida um registro, com o que é aceito e o que é recusado. A terceira é o histórico de alterações mantido fora do software. Cadastro sem histórico não permite reconstruir por que um dado chegou ao estado atual, e sem isso a auditoria vira reconstrução de memória.
O que essa organização não resolve
Separar dado de regra não recupera informação que nunca foi registrada. Se um campo era preenchido por convenção e ninguém escreveu a convenção, o cadastro novo começa com a mesma dúvida, apenas em outro software.
Também não decide disputa de regra entre áreas. Quando duas equipes usam o mesmo campo com significados diferentes, a definição é decisão de negócio, não de cadastro. E não cobre o que o sistema novo não suportar: se o modelo aprovado não prevê histórico, ele fica fora do sistema ou permanece em planilha paralela. A conferência da primeira carga segue necessária.
Recurso prático
Conferência do cadastro antes de trocar o sistema
- Lista dos campos que alguma área usa para decidir, com o nome de quem responde por cada um
- Regra escrita que define quando um registro é aceito e quando é recusado
- Origem declarada de cada campo: entrada manual, outro sistema ou cálculo interno
- Histórico de alterações guardado fora do sistema atual, com data e autor
- Campos sem uso confirmado, marcados para não migrar
- Divergência de significado entre áreas registrada como pendência, não como dado
- Critério de conferência da primeira carga no sistema novo
O ponto mais ignorado é o campo sem regra declarada. Ele migra com aparência de limpo e volta a divergir quando a operação recomeça, porque o significado morava na tela e no hábito de quem digitava.
Sobre o que está escrito aqui
Conceitos relacionados: cadastro mestre · dono do campo · dicionário de dados · histórico de alterações · regra embutida na operação. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Projeto de implementação, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Integrações, sistemas e qualidade de dados — Página central do tema
- Planilhas divergentes: o que exigir na contra… — planilhas divergentes
- Cadastros duplicados: caminhos para comparar… — cadastros duplicados
Páginas relacionadas
O mesmo problema em outro objetivo
- Cadastro que não sobrevive à troca de sistema: o que comparar — Comparar alternativas
- Cadastro que quebra na troca de sistema: o que fica fora dele — Orientar implementação
- Cadastro que não sobrevive à troca de sistema: o que exigir — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- Base sem dono definido: como localizar quem decide — Sinais de que a responsabilidade pela base se perdeu, quais decisões ficaram sem dono e o que o diagnóstico não resolve sozinho.
- Cliente duplicado entre áreas: quando vale contratar solução — O que avaliar antes de contratar solução para cliente duplicado entre áreas, o que é decisão de dado e o que é decisão de responsabilidade.
- Campos preenchidos sem padrão: como mapear a dispersão — Critérios objetivos para auditar campos com grafias diferentes, calcular o índice de dispersão de valores e separar erro humano de falha no desenho do sistema.
- Sistemas isolados: o que checar antes de comprar outro — Critérios operacionais para avaliar contratos de software quando a arquitetura atual opera sem comunicação direta entre áreas.
- Mesmo campo, formatos diferentes: o que cada escolha cobra — Compara lista fechada, campo livre com convenção e correção posterior pelo custo de manter cada uma e pelo erro que cada escolha deixa passar.