Lançamento rápido sem processo definido
Há muitas autarquias e entidades públicas locais que conseguem “arrancar” uma solução digital em poucas semanas e, ainda assim, passados dois ou três meses, já ninguém a usa como previsto. O problema raramente está apenas na tecnologia. Na maior parte dos casos, as falhas projetos digitais administração local começam quando se lança uma ferramenta antes de estar claro como ela entra no trabalho diário do atendimento, dos serviços administrativos e das chefias.
É uma situação comum. A câmara municipal contrata uma plataforma para pedidos online, a junta de freguesia cria um formulário para marcações, ou um agrupamento de escolas implementa um sistema para gerir requerimentos. No dia da apresentação, tudo parece correr bem: há demonstração, circula um email interno, coloca-se um link no site e faz-se uma publicação nas redes sociais. Mas, na semana seguinte, os pedidos começam a chegar e surgem as perguntas reais: quem recebe primeiro? Quem valida? Quem responde ao munícipe? Em quanto tempo? Onde fica registado o histórico? Se o pedido entrar por email e pela plataforma ao mesmo tempo, qual prevalece?
Quando estas respostas não existem, a solução digital passa a ser apenas mais um canal, em vez de organizar o serviço. E isso cria duplicação. O munícipe submete online, mas telefona dois dias depois porque não teve retorno. O atendimento ao balcão não sabe ver o estado do pedido. O técnico recebe um aviso por email, mas continua a gerir o trabalho numa folha Excel própria. A chefia pede um ponto de situação e ninguém consegue dizer com segurança quantos processos estão pendentes.
Vê-se isto com frequência em áreas como:
- pedidos de ocupação da via pública;
- requerimentos urbanísticos simples;
- marcação de transportes escolares;
- inscrições em atividades de férias;
- pedidos de atestados ou declarações em juntas de freguesia.
O erro de base é pensar que digitalizar o formulário resolve o processo. Não resolve. Se o circuito interno continuar dependente de telefonemas, encaminhamentos manuais e decisões informais, a plataforma só torna mais visível a desorganização que já existia.
Em muitos casos, o arranque é apressado por pressão legítima: fim de mandato, necessidade de mostrar serviço, financiamento com prazo, ou vontade de reduzir filas no balcão. Mas lançar cedo sem processo definido costuma sair caro. Ao fim de pouco tempo, os trabalhadores perdem confiança na ferramenta, os munícipes deixam de a usar e a organização volta ao email, ao papel e ao Excel.
Falta de dono interno e de regras de utilização
Outro motivo muito frequente para o insucesso é a ausência de um responsável interno claro. Não basta haver um fornecedor disponível ou um técnico de informática que “acompanha o projeto”. É preciso existir um dono funcional: alguém da área de negócio que saiba como o serviço funciona, tenha legitimidade para definir regras e acompanhe a operação nas primeiras semanas.
Sem esse dono interno, começam os desvios. Cada serviço usa a solução à sua maneira. Um técnico atualiza estados, outro responde apenas por email, outro imprime os pedidos e arquiva em papel. No atendimento, há quem peça ao munícipe para “mandar também por email, para garantir”. Em pouco tempo, a organização tem três versões da mesma informação.
Num município de média dimensão, por exemplo, uma plataforma de ocorrências urbanas pode arrancar com boa adesão dos munícipes. Buracos na via, iluminação avariada, limpeza urbana: tudo entra pelo portal. Mas se não estiver definido quem tria, quem encaminha e quem fecha a ocorrência, o sistema degrada-se depressa. A divisão de obras diz que é com o ambiente, o ambiente diz que depende da freguesia, a freguesia não tem acesso ao sistema, e o pedido fica “em análise” durante semanas. O munícipe volta a reclamar, agora por telefone e por email.
Nas escolas, acontece algo semelhante com plataformas para pedidos de declarações, justificações ou marcações. Se a secretaria continua a responder de forma diferente consoante a pessoa que está de serviço, a ferramenta não cria consistência. Apenas acrescenta mais um ponto de entrada.
As regras de utilização têm de ser simples e explícitas. Por exemplo:
- todos os pedidos recebidos por telefone devem ser registados no sistema pelo atendimento;
- o estado do processo só pode ser atualizado na plataforma, não em folhas paralelas;
- as respostas ao munícipe devem sair pelo canal definido, para garantir histórico;
- cada tipologia de pedido tem um serviço responsável e um prazo de primeira resposta;
- os pedidos incompletos seguem um procedimento uniforme de notificação.
Sem estas regras, a ferramenta fica dependente da boa vontade individual. E a administração local não pode assentar processos críticos em rotinas informais. Além disso, quando há tratamento de dados pessoais, a desorganização operacional aumenta o risco de incumprimento do RGPD: acessos excessivos, envio de informação para emails errados, falta de controlo sobre quem consultou o quê, ou conservação desnecessária de documentos.
Também aqui importa lembrar que a digitalização na Administração Pública não é apenas uma questão técnica. A AMA tem vindo a insistir, em várias orientações e práticas de modernização administrativa, na necessidade de redesenhar processos e simplificar atendimento. E o enquadramento do Decreto-Lei n.º 83/2018, associado à modernização administrativa e à desmaterialização de procedimentos, aponta precisamente para uma lógica de integração do serviço, e não para a mera substituição do papel por um formulário online.
O que devia estar preparado antes do arranque
Antes de colocar uma solução em produção, há um conjunto de decisões operacionais que deviam estar fechadas. Não é preciso um plano teórico extenso. É preciso trabalho prático, com quem atende, quem analisa e quem decide.
O primeiro ponto é mapear o processo real. Não o processo “ideal” que está no regulamento, mas o que acontece no dia a dia. Quem recebe? Quem valida documentos? Onde há esperas? Que pedidos chegam incompletos? Que dúvidas são mais frequentes ao balcão? Se isto não estiver identificado, a solução digital vai reproduzir os mesmos bloqueios.
O segundo ponto é definir responsabilidades por tipologia de pedido. Em muitas autarquias, o problema não é falta de sistema; é falta de clareza sobre quem faz o quê. Um quadro simples com serviço responsável, substituto, prazo e critério de escalamento evita muitos bloqueios nas primeiras semanas.
O terceiro ponto é preparar conteúdos e modelos de resposta. Se um pedido de licença, uma inscrição ou uma reclamação exigem sempre as mesmas notificações intermédias, essas minutas devem estar prontas. Caso contrário, cada trabalhador escreve à sua maneira, perde tempo e aumenta o risco de erro.
O quarto ponto é testar com casos reais. Não basta o fornecedor mostrar que “funciona”. É preciso simular situações concretas:
- um munícipe submete um pedido sem anexo obrigatório;
- entra um pedido duplicado por email e plataforma;
- um processo tem de passar por dois serviços;
- o prazo expira sem resposta;
- o cidadão pede informação sobre o estado no balcão;
- há necessidade de retificar dados pessoais.
O quinto ponto é garantir conformidade documental e proteção de dados. Quem define perfis de acesso? Que dados são mesmo necessários? Quanto tempo ficam disponíveis? Existe registo de operações? Há informação clara ao titular dos dados? Em contexto local, onde muitos serviços ainda funcionam com práticas muito manuais, esta preparação é decisiva para cumprir o RGPD sem travar o serviço.
Por fim, é importante preparar a frente de atendimento. Muitas soluções falham porque o balcão, a linha telefónica e a secretaria não foram envolvidos. São estas equipas que recebem as dúvidas dos munícipes quando algo corre mal. Se não souberem explicar o novo circuito, acabam por contornar a ferramenta para “desenrascar”, e o processo volta ao modelo anterior.
Como estabilizar a operação após implementação
Mesmo quando o arranque foi imperfeito, ainda é possível recuperar. A estabilização da operação nas primeiras seis a oito semanas é muitas vezes o fator que separa um projeto abandonado de uma solução que passa a fazer parte do serviço.
O primeiro passo é acompanhar diariamente os pedidos em aberto. Não com reuniões longas, mas com um ponto de situação curto: quantos entraram, quantos foram resolvidos, onde estão os bloqueios, que tipologias estão a gerar mais dúvidas. Este acompanhamento deve envolver a chefia operacional e o responsável funcional do processo.
O segundo passo é eliminar canais paralelos sempre que possível. Se a regra é receber pela plataforma, o serviço não deve continuar a aceitar o mesmo tipo de pedido por três vias diferentes sem controlo. Quando isso não puder ser evitado, então todos os pedidos devem ser registados no mesmo ponto, para haver histórico único.
O terceiro passo é corrigir rapidamente o que está a falhar no terreno. Por exemplo, se os munícipes estão a abandonar um formulário porque não percebem um campo, simplifica-se esse campo. Se os técnicos não atualizam estados porque a lista é confusa, ajusta-se a nomenclatura. Se o atendimento não consegue consultar o processo, revêem-se permissões e ecrãs. Pequenas correções operacionais fazem mais diferença do que grandes reformulações prometidas para “a próxima versão”.
O quarto passo é medir coisas simples e úteis:
- tempo até à primeira resposta;
- número de pedidos devolvidos por falta de elementos;
- pedidos resolvidos dentro do prazo;
- volume de contactos telefónicos sobre estado do processo;
- número de pedidos tratados fora da plataforma.
Estes indicadores mostram se a solução está de facto a aliviar o atendimento e a organizar o serviço. Se o número de telefonemas se mantém igual, é sinal de que o munícipe continua sem visibilidade. Se muitos pedidos são tratados fora do sistema, é sinal de que a ferramenta ainda não foi incorporada no trabalho real.
O quinto passo é reforçar regras com formação muito prática. Não é preciso uma sessão longa sobre transformação digital. É mais útil fazer 45 minutos com exemplos do dia a dia: como registar um pedido telefónico, como responder sem perder histórico, como encaminhar para outro serviço, como fechar corretamente um processo. Em juntas de freguesia e escolas, onde as equipas são pequenas e acumulam funções, esta abordagem é especialmente importante.
Em resumo, muitos projetos digitais na administração local falham logo após o arranque porque foram lançados como tecnologia e não como operação. Quando a solução não encaixa nos circuitos reais, nas responsabilidades internas e nas rotinas de atendimento, acaba por ser contornada. O que faz a diferença não é apenas implementar depressa; é preparar processo, dono, regras e acompanhamento. É isso que permite que a ferramenta deixe de ser uma experiência de curto prazo e passe a ser parte normal do serviço ao munícipe.