Projask Automação Falar com um especialistaFalar agora

Quanto custa automatizar um processo: o que determina o custo e como saber se vale a pena

Não existe preço de tabela para automação: o custo de um projeto é determinado por quantos sistemas entram, que caminho de integração cada um oferece, quantas exceções o processo esconde e quanta manutenção ele vai exigir depois — e só faz sentido comparar esse custo com o que o processo manual já custa hoje.

Quem pergunta quanto custa automatizar um processo quase sempre quer um número único, e quem responde com um número único antes de olhar os sistemas está chutando. O preço de um projeto de automação não sai de tabela: é montado a partir de fatores que variam caso a caso. E o número isolado decide pouco, porque a escolha não é entre gastar e não gastar — é entre dois custos que já existem.

Este texto faz duas coisas: entrega o método para você calcular o custo do processo que já roda na sua operação e destrincha, um a um, os fatores que movem o preço de um projeto. Nenhum valor da Projask aparece aqui — os números da conta são os seus.

Antes do preço: quanto o processo manual já custa hoje

O custo do processo manual é o número que dá sentido a qualquer orçamento, e ele está ao seu alcance sem depender de fornecedor. São quatro variáveis, na ordem em que dá para levantar:

  1. Frequência. Quantas vezes o processo roda por mês. Conte execuções, não dias de trabalho.
  2. Tempo de trabalho por execução. Some o tempo efetivo de todas as pessoas que encostam no processo, inclusive os dois minutos de quem só aprova.
  3. Tempo de ciclo. Quanto leva do começo ao fim, incluindo as esperas. Esse número mede prazo, não dinheiro — e por isso fica fora da multiplicação.
  4. Custo da hora dessas pessoas. O custo real para a empresa: salário bruto mais encargos e benefícios, dividido pelas horas efetivamente trabalhadas no mês. Não é o salário líquido.

A variável medida errado costuma ser a segunda. Tempo de trabalho não é tempo de digitação: inclui procurar a informação que falta, conferir o que foi preenchido e cobrar quem não respondeu. Digitar é quase sempre a menor parte.

Já a espera — o arquivo que não chegou, a resposta que não veio — pertence ao tempo de ciclo, e não ao custo em dinheiro: ninguém fica parado olhando a caixa de entrada enquanto espera. Multiplicar a espera pelo custo da hora infla o número e derruba a credibilidade dele na primeira pergunta de quem estiver do outro lado da mesa. A espera entra na decisão por outro caminho: prazo perdido, cliente aguardando resposta.

E não estime de memória. Cronometre duas ou três execuções reais. A estimativa de memória tende a ficar abaixo do real, porque o que se lembra é o tempo em que se estava fazendo algo, não o tempo espalhado em idas e voltas.

A parte da conta que quase ninguém soma: erro e retrabalho

Processo manual não custa só o tempo que consome. Custa também o que produz errado. Redigitação entre sistemas gera erro de digitação, e a correção costuma sair mais cara que a digitação original, porque envolve três etapas que a digitação não tem: alguém descobrir o erro, alguém avisar quem precisa saber e alguém refazer — normalmente em dois sistemas.

Dá para levantar isso sem estatística nenhuma. Durante um mês, anote quantas vezes alguém teve que corrigir algo naquele processo. Na prática, a operação já sabe de cor quais são os casos; o que falta é o registro.

Quando existirem, entram na conta também os custos indiretos: pagamento feito em duplicidade, prazo perdido, cliente esperando resposta, relatório desatualizado que alguém usou para decidir alguma coisa.

Vale separar dois conceitos que costumam ser tratados como um só. Erro é engano — alguém digitou 1.200 onde era 12.000. Exceção é um caso legítimo que foge da regra — aquele cliente que é faturado de outro jeito. Erro é custo do processo manual; exceção vai reaparecer daqui a pouco como um dos fatores que mais encarecem o projeto.

Uma observação honesta: parte desses custos não é mensurável em dinheiro, e forçar um número só serve para enfraquecer a conta. Registre como fato qualitativo da decisão e siga.

Quanto custa automatizar um processo: os fatores que movem o preço

Com o custo do lado manual na mão, dá para olhar o outro lado. Estes são os fatores que realmente movem o preço de um projeto — e que permitem prever, antes de qualquer orçamento, se o seu caso é simples ou caro.

  1. Quantos sistemas estão envolvidos. Automatizar dentro de um sistema é um problema. Entre dois é outro. Entre quatro, a complexidade não cresce em linha reta: cada par que precisa conversar é mais um mapeamento de campos para fazer e mais um caminho para testar.
  2. Quantas etapas o processo tem, e quantas delas exigem decisão humana. Etapa que só transporta dado é barata. Etapa em que alguém olha e decide precisa de tela para a pessoa ver, de fila para o que está pendente e de registro de quem decidiu o quê e quando.
  3. Quantas exceções não documentadas o processo tem. É o fator que mais estoura orçamento, justamente porque ninguém as menciona no começo. Elas aparecem no meio do projeto, em frases do tipo "quando o cliente é daquele estado a gente faz diferente" ou "quando o pedido é urgente, pula a aprovação".
  4. Se a entrada é estruturada ou exige interpretação. Dado que já chega em campo é regra, e regra custa pouco. Documento com layout variável e texto livre exigem IA aplicada ao processo, o que traz custo por execução e, quase sempre, uma fila de revisão humana para os casos de baixa confiança.
  5. O que acontece quando dá errado. Definir quem é avisado, o que é reprocessado automaticamente e o que jamais pode ser executado duas vezes é trabalho de projeto, não detalhe de implementação. Pular isso é o que transforma automação em fonte de problema.

Os cinco pesam. Mas, na prática, costuma pesar mais do que qualquer um deles o caminho de integração que cada sistema oferece.

Por que a pergunta "esse sistema tem API?" define o preço

API é a porta oficial que um sistema oferece para outro sistema pedir e enviar dados sem passar por uma pessoa. Quando existe e é documentada, é o caminho mais barato de construir e o mais estável de manter. Quando não existe, o mesmo processo custa bem mais — e essa diferença não é visível de fora.

Caminho disponívelO que significaEfeito no esforço
API documentadaO sistema publica uma porta oficial para consultar e gravar dados, com documentação de como usá-la.Menor esforço de construção e de manutenção.
WebhookO sistema avisa sozinho quando algo acontece, em vez de você ficar perguntando de tempo em tempo. Costuma vir junto com a API, não no lugar dela.Reduz a consulta repetida e aproxima a reação do imediato, mas exige um endereço público para receber os avisos e tratamento para aviso repetido ou perdido.
Banco de dados ou arquivoAcesso direto à base, ou troca por CSV, XML e planilha depositada numa pasta.Funciona, mas custa mais em conferência e depende de o formato não mudar. Gravar direto na base de um sistema de terceiro passa por cima das validações dele: em geral só a leitura é defensável.
Só a tela (RPA)Nenhum dos anteriores: sobra um robô de RPA — automação que opera a interface clicando e digitando como um usuário faria.Maior esforço de construção e o mais frágil de manter: mudança de layout, de fluxo de login ou de mensagem de erro quebra o robô.

A consequência no orçamento é direta. Um processo com três sistemas em que dois têm API e um só permite automação de tela custa diferente do mesmo processo em que os três têm API. É o mesmo desenho, a mesma regra de negócio, e preços que não se parecem. Por isso nenhum orçamento sério sai antes de alguém olhar os sistemas envolvidos.

Esse ponto tem um artigo inteiro dedicado a ele: integração de sistemas.

Custo total: construção, homologação e manutenção

Construção é a parte visível, e é a única que a maioria dos orçamentos cobre: desenho do processo, desenvolvimento e testes.

Homologação é a fase em que a automação roda em paralelo com o processo manual até a operação confiar nos números. Custa tempo das pessoas e é a primeira coisa que alguém propõe cortar para economizar. Não corte: é justamente a homologação que revela as exceções que ninguém contou na reunião inicial — e descobrir exceção em homologação sai mais barato que descobrir em produção.

Manutenção é o custo que costuma ser omitido e que precisa estar no contrato. O sistema do outro lado muda de versão, renomeia um campo, altera a regra de autenticação, e a integração para de funcionar sem que ninguém do seu lado tenha mexido em nada. Isso não é defeito do projeto: é o ciclo de vida normal de qualquer integração em produção.

A pergunta certa para qualquer fornecedor, então, não é "tem garantia?". É: o que está incluído quando a quebra vem de mudança de terceiro, qual o prazo de resposta e como isso é cobrado.

Some ainda o monitoramento. Automação que falha em silêncio é pior que processo manual, porque o erro só aparece quando alguém sente falta do resultado — e aí o estrago já está distribuído. E some os custos recorrentes de infraestrutura e, quando há IA no caminho, o custo por execução: pequeno em volume baixo, relevante em volume alto.

Quando automatizar não se paga

Há casos em que a conta não fecha, e dizer isso faz parte do diagnóstico:

  • Processo raro e curto. Roda poucas vezes por mês e leva minutos. O custo de construir e manter não é recuperado; a melhor decisão pode ser simplificar o processo manual e parar por aí. A exceção é o processo raro cujo erro sai caro — um pagamento em duplicidade, um prazo regulatório perdido.
  • Regra instável. A política muda a cada poucos meses e ninguém consegue dizer qual será a regra no semestre que vem. Automatizar regra em movimento é pagar duas vezes pela mesma coisa.
  • Sistema em substituição. Se o ERP vai ser trocado, integrar com o atual é construir para descartar. Vale esperar, ou desenhar a automação na camada que sobrevive à troca.
  • Volume baixo com exceções demais. Quando quase toda execução é um caso especial, não existe caminho comum para automatizar. O processo precisa ser padronizado antes — e isso é trabalho de gestão, não de software.
  • Processo que ninguém consegue descrever. Se duas pessoas explicam o mesmo processo de formas diferentes, o problema ainda é de desenho. Software aplicado sobre confusão produz confusão mais rápida.

Descobrir que não vale a pena é um resultado legítimo de um diagnóstico — e sai bem mais barato do que descobrir isso com o projeto pronto.

Licença de plataforma ou solução sob medida

São dois modelos de custo com formatos diferentes, e nenhum é superior por natureza.

Plataforma cobra licença. O custo de entrada é menor e o prazo é curto para os casos que ela já prevê. Em compensação, existe um valor que se repete todo mês enquanto o processo existir. O que costuma escalar nessa cobrança é número de usuários, volume de execuções ou conectores adicionais — então projete o custo no volume futuro, não no de hoje.

O limite real da plataforma aparece na exceção. Ela resolve bem o que cabe no modelo dela; quando o processo tem um caso fora do padrão, restam duas saídas — acomodar o processo à ferramenta, ou pagar desenvolvimento por cima da licença mesmo assim.

Sob medida tem custo de construção maior no início e pode ser contratado sem licença recorrente pelo uso. O que foi construído atende exatamente o processo existente, exceções incluídas.

Duas coisas aqui dependem do contrato, não do modelo, e precisam estar escritas antes da assinatura: de quem fica o código e o que a manutenção cobre. Quando o código fica com a empresa, trocar de fornecedor é possível; na plataforma, parar de pagar é parar de operar.

O critério prático: processo comum, sem exceção relevante e sem sistema legado no caminho tende à plataforma. Processo que é o jeito específico daquela empresa trabalhar tende ao sob medida.

Como pedir um orçamento que signifique alguma coisa

Três coisas você levanta sozinho, antes de falar com qualquer fornecedor: o custo mensal calculado nas duas primeiras seções, a lista dos sistemas envolvidos e a lista das exceções que a operação já conhece. Com isso na mão, a conversa deixa de ser sobre preço e passa a ser sobre escopo.

E quatro perguntas valem para qualquer proposta: quais dos meus sistemas têm API; o que acontece quando um deles muda; o que está incluído na manutenção; quanto tempo de homologação está previsto. Desconfie de preço fechado dado antes de alguém olhar os sistemas — o caminho de integração disponível é o que mais move o custo, e ele não é visível de fora.

A posição da Projask é essa: diagnóstico do processo antes do código, escopo baseado no processo real e não no catálogo de uma ferramenta, e a disposição de dizer que não vale a pena quando não vale.

Se você já tem o processo em mente, o começo é um diagnóstico — descreva o processo pelo WhatsApp e a gente olha os sistemas envolvidos antes de falar em número. Se ainda está mapeando o terreno, comece por automação de processos.

Perguntas frequentes

Como eu calculo quanto o processo manual já me custa hoje?

Multiplique a frequência no mês pelas horas de trabalho somadas de todas as pessoas por execução e pelo custo da hora dessas pessoas. O custo da hora é o custo real para a empresa: salário bruto mais encargos e benefícios, dividido pelas horas efetivamente trabalhadas no mês.

O tempo de trabalho não é só o tempo de digitação — inclui procurar a informação que falta, conferir o que foi preenchido e cobrar quem não respondeu. Já o tempo de espera pertence ao tempo de ciclo e fica fora da multiplicação, porque ninguém fica parado enquanto espera; ele entra na decisão como indicador de prazo. Em vez de estimar de memória, cronometre duas ou três execuções reais, e some à conta o custo de erro e retrabalho.

O que faz um projeto de automação ficar mais caro ou mais barato?

Cinco fatores movem o preço: quantos sistemas estão envolvidos, quantas etapas exigem decisão humana, quantas exceções não documentadas o processo esconde, se a entrada é estruturada ou exige interpretação, e o que precisa acontecer quando algo dá errado.

Na prática, costuma pesar mais do que qualquer um deles o caminho de integração que cada sistema oferece. Quando existe API documentada, o esforço de construir e manter é o menor; quando só sobra automatizar a tela com um robô de RPA, o mesmo processo custa mais e fica mais frágil, porque qualquer mudança de layout ou de login quebra o robô. Por isso nenhum orçamento sério sai antes de alguém olhar os sistemas envolvidos.

Automação é um custo único ou tem manutenção depois?

O custo total tem três partes. Construção é a visível — desenho, desenvolvimento e testes. Homologação é a fase em que a automação roda em paralelo com o processo manual até a operação confiar nos números, e é ela que revela as exceções que ninguém contou na reunião inicial. Manutenção é o custo mais omitido: o sistema do outro lado muda de versão, renomeia um campo ou altera a autenticação, e a integração para de funcionar sem que ninguém do seu lado tenha mexido em nada.

Some ainda monitoramento, custos recorrentes de infraestrutura e, quando há IA no caminho, o custo por execução. A pergunta certa para o fornecedor não é se tem garantia, e sim o que está incluído quando a quebra vem de mudança de terceiro, qual o prazo de resposta e como isso é cobrado.

Vale a pena automatizar um processo que roda poucas vezes por mês?

Em geral não, quando ele também é curto: o custo de construir e manter não é recuperado, e a melhor decisão pode ser simplificar o processo manual e parar por aí. A exceção é o processo raro cujo erro sai caro — um pagamento em duplicidade, um prazo regulatório perdido.

Outros casos em que a conta não fecha: regra que muda a cada poucos meses, sistema que vai ser substituído, volume baixo com exceções demais (aí o processo precisa ser padronizado antes, e isso é trabalho de gestão) e processo que ninguém consegue descrever de forma consistente. Descobrir que não vale a pena é um resultado legítimo de diagnóstico, e sai mais barato do que descobrir com o projeto pronto.

É melhor pagar licença de uma plataforma ou mandar construir sob medida?

São dois modelos de custo com formatos diferentes, e nenhum é superior por natureza. A plataforma cobra licença: o custo de entrada é menor e o prazo é curto para os casos que ela já prevê, mas existe um valor que se repete todo mês enquanto o processo existir. O que costuma escalar nessa cobrança é número de usuários, volume de execuções ou conectores adicionais — por isso vale projetar o custo no volume futuro, não no de hoje.

O limite real da plataforma aparece na exceção. Ela resolve bem o que cabe no modelo dela; quando o processo tem um caso fora do padrão, restam acomodar o processo à ferramenta ou pagar desenvolvimento por cima da plataforma.