Como identificar onde a IA faz sentido na sua operação
Cinco etapas de verificação para qualificar processos operacionais antes de um diagnóstico de IA, com critérios de aprovação e reprovação.
Mauricio Zaffari
Quando você reúne a equipe com uma lista de processos operacionais para avaliar automação, começar pelas capacidades dos modelos é o caminho errado. O que funciona na prática é um procedimento de triagem que qualifica ou descarta candidatos antes de mobilizar horas técnicas e orçamento.
O protocolo tem cinco etapas, e cada uma tem critérios claros de aprovação e reprovação. Para mostrar como ele funciona, vamos usar um cenário hipotético, mas realista: a conferência de notas fiscais contra pedidos de compra no ERP antes da liberação do pagamento.
Etapa 1: Volume e repetição
O teste: O processo roda em cronograma previsível e com volume suficiente para que a execução manual gere gargalo operacional?
Critério de APROVAÇÃO: O processo roda diariamente ou semanalmente, processa dezenas ou centenas de registros e consome horas dedicadas da equipe.
Critério de REPROVAÇÃO: A tarefa é pontual, esporádica ou acontece poucas vezes por mês com regras diferentes a cada execução.
Ação na reprovação: Priorize outros candidatos. Automatizar fluxos de baixo volume costuma gerar custo de sustentação sem ganho perceptível, salvo quando o custo ou o risco de cada ocorrência justificar o projeto.
Teste do candidato (conferência de notas): No cenário de exemplo, a equipe de contas a pagar recebe cerca de 120 notas por dia útil e dois analistas dedicam quatro horas diárias para cruzar itens com pedidos de compra. Veredito: APROVADO.
Etapa 2: Regras explícitas versus conhecimento tácito
O teste: Um especialista da operação consegue descrever por escrito as condições exatas que aprovam, retêm ou rejeitam um item?
Critério de APROVAÇÃO: Tolerâncias de valores, alíquotas fiscais, prazos e regras de roteamento estão documentados em manuais operacionais ou parâmetros de sistema.
Critério de REPROVAÇÃO: Analistas tomam decisões com base em impressões informais, como "costumamos aceitar pequenas diferenças para o fornecedor X se a entrega foi adiantada".
Ação na reprovação: Documente as regras e exceções antes de avaliar a automação. Regras que existem apenas na memória de uma pessoa não sustentam um fluxo automático.
Teste do candidato (conferência de notas): Códigos de produtos, margens de divergência de até 2 por cento e condições de pagamento estão em norma interna, mas a tolerância de frete foi combinada verbalmente por um comprador. Veredito: REPROVADO POR ENQUANTO. A etapa só é superada quando a tolerância de frete estiver documentada.
Etapa 3: Acessibilidade e formato dos dados
O teste: Os documentos recebidos e as tabelas de referência estão acessíveis de forma programática, ou dependem de logins manuais e planilhas soltas?
Critério de APROVAÇÃO: Documentos chegam por caixa de entrada monitorada, diretório compartilhado ou fila de mensageria. As tabelas do ERP podem ser lidas via réplica de banco de dados, API ou exportação agendada.
Critério de REPROVAÇÃO: Informações críticas estão presas em papel físico, em planilhas locais não sincronizadas ou em portais que exigem login manual com captcha.
Ação na reprovação: Trate a demanda como um projeto de integração de dados, não de inteligência artificial. Conecte as fontes primeiro.
Teste do candidato (conferência de notas): As notas chegam em PDF e XML por e-mail específico de contas a pagar, e os pedidos residem em banco de dados relacional com acesso de leitura. Para a conferência, a leitura é suficiente: a liberação do pagamento continua acontecendo no ERP, com as permissões e aprovações definidas no projeto. Veredito: APROVADO.
Etapa 4: Critério determinístico de conferência
O teste: Existe um teste objetivo para determinar se a saída gerada está correta ou se cometeu um erro de validação?
Critério de APROVAÇÃO: Há regras numéricas e lógicas claras: valores extraídos coincidem com os pedidos dentro das tolerâncias, e qualquer inconsistência gera apontamento para revisão humana.
Critério de REPROVAÇÃO: A avaliação de sucesso é subjetiva, como "o resumo parece convincente". Sem critérios objetivos, a equipe não consegue avaliar as divergências de forma consistente nem acompanhar a acurácia do fluxo ao longo do tempo.
Ação na reprovação: Paralise o avanço até que a operação estabeleça parâmetros claros de sucesso.
Teste do candidato (conferência de notas): Uma conferência é válida quando quantidades, valores unitários e CNPJ batem com a ordem de compra dentro das tolerâncias documentadas. Qualquer diferença vai para fila de exceção. Veredito: APROVADO.
Etapa 5: Dono do processo e gestão de exceções
O teste: Há um supervisor operacional responsável por analisar exceções, atualizar regras e garantir a continuidade do fluxo?
Critério de APROVAÇÃO: Um gestor da área assume a responsabilidade direta pela fila de exceções e pelo acompanhamento da acurácia diária.
Critério de REPROVAÇÃO: A demanda vem de uma área corporativa isolada sem envolvimento da liderança operacional que responde pela rotina do setor.
Ação na reprovação: Não inicie o desenvolvimento. Processos sem dono na operação tendem a cair em desuso depois da entrega.
Teste do candidato (conferência de notas): A coordenadora de contas a pagar assume a fila de divergências na rotina do time. Veredito: APROVADO.
As cinco etapas formam este fluxo de decisão:
flowchart TD
Candidato["Processo candidato"] --> G1{"Etapa 1: Volume suficiente?"}
G1 -- Não --> D1["Priorizar outros processos"]
G1 -- Sim --> G2{"Etapa 2: Regras documentadas?"}
G2 -- Não --> D2["Documentar regras primeiro"]
D2 --> G2
G2 -- Sim --> G3{"Etapa 3: Dados acessíveis?"}
G3 -- Não --> D3["Resolver acesso aos dados"]
D3 --> G3
G3 -- Sim --> G4{"Etapa 4: Saída conferível?"}
G4 -- Não --> D4["Definir critério de validação"]
D4 --> G4
G4 -- Sim --> G5{"Etapa 5: Dono definido?"}
G5 -- Não --> D5["Definir dono na operação"]
D5 --> G5
G5 -- Sim --> Pronto["Apto para o diagnóstico de 2 a 3 semanas"]
A escolha de priorização entre candidatos
Quando vários processos passam pelas cinco etapas, evite ordená-los pelo retorno financeiro teórico. Trate a economia como hipótese a validar no piloto, não como critério de seleção.
Entre os aprovados, priorize o fluxo com dados acessíveis, regras documentadas e saída conferível. Anote as dependências restantes de cada candidato; elas entram no planejamento do diagnóstico.
O diagnóstico costuma ser planejado para 2 a 3 semanas. Quando o piloto é viável, costuma ser estimado em 4 a 6 semanas após a definição do escopo.
Em resumo: o checklist de qualificação
Antes de mobilizar horas técnicas e orçamento, passe cada candidato por este checklist:
- Etapa 1: Frequência regular e volume operacional comprovado.
- Etapa 2: Lógica de decisão mapeada e documentada.
- Etapa 3: Dados de entrada e consulta acessíveis por conexão direta.
- Etapa 4: Critério objetivo para medir acertos e erros.
- Etapa 5: Gestor operacional responsável pela análise de exceções.
Se o processo reprovar em alguma etapa, resolva o bloqueio específico antes de programar qualquer linha de código. Se passar por todas, ele está pronto para o diagnóstico.
Deseja aplicar essa triagem aos processos da sua empresa? Solicitar diagnóstico.