Na reunião trimestral, o painel está projetado e o diretor comercial aponta para a queda numa região, perguntando o que aconteceu.
Quem cuida do BI responde que aquele número não está certo, porque o sistema de vendas mudou em maio e ninguém ajustou a carga. A conversa segue por opinião, e o painel fica projetado no canto da tela, ignorado.
O problema é que essa cena descreve a maior parte das empresas que se dizem orientadas por dado. Têm painel, têm indicador, têm relatório automático — e a decisão continua saindo de quem fala mais alto.
Neste artigo, separamos os três níveis de maturidade que costumam ser confundidos, a condição que precede todos eles e os cenários em que decidir por dado não compensa.
Decidir por dado é quando alguém muda de ideia
A definição prática é essa, e é desconfortável: uma empresa decide por dado quando o dado muda uma decisão que já estava tomada.
Se o número confirma o que a diretoria já pensava, ele não decidiu nada: apenas acompanhou. O teste real acontece quando o dado contraria a expectativa. Nesse momento, ou ele muda a decisão, ou é questionado até sumir da conversa.
Todo o resto — quantidade de painéis, tamanho do armazém de dados, ferramenta escolhida — é meio, e só isso é fim. O termo em inglês, data-driven, virou sinônimo de ter relatório, e não é isso que ele quer dizer.
Relatar, monitorar e decidir
Relatar. O dado descreve o que aconteceu: faturamento do mês, pedidos por região, ticket médio. É o nível em que quase toda empresa está, e ele tem valor — sem uma descrição comum, cada área chega à reunião com um número diferente.
Monitorar. O dado avisa quando algo saiu do esperado. Não é olhar o painel toda segunda: é ser avisado na terça, quando a margem de um produto caiu abaixo do limite. Exige definir o que é normal, e é aí que a maioria para.
Decidir. O dado entra antes da escolha, não depois. Qual produto descontinuar, qual região recebe mais estoque, qual cliente merece condição diferente. Aqui ele precisa não só existir, mas chegar a tempo e resistir a questionamento.
Pular de relatar direto para decidir é a causa mais comum de frustração com projeto de dados. Sem o nível do meio, ninguém percebe que o número está errado antes de a decisão ser tomada com ele.
A condição que precede os três níveis
Decidir por dado exige confiar no dado. E confiança não se constrói com apresentação: se constrói não sendo desmentido.
Numa pesquisa da Monte Carlo com a Wakefield Research, feita em março de 2023 com 200 profissionais, 74% disseram que a área de negócio identifica os problemas no dado antes do time. O recorte é global, e nós já escrevemos sobre o mecanismo disso em por que o erro aparece primeiro na reunião.
O que interessa aqui é a consequência, e ela é organizacional. A partir da segunda vez que o número é desmentido na frente de todo mundo, aquele painel deixou de existir para quem assistiu.
A pessoa volta a decidir como decidia antes, e continua assim mesmo depois de o erro ser corrigido, porque confiança perdida não volta com aviso de correção.
Daí a ordem: primeiro o dado precisa ser confiável, depois ele pode decidir. Investir em painel antes de investir em confiabilidade é montar a vitrine antes do estoque.
Quando não compensa decidir por dado
A maior parte do conteúdo sobre o tema trata a decisão orientada por dado como sempre melhor. Não é, e há pelo menos quatro casos em que não é.
- Decisão barata e reversível. Se testar custa menos que medir, teste. Trocar o texto de um botão não precisa de análise prévia; precisa de reversão rápida.
- Amostra pequena demais. Decidir sobre um padrão observado em doze casos é decidir por acaso com aparência de rigor. O dado dá falsa segurança, que é pior que insegurança declarada.
- Custo de medir maior que o valor da decisão. Instrumentar o processo, montar a coleta e manter aquilo de pé custa. Se a decisão vale menos que isso, a resposta certa é decidir sem.
- Decisão que depende de valor, não de fato. Quanto de margem abrir mão para entrar num mercado novo é escolha de estratégia. O dado informa o custo; ele não escolhe por você.
Exemplo prático
Uma rede com quatro lojas quer decidir se muda o horário de abertura. Instrumentar fluxo de entrada por faixa de horário exige contador de pessoas, integração e alguém cuidando daquilo todo mês. A decisão vale um teste de seis semanas em duas lojas, comparado com as outras duas. Medir tudo custaria mais que o resultado da escolha.
Saber quando não usar é parte de usar bem.
Como isso aparece no resultado
Sem promessa de percentual, porque número de retorno nesse tema costuma vir de quem vende a solução. O que dá para afirmar são os mecanismos.
- O ciclo de decisão encurta. A discussão deixa de ser sobre qual número está certo e passa a ser sobre o que fazer. Em reunião recorrente, é a maior parte do tempo economizado.
- A discussão muda de eixo. Sai da hierarquia e entra na evidência. Quem tem o dado consegue contrapor quem tem o cargo.
- O erro fica mais barato. Monitorar significa descobrir o desvio em dias, não no fechamento do trimestre. A correção acontece enquanto ainda é correção.
- O trabalho analítico deixa de ser desperdiçado. Análise que ninguém usa porque ninguém confia no dado é custo puro. É o resultado mais direto e o menos citado.
Nenhum deles aparece no primeiro mês. Todos aparecem no primeiro trimestre.
Onde o Januss entra
O Januss não resolve cultura de decisão. Nenhuma ferramenta resolve — isso é assunto de gestão, de incentivo e de quem senta na cabeceira da mesa.
O que ele resolve é a camada abaixo: fazer com que o número não seja desmentido na reunião.
Testes declarados que param a execução. Campo obrigatório vazio, chave que deveria ser única e duplicou, valor fora da lista aceita, relacionamento quebrado entre tabelas. Cada teste pode só avisar ou interromper a carga, e interromper significa que o painel continua exibindo o número da véspera, correto, em vez do número novo, errado.
É uma escolha que parece pequena e não é. Painel desatualizado se explica em uma frase; painel errado custa a confiança de quem olhou.
Garantia declarada na carga incremental. A cada execução, a tabela de destino fica idêntica, linha a linha, ao que uma recarga completa produziria. E quando o motor não consegue garantir isso — uma transformação que agrega sobre junção, por exemplo —, ele recusa o incremental e explica o motivo, em vez de entregar um número aproximado que ninguém vai conferir.
Exclusão que chega ao destino. A leitura é do log de transações, não de consulta agendada. Registro apagado na origem some do destino também. Sem isso, o total do relatório fica maior que a realidade — e é o tipo de erro que só aparece quando alguém compara com o sistema.
Some-se o aviso por e-mail quando a carga falha, e o pipeline se desligando sozinho depois de três falhas seguidas, em vez de insistir em silêncio.
Nada disso torna uma empresa orientada por dado. Só remove o motivo mais comum para ela não conseguir ser.
Quer testar com uma base sua? São 14 dias de teste, sem cartão de crédito: criar seu ambiente.
Fontes
O dado citado no texto vem de uma fonte só, aberta na origem:
Crie seu workspace em minutos.
Aponte para a sua origem e veja o dado chegando ao banco no mesmo dia.