terça-feira, setembro 22, 2026

Automatizar é o último passo: Um convite (parte IV)

A HBR publicou um artigo, "Stop Automating Old Processes. Design New Ones Instead" que vai ao encontro de postais que escrevi este ano:

O artigo parte de um paradoxo. As empresas estão a aumentar rapidamente o investimento em inteligência artificial, mas o retorno continua a ser difícil de encontrar. Segundo os números citados pelos autores, quase oito em cada dez organizações já usam IA generativa em pelo menos uma função, mas:

"PwC’s 2026 “Global CEO Survey” finds that only 12% of CEOs report both revenue and cost benefits, while McKinsey QuantumBlack’s April 2026 analysis finds that 60% of organizations still see no enterprise-wide EBIT impact"

Talvez o problema não esteja na falta de tecnologia. Talvez esteja naquilo que se escolhe transformar. Muitas empresas pegam numa tarefa antiga, colocam-lhe IA em cima, medem quanto tempo pouparam e chamam-lhe transformação. O artigo da HBR defende que a unidade de análise não deve ser a tarefa isolada, mas o fluxo de trabalho que produz um resultado valorizado pelo cliente ou pelo utilizador.

É uma diferença importante. Uma tarefa pode ficar muito mais rápida sem que o processo melhore. Pode até piorar. Um agente pode produzir propostas comerciais em minutos, mas, se a informação necessária continuar dispersa, os critérios de aprovação forem ambíguos e a capacidade para cumprir não for verificada, a empresa apenas passará a produzir propostas problemáticas mais depressa. Pode classificar reclamações automaticamente, mas, se ninguém tiver autoridade para investigar causas recorrentes, a velocidade de classificação não melhora a experiência do cliente. Pode encerrar acções correctivas com grande eficiência, mas, se as causas não forem compreendidas e a eficácia não for verificada, teremos um excelente sistema para fechar problemas que regressam.

No primeiro postal da série recorri ao chamado algoritmo de Elon Musk: questionar os requisitos, eliminar o que não devia existir, simplificar e optimizar, acelerar e, apenas no fim, automatizar. A ordem interessa porque a pior coisa que podemos fazer é acelerar aquilo que devia ter sido eliminado.

No segundo, trouxe Arvind Krishna, CEO da IBM, e a sua defesa de uma reestruturação profunda dos workflows. O exemplo era básico e, por isso mesmo, poderoso: um pedido interno que chegava a envolver 18 pontos de contacto passou a ter um único ponto de contacto. A IBM não se limitou a fazer mais depressa cada uma das 18 passagens. Redesenhou o percurso.

No terceiro postal, parti da observação de processos reais. Quando seguimos o trabalho com as pessoas que o executam, aparecem as pequenas fricções que os organigramas e os procedimentos não mostram: informação pedida duas vezes, decisões que sobem sem necessidade, ficheiros paralelos, validações feitas por hábito, documentos preparados manualmente, esperas entre departamentos e excepções tratadas de memória.

Na série sobre o "biorreactor" da fábrica, acrescentei outra dimensão. A IA não deve começar pela pergunta "Onde podemos usar IA?" Deve começar por uma dor operacional, uma variação importante ou uma decisão que está a ser tomada tarde demais. Depois é necessário ligar toda a cadeia:

dados → análise → previsão → decisão → acção → verificação → aprendizagem

Sem esta cadeia, a IA transforma-se num painel mais elegante, numa demonstração interessante ou numa forma moderna de produzir confusão. O artigo da HBR dá agora uma estrutura mais completa a esta linha de raciocínio. Não basta melhorar o processo antes de o automatizar. É necessário redesenhar o fluxo de ponta a ponta, decidir onde deve permanecer a autoridade humana e preparar o sistema para os casos em que a realidade não segue o caminho feliz da demonstração.

O artigo identifica quatro falhas recorrentes nos projectos de IA.

A primeira é acelerar tarefas sem acelerar a criação de valor. Produzem-se mais relatórios, mais código, mais respostas ou mais tickets encerrados, mas o resultado procurado pelo cliente não melhora.

A segunda é desenhar apenas para o caso normal. A demonstração funciona, mas a operação real contém informação em falta, requisitos contraditórios, baixa confiança, casos ambíguos e situações que ninguém previu.

A terceira é ignorar o fluxo de ponta a ponta. Uma actividade torna-se mais rápida e o estrangulamento desloca-se para a etapa seguinte. A IA produz mais código, mas os testes e a revisão não conseguem absorvê-lo. Gera mais propostas, mas a engenharia ou a produção não conseguem validá-las. Prepara mais análises, mas a gestão não tem capacidade para decidir sobre elas.

A quarta é optimizar a métrica errada. O número de tickets encerrados aumenta, mas os clientes voltam a contactar a empresa. O tempo de resposta diminui, mas cresce o retrabalho. O dashboard fica verde enquanto a realidade se degrada.

Esta é uma velha doença da gestão com uma nova interface: confundir actividade com resultado e eficiência local com desempenho do sistema.

Há aqui uma oportunidade para recuperar a abordagem por processos das mãos de quem a reduziu a fluxogramas para mostrar ao auditor. Num mundo com agentes de IA, compreender o trabalho torna-se ainda mais importante. Antes de automatizar uma decisão, é preciso saber quem deve decidir, com que informação, segundo que critérios e dentro de que limites. Antes de acelerar uma passagem, é preciso perceber se ela acrescenta valor ou se apenas existe porque dois sistemas nunca foram ligados. Antes de treinar um agente para preencher um formulário, talvez convenha perguntar por que razão o formulário existe. 

Nas PME, esta disciplina é particularmente importante. Como há menos recursos e menos folga de gestão, a tentação de automatizar rapidamente uma tarefa incómoda é grande. Mas também é maior o custo de cristalizar um processo mal concebido. A IA pode libertar uma pequena empresa de muito trabalho administrativo; também pode cobrir de cimento digital as suas redundâncias, ambiguidades e pequenas capelinhas. 

A HBR recupera uma advertência de Michael Hammer, publicada em 1990: 

"This kind of mismatch between our expectations of technology and the returns to our investment in it is not exactly new. In 1990, Michael Hammer warned in these pages that incumbent companies were squandering the opportunities afforded by IT by pointing it at existing processes instead of redesigning the processes to leverage the technology’s capabilities.

Three decades later, his warning is as urgent as ever."

Mais de três décadas depois, a inteligência artificial torna a advertência ainda mais actual. Nunca foi tão fácil automatizar. Por isso, nunca foi tão importante decidir primeiro o que não deve ser automatizado.

Automatizar é o último passo. Automatizar um processo ineficiente não o transforma. Apenas aumenta a velocidade a que ele é ineficiente.

Continua.

Sem comentários: