Quando medir o resultado de um projeto de inovação
Você mede depois que a operação estabiliza, não quando o sistema entra no ar. Projeto de inovação costuma piorar antes de melhorar: a equipe reaprende o trabalho enquanto o processo se reacomoda, e os números caem nesse intervalo. Medir dentro do vale produz um veredito sobre a transição, não sobre o projeto.
Por que o número piora logo depois do go-live?
Porque a rotina antiga parou de funcionar e a nova ainda não é automática. Nesse intervalo a operação paga dois custos ao mesmo tempo: o do processo que está sendo desmontado e o do processo que ainda não rende.
O nome disso na literatura econômica é curva J. A pesquisa do Census Bureau conduzida por Kristina McElheran, Mu-Jeung Yang, Zachary Kroff e Erik Brynjolfsson cruzou duas pesquisas censitárias de 2017 e 2021 e achou o padrão com evidência causal: queda primeiro, crescimento depois. A cobertura do MIT Sloan resume a leitura de McElheran de que a tecnologia não é plug-and-play e exige mudança sistêmica, o que gera atrito, principalmente em empresas estabelecidas.
O estudo é sobre IA industrial em fábricas. A mecânica não é: ela vale para troca de ERP, integração de sistemas e redesenho de fluxo, porque o que produz o vale é a equipe reaprendendo o trabalho, não a tecnologia específica que entrou.
O achado mais útil para quem gerencia inovação é outro. Nas empresas mais velhas, o que se deteriora no curto prazo é a gestão, não a máquina. Elas deixam de monitorar indicadores e metas de produção durante o ajuste, e esse recuo responde por cerca de um terço da perda de produtividade delas. A instrumentação afrouxa justamente no mês em que você mais precisa dela.
Qual é a janela de medição certa?
A janela abre quando a série estabiliza, não numa data de calendário. Antes disso você tem duas populações diferentes de eventos misturadas no mesmo período: os que passaram pela transição e os que já rodam no regime novo.
A média mensal soma as duas e devolve um número que não descreve nenhuma. Se a transição durou seis semanas e você mede o trimestre inteiro, metade da amostra é aprendizado. O projeto bom fica medíocre no relatório. O projeto ruim fica salvável, porque a culpa cabe no aprendizado.
O sinal de estabilidade está na dispersão, não na média. Enquanto a equipe ainda está aprendendo, o mesmo tipo de caso leva tempos muito diferentes para andar. Quando o desvio entre casos parecidos para de encolher mês a mês, o regime novo se formou e a média passa a significar alguma coisa.
Esse platô sozinho não diz se o projeto funcionou. Ele diz que dá para começar a medir. A resposta sobre o resultado vem do patamar em que a dispersão estacionou, comparado ao de antes do go-live.
Repare no descompasso entre essa exigência e o prazo que as empresas se dão. Na pesquisa da Deloitte, feita com 3.235 líderes de negócios e TI em 24 países, 115 deles no Brasil, 49% dos brasileiros esperam levar pelo menos 40% dos experimentos à operação em três a seis meses. É uma expectativa de escala colocada dentro do intervalo em que a curva ainda está descendo.
O que o seu sistema precisa registrar para separar as duas fases?
Registro por evento, com carimbo de tempo. Sem isso você não tem como dizer em que semana a curva virou, e sem essa data não existe janela de medição, só o fechamento do mês.
Na prática são três coisas, e nenhuma delas é um painel novo:
- Quando cada caso andou. Não a data de conclusão, e sim o horário de cada passagem de etapa. É o que permite reconstruir a série depois, inclusive de forma retroativa.
- Por qual caminho ele andou. Fluxo novo, fluxo antigo, ou a exceção que alguém abriu por fora. Se os três entram no mesmo balde, o resultado do fluxo novo fica diluído pelo volume que nunca passou por ele.
- Qual versão do processo estava valendo. Uma marca simples de regime, atualizada quando o processo muda. Sem ela, a comparação com o passado compara coisas diferentes.
Isso é decisão de arquitetura, tomada antes do go-live. Depois que o trimestre fechou sem esses campos, não há análise que recupere a informação: o dado não foi gravado. É o mesmo problema que tratamos em dashboard gerencial: por que os números não batem, visto do lado da medição de projeto.
Dois assuntos se confundem com frequência aqui. Em como medir o ROI de inovação e provar à diretoria o tema é a linha de base e a atribuição do ganho, ou seja, contra o quê você compara. Aqui o tema é quando você compara. Dá para acertar a linha de base e ainda assim ler o número na semana errada.
Um exemplo, e ele é hipótese
Com todas as letras: o caso abaixo é construído para ilustrar o raciocínio. Os números são ilustrativos e não saíram de nenhuma medição da Yowpi.
Uma distribuidora troca a conferência manual de pedidos por um fluxo com validação automática. No primeiro mês, o tempo médio de liberação sobe, porque a equipe confere o que o sistema decidiu e ainda refaz parte na planilha antiga. No segundo, a média volta ao patamar anterior e a diretoria conclui que o investimento não mudou nada.
O que ninguém olhou: entre pedidos do mesmo tipo, a diferença de tempo caiu pela metade. Os casos simples já passavam direto, e os complexos concentravam a demora. Era o fluxo novo funcionando na parte que ele se propôs a resolver, escondido dentro de uma média que ainda carregava o retrabalho da transição.
Sem o carimbo de tempo por etapa e sem a marca de qual caminho cada pedido seguiu, essa leitura não existe. Existe só a média, e a média disse que o projeto não serviu.
O que combinar com a diretoria antes de começar
Escreva quatro coisas antes da primeira linha de código, e deixe registrado onde a diretoria consiga consultar depois:
- Qual indicador de negócio a iniciativa move, escolhido entre os que a diretoria já acompanha.
- Qual é a duração esperada da transição, com a data em que a janela de medição abre.
- Qual sinal indica que o regime estabilizou, para que a data seja revisável com critério e não por conveniência.
- Qual é a condição de parada, ou seja, o que precisa acontecer para o projeto ser encerrado antes da janela abrir.
A última é a que protege as outras três. Sem condição de parada escrita, qualquer número ruim no meio da transição vira argumento para encerrar, e qualquer projeto sem resultado vira argumento para esperar mais um trimestre. Combinar o critério antes tira as duas conversas do improviso.
O critério de encerramento em si já tratamos em quando encerrar um projeto de inovação que não escala. O que muda aqui é a ordem: a condição de parada precisa existir antes de a janela de medição abrir, senão ela acaba escrita depois do número ruim, por quem o número ruim incomoda.
Esse combinado também muda a conversa sobre adoção. Um sistema pouco usado no mês dois é esperado; no mês seis é sintoma. A diferença está em medir o uso real depois do go-live, não em perguntar à equipe se ela gostou.
Acertar a janela não encerra o assunto. Quando o ganho aparece, ele ainda precisa virar resultado, e é aí que entra por que o ganho de produtividade não vira resultado.
Perguntas frequentes
Não vejo como mensurar o resultado. Por onde começo?
Pelo campo, não pelo painel. Escolha um indicador que a diretoria já usa e verifique se o sistema grava o horário de cada passagem de etapa desse processo. Se não grava, esse é o primeiro trabalho. Painel construído sobre dado agregado mensal não responde quando o resultado apareceu, e é essa pergunta que decide o veredito.
Não consigo justificar o investimento agora. Isso muda alguma coisa?
Muda o que você promete. Um business case que promete ganho no primeiro trimestre entrega uma queda e perde credibilidade para o pedido seguinte. Declare a transição, diga quanto ela deve durar e marque a data em que a medição começa. Assim o resultado se sustenta quando chegar. A evidência da curva J respalda esse jeito de apresentar o caso, e vem de pesquisa pública, não de fornecedor.
Receio de que não elimine os gargalos de verdade. Como saio dessa dúvida antes?
Olhe a dispersão em vez de esperar o fechamento. Se a equipe já domina o fluxo e a dispersão estacionou no mesmo patamar de antes do projeto, o gargalo continua onde estava e mudou só a interface. Esse sinal aparece semanas antes do trimestre acabar, e dá tempo de corrigir o escopo enquanto o projeto ainda está em execução.
O próximo passo
Se a sua operação hoje só produz média mensal, o Diagnóstico de Arquitetura Operacional é uma conversa de 30 minutos sobre o que os seus sistemas registram e o que falta para medir um projeto no momento certo: agende quando fizer sentido.
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem proposta na primeira conversa.
Agendar diagnóstico