Dashboard de indicadores: por que o número precisa nascer num sistema, e não na planilha

Quase toda empresa que me procura para "fazer um dashboard" já tem um. Ele mora numa planilha, alguém passa a manhã de segunda consolidando, e na reunião metade do tempo é gasto discutindo se o número está certo. A outra metade discute o número. Quase nunca sobra tempo para a pergunta que interessa: o que a gente faz de diferente essa semana?

O problema raramente é o gráfico. É o que está embaixo dele. Este guia é sobre essa camada de baixo, que ninguém vê e que decide se o painel serve para alguma coisa. Os exemplos são de pedidos, mas a lógica é a mesma para qualquer processo com etapas: vendas, atendimento, produção, compras, seleção de pessoas.

Comece pela decisão, não pelo gráfico

Um dashboard útil nasce de trás para frente:

1. Qual decisão alguém precisa tomar? "Preciso de mais gente na produção ou o atraso está em outro lugar?"
2. Qual número responde a isso? Quanto tempo cada pedido fica em cada etapa.
3. De onde esse número sai? Da data em que o pedido entrou e saiu de cada etapa.
4. Esse dado existe hoje? Na maioria das empresas, não. E é aqui que o projeto de verdade começa.

Quem começa pelo gráfico termina com quarenta indicadores bonitos que ninguém usa. Quem começa pela decisão descobre rápido que o gargalo não é a ferramenta de visualização, é o registro.

O número nasce no processo, não no painel

Olhe como a maioria dos controles guarda um pedido:

pedido | cliente  | etapa      | atualizado em
1042   | Padaria  | produção   | 14/10
1043   | Mercado  | aprovação  | 09/10

Isso é o status atual. Toda vez que o pedido muda de etapa, alguém sobrescreve a célula. A informação de quando ele entrou em aprovação, quanto tempo ficou lá e quem aprovou desaparece na hora.

Agora o mesmo pedido guardado como histórico de eventos, uma linha por mudança:

pedido | etapa      | entrou em   | por
1042   | orçamento  | 01/10 09:12 | Ana
1042   | aprovação  | 02/10 16:40 | Ana
1042   | produção   | 09/10 10:05 | cliente
1042   | entrega    | 14/10 08:30 | Carlos

Parece só uma tabela maior. Mas dela saem quase todos os indicadores que importam numa operação, e da primeira não sai nenhum deles:

• Tempo em cada etapa. O pedido 1042 ficou 7 dias esperando aprovação do cliente e 5 em produção.
• Conversão entre etapas. De cada 100 orçamentos, quantos chegam a aprovação, quantos a produção.
• Envelhecimento do que está aberto. Quais pedidos estão parados na mesma etapa há mais tempo que o normal, agora, antes de virar atraso.
• Retrabalho. Quantos pedidos voltaram de produção para orçamento, coisa que o status atual simplesmente esconde.
• Quem e quando. Em qual mão o processo para, sem precisar perguntar a ninguém.

Para quem quer ver como isso vira consulta, o tempo por etapa sai de uma linha só num banco de dados (aqui em MySQL 8):

SELECT pedido, etapa,
       DATEDIFF(LEAD(entrou_em) OVER (PARTITION BY pedido ORDER BY entrou_em),
                entrou_em) AS dias_na_etapa
FROM eventos;

E a conversão por etapa é uma contagem simples de quantos pedidos diferentes passaram por cada uma:

SELECT etapa, COUNT(DISTINCT pedido) AS pedidos
FROM eventos
GROUP BY etapa;

Não precisa entender o código. O ponto é: com o histórico, cada pergunta nova vira uma consulta de minutos. Sem ele, vira um mutirão de memória e de e-mail antigo, e o resultado é um palpite.

Por que a planilha não chega lá

Tecnicamente dá para manter um histórico numa planilha. Na prática ninguém consegue, por cinco motivos:

• Ela convida a sobrescrever. O gesto natural numa planilha é editar a célula. Registrar uma linha nova a cada mudança, com data e hora, depende da disciplina de todo mundo, todo dia. Um sistema faz isso sozinho quando alguém clica em "aprovar".
• A data é digitada depois. Quem atualiza a planilha no fim do dia, ou na sexta, coloca a data que lembra. O tempo por etapa vira ficção. No sistema, a data é a do clique.
• Existem várias verdades. A cópia do comercial, a da produção, a versão "final_v3" que alguém mandou por e-mail. O painel montado em cima disso mostra a verdade de quem consolidou por último.
• A fórmula erra calada. Uma linha a mais que ficou fora do intervalo, uma referência que escorregou. Não aparece erro nenhum; aparece um número errado com cara de certo. Aconteceu num dos estudos de economia mais citados da década passada, o de Reinhart e Rogoff, em que um intervalo de planilha deixou cinco países fora da média (Retraction Watch), e no modelo de risco do JPMorgan no caso "London Whale", uma cadeia de planilhas preenchida à mão em que uma fórmula dividia pela soma em vez da média (The Baseline Scenario, citando o relatório do próprio banco).
• Ninguém sabe quem mudou o quê. Sem permissão por pessoa e sem registro de alteração, um número que mudou na véspera da reunião não tem explicação.

Nada disso é culpa de quem usa a planilha. Ela é uma ferramenta excelente para pensar, simular e fazer conta. Ela só não foi feita para ser o registro oficial de um processo com várias pessoas mexendo. Escrevi sobre os sinais de que chegou a hora da troca em planilha ou sistema: quando vale a pena trocar.

Três armadilhas de leitura que o dado bem guardado resolve

Mesmo com o dado certo, um painel engana se for lido do jeito errado. Três armadilhas aparecem em quase todo projeto:

1. A média esconde o caso que importa

Sete pedidos entregues em 3, 4, 4, 5, 5, 6 e 29 dias. A média dá 8 dias. A mediana, o valor do meio, dá 5. Os dois números juntos contam a história: o normal é 5, e existe um caso fora da curva que puxou a média e merece ser investigado. Um painel que mostra só a média esconde justamente esse pedido. Com o histórico, dá para mostrar os dois e listar o caso estranho com um clique.

2. Quem ainda está no meio do caminho não é perda

Se você calcula a conversão do mês e conta como "não convertido" o orçamento enviado ontem, a taxa despenca no fim de todo mês e se recupera no começo do seguinte. Ninguém perdeu nada; o processo só não terminou. A forma correta é acompanhar cada grupo pela data de entrada (todos os orçamentos de setembro, por exemplo) e medir quando ele já teve tempo de andar. Isso exige saber quando cada item entrou, ou seja, o histórico.

3. Número pequeno balança muito

Uma etapa com 100% de conversão em 2 casos não vale o mesmo que uma com 90% em 500. Todo painel honesto mostra a quantidade ao lado da porcentagem. E o recorte que revela o problema (por unidade, por vendedor, por tipo de serviço) é justamente o que gera grupos pequenos. Mostrar o tamanho do grupo é o que impede alguém de tirar conclusão de dois casos.

O que muda na operação

Um exemplo para deixar concreto. Uma empresa entrega pedidos em 18 dias, em média, e quer chegar a 12. A primeira ideia é contratar mais gente na produção.

Com o tempo por etapa, o painel mostra outra coisa: dos 18 dias, 7 são o pedido parado esperando o cliente aprovar o orçamento. Isso é 39% do prazo inteiro numa etapa em que a produção nem encostou. Mais gente na produção não muda esse número. Um lembrete automático para o cliente no terceiro dia, ou um orçamento mais claro, talvez mude.

É esse o impacto de um painel bem alimentado:

• O gargalo aparece onde ele está, e não onde todo mundo acha que está.
• O alerta chega antes do atraso. O sistema avisa que o pedido está há 6 dias numa etapa que costuma levar 2, enquanto ainda dá para agir.
• A reunião muda de assunto. Ninguém discute mais se o número está certo, porque ele sai do mesmo lugar para todo mundo. O tempo vai para a causa e para a decisão.
• A segunda-feira de consolidação acaba. O painel se atualiza sozinho, porque o dado já nasce no lugar certo.

Por onde começar, sem gastar com ferramenta cara

O erro mais comum é começar comprando uma ferramenta de BI e ligar ela na planilha de sempre. O painel fica mais bonito e continua mostrando o mesmo dado incompleto. A ordem que funciona é a contrária:

1. Registrar. Colocar o processo num sistema, mesmo que simples, em que cada mudança de etapa é um clique e gera uma linha com data e responsável. É o passo que mais muda o resultado, e o que menos aparece.
2. Consultar. Com o histórico guardado, montar as poucas consultas que respondem às decisões do primeiro tópico: tempo por etapa, conversão, o que está envelhecendo.
3. Mostrar. Só então o painel. Pode ser uma tela dentro do próprio sistema ou uma ferramenta de BI ligada ao banco. Nessa altura a ferramenta é o detalhe.

E cada pessoa vê o que decide. Quem opera precisa da lista do que está parado hoje; quem coordena, do tempo e da conversão por etapa; quem dirige, do custo, do prazo e da tendência. É o mesmo dado, em três recortes.

Quanto isso custa depende do tamanho do processo, e eu explico o que move esse preço em quanto custa automatizar um processo. Na maior parte das empresas pequenas, o passo 1 é bem menor do que parece: poucas telas, uma tabela de eventos bem desenhada e o hábito de clicar em vez de digitar numa célula.

Quero um diagnóstico dos meus números

Os exemplos de pedidos e prazos deste guia são fictícios e servem para ilustrar o cálculo. Os casos de planilha foram conferidos nas fontes linkadas em 26 de outubro de 2026.