Consultor Líder de BI & Analytics Engineering

Eu transformo dados complexos em algo útil.

Eu projeto plataformas modernas de analytics e produtos de BI que transformam dados em escala empresarial em decisões claras e confiáveis.

Rafael Figueiredo

Próximo a Frankfurt · Alemanha

8+anos desenvolvendo
analytics empresarial
3 bi+registros processados em
modelos de BI de larga escala
400+gestores atendidos
por uma única solução
5idiomas falados
em equipes globais

Experiência

Trabalho em empresas complexas.

Escolha uma empresa para ver as funções, tecnologias e contribuições detalhadas por trás do trabalho.

Deutsche BahnDeutsche LeasingSamsungWIRTGEN GROUPINNIO GroupMercedes-Benz Tech InnovationDeutsche BankRoche Diagnostics

Estudos de caso

A cadeia inteira — e o que custou confiar nela.

Projetos públicos documentados de ponta a ponta — incluindo os defeitos encontrados no caminho e os limites do que os números finais conseguem provar.

Licitações da UE: um produto de BI de ponta a ponta

Dados públicos reais de licitações, levados até o fim: sistemas de origem incompatíveis, um Data Vault absorvendo a resolução de entidades, marts dimensionais e um modelo semântico que publica a própria cobertura e integridade ao lado dos números. Cada métrica é definida por escrito antes de existir qualquer DAX, e testes de regressão fixam cada uma em um contexto de filtro conhecido.

PostgreSQLdbtData VaultPower BIAirflow
Ler o estudo de caso

Três números pareciam perfeitos e estavam errados. Encontrá-los é o trabalho de verdade; o pipeline que os produziu é commodity. Aqui está em que consistia cada defeito, como ele apareceu e o que os números finais ainda assim não conseguem dizer.

351adjudicações na amostra atual
61,8%dos valores adjudicados passam nas regras de qualidade
29testes de regressão fixando cada métrica
0,3%das adjudicações associadas a um ministério federal

Uma proporção que só podia dar zero

A proporção de contratos-quadro foi medida a princípio sobre o valor certificado — o total que exclui as adjudicações reprovadas nas regras de qualidade da camada de dados. Toda adjudicação de contrato-quadro é reprovada por essas regras, porque o tratamento ambíguo do contrato-quadro é justamente o que impede certificar o valor. A métrica devolvia, portanto, 0% em qualquer contexto de filtro, de forma permanente, e aparecia como um zero limpo e confiante.

Medida sobre o total que inclui valores não verificados, onde as adjudicações de contrato-quadro de fato estão presentes, ela indica 45,7%. O defeito não estava no DAX, e sim na escolha da base — o tipo de erro que nenhuma verificação de sintaxe enxerga.

Um total orçamentário que somava receita com despesa

O arquivo do orçamento federal alemão contém as duas metades do orçamento. Um orçamento fecha em equilíbrio, então somar todas as linhas devolve praticamente o dobro: € 993 bi contra um Bundeshaushalt de 2022 efetivo de € 495,8 bi — um número que pareceria perfeitamente plausível num cartão.

O primeiro dígito do código do Gruppierungsplan separa as duas: os grupos 0–3 são receita e financiamento, os grupos 4–9 são despesa. Cada metade agora reconcilia em € 495,79 bi no exercício de 2022, batendo com o orçamento publicado. A classificação começou como coluna calculada no modelo semântico e desde então passou para o warehouse, onde é derivada da origem e todo consumidor a herda em vez de deduzi-la de novo.

Uma taxa que dividia um recorte por outro

A proporção de contratos-quadro filtra a mesma coluna pela qual quem lê também pode filtrar. Sem KEEPFILTERS, o filtro interno da métrica substitui o filtro de quem lê em vez de restringi-lo. Filtrada para adjudicações fora de contrato-quadro, ela devolvia 84% — valor de contrato-quadro dividido por valor fora de contrato-quadro. Não era erro nem vazio: uma porcentagem plausível que não significa nada.

Toda taxa do modelo agora envolve o filtro do numerador em KEEPFILTERS, e cada uma tem um teste que afirma o comportamento correto ao ser filtrada pela coluna que ela filtra. A maioria dos defeitos de DAX são defeitos de contexto de filtro, por isso a suíte fixa as métricas em vários contextos e não apenas no total geral.

Definições antes do DAX, inclusive as contestadas

Cada métrica foi definida por escrito antes de existir qualquer DAX. Se um número é definido apenas pelo código que o calcula, o código vira a definição, e ninguém consegue dizer se ele está certo — apenas se ele roda.

O contrato também registra onde existe mais de uma definição defensável. A taxa de licitante único é o caso claro: 55 das 351 adjudicações não registram quantas empresas apresentaram proposta. Contando apenas as adjudicações com número de propostas conhecido, dá 19,9%; contando todas, 16,8%. Uma diferença de 3,1 pontos não é arredondamento, e muda a leitura do achado. A primeira é certificada, a segunda é publicada ao lado, e nenhuma aparece sem a cobertura de dados de propostas de 84,3% que limita as duas.

A junção que falhou, publicada como achado

O desenho original comparava o volume de licitações com os orçamentos por ministério. Apenas 1 de 104 compradores pôde ser associado a um ministério federal. A causa é estrutural, não uma questão de ajuste fino: os compradores alemães que aparecem no TED são em sua maioria municípios, estados, hospitais e concessionárias, enquanto o orçamento federal cobre apenas ministérios federais. Os dois conjuntos quase não se sobrepõem, então nenhum matching melhor consegue ligá-los.

A comparação foi retirada do relatório. Em seu lugar entra a junção que falhou, como achado — dois conjuntos de dados oficiais sobre atividade governamental correlata que não podem ser ligados nesse escopo. Resolver isso direito exigiria dados orçamentários estaduais e municipais, o que é uma fase posterior.

Ver o repositório
Warehouse, modelo semântico e relatório construídos · 29 testes de modelo aprovadosRepositório público

Os maiores bancos do Brasil: uma camada de BI governada sobre dados oficiais

Quinze meses de balancetes COSIF do Banco Central e cinco séries macroeconômicas, levados dos arquivos brutos até um modelo de Power BI versionado. Quatro linhas de relatório são mapeadas a partir de contas de primeiro nível e reconciliam com a origem até o centavo; cada métrica é definida por escrito antes de existir qualquer DAX, e o relatório publica a própria proveniência e reconciliação ao lado dos números.

PostgreSQLdbtDagsterPower BIdlt
Ler o estudo de caso

O pipeline é commodity; confiar nos números é o trabalho de verdade. Um balanço que se somava ao longo dos meses, uma métrica de crescimento que compilava para nada, quatro linhas que nunca podem ser somadas — aqui está em que consistia cada uma, como apareceu e o que os números finais ainda assim não conseguem dizer.

R$ 13,67 triativos totais dos 15 maiores bancos, mar. 2026
900saldos auditados por banco, mês e linha de relatório
R$ 0,00diferença na reconciliação dos marts com as contas de origem
214/214nós de modelo e teste do dbt aprovados

Um balanço que se somava ao longo de quinze meses

O primeiro cartão marcava R$ 190 trilhões em ativos totais. Um saldo é um estoque, não um fluxo: somar o balanço de março ao de fevereiro não faz sentido, mas um cartão sem filtro de mês soma os quinze meses e exibe um número confiante e errado.

Agora toda métrica de saldo é semiaditiva — devolve o mês mais recente no contexto, então um cartão mostra a foto de março, R$ 13,67 tri, enquanto a linha de tendência mensal continua intacta. O defeito não estava na aritmética; estava em tratar um estoque como fluxo.

Uma métrica de crescimento que compilava para nada

O crescimento mês a mês usava DATEADD a princípio. A tabela de datas é de grão mensal — quinze linhas, uma por mês de referência — e o DATEADD precisa de um calendário diário contíguo, então ele falhava enquanto todos os outros visuais renderizavam. Reescrita com EDATE e um filtro explícito sobre a tabela de datas, ela funciona em grão mensal.

Por baixo escondia-se uma falha ainda mais estranha: a mesma métrica compilava silenciosamente para um stub de erro porque uma variável se chamava Current — um token que este interpretador de DAX reserva e rejeita sem erro visível. Renomeada para CurVal, ela compila. Os dois são o tipo de defeito que nenhuma verificação de sintaxe enxerga; pegá-los exigiu consultar o modelo ao vivo, não confiar que ele havia carregado.

Quatro linhas que nunca podem ser somadas

Ativos totais, carteira de crédito, depósitos e patrimônio ficam em lados diferentes do balanço: dois são ativos, um é passivo, um é patrimônio. Somados, não significam nada. Por isso o modelo nunca os totaliza, e toda razão divide por ativos totais — o único denominador certificado.

Uma métrica genérica de 'cobertura do mapeamento' foi descartada pelo mesmo motivo: as contas COSIF são hierárquicas, então uma conta-pai já contém as filhas, e não há um único denominador com sentido entre lados diferentes. A cobertura, onde significa algo, é expressa por lado — crédito como proporção dos ativos já é isso.

Definições antes do DAX, e um contrato que diz o que não está certificado

Cada métrica foi definida por escrito antes de existir qualquer DAX, com um status. Ativos totais é certificado contra o ranking de origem reproduzido; crédito, depósitos e patrimônio são rascunhos governados, porque o mapeamento das contas é defensável mas ainda não foi formalmente aprovado. Se um número é definido apenas pelo seu código, o código vira a definição e ninguém consegue dizer se ele está certo.

A camada de dados de propósito não calcula nenhuma das razões de negócio. Ela entrega os marts certificados e garante o formato deles; as razões e seus denominadores contestados vivem num contrato de métricas, onde podem ser vistos e questionados em vez de enterrados numa métrica.

Confiança como página, reconciliação declarada com honestidade

O relatório traz uma página de Confiança: o período de origem mais recente, o checksum do arquivo ativo, as datas de coleta declaradas separadamente das datas de referência, o mapeamento de sete contas para quatro linhas e uma declaração de escopo em linguagem simples. Ela lê apenas os marts certificados — a camada de BI nunca toca nas tabelas brutas, de staging ou de núcleo.

A reconciliação é declarada como um fato do momento da certificação — os saldos por linha de relatório reproduzem as somas das contas de origem mapeadas até o centavo — e não como um número ao vivo, porque o warehouse não reconcilia de novo a cada atualização. Afirmar o contrário seria um número mais confiante que significa menos.

Ver o repositório
Camada de dados certificada · modelo de Power BI e relatório de três páginas construídos e verificados ao vivoRepositório público

Em desenvolvimento

Ferramentas criadas a partir de problemas que vale resolver uma vez.

Projetos paralelos nascidos da consultoria para eliminar uma etapa manual quando o mesmo problema aparecer novamente.

Medallion orientado por metadados para Fabric

Um framework de ingestão baseado em configuração, não em código. Tabelas de controle de metadados conduzem as camadas Bronze, Silver e bridge que alimentam um modelo semântico Direct Lake. Assim, integrar uma tabela significa inserir linhas de metadados em vez de escrever código. A reconciliação falha de forma explícita quando há divergências, e todo o framework pode ser instalado pelo navegador.

Microsoft FabricPySparkPythonMedallion
Implantado e em execuçãoRepositório privado

Toolkit para modelos semânticos do Fabric

Notebooks para operações de modelo que normalmente exigiriam cliques em uma interface: ciclo de vida da atualização incremental, diagnósticos somente leitura até o consumo VertiPaq por coluna, alterações cirúrgicas de metadados com TOM e clonagem de modelos entre workspaces com reconexão dos relatórios.

Microsoft FabricTOMXMLAPython
Em uso · v0.6.0Repositório privado

Ecossistema de design para Power BI

Três camadas reutilizáveis para que o design no Power BI não precise resolver os mesmos problemas em cada projeto: um sistema de temas alinhado à marca, um registro tipado de componentes de relatório e um builder que monta relatórios a partir de uma especificação sob um tema.

Power BIPBIRTemasPython
Camada de temas pronta · componentes e builder em andamentoRepositório privado

O que eu ofereço

De dados brutos a ações seguras.

Atuo em toda a jornada de analytics, com profundidade especial onde engenharia, design de BI e adoção se encontram.

Produtos de BI

Experiências em Power BI e Tableau construídas em torno das decisões que as pessoas realmente precisam tomar.

Power BI · Tableau · DAX · UX

Analytics engineering

Modelos semânticos reutilizáveis, transformações testadas e pipelines que permanecem compreensíveis enquanto escalam.

SQL · Python · dbt · PySpark

Plataformas modernas de dados

Arquiteturas pragmáticas que cobrem ingestão, camadas Lakehouse, modelagem e consumo governado.

Fabric · Azure · Databricks · AWS

Liderança técnica

Liderança colaborativa em migrações, padrões, mentoria, alinhamento com stakeholders e capacitação de equipes.

Estratégia · Treinamento · CI/CD · SAFe
O melhor produto de analytics não é o dashboard mais carregado. É aquele em que as pessoas confiam o suficiente para agir.

Combino engenharia prática com a visão de consultor sobre o sistema completo: a pergunta de negócio, o modelo de dados, a interface e as pessoas que assumirão sua evolução.

01

Definir a decisão

Começar pela pergunta de negócio, pelo público e por como deve ser uma decisão melhor.

02

Construir a base

Criar modelos, pipelines e práticas de entrega que tornem analytics confiável algo repetível.

03

Fortalecer a equipe

Compartilhar padrões, orientar colaboradores e tornar o sistema final mais fácil de assumir e evoluir.

Disponível para projetos híbridos e remotos selecionados

Tem um desafio complexo de BI?

Vamos transformá-lo em um próximo passo claro.

Iniciar uma conversa
Aschaffenburg · região de FrankfurtInglês · Alemão · Português