Por que um sistema de protocolo deve copiar o processo da prefeitura antes de otimizá-lo

Um sistema de protocolo eletrônico deveria começar reproduzindo, sem alterar, o rito que a prefeitura já pratica — inclusive as etapas redundantes e as exceções pouco elegantes — e só depois de esse processo estar rodando dentro da plataforma é que faz sentido discutir onde simplificar. A prática mais comum no mercado é o oposto: o fornecedor chega com um fluxo padrão já modelado como “a forma certa” de tramitar um alvará ou uma licença e cobra da administração o trabalho de adaptar sua rotina a esse modelo antes mesmo de começar a operar. Essa inversão parece economizar tempo de implantação, mas empurra para o pior momento possível — a virada para o digital — um esforço de redesenho que deveria vir depois, com o órgão já usando o sistema e com dado real para decidir o que vale a pena mudar.

O modelo pronto ignora a exceção que sustenta uma decisão antiga

Todo processo administrativo municipal carrega exceções que não estão escritas em manual nenhum, mas que existem por um motivo concreto: um despacho que passa por dois pareceres em vez de um porque determinada secretaria exige dupla assinatura desde uma reestruturação interna antiga; um documento que só é aceito em certo formato porque é assim que o cartório da região trabalha. Um sistema que chega com fluxo genérico e pede para o órgão “se adaptar” trata essas exceções como ruído a eliminar, não como conhecimento operacional acumulado.

O resultado mais comum não é a prefeitura aceitar o modelo novo de bom grado — é ela manter um contorno paralelo em papel ou planilha para lidar com o caso que o sistema não previu, o que anula boa parte do ganho da digitalização. Isso vale tanto para uma secretaria de obras quanto para uma câmara municipal com rito legislativo próprio: o detalhe que parece dispensável para quem desenhou o sistema de fora costuma ser, para quem opera o processo todos os dias, o motivo de uma decisão anterior que ninguém documentou, só praticou.

Pedir para reformar o processo antes de operar é o motivo mais comum de projeto travado

Quando a condição para começar a usar um sistema é primeiro redesenhar o processo inteiro para caber no modelo do fornecedor, a implantação vira, na prática, um projeto de reengenharia de processos com prazo de sistema — e reengenharia de processo tem outro ritmo, outro conjunto de decisores e outro risco político do que um projeto de tecnologia. É esse descompasso que explica boa parte dos projetos de digitalização que nunca saem da fase de “mapeamento”: o órgão não recusou a tecnologia, recusou o pré-requisito de mudar o processo antes de ver o sistema funcionando com o processo que já existe.

Instituições que conseguem sair do papel em semanas, e não em anos, costumam inverter essa ordem: primeiro entram no ambiente digital com o rito que já praticam, mesmo com suas imperfeições, e só depois — operando — decidem juntas o que faz sentido simplificar.

Otimizar depois é mais seguro do que otimizar antes, porque existe dado

Só depois de operar o processo replicado dentro do sistema por algumas semanas é que aparece o dado que sustenta uma mudança de verdade: quantos processos passam por determinada etapa sem nunca ser rejeitados ali, o que indica que a etapa pode ser cortada; quanto tempo cada exceção consome, o que indica se vale formalizá-la ou eliminá-la. Propor a mesma mudança antes de rodar o processo é uma aposta baseada na intuição de quem não opera aquele processo todo dia; propor depois é uma decisão apoiada no comportamento real daquele órgão específico.

Um exemplo público desse tipo de ganho, medido depois da digitalização e não prometido antes dela, é o de Criciúma (SC): a prefeitura registrou economia de R$ 745 mil em seis meses e deixou de imprimir 59,6 milhões de folhas de papel após digitalizar a tramitação de processos, segundo dado divulgado pelo próprio município. Esse tipo de número só existe porque alguém mediu o processo depois de ele estar rodando — não porque um fornecedor estimou de antemão quanto uma reforma de processo “deveria” economizar.

Conclusão

Copiar o processo antes de melhorá-lo não é resignação com a ineficiência existente — é a sequência que reduz o risco de melhorar a coisa errada. O órgão público que exige ver seu próprio rito rodando dentro do sistema, do jeito que ele é hoje, antes de discutir qualquer simplificação, está protegendo o próprio projeto de digitalização de um fracasso comum: gastar meses reformando processo no papel para, no fim, não conseguir operar o sistema porque a reforma nunca foi de fato validada por quem executa o processo todo dia. Veja também por que um sistema de tramitação genérico muitas vezes falha justamente nesse ponto, e como a triagem de documentos só deveria ser automatizada depois que a regra que ela aplica já foi validada em operação real.