Testar um Plano Antes de se Comprometer

Onde Isso Dá Errado

Uma greve fecha um porto na segunda. Na terça alguém tem que dizer se traz as peças de avião, se segura a linha, ou se embarca por outro porto. A resposta depende de quanto cada opção custa, de quanto tempo cada uma leva, e de quais pedidos ficam em risco de qualquer jeito.

Então alguém monta uma planilha. Leva dois dias. Ela carrega uma única versão dos fatos, se apoia em números digitados à mão, e é jogada fora assim que a decisão é tomada. Na próxima vez que isso acontecer, o trabalho começa outra vez do zero.

O plano não é a parte difícil. Ter os números em tempo é.

E ninguém quer testar um plano novo no sistema de produção. É o sistema com o qual a fábrica, o armazém e a contabilidade funcionam. Um experimento lá dentro não é um experimento.

Para Quem É Isto

Três pessoas na mesma sala na terça-feira, discutindo a partir de três conjuntos de números diferentes.

• Diretor de operações. O que chega hoje é um porto fechado na segunda e uma decisão para a terça, com os números que resolveriam espalhados por quatro sistemas. O que muda é o que você leva para a reunião: a mudança escrita como uma frase clara, as regras com que ela colide, e a ordem em que elas doem.
• Responsável pelo planejamento. O que chega hoje é um plano discutido a partir de pontos de pedido, prazos de entrega e compromissos de serviço que vivem na cabeça de três pessoas — que é como duas delas passam uma hora descobrindo que descreviam planos diferentes. O que muda é a ordem do trabalho. As premissas ficam escritas antes da discussão, e não reconstruídas depois, e cada consequência nomeia a regra de que decorre, de modo que um colega pode discordar pelo mérito.
• Diretor financeiro. O que chega hoje é uma linha de frete urgente no contas a pagar que ninguém consegue amarrar à decisão que a causou. O que muda é que a opção que alguém escolheu e o nome de quem escolheu ficam guardados juntos, então a pergunta de seis meses depois se responde pelo arquivo, e não pela reunião.

O Que Acontece No Lugar

Vale ser claro sobre o que isto é, porque a categoria está cheia de ferramentas que são vagas quanto a isso. O motor não roda uma simulação sobre os seus dados de produção e não calcula um resultado. Você enuncia a mudança como uma hipótese e entrega a ele as regras que governam aquilo que você está mudando — pontos de pedido, prazos de entrega, compromissos de serviço, a premissa de reserva. Ele raciocina sobre essas regras e devolve uma leitura ordenada do que decorre daí, com cada consequência amarrada à regra de que ela saiu.

Então o que volta é um argumento, não uma resposta. É isso que é útil, e vale dizer sem rodeios: uma projeção apresentada como decisão é pior do que nenhuma projeção, porque tira o julgamento de alguém que responde por ele e passa para um software que não responde. O que isto dá à sala é o caso aberto — com quais regras a mudança colide, em que ordem elas mordem, e o que alguém precisaria acreditar para o plano se sustentar. A decisão fica onde estava.

Duas consequências disso valem a pena. Enunciar a hipótese força as premissas a ficarem escritas, que é o passo que as equipes pulam e a razão pela qual duas pessoas podem discutir uma hora e descobrir que estavam falando de planos diferentes. E como o raciocínio acontece no seu próprio hardware, o cenário que você está considerando — qual fornecedor você poderia tirar, qual rota você poderia cortar — nunca sai do prédio.

Você também pode deixar difícil de propósito. Rode a rota com uma semana de atraso. Tire a segunda fonte de fornecimento. Deixe uma carga refrigerada derivar. Um plano que só se sustenta quando a semana corre bem vai cair aqui, na sua frente, enquanto descobrir isso ainda não custa nada.

A execução não escolhe para você. Ela coloca as opções em fila. Quando alguém escolhe uma e manda para que se aja, a opção escolhida e o nome dessa pessoa ficam anotados juntos, então a pergunta que vem seis meses depois é respondida a partir do arquivo, e não a partir da reunião.