Discovery do Dashboard de Filiais

A Motz opera o elo entre motoristas e cargas de transporte para grandes indústrias, e neste projeto o cliente era a Votorantim Cimentos. Em cada filial, um agenciador é responsável por conectar a demanda de cargas que chega da Votorantim com a oferta de caminhões disponíveis, hoje majoritariamente por planilha, WhatsApp, telefone e memória. O pedido inicial que chegou até mim foi direto: construir um painel com indicadores para as filiais. Se eu tivesse aceitado esse enunciado como o problema, provavelmente teria entregue um dashboard bem desenhado que ninguém usaria.

O trabalho real deste case foi o processo de descoberta que transformou um pedido de "fazer um painel" em uma definição precisa do problema a resolver, e como essa definição guiou cada decisão de escopo daí em diante. Este case documenta esse caminho: da provocação inicial ao problem framing, do framing às hipóteses de solução, das hipóteses à priorização com o negócio, e da priorização ao desenho da primeira versão do produto.

A operação de fretes entre a Votorantim e a Motz funciona hoje assim: a Votorantim envia semanalmente uma programação de cargas, com cotas, volumes e rotas, para cada filial. Analistas internos dividem essas cotas entre transportadoras, priorizando transportadores cativos (motoristas fixos da filial) e recorrendo ao mercado aberto quando a demanda não é atendida por eles.

Esse desenho já sinalizava o problema antes de qualquer entrevista. O dado nasce em um sistema, passa por planilhas manuais, alimenta um app e um totem, e volta a ser consolidado manualmente para virar relatório. Cada uma dessas transições é um ponto de perda, atraso ou divergência de informação.

Primeiro, o sintoma

O sintoma relatado por praticamente todas as filiais era parecido: falta de visibilidade. Mas o padrão que emergiu ao cruzar as entrevistas era outro: uma inconsistência radical na forma como a informação chegava a cada agenciador, dependendo inteiramente de fatores fora do controle do processo.

Os principais impactos diagnosticados pelos entrevistados:

• Aumento do tempo de espera dos motoristas.
• Redução do giro da frota.
• Maior índice de recusas por parte dos parceiros.
• Menor capacidade de faturamento diário.
• Perda de oportunidades de encaixe e redistribuição de cargas em tempo real.

Em pelo menos um caso mapeado, a qualidade da informação dependia diretamente da relação pessoal entre o agenciador da filial e o analista da Votorantim responsável por aquela conta, a ponto de um agenciador ter, por proximidade histórica, acesso a credenciais de sistema de um interlocutor do cliente. Se essa pessoa deixasse a função, o fluxo de informação se rompia junto com ela. Em outro caso, um analista regional, ao ser questionado sobre a origem dos dados que alimentavam sua própria planilha consolidada, não soube explicar de onde vinham, apenas que "um analista atualiza para mim".

A partir daí, o problema pôde ser declarado de forma mais precisa :)

A causa raiz não era a ausência de um painel, e sim a ausência de uma fonte de informação padronizada e sistêmica, hoje substituída, filial a filial, por relacionamento pessoal e por planilhas paralelas sem rastreabilidade de origem.

"Se todas as filiais recebessem o mesmo acesso à informação, o problema desapareceria?"

Com a causa raiz definida, mapeei as dores relatadas cruzando duas dimensões: o impacto na gestão (a visão da liderança) e o impacto no agenciamento (o dia a dia de quem fecha a carga).

Levei as duas hipóteses para uma sessão de alinhamento com o Head de Operações e o Product Manager. O objetivo não era escolher A ou B de forma binária, e sim usar a tensão entre elas para chegar a uma lista de itens indispensáveis para a primeira versão, testando cada candidato contra uma pergunta simples: isso resolve o problema de oferta e demanda de forma sistêmica, ou reintroduz dependência de planilha e relacionamento?

Esse exercício de priorização foi orientado por um princípio que virou critério de corte para todo o roadmap: não construir nada que dependa de disciplina manual de preenchimento como pré-condição para funcionar, porque isso reproduz exatamente a falha estrutural identificada no problem framing.

Combinação de fatores

A decisão final de escopo combinou o que havia de mais valioso nas duas hipóteses. A V1 herdou da Hipótese A o compromisso de consultar a fonte de dados de forma sistêmica, sem depender de planilha alheia, e herdou da Hipótese B a disciplina de não tentar absorver todo o processo de agenciamento de uma vez, mantendo o escopo restrito ao essencial de oferta, demanda e previsibilidade.

O Painel de Filiais resultante organiza a tela em três camadas de decisão para o agenciador:

• Uma visão de oferta mostra quantos motoristas estão com carga aceita, quantos estão sem carga atrelada e portanto ociosos, e o status em tempo real da frota (disponível, em viagem, carregando, offline).
• Uma visão de demanda e gargalos mostra o volume carregado contra o pendente, cargas ofertadas sem aceite com seu aging, e o tempo operacional por etapa (espera, carregamento, trânsito, descarga), para expor onde o processo está de fato travando.
• E uma visão operacional detalhada traz uma tabela de ordens de carregamento com status, crédito, valor do frete, aging, cliente, itinerário e o motivo de eventual erro, como falta de motorista, erro de roteirização, stockout ou bloqueio, permitindo que o agenciador aja sobre exceções específicas em vez de apenas observar médias.

Resultados

Amostragem

O piloto rodou primeiro nas duas filiais escolhidas para representar os extremos de maturidade, e depois foi estendido para o restante da rede em ondas. Antes de listar o que melhorou, vale registrar algo que ouvi de um agenciador durante a devolutiva do piloto, porque isso mudou como eu li os próprios resultados:

"...sem dúvida, essa dependência da expedição gera perdas de produtividade e de oportunidade. Porém, quando nós que estamos nessa ponta não temos autonomia para interagir na oferta das cargas e agir rapidamente diante dos gargalos operacionais, acabamos dando um passo para trás em termos de eficiência. A tecnologia existe, mas a operação perde agilidade por depender de etapas que não conseguimos influenciar diretamente."

Segundo, e mais relevante para o projeto, ela expõe um limite do que a V1 do painel resolveu: dar visibilidade não é o mesmo que dar autonomia. O agenciador identifica o gargalo rápido, mas continua sem poder de ação direta sobre a oferta e a redistribuição de cargas, porque essa decisão passa pela expedição, uma etapa que ele não controla.

Com isso em mente, o que de fato mudou:

• A visibilidade sobre ociosidade da frota melhorou, mas o poder de agir sobre ela ainda é parcial. O indicador de motoristas sem carga atrelada, que partia de uma média de 43 veículos por filial (cerca de 67 placas e 1.240 toneladas de capacidade parada), passou a ser acompanhado em tempo real pelo próprio agenciador, e não só pela gestão no relatório do dia seguinte. Isso reduziu o tempo entre identificar a ociosidade e sinalizar o problema para quem podia agir. Nas filiais piloto, o número caiu para uma faixa entre 30 e 35 veículos, uma melhora real, porém mais modesta do que se o agenciador pudesse recolocar a carga sozinho no momento em que via o motorista parado.
• O tempo de espera do motorista segue sendo o ponto mais sensível. Esse foi justamente um dos impactos citados pelo agenciador, e os dados confirmaram a percepção: mesmo enxergando o gargalo na hora (espera, carregamento, trânsito ou descarga), a filial só consegue reduzir a espera quando a redistribuição da carga é aprovada por quem está fora da ponta operacional. O ganho do painel aqui foi de antecipação, não de resolução: o agenciador passou a sinalizar o problema minutos depois de ele aparecer, em vez de horas depois, mas o tempo de resposta da cadeia ainda depende de terceiros.
• OTIF teve melhora consistente, mas ainda distante do potencial citado pelo agenciador. O volume carregado contra o pendente, que rodava em torno de 87% contra uma meta de 90%, passou a oscilar entre 89% e 91% nas semanas de operação mais estável. É uma melhora real, mas o próprio time de agenciamento avalia que o ganho seria bem maior se pudessem agir diretamente na redistribuição da carga no momento em que percebem o risco, e não apenas relatar o risco para outra área decidir.
• O aging das cargas ofertadas sem aceite caiu, dentro de uma faixa mais variável do que eu esperava inicialmente. Antes do painel, uma carga ofertada e sem aceite ficava em média 2,4 dias parada até alguém perceber e agir. Com o motivo do travamento exposto na tabela operacional (falta de motorista, erro de roteirização, stockout, bloqueio de crédito), esse tempo caiu, mas de forma desigual: em dias de volume baixo e frota disponível, a resposta ficou próxima de algumas horas; em dias de pico, com pouca disponibilidade de frota, o ganho foi bem menor, exatamente como o agenciador descreveu ao dizer que o impacto varia com o volume do dia.
• Índice de recusa dos motoristas parceiros e giro de frota seguem como indicadores de atenção. Esses dois pontos, citados diretamente pelo agenciador como consequência da falta de autonomia na ponta, ainda não mostraram uma melhora clara atribuível ao painel isoladamente. A leitura do time é que recusa e giro de frota dependem mais da velocidade de resposta a um gargalo do que da visibilidade sobre ele existir, o que reforça que esses indicadores vão responder melhor quando o agenciador tiver poder de atuação direta na oferta, não apenas informação sobre ela.
• Onboarding de agenciadores ficou mais rápido, esse foi um dos ganhos mais claros e menos disputáveis. Antes, um agenciador novo levava semanas para aprender a montar sua própria versão da planilha de controle, geralmente copiando o modelo de outra pessoa. Com o painel padronizado entre filiais, o tempo para operar com autonomia caiu de cerca de três a quatro semanas para menos de duas, porque a lógica de leitura é a mesma em qualquer unidade.

Aprendizados

O maior risco deste projeto nunca foi de execução, foi aceitar o enunciado do problema como ele chegou. A empresa já tinha dezenas de painéis subutilizados; construir mais um dashboard bem desenhado não teria mudado o resultado de negócio. O que mudou a trajetória do projeto foi ir a campo antes de desenhar qualquer tela, cruzar entrevistas de filiais com realidades muito diferentes entre si, e insistir em nomear a causa raiz, uma inconsistência sistêmica de informação mascarada por relacionamento pessoal, mesmo quando isso significava propor duas hipóteses de solução deliberadamente conflitantes só para forçar uma decisão explícita de escopo, em vez de deixar o caminho mais fácil vencer por omissão.

Fica um critério que pretendo levar para os próximos projetos: toda funcionalidade candidata precisa ser testada contra a pergunta "isso resolve a causa raiz, ou só maquia o sintoma?", com a disciplina de cortar do escopo tudo que passar apenas no segundo teste.