Em que cenário essa decisão aparece de verdade?
A pergunta ERP próprio vs SaaS público aparece em dois momentos típicos: na contratação inicial de um sistema integrado de gestão pública (cenário comum em municípios que ainda operam com sistemas departamentais isolados) e na troca de um ERP existente que chegou ao fim de vida útil ou cujo contrato ficou insustentável.
A maior parte das prefeituras médias e grandes do Brasil opera hoje com ERP fornecido por uma das três ou quatro empresas dominantes do setor — geralmente em contratos longos, com customização acumulada ao longo de anos e dependência operacional alta. SaaS público, no sentido próprio do termo, ainda é minoritário em ERPs municipais, mas avança rapidamente em módulos específicos (atendimento, protocolo, tributário).
A literatura comercial tende a tratar a decisão como binária — ou ERP tradicional, ou SaaS — e a recomendar SaaS por princípio. A realidade operacional do setor público brasileiro é mais cinzenta: nem todo SaaS público é maduro, nem todo ERP tradicional é necessariamente arcaico. O que importa é a aderência ao cenário institucional concreto.
O que muda na arquitetura entre os dois modelos?
A diferença mais visível é a localização da infraestrutura. ERP próprio roda em servidores controlados pelo ente público — em data center próprio ou em nuvem contratada — com o sistema instalado, configurado e mantido sob a responsabilidade da equipe local (mesmo quando há contrato de suporte). SaaS público roda em infraestrutura do fornecedor, e o ente consome o serviço via navegador ou API.
Isso tem consequência prática em três áreas: customização, atualização e backup. ERP próprio permite customização profunda — alterar regra de negócio, criar módulo específico, integrar com sistema local exótico — porque o código e a configuração estão no ambiente do ente. SaaS público padroniza a experiência: customização existe, mas dentro do que o fornecedor expõe como configuração. Em compensação, atualização do SaaS é contínua e silenciosa; ERP próprio exige projeto de upgrade periódico (geralmente disruptivo).
Backup e continuidade também diferem. No ERP próprio, a responsabilidade pelo backup é local — o ente decide a política, executa e responde. No SaaS público, o fornecedor garante a continuidade dentro do contrato, mas o ente perde controle sobre o detalhe operacional — o que pode ser bom (menos custo operacional) ou ruim (menos visibilidade) dependendo da maturidade interna.
Quando faz sentido manter ou contratar um ERP próprio?
Há cenários em que ERP próprio continua sendo a escolha racional, e ignorar isso por modismo de SaaS sai caro.
Equipe técnica robusta e estável
Estados, capitais e órgãos federais com TI interna estruturada conseguem operar ERP próprio com qualidade — e ganham flexibilidade que SaaS dificilmente oferece. Equipe que sabe administrar banco de dados, ambientes, integrações e processos de release tem condições reais de extrair valor de uma arquitetura própria.
Exigência regulatória de localização e isolamento
Para órgãos que tratam dados de segurança pública, inteligência, defesa ou saúde sensível em larga escala, requisitos regulatórios específicos podem inviabilizar SaaS multi-tenant — exigindo controle direto de onde os dados residem, como são acessados e por quem. Nesses casos, ERP próprio em ambiente controlado é via natural.
Operação altamente customizada por anos
Quando uma prefeitura ou estado acumulou customizações específicas que refletem regras de negócio reais (não apenas vontade dos secretários antigos), migrar para SaaS implica perder essas customizações ou reconstruí-las em camada adjacente — quase sempre com perda de funcionalidade no curto prazo. ERP próprio preserva o investimento prévio.
Investimento inicial absorvível e horizonte longo
Ente com orçamento de TI estável e horizonte de gestão técnica de mais de 8 a 10 anos tem condições de amortizar investimento inicial alto de ERP próprio. SaaS, com pagamento recorrente, vence no curto prazo mas pode ficar mais caro no longo prazo dependendo da modalidade contratual.
Quando faz sentido contratar SaaS público?
Igualmente, há cenários em que SaaS é evidentemente superior — e insistir em ERP próprio é desperdício.
Município pequeno ou médio com equipe de TI enxuta
Prefeitura de até 200 mil habitantes raramente sustenta operação técnica de ERP próprio com qualidade. SaaS público especializado entrega operação profissional, atualização contínua e padrões de segurança que a equipe local não conseguiria operar — a custo final menor.
Necessidade de partir do zero rapidamente
Cenário de ente que ainda opera com sistemas departamentais isolados, planilha e papel, e precisa estruturar uma operação integrada em prazo curto. SaaS encurta o tempo até produção de seis a doze meses para algo entre dois e quatro meses, dependendo do escopo.
Foco em jornadas-padrão com pouca customização
Quando as regras de negócio do ente são predominantemente as regras-padrão do setor público brasileiro — sem peculiaridades regulatórias locais relevantes —, SaaS cobre confortavelmente. Customização vira exceção, não regra, e o custo de manter operação própria não se justifica.
Política institucional de preservação de orçamento
Gestores que precisam preservar capital para outros investimentos (obras, educação, saúde) ganham com SaaS — investimento inicial menor, custo previsível, sem capex acumulado em hardware ou licenças perpétuas. A pressão fiscal contemporânea favorece o modelo recorrente nos primeiros anos.
Como comparar o custo total de propriedade nos dois modelos?
Comparação que olha apenas preço de aquisição é enganosa nos dois sentidos. O cálculo defensável precisa considerar pelo menos cinco componentes ao longo de um horizonte de cinco anos.
Primeiro, custo de aquisição ou implantação inicial. ERP próprio tem custo alto neste componente — licença perpétua mais implantação geralmente entre R$ 500 mil e vários milhões, conforme escopo. SaaS público tem custo de implantação consideravelmente menor — entre R$ 50 mil e R$ 300 mil para escopos comparáveis em município médio.
Segundo, custo recorrente. ERP próprio cobra manutenção evolutiva (geralmente 15% a 25% da licença ao ano) mais infraestrutura. SaaS cobra assinatura, geralmente por usuário, processo ou capacidade contratada — montante anual que, em município médio, costuma equivaler a 60% a 100% do custo de manutenção do ERP próprio equivalente.
Terceiro, custo operacional interno. ERP próprio exige equipe local dedicada (DBA, sysadmin, suporte). SaaS reduz esse custo significativamente — equipe mínima para fazer integração e suporte usuário. A diferença, em município médio, pode chegar a R$ 300 mil a R$ 600 mil/ano em folha técnica evitada com SaaS.
Quarto, custo de upgrade e modernização. ERP próprio exige projetos periódicos de upgrade (geralmente caros, geralmente disruptivos). SaaS embute a modernização na assinatura. Em horizonte de cinco anos, esse componente pode dobrar o custo total do ERP próprio frente ao SaaS comparável.
Quinto, custo de saída. Modalidade frequentemente ignorada na comparação inicial: quanto custa migrar dados, treinamento e operação para outro fornecedor? Para ERP próprio, depende do quanto a operação está acoplada à arquitetura escolhida; para SaaS, depende de cláusulas contratuais de portabilidade. Em ambos os casos, é prudente embutir esse custo na avaliação inicial.
Quais são os gradientes de dependência de fornecedor?
A narrativa comercial costuma tratar dependência como sim/não — ou você tem ou não tem. A realidade é um gradiente, e os dois modelos podem se posicionar em pontos diferentes da mesma escala.
ERP próprio com fornecedor único de implantação e sustentação, código fechado e customização tácita acumulada cria dependência altíssima — trocar é projeto de muitos milhões de reais. ERP próprio com código aberto, equipe interna que conhece a arquitetura e contratos modulares cria dependência baixa, mas é minoria.
SaaS público com cláusula de portabilidade de dados em formato aberto, API documentada e contrato com prazos de saída claros cria dependência moderada. SaaS público sem cláusula de portabilidade, dados em formato proprietário e contrato sem prazos definidos cria dependência tão alta quanto ERP próprio fechado — talvez maior, porque o ente sequer tem o ambiente de execução.
O critério defensável é, portanto, contratual e arquitetural — não modelo. ERP próprio com código aberto e dados próprios pode ser menos refém do fornecedor que SaaS proprietário sem cláusula de saída. Avaliar dependência exige olhar contrato e arquitetura, não tipo de licenciamento.
Por que a decisão híbrida costuma ser a melhor saída
Em órgãos públicos com alguma maturidade técnica, a decisão final raramente é monolítica. O caminho que mais funciona, na prática, é híbrido — ERP próprio em módulos onde controle e customização importam (geralmente tributário, contabilidade, planejamento), e SaaS público em módulos onde padronização é mais valiosa (atendimento, protocolo, portal de serviços, gestão de contratos).
Essa arquitetura híbrida exige integração — APIs entre os módulos próprios e os SaaS contratados — mas é a forma realista de capturar o melhor dos dois mundos. Estados que tentaram migrar tudo para SaaS encontraram resistência interna em áreas sensíveis; municípios que insistiram em ERP próprio em tudo ficaram pesados nas áreas que poderiam ser SaaS.
O exercício de planejamento é, então, modular: para cada módulo, perguntar quanto a customização importa, quanto a equipe local sustenta operação, quanto o fornecedor entrega de padrão. A resposta varia por módulo — e a arquitetura final reflete essa variação.
Por onde começar essa decisão
Primeiro: diagnóstico do que existe. Mapear sistemas atuais, contratos vigentes, vencimentos, custo total dos últimos três anos por sistema. Sem esse retrato, qualquer decisão é palpite.
Segundo: capacidade interna real, não declarada. Quantos servidores de TI o ente realmente tem? Quais habilidades? Qual o turnover histórico? Decisão de ERP próprio em ente com TI enxuta e instável vira contratação de fato terceirizada — só com a aparência de operação própria.
Terceiro: horizonte da gestão técnica. CTO ou secretário de TI estável por mandato longo viabiliza ERP próprio; rotação a cada eleição empurra para SaaS. Esse é um filtro que muita análise técnica ignora, e que define o resultado prático.
Por último: pilotar antes de decidir definitivamente. Quando possível, contratar SaaS em um módulo específico (atendimento, por exemplo) e operar por seis a doze meses ao lado do ERP próprio é a forma mais barata de descobrir, na prática, qual modelo serve melhor à instituição — sem precisar fazer migração de larga escala antes de ter evidência.