Há um interesse crescente em melhorar o planejamento e a gestão do investimento público. O gerenciamento de despesas públicas de capital de longo prazo é visto como uma contribuição fundamental para o crescimento sustentável. Esse interesse crescente na gestão de investimentos públicos inclui a busca de melhor automação e gerenciamento por meio do uso do software empresarial de Planejamento de Recursos Governamentais (GRP). Esta é a terceira parte de uma série que explora:
- Por que a gestão de investimentos públicos é crucial??
- Como o software pode viabilizar o ciclo de vida do investimento público??
- Por que é importante a integração entre os sistemas e subsistemas de software de investimento público??
- Quais soluções de software estão disponíveis na FreeBalance para ajudar o governo a gerenciar investimentos públicos?
Por que é importante a integração entre os sistemas e subsistemas de software de investimento público?
As organizações governamentais costumam usar software autônomo para gerenciar o ciclo de vida do Gerenciamento de Investimentos Públicos (PIM). Conforme descrito no entrada anteriorDe acordo com a pesquisa, uma solução abrangente de software de PIM requer elementos das categorias CPM, PPM, GRP, ERP e SCM. Nossa observação é que o software comercial de prateleira (COTS) e o software desenvolvido sob medida usados pelos governos para investimentos públicos raramente são integrados ou fazem interface de forma automatizada. Muitos especialistas acreditam que o software autônomo é apropriado para o que parece ser funções autônomas, geralmente usadas exclusivamente por agências governamentais ou ministérios individuais.
Os sistemas autônomos não conseguem atender às conformidade, consistência, colaboração, abrangência e comunicação necessidades de investimentos públicos. Aqui estão alguns exemplos que vimos em implementações governamentais que carecem de integração:
- Separação do planejamento do orçamento de capital ou da aquisição das estruturas de desempenho resultando em investimentos que não estão vinculados aos objetivos do governo
- Separação do software de planejamento orçamentário operacional e de capital resultando na falta de orçamentos de operação e manutenção quando o investimento de capital é concluído, resultando em infraestrutura em ruínas ou hospitais e escolas sem suprimentos
- Separação do planejamento orçamentário e da execução orçamentária resultando na incapacidade de pagar por contratos de vários anos porque os compromissos de vários anos não foram integrados
- Separação do orçamento e do planejamento de caixa resultando em uma previsão de caixa ruim e na necessidade de mais instrumentos de dívida para financiar projetos
- Separação do gerenciamento do orçamento e da dívida resultando em financiamento insuficiente para investimentos públicos devido a previsões ruins ou projetos de infraestrutura paralisados por falta de fundos
- Separação da aquisição dos controles de compromisso resultando em orçamentos excedentes ou insuficientes, violando as leis orçamentárias e levando os governos a atrasos (especialmente se estiverem usando contabilidade baseada em caixa)
- Separação da aquisição da gestão de contratos resultando em pagamentos a fornecedores que não seguem os requisitos contratuais ou as regulamentações financeiras
- Separação do gerenciamento de ativos do planejamento orçamentário resultando no uso inadequado de ativos, como frotas, e na falta de orçamentos para operações, reparos e substituição de ativos quando estes chegam ao fim da vida útil
- Separação do M&A da implementação e das operações do projeto onde os tomadores de decisão e o público têm pouca ideia dos resultados positivos dos investimentos em infraestrutura
- Falta geral de segregação de funções onde os indivíduos podem aprovar grande parte do ciclo do PIM sem uma supervisão eficaz, o que geralmente permite práticas corruptas
Qualquer grande organização com vários aplicativos pode se beneficiar de uma forte integração. O principal risco dos sistemas não integrados é lidar com alterações de metadados. Isso é particularmente importante no setor público com a reforma e a modernização da Gestão Financeira Pública (PFM). Metadados, nesse caso, referem-se a classificações de informações que precisam ser alteradas em vários aplicativos. Isso pode ser particularmente difícil quando alguns aplicativos têm metadados codificados. Há problemas de coordenação mesmo em situações em que os metadados podem ser ajustados entre muitos subsistemas PIM. Exemplos de problemas de metadados que podem afetar muitos subsistemas PIM da reforma do PFM incluem:
- Orçamento de programas onde um segmento COA adicional é adicionado para permitir a visualização de informações por programas e não apenas por meio da estrutura organizacional
- Gestão de desempenho onde um segmento COA adicional é adicionado ou o segmento do programa é atualizado para apoiar estruturas de desempenho alinhadas com as metas do governo
- Contabilidade de exercício onde elementos COA de acumulação adicionais são necessários e a avaliação de ativos e a depreciação são rastreadas
- Reforma das aquisições onde novas regras para compromissos, contratos, fornecedores e pagamentos exigem novas classificações
- Gestão de caixa com a Treasury Single Account (TSA), que muda a natureza do planejamento da dívida e do gerenciamento de pagamentos
Como avaliar as necessidades de integração
Alguns observadores argumentarão que os riscos da falta de integração não são altos em alguns casos. É difícil integrar um portfólio de COTS e softwares desenvolvidos sob medida que usam estruturas de programação diferentes e mecanismos diferentes para integração. Vimos governos utilizarem muitas práticas tecnológicas ruins para a integração, incluindo procedimentos armazenados e chamadas diretas ao banco de dados.
A FreeBalance desenvolveu uma abordagem baseada em risco para determinar o risco de integração. Essa abordagem usa uma matriz de risco padrão que mostra o impacto por probabilidade. A falta de risco de integração aumenta para qualquer aplicativo que:
- Ciclo de vida: abrange muitos elementos do ciclo de vida, do planejamento aos resultados
- Pontos de integração lógica: abrange muitos pontos de integração lógica com outros aplicativos
- Integração de aplicativos lógicos: abrange muitos aplicativos com os pontos de integração lógica
- Aplicativos da categoriasão parte de um conjunto de aplicativos separados para uma função geral, como vários aplicativos de planejamento orçamentário para orçamentos de salário, capital, recorrentes, desenvolvimento e dívida
- Ciclo de compromissoInclui várias etapas no ciclo de compromisso, desde orçamentos até pagamentos, passando por compromissos e obrigações em que os orçamentos podem ser excedidos.
- Risco de erroinclui grandes volumes de dados, como compras, ou grandes quantias em moeda, como contratos
O processo que usamos identifica os riscos dos subsistemas do PIM de muito alto a muito baixo:
- Muito alto: alta probabilidade e alto impacto quando é necessária uma integração técnica rigorosa de boas práticas e quando a falta de recursos de integração combinada com qualquer falta de funcionalidade resulta na substituição do aplicativo
- Alta: alta probabilidade ou alto impacto combinado com média probabilidade ou médio impacto, onde um plano de integração é necessário e atualizações de aplicativos podem ser necessárias
- MédioRisco médio: probabilidade média e impacto médio, em que uma visão de arquitetura empresarial da integração é necessária para todos os riscos médios a muito altos, e os aplicativos são migrados para um barramento de servidor de aplicativos
- BaixaOs aplicativos com menor risco podem ser interligados por meio de arquivos simples, chamadas de banco de dados ou outro mecanismo simples, e os aplicativos classificados como de baixo e médio risco devem ser substituídos por aplicativos integrados somente se faltar uma funcionalidade importante
Um cenário de problema de integração de compras
Descrevemos os motivos pelos quais sistemas autônomos de compras eletrônicas não são uma boa ideia em um post de 2014. Foram descritos os pontos de integração entre as aquisições e outros subsistemas de PFM. A postagem surgiu de uma reunião com uma equipe que desenvolvia um sistema personalizado de "Compras Governamentais Eletrônicas" (e-GP). O líder da equipe argumentou que o sistema GRP de back-office seria capaz de lidar com compromissos porque os ministérios individuais garantiriam que havia orçamento antes de aprovar qualquer requisição ou pedido de compra. Ele também sugeriu que não existia algo como "aquisição de back-office". A equipe demonstrou grande confiança nessas afirmações. Isso me fez lembrar do ditado: "confiança é aquela sensação que você tem logo antes de entender completamente o problema". O problema é o seguinte:
- O órgão governamental verifica se há orçamento suficiente para uma requisição de $10M para um investimento público e emite um compromisso (ou pré-embolso) no sistema de back-office e emite uma Solicitação de Proposta no sistema e-GP
- O compromisso pode não estar estritamente relacionado à aquisição porque o controle é manual
- Os fornecedores fornecem propostas em que a proposta vencedora pode ser inferior ao orçamento, exigindo uma anulação manual no GRP, ou pode ser superior ao orçamento, exigindo uma aprovação orçamentária que siga os procedimentos de disciplina fiscal usados pelo governo
- O contrato e a implementação provavelmente abrangerão vários anos, daí a necessidade de mostrar os compromissos de vários anos no GRP e no sistema de planejamento orçamentário, e onde os valores para os anos provavelmente serão diferentes do plano original
- O fornecedor ou fornecedores executam o contrato, mas pode haver atrasos, o que significa que podem ser necessárias prorrogações de orçamento, supondo que elas sejam válidas na lei de aquisições
- Os recebimentos e devoluções de mercadorias e serviços precisam ser considerados no GRP de back-office
- As penalidades e os pagamentos por desempenho podem fazer parte do contrato, o que afeta o cálculo de back-office para compromissos e orçamentos
- A falta de segregação de funções no sistema e-GP, principalmente se esse sistema for responsável pela autorização de pagamentos, é um risco significativo