Um processo desenhado ainda não é uma operação funcionando.

Uma equipe pode desenhar um fluxo melhor, aprovar o protótipo e ainda chegar à segunda-feira com o mesmo trabalho manual. Isso acontece porque to-be e to-run respondem a perguntas diferentes.

O to-be descreve como o processo deveria funcionar. O to-run define tudo o que precisa existir para que esse processo funcione todos os dias, inclusive quando algo sai do caminho esperado.

O papel do to-be

O to-be organiza o futuro desejado. Ele ajuda a tornar visíveis:

• etapas e decisões;
• papéis e responsabilidades;
• regras, aprovações e exceções;
• interfaces e experiências;
• automações e integrações possíveis;
• indicadores que precisam mudar.

É uma etapa indispensável. O problema aparece quando o desenho é tratado como se já fosse a operação.

O que o to-run acrescenta

O to-run leva a discussão do fluxo ideal para a capacidade operacional. Isso inclui arquitetura, acesso, dados, segurança, teste, monitoramento, documentação, treinamento, suporte e responsáveis.

Uma integração não está pronta apenas porque funcionou uma vez no ambiente de desenvolvimento. Um agente de IA não está pronto apenas porque produziu uma boa resposta em uma demonstração. Um fluxo de trabalho não está pronto apenas porque sua sequência principal foi publicada.

Pronto é utilizável, responsável e sustentado — não apenas publicado.

As exceções fazem parte do processo

Operações reais têm dados ausentes, sistemas indisponíveis, regras conflitantes e decisões que exigem intervenção humana. Por isso, o desenho do to-run precisa responder também:

• O que ocorre quando a integração falha?
• Quem revisa uma resposta de baixa confiança?
• Como uma tarefa volta ao fluxo depois de uma correção?
• Que informação precisa ficar registrada?
• Quem recebe o alerta e qual é o próximo passo?

Automatizar apenas o caminho feliz cria uma demonstração. Construir os caminhos de exceção cria capacidade operacional.

Cinco perguntas antes de chamar de pronto

1. Existe um critério observável de aceite?

Todos precisam saber o que será testado e que resultado caracteriza uma entrega válida.

2. Os fluxos de erro e exceção foram testados?

Falhas previsíveis precisam de resposta previsível. Logs, mensagens e fallback não podem ser decisões posteriores.

3. A operação sabe usar e sustentar a solução?

Documentação, treinamento, responsáveis e canal de suporte fazem parte da entrega.

4. Segurança e acesso foram tratados no contexto real?

Usuários, permissões, dados, ambientes e integrações precisam estar coerentes com a rotina da empresa.

5. O valor será revisto depois da entrada em operação?

O indicador definido no início deve voltar à conversa. Sem revisão, é difícil separar adoção real de simples publicação técnica.

Do desenho à rotina

Transformação operacional não termina quando o futuro foi desenhado. Ela acontece quando pessoas, sistemas, dados e responsabilidades conseguem sustentar esse futuro na prática.

É por isso que o método da Avni acompanha o processo atual, a decisão de valor, o desenho futuro, a implantação e a evolução. O desenho orienta a construção; a operação mostra o que ainda precisa mudar.