Uma Agencia Governamental Implementou Um Sistema De Informação

Por que a maioria dos sistemas de informação governamentais falha nos primeiros seis meses

Quando uma agencia governamental implementou um sistema de informação, o problema raramente é o software em si. A gente já viu isso acontecer em três estados diferentes e o padrão era sempre o mesmo: o ERP ou o módulo de gestão que foi comprado custa mais do que o orçamento anual da secretaria, os servidores precisam ser adaptados na mão porque a infraestrutura local nunca segue o padrão do fornecedor, e depois ainda tem a questão dos dados migrados de planilhas que ninguém mais sabe quem criou. O que eu aprendi na prática é que o ponto de ruptura nunca é técnico. É organizacional. Os servidores públicos que vão usar o sistema diariamente foram treinados em métodos antigos, e quando a transição acontece sem uma fase de convivência entre o legado e o novo sistema, simplesmente ninguém passa a usar. A gente chama isso de resistência silenciosa, que é bem diferente de uma oposição aberta. Ninguém diz que não vai usar. Simplesmente continua fazendo tudo no papel e no Excel ao lado.

Como uma agencia governamental implementou um sistema de informação sem perder os dados críticos

Eu tive um caso específico com uma prefeitura do interior que precisava migrar o cadastro de beneficiários de um programa social. O sistema antigo era um arquivo Access que tinha sido montado em 2009 por um estagiário que nunca mais voltou. O novo sistema era um módulo web com banco MySQL, rodando em servidor próprio dentro da prefeitura. O problema real não era importar os registros. Eram os cadastros duplicados, os CPFs com dígitos errados, os nomes registrados de formas diferentes na mesma pessoa, e principalmente os registros órfãos que não tinham vínculo com nenhuma outra tabela. Se você roda um script de importação cego, acaba criando uma bagunça dobrada em vez de resolver a bagunça original. A solução que funcionou foi criar uma camada intermediária. Nós montamos uma base temporária em PostgreSQL, rodamos um script de deduplicação usando fuzzy match pelo nome e CPF, e depois deixamos os servidores da própria prefeitura revisarem linha por linha os casos ambíguos. Demorou quatro dias de trabalho manual, mas evitou que o sistema novo herdasse erros que já estavam espalhados há quinze anos. O custo disso foi puro tempo humano, não tecnologia.

Se você está pensando em pular essa fase de saneamento e ir direto para a migração, sugiro que leia isso de novo. Migração sem saneamento prévio é o jeito mais rápido de transformar um problema lento num problema urgente.

O que ninguém explica sobre a governança de dados depois da implementação

Muitas pessoas acham que a implementação termina quando o sistema entra em produção. Na realidade, é quando começa a parte mais difícil. Uma vez que o sistema está rodando, você precisa de um responsável por governança de dados, um comitê de alteração de fluxo, e um processo documentado para mudanças. Sem isso, qualquer servidor que entender o básico do sistema começa a fazer ajustes sozinha, e em seis meses você tem meia dúzia de campos sendo populados por lógicas diferentes que ninguém consegue explicar. Eu vi um caso em que um campo de "categoria de benefício" tinha cinco valores possíveis no manual do sistema, mas na prática existiam onze porque cada região havia criado os seus próprios conforme a necessidade local. O sistema não bloqueava, não validava, e o relatório final simplesmente não refletia a realidade. A correção não foi no software. Foi numa reunião de duas horas com os coordenadores regionais para alinhar o que cada valor realmente significava. O ponto que eu quero deixar claro é que sistema de informação em órgão público não é uma questão de TI. É uma questão de processo. Se o processo não existe antes da implementação, o sistema vai automatizar o caos em vez de resolvê-lo.

Dificuldades reais que aparecem só depois de três meses de uso

Um dos problemas mais comuns que eu encontrei foi a questão da permissividade de acesso. No início, todo mundo recebe senha de administrador por conveniência. Isso funciona nas primeiras semanas, porque você quer agilidade. Depois de três meses, você tem dezenas de usuários com acesso total a tabelas que não deveriam consultar, e a auditoria interna vira um pesadelo porque não tem registro de quem alterou o quê e quando. A solução técnica existe e é simples: role-based access control com log de auditoria em tabela separada, imutável. O problema é que a equipe de TI muitas vezes não tem orçamento para implementar isso direito, e acaba relying em soluções básicas que não escalam. O resultado é um sistema que funciona, mas que não pode ser auditado com confiança. Outro ponto que vale mencionar é a questão da integração com sistemas existentes. Nenhuma prefeitura ou secretaria opera com um único sistema. Existe o financeiro, o operacional, o cadastral, e às vezes mais três que foram comprados em anos diferentes de gestões diferentes. Fazer esses sistemas conversarem entre si exige um middleware ou uma API bem desenhada, e a maioria dos órgãos não tem expertise interna para isso. Nós resolvemos usando um serviço de integração leve com rotas mapeadas manualmente, mas isso significa que toda mudança em qualquer um dos sistemas parceiros exige revisão da integração.

Eu também gostaria de ser honesto sobre uma limitação importante: não existe solução única que funcione para todos os casos. Sistemas de informação governamental dependem fortemente do contexto local, da cultura organizacional, e da disponibilidade de recursos humanos para manutenção contínua. O que funcionou em uma prefeitura de médio porte pode falhar completamente em uma prefeitura menor que não tem ninguém dedicado à sustentação do sistema. Se o seu órgão não tem ao menos uma pessoa dedicada exclusivamente à administração do sistema após a implementação, considere seriamente se vale a pena investir nessa migração agora. Às vezes, o sistema mais simples que alguém consegue dar manutenção é melhor do que o sistema mais completo que ninguém consegue sustentar.

Checklist prático para quem está começando

A base de tudo é mapear os fluxos atuais antes de escrever qualquer linha de código ou comprar qualquer licença. Eu recomendo que você passe pelo menos duas semanas documentando o que cada setor faz hoje, quais são os pontos de atrito, e quais decisões são tomadas manualmente que poderiam ser automatizadas. Esse exercício por si só já reduz em cerca de trinta por cento a chance de retrabalho durante a implementação. O segundo ponto é a formação de uma equipe mista. Não confie apenas na equipe de TI do órgão. Inclua pelo menos dois servidores de cada área que vai usar o sistema, preferably aqueles que são mais antigos e conhecem os velhos processos de memória. Eles vão identificar armadilhas que um desenvolvedor externo jamais veria. Terceiro, defina desde o início o que vai ser considerado dado master. Quem decide o que é a versão verdadeira de um registro, onde esse registro é armazenado, e qual sistema tem autoridade sobre ele. Sem essa definição, você vai ter o mesmo problema que eu descrevi antes: múltiplas versões da mesma informação circulando pelo órgão, cada uma considerada correta por quem a criou.

Por fim, planeje a descontinuidade do sistema antigo desde o primeiro dia. Eu já vi casos em que o sistema antigo ficou rodando por dois anos depois da nova implementação porque ninguém teve coragem de desligar. Isso gera confiança falsa e atrapalha a adoção do novo sistema. Defina uma data de desligamento e cumpra ela, mesmo que signififique ter que lidar com alguns incidentes nos primeiros dias após a virada.