Um portal de clientes com Power BI Embedded

No quinto ano construindo uma área de BI dentro de uma consultoria que atende escolas particulares no Brasil, o difícil já não eram os dados. Scripts em Python faziam o tratamento, os relatórios liam do SQL Server e a equipe tinha chegado a quatro pessoas. Faltava cuidar do último elo da corrente: como um relatório pronto chegava à pessoa que tinha pedido por ele.

Este texto faz parte de uma série sobre seis anos construindo uma área de BI. Ele trata do quinto ano, quando construí um portal web em volta do Power BI Embedded e o trabalho de BI passou a existir fora dos projetos de consultoria que o tinham criado.

Onde a área de clientes começou

O portal nasceu de algo mais antigo. No meu primeiro ano, uma das primeiras tarefas foi criar uma área de clientes para a consultoria compartilhar os resultados do seu trabalho. Ao mesmo tempo, eu migrava para o Power BI todos os relatórios que a empresa produzia. Contei esse começo em Power BI como produto.

Aquela primeira área de clientes provou uma coisa logo cedo: os clientes perceberam a visualização mais clara e interativa dos próprios dados, e deram valor a ela. O BI deixou de ser tarefa paralela e virou um item do nosso portfólio.

Quatro anos depois, o cenário era outro. O tratamento estava automatizado, os relatórios estavam mais rápidos e havia gente para cuidar deles. Por isso, os objetivos do quinto ano giravam em torno de quem lia. Eu queria melhorar a experiência de quem abria os relatórios e queria um produto que se sustentasse sozinho, além dos contratos de consultoria.

Por que compartilhar é a parte difícil

Montar um relatório é problema resolvido. Colocá-lo na frente de alguém de fora da empresa, com segurança, é onde muito projeto de BI emperra.

O atalho tentador é o publicar na web. Ele gera um link que qualquer pessoa abre, sem login nenhum. Para dado público, tudo bem. Para qualquer coisa confidencial, é a ferramenta errada, porque o link é a única tranca. Resultado de pesquisa ou número financeiro de uma escola não pode ficar a um encaminhamento de distância de um desconhecido.

O outro caminho é trazer cada leitor para dentro da própria ferramenta de BI, do lado do cliente, com um acesso para administrar. Isso joga o trabalho em cima de quem só quer ler um painel. Cada leitor novo vira uma configuração nova, e a experiência passa a depender da intimidade de cada escola com uma ferramenta que ela não escolheu.

Nenhuma das duas opções servia para o que eu queria: o cliente abre uma página, entra com seu login e vê os seus relatórios, sem precisar aprender nada.

Como o portal funcionava

O modelo que usamos é o que a Microsoft chama de embed for your customers, também conhecido como app owns data. O nome assusta, mas a lógica cabe em quatro linhas:

• O cliente entra na nossa aplicação, não no Power BI.
• A nossa aplicação se autentica sozinha no Power BI, por meio de uma entidade de serviço (service principal), e pede os relatórios que aquele cliente pode ver.
• Os relatórios rodam numa capacidade paga por nós, o fornecedor.
• Quem vê os relatórios não precisa de licença própria do Power BI.

A aplicação era um sistema web em Python feito com Flask, com o front-end em JavaScript, HTML e CSS puros. Nada de exótico, e de propósito. O Python já rodava o nosso tratamento de dados, então portal e rotinas de dados falavam a mesma língua: quem lia uma parte conseguia acompanhar a outra.

O front-end envolvia os relatórios incorporados nas nossas próprias páginas, para que o cliente visse um produto só, e não uma colcha de retalhos de ferramentas.

O que mudou

O primeiro efeito apareceu do nosso lado. A manutenção dos relatórios ficou mais simples, porque os relatórios e o caminho que os clientes faziam até eles passaram a morar num sistema só, sob o nosso controle.

O segundo efeito foi do lado do cliente. As pessoas ganharam acesso seguro e prático às próprias informações. Entravam num portal e encontravam o que era delas, sem depender de alguém mandar arquivo ou link.

Depois veio o número: um crescimento de 400%. Não atribuo esse resultado só ao portal. Ele foi construído em cima de um ano de automação e de uma equipe maior, e sem isso seria uma bela porta de entrada para um prédio lento. Mas foi a peça que fez o BI funcionar como produto, usado pelos clientes por conta própria, fora dos projetos de consultoria.

O que eu faria de novo

Olhando para trás, algumas decisões daquele ano continuam de pé, e eu as tomaria do mesmo jeito hoje.

• Tratar a entrega como parte do trabalho de BI, e não como detalhe do fim. Relatório difícil de achar é relatório que as pessoas param de abrir.
• Fazer o cliente entrar no seu produto, e não na ferramenta de BI. Autenticação e capacidade ficam do seu lado, onde você consegue administrar.
• Nunca colocar dado privado atrás de link público, nem para um teste rápido. Teste rápido tem o hábito de virar definitivo.
• Construir com a tecnologia que a equipe já domina. No nosso caso era Python, então o Flask foi o caminho mais curto entre a ideia e o portal funcionando.
• Começar pequeno. A área de clientes do primeiro ano veio antes, e o portal cresceu a partir dela. Anos de uso real vieram antes da primeira linha de código do portal.

A mesma ideia, compartilhar o BI com quem é de fora sem obrigar essa pessoa a entrar na sua estrutura, é o que a plataforma de BI da bi19 faz hoje: ela compartilha painéis e relatórios do Power BI com pessoas de fora da sua organização. A última parte da série trata do ano em que o trabalho saiu dos sistemas e foi para as pessoas: liderar uma equipe de BI.