Implementação de ERP governamental: autorização de segurança e conformidade

As implementações governamentais de ERP combinam a complexidade operacional de implantações empresariais em grande escala com restrições regulatórias, responsabilidade política e requisitos de segurança que nenhuma implementação comercial enfrenta. Uma agência que implementa o ERP deve navegar pelas regras de aquisição competitivas (a implementação em si deve ser adjudicada de forma competitiva), pelos requisitos de segurança da FISMA, pelos requisitos de autorização potencialmente do FedRAMP, pela supervisão do Inspetor Geral e pelos ciclos de aprovação orçamentária legislativa — antes de escrever uma única linha de configuração.

Este guia fornece uma estrutura de nível profissional para a implementação de ERP governamental, com atenção específica aos requisitos de segurança, conformidade e governança que distinguem as implantações no setor público das comerciais.

Principais conclusões

A aquisição governamental de ERP deve, por si só, cumprir os requisitos de licitação - orçamento de 12 a 18 meses para aquisição antes do início da implementação

A conformidade com a FISMA exige uma Autorização de Operação formal (ATO) antes de processar dados governamentais na produção

A autorização do FedRAMP (para agências federais) ou requisitos estaduais equivalentes restringem a seleção do fornecedor de nuvem

Os requisitos de autorização de segurança para o pessoal de implementação podem limitar as opções de pessoal do fornecedor

As dotações orçamentais legislativas restringem os orçamentos de implementação e podem exigir autorização separada para grandes investimentos em TI

A supervisão do Inspetor Geral e do GAO dos principais projetos de TI exige documentação proativa e transparência

Os requisitos de classificação de dados governamentais afetam a arquitetura, os controles de acesso e a configuração do registro de auditoria

A gestão de mudanças em ambientes de serviço público requer consulta sindical e planejamento formal de transição da força de trabalho

Pré-Implementação: Aquisições e Autorização Legislativa

A aquisição governamental de ERP é em si um projeto importante que deve ser concluído antes que a implementação possa começar. O processo de aquisição de um grande ERP governamental normalmente leva de 12 a 24 meses, desde a definição dos requisitos até a adjudicação do contrato.

Desenvolvimento de Requisitos

A lei de compras governamentais exige que a agência defina seus requisitos antes de solicitar propostas — as agências não podem selecionar primeiro um fornecedor e definir requisitos em torno das capacidades do fornecedor selecionado. O desenvolvimento de requisitos envolve:

Avaliação do estado atual: documente os sistemas existentes, sua idade, suas lacunas funcionais e o custo estimado de manutenção deles
Requisitos de negócios: documente os recursos funcionais específicos necessários, organizados por módulo (finanças, compras, RH, subsídios, serviços ao cidadão)
Requisitos técnicos: especifique requisitos de integração, requisitos de volume de dados, requisitos de desempenho, requisitos de segurança (nível FISMA) e padrões de interoperabilidade
Critérios de avaliação: Defina os critérios pelos quais as propostas serão avaliadas, com pesos atribuídos, antes de emitir a solicitação

Os documentos de requisitos tornam-se parte do registro público e estão sujeitos a protestos de aquisição por parte de fornecedores malsucedidos, caso pareçam favorecer um produto específico. Os requisitos devem ser baseados no desempenho e tecnologicamente neutros sempre que possível.

Compras Competitivas

A aquisição governamental de ERP normalmente ocorre por meio de um de dois veículos:

Competição completa e aberta: uma solicitação de proposta (RFP) completa com anúncio público, respostas do fornecedor, avaliação técnica e decisão de premiação pelo melhor valor
Veículos de contrato governamental existentes: Muitas agências governamentais adquirem ERP por meio de veículos de contrato de premiação múltipla estabelecidos (Cronogramas GSA, SEWP, titulares de BPA) que já concluíram um processo de premiação competitivo

A utilização de um veículo contratual existente pode reduzir o tempo de aquisição em 12 a 18 meses em comparação com uma concorrência completa. No entanto, a agência deve garantir que o veículo contratual abrange os produtos e serviços necessários e que a concorrência da ordem de tarefas dentro do veículo é adequadamente competitiva.

Orçamento e Autorização Legislativa

Os grandes investimentos governamentais em TI — normalmente aqueles que excedem os limites definidos — exigem autorização legislativa separada. Em algumas jurisdições, um projecto de TI de capital acima de um montante limite requer autorização de rubrica orçamental específica, separada da dotação operacional da agência. A obtenção desta autorização acrescenta outro ciclo ao cronograma de pré-implementação.

As agências devem planear um período de pré-implementação de 24 a 36 meses para um ERP importante (desde o planeamento inicial até à adjudicação do contrato e autorização legislativa) e incluir este cronograma no calendário geral do projeto.

Conformidade FISMA e Autorização para Operar

A Lei Federal de Gerenciamento de Segurança da Informação (FISMA) exige que todo sistema de informação federal receba uma Autorização formal para Operar (ATO) antes de processar, armazenar ou transmitir informações governamentais. O processo ATO envolve uma avaliação de segurança abrangente que deve ser concluída antes da implantação da produção.

Categorias de segurança FISMA

A FISMA exige que os sistemas de informação sejam categorizados pelo impacto potencial de uma violação de segurança na confidencialidade, integridade e disponibilidade – Baixo, Moderado ou Alto para cada dimensão. A categorização geral do sistema determina os controles de segurança necessários da Publicação Especial 800-53 do NIST.

A maioria dos sistemas financeiros governamentais são classificados como de impacto moderado para todas as três dimensões, exigindo a implementação de aproximadamente 300 controles de segurança do catálogo NIST 800-53. Sistemas de alto impacto (incomuns em ERP financeiros) exigem controles adicionais.

Plano de segurança do sistema

O principal documento da FISMA é o Plano de Segurança do Sistema (SSP), que documenta:

O limite do sistema (quais componentes estão incluídos no limite de autorização)
Os tipos de dados processados pelo sistema e seus níveis de sensibilidade
Os controlos de segurança implementados e como satisfazem os requisitos NIST 800-53
Os controles herdados do ambiente de hospedagem (controles comuns)
Os controles que são de responsabilidade do proprietário do sistema (controles específicos do sistema)

Preparar o SSP para uma implementação complexa de ERP é um projeto significativo por si só, normalmente exigindo de 3 a 6 meses de trabalho de documentação por profissionais de segurança experientes.

Avaliação e autorização de segurança

Após a conclusão do SSP, uma equipe de avaliação independente — seja um terceiro autorizado ou uma equipe de avaliação interna separada da equipe de implementação — testa os controles de segurança para verificar se eles funcionam conforme documentado. A avaliação gera um Relatório de Avaliação de Segurança (SAR) que documenta as descobertas.

O Oficial Autorizador (AO) analisa o SSP e o SAR e toma a decisão de autorização — concedendo uma ATO, emitindo uma ATO condicional com a remediação necessária ou negando a autorização. Uma ATO normalmente é emitida por três anos, após os quais é necessária uma reavaliação.

Autorização FedRAMP para Cloud ERP

Para agências federais que usam ERP hospedado em nuvem, o provedor de serviços em nuvem deve manter uma autorização FedRAMP no nível de impacto apropriado (Baixo, Moderado ou Alto). A autorização do FedRAMP é uma avaliação formal dos controles de segurança da plataforma em nuvem por uma Organização de Avaliação de Terceiros (3PAO) credenciada pelo programa FedRAMP.

Impacto na seleção do fornecedor

Os requisitos de autorização do FedRAMP restringem significativamente a seleção de fornecedores de ERP em nuvem. Nem todos os fornecedores comerciais de ERP obtiveram autorização do FedRAMP, especialmente no nível de alto impacto. As agências devem verificar o status de autorização do FedRAMP durante a aquisição – o FedRAMP Marketplace em marketplace.fedramp.gov é a fonte oficial.

Controles herdados

Um benefício significativo do uso de plataformas em nuvem autorizadas pelo FedRAMP é a herança de controles de segurança comuns do ambiente em nuvem. Os controles relacionados à segurança física, controles ambientais e algumas funções de gerenciamento de identidade estão documentados no pacote de autorização FedRAMP do provedor de nuvem e podem ser herdados pelos sistemas da agência que usam a plataforma. Isto reduz a carga de documentação de segurança para o ATO da agência.

Requisitos de autorização de segurança

As implementações governamentais de ERP que envolvem sistemas confidenciais ou informações confidenciais, mas não classificadas, com níveis de alto impacto podem exigir autorizações de segurança para o pessoal de implementação. Este requisito pode afetar significativamente a composição e o cronograma da equipe de implementação.

Processo de investigação de segurança pessoal

As investigações de antecedentes necessárias para autorizações de segurança normalmente levam de 3 a 18 meses para serem concluídas, dependendo do nível de autorização e da complexidade dos antecedentes do indivíduo. Os fornecedores de implementação podem não conseguir designar os seus consultores mais experientes se esses indivíduos não tiverem ou não puderem obter as autorizações necessárias.

Mitigando restrições de liberação

As agências podem mitigar as restrições de liberação:

Identificar os requisitos de liberação no início do planejamento e iniciar o processo de liberação para o pessoal-chave de implementação antes da adjudicação do contrato
Projetar a implementação para minimizar a exposição do pessoal autorizado ao trabalho de configuração do ERP que requer acesso a dados confidenciais
Usar um consultor técnico autorizado fornecido pelo governo para gerenciar o trabalho de configuração sensível à autorização, com o fornecedor de implementação fornecendo conhecimento funcional em níveis de classificação mais baixos

Classificação e tratamento de dados

Os dados governamentais são classificados em diversas categorias que afetam a forma como devem ser tratados no ERP:

Informações Não Classificadas Controladas (CUI)

CUI é uma categoria ampla de informações governamentais que requer proteção por lei, regulamentação ou política governamental, mas não chega ao nível confidencial. O ERP financeiro normalmente contém CUI, incluindo: informações de identificação pessoal (PII) de funcionários e contratados, informações financeiras sobre programas governamentais e informações confidenciais de compras.

Os requisitos de tratamento de CUI incluem: controles de acesso ao sistema, registro de auditoria, restrições de transferência e requisitos de descarte. A configuração do ERP deve impor controles CUI no nível do elemento de dados para informações designadas como CUI.

Registros da Lei de Privacidade

Os registros de funcionários e contratados do governo estão sujeitos aos requisitos da Lei de Privacidade, que determinam: manter um Aviso de Sistema de Registros (SORN) descrevendo os registros, limitando a divulgação a fins autorizados, fornecendo aos indivíduos acesso a registros sobre si mesmos e mantendo registros precisos. A implementação do ERP deve incluir análise de impacto da Lei de Privacidade e controles apropriados para todos os sistemas que mantêm registros cobertos pela Lei de Privacidade.

Fases de implementação para o governo

As implementações de ERP governamentais exigem fases que levem em conta os ciclos orçamentários do ano fiscal, a supervisão legislativa e o calendário operacional da agência.

Fase 1: Fundação e Finanças (Ano 1)

A implementação financeira estabelece a estrutura contabilística do fundo da qual dependem todos os módulos subsequentes. Esta fase inclui:

Desenho do plano de contas alinhado com a estrutura do fundo GASB
Migração e reconciliação de saldo de abertura
Integração orçamentária e configuração de contabilidade de oneração
Desenvolvimento de modelos de demonstrações financeiras GAAP e GASB
Projeto e testes de processos de fechamento de final de ano

O ano fiscal é a unidade natural de implementação das finanças públicas – o novo sistema deve estar pronto para processar um ano fiscal completo, do início ao fim, antes de entrar em funcionamento.

Fase 2: Aquisições e Gestão de Contratos (Ano 2, T1-Q2)

A implementação de aquisições segue as finanças porque as transações de aquisições são contabilizadas no razão geral. Esta fase inclui:

Migração de banco de dados de fornecedores e integração SAM.gov
Configuração e fluxo de trabalho do limite de lances
Fluxo de trabalho de pedidos e requisições de compra
Configuração de gerenciamento de contrato
Configuração de rastreamento MWBE

Fase 3: RH e folha de pagamento (Ano 2, 3º a 4º trimestre)

O RH governamental e a folha de pagamento estão entre os módulos mais complexos de implementar devido aos sistemas de classificação de cargos, contratos sindicais e integração previdenciária. Esta fase requer:

Configuração do cronograma de classificação de cargos
Regras de escala salarial e avanço de etapas
Implementação do prazo do contrato da União por unidade de negociação
Configuração de administração de benefícios
Configuração de cálculo de contribuição previdenciária

Fase 4: Gestão de Subsídios (Ano 3)

A gestão de subvenções pode ser implementada após a fundação da GL ser estabelecida. Esta fase inclui:

Configuração de prêmio federal e configuração de rastreamento
Configuração de regras de custos admissíveis por programa
Configuração da metodologia de alocação de custos
Fluxo de trabalho de gerenciamento de subrecipientes
Configuração do modelo de relatório federal (SF-425, SF-270, etc.)

Gestão de Mudanças em Ambientes de Função Pública

A gestão de mudanças em agências governamentais enfrenta diversas restrições não presentes em ambientes comerciais:

Requisitos de consulta sindical

Nas agências com forças de trabalho sindicalizadas, mudanças significativas nos processos de trabalho — incluindo a implementação de ERP — podem desencadear obrigações de negociação ao abrigo do acordo de negociação colectiva. Os contratos sindicais muitas vezes exigem que a agência notifique o sindicato e negocie o impacto das mudanças tecnológicas na negociação dos funcionários da unidade antes da implementação.

O envolvimento precoce com representantes sindicais – explicando o cronograma de implementação, as mudanças previstas no fluxo de trabalho e o compromisso da agência com o apoio à transição da força de trabalho – constrói o relacionamento de cooperação necessário para uma gestão de mudanças bem-sucedida. As relações sindicais adversas durante a implementação do ERP estão associadas a taxas de adoção mais baixas e a mais queixas.

Impacto da classificação de posição

A implementação do ERP pode alterar a natureza de cargos específicos – reduzindo a complexidade de algumas funções (devido à automação) e aumentando a complexidade de outras (devido a novas responsabilidades de gestão do sistema). Os sistemas de classificação de cargos podem exigir a reclassificação formal dos cargos afetados, o que exige documentação, revisão do supervisor e, potencialmente, consulta sindical.

Treinamento em ambientes de aprendizagem governamentais

Os programas de formação governamental muitas vezes devem cumprir requisitos específicos: as agências civis podem utilizar sistemas de gestão de aprendizagem obrigatórios (por exemplo, USA Learning para agências federais), a formação deve ser acessível a funcionários com deficiência nos termos da Secção 508, e a documentação de formação deve ser mantida durante o período de retenção exigido.

Inspetor Geral e Engajamento de Supervisão

Os principais projetos de TI do governo — especialmente aqueles com orçamentos superiores a US$ 10 milhões — atraem rotineiramente a atenção de supervisão dos escritórios do Inspetor Geral, dos órgãos de auditoria legislativa (GAO, auditores legislativos estaduais) e dos comitês de supervisão legislativa. O envolvimento proativo com os órgãos de supervisão reduz o risco de resultados adversos.

Termo do Projeto e Documentação de Governança

Mantenha documentação abrangente da governança do projeto: o termo de abertura do projeto, o estatuto do comitê diretor, atas de reuniões que documentam as principais decisões e o registro formal de riscos. Os órgãos de supervisão avaliam a qualidade da governação do projecto como um indicador importante do sucesso da implementação.

Relatório Trimestral de Status

Estabelecer uma cadência regular de relatórios de situação aos órgãos de supervisão – relatórios escritos trimestrais complementados por briefings nos principais marcos. Os relatórios de estado devem incluir: desempenho dos custos (real vs. planeado), desempenho do cronograma (real vs. planeado), principais riscos e ações de mitigação, e marcos futuros. Relatórios de situação precisos e oportunos criam credibilidade junto aos órgãos de supervisão e reduzem o risco de descobertas surpreendentes.

Verificação e validação independentes

Muitas agências governamentais contratam um terceiro independente — um empreiteiro de IV&V — para revisar continuamente o projeto de implementação e fornecer avaliações objetivas de cronograma, custo e risco técnico. O envolvimento da IV&V demonstra o compromisso com a responsabilização e fornece um alerta precoce sobre problemas de implementação antes que se tornem crises.

Pós-Implementação: Conformidade Contínua

Após a entrada em funcionamento, as agências governamentais devem manter a conformidade contínua com os requisitos da FISMA, de privacidade e de gestão de subvenções.

Avaliações anuais de segurança

A FISMA exige revisões anuais de segurança dos sistemas autorizados. Estas revisões verificam se os controlos de segurança continuam a funcionar eficazmente, se novas vulnerabilidades foram identificadas e corrigidas e se a documentação dos limites do sistema permanece precisa.

Monitoramento Contínuo

A orientação do NIST sobre monitoramento contínuo espera que as agências monitorem os controles de segurança continuamente, em vez de apenas no ponto de reavaliação de três anos. O ERP deve gerar relatórios automatizados de monitoramento de segurança – relatórios de acesso ao sistema, registros de alterações de configuração e alertas de detecção de anomalias – que alimentam o programa de monitoramento contínuo da agência.

Perguntas frequentes

Quanto tempo leva o processo de autorização do FedRAMP?

A autorização do FedRAMP para um novo serviço em nuvem normalmente leva de 12 a 24 meses desde o envolvimento inicial com o programa até a autorização. As agências podem reduzir esse cronograma selecionando fornecedores de ERP em nuvem que já possuem autorização FedRAMP Moderada, o que significa que a avaliação de segurança já foi concluída. O FedRAMP Marketplace lista todos os serviços em nuvem autorizados em seu nível de autorização atual.

Qual é o cronograma do processo de Autoridade para Operar (ATO) para um ERP governamental?

O processo ATO normalmente leva de 6 a 12 meses desde o início da documentação de segurança até a emissão da autorização. Isto inclui 3 a 6 meses para a preparação do Plano de Segurança do Sistema, 2 a 4 meses para a avaliação de segurança e 1 a 2 meses para a análise e decisão do funcionário responsável pela autorização. As agências que usam um ERP em nuvem com uma autorização FedRAMP existente podem aproveitar a documentação de controles herdada para acelerar significativamente seu próprio processo ATO.

Como lidamos com a transição entre anos fiscais durante a implementação?

A abordagem mais comum é implementar o novo ERP a partir do início de um novo exercício fiscal, migrando os saldos finais do ano anterior para os saldos iniciais do novo sistema. Isto cria uma ruptura nítida num limite contabilístico natural. A alternativa — implementação a meio do ano — exige a divisão dos dados financeiros do ano entre dois sistemas e a reconciliação dos resultados combinados para os relatórios anuais, o que é significativamente mais complexo.

Quais são os fatores de alto risco do GAO para projetos de TI governamentais?

O GAO identificou vários factores de alto risco para projectos de TI governamentais com base na análise de implementações falhadas: requisitos de negócio pouco claros, fraca governação de projectos, pessoal de gestão de programas inadequado, dependência excessiva de contratantes com supervisão governamental insuficiente, calendários comprimidos motivados por restrições políticas em vez de técnicas, e tempo de teste insuficiente. Um plano de implementação que aborde explicitamente cada um destes factores de risco demonstra a prontidão de implementação para os órgãos de supervisão.

Como gerenciamos a transição do sistema legado para agências com litígios pendentes?

As agências governamentais frequentemente têm litígios ou processos administrativos pendentes que exigem acesso a registros de sistemas legados. Antes de desmantelar um sistema legado, a agência deve garantir que todos os registos sujeitos a retenção legal sejam preservados num formato legalmente defensável. Isto pode exigir a manutenção do acesso somente leitura ao sistema legado durante o litígio ativo ou a migração de registros relevantes do litígio para um arquivo gerenciado separadamente com documentação da cadeia de custódia.

Próximas etapas

As agências governamentais prontas para iniciar a modernização do ERP devem começar com uma avaliação abrangente das capacidades atuais do sistema, dos requisitos de categorização da FISMA e das restrições do cronograma de aquisição. A prática do setor público da ECOSIRE traz experiência com requisitos de compras governamentais, conformidade com a FISMA e implementação de contabilidade de fundos para implantações de ERP no setor público.

Explore os serviços de implementação de ERP Odoo da ECOSIRE para saber como nossa metodologia estruturada e experiência no setor público podem orientar a jornada de modernização de sua agência.

Government ERP Implementation: Security Clearance and Compliance