Antes de mover um dado, nomeie o dono dele

Em 1 minuto

Quando uma empresa reúne os dados num só lugar, a tecnologia não substitui o acordo sobre quem responde por cada conjunto de dados. Se um número sai errado, quem o corrige, em qual sistema e com qual prioridade combinada? A prática do setor pede três coisas antes de carregar um dado: um dono com nome, um acordo escrito entre quem produz o dado e quem o usa, e algumas regras de qualidade que possam ser verificadas a cada carga. Nem tudo exige o mesmo rigor: com uma única fonte e um uso restrito, dá para começar leve.

Imagine uma empresa de distribuição de porte médio. É fictícia, mas se parece com muitas. Vende por três canais, fatura num sistema, mantém o estoque noutro e a cobrança num terceiro. No fim de cada mês, o Financeiro e o Comercial chegam à reunião com um número diferente de vendas líquidas.

A diretoria decide resolver isso de uma vez: reunir todos os dados numa plataforma, com painéis para cada área. O projeto começa bem. Em três meses os dados já chegam, os painéis estão bonitos e a reunião… continua igual. Agora a discussão acontece diante de uma tela maior.

O que aconteceu? Ninguém fez uma pergunta simples antes de mover o primeiro dado: quem responde por ele?

Este artigo é para quem vai aprovar — ou já aprovou — um projeto para reunir os dados da empresa. Ele defende uma ideia: antes de mover um dado, nomeia-se o dono dele, escreve-se o que ele promete e decide-se como se verifica. A tecnologia vem depois.

Por que os dados sem dono se deterioram

Um dado de vendas é produzido por uma área (a que fatura), transformado por outras (a que concilia, a que monta o relatório) e usado por muitas. Quando algo dá errado, cada uma pode apontar para a seguinte. Se ninguém é responsável por esse dado estar correto, o erro é corrigido à mão no relatório, todo mês, e o seguinte reaparece.

O setor dá nome a esse problema há anos. Zhamak Dehghani, no texto que deu origem à ideia de data mesh, propõe repartir a responsabilidade pelos dados entre «people who are closest to the data» e tratar cada conjunto de dados como um produto, com os usuários tratados como clientes [1]. Não é preciso adotar toda essa abordagem para ficar com o essencial: um dado compartilhado precisa de alguém que responda por ele, assim como um produto precisa de alguém que responda pela qualidade dele.

Três coisas que se definem antes de carregar

1. Um dono com nome, não uma área

«O Financeiro olha» não é um dono. Um dono é uma pessoa com nome, na área que produz o dado ou na que melhor o entende, com três responsabilidades:

• Dizer o que o dado significa. O que é uma «venda líquida»: com ou sem devoluções? Com ou sem notas de crédito? Na data da fatura ou na data do recebimento?
• Aprovar as mudanças. Se o sistema de origem muda uma regra, o dono decide se a definição também muda e avisa quem usa o dado.
• Atender quando não bate. Quando uma verificação falha, alguém precisa responder, num prazo combinado.

O marco de qualidade de dados do governo do Reino Unido atribui ao dono do dado decisões como arquivar ou destruir um dado que deixou de ser usado, e pede que a informação sobre a qualidade dele seja guardada junto com o dado [3]. É um guia público, não uma norma para a empresa, mas o princípio vale do mesmo jeito: as decisões sobre um dado têm um responsável.

2. Um acordo escrito entre quem produz e quem usa

O segundo passo é pôr por escrito o que esse conjunto de dados promete. O setor chama isso de contrato de dados: um acordo entre quem produz o dado e quem o consome. O padrão aberto para esses contratos, o Open Data Contract Standard (projeto Bitol, na fundação LF AI & Data), organiza-os em seções: o fundamental, a estrutura dos dados, as regras de qualidade e os canais de suporte, entre outras [2].

Para um comitê, não é preciso um formato técnico. Basta que o acordo responda, numa página:

• O que contém: quais campos, com que significado e em que unidade.
• Com que frequência chega: ao fechamento do dia, a cada hora, no momento em que acontece.
• Que qualidade promete: as regras da seção seguinte.
• Quem é avisado quando algo muda ou falha, e em quanto tempo isso é atendido.

O acordo protege os dois lados. Quem usa o dado sabe o que esperar; quem o produz sabe o que não pode mudar sem avisar.

3. Poucas regras de qualidade verificadas a cada carga

A qualidade não se declara; verifica-se. O marco britânico usa seis dimensões definidas pela DAMA UK: completude, unicidade, consistência, oportunidade, validade e exatidão [3]. O exemplo dele é útil: 300 alunos, 294 telefones de emergência registrados; o campo está completo a 98%, mas isso não diz que os telefones estejam corretos. Completo não é o mesmo que correto.

Traduzidas para uma empresa, as primeiras regras costumam ser simples:

Regras de exemplo, para ilustrar; as de cada empresa são definidas por cada dono.

Como ponto de partida, escolha as regras que cubram os riscos mais relevantes desse dado — registros faltantes, duplicados, diferenças em relação à origem —, combine quando são verificadas e quem atende uma falha, e faça com que o resultado seja visto por quem usa o dado antes de usá-lo.

Quando tudo isso é necessário e quando não

Nomear donos e escrever acordos custa tempo de pessoas ocupadas. Não compensa em todos os casos.

Dá para começar leve se:

• Os relatórios saem de um único sistema, com uso restrito e um responsável identificado.
• É uma análise pontual, que ninguém vai repetir nem usar para decidir sobre dinheiro.
• É um experimento com dados de teste, sem efeito na operação.

Mesmo nesses casos, e mais ainda se houver dados pessoais ou uma obrigação regulatória, deixe por escrito o que o dado significa, quem responde por ele e quem pode vê-lo.

Convém fazer antes de carregar se:

• O mesmo número é montado com dados de dois ou mais sistemas.
• Duas áreas já chegam à reunião com números diferentes para a mesma coisa.
• O dado alimenta uma decisão de dinheiro, um relatório para uma autoridade ou um modelo de IA.
• Vão entrar novas fontes a cada ano: cada uma multiplica as formas de errar.

O que descartamos, e por quê

• «Primeiro carregamos tudo e depois vemos.» É a tentação mais comum, porque dá a sensação de avanço. O problema é que a governança acrescentada depois, sobre dados que já estão em uso, é negociada com áreas que já construíram relatórios sobre definições diferentes.
• «Que a TI seja a única dona do dado.» A TI pode responder pela operação, pela segurança e pelos acessos, mas não cabe a ela decidir se uma devolução subtrai no mês da venda ou no da nota de crédito. Esse significado, o uso dele e a qualidade dele são da área de negócio. Deixe os dois papéis por escrito, e quem resolve quando não coincidem.
• «Um comitê de dados decide tudo.» Um comitê ajuda a resolver conflitos entre áreas, mas se cada mudança espera a sessão mensal, as pessoas voltam à planilha. O dono decide as mudanças dentro do âmbito dele; se uma mudança toca uma definição compartilhada, os acessos, a privacidade ou outra área, o comitê a resolve, com responsável e data.
• «Comprar uma ferramenta de catálogo resolve a governança.» Uma ferramenta guarda as definições; não as escreve nem as faz cumprir. Sem donos, o catálogo se enche de campos sem descrição.

Cinco perguntas para o próximo comitê

1. Quem, com nome, responde por cada um dos cinco números mais discutidos na reunião?
2. Está escrito o que cada um significa, e o dono o aprovou?
3. Quais regras são verificadas a cada carga, e quem vê o resultado antes de o número ser usado?
4. Quando uma regra falha, quem é avisado e em quanto tempo isso é atendido?
5. Se o sistema de origem muda uma regra, quem fica sabendo antes de o relatório sair errado?

Se a maioria das respostas for «ninguém» ou «depende», o projeto de dados ainda não está pronto para crescer.

Por onde começar esta semana

Pegue os três conjuntos de dados por trás dos números mais discutidos — as faturas, os pagamentos, o estoque, o que for — e preencha uma folha para cada um:

• Dono: nome e área; e, à parte, quem o opera na TI.
• Quem o usa: quais áreas e para quais decisões.
• O que promete: o que contém e com que frequência chega.
• Regras: como se sabe que está completo, sem duplicados e conciliado com a origem.
• Acessos: quem pode vê-lo.
• Aviso: quem é avisado quando não bate, e com que prioridade isso é atendido.

Se alguma casa ficar vazia, essa é a primeira tarefa, antes de comprar ou construir qualquer coisa.

O que a Hábil faz

Na Hábil construímos sob medida os sistemas e as integrações que movem os dados da empresa, e operamos a plataforma onde esses dados se reúnem.

Se a empresa precisa de uma única versão dos números, a proposta está no Hábil Lake. Escolhemos juntos as três a cinco perguntas que mais custam hoje. Para cada uma, deixamos por escrito de qual sistema sai cada dado, como é calculado e com o que é conciliado. Cada carga é comparada com o sistema de origem —contagens, somas, totais por data— e o resultado fica à vista, como um semáforo: bate ou não bate. Cada tabela tem uma descrição, um sistema de origem e o registro das tabelas de onde sai, e os acessos são dados por perfil.

A conversa pode começar com as três folhas, mesmo pela metade: quais dados, quem os produz e onde os números se separam. Com isso, revisamos juntos por onde convém começar. Escreva para nós pelo WhatsApp; para proteger as informações, não compartilhe por esse meio dados dos clientes nem dos sistemas da empresa: combinaremos na conversa o canal para o caso.

Peça a primeira conversa, sem custo.

Consultadas em 13 de novembro de 2026. Cada referência traz o grau de confiança: alta (fonte primária lida).