Pular para o conteúdo

Soluções · Integrações, sistemas e qualidade de dados

Cadastro que não sobrevive à troca de sistema: o que exigir

O que exigir na contratação para que o cadastro não se perca na troca de sistema?

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

ItemO que verificar
Lista de atributos essenciaisCada 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 encerramentoFormato, 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

Páginas relacionadas

O mesmo problema em outro objetivo

Outras leituras em Integrações, sistemas e qualidade de dados

Quer avaliar isso no seu contexto?

Esta página trata de cadastro que não sobrevive à troca de sistema. Diagnóstico de integração é a frente que investiga o mecanismo por trás desse tipo de problema. O formato mais associado é Projeto de implementação.