Automatização de processos empresariais para PME

1. O que resolvemos exatamente

Estes são os cinco problemas que mais vezes nos colocam, tal como os conta quem os sofre:

• «A minha equipa passa metade da manhã a introduzir faturas de fornecedor no ERP.» Cada fornecedor envia o seu PDF com um formato diferente, alguém abre, escreve os campos e arquiva o documento. É o processo que consome mais horas e o mais fácil de medir.
• «O correio entra sem classificação e escapam-nos coisas.» Encomendas, incidentes, orçamentos e publicidade na mesma caixa, distribuídos à mão todas as manhãs e com a resposta a depender de quem está nesse dia.
• «Fechar o relatório do mês custa-nos três dias.» Dados exportados de três sítios, colados numa folha de cálculo e formatados à mão, todos os meses igual, com o risco de erro que isso tem.
• «Cada pessoa preenche a folha de obra à sua maneira.» Informação que chega em papel, em fotografia ou numa mensagem, e que alguém tem de interpretar e lançar antes de se poder faturar.
• «Os mesmos dados estão em quatro aplicações e ninguém sabe qual é o bom.» Copiar e colar entre o ERP, o CRM e as folhas de cálculo da equipa, com as divergências a aparecerem exatamente quando é preciso decidir algo.

Todos têm a mesma forma: informação que chega sem estrutura, uma pessoa que a interpreta e um sistema que espera o dado já limpo.

2. Como funciona

Não existe uma plataforma mágica que faça isto. Existe um fluxo construído à medida sobre quatro peças, e convém saber o que cada uma faz antes de contratar nada:

• Captura. O sistema recolhe a entrada onde ela já está: uma caixa de correio, uma pasta partilhada, um formulário, uma pasta do ERP. Não se pede à equipa que mude por onde lhe chegam as coisas.
• Interpretação. Um modelo de linguagem lê a entrada não estruturada e devolve campos concretos: número de fatura, base tributável, fornecedor, tipo de incidente, urgência. Quando o documento é uma imagem ou uma digitalização, passa antes por reconhecimento ótico de caracteres.
• Regras e execução. Com o dado já estruturado, a consequência é executada por regras deterministas: criar o lançamento, abrir o pedido de assistência, avisar o responsável, mover o ficheiro. Aqui a IA não intervém de propósito — as regras são mais baratas, mais rápidas e perfeitamente previsíveis.
• Integração e registo. A ligação ao seu ERP ou CRM faz-se por API, por base de dados ou por troca de ficheiros, segundo o que o sistema permitir. Tudo o que o fluxo decide fica registado: o que entrou, o que interpretou, com que confiança e o que fez depois.

Com que o construímos

Quando o processo arranca por um disparador —chega um email, é carregado um ficheiro, alguém preenche um formulário—, a orquestração pode ser montada recorrendo a plataformas como Power Automate, n8n, Make ou Trigger.dev, segundo onde vive o processo e que licenças já tem. Se a sua empresa está no Microsoft 365, o Power Automate costuma sair gratuito na prática.

Quando não há disparador e o que é preciso é que algo aconteça à sua hora —consolidar o do dia anterior, verificar uma caixa de correio a cada quinze minutos, fechar o mês—, resolvemo-lo com tarefas programadas que acordam uma função própria. É mais barato de manter do que uma ferramenta visual, não depende da licença de ninguém e deixa o registo de execuções do seu lado. É o caminho pelo qual estamos a substituir parte do que antes montávamos sobre ferramentas de fluxo.

O que não encaixa em nenhuma das duas desenvolvemos em C#, JavaScript ou Python. A escolha não é ideológica: manda com que se dá melhor o seu sistema e quem o vai manter depois.

Sobre os ERP, uma precisão que convém fazer cedo: não somos especialistas em nenhum ERP concreto e não o pretendemos. Já integrámos com os habituais do tecido industrial, mas o que sabemos fazer é falar com o que já tem —ler, escrever e sincronizar— não configurá-lo nem parametrizá-lo por dentro. Para isso existe o seu implementador, e trabalhamos com ele sem problema. Se alguém lhe prometer as duas coisas, pergunte-lhe pela segunda.

A peça que mais se esquece é a quinta: a fila de revisão. Cada caso leva um nível de confiança e os que ficam abaixo do limiar não se executam sozinhos, esperam por uma pessoa. Essa fila é o que permite subir o limiar com o tempo e o que evita descobrir um erro três meses depois.

Postos um ao lado do outro, a mudança vê-se melhor. Note que a entrada e o destino são os mesmos: o que se move é quem faz o trabalho intermédio.

Os dois percursos avançam ao mesmo tempo e na mesma escala temporal: o de cima ainda vai no segundo passo quando o de baixo já terminou e está à espera. As proporções são ilustrativas — o que sustentamos é que um demora bastante mais do que o outro, não quanto exatamente no seu caso.

3. Casos típicos por setor

Os nossos clientes estão hoje na indústria, em fabricação discreta e de processo: automóvel, alimentação e bebidas. É aí que temos o percurso e é de projetos reais que vêm os exemplos.

Os outros quatro são padrões, não casos publicados. Os processos administrativos parecem-se muito mais entre setores do que parece de dentro de cada um —uma fatura de fornecedor lê-se igual numa fábrica e num escritório—, e por isso os incluímos: não nos limitamos a um único setor e não queremos aparentar que o fazemos.

Indústria: automóvel, alimentação e bebidas

Distribuição e logística

Serviços profissionais

Comércio e pós-venda

Administração e back office

4. O que precisa de ter antes de começar

Requisitos honestos. Se faltar algum, dizemo-lo no diagnóstico e não na fatura:

• Volume. O processo tem de repetir-se muitas vezes por mês. Abaixo de um certo número de casos, o projeto não se amortiza mesmo que funcione perfeitamente.
• Alguém que saiba como se faz de verdade. Não como o procedimento diz que se faz. Precisamos de algumas horas dessa pessoa no início, e é o investimento com mais retorno de todo o projeto.
• Acesso aos sistemas ou aos seus dados. Credenciais, API, exportações ou acesso à base de dados. Se um sistema estiver fechado, é preciso saber antes de prometer nada.
• Um critério de acerto verificável. Tem de existir uma forma de saber se a saída está correta. Se não existir, também não há forma de detetar quando o sistema começa a falhar.
• Tolerância ao erro com revisão humana. Nenhum sistema acerta cem por cento. O processo tem de admitir que uma percentagem de casos passe por uma pessoa.
• A medição do ponto de partida. Horas por mês, número de casos, taxa de erro e prazo atuais. Se não os tiver, medimo-los antes de tocar em nada: sem esse número, depois não há forma de demonstrar que o projeto serviu.

5. Quando NÃO é a solução

Dizer não a tempo poupa mais dinheiro do que a maioria dos projetos. Casos em que desaconselhamos automatizar:

• O processo está desorganizado. Se ninguém sabe quem é responsável por cada passo, ou cada pessoa o faz de forma diferente, primeiro é preciso redesenhá-lo. Automatizar um processo desorganizado só consegue que se engane mais depressa e em maior escala.
• As regras são claras e estáveis. Então basta a automatização clássica: mais barata, mais rápida e mais previsível. Meter um modelo de linguagem aí só soma custo e incerteza.
• O que incomoda é o volume pontual, não o recorrente. Um pico de trabalho duas vezes por ano resolve-se com reforço temporário, não com um projeto.
• O erro não é tolerável. Em passos onde errar tem consequências graves e irreversíveis, o sistema pode propor, mas a decisão fica numa pessoa.
• O processo está a ponto de mudar. Se há uma migração de ERP ou uma alteração regulamentar em cima da mesa, convém esperar: automatizar algo que vai desaparecer em três meses é atirar dinheiro fora.

6. Como se mede o retorno

Um projeto de automatização justifica-se com quatro métricas, todas comparadas com o ponto de partida:

• Horas libertadas por mês e o seu custo equivalente. É a poupança direta e a mais fácil de defender perante a direção.
• Taxa de erro antes e depois, e o custo de cada erro: reprocessamentos, notas de crédito, penalizações, perda de cliente.
• Prazo do processo de ponta a ponta. Muitas vezes vale mais do que a poupança de horas, porque desbloqueia faturação.
• Capacidade: quantos casos mais se podem absorver sem contratar ninguém.

Como referência do que vimos nos nossos próprios projetos: cerca de 20 horas por mês por colaborador nas tarefas que automatizamos, a primeira automatização em produção em 2-4 semanas e amortização abaixo dos seis meses no primeiro projeto. Não é uma promessa: o resultado depende do âmbito e do ponto de partida de cada empresa, e o número que importa é o que sai de medir o seu próprio processo. O método completo, fase a fase, está em como se mede o retorno do guia.

7. Se o processo trata dados pessoais

Quase todos o fazem: um email de cliente, uma fatura com nome e NIF ou uma folha de obra com o nome do operador já são dados pessoais. Isso não impede automatizar, mas muda o desenho.

Classificamos cada caso de uso por nível de risco segundo o Regulamento (UE) 2024/1689 antes de começar a desenvolver, e aplicamos as obrigações que correspondam juntamente com as do RGPD. A maioria dos processos administrativos internos fica no nível de transparência e não no de risco elevado; as exceções habituais são o recrutamento e a avaliação de trabalhadores, que entram em risco elevado e exigem bastante mais. Os dados não são usados para treinar modelos de terceiros e, quando é necessário, a solução é instalada na sua própria infraestrutura.

O calendário de aplicação e as obrigações concretas estão na página de conformidade em IA, que mantemos atualizada sempre que a norma muda.

8. Perguntas frequentes

Serviços que costumam acompanhar este: integração de sistemas · agentes de IA.