Por que dashboards de autoatendimento não funcionam

• "self-serve dashboards" na prática não funcionam bem, porque engenheiros ou cientistas de dados acabam gastando muito tempo escrevendo queries e preparando dashboards para usuários de negócio.

Por que o "self-serve BI" não funciona

• SQL é a única ferramenta real de "self-serve BI". Mas a maioria dos fornecedores de "self-serve BI" tenta disfarçar SQL como se fosse outra coisa.
• Escrever queries SQL não é a única barreira para que stakeholders de negócio consultem dados. Eles não entendem o significado dos dados, de onde vêm, como são calculados, nem sabem como interpretar e validar os resultados.

Tentativa 1: a abordagem tradicional de "menus suspensos e caixas de seleção"

• Essa interface não passa de uma tentativa de fazer "SQL-by-mouse". Não é melhor que SQL; na verdade, é mais lenta, menos confiável, mais limitada e não pode ser generalizada para outras ferramentas.
• Pessoas como um CFO não vão usar essa interface para consultar dados, porque não têm o contexto necessário para entender os dados nem confiança nos resultados.

Tentativa 2: a abordagem text-to-SQL

• LLMs são quase eficazes demais em traduzir linguagem natural para SQL. Eles vão tentar gerar uma query mesmo quando a pergunta não fizer sentido.
• Um profissional técnico perceberá quando a pergunta não faz sentido e pedirá mais contexto. Vai explicar os tipos de dados disponíveis e colaborar com a área de negócio para formular perguntas precisas e úteis.
• LLMs podem vir a ser a solução real para "self-serve BI", mas ainda não em sua forma atual. Eles precisam de mais contexto e de maior capacidade para expressar incerteza e pedir mais informações.

O que realmente funciona

• O problema do "self-serve BI" não é o SQL, mas o contexto e o significado dos dados. A solução, independentemente da interface, é ensinar às pessoas sobre os dados que estão consultando.
• Fazer com que a equipe técnica documente todo o conhecimento gera uma sobrecarga considerável e rapidamente fica desatualizado.
• A verdadeira solução para "self-serve BI" não é tornar o BI "self-serve" para pessoas não técnicas, mas permitir que profissionais técnicos deem suporte aos stakeholders de negócio com mais eficiência, usando ferramentas melhores.

Sugestões para ferramentas melhores:

1. Fornecer LLMs para profissionais técnicos, não para stakeholders de negócio.
2. Permitir que usem livremente os dados com ferramentas com as quais se sintam confortáveis, como Python, R etc.
3. Permitir que profissionais técnicos compartilhem facilmente o que produzem. Notebooks e aplicações internas de dados são difíceis de compartilhar porque precisam lidar com contêineres, dependências e infraestrutura.

[GN⁺]

Comentários do Hacker News

• Em uma empresa que criava dashboards com uma ferramenta de BI, os números estavam estranhos, então foram olhar o gerador de consultas e não dava para saber de jeito nenhum se parte da query era um inner join ou um left join
  O analista de negócios que criou aquele dashboard também não sabia; na prática, a intenção era usar inner join, mas foi executado um left join, e os dados exibidos saíram uma ordem de grandeza maiores do que o real
  Desde então, deixei de confiar nesse tipo de camada de abstração em cima de SQL voltada a pessoas que não conhecem SQL

  • Como alguém que lidera equipes de engenharia de dados/ciência de dados há mais de 15 anos, é exatamente esse o ponto central
    Há muita gente que consegue acessar os dados, mas não entende os próprios dados, suas relações nem o que significam os resultados que produziu
    Nos últimos 25 anos, engenheiros e cientistas distribuídos/embutidos, dashboards self-service, ferramentas low-code de BI/dados e, agora, texto→SQL/visualização com base em LLM surgiram como se fossem soluções, mas no fim não resolveram a falta de compreensão dos dados nem o problema de confiança nos resultados
    Só que SQL também não é a solução. Há muita gente que conhece SQL o suficiente para extrair dados, mas poucas pessoas conhecem a estrutura dos dados, o schema e a forma correta de usá-los
    Ainda não existe uma ferramenta que resolva esse problema além da experiência; talvez LLMs consigam um dia, mas, sinceramente, isso parece pouco provável
    Dashboards são bons para ver rapidamente KPIs e investigar mais a fundo, mas, no fim, o importante são as práticas de gestão de dados e a capacidade de entender corretamente dados/relações/métricas e conectá-los a insights de negócio
    O futuro é promissor, mas até agora as ferramentas de próxima geração nunca cumpriram o que prometeram, então passei a nunca confiar nelas com facilidade
  • Já vi isso se repetir em ferramentas low-code
    Defaults razoáveis e mecanismos para dar um tiro no próprio pé são apenas uma diferença de perspectiva
  • Fico imaginando se, depois da correção, todo mundo não ficou em polvorosa porque os números caíram
    Já vi casos em empresas grandes em que, quando um bug sutil ou uma decisão de design faz a receita parecer maior, ninguém quer mexer nisso e assumir a responsabilidade pela queda da receita
    Por exemplo, um botão do plano gratuito ficar abaixo da dobra em uma resolução média, o cálculo de estado estar errado e impedir a aplicação de um desconto, ou alguém ter omitido um false e, mesmo o cadastro tecnicamente não sendo necessário, o sistema exigir cadastro
    Fico curioso se sentiram algo parecido, com medo de serem culpados pela queda dos números
  • Esse é um problema comum a todas as soluções no-code
    A parte difícil de implementar fluxos lógicos complexos não é digitar código em uma IDE, mas a capacidade de modelar o problema e projetar algoritmos eficazes
    Essas ferramentas miram usuários não técnicos com a promessa de que não precisam escrever código, mas os usuários ainda não entendem a parte complexa de projetar a solução de forma engenheirada, então se perdem ou produzem resultados errados
    Tentativas de expandir processos de negócio complexos com ferramentas no-code acabam batendo em uma parede depois de muito tentativa e erro e, no fim, são entregues a engenheiros de verdade
    Só que o engenheiro precisa trabalhar sem o suporte que seria natural ao escrever código em uma linguagem de programação de verdade
    Quando se fica preso a um construtor visual de fluxos, repositórios compartilhados, controle de versão adequado, revisão de código, testes automatizados e CI/CD se tornam praticamente impossíveis
  • É só fazer como em outros lugares. Sintetize relações abstratas como views e limite os dashboards de BI self-service a views que façam sentido semântico
    Usuários basicamente enxergam apenas a partir do próprio ponto de vista, então é preciso oferecer alternativas que também permitam ver do jeito que eles pensam
    Conheço um produto que trata presença educacional com base em horários, porque cada escola, campus e data tem combinações diferentes de grade, e precisa ser flexível para eventos esportivos, substituições de turno, atividades com turmas combinadas e grades em ciclos de 14 dias
    Isso não significa que não se possa criar uma view que sintetize essa grade complexa em presença por aula ou presença manhã/tarde

• A suposição de que usuários de negócio não conseguem aprender, ou são apressados demais para aprender, a relação entre suas perguntas, o modelo de dados e os menus suspensos é absurda
  Pelo contrário, pela minha experiência, eles tentam aprender, mas muitas vezes quem modela os dados não entende o domínio o suficiente para capturar as nuances da pergunta
  Como resultado, em nome de simplificar o self-service, escondem nuances e aumentam o tempo para chegar à resposta, ou as removem totalmente e produzem respostas imprecisas e enganosas
  Também não gosto do eufemismo não técnico. Há bastante meio-termo entre LLMs, ferramentas geradoras de queries de BI e SQL; não há necessidade de declarar que a barreira de competência é absoluta

  • Isso também tem a ver com o conselho que sempre dou a jovens interessados em programação
    É bom se tornar especialista em computadores, programação e análise de dados, mas, se possível, digo para colocar no centro o domínio em que estudam ou trabalham e desenvolver essas habilidades como algo secundário
    A solução para o problema em que especialistas de domínio não conhecem dados e especialistas de dados não conhecem o domínio é que os dois sejam a mesma pessoa
  • Os melhores resultados de negócio/dados na minha carreira surgiram quando havia um PM que sabia SQL, ferramentas simples de extração e agendamento, e um modelo de dados razoável, mantido pela equipe de engenharia de dados com contribuições de desenvolvedores de BI ou do design de tabelas

• Agora parece que a incompetência organizacional atingiu um novo patamar
  Havia uma tirinha do Dilbert criticando planilhas, e ela se aplica diretamente a ferramentas de BI e ferramentas de IA
  Era algo como: “É claro que a planilha desta apresentação está cheia de erros e informações incorretas. Mas isso não importa, porque ninguém vai olhar para ela de novo, a menos que reforce uma decisão que a diretoria já tomou”
  Na vida real também há relatórios e dashboards quebrados por toda parte
  Às vezes eles não são atualizados por meses, ou até anos, e mesmo assim são usados em processos, decisões e fluxos de trabalho sem que ninguém perceba
  Há casos em que os dados não são atualizados, mas são pivotados por data/hora, então a cada execução os mesmos dados são rearranjados, e por isso fica difícil notar que está tudo muito quebrado
  Também há muitos casos em que fórmulas e “matemática” de todo tipo estão completamente erradas e produzem números imaginários

  • A expressão incompetência organizacional é inadequada. As pessoas não são incompetentes
    O problema dos dados ficou exponencialmente mais difícil à medida que o mundo se afastou dos sistemas EDW e ERP centralizados, e o nível de investimento simplesmente não acompanhou isso

• Ao longo dos últimos 24 anos, venho fornecendo dados a usuários de negócios, mas, seja com ferramenta de consulta, MS Access, Power BI ou cubos de dados no Excel, só uma minoria realmente usa
  Provavelmente são as mesmas pessoas que, 40 anos atrás, também teriam extraído dados de terminais e relatórios impressos para analisá-los
  Ainda assim, executivos gostam de dashboards de indicadores-chave, e novas ferramentas de BI tornam muito mais fácil criar e manter dashboards de KPI

  • É bom descobrir, dentro da empresa, pessoas que não sabem o quanto são boas em programar
    O cargo pode ser algo como “assistente pessoal”, mas elas mexem em formulários do SharePoint, Access e Excel como hackers e produzem coisas incríveis
    Reconhecer essa capacidade inteligente e dar ferramentas mais poderosas a elas é excelente. Às vezes elas acabam indo para empregos melhores, e isso também é ótimo
  • Nos primórdios da computação, a maior parte do trabalho era feita em mainframes grandes e compartilhados
    Computadores eram tão caros que o “departamento de computação” era uma área separada dentro da empresa; por exemplo, se a divisão Oeste precisasse de recursos de computação, contratava o departamento de computação que tinha um mainframe instalado no local
    Nosso grupo era uma pequena e ágil equipe interna de análise que usava os novos e “baratos” minicomputadores
    A vantagem era que, graças à estrutura de financiamento, conseguíamos responder muito mais rapidamente às necessidades dos usuários
    Um dia, andando pela fábrica, vi um usuário recortando linhas de um relatório de listras verdes que tínhamos gerado, colando-as em outra folha e tirando cópias
    Ele estava ordenando o relatório por outro critério; quando eu disse “podemos fazer isso para você!”, a reação foi “Sério?”
    Quem precisa concluir o trabalho dá um jeito de concluir. O objetivo de um grupo de sistemas de computação que atende clientes internos é tornar esse processo o mais eficiente possível
    Outra pessoa usava um PC, um digitalizador em tablet e AutoCAD para registrar pontos em uma aeronave e criar perfis de radar
    Não era bem o uso original de CAD, mas sim um uso criativo para capturar dados a partir dos desenhos do Jane's Combat Aircraft
  • Quando assumo trabalhos para criar software de integração de sistemas, muitas vezes os clientes ficam muito surpresos só de eu configurar ou expor dashboards já existentes
    Eles não acreditam que aqueles dados já estavam lá desde o início
    Integração é uma operação de negócio necessária, mas dados fáceis de entender são algo de que os stakeholders realmente gostam. É uma adição de valor muito fácil

• A interface tradicional de BI mencionada no texto é o Metabase, que atualmente é uma das melhores interfaces para BI
  O Metabase permite ver o SQL gerado pela GUI e também converter aquela pergunta para SQL puro, o que é bom para passar do autosserviço para a governança
  Fica fácil corrigir e validar a lógica, e pessoas com menor proficiência técnica ganham um caminho para desenvolver suas habilidades
  Dito isso, o ponto central do texto está correto. Mesmo do ponto de vista de quem trabalha profissionalmente com dados, ferramentas de BI raramente dão a mais pessoas a compreensão precisa dos dados ou as habilidades necessárias para usá-los corretamente
  Quando os dados são bem gerenciados, a ferramenta fica fácil e as pessoas conseguem descobrir; mas o mundo é complexo, então os dados também ficam complexos
  O custo de gestão de dados é muito visível, enquanto os benefícios não são tão visíveis

• Cheguei a uma conclusão parecida sobre “BI de autosserviço”, mas a solução é um pouco diferente
  Acho melhor elevar a camada de abstração e criar dashboards altamente customizáveis, mas sem expor SQL aos usuários de negócio
  Por exemplo, um dashboard com 20 filtros, dimensões de detalhamento e 20 parâmetros que controlam as “premissas usadas”
  A pergunta “quero ver o desempenho dos anúncios do Google no mês passado por faixa etária” vira a tarefa de alterar 3 ou 4 dropdowns predefinidos
  Os parâmetros são importantes aqui, porque só expõem controles validados e não permitem SQL arbitrário
  Claro que dashboards assim são difíceis de criar e exigem bastante especialização em visualização, como Looker, Tableau e Excel, mas, no fim, 70% das perguntas viram autosserviço
  É melhor desistir dos outros 30%, e é preciso ter alguém que traduza perguntas de negócio em perguntas de dados. Isso é um problema de pessoas

  • Basta identificar as perguntas frequentes e criar dashboards adequados para elas
    Assim, quando o CFO ou qualquer outra pessoa precisar de uma resposta para um período específico, é só abrir aquele dashboard e ajustar um pouco os parâmetros padrão

• Uso o Metabase mostrado na imagem e, em geral, usuários não técnicos realmente o utilizam
  O que ajudou na adoção foi realizar “horários de atendimento” e mostrar exemplos diretamente, como “como obter as vendas de uma loja ou de um estado específico”
  Isso não resolveu todos os problemas, consultas e exportações, mas uma parte considerável das solicitações que antes chegavam à engenharia agora nem chega a esse estágio
  Outro motivo pelo qual o Metabase é bom é que ele pode ser auto-hospedado e usar SSO do GSuite

  • Pela minha experiência, o problema não é o meio de consultar os dados, mas o contexto peculiar dos próprios dados
    A métrica principal não é “os pedidos de ajuda diminuíram, então os usuários estão mais independentes”
    Isso porque é muito provável que esses usuários estejam extraindo e interpretando métricas completamente erradas
    Já vi repetidas vezes usuários pouco técnicos acessarem dados, acreditarem que “não é tão difícil quanto eu pensava” e construírem uma pirâmide de análises ruins
    Análise correta sempre exige contexto
    Por exemplo, a receita recorrente não deve usar a data de envio para calcular a receita mensal, porque a equipe financeira preenche novamente as datas de envio
    O preço de catálogo é armazenado em USD, mas, na prática, a taxa de câmbio é ajustada mensalmente com base na tabela monthly_discount
    Por causa da convenção de marcar estoque não vendido do ano anterior, itens com data de compra null devem ser excluídos do relatório de receita
    Como os preços estão em moeda local, não se deve somar a receita sem fazer join com a tabela de câmbio
  • Metabase é bom
    Configurei para os não programadores da empresa e, sinceramente, eles quase não usam além de visualizar os dashboards que criei, mas a reação foi positiva
    É uma ferramenta realmente útil

• Sempre acho engraçado altos executivos ganharem muito dinheiro e, ainda assim, não conseguirem rodar consultas SQL de BI
  SQL foi criado justamente para facilitar que gestores consultassem dados
  Como ex-vendedor/gestor, não tenho muita simpatia por esse tipo de pessoa

  • Conheço um CEO que “sabe” SQL e é melhor nisso do que a maioria das pessoas na empresa que dizem saber SQL
    Mas ele não faz isso pessoalmente. Porque entende princípios econômicos básicos
    Mesmo que ele consiga fazer em meio dia algo que outra pessoa levaria 3 dias para fazer, esse meio dia é tempo em que ele deixa de fazer coisas que só o CEO pode fazer
    Um CxO competente também sabe que a parte que realmente consome tempo está em acertar perfeitamente os detalhes
    Mesmo que SQL seja de “alto nível”, peculiaridades no tratamento de nulls, tratamento de datas e merges que não batem exigem tempo e concentração para obter uma resposta confiável
    Se há alguém especializado nisso, o certo é deixar essa pessoa fazer

• Acho que dashboards de BI podem funcionar bem para consultas muito simples
  Se você chegou ao ponto de pedir a usuários não técnicos que executem joins de dados, já foi fundo demais; nesse caso, é melhor simplesmente usar SQL
  Joins podem parecer básicos para algumas pessoas, mas pessoalmente às vezes também os acho difíceis de entender, e em uma UI de dashboard menos expressiva que SQL eles viram uma combinação propensa à confusão
  No fim, é uma concessão. Dá para tornar isso mais acessível a usuários não técnicos do que SQL, mas inevitavelmente fica menos poderoso que SQL
  Ainda assim, há muita utilidade nesse espaço intermediário. Na prática, boa parte de “BI” é algo no nível de “temos algumas colunas de dados; por favor, plote uma em relação à outra”
  O autor diz que SQL é a única ferramenta de BI “self-service”, mas, sinceramente, acho que essa ferramenta é o Excel
  Muitas ferramentas de BI estão mais para recriar o Excel com uma interface nova e, por isso, menos familiar
  Acho que o meme de odiar Excel surgiu do passado de tentar fazer coisas complexas no Excel
  Se a manipulação complexa de dados for feita em SQL e “mostre isso como gráfico de pizza” for feito no Excel, talvez ferramentas de BI realmente não sejam necessárias

  • Eu ia dizer quase a mesma coisa sobre a relação entre SQL e Excel
    Se as fontes de dados subjacentes estiverem bem limpas, transformadas e com controle de acesso adequado, dá para ir surpreendentemente longe só com VLOOKUP e tabelas dinâmicas
    Quando há mais de uma fonte de dados, dar a usuários não técnicos uma oportunidade de self-service sempre acaba levando a uma mistura offline de dados
    Aí vem a pergunta: “Equipe de dados, por que os dados de ‘vocês’ não batem com os ‘meus’ dados?”, sempre partindo da premissa de que o lado deles está certo

• O problema central é que as ferramentas modernas são diferentes de desktops clássicos como workstations Smalltalk ou Emacs
  Esses ambientes eram totalmente integrados, tudo estava nas mãos do usuário e o conceito de programação pelo usuário final era embutido
  No org-mode, é possível criar slides bonitos num instante, escrever e executar rapidamente trechos de código e obter resultados
  Mas, do ponto de vista de dashboards, as limitações são grandes. Dá para plotar dados rapidamente, mas o resultado fica mais próximo de uma imagem estática e bruta; fazer algo bonito com PGF/TikZ leva tempo demais para ser uma opção viável e continua sendo estático
  O próprio Emacs é a ferramenta certa, mas é uma ferramenta de uma era mais antiga
  Ferramentas modernas oferecem interações mais vistosas e rápidas, mas só permitem ações muito limitadas, ficam presas em UIs inflexíveis e também não são integradas a outras coisas
  R, junto com RStudio/quarto, talvez seja a forma mais rápida de produzir conteúdo bonito, rápido e sujo, mas fica muito aquém da flexibilidade do Emacs
  No fim, não parece haver solução a menos que se reescreva toda a stack de software moderna com base no paradigma clássico e na capacidade do hardware moderno