Toda proposta de automação de fluxos de trabalho com pouco código começa com a mesma coisa: velocidade. Construções mais rápidas, implantação mais rápida, tudo mais rápido.
É verdade que a velocidade ajuda, mas não é ela que decide se um fluxo de trabalho sobrevive ao primeiro ano. É a responsabilidade — especificamente, quem é responsável pela lógica associada e o que acontece quando essa pessoa sai da equipe, é promovida ou simplesmente tira duas semanas de férias. Um fluxo de trabalho que é executado rapidamente hoje e fica concentrado apenas na memória de uma pessoa não está automatizado. Ele é apenas rápido, não durável, o que é um problema.
Essa lacuna entre velocidade e durabilidade raramente aparece em uma demonstração de produto, o que é compreensível, pois não é exatamente um ponto de venda para nenhuma ferramenta. Na realidade, isso só vem à tona cerca de oito meses depois, quando a pessoa que criou o fluxo de trabalho está fora do escritório ou mudou de empresa, e o relatório alimentado por ele ainda precisa ser entregue na manhã de segunda-feira. Nesse ponto, ninguém está comemorando a rapidez com que ele foi criado originalmente.
Este artigo aborda cinco pontos em que a velocidade e a durabilidade seguem caminhos diferentes, começando pelo próprio argumento da velocidade.
Por que a velocidade não é o único motivo pelo qual o trabalho com pouco código é importante
A velocidade é um benefício real do pouco código, com certeza, mas se você a buscar como objetivo, tudo o que terá é uma planilha mais rápida, não uma automação durável de fluxo de trabalho.
As organizações estão apostando sério na velocidade, e os números do mercado confirmam isso. O Gartner projeta que o mercado de tecnologias de desenvolvimento com pouco código alcançará US$ 58,2 bilhões até 2029, crescendo 14,1% ao ano à medida que a IA baseada em agentes e o desenvolvimento cidadão estimulam a adoção. Mas isso não diz nada sobre se o que elas constroem se mantém.
E é aí que a diferença entre a adoção e a durabilidade realmente importa. Um fluxo de trabalho rápido de construir e fácil de repassar ganha mais valor a cada mês, pois outra pessoa além do criador original pode assumi-lo e continuar a aprimorá-lo. Um fluxo de trabalho que é apenas rápido de construir fica cada vez mais arriscado a cada mês, porque ninguém além do autor sabe realmente o que está acontecendo lá dentro. Confundir os dois é onde a maior parte do marketing com baixo código erra.
Por exemplo, um analista monta algo em uma tarde. Funciona e, silenciosamente, passa a sustentar a estrutura. Seis meses depois, ninguém mais consegue mexer nisso com segurança. É um padrão que aparece da mesma forma em todas as equipes de analytics, e você provavelmente já viu isso acontecer de perto.
Nenhum desses padrões é especificamente um problema de pouco código, mas a velocidade do pouco código facilita atingir esse estado mais rapidamente, com menos escrutínio ao longo do caminho do que um processo codificado manualmente jamais faria.
Imagine dois fluxos de trabalho criados na mesma semana, ambos solucionando o mesmo problema. O primeiro é desenvolvido rapidamente e continua exatamente tão rápido quanto no dia em que foi lançado, sem nenhuma documentação e sem nenhum responsável designado além de quem o escreveu, o equivalente em fluxo de trabalho de uma porta sem identificação que ninguém quer abrir. O segundo leva um pouco mais de tempo para ser concluído porque foi criado com uma estrutura documentada e um ponto de transferência claro.
Um ano depois, o primeiro fluxo de trabalho continua intocado, porque atualizá-lo parece arriscado. O segundo fluxo de trabalho foi ajustado quatro ou cinco vezes por pessoas diferentes, porque atualizá-lo parece seguro.
A velocidade de montagem dos dois fluxos de trabalho foi quase idêntica, mas o valor que cada um gerou ao longo de 12 meses não foi.
Sem código ou bom para código nunca foi uma escolha permanente
Uma correção manual se torna um passo com script. Um passo com script se torna uma peça compartilhada e reutilizável que outros fluxos de trabalho chamam. Essa progressão é o ciclo de vida real, embora a maioria dos conteúdos de fornecedores trate sem código versus bom para código como uma decisão única tomada no momento da compra.
Os compradores escolhem o baixo código em parte para evitar ficar presos a uma única maneira rígida de construir as coisas, mas fixar essa escolha no procurement pode dar errado de qualquer maneira. Exagere na abordagem sem código, e o primeiro caso limite que a interface não conseguir lidar é solucionado com uma solução alternativa acoplada fora da plataforma. Exagere na abordagem priorizando o código, e a equipe passa meses construindo o que uma tela governada teria lidado nativamente, para depois herdar toda a manutenção da qual o baixo código deveria poupá-los.
A melhor pergunta: um único fluxo de trabalho pode combinar um passo de arrastar e soltar com uma linha de SQL ou Python, sem a necessidade de reconstrução toda vez que os requisitos mudarem? Essa capacidade importa mais do que ser rotulado como "sem código" ou "bom para código", pois as necessidades de um fluxo de trabalho raramente permanecem fixas por muito tempo. Uma junção de arrastar e soltar que funciona perfeitamente no lançamento pode precisar de um passo de RegEx personalizado seis meses depois, após um sistema de origem começar a enviar um campo formatado de maneira diferente de antes.
Se a plataforma só faz arrastar e soltar, esse passo de RegEx é construído em outro lugar, em um script conhecido apenas por quem o gravou. O fluxo de trabalho ainda "funciona", mas a lógica que realmente importa escapou silenciosamente para fora do sistema destinado a controlá-la.
Existe algum fluxo de trabalho na sua equipe que está travado agora, especificamente porque aquela escolha de "ou um ou outro" foi feita cedo demais e ninguém a reavaliou desde então?
Bloquear o desenvolvimento cidadão inevitavelmente leva ao shadow IT
Eis o problema que você provavelmente vai enfrentar ao restringir o desenvolvimento cidadão para manter tudo sob controle — você geralmente terá mais IT paralela, não menos. Esse paradoxo acontece porque a demanda por automação não desaparece simplesmente quando você bloqueia o acesso; ela apenas se move para qualquer ferramenta mais fácil de pegar sem pedir permissão, o que raramente é a ferramenta que alguém teria escolhido de propósito.
A pesquisa da Forrester sobre desenvolvimento cidadão descobriu que pelo menos dois terços das organizações já têm uma estratégia formal de desenvolvedor cidadão ou planejam criar uma nos próximos 12 meses. A Forrester mapeou três maneiras de escalar isso de forma responsável:
- Privateer: uma pequena equipe autônoma integrada a uma unidade de negócio
- Democracia: um modelo amplamente aberto disponível para qualquer pessoa, com diretrizes definidas sobre o que ela pode criar
- Federação: um híbrido que combina os dois, com padrões centrais e construção distribuída
A melhor maneira de gerenciar o desenvolvimento por não especialistas é construir a estrutura de governança antes que a demanda a supere, em vez de correr atrás depois.
Mas, antes de criar essa estrutura, é preciso concordar sobre quem realmente está fazendo a criação. A pesquisa do MIT sobre desenvolvimento cidadão apresenta três funções separadas:
- Desenvolvedores cidadãos constroem aplicações.
- Automatizadores cidadãos configuram automações entre sistemas que não se comunicam nativamente.
- Cientistas de dados cidadãos criam os modelos e dashboards.
Cada uma dessas funções precisa de um tipo diferente de supervisão, e agrupá-las sob "desenvolvimento cidadão" apenas esconde essa distinção.
O objetivo não é ter menos pessoas criando fluxos de trabalho. É fazer com que elas construam dentro de um sistema que mantenha o trabalho visível e auditável. O self-service analytics é um ótimo exemplo dessa mesma ideia funcionando na prática: quando a TI deixou de tratá-lo como uma ameaça e passou a tratá-lo como algo para o qual projetar a usabilidade, a adesão decolou a partir daí.
Honestamente, a pergunta "Os analistas devem ter permissão para automatizar o próprio trabalho?" foi respondida há muito tempo, na primeira vez que alguém gravou uma macro só para economizar uma tarde de trabalho. Portanto, essa pergunta não é mais o assunto que o TI deveria estar discutindo.
A verdadeira conversa é sobre onde colocar as proteções; sobre quais fluxos de trabalho precisam de um responsável documentado e de um passo de revisão antes de afetarem um número financeiro; e quais têm um risco baixo o suficiente para que um automatizador cidadão possa simplesmente lançar sem esperar por um chamado. Pule essa conversa, e você não vai acabar com menos desenvolvimento cidadão. Você acaba com a mesma quantidade; só não consegue mais ver.
Um checklist para qualquer conversa com fornecedores de pouco código
Essas quatro perguntas funcionam bem em qualquer discussão com fornecedores, não importa qual plataforma você esteja avaliando:
- A lógica do fluxo de trabalho pode se mover ao longo do espectro do sem código ao bom para código sem acionar uma reconstrução?
- O desenvolvimento cidadão dentro da plataforma é governado e visível, ou simplesmente permitido e não monitorado?
- Os fluxos de trabalho são desenvolvidos como componentes reutilizáveis e documentados, ou como scripts pontuais que ninguém mais consegue abrir com segurança?
- A plataforma oferece suporte a iterações contínuas conforme os requisitos mudam ou apenas à implantação inicial?
O pouco código perde o sentido quando nada é reutilizado
O que limita uma implantação com pouco código quase sempre se resume à reutilização: o fluxo de trabalho foi construído para ser retomado ou para ser esquecido assim que funciona?
Como exemplo, veja como essa questão de reutilização normalmente se desenrola em uma equipe de procurement que concilia exceções de ordens de compra com faturas de fornecedores. Alguém da equipe geralmente acaba criando uma macro pessoal do Excel que sinaliza divergências por valor em dólares, e ela tende a funcionar bem o suficiente para que ninguém a questione por anos, o que no continuum espaço-tempo das macros de escritório é praticamente uma eternidade.
Esse tipo de macro costuma capturar a maioria dos tipos de exceção perfeitamente, digamos sete em cada nove, mas deixa passar qualquer caso de borda para o qual ninguém pensou em programar, como incompatibilidades na formatação dos números de pedido de compra entre o sistema ERP e o PDF da fatura, uma particularidade específica de como determinados fornecedores formatam a documentação. Lacunas como essa são exatamente o tipo de coisa que aciona uma constatação de auditoria da SOX.
Se você já herdou a planilha de outra pessoa, este caso vai parecer familiar. O analista que normalmente supervisiona a planilha fica ausente, e o acúmulo de exceções cresce silenciosamente por algumas semanas antes que alguém perceba, porque ninguém mais na equipe sabia que a macro existia, muito menos como abri-la.
Geralmente, essa falha é o que finalmente leva uma equipe a reconstruir a lógica de correspondência de forma adequada, como um componente de fluxo de trabalho documentado e reutilizável, com o próprio agendamento e acionador, incluindo qualquer caso limite que a macro original tenha deixado passar.
Nada disso tem a ver com criar com mais rapidez. O objetivo é criar algo que não dependa de uma única pessoa se lembrar de que isso existe, o que é tão importante para um profissional de finanças ou auditoria quanto para a equipe.
Confira um exemplo de um componente reutilizável, neste caso uma macro, que foi criado no Alteryx:
| Antes: macro pessoal | Depois: componente reutilizável | |
|---|---|---|
| Responsável | Um analista, não documentado | Compartilhado, documentado, aberto para a equipe |
| Cobertura de exceções | 7 de 9 tipos | Todos os 9, incluindo a incompatibilidade no número do pedido de compra |
| Hora de reconciliar | Passe manual de vários dias | Lista de exceções do mesmo dia |
| Reutilizar em várias categorias | Nenhum; reconstruído do zero a cada vez | Reutilizado em duas outras categorias de gastos, sem reconstrução |
Se isso parece com a situação da sua equipe, vale a pena testar a resistência do estado atual do seu fluxo de trabalho antes de escolher um fornecedor. Mude das planilhas para os fluxos de trabalho mostra como é, na prática, essa transição de planilhas de proprietário único para fluxos de trabalho reutilizáveis e documentados.
A automação não termina na implantação
Um fluxo de trabalho automatizado uma única vez e nunca revisado se degrada da mesma forma que uma planilha sem manutenção, só que de maneira menos visível. Isso pega você de surpresa mais tarde, geralmente como um achado de auditoria ou um número que discretamente deixou de corresponder à realidade.
A ideia de componentes reutilizáveis do exemplo de procurement se paga novamente bem aqui. Atualize o componente de correspondência compartilhado uma única vez — digamos, se um fornecedor mudar ou um limite se alterar —, e todo fluxo de trabalho criado com base nele é atualizado automaticamente. Ninguém precisa procurar uma dúzia de cópias e corrigi-las uma a uma, porque, para começar, só existe uma cópia.
Assistentes de IA em idioma natural também estão surgindo aqui, e é importante entender o que eles realmente fazem. O Ask Alteryx é um bom exemplo. Ele ajuda a equipe a consultar ou atualizar um fluxo de trabalho governado existente em linguagem simples, mas não substitui a estrutura governada associada. Pense nele como o assistente, não o arquiteto — duas funções diferentes, que valem a pena manter bem distintas ao avaliar qualquer ferramenta.
O checklist, testado com o Alteryx One
Veja como o Alteryx se compara à avaliação de fornecedores de que falamos antes.
| Pergunta | Como o Alteryx One atende |
|---|---|
| A lógica pode se mover pelo espectro de sem código a bom para código sem uma reconstrução? | Fluxos de trabalho combinam passos de arrastar e soltar com Python e SQL nativos na mesma tela, para que a equipe não fique presa a apenas um lado do espectro no procurement. |
| O desenvolvimento cidadão é governado e visível, e não apenas permitido? | Acesso baseado em funções e histórico de versões dão à TI a visibilidade para que analistas construam sem perder o controle sobre o que foi criado. |
| Os fluxos de trabalho são componentes reutilizáveis ou scripts pontuais? | Macros e aplicativos analíticos são criados uma única vez como componentes documentados e compartilháveis, o mesmo padrão que transformou o processo de reconciliação da equipe de procurement em uma infraestrutura compartilhada. |
| A plataforma comporta a iteração contínua, não apenas à implantação inicial? | O Copilot ajuda as equipes a consultar e atualizar fluxos de trabalho existentes em linguagem natural, além da estrutura governada já existente. |
Introdução à automação de fluxos de trabalho com pouco código
Se você ainda está avaliando os detalhes, a automação de fluxos de trabalho recorrentes de analistas e uma estrutura de avaliação formal aprofundam partes desse argumento mais do que este artigo pode cobrir.
Mas você não precisa ler tudo isso nem adotar uma plataforma inteira, antes de começar. Escolha um relatório recorrente ou um processo de reconciliação manual, do tipo que provavelmente ainda está na planilha pessoal de alguém, e reconstrua apenas essa parte como um componente governado e reutilizável. Veja como funciona antes de decidir se vale a pena migrar o resto do catálogo.
A conclusão é que a automação de fluxo de trabalho com pouco código vale a pena pela propriedade e durabilidade, e não apenas pela velocidade da primeira construção. O Alteryx One foi criado exatamente com isso em mente, e uma avaliação gratuita é a maneira mais rápida de descobrir se ele resiste ao teste com o seu próprio fluxo de trabalho.