Resposta direta
A saída é nomear um dono formal para a base, com escopo escrito, antes de qualquer melhoria técnica. Dono não é quem opera o sistema: é quem decide o que entra, o que sai e o que prevalece quando duas áreas discordam. Sem essa definição, correções viram disputa e a base continua ambígua. O caminho prático tem três passos: registrar o estado atual dos campos críticos, atribuir responsabilidade por domínio de dado e criar uma instância de decisão para conflitos. A implementação só se sustenta quando o dono tem tempo alocado e critério de escalada.
- Objetivo
- Orientar implementação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata da atribuição formal de responsabilidade por domínio de dado, assunto que as demais páginas do tema não cobrem ao tratar de integração, consolidação e validação.
Quem responde quando o dado está errado
Toda base tem um fornecedor de tecnologia e, quase sempre, nenhum responsável pelo conteúdo. São papéis distintos. O fornecedor responde pela disponibilidade do sistema; o dono do dado responde pelo significado, pela regra de preenchimento e pela correção. Quando essa distinção não está escrita, cada área presume que a outra cuida do assunto.
O primeiro passo é separar três funções: quem decide a regra, quem opera a manutenção e quem responde pelo resultado quando o dado afeta uma decisão de negócio. Em bases compartilhadas, essas funções costumam estar na mesma pessoa por acidente, não por desenho. Nomear explicitamente cada uma reduz a chance de a base ficar sem resposta.
Como registrar a responsabilidade em vez de combiná-la verbalmente
A definição precisa caber em um documento curto, por domínio de dado. Para cada domínio, registre quem decide, qual é a regra de entrada, o que conta como erro e qual instância resolve conflito entre áreas. Domínio é o recorte que faz sentido para a operação, não a estrutura das tabelas.
Vale definir também o custo da decisão. Dono sem tempo alocado e sem autoridade sobre a origem do dado apenas acumula pendências. Se a área que gera o dado não responde pela qualidade dele, a responsabilidade formal vira ficção. A revisão do arranjo deve ocorrer em periodicidade definida, com pauta fixa: conflitos abertos, regras alteradas e campos sem dono.
O que a definição de dono não resolve
Nomear responsáveis não corrige regra de negócio mal desenhada, origem duplicada nem incentivo conflitante. Se uma área é medida por volume e outra por consistência, o dono do dado decide no meio de uma disputa que não é técnica. Nesses casos, a decisão precisa subir para quem responde pela meta, não para quem opera a base.
Também não se aplica quando a base é, de fato, cópia de um sistema externo sem governança possível, ou quando o custo de manter o cadastro supera o uso que se faz dele. Nesses cenários, a alternativa pode ser reduzir o escopo da base, aposentar campos ou tratar a fonte externa como referência oficial. O arranjo de dono organiza a responsabilidade, mas não cria dado correto por si.
Recurso prático
Responsabilidade por domínio de dado
| Domínio de dado | Quem decide a regra | O que precisa ficar registrado |
|---|---|---|
| Cliente | Área comercial, com validação do cadastro | Regra de duplicidade, campos obrigatórios e quem aprova exceção |
| Produto | Operação ou engenharia, conforme a origem do cadastro | Quem altera atributo, como a mudança chega aos demais sistemas e quem confere |
| Financeiro | Controladoria | Critério de competência, origem do lançamento e responsável pela conciliação |
| Referência compartilhada | Instância de decisão entre áreas | Quem prevalece no conflito, prazo de resposta e registro da decisão |
O erro mais comum é nomear o dono do sistema como dono do dado. O primeiro cuida da ferramenta; o segundo responde pelo conteúdo, inclusive quando a ferramenta muda.
Sobre o que está escrito aqui
Conceitos relacionados: dono do dado · domínio de dado · sistema de origem · regra de preenchimento · instância de decisã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
- Diagnóstico de sistemas desconectados na oper… — sistemas desconectados
- Sistemas desconectados: como ordenar o fluxo… — sistemas desconectados
Páginas relacionadas
O mesmo problema em outro objetivo
- Base sem dono definido: como localizar quem decide — Diagnosticar
- Base sem dono: como definir quem responde pelo dado — Organizar um processo
- Base de dados sem dono: o que comparar antes de decidir — Comparar alternativas
- Base de dados sem dono: como medir o que ninguém acompanha — Explicar medição
- Base de dados sem dono: o que definir ao contratar — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- Planilha de apoio sem versão: como definir a cópia válida — Dono, nome, data de corte e conferência de uma planilha de apoio, e o ponto em que ela deixa de ser exceção e vira requisito de sistema.
- Planilha que virou sistema: como contratar a substituição — Critérios operacionais para mapear regras de negócio, dados e responsabilidades antes de contratar um software para substituir planilhas críticas da rotina.
- Exportações manuais: onde o retrabalho se esconde — Roteiro de diagnóstico para identificar a origem, o tratamento intermediário e a real dependência das planilhas geradas manualmente entre sistemas.
- Planilhas paralelas: como fixar uma versão de referência — Como dar dono, versão e regra de substituição a planilhas de apoio que circulam sem controle, sem depender de ferramenta nova.
- Sincronização sem janela definida: o corte que ninguém fecha — Um processo para definir data de corte, dono do número e rotina de conferência quando a sincronização entre sistemas não tem janela combinada.