Artigos · · 6 min de leitura
Quando o Zapier, o Make ou o n8n ficam pequenos?
Em três momentos: quando um fluxo decide o que só a sua empresa pode decidir, quando pode falhar sem ninguém ver e quando os fluxos dependem entre si.
Três momentos, e nenhum deles é o que as pessoas esperam. Quando um fluxo precisa fazer um julgamento que só a sua empresa pode fazer. Quando um fluxo pode falhar sem que ninguém descubra. Quando os fluxos passam a depender uns dos outros. Até que um desses momentos chegue, essas ferramentas são a resposta certa, e vamos dizer isso e ir embora.
Vale dizer essa última parte primeiro, porque o conselho que você costuma receber sobre essa questão vem de alguém que tem algo maior para vender. A maioria das empresas que rodam um punhado de fluxos deve continuar rodando esses fluxos.
Em que essas ferramentas são boas de verdade?
Em levar informação entre aplicativos que nunca foram feitos para conversar entre si. Esse é um problema real, e elas o resolvem bem. Um gatilho, alguns passos, um destino: um pedido novo gera uma linha, um anexo se arquiva sozinho, um formulário preenche uma planilha, alguém é avisado. Qualquer pessoa do seu escritório que se dê bem com planilhas consegue montar um fluxo desses, sem desenvolvedor, sem projeto e sem pedir permissão.
Elas também fazem uma coisa pela qual ninguém lhes dá crédito. Cada fluxo na sua conta foi montado por uma pessoa que sentia um custo específico todos os dias e descreveu exatamente o que deveria acontecer no lugar. Isso descreve o que a sua empresa precisa melhor do que qualquer consultor conseguiria fazendo perguntas, e vamos voltar a isso no final.
Quando um fluxo precisa saber algo que só você sabe?
Este é o primeiro limite, e ele chega sem fazer barulho.
“Lance este pedido no sistema de faturamento” é um problema de transporte. Essas ferramentas foram feitas para isso. “Lance este pedido no sistema de faturamento, a menos que o cliente esteja com o crédito bloqueado, e, se faltar o item, tire-o do depósito que puder enviar mais rápido” é um problema de julgamento. Ele precisa das suas regras de crédito, das suas posições de estoque e da sua geografia de expedição, e nada disso está no pedido.
Dá para forçar, e as pessoas forçam. Uma tabela de consulta numa planilha. Três ramificações de filtro. Um segundo fluxo que roda antes e grava uma marcação que o primeiro lê. Funciona, por um tempo. O que aconteceu é que uma parte da lógica do seu negócio agora mora num quadro visual onde ninguém consegue lê-la como uma frase, ninguém consegue testá-la antes de mudá-la e ninguém consegue explicar por que ela decidiu o que decidiu na terça-feira passada.
Um teste que você pode fazer hoje: pegue o seu fluxo mais importante e peça a alguém que não o montou para explicar em voz alta o que ele faz e por quê. Se a pessoa não conseguir, a regra não está escrita em lugar nenhum da sua empresa. Ela existe só como caixas e setas, numa conta, na cabeça de uma pessoa.
Como você saberia se um fluxo parou?
O segundo limite, e o que sai caro.
Essas ferramentas falham em silêncio, e isso não é um defeito delas. Uma execução dá erro, o erro é registrado, talvez um e-mail caia na caixa de entrada de quem montou o fluxo. A empresa segue em frente, sem saber. O pedido que nunca chegou ao faturamento não é descoberto como um erro; é descoberto como uma nota fiscal que falta, ou como um cliente perguntando onde está a mercadoria.
Então faça duas perguntas sobre o fluxo de que você mais depende. Quem perceberia se ele parasse hoje à noite? E como perceberia? Se a resposta honesta à segunda for “o cliente ia ligar”, você não tem uma automação. Você tem uma dependência não declarada.
O que resolve isso não é uma ferramenta mais esperta. É um hábito, e é engenharia comum: uma falha chega a uma pessoa nomeada no mesmo dia, levando o que falhou, o que estava sendo processado e o que fazer a respeito, e o que falhou fica numa fila que alguém pode reprocessar quando a causa for corrigida. Nada glamoroso, e é toda a diferença entre uma automação sobre a qual se pode tocar uma empresa e uma automação de que você fica sabendo por um cliente.
Quando o vigésimo fluxo vira o problema?
O terceiro limite é a dependência, e é ele que decide a maioria dos casos.
Um fluxo é uma ferramenta. Vinte fluxos são um sistema que ninguém projetou. O décimo nono grava uma linha que o vigésimo lê. Alguém renomeia uma coluna numa planilha e alguma coisa para três fluxos adiante, por motivos que levam um dia para descobrir. Não existe uma lista do que roda onde, nenhum jeito de testar uma mudança antes num lugar seguro e nenhum registro de por que qualquer parte daquilo foi montada do jeito que foi. Muitas vezes, a pessoa que montou os mais importantes já mudou de emprego.
Repare no que não está acontecendo aqui. Nada está quebrado. Cada fluxo ainda faz exatamente o que foi montado para fazer. O que se perdeu foi a capacidade de qualquer pessoa mudar qualquer coisa com segurança, e é isso que “ficar pequeno” quer dizer de verdade. Não é a ferramenta que encolheu. É a sua dependência dela que passou à frente do seu entendimento dela.
E quanto custa?
Vale falar disso com clareza, porque costuma ser o que finalmente leva o dono a fazer a pergunta, embora raramente seja o melhor motivo para agir.
Essas ferramentas cobram pelo quanto fazem. Cada execução, cada passo, contado e cobrado. Ou seja, a conta cresce na proporção exata de quão bem a automação está funcionando, e o mês em que você finalmente faz toda a mesa de pedidos passar por ela é o mês em que a assinatura começa a doer. É um incentivo estranho para ter por baixo de algo de que a sua empresa depende, seja qual for o número que vem com ele.
Então você joga tudo fora?
Não, e a resposta é a mesma de substituir ou conectar o software que você usa: a questão nunca é a ferramenta, e sim quais fluxos são reprovados em qual teste.
Pegue a lista do que você montou. Para cada item, três perguntas. Ele faz um julgamento que só a sua empresa pode fazer? Alguém saberia se ele parasse? Alguma outra coisa depende dele? Os fluxos que não são reprovados em nenhuma das três ficam exatamente onde estão, e a maioria vai ficar. Os que são reprovados em uma ou mais são a sua especificação: são esses que devem virar um sistema seu, monitorado, testado e escrito em algo que uma pessoa consiga ler.
A maioria das empresas para as quais essas ferramentas realmente ficaram pequenas chegou a esse ponto em três ou quatro lugares, e não em tudo. Quem disser o contrário tem uma plataforma para vender a você.
O que você deve guardar do que montou?
Mais do que você imagina, e é a parte que mais se joga fora.
Cada fluxo naquela conta é uma demanda documentada. Uma pessoa real, arcando com um custo real, descrevendo com precisão o que deveria acontecer no lugar, e se importando o bastante para montar. Isso vale mais do que a mesma resposta dada numa reunião, porque foi construído, e não pedido. Ninguém monta um fluxo para um problema que não tem.
Então, quando o trabalho muda de lugar, os fluxos vão junto como evidência, e não como entulho: o que foi automatizado, por quem, em que ordem de dor. É o documento de requisitos mais honesto que a sua empresa tem, e não custou nada para ser produzido.
O fabricante de móveis mostra como é o outro lado disso. Cada etapa de um pedido confirmada no celular pela pessoa que a faz, todos os pedidos no painel do dono, nada redigitado entre o orçamento e a expedição. Nada disso está além do que uma ferramenta no-code consegue tentar. Tudo isso está além do que se pode confiar a uma delas.
Então: não quando alguém diz que a ferramenta é pouco profissional, nem quando você chega a um certo tamanho. Quando um fluxo faz um julgamento que ninguém consegue ler, quando uma falha chega a você por um cliente e quando ninguém tem coragem de mexer no décimo nono fluxo. São três perguntas sobre sistemas que você já tem, e as respostas apontam o punhado que vale a pena mudar de lugar. Todo o resto fica onde está, e é assim que definimos o escopo de um trabalho de IA e automação desde o início.