Um relatório Power BI pode ter um aspeto impecável e, ainda assim, falhar logo nas primeiras semanas de utilização. Demora a abrir, um total não coincide com o valor que a área financeira conhece, ou ninguém consegue explicar como é calculado um indicador. Estes problemas raramente se notam numa demonstração e só surgem quando o relatório já está a ser usado para tomar decisões. 

Durante muito tempo, a forma de os evitar foi a revisão manual: um elemento mais experiente da equipa abria o modelo e verificava, ponto a ponto, o que estava bem e o que precisava de ser corrigido. Este método funciona, mas depende de quem revê e do tempo disponível. Neste artigo explicamos como passámos a fazer esta validação com critérios definidos e ferramentas próprias, e o que isso muda para a equipa e para o cliente. 

O que normalmente falha num relatório entregue

A maioria dos problemas não está no que se vê no ecrã, mas no modelo semântico, que é a camada que fica por trás do relatório, onde estão as tabelas, as relações entre elas e os cálculos que dão origem a cada número.  

As falhas mais comuns dividem-se em quatro grupos: 

Relatórios lentos. O modelo carrega colunas que nenhum visual utiliza. As tabelas estão ligadas por relações bidirecionais ou de muitos-para-muitos, e cada filtro obriga o Power BI a fazer mais cálculos. As datas são guardadas juntamente com a hora, o que aumenta o tamanho do modelo. Cada filtro demora segundos a responder e os utilizadores acabam por exportar os dados para Excel. 

Números que não batem certo. Há medidas repetidas com nomes diferentes, divisões que dão erro quando o denominador é zero e comparações com o ano anterior feitas sem uma tabela de calendário bem configurada. Quando um valor não coincide com o de outro relatório ou com o sistema de origem, o utilizador passa a confirmar os números noutro lado e o relatório perde utilidade. 

Modelos difíceis de manter. Os nomes das tabelas e medidas não são claros, as chaves técnicas aparecem ao utilizador, os cálculos não têm descrição e há valores fixos escritos dentro das fórmulas. Cada alteração pedida pelo cliente demora mais e tem mais risco, sobretudo quando quem a faz não foi quem construiu o modelo. 

Ausência de documentação. A documentação fica normalmente para o fim do projeto, quando já falta tempo. O conhecimento sobre o modelo fica com quem o desenvolveu, e o cliente recebe um relatório que funciona, mas que não consegue explicar. 

Com o crescimento da equipa e do número de projetos, rever tudo à mão em cada entrega deixou de ser viável. Um modelo de dimensão média tem dezenas de tabelas e centenas de colunas e medidas. Duas pessoas a rever o mesmo modelo chegam muitas vezes a conclusões diferentes, e o que se verificou num projeto não fica registado para o seguinte. Foi para resolver isto que criámos o Quality Guard. 

Os critérios que verificamos 

O Quality Guard é o conjunto de ferramentas que o nosso Centro de Excelência de Power BI utiliza para garantir a qualidade dos relatórios. É composto por três peças: as Medallion Rules, que definem os critérios; as BPA Rules, que verificam o modelo de forma automática; e o Smart PBI, um conjunto de scripts que já cumprem esses critérios desde o início do desenvolvimento. 

As Medallion Rules são uma lista de boas práticas organizada em quatro áreas: a modelação dos dados, o desenho dos relatórios, o DAX (a linguagem usada para escrever os cálculos) e a configuração do Power BI Service, a plataforma onde os relatórios são publicados e partilhados. 

Dentro de cada área, as regras estão divididas em três níveis: Gold, Silver e Bronze. As regras Gold são as que nenhum relatório deve falhar, as Silver são fortemente recomendadas e as Bronze são melhorias que ganham importância em modelos maiores ou mais complexos. Esta divisão ajuda a definir prioridades quando o tempo do projeto é limitado. 

A tabela seguinte mostra um exemplo de regra Gold em cada área e o que essa regra garante a quem usa o relatório. 

Com uma lista comum, quem desenvolve e quem revê usam os mesmos critérios. Quando uma regra não pode ser cumprida, por limitações da fonte de dados ou por um pedido do cliente, a exceção é aceite desde que seja justificada. Ainda assim, continua a ser preciso verificar cada regra em cada modelo. Essa verificação é feita com as BPA Rules. 

Como o Quality Guard automatiza a verificação 

As BPA Rules (Best Practice Analyzer) transformam parte das Medallion Rules em verificações automáticas. São 71 regras executadas no Tabular Editor, uma ferramenta externa ao Power BI usada por quem desenvolve modelos. Em poucos segundos, todo o modelo é comparado com essas regras e o resultado é a lista dos pontos que não as cumprem. 

A tabela seguinte mostra como algumas destas regras correspondem às falhas descritas no início do artigo.

Cada regra tem um nível de gravidade, de 1 a 3, e as de gravidade mais alta têm de estar resolvidas antes da entrega. Em 19 regras, a correção pode ser feita automaticamente pelo Tabular Editor, por exemplo para esconder chaves técnicas ou aplicar o formato correto aos números. 

Os resultados são reunidos num relatório Power BI que mostra os avisos por gravidade, por área de negócio e por modelo, o que permite acompanhar a evolução de cada modelo ao longo do projeto. A análise ainda é lançada por um elemento da equipa, mas as regras são sempre as mesmas, independentemente de quem a executa. 

Figura 1: Página de resumo do relatório de resultados das BPA Rules. 

O Smart PBI atua antes da validação. É um conjunto de scripts que criam, em poucos minutos, elementos de que quase todos os modelos precisam: a tabela de calendário, os cálculos de comparação entre períodos e as ligações às fontes de dados mais comuns. Como estes scripts já seguem as Medallion Rules, um modelo construído com eles chega à fase de validação com menos problemas. A tabela de calendário já vem configurada e não são precisas dezenas de medidas que repetem os mesmos cálculos de tempo para cada indicador. 

Documentação como subproduto, não como tarefa extra 

A quarta falha descrita no início do artigo, a ausência de documentação, é tratada pelo Doc4PBI. A ferramenta gera a documentação a partir do próprio modelo semântico, que já contém toda a informação necessária: tabelas, colunas, medidas, relações e cálculos, pelo que não é preciso escrevê-la à mão no fim do projeto. 

Existem duas versões. A versão para Power BI Desktop usa funções nativas do Power BI para criar, dentro do modelo, tabelas com esta informação, que acompanham cada atualização dos dados. A versão para Microsoft Fabric documenta vários modelos de uma só vez e mostra também as dependências entre cálculos, ou seja, que medidas são usadas por outras. 

Na fase de validação, o Doc4PBI dá a quem revê uma visão completa do modelo num único relatório: que medidas não têm descrição, que objetos estão escondidos e como as tabelas se relacionam. No fim do projeto, a mesma documentação é entregue ao cliente, sem trabalho adicional. O funcionamento da ferramenta é explicado em detalhe num artigo anterior, “Doc4PowerBI: Documenting Your Power BI Models Without Writing a Single Line of Code”.

Figura 2: Página de documentação do Doc4PBI, gerada a partir do modelo semântico. 

Exemplo de aplicação do Quality Guard 

Aplicámos o Quality Guard a um relatório interno do nosso Centro de Excelência, usado para acompanhar as atividades, os ativos e os casos de estudo da equipa. O modelo tinha sido construído com o calendário do Smart PBI, mas as BPA Rules nunca tinham sido executadas sobre ele. A primeira análise identificou 296 avisos. Depois das correções, o número desceu para 164. A maior parte foi resolvida com a correção automática do Tabular Editor e com uma única alteração de configuração no Power BI.

As correções com maior efeito foram três: 

Tabelas de datas automáticas. O Power BI estava a criar quatro tabelas de datas escondidas, que ocupavam espaço e repetiam o trabalho do calendário já existente. Desligar esta opção eliminou, por si só, cerca de 20 avisos. 

Formato das medidas. As medidas numéricas passaram a ter separador de milhares, para que os valores apareçam da mesma forma em todos os visuais. 

Colunas técnicas. As chaves técnicas foram escondidas do utilizador e várias colunas foram ajustadas para que o Power BI leia menos dados em cada página. 

Os nove avisos de gravidade alta mantiveram-se de forma intencional. Correspondem a medidas que devolvem texto, como títulos dinâmicos, e a um parâmetro de campo, casos em que a regra não se aplica. São o tipo de exceção justificada previsto nas Medallion Rules. Cerca de metade dos avisos que restam são objetos sem descrição, que podem ser tratados numa fase seguinte. 

O que muda para a equipa e para o cliente 

Para a equipa, a revisão segue sempre os mesmos critérios e a verificação do modelo faz-se em minutos. Quem entra num projeto a meio encontra um modelo organizado e documentado e começa a trabalhar mais depressa. 

Para o cliente, os relatórios respondem mais depressa e os números coincidem entre páginas e entre relatórios. O modelo pode ser mantido por outra equipa, interna ou externa, e a documentação faz parte da entrega. 

Conclusão 

Com o Quality Guard, a qualidade de um relatório deixa de depender de quem o revê ou do tempo que sobra no fim do projeto. As Medallion Rules definem os critérios, as BPA Rules verificam o modelo e o Doc4PBI gera a documentação, e cada modelo é validado da mesma forma antes de chegar ao cliente. Os problemas são encontrados durante o desenvolvimento, quando ainda são simples de corrigir.