Tecnologia
Consultoria e implementação de Power BI
A empresa tem painel para tudo e nenhuma métrica acordada. Duas áreas abrem dois relatórios e chegam a dois números de receita, ambos defensáveis. A reunião passa a discutir de quem é o número, em vez de decidir com ele. Enquanto isso a atualização demora cada vez mais, e quem pede um recorte novo espera pelo relatório que só uma pessoa sabe mexer.
Como a gente encara.
O trabalho começa pela métrica, não pelo relatório. Cada número usado para decidir recebe uma definição só, com um dono do negócio que desempata. Depois a regra de negócio desce para a camada de dado, e o Power Query fica só com tipagem, nome de coluna e ajuste de estrutura. O modelo passa a ter fato e dimensão em vez de uma tabela larga. E o acesso é desenhado antes da publicação, com row-level security onde há dado que não deve circular.
Onde costuma quebrar
Os erros que aparecem sempre, e que ninguém conta na demonstração.
- 01
Cada área com a sua própria definição de receita, escrita em DAX dentro do relatório dela. As duas medidas estão corretas e devolvem números diferentes, e não existe lugar nenhum onde olhar para saber qual vale.
- 02
Transformação pesada feita no Power Query em vez da camada de dado. A atualização demora porque o mesmo trabalho é refeito a cada execução, e a regra fica invisível para quem não abre o arquivo.
- 03
Modelo em tabela única e larga. O motor é colunar: ele lê segmentos das colunas que a medida pede, não a tabela, e comprime cada coluna pela repetição dos valores dela. Repetição, aliás, é o caso barato: cada valor distinto entra uma vez no dicionário da coluna e a linha guarda só o índice dele, e sequências iguais ainda são colapsadas pela codificação por repetição (run-length encoding). O que a tabela larga cobra é outra coisa: você passa a pagar esse índice em toda linha do fato, e não nas poucas linhas da dimensão, e arrastar para o fato um atributo de alta cardinalidade infla o dicionário e acaba com as sequências que o compressor colapsaria. O arquivo incha, mais segmento precisa ser varrido, e a medida que era instantânea passa a fazer o seu usuário esperar. Fato e dimensão existem por causa disso, não por gosto de modelagem.
- 04
Publicação sem controle de acesso. O relatório é compartilhado com quem pedir, carrega o detalhe por cliente ou por pessoa, e não há row-level security separando quem enxerga o quê.
O que custa mais do que parece
- Capacity dedicada é cara e costuma ser comprada como remédio para modelo mal desenhado. Ela compra tempo, não corrige a causa: o mesmo modelo largo continua comprimindo mal e varrendo mais do que precisaria, e o alívio dura até o volume alcançar a capacidade nova.
- A atualização programada consome janela que compete com a carga do próprio dado. Se o dataset atualiza enquanto o pipeline ainda escreve, você publica número pela metade; e sem incremental refresh cada atualização relê todo o histórico só para trazer o dia.
- O gateway de dados local (on-premises data gateway) é uma peça sua, permanente, e quase ninguém a orça. Tudo que vem de fonte que não está na nuvem atravessa esse serviço, que costuma acabar instalado na máquina de uma pessoa e autenticado com a conta dela. Quando essa máquina é trocada, quando a senha muda ou quando essa pessoa sai, a atualização programada para — e a falha chega como dado velho no painel, não como erro que alguém receba.
O que você recebe
- Lista dos números que a empresa usa para decidir, cada um com uma definição só e um dono do negócio que desempata.
- Transformação movida para a camada de dado, com o Power Query reduzido a tipagem, renomeação de coluna e ajuste leve de estrutura.
- Modelo com fato e dimensão, medidas centralizadas e o caminho de cada número até a origem documentado.
- Política de acesso escrita, com row-level security onde há dado restrito e revisão de quem enxerga cada workspace.
- Janela de atualização acordada com a carga de origem, incremental refresh onde ele cabe e gateway com dono nomeado.
O que fazemos com Power BI
Open source ou enterprise, a frente é a mesma.
Implantar
Do zero, com a arquitetura decidida no diagnóstico e não pelo catálogo do fornecedor.
Migrar
De outra ferramenta, ou de uma versão antiga, com o que já roda continuando a rodar.
Desenvolver em cima
Aplicação, integração e automação construídas sobre Power BI, incluindo o que a ferramenta não faz sozinha.
Sustentar
Operação, custo sob controle e correção de rota depois que entra em produção.
Perguntas diretas.
- Quando um relatório novo não é a resposta?
- Quando a pergunta será feita uma vez: uma consulta responde hoje e não deixa mais um painel para alguém manter para sempre. Quando quem consome o número é um sistema, e não uma pessoa, o que se precisa é de uma tabela ou de uma interface, não de uma tela. E quando o incômodo é que dois números discordam, mais um relatório só acrescenta um terceiro número defensável ao debate. Painel é bom para acompanhar o que se olha com frequência; para o resto ele é a resposta que parece produtiva e não é.
- Dá para dar autonomia às áreas sem voltar a ter uma definição de receita por área?
- Dá, separando o que cada um faz. As medidas ficam num modelo semântico compartilhado, mantido por quem responde pela definição, e as áreas se conectam a ele para montar as suas próprias visões. Elas ganham a liberdade que importa — recorte, filtro, layout — sem escrever a regra de novo. A parte difícil não é técnica: alguém precisa ter o mandato de dizer que aquela medida nova é a medida que já existe com outro nome. Sem esse alguém, o modelo compartilhado vira só mais um lugar onde a divergência mora.
- Precisamos de um data warehouse antes, ou dá para conectar direto no sistema de origem?
- Se o dado vem de um sistema só, o volume é pequeno e a regra é simples, conectar direto funciona e evita uma camada inteira. A conta muda quando existem várias fontes que precisam ser reconciliadas, ou histórico que a origem sobrescreve. Aí cada relatório passa a refazer a junção do seu jeito, a atualização começa a pesar sobre o banco que atende a operação, e o dado de ontem já não existe mais para conferir. É esse ponto, e não o tamanho da empresa, que indica quando a camada intermediária deixa de ser luxo.
Antes de escolher a ferramenta
A ferramenta é consequência da arquitetura. Nunca a premissa.
Esta página existe porque alguém procura por esse nome. Mas a escolha certa sai do diagnóstico do seu cenário, não do catálogo de quem vende. Se a resposta for outra ferramenta, ou nenhuma, é isso que você vai ouvir.
Não está na lista? Não é impedimento, é conversa. O que decide não é o nome do produto, é o problema que ele precisa resolver.