Como automatizar a empresa sem trocar todos os sistemas
Um manual para reduzir retrabalho conectando o que sua empresa já usa, com fonte de verdade, responsáveis, métricas e limites de segurança.
Por Cesar A. Machado · · 15 min
- Escolha um processo com volume, regra estável e responsável claramente definido.
- Declare a fonte de verdade antes de conectar CRM, ERP, planilhas ou atendimento.
- Separe leitura, sugestão e escrita; cada nível exige controles diferentes.
- Meça tempo, erro, exceção e custo operacional antes de ampliar o piloto.
- Interrompa a automação quando o risco ou a ambiguidade superar o ganho comprovado.
A resposta curta: conecte o fluxo, não substitua a empresa
Sim, é possível automatizar uma empresa de 20 a 100 funcionários sem trocar ERP, CRM, sistema financeiro e canais de atendimento ao mesmo tempo. O caminho mais seguro é escolher um fluxo repetitivo, declarar de onde cada dado vem, conectar sistemas por uma interface documentada e manter uma pessoa responsável pelas exceções. A automação deve reduzir uma passagem manual específica; não deve esconder um processo mal definido atrás de uma ferramenta nova.
Comece por uma operação cujo resultado possa ser conferido em poucos dias: receber um pedido, validar campos, criar uma tarefa comercial ou avisar o financeiro. Deixe para depois decisões que envolvem crédito, contratação, demissão, saúde, dados sensíveis ou pagamentos irreversíveis. O primeiro objetivo não é provar que a tecnologia é inteligente; é provar que a empresa consegue executar uma rotina com menos retrabalho, sem perder rastreabilidade.
A pesquisa TIC Empresas 2024, do Cetic.br, encontrou automação de processos e fluxos de trabalho entre os usos de IA declarados pelas empresas que utilizavam IA. Isso descreve adoção observada, não garante economia para uma empresa específica. Para o gestor, a consequência prática é testar a rotina real: volume, qualidade dos dados, filas, exceções e tempo de supervisão.
Antes da ferramenta: desenhe o trabalho que hoje atravessa sistemas
O ponto de partida é uma entrevista curta com quem executa o trabalho, não uma demonstração de fornecedor. Escolha uma rotina que cruza pelo menos duas áreas e reconstrua os últimos dez casos. Registre a entrada, cada decisão, o sistema consultado, o campo alterado, a pessoa que aprovou, a saída e o tempo parado. Diferencie espera de execução: muitas horas atribuídas ao sistema são, na verdade, falta de informação, aprovação ou prioridade.
O responsável pelo processo deve escrever a regra em linguagem verificável. “Enviar para vendas quando o cliente demonstrar interesse” é vago. “Criar tarefa para a equipe comercial quando houver CNPJ válido, produto escolhido e consentimento registrado” permite teste. Se a regra muda a cada caso, a automação pode apenas organizar a triagem e pedir decisão humana. A variabilidade não é defeito do sistema; é um sinal de que o desenho ainda precisa de política.
| Elemento | Pergunta de diagnóstico | Evidência mínima |
|---|---|---|
| Gatilho | O que inicia o fluxo? | Evento ou registro identificável |
| Entrada | Quais campos são obrigatórios? | Lista de campos e origem |
| Regra | Qual condição produz qual ação? | Exemplos aprovados e rejeitados |
| Responsável | Quem responde pelo resultado? | Nome da função, não só da ferramenta |
| Saída | Onde o resultado deve aparecer? | Registro criado, atualizado ou comunicado |
| Exceção | Quando a máquina deve parar? | Fila, alerta e prazo de tratamento |
Faça também um inventário de permissões e dados pessoais. Nome, e-mail, telefone, CPF, histórico de atendimento e dados de funcionários não devem circular só porque uma integração torna isso tecnicamente fácil. O mapa precisa dizer quais campos são necessários para a finalidade, quem pode visualizá-los, por quanto tempo ficam retidos e qual fornecedor os processa. A ANPD orienta agentes de pequeno porte a adotar medidas administrativas e técnicas essenciais, proporcionais ao risco e à realidade da organização.
A decisão precisa ser assinada pelo dono do processo e registrada com a data, a versão da regra e o período observado. Sem esse registro, o piloto não produz aprendizado confiável nem oferece base para comparar a próxima mudança.
Fonte de verdade e contrato: o que pode ser sincronizado
“Fonte de verdade” não significa que um sistema é melhor em tudo. Significa que, para um atributo e uma decisão, existe um lugar oficial que vence conflitos. O ERP pode ser a referência para contas a receber; o CRM, para etapa comercial; o sistema de atendimento, para histórico de conversas. Uma planilha pode ser uma entrada temporária, mas não deve virar autoridade silenciosa sobre preço, estoque ou limite de crédito.
Documente o contrato de cada integração: identificador do registro, campos enviados, campos recebidos, formato, unidade, data e hora, frequência, permissões, tratamento de ausência e política de atualização. Combine ainda o que significa “sucesso”. Uma chamada HTTP aceita não prova que o negócio foi concluído; o destino precisa devolver um identificador ou estado verificável. Guarde a referência entre os sistemas para investigação e reconciliação.
APIs são preferíveis quando o fornecedor as documenta, versiona e monitora. Exportações agendadas podem ser adequadas para relatórios ou cargas não urgentes, desde que tenham controle de versão, validação e reconciliação. Capturar dados pela tela, usar credenciais compartilhadas ou depender de uma planilha aberta no computador de alguém reduz a previsibilidade e aumenta o custo de suporte. O portal Governo Digital descreve interoperabilidade como a capacidade de sistemas trabalharem em conjunto para trocar informações de maneira eficaz; para uma empresa, isso começa por contratos claros, não por quantidade de conectores.
Defina a política de conflito: se o cliente muda o telefone no CRM e no atendimento, qual valor vence? Se a origem estiver indisponível, a integração espera, falha para uma fila ou usa o último valor conhecido? “Continuar mesmo assim” é uma decisão de negócio que pode propagar dado errado. Registre a escolha e teste um caso de atraso, um caso duplicado e um caso com campo obrigatório ausente.
Suba em camadas: leitura, sugestão e escrita controlada
A primeira camada é leitura: consultar um sistema e produzir uma visão para alguém. A segunda é sugestão: classificar, resumir, calcular prioridade ou preparar um rascunho, sempre com fonte e confiança visíveis. A terceira é escrita: criar ou alterar um registro. A quarta é efeito externo: disparar cobrança, cancelar pedido, alterar preço ou enviar comunicação em massa. Quanto mais irreversível o efeito, mais forte precisa ser a autorização, a validação e a capacidade de interromper.
Use código determinístico para validação, autorização, cálculo, transição de estado e efeitos críticos. Use IA, quando houver benefício real, para interpretar texto, extrair campos ou sugerir uma classificação. A saída da IA deve passar por um esquema validado; conteúdo incompleto, contraditório ou fora dos limites vai para revisão humana. Não permita que um modelo decida sozinho quem recebe desconto, qual funcionário é penalizado ou qual obrigação legal deixa de ser cumprida.
A idempotência é indispensável quando uma mesma mensagem pode ser reenviada. Gere uma chave estável para o evento e faça o destino reconhecer que aquele efeito já foi aplicado. A documentação da Stripe é uma referência técnica clara: requisições idempotentes permitem repetir uma chamada sem criar um segundo efeito quando a primeira resposta se perde. O princípio é aplicável a outros domínios, mas o contrato exato depende do sistema integrado; não copie uma implementação sem testar concorrência e falhas.
| Camada | Uso recomendado | Controle obrigatório |
|---|---|---|
| Leitura | Consulta e painel operacional | Permissão, atualização e fonte |
| Sugestão | Classificação ou rascunho | Revisão, evidência e registro da versão |
| Escrita | Criar ou atualizar registro | Idempotência, validação e auditoria |
| Efeito externo | Cobrar, cancelar ou notificar | Aprovação, limite e rollback operacional |
Para cada etapa, defina timeout, número limitado de tentativas e destino para falhas permanentes. Um worker não pode ficar repetindo indefinidamente uma operação que será recusada por dado inválido. Registre o identificador do processo, o tenant ou unidade responsável, o ator, o estado anterior, o novo estado, o tempo, o erro classificado e a versão da regra. Isso torna a automação explicável para a operação e para uma investigação posterior.
A documentação também deve registrar a decisão de não automatizar. Ela evita que uma pessoa retome, meses depois, a mesma ideia sem conhecer o risco que já foi identificado. Anote o processo avaliado, a hipótese, os dados observados, a causa do bloqueio e a condição que permitiria reabrir a análise. Pode ser falta de volume, regra instável, ausência de API, contrato inadequado, custo de supervisão ou impacto difícil de reverter. Essa memória operacional protege o orçamento e ajuda a direção a distinguir uma prioridade legítima de uma moda tecnológica.
Interrompa o projeto se a única forma de integração for compartilhar senha pessoal, copiar dados sensíveis para um serviço sem contrato ou desativar logs. Pare também quando o fornecedor não explicar onde os dados ficam, como são apagados, quais suboperadores participam ou como o acesso é revogado. Uma automação que economiza minutos e cria uma exposição que a empresa não consegue investigar é uma troca ruim, mesmo que a tela pareça eficiente.
Piloto hipotético: calcular o ganho sem vender uma promessa
Cenário hipotético — não é um caso real: uma distribuidora com 42 funcionários recebe pedidos por formulário, e-mail e WhatsApp. Uma pessoa confere campos e cria o pedido no ERP. A empresa quer automatizar apenas a triagem de pedidos completos, sem emitir nota, reservar estoque ou cobrar o cliente. Premissas do cálculo: 18 pedidos por dia útil, 22 dias úteis por mês, 7 minutos médios de conferência e cadastro por pedido, 70% dos pedidos com campos suficientes para seguir sem correção, 100% de conferência humana por duas semanas e custo interno de R$ 38 por hora. Esses números são hipóteses para ensinar o método, não uma estimativa para o leitor.
Fórmula: horas mensais atuais = pedidos por dia × dias úteis × minutos por pedido ÷ 60. Resultado hipotético: 18 × 22 × 7 ÷ 60 = 46,2 horas por mês. Horas potencialmente encaminhadas = 46,2 × 70% = 32,34 horas por mês. Valor bruto de tempo = 32,34 × R$ 38 = R$ 1.228,92 por mês. Esse valor não é lucro: exclui implementação, monitoramento, suporte, retrabalho, licenças, treinamento, indisponibilidade e o custo de revisar exceções.
O piloto só pode afirmar ganho depois de comparar uma linha de base com o fluxo automatizado. Meça por duas semanas antes e duas depois: tempo mediano até o pedido estar pronto, percentual de pedidos encaminhados sem correção, duplicidades, campos faltantes, horas de supervisão, falhas por indisponibilidade e casos enviados para a fila manual. Se a automação economizar 32 horas, mas exigir 28 horas de conferência e gerar pedidos duplicados, o resultado operacional pode ser negativo mesmo com uma demonstração bonita.
Critérios de avanço: nenhum efeito financeiro direto no piloto; erro de campo crítico igual a zero; duplicidade igual a zero; todas as falhas visíveis em uma fila; revisão humana capaz de corrigir o registro; e responsável disponível em horário definido. Critérios de interrupção: perda de rastreabilidade, vazamento ou exposição indevida de dados, divergência de fonte, repetição de efeitos, fila sem tratamento, erro acima do limite acordado ou tempo de supervisão maior que o trabalho manual substituído.
Operação diária: responsáveis, métricas e exceções
Uma automação sem dono vira um incidente sem responsável. O dono do processo decide a regra e aceita o resultado; a pessoa de tecnologia mantém conexão, credenciais, logs e mudanças; a operação trata exceções; segurança ou privacidade revisa o uso de dados; e a direção aprova risco, orçamento e limite de efeito. Em uma empresa menor, uma pessoa pode acumular funções, mas as decisões continuam precisando estar nomeadas.
Acompanhe um conjunto pequeno de métricas. Volume: quantos eventos chegaram e quantos terminaram. Qualidade: quantos foram concluídos sem correção, duplicidade ou dado ausente. Tempo: mediana e p95 do início ao fim. Exceção: quantos pararam, por qual motivo e por quanto tempo. Segurança: acessos negados, campos sensíveis enviados, credenciais próximas do vencimento e alterações de permissão. Custo: licenças, consumo, suporte e horas de supervisão.
Toda exceção deve ter estado persistente: recebida, validando, aguardando informação, concluída, cancelada ou falha permanente. A fila precisa guardar o motivo, a próxima ação, o responsável, o prazo e a referência dos sistemas envolvidos. Retry é apropriado para indisponibilidade transitória; não é solução para CPF inválido, regra ausente ou permissão negada. Quando o erro é permanente, retire o evento do ciclo automático e corrija a causa antes de reprocessar.
Faça uma reconciliação periódica: compare contagens e identificadores da origem e do destino, procure registros sem par, duplicidades e alterações fora do fluxo. Defina como pausar a automação e como operar manualmente durante a pausa. O procedimento deve caber em uma página: quem aciona, qual botão ou configuração muda, quais registros são preservados, como evitar dupla execução e quem comunica a área afetada.
A reunião semanal do fluxo deve durar o suficiente para responder três perguntas: o que falhou, o que ficou lento e qual exceção se repetiu. Não transforme o encontro em uma coleção de opiniões sobre a ferramenta. Use a fila e as métricas para escolher uma causa. Se muitos registros param por campo vazio, corrija o formulário ou a regra de entrada. Se a origem muda o formato sem aviso, trate versionamento e contrato. Se a equipe ignora alertas, reduza o ruído e defina uma prioridade. A melhoria precisa alterar uma etapa observável e ter responsável e prazo.
Para revisar um desenho de automação antes de colocá-lo em produção, envie o fluxo, os sistemas envolvidos e os critérios de parada em https://blog.cesarmachado.com/contato. A conversa deve começar pelo processo e pelas evidências, não pela escolha de uma plataforma. Se o risco estiver alto, a recomendação pode ser manter a operação manual, limitar a automação à leitura ou construir uma aprovação humana. Esse tipo de decisão é parte do método: reduzir escopo também é uma forma de entregar valor.
Segurança e LGPD: o atalho técnico não elimina responsabilidade
Conectar sistemas amplia a superfície de acesso. Antes do piloto, liste os dados pessoais tratados, finalidade, base ou justificativa aplicável, sistemas envolvidos, fornecedores, perfis de acesso, retenção e descarte. Minimize campos: para criar uma tarefa de retorno, talvez você precise do identificador e do canal, não de todo o histórico do cliente. Mascare dados em testes e nunca use uma base real em uma ferramenta sem avaliar contrato, localização, retenção e controles.
A LGPD se aplica ao tratamento de dados pessoais em meios físicos e digitais. A Resolução CD/ANPD nº 2/2022 prevê simplificações para agentes de pequeno porte, mas deixa claro que elas não dispensam o cumprimento dos demais dispositivos da LGPD. Portanto, tamanho não é autorização para compartilhar dados sem critério. A ANPD também publica guia específico de segurança para agentes de pequeno porte, útil como lista de controles administrativos e técnicos proporcionais ao risco.
Proteja credenciais com contas de serviço individuais, privilégio mínimo, rotação e revogação documentada. Separe desenvolvimento, homologação e produção. Registre quem acessou e alterou o fluxo. Defina prazo para comunicar e investigar incidente, preserve evidências e saiba qual fornecedor precisa ser acionado. O controle não precisa ser sofisticado para ser útil: precisa existir, ser testado e ter alguém responsável.
Roteiro de 30 dias e decisão de continuidade
Dias 1 a 5: escolha uma rotina, nomeie o dono, registre a linha de base e descreva dez casos reais anonimizados. Dias 6 a 10: defina fonte de verdade, campos mínimos, permissões, exceções, métricas e critérios de parada. Dias 11 a 15: construa leitura ou sugestão em ambiente de teste, com dados falsos e logs. Dias 16 a 22: rode em modo acompanhado, compare cada saída e corrija regras, não apenas mensagens. Dias 23 a 30: opere com limite de volume, faça reconciliação, registre incidentes e decida entre ampliar, ajustar ou encerrar.
A decisão não deve ser “gostamos da ferramenta”. Use quatro perguntas: o fluxo terminou com menos esforço total? A qualidade ficou igual ou melhor? As exceções são visíveis e tratáveis? O risco está dentro do limite aprovado? Se uma resposta for não, a recomendação é corrigir o desenho ou parar. Trocar de fornecedor pode ser necessário quando há falha de contrato, suporte ou segurança; trocar todos os sistemas só porque uma rotina não foi modelada costuma ser uma reação cara ao problema errado.
Se o fluxo aprovado for ampliado, versione a regra, registre a mudança, atualize o treinamento e revise permissões. A cada nova integração, repita o inventário de dados e a reconciliação. Se o volume crescer, observe filas e limites de API antes de aumentar tentativas. Se a natureza da decisão mudar de organização para decisão automática, faça uma nova avaliação; o risco não é constante só porque o conector é o mesmo.
| Decisão | Evidência necessária | Próximo passo |
|---|---|---|
| Ampliar | Ganho líquido e risco dentro do limite | Aumentar volume gradualmente |
| Ajustar | Falha localizada e causa conhecida | Corrigir regra ou entrada |
| Manter manual | Ambiguidade, risco ou supervisão excessiva | Registrar bloqueio e reavaliar |
| Encerrar | Sem ganho ou sem controle mínimo | Desligar, documentar e preservar dados |
Se você precisa escolher o primeiro processo, descreva o gatilho, o volume mensal, os sistemas envolvidos e a exceção que mais consome tempo em https://blog.cesarmachado.com/contato. Uma conversa curta pode ajudar a transformar uma ideia ampla em um piloto mensurável, incluindo a hipótese de não usar IA quando uma regra simples for mais segura.
O responsável deve publicar um pequeno relatório ao fim do piloto: volume processado, percentual de sucesso, exceções por causa, tempo de supervisão, incidentes, custo e recomendação. Inclua três amostras de entrada e saída, sempre anonimizadas, para que outra pessoa consiga reproduzir a conferência. Se o processo usa comunicação com cliente, revise também tom, consentimento, frequência e canal de retorno. A automação não deve dificultar o atendimento de uma pessoa nem impedir que um registro seja corrigido quando a informação original estiver errada.
O melhor resultado não é uma empresa que automatizou tudo. É uma operação em que cada fluxo tem dono, fonte, limite, evidência e saída manual. Quando isso existe, trocar um componente no futuro fica menos arriscado porque a empresa conhece o processo que está protegendo.
Fontes consultadas
Cetic.br/NIC.br, Pesquisa TIC Empresas 2024: https://cetic.br/pt/tics/pesquisa/2024/empresas/H9A/expandido/. Sustenta os dados sobre uso de IA por tipo, incluindo automatização de processos e fluxos de trabalho por porte.
Cetic.br/NIC.br, documentação e microdados da TIC Empresas 2024: https://www.cetic.br/pt/arquivos/pesquisa/2024/empresas/. Sustenta a descrição da pesquisa, tabelas, documentação metodológica e limites para interpretar percentuais.
ANPD, Guia Orientativo sobre Segurança da Informação para Agentes de Tratamento de Pequeno Porte: https://www.gov.br/anpd/pt-br/centrais-de-conteudo/materiais-educativos-e-publicacoes/guia_seguranca_da_informacao_para_atpps___defeso_eleitoral.pdf. Sustenta a recomendação de medidas administrativas e técnicas proporcionais ao risco.
ANPD, Resolução CD/ANPD nº 2/2022: https://www.gov.br/anpd/pt-br/acesso-a-informacao/institucional/atos-normativos/regulamentacoes_anpd/resolucao-cd-anpd-no-2-de-27-de-janeiro-de-2022. Sustenta os limites das flexibilizações para agentes de pequeno porte e a permanência das obrigações da LGPD.
Governo Federal, Lei nº 13.709/2018 — LGPD: https://www.gov.br/pt-br/lgpd/lei-no-13-709-18-lei-geral-de-protecao-de-dados-lgpd-1. Sustenta a aplicação da proteção de dados pessoais e a necessidade de tratar dados com finalidade e controles adequados.
Governo Digital, Interoperabilidade: https://www.gov.br/governodigital/pt-br/infraestrutura-nacional-de-dados/interoperabilidade. Sustenta a definição de interoperabilidade e a ideia de APIs documentadas como mecanismo de troca entre sistemas.
CGU, Gestão de Riscos: https://www.gov.br/cgu/pt-br/acesso-a-informacao/governanca/gestao-de-riscos/gestao-de-riscos. Sustenta o uso de procedimentos de controle proporcionais ao risco, mapeamento e melhoria contínua.
Stripe, Idempotent requests: https://docs.stripe.com/api/idempotent_requests?javascript=false&lang=node. Sustenta a explicação técnica de idempotência e o cuidado com repetição de requisições; a aplicação a outros sistemas exige validação do contrato próprio.
Automatizar sem trocar tudo é decidir qual informação atravessa cada fronteira, quem pode alterá-la e como a empresa volta atrás quando algo sai do esperado.
