O diretor financeiro apresenta um número, o diretor comercial apresenta outro, e os dois falam do mesmo indicador com os mesmos dados no mesmo warehouse. Não é um problema de dados, é um problema de definições, e ninguém na sua equipe é formalmente responsável por resolvê-lo.
O vazio que ninguém enxerga
Entre o data engineer que constrói os pipelines e o analista que produz os relatórios, a maioria das organizações deixou um espaço vazio. É ali que se desenrolam as disputas de números no comitê de direção, as horas perdidas reconciliando métricas que deveriam designar a mesma coisa, e as decisões tomadas sobre bases que ninguém consegue realmente explicar.
O data engineer faz seu trabalho: os dados chegam no warehouse, limpos, tipados, presentes. O analista faz o dele: constrói um relatório, tira conclusões, alerta sobre tendências. Os dois fazem o que lhes é pedido. O problema não está aí.
Ele está no que ninguém se perguntou: o que é um cliente ativo, exatamente? Em qual período calculamos? Uma conta suspensa há trinta dias faz parte? Essas definições existem, de certa forma. Estão em um arquivo Excel compartilhado, em um e-mail de 2022, na memória de um consultor que já seguiu em frente. Mas elas não estão no sistema. O que falta não é uma pessoa com um novo cargo. É uma camada: aquela que garante que os dados cheguem aos analistas com definições estáveis, documentadas e testadas, e não mais com convenções implícitas.
O que frequentemente falta entre os dois
A função que está faltando tem entregáveis precisos. Você pode verificá-los, testá-los e mantê-los assim que existirem. É isso que importa, não o rótulo que se coloca na cadeira.
Primeiro entregável: os dados brutos do warehouse são organizados em marts de negócio. Camadas nomeadas segundo a linguagem da organização, não segundo as convenções técnicas do sistema fonte. Não tbl_cust_ev_log, mas clientes_ativos_30d, com sua definição escrita, seus testes automatizados, sua data de última atualização. É exatamente o que se entende por falar a linguagem do negócio com tabelas intermediárias.
Esses marts são construídos com ferramentas como dbt como camada de transformação. Cada modelo é versionado no Git, documentado inline, testado a cada execução. Se a definição de "cliente ativo" evolui, a mudança é rastreável: quem decidiu, quando, por quê. Se duas equipes usam duas definições incompatíveis, o teste falha e o problema surge antes de chegar ao relatório do comitê de direção.
O outro entregável estruturante é a documentação que vive no código. Não no Confluence, não em um wiki que ninguém atualiza depois do primeiro trimestre. No repositório, no mesmo lugar que as transformações. Uma documentação que se implanta junto com os dados. Se você quiser aprofundar esse ponto específico, detalhamos passo a passo como documentar a semantic layer em um artigo dedicado.
Resultado concreto: quando o CFO e o Chief Data Officer consultam o mesmo dashboard, eles veem o mesmo número de clientes ativos. Não porque concordaram verbalmente em uma reunião, mas porque existe apenas uma única definição no sistema, com suas regras de negócio explícitas e seus testes que garantem a consistência a cada atualização.
A semantic layer: esse contrato entre seus dados e suas equipes
O termo "semantic layer" merece um conteúdo preciso. Não é um conceito de conferência de dados, é algo concreto que se pode construir, testar e entregar.
Uma semantic layer é uma camada de abstração entre os dados brutos do seu warehouse e as pessoas que os consomem. À esquerda, tabelas com nomes como fact_contract_event_v2 ou stg_crm_accounts. À direita, conceitos que seu diretor comercial entende sem treinamento: "clientes ativos neste mês", "taxa de cancelamento nos últimos 12 meses", "ticket médio por segmento". Ela faz a ligação entre os dois, com regras explícitas, documentadas e testadas a cada atualização.
Quando é bem construída, os efeitos aparecem rápido. Cada equipe parte do mesmo referencial. Um analista de finanças e um analista de marketing trabalham em perímetros diferentes sem produzir números contraditórios, porque a base está estabelecida no código, não nas memórias individuais. Os novos integrantes aprendem sobre os dados em poucos dias ao invés de meses. As reuniões de reconciliação desaparecem.
Quando não é, cada equipe reconstrói suas próprias definições em suas próprias ferramentas. O analista de finanças tem sua view no PowerBI. O analista de marketing tem a dele no Tableau. Elas não se comunicam. Ao final de dezoito meses, você tem trinta marts não documentados, tabelas nomeadas temp_final_v3_ok, e uma dívida que ninguém ousa tocar com medo de quebrar algo. As decisões são tomadas com base em números que as equipes não conseguem mais explicar, ou que não ousam mais questionar. O custo não é técnico. É decisional.
Um exemplo no setor bancário e de seguros
Tomemos um caso recorrente nas organizações financeiras. Duas equipes calculam um indicador de risco: a taxa de sinistralidade, ou a taxa de créditos duvidosos conforme o setor.
A equipe de Riscos aplica sobre os contratos ativos na data de fechamento, com exclusão dos contratos em fase de litígio. A equipe de Finanças aplica sobre um período móvel de doze meses, sem exclusão. As duas metodologias são defensáveis do ponto de vista atuarial. Nenhuma está documentada no sistema de dados. As duas alimentam reportings que sobem ao comitê de direção.
Na reunião de pilotagem, os números diferem em quase dois pontos. Cada diretor defende seu perímetro. A reunião ultrapassa em muito seu horário. Nenhuma decisão é tomada.
Isso não é anedótico. Nas organizações financeiras que acompanhamos, esse cenário se reproduz nos indicadores de risco, no desempenho comercial, nas taxas de retenção, nos volumes de produção. O problema não é que as equipes estejam erradas. É que o sistema de dados nunca decidiu.
A resposta está em dois marts distintos: sinistralidade_riscos e sinistralidade_financas, com suas respectivas definições documentadas, seus filtros explícitos, e um modelo de reconciliação que expõe a diferença e sua causa. Quando as duas equipes consultam o dashboard, elas veem os dois números, sua diferença, e a regra de negócio que a explica. A reunião fala sobre a decisão a tomar, não sobre o número em que acreditar.
Isso é uma camada semântica comum. Não é mais uma reunião de governança. É um código que impõe clareza.
Por que essa função está ausente na sua organização
Três razões aparecem toda vez, em setores diferentes.
A competência é rara. Ela exige entender as necessidades de negócio com precisão suficiente para nomear as coisas corretamente, ou seja, preferir clientes_ativos_30d a dim_user_status, e dominar a técnica o bastante para produzir modelos dbt robustos, escrever testes que funcionem em produção, e estruturar uma camada que não se torne uma dívida em seis meses. Ela mantém uma conversa dbt com os data engineers, depois apresenta os KPIs a um diretor regional, sem que você faça a tradução.
A função é frequentemente diluída em outros papéis. Em muitas equipes, é o analista mais técnico que assume esse trabalho além do resto, sem método, sem ferramental coerente, sem tempo alocado. O resultado: marts meio documentados, testes que cobrem trinta por cento dos casos, uma camada que parece uma obra em andamento permanente. Um data catalog ativo torna essa dívida visível, mas não a resolve sozinho.
Não é uma necessidade permanente no mesmo nível de intensidade, portanto não necessariamente um cargo efetivo. O valor se concentra em dois momentos: a construção inicial da camada semântica, e as fases de expansão quando novos domínios de negócio chegam. Entre os dois, resta uma manutenção que as equipes internas podem garantir se o trabalho foi bem feito desde o início.
O que a Bomzai implementa
A Bomzai atua nesses assuntos no setor bancário, seguros, transporte e indústria. O que implementamos não é mais uma auditoria, nem uma recomendação de arquitetura que acaba na gaveta.
É uma camada semântica em produção: marts documentados e nomeados segundo o vocabulário de negócio da sua organização, testes automatizados que validam a consistência das definições a cada atualização, um catálogo de métricas que sua equipe de dados pode manter sem nós após a entrega.
Nossos consultores mantêm as duas conversas ao mesmo tempo. Eles trabalham com os data engineers nas transformações e apresentam as definições de KPI à direção de negócio, sem que você tenha que servir de intérprete entre suas equipes técnicas e de negócio. É precisamente a competência que falta, e é a que colocamos diante do seu problema.
Primeiro entregável em produção: seis a oito semanas. Não seis meses de roadmap antes de ver qualquer coisa rodando.
A verdadeira pergunta a fazer
A pergunta não é "vocês têm alguém com tal ou tal cargo?". As organizações colocam palavras diferentes por trás das mesmas missões, e um data engineer pode muito bem realizar esse trabalho. A pergunta útil está em outro lugar.
Primeiro: vocês dispõem de uma camada semântica? Definições de negócio estabelecidas no código, documentadas, testadas, compartilhadas por todas as equipes que consomem dados. Depois: vocês têm pessoas cujo papel é explicitamente mantê-la e fazê-la evoluir quando as definições mudam e novos domínios chegam? Essas missões de governança são geralmente conduzidas pelo data office, quando ele existe.
Se você respondeu não às duas perguntas, o problema não é que suas equipes carecem de rigor. É que nenhuma camada decide por elas. Podemos construí-la com você, e deixá-la com você.
