Piloto de inovação: quantos casos ele precisa ver
Quantos casos o piloto precisa ver? Todos os que a operação produz com frequência suficiente para aparecer no primeiro ano, incluindo fechamento de mês, cancelamento, correção e a exceção que ninguém documenta. Duração não mede isso. Um piloto de três semanas pode ver muito ou quase nada, dependendo de quais casos entraram nele.
Por que o piloto deu certo e o sistema não?
Porque os dois foram submetidos a populações diferentes. O piloto recebeu os casos que couberam na janela, e a janela foi escolhida pelo calendário do projeto. O sistema recebe a operação inteira, com o fechamento de mês, o cliente que cancela no meio, o pedido que volta e a nota emitida errada.
Isso não é falha de execução do piloto. É consequência de como ele foi dimensionado. A pergunta que costuma abrir a reunião de planejamento é quanto tempo o teste vai durar. A pergunta que decide o resultado é quais casos ele precisa conter.
Já tratamos de como montar o experimento em prototipagem rápida: como validar antes de investir, e do que falta depois da aprovação em protótipo aprovado: o que falta para virar sistema. Aqui o assunto é anterior aos dois: o que entrou no teste.
Quantos caminhos um processo real tem?
Mais do que o desenho de processo costuma mostrar. Dá para responder isso com dado, porque algumas empresas passaram a doar seus registros de eventos para pesquisa.
Um dos casos públicos mais bem documentados é o de uma multinacional holandesa de tintas e revestimentos, que em 2019 abriu para pesquisa os pedidos de compra de 2018 de parte de suas 60 subsidiárias. São 76.349 documentos de compra, 251.734 itens e 1.595.923 eventos registrados em 42 tipos de atividade, executados por 607 pessoas e 20 processos automáticos (descrição oficial do log).
Dois alunos da RWTH Aachen, na categoria estudante do desafio, analisaram esse log e contaram 11.973 sequências distintas de atividades (Hüser e Heisenberger). Um caso tem entre 1 e 990 eventos.
O número que mais interessa a quem desenha piloto é outro. Seis atividades concentram cerca de 86% dos eventos, e as outras 36 dividem o que sobra. Um piloto dimensionado pelo que mais aparece enxerga o processo com seis palavras.
Esse formato não é exclusividade daquele log, e o extremo oposto também existe. Um grupo da TU München catalogou 98 logs públicos de processos reais em 37 atributos, entre eles a cobertura das cinco variantes mais frequentes, e registrou contagens de variantes que vão de 1 a 22.632 (Costa, Eroglu, Andree e Pufahl). Onde a sua operação cai nessa faixa é pergunta empírica, não suposição.
O que o piloto descobre que o desenho não sabia
A parte útil do teste raramente é a confirmação. É a discordância entre o processo que a empresa acredita ter e o que ela executa.
No log de compras, a empresa acredita que um grupo específico de itens sempre passa por conferência cruzada entre o recebimento da mercadoria e o recebimento da nota. Na categoria dominante do log, os analistas encontraram cerca de 14.000 casos, de 747 fornecedores diferentes, em que os dois registros não apareceram juntos. O controle existia no documento e não na execução. Quem escreve o piloto pelo documento herda essa distância inteira.
Na mesma categoria, 53.092 casos precisaram de remoção de bloqueio de pagamento antes de liquidar a nota, e 7.800 terminaram com o item de compra apagado, um desfecho que acrescenta 72 dias em média ao caso. Nenhuma dessas três coisas é o caminho que alguém desenha no quadro.
Um segundo log, de outro setor, mostra o mesmo tipo de descolamento com números menores. Ao acompanhar 1.050 pacientes com suspeita de sepse num hospital regional holandês por um ano e meio, Felix Mannhardt e Daan Blinde mediram, em estudo publicado em 2017, a aderência a duas regras clínicas de tempo: antibiótico em até uma hora após a triagem e lactato em até três horas (relatório BPMDS).
A primeira regra foi violada em 58,5% dos casos. A segunda, em 0,7%.
Os próprios autores não leem esse 58,5% como veredito sobre o cuidado. Eles apontam duas explicações concorrentes: a regra de uma hora é reconhecidamente estrita e nem todos os pacientes da amostra tinham sepse grave; e o horário do antibiótico é digitado à mão, com registros 24 horas depois da triagem e outros anteriores a ela. A conclusão deles é que a medição, sozinha, não sustenta ação.
Para quem dimensiona piloto, a lição está aí. A distância entre 58,5% e 0,7% pode ser regra que não cabe na operação ou cadastro que não registra o que aconteceu, e as duas hipóteses só se separam medindo.
Como dimensionar a cobertura em vez do calendário
Comece pela lista, não pelo cronograma. Antes de escolher a data de início, escreva os casos que o piloto precisa conter, com nome e quantidade mínima:
O caso comum, para ver se o desenho básico funciona. O caso de exceção que a equipe resolve por fora hoje, com planilha, mensagem ou telefonema. O caso de correção, quando alguém erra e precisa desfazer. O caso de cancelamento no meio do fluxo. O caso periódico, que só existe no fechamento do mês ou do trimestre.
Esse último é o que mais escapa. No processo de compras da multinacional, um item de aluguel gera um pedido e doze recebimentos ao longo do ano, um por mês, cada um com uma nota de um doze avos do valor. Itens de logística chegam a ter centenas de recebimentos num único item. Um piloto de três semanas não vê nada disso, e não é por ser curto: é por não conter o caso.
Quando um caso da lista não pode ser produzido no período, você tem duas saídas honestas. Injetar o caso de propósito, reprocessando um registro real do ano passado dentro do piloto. Ou declarar o caso como não coberto, por escrito, e tratá-lo como risco aberto na decisão de promover.
Existe uma terceira saída, que é supor que ele vai funcionar porque os outros funcionaram. Essa é a que costuma produzir o sistema que quebra no primeiro fechamento.
Como isso funciona na prática
O cenário abaixo é uma hipótese de trabalho, não uma medição de cliente. Serve para mostrar a diferença entre as duas formas de dimensionar.
Uma empresa de manutenção de equipamentos com faturamento na casa de R$ 400 mil por mês testa um sistema de ordem de serviço. O piloto roda três semanas com dois técnicos e fecha 60 ordens sem incidente. A recomendação é promover.
Reescrito por cobertura, o mesmo piloto pede outra coisa. Trinta ordens comuns. Cinco atendimentos com peça em garantia, que hoje o técnico resolve por telefone com o fornecedor. Cinco ordens abertas e canceladas pelo cliente depois do deslocamento. Três casos de retrabalho, quando o equipamento volta pelo mesmo defeito em menos de 30 dias. E o fechamento de contrato mensal, que precisa ser reprocessado com dados de um mês passado porque não cabe na janela.
As trinta ordens comuns provavelmente passam nos dois desenhos. As outras treze é que definem se existe sistema ou se existe uma tela bonita com uma operação paralela atrás.
O caso que o piloto não viu precisa de um endereço
Essa é a parte arquitetural, e ela vale mesmo para o piloto bem dimensionado, porque cobertura completa não existe.
O caso não previsto acaba acontecendo. A única escolha real é se ele acontece dentro do sistema ou fora dele. Quando não há lugar definido, ele sai. Vira mensagem no celular de alguém, e depois vira conhecimento que só aquela pessoa tem. Foi assim que a operação virou o que é hoje.
Três decisões resolvem isso, e todas cabem antes do go-live. Onde o caso fora do padrão fica registrado, com o mesmo identificador do caso comum. Quem tem alçada para resolvê-lo e em que prazo. Em que estado o registro fica depois, para que o relatório do mês seguinte saiba contá-lo.
Sem essas três, o sistema fica com uma cobertura declarada que a operação não respeita, e o número que sai dele deixa de bater com o financeiro. Esse é o mesmo mecanismo que descrevemos em dashboard gerencial: por que os números não batem.
O estudo do hospital deixa ainda uma lição sobre método. O modelo de processo gerado automaticamente pelos algoritmos ficou impreciso demais para conversar com médicos e enfermeiros. O modelo desenhado à mão, em rodadas com quem executa o trabalho, cobriu 98,3% do log. A leitura correta do dado ainda depende de quem opera.
Perguntas frequentes
A implementação vai exigir tempo demais do time?
Dimensionar por cobertura costuma custar menos tempo que dimensionar por calendário, porque troca semanas de observação passiva por casos escolhidos. Um piloto que injeta cinco exceções na primeira semana aprende mais que um que espera três semanas para ver se alguma aparece. O custo real está em reprocessar registros antigos, e isso costuma ser trabalho de horas, não de sprints.
Não vejo como mensurar o resultado do piloto.
Meça cobertura antes de medir desempenho. A lista de casos escrita no início vira o placar: quantos foram executados dentro do sistema, quantos saíram para planilha ou mensagem, quantos ninguém conseguiu produzir. Esse placar é verificável e não depende de opinião de usuário, ao contrário da percepção de que o teste foi bem.
Receio de que o sistema não elimine os gargalos de verdade.
Esse receio é fundamentado, e a cobertura existe justamente para resolvê-lo. Gargalo raramente mora no caso comum, que já é rápido porque é repetido. Ele mora na exceção, no retrabalho e na espera por decisão. Um piloto que só viu o caso comum não tem como demonstrar nada sobre o gargalo, e aprovar por causa dele é decidir sem evidência.
O próximo passo
Se o seu piloto está prestes a ser promovido e a lista de casos que ele viu nunca foi escrita, vale uma conversa de 30 minutos: o Diagnóstico de Arquitetura Operacional serve para mapear quais caminhos a sua operação produz antes de a decisão ser tomada.
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