Resposta direta
O cadastro sobrevive à troca de sistema quando o contrato define quem responde pelo dado, e não apenas quem entrega a ferramenta. Antes de assinar, três pontos precisam estar escritos: a lista de atributos essenciais com significado acordado, a área responsável por manter cada um em dia e o formato de saída dos dados no encerramento. Sem isso, a transição vira reconstrução manual e o histórico se perde em decisões tomadas no meio do projeto. Essa avaliação não elimina o risco de retrabalho. Torna visível, antes da compra, o que a empresa terá de cobrar depois.
- Objetivo
- Orientar avaliação e contratação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata a contratação como decisão sobre posse, significado e saída do dado, não sobre recursos do sistema.
O que a contratação precisa fixar
A troca de sistema expõe o cadastro porque o dado foi desenhado dentro de um sistema, não fora dele. Campos que só fazem sentido naquela tela, códigos internos e regras escondidas no código não atravessam a fronteira. O contrato precisa tratar o dado como ativo da empresa, com definição acordada entre as áreas antes de virar campo de tela.
Três itens não podem ficar para depois: a lista de atributos que a operação não pode perder, quem responde por manter cada um em dia e em que formato os dados saem ao final do contrato. Sem esses pontos escritos, qualquer troca de fornecedor recomeça do zero.
Como comparar propostas sem olhar só o preço
Duas propostas parecidas na demonstração divergem no que acontece no dia da saída. Uma pergunta separa as duas: o que a empresa recebe se encerrar o contrato, em qual formato e em quanto tempo o fornecedor entrega. A resposta precisa estar no contrato, não na conversa comercial.
Vale pedir o dicionário de dados atual e compará-lo com a lista de atributos essenciais da empresa. Onde não houver correspondência, é preciso decidir se o atributo será abandonado, recriado no sistema novo ou mantido em processo paralelo. A decisão é da área dona do dado, não do fornecedor.
O que essa avaliação não resolve
Contrato bem escrito não conserta cadastro que já está errado. Se o dado de origem tem divergência entre áreas, a troca de sistema apenas transfere o problema para uma base nova. Acordar significado e limpar registros é trabalho anterior, com dono interno.
A avaliação também não elimina retrabalho nem assegura que a operação use os campos como foram definidos. Ela reduz o custo da próxima troca; não substitui disciplina de manutenção. Onde não há responsável definido pelo cadastro, nenhuma cláusula segura o dado.
Recurso prático
O que precisa estar escrito antes da assinatura
| Item | O que verificar |
|---|---|
| Lista de atributos essenciais | Cada campo com significado único, acordado entre as áreas antes da compra |
| Responsável pela manutenção | Área dona de cada atributo e rotina de atualização registrada |
| Saída de dados no encerramento | Formato, abrangência e prazo de entrega dos dados descritos em contrato |
O ponto mais ignorado é a saída. A negociação costuma tratar a entrada de dados e deixar o formato de encerramento fora do contrato, o que transfere o custo para a troca seguinte.
Sobre o que está escrito aqui
Conceitos relacionados: atributo essencial · dicionário de dados · responsável pelo cadastro · formato de saída · cláusula de encerramento. 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
- Dados desatualizados: o que precisa estar em dia — dados desatualizados
- Validação na entrada: onde o dado errado nasce — dado errado na origem
Páginas relacionadas
O mesmo problema em outro objetivo
- Cadastro preso ao sistema antigo: como separar dado de regra — Organizar um processo
- 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
Outras leituras em Integrações, sistemas e qualidade de dados
- Número sem unidade: o que comparar antes de tratar — Compara as formas de tratar um valor registrado sem unidade: perguntar à fonte, deduzir pelo contexto, padronizar com conversão registrada ou bloquear o dado.
- 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.
- Campo obrigatório sem uso: como medir o uso de fato — Critérios para medir se um campo obrigatório virou dado usado na operação ou apenas preenchimento de tela, com sinais de uso, abandono e contorno.
- 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.
