Por que seu piloto não virou operação
O piloto funcionou, todos aplaudiram na demonstração e nada entrou em produção. Isso raramente é problema de modelo. É ausência de cinco decisões que ninguém tomou.
Aplicar um checklist de prontidão operacional em qualquer piloto seu e dizer, com evidência, o que falta para ele entrar em produção ou por que ele deve ser encerrado.
Faça um cadastro para liberar este curso
O curso 01 é aberto. Para os cursos 02 a 05, pedimos seis campos. É um cadastro único: feito uma vez, vale para toda a trilha. Não é diagnóstico gratuito nem gera contato comercial automático.
Demonstração e operação são coisas diferentes
Uma demonstração precisa funcionar uma vez, com dados escolhidos, na frente de quem já quer ver aquilo funcionando. Uma operação precisa funcionar todos os dias, com os dados que aparecem, e falhar de forma previsível quando falha.
A maior parte dos pilotos morre porque foi construída para o primeiro cenário e depois cobrada pelo segundo. O time apresenta um caso que passou, alguém pergunta o que acontece quando o documento vem ilegível, e a conversa termina em promessa de ajuste.
Uma demonstração precisa funcionar uma vez, com dados escolhidos, na frente de quem já quer ver aquilo funcionando. Uma operação precisa funcionar todos os dias e falhar de forma previsível quando falha.O argumento central deste curso
Não existe dono, existe entusiasta
Piloto costuma ter patrocinador de vitrine e um entusiasta que faz acontecer. Nenhum dos dois é dono. Dono é quem responde pelo número quando ele não aparece, tem orçamento para sustentar a operação e autoridade para mudar o processo em volta.
Teste simples: se a operação parar de rodar na terça-feira, quem recebe a ligação? Se a resposta é "o pessoal de tecnologia" ou "depende", não existe dono.
O critério de conclusão nunca foi escrito
Uma operação precisa saber quando terminou uma unidade de trabalho. O documento foi conferido, o lead foi qualificado, a proposta está pronta para envio. Sem esse critério, não há como medir volume, não há como medir erro e não há como pagar por resultado.
Piloto vive sem isso porque a avaliação é subjetiva: alguém olha a saída e diz que está boa. Operação não sobrevive assim.
A exceção não tem caminho
Todo fluxo real gera casos fora do padrão. No piloto, a exceção volta para o entusiasta, que resolve na mão e não registra. Em operação, a exceção precisa de destino: quem recebe, em quanto tempo, com qual informação e o que acontece se ninguém responder.
Ninguém sabe dizer qual porcentagem dos casos precisou de intervenção humana no último mês. Se não é medido, não foi desenhado.
O custo por unidade nunca foi calculado
Piloto roda com volume baixo, e o custo aparece como algo desprezível. Em produção, o mesmo custo por caso multiplicado pelo volume real pode inverter o resultado econômico. Quando a fatura chega antes da conta ter sido feita, a operação é suspensa por finanças, não por tecnologia.
É preciso saber o custo de um caso simples, de um caso que exigiu reprocessamento e de um caso que foi para exceção humana.
A integração ficou para depois
O piloto que exige alguém exportando planilha e colando resultado em outro sistema não é operação, é trabalho manual com etapa nova. Enquanto a saída não entra no sistema onde a decisão acontece, o ganho fica preso na demonstração.
| Decisão | Como está no piloto | O que a operação exige |
|---|---|---|
| Dono | Um entusiasta que faz acontecer | Quem responde pelo número, com orçamento e autoridade |
| Conclusão | Alguém olha a saída e diz que está boa | Critério escrito do que conta como unidade concluída |
| Exceção | Volta para o entusiasta, sem registro | Destino, prazo, responsável e o que ocorre se ninguém responder |
| Custo | Desprezível no volume de teste | Custo do caso simples, do reprocessado e do que foi para humano |
| Integração | Exportar planilha e colar em outro sistema | Saída entra no sistema onde a decisão acontece |
Encerrar um piloto pode ser a decisão correta
Nem todo piloto merece produção. Se o volume é pequeno, se o dado necessário não existe, se o processo em volta vai mudar nos próximos meses, encerrar preserva orçamento e credibilidade. O erro não é encerrar, é manter em estado permanente de quase.
O piloto em estado permanente de quase
Um piloto é apresentado com um caso que passou. Alguém pergunta o que acontece quando o documento chega ilegível, e a resposta é uma promessa de ajuste. O ciclo se repete a cada apresentação.
Um ano depois o piloto continua ativo, consumindo atenção e orçamento, sem nunca ter entrado em produção nem sido encerrado. Ninguém quer ser quem cancelou, e ninguém consegue defender a continuidade.
Checklist de prontidão operacional
Avalie um piloto seu nos cinco pontos. Marque cada linha com o que já existe por escrito, não com o que se pretende fazer.
| Ponto de decisão | Existe hoje? (sim, parcial, não) | Quem responde |
|---|---|---|
| Dono com orçamento | ||
| Critério de conclusão | ||
| Caminho de exceção | ||
| Custo por unidade | ||
| Integração no sistema final |
Piloto com dois ou mais pontos em "não" não está pronto para produção, e insistir nele consome o orçamento que a próxima iniciativa vai precisar.
De onde vem o argumento
Os cinco pontos não são teoria de gestão. São as perguntas que aparecem quando uma operação assistida por IA entra em produção e alguém precisa responder por ela em uma reunião de resultado.
Quando o checklist virar decisão de investimento
Se o piloto tem dono, critério e volume, mas falta arquitetura e integração, o problema é execução. Se falta dono e critério, o problema é anterior à tecnologia. O Prumo Discovery separa os dois casos antes de qualquer construção.