O projeto durou oito meses, o dashboard foi entregue, rodava, atualizava todo dia. A equipe de TI construiu o que achava que o negócio precisava ver. O gestor abria, não encontrava o que precisava, fechava, e ia pedir o relatório no Excel para o analista.

O projeto estava concluído, e, o problema estava começando.

Um painel que não tira o gestor do Excel falhou na pergunta, não na ferramenta. E esse tipo de falha é sistêmica: em diagnósticos realizados em empresas de médio e grande porte, mais de 60% dos dashboards entregues estão sendo subutilizados.

O motivo é simples e incômodo: a maioria das empresas mede a entrega de dados, mas, ninguém mede o uso. O projeto tem uma data de go-live, uma aprovação técnica e uma nota fiscal. Porém, não tem um indicador de adoção, e não tem uma data de revisão pós-entrega, assim, o sintoma fica invisível porque ninguém foi encarregado de vê-lo.

O investimento em BI cresceu de forma consistente na última década. Empresas adquiriram licenças, contrataram analistas e construíram pipelines de dados. A promessa era uma tomada de decisão mais rápida e mais embasada. O resultado, em muitos casos, acabou sendo uma camada de dashboards paralela à rotina real de decisão.

O problema tem uma causa estrutural: projetos de dados são gerenciados como projetos de TI. O sucesso é medido pela entrega técnica, o sistema sobe, os dados atualizam, o relatório está tecnicamente correto. Só que ninguém pergunta se o gestor abriu o dashboard essa semana sem que alguém pedisse para ele abrir.

Essa lacuna entre entrega e uso não aparece nos relatórios de projeto simplesmente porque não existe um campo para ela. O indicador de sucesso costuma ser binário: entregue ou não entregue. Uso real, frequência de acesso espontâneo, perguntas que o usuário foi buscar e não encontrou... esses dados até existem nos logs das ferramentas de BI, mas quase nunca são analisados.

O efeito composto disso tudo é silencioso: cada projeto entregue e não usado justifica o próximo pedido de relatório em Excel. O analista fica sobrecarregado, e o time de TI entrega mais dashboards para tentar resolver o problema dos dashboards anteriores. E o ciclo se repete, puramente porque ninguém mediu a causa raiz.

O Teste da Segunda-feira é uma auditoria de adoção que qualquer gestor pode aplicar a qualquer dashboard em menos de uma hora.

A lógica parte de uma pergunta bem concreta: na última segunda-feira de manhã, sem que ninguém pedisse, quem abriu esse dashboard? Se a resposta for "ninguém", ou se você simplesmente não sabe, você tem um problema de adoção que nenhuma atualização técnica vai conseguir resolver.

O Teste da Segunda-feira tem três verificações principais:

A primeira: quem acessou sem ser convocado? O uso espontâneo é o único indicador honesto de que o dashboard respondeu a uma pergunta que o usuário já tinha. O acesso por convocação (como abrir o painel só para a reunião) não conta. Nos logs de acesso das ferramentas de BI, essa diferença é perfeitamente rastreável.

A segunda: o que o usuário foi buscar e não encontrou? Toda ferramenta de BI registra o comportamento de navegação. Filtros aplicados e descartados, abas abertas e fechadas rapidamente, sessões curtas em painéis longos... tudo isso são rastros de perguntas sem resposta. Quando o usuário não encontra o que precisa, ele simplesmente fecha tudo e vai para o Excel. O log registra isso muito antes de qualquer reunião de feedback.

A terceira: para onde o usuário foi depois? Se o destino for uma planilha ou um pedido direto ao analista, o dashboard falhou na pergunta, e não na ferramenta em si. Já se o destino for uma decisão tomada, o projeto funcionou.

Aplicar o Teste da Segunda-feira uma vez por trimestre, em cada dashboard ativo, custa menos do que o próximo pedido de um novo painel. E, de quebra, revela onde o investimento em dados está produzindo decisões de verdade e onde está produzindo apenas uma entrega bem documentada.

Em 2013, a Target iniciou sua expansão para o Canadá com um sistema integrado de gestão de estoque. Os dados de fornecedores foram migrados com erros sistemáticos: dimensões incorretas, unidades trocadas, SKUs duplicados. Os relatórios mostravam estoque disponível que não existia nas prateleiras.

Os gestores das lojas perceberam rapidamente que os painéis não refletiam a realidade. Pararam de consultá-los e voltaram ao controle manual. O resultado foi simultâneo: prateleiras vazias em produtos de alta demanda e excesso de estoque em itens errados.

Em janeiro de 2015, o Target Canada pediu recuperação judicial. Foram 133 lojas fechadas em menos de dois anos de operação. O sistema estava entregue. Os gestores tinham parado de usá-lo meses antes.

Fonte: Harvard Business School Case "Target Canada's Collapse", 2016.

Escolha o dashboard mais importante que sua área entregou nos últimos doze meses e aplique a primeira verificação do Teste da Segunda-feira: sem que ninguém pedisse, quem o abriu na última semana?