Por que baixo código não substitui um sistema de processo administrativo

Uma ferramenta de baixo código genérica monta uma tela de formulário e um fluxo de aprovação em poucos dias — isso é real, e é sedutor para qualquer time de TI que precisa tirar demanda represada da fila. O que ela não resolve sozinha é o rito: a exigência de que toda decisão administrativa seja motivada, que todo prazo tenha um efeito jurídico definido para quando vence, e que toda etapa deixe rastro auditável para quem vier questionar depois. Confundir “fácil de montar” com “pronto para o setor público” é o tipo de erro que só aparece na auditoria, nunca na demonstração do fornecedor.

Baixo código resolve a tela, não resolve o rito

O ganho de uma plataforma genérica de baixo código é real e imediato: quem antes dependia de uma fila de desenvolvimento interna para digitalizar um pedido de férias, uma requisição de compra ou um encaminhamento entre setores passa a montar isso sozinho, arrastando campo e definindo aprovador. Para uma instituição pública que já acumulou dezenas de sistemas internos construídos ao longo dos anos, essa promessa de agilidade e autonomia é difícil de recusar — foi exatamente o argumento que levou uma prefeitura de médio porte, depois de manter mais de duzentos sistemas desenvolvidos internamente, a contratar uma ferramenta de baixo código só para padronizar os fluxos de requisição entre secretarias.

O problema aparece quando o fluxo deixa de ser genérico. Motivar um indeferimento com base no dispositivo legal aplicável, calcular um prazo cujo vencimento produz efeito automático — deferimento tácito, indeferimento por decurso, arquivamento por inércia —, ou preservar o histórico de quem decidiu o quê e quando, com a integridade que sustenta uma resposta ao Tribunal de Contas: nada disso nasce de um botão “aprovar/reprovar” arrastado numa tela. A Lei 9.784/1999, que rege o processo administrativo no âmbito federal e serve de referência subsidiária para municípios sem lei própria, elenca a motivação entre os princípios exigidos já no artigo 2º — e um sistema que não modela isso como conceito nativo não vai improvisar essa exigência na hora que o Ministério Público pedir explicação.

Cada exceção vira desenvolvimento sob demanda, não parametrização

O ganho inicial de autonomia dura exatamente até a primeira exceção. Um parecer técnico que só pode ser assinado por quem tem competência específica, uma exigência documental condicionada ao CNAE do requerente, um prazo que dispara indeferimento automático por força de lei — assim que o fluxo pede uma regra de negócio real de processo administrativo público, o “sem código” descobre seu limite: alguém precisa programar. E esse alguém volta a ser o mesmo time de desenvolvimento que a ferramenta foi comprada para desafogar.

Isso não é falha de execução, é o desenho do produto: uma plataforma de baixo código genérica otimiza a superfície — quantos campos, qual aparência, quantos aprovadores em sequência — porque ela não foi construída em cima do vocabulário do setor público. Ela não sabe, de fábrica, o que é motivação do ato, o que é decurso de prazo com efeito jurídico ou o que é trilha auditável exigida por controle externo. Aprende isso por parametrização manual, processo por processo, exatamente onde a promessa de agilidade para de valer.

A dívida técnica de sistemas paralelos não desaparece, ela migra de lugar

Uma instituição que chegou a duzentos sistemas internos ao longo dos anos não tinha excesso de tecnologia — tinha excesso de soluções pontuais para o mesmo problema de fundo: cada área resolvendo sua urgência isoladamente, sem um motor comum de tramitação. Adicionar mais uma ferramenta genérica a esse cenário, por mais moderna que seja sua interface, não reduz a fragmentação: troca a pergunta “qual desses duzentos sistemas tem o dado correto deste processo” por “esse processo está no sistema legado ou já migrou para a nova ferramenta” — uma dúvida que pesa tanto na governança de dados quanto na resposta a um pedido de informação amparado pela Lei de Acesso à Informação (12.527/2011), que exige saber, com certeza, onde está o registro oficial de cada ato.

O que reduz essa dívida não é mais uma ferramenta flexível para qualquer fluxo imaginável — é uma plataforma que já nasce modelando o processo administrativo eletrônico como núcleo, não como módulo encaixado por cima de um motor de workflow genérico. A flexibilidade que importa não é poder desenhar qualquer tela: é poder configurar qualquer regra específica do seu rito, em cima de uma base que já chega correta por padrão — prazo com efeito jurídico, motivação obrigatória e histórico auditável, antes mesmo da primeira configuração.

Conclusão

A pergunta que decide se uma ferramenta serve ao setor público não é “é fácil de configurar” — é o que acontece na primeira exceção. Se a resposta for “abre um chamado de desenvolvimento”, a ferramenta não eliminou o gargalo que a instituição tinha antes de contratá-la: só deu a ele uma interface mais bonita. Uma plataforma pensada para o rito administrativo público resolve a exceção como parametrização, não como projeto novo — e é isso que separa um sistema que acompanha a complexidade real da gestão pública de mais um item na lista de ferramentas que prometeram resolver tudo. Para ver como esse desenho funciona num processo real, agende uma demonstração da Aprova.