O dono de uma empresa de logística no interior de São Paulo contratou uma ferramenta de automação para o processo de emissão de notas fiscais. Três meses depois, a ferramenta funcionava exatamente como prometido. O problema: o processo que ela automatizou tinha três erros de conferência embutidos que a equipe corrigia manualmente toda semana. A automação acelerou o processo. E acelerou os erros junto.
Esse não é um caso isolado. É um padrão recorrente em automação de PMEs: a ferramenta funciona, o processo era ruim, e ninguém mapeou isso antes de assinar o contrato.
Por que automatizar um processo errado sai mais caro do que não automatizar nada
Quando um processo tem falhas manuais, ele tem pelo menos uma vantagem: dá para parar no meio. A pessoa que executa percebe que algo está estranho e para para conferir. A automação não faz isso. Ela executa até o fim, com velocidade e sem hesitação.
Um processo manual com erro gera retrabalho eventual. Um processo automatizado com erro gera retrabalho em escala, toda vez, sem exceção.
O dado que ilustra esse risco vem de uma direção inesperada: o Gartner previu em junho de 2025 que mais de 40% dos projetos de IA agentiva serão cancelados até o final de 2027, citando custos crescentes, valor de negócio pouco claro e controles de risco inadequados. Projetos que são cancelados raramente falham na tecnologia. Eles falham no que foi decidido automatizar.
Para PMEs, o custo não é só financeiro. É o tempo do gestor tentando entender por que o sistema "que funcionava na demonstração" está gerando problemas que antes não existiam.
O processo real não é o processo que sua equipe descreve
Quando você pergunta para alguém como o processo funciona, a pessoa te descreve como ele deveria funcionar. O que ela aprendeu no treinamento, o que consta no manual (se existir), o que ela responderia numa auditoria.
O processo real é diferente. Ele tem:
- Os atalhos que a equipe descobriu porque o jeito oficial é lento demais
- As exceções que viraram regra sem que ninguém atualizasse nada
- A dependência de uma pessoa específica que sabe uma senha, tem acesso a um sistema, ou simplesmente "sabe como é"
- Os erros que são corrigidos antes de chegar no cliente, mas que ninguém registra porque consertar faz parte do trabalho
Numa empresa de distribuição com que trabalhamos, o processo de separação de pedidos era descrito pela equipe como algo que levava em torno de duas horas. Na prática, levava cinco, porque uma etapa inteira dependia de a pessoa responsável estar presente para acessar o sistema da transportadora parceira. Quando ela estava de férias, o processo mudava. Esse desvio não apareceu em nenhuma entrevista. Apareceu quando alguém perguntou: o que acontece quando ela não está?
Esses desvios não aparecem numa entrevista de 20 minutos. Eles aparecem quando você observa o processo acontecendo, ou quando faz a pergunta certa.
A pesquisa de Maturidade Digital do Sebrae de 2024 mediu a média dos pequenos negócios brasileiros em 35 pontos numa escala de 0 a 80. Apenas 27% possuem sistema de gestão integrando todas as áreas do negócio. Isso significa que na maioria das PMEs, o processo real vive na cabeça das pessoas e em planilhas paralelas, não em sistemas. Automatizar sem mapear esse cenário é automatizar a versão fictícia do processo, não a versão que acontece de fato.
Por que o fornecedor não deve ser quem faz o mapeamento
Essa parte nenhum artigo sobre automação menciona: quando o fornecedor de uma ferramenta conduz o levantamento dos seus processos, ele está fazendo isso com viés. Não necessariamente por desonestidade. Mas por limitação estrutural.
O fornecedor faz o levantamento sabendo o que a ferramenta dele resolve. Isso não é desonestidade: é limitação de perspectiva. O problema é você tratar o resultado como diagnóstico neutro. Pergunte a qualquer revendedor: em quantos casos o levantamento concluiu que a empresa não precisava do produto dele? A resposta vai dizer tudo.
Esse conflito de interesse existe e já foi regulamentado em outros contextos. O governo federal americano tem uma regra específica (FAR Subpart 9.5) que proíbe que o mesmo fornecedor que ajudou a preparar especificações técnicas seja quem oferece a solução resultante. O motivo explícito na norma: "o contratado pode favorecer seus próprios produtos ou capacidades".
Se o governo americano precisou criar uma lei para lidar com isso em compras públicas, é porque o problema é real o suficiente para exigir regulamentação.
A Sage, fabricante de software de gestão, documentou em seu próprio blog americano que consultores de seleção de ERP frequentemente têm relacionamentos estabelecidos com fornecedores específicos que criam viés na recomendação, mesmo quando o produto não é o mais adequado. E que o mesmo consultor que faz a seleção costuma ser pago para implementar o sistema escolhido. O incentivo financeiro está embutido na estrutura.
No Brasil, com PMEs, o mecanismo é idêntico. O revendedor de software de gestão conduz o levantamento de requisitos, apresenta um diagnóstico, e recomenda a própria solução. Ele não está errado ao fazer isso. Mas você não deve confundir esse levantamento com um mapeamento neutro do seu processo.
A pergunta que o dono de PME faz na prática é: "posso pedir para o fornecedor mapear meus processos junto comigo?" A resposta honesta é: você pode participar desse levantamento, mas não pode assumir que o resultado é imparcial. O mapeamento que vai servir de base para a decisão precisa vir de dentro da sua empresa.
A pergunta que revela tudo: o que acontece quando dá errado?
Existe uma pergunta que, quando você faz para a sua equipe, revela mais sobre o processo real do que qualquer fluxograma. A pergunta é: o que acontece quando dá errado?
Não o que deveria acontecer. O que acontece de fato.
Se a resposta for "a gente liga para o fulano", o processo tem uma dependência crítica de pessoa que não está documentada em lugar nenhum. Se a resposta for "a gente refaz tudo desde o começo", o processo tem um ponto de falha sem mecanismo de recuperação. Se a resposta for "depende", o processo tem variações não mapeadas que vão surgir depois da automação como exceções que o sistema não sabe tratar.
Cada uma dessas respostas é um sinal de que o processo precisa ser revisado antes de ser automatizado. O processo tinha exceções que o sistema não sabia tratar. Ninguém havia perguntado sobre elas antes de assinar.
Pergunte também: quantas vezes por mês esse processo falha de alguma forma? Quanto tempo a equipe gasta consertando essas falhas? Quem sabe fazer esse processo quando a pessoa principal está de férias?
Você não precisa de BPMN nem de software de mapeamento para fazer essas perguntas. Precisa de uma hora sentado com quem executa o processo, sem o fornecedor na sala.
Ferramenta mínima para mapear: papel, planilha ou Miro em uma tarde
O mapeamento que precisa acontecer antes de qualquer reunião com fornecedor não precisa ser sofisticado. Precisa ser honesto.
O protocolo mínimo funciona assim:
Primeiro, escolha um processo específico. Não "o processo de vendas". Escolha "o processo de registro de um pedido novo, desde o momento em que o cliente entra em contato até o pedido aparecer no sistema". Quanto mais específico o escopo, mais útil o resultado.
Segundo, reúna as pessoas que executam o processo, não os gestores que supervisionam. Peça para cada uma descrever o que faz, em que ordem, e quanto tempo cada etapa leva na prática. Anote no papel ou numa planilha. Não corrija nada ainda.
Terceiro, compare as descrições. Se duas pessoas descrevem o mesmo processo de formas diferentes, você encontrou uma variação não documentada. Se uma etapa aparece na descrição de uma pessoa mas não na outra, você encontrou uma dependência invisível.
Quarto, para cada etapa, pergunte: o que acontece quando dá errado? O que precisa estar disponível para essa etapa funcionar? Quem depende do resultado desta etapa para fazer o próprio trabalho?
Quinto, anote os tempos. Não para otimizar agora, mas para ter uma referência. Se o processo leva 45 minutos hoje e a proposta de automação promete reduzir para 5 minutos, você precisa entender quais etapas somam esses 40 minutos de diferença.
Esse protocolo não vai gerar um mapeamento de consultoria. Vai gerar um documento honesto sobre como o processo funciona hoje, com os gargalos reais visíveis. É o suficiente para você entrar em qualquer reunião comercial sabendo o que está procurando automatizar, e o que o fornecedor está propondo automatizar. Se as duas coisas não coincidirem, você tem uma pergunta importante para fazer.
Como saber que o processo está pronto para a automação começar
Existe um conjunto de sinais que indicam que o processo está maduro o suficiente para ser automatizado. Não perfeito. Maduro.
- O processo está executado da mesma forma pela maioria das pessoas na maioria das vezes
- As exceções têm tratamento definido, mesmo que manual
- O resultado é previsível: dadas as mesmas entradas, as saídas são consistentes
- Os dados existem num sistema real, não na planilha que só uma pessoa sabe abrir
- Quando você pergunta para dois membros da equipe como o processo funciona, as respostas coincidem no essencial
Se qualquer um desses pontos faltar, a automação vai resolver parte do problema e criar outros.
O Sebrae aponta que 66% das micro e pequenas empresas brasileiras ainda estão na fase inicial do processo de digitalização, com apenas 3% consideradas líderes em suas áreas. A maioria das PMEs está automatizando processos que ainda não foram nem documentados de forma confiável. A etapa de mapeamento não é burocracia. É o que separa uma automação que funciona de uma que cria problema novo todo mês.
Caso real: o que acontece quando essa etapa é pulada
O padrão que a Coffe&Code Labs observa em clientes de PME segue a mesma estrutura: empresa contrata ferramenta, fornecedor conduz levantamento de requisitos, sistema é implantado, empresa descobre que o que foi automatizado não era o gargalo real.
Em um caso descrito de forma anônima em publicações do setor, uma empresa de distribuição automatizou o processo de geração de pedidos para fornecedores. O sistema funcionava. O problema era que o processo de conferência de estoque, que alimentava os pedidos, era feito manualmente com defasagem de dois dias. A automação acelerou os pedidos. Os pedidos continuaram sendo feitos com base em dados de estoque desatualizados. A empresa passou a receber mercadoria que não precisava e a ter falta do que vendia mais.
A automação não criou o problema. O problema já existia. A automação tirou a lentidão que dava tempo para a equipe perceber o erro antes de o pedido sair.
Esse é o risco concreto de automatizar sem mapear: a ineficiência que existia tinha pelo menos uma função protetora. Quando você remove a ineficiência sem entender o processo, pode remover a proteção junto.
O que preparar antes da primeira reunião comercial
Antes de qualquer reunião com fornecedor de automação, reserve uma tarde para o protocolo descrito acima. Não precisa ser perfeito. Precisa ser feito pela sua equipe, sem o fornecedor presente.
O resultado mínimo que você precisa ter na mão antes de sentar numa reunião comercial: o fluxo real do processo em questão, com os tempos por etapa, as exceções conhecidas, os pontos de falha identificados, e as dependências de pessoa mapeadas.
Com isso em mãos, você consegue comparar o que o fornecedor está propondo automatizar com o que você sabe que precisa ser resolvido. Se a proposta cobre o gargalo real, avança. Se a proposta automatiza a parte visível e deixa o problema principal de fora, você sabe fazer a pergunta certa antes de assinar.
Faça essa pergunta para quem executa o processo principal da sua operação: o que acontece quando dá errado? Se a resposta for "a gente liga pro fulano", "a gente refaz tudo" ou "depende", o processo ainda não está pronto para ser automatizado. Qualquer ferramenta que entrar antes desse mapeamento vai acelerar o problema junto com o fluxo. A Coffe&Code Labs faz esse diagnóstico sem vínculo com ferramenta específica. Se quiser mapear antes de sentar com qualquer fornecedor, leia também quanto custa automatizar um processo na empresa ou fale com a gente.