Governança de dados começa pelo significado dos dados
Conheça melhor a Núcleo P
Site, conteúdo, sistemas e comunicação institucional ajudam clientes, parceiros e candidatos a formar uma percepção sobre a empresa antes mesmo da primeira conversa.
Conheça a Núcleo P
/quem-somos
Veja o que fazemos
/servicos
site/nucleop-com/article/01/governanca-de-dados-comeca-pelo-significado-dos-dados/article-cover.png
8
9750a983-d46d-4228-a49f-75c610e35618
/servicos/estruturacao-organizacional
Antes de políticas, catálogos e ferramentas, existe um problema mais básico: a empresa precisa concordar sobre o que seus dados significam.
Newsletter
“Quantos clientes ativos temos?”
A pergunta parece simples até três áreas responderem com números diferentes.
O comercial considera ativo quem possui oportunidade ou contrato vigente. O financeiro conta quem teve faturamento em determinado período. A operação olha para quem possui serviço em execução. O suporte inclui contas ainda atendidas mesmo sem nova receita.
Cada resposta pode estar correta dentro de seu contexto.
O problema começa quando a empresa trata a palavra “cliente” como se todos estivessem falando da mesma coisa.
Boa parte das discussões sobre governança de dados começa tarde demais. Fala-se em catálogo, linhagem, qualidade, acesso, plataforma e política. Tudo isso importa. Mas existe uma camada anterior: o significado.
Se a organização não consegue dizer com clareza o que um dado representa, qualquer infraestrutura construída sobre ele herda a ambiguidade.
O mesmo nome não garante o mesmo conceito
Empresas criam linguagem ao longo do tempo.
“Pedido”, “receita”, “lead”, “projeto”, “churn”, “produto”, “contrato”, “usuário”, “margem”. Palavras conhecidas dão a sensação de que não precisam de definição.
Só que cada área observa o negócio de uma perspectiva diferente.
Para vendas, uma oportunidade pode estar “ganha” quando o cliente aceita a proposta. Para o financeiro, a relação pode só existir quando há contrato formalizado ou faturamento. Para a operação, o trabalho ainda não começou. Para dados, cada sistema terá um estado diferente representando pedaços desse processo.
O conflito aparece depois, geralmente em um relatório.
Alguém compara números e conclui que existe problema de integração ou qualidade.
Pode existir. Mas também pode existir apenas um desacordo semântico que nunca foi tornado explícito.
Nenhuma ferramenta consegue decidir sozinha qual conceito a empresa quer adotar.
Definir não significa eliminar contexto
Governança não exige que toda a empresa use uma única métrica para tudo.
Isso seria simplificação excessiva.
É perfeitamente legítimo existir “cliente com contrato vigente”, “cliente com faturamento nos últimos 90 dias”, “cliente em operação” e “cliente elegível para suporte”. O ganho está em nomear cada conceito, documentar sua regra e saber onde ele deve ser usado.
O problema é chamar todos de “cliente ativo” e esperar que os sistemas se entendam.
Definição sem contexto também é perigosa. Uma métrica pode ser adequada para uma decisão comercial e inadequada para uma análise financeira. Um status pode funcionar no CRM e ser insuficiente para uma integração operacional.
Governar dados não é perseguir uniformidade absoluta.
É reduzir ambiguidade onde a ambiguidade cria erro, retrabalho ou decisões incompatíveis.
Toda definição precisa de uma origem
Depois de definir o conceito, surge outra pergunta: de onde vem a informação considerada válida?
Se o cadastro do cliente existe no CRM, no ERP, na plataforma de atendimento e em planilhas locais, qual deles é a fonte de referência para cada atributo?
O CRM pode ser referência para etapa comercial. O ERP para dados fiscais. O sistema operacional para status de execução. Isso é possível, desde que a arquitetura de dados deixe claro quem é autoridade sobre o quê.
Sem essa clareza, a integração vira disputa silenciosa.
Uma alteração acontece em um sistema e não chega ao outro. Um processo sobrescreve informação mais recente. Usuários corrigem manualmente um dado porque não confiam na sincronização. Aos poucos, cada área passa a criar sua própria versão da realidade.
O problema não é apenas duplicidade técnica.
É ausência de autoridade definida sobre a informação.
Qualidade depende do uso
“Dado de qualidade” parece um conceito absoluto, mas quase sempre depende da finalidade.
Um endereço incompleto pode não impedir uma análise de segmentação e, ao mesmo tempo, inviabilizar uma entrega. Um telefone desatualizado pode ser irrelevante para faturamento e crítico para atendimento. Uma data sem horário pode ser suficiente para um relatório mensal e inadequada para reconstruir uma sequência de eventos.
Por isso regras de qualidade deveriam nascer da relação entre dado e processo.
Completo para quê? Atualizado em quanto tempo? Consistente com qual fonte? Único em qual domínio? Válido segundo qual regra?
Sem responder isso, iniciativas de qualidade viram listas genéricas de campos obrigatórios.
E campo obrigatório não garante informação boa. Às vezes só garante que alguém colocará qualquer coisa para conseguir avançar.
Ownership não é “quem cuida da planilha”
Um dado importante precisa ter responsabilidade associada.
Isso não significa que uma única pessoa seja dona de cada registro. Significa saber quem responde pela definição, pelas regras, pela qualidade esperada e pela resolução de conflitos daquele domínio de informação.
Se ninguém possui autoridade para decidir o que “receita recorrente” significa, a discussão reaparece em cada relatório.
Se ninguém responde pelo cadastro mestre de produtos, duplicidades e variações se acumulam.
Se tecnologia precisa arbitrar o significado de um dado porque as áreas de negócio não chegaram a uma definição, ela acaba tomando uma decisão que não deveria ser exclusivamente técnica.
Governança distribui responsabilidades. Não terceiriza significado para o time de dados.
Integração revela conflitos que já existiam
Projetos de integração têm uma capacidade quase cruel de expor inconsistências organizacionais.
Dois sistemas usam chaves diferentes. Os status não correspondem. Um campo aceita múltiplos valores; outro, apenas um. Um sistema entende “cancelado” como encerramento definitivo; outro permite reativação. Uma entidade existe em um lado e foi dividida em três no outro.
É tentador tratar tudo como mapeamento técnico.
Algumas diferenças são mesmo técnicas. Outras representam modelos de negócio diferentes.
Quando a integração força esses modelos a conversar, a empresa precisa decidir o que antes conseguia manter separado.
É por isso que boas integrações dependem de modelagem e governança, não apenas de conectores.
Dashboard não corrige realidade mal definida
Business intelligence consegue consolidar, transformar e apresentar informação de maneiras extremamente úteis.
Mas o dashboard é o fim visível de uma cadeia.
Antes dele existem sistemas de origem, eventos, regras, cadastros, integrações, transformações e definições. Se cada camada carrega ambiguidades diferentes, a visualização pode ser tecnicamente impecável e conceitualmente errada.
Pior: números bem apresentados passam sensação de certeza.
É possível gastar semanas discutindo a cor de um indicador enquanto duas áreas ainda discordam sobre o que o indicador mede.
Governança existe, entre outras razões, para evitar esse tipo de precisão falsa.
Governança começa na conversa difícil
Ferramentas ajudam. Catálogos ajudam. Arquiteturas ajudam. Políticas também.
Mas nenhuma delas substitui uma conversa que muitas empresas evitam: “quando usamos esta palavra, estamos falando exatamente do quê?”.
A partir daí surgem outras.
- Quem é responsável pela definição?
- Qual sistema registra a fonte oficial?
- Que regra determina qualidade?
- Quem pode alterar?
- Como a mudança é comunicada?
- Quais processos dependem disso? Quais relatórios serão afetados?
Essas perguntas transformam governança em prática operacional.
Sem elas, é possível possuir uma plataforma moderna de dados e continuar discutindo em reunião qual número está certo.
A governança começa antes da ferramenta.
Às vezes, começa simplesmente quando duas áreas descobrem que estavam usando o mesmo nome para duas coisas diferentes.
site/nucleop-com/article/01/governanca-de-dados-comeca-pelo-significado-dos-dados/article-cta.png
Título: Dados confiáveis exigem responsabilidades claras
Quero acompanhar
Conheça a Estruturação Organizacional
Quando conceitos, fontes e regras mudam de uma área para outra, o problema não está apenas nos sistemas. Está também em quem define, mantém e responde pela informação.
- papéis e responsabilidades claros;
- ownership sobre informações críticas;
- interfaces entre áreas;
- critérios e alçadas de decisão;
- redução de ambiguidades e retrabalho.
Tecnologia, dados, gestão e operação produzem decisões melhores quando são discutidos sem receitas prontas. Assine para acompanhar novas análises, critérios e provocações da Núcleo P.