Porque é que a integração da gestão do investimento público é importante? class=

Porque é que a integração da gestão do investimento público é importante?

Há um interesse crescente em melhorar o planeamento do investimento público e a gestão do investimento público. A gestão das despesas públicas de capital a longo prazo é vista como um contributo fundamental para o crescimento sustentável. Este interesse crescente na gestão do investimento público inclui a procura de uma melhor automatização e gestão através da utilização de software empresarial de Planeamento de Recursos Governamentais (GRP). Esta é a terceira parte de uma série que explora:

  1. Porque é que a gestão do investimento público é crucial??
  2. Como pode o software permitir o ciclo de vida do investimento público?
  3. Por que razão é importante a integração entre sistemas e subsistemas de software de investimento público??
  4. Que soluções de software estão disponíveis na FreeBalance para ajudar a administração pública a gerir os investimentos públicos?

Por que razão é importante a integração entre sistemas e subsistemas de software de investimento público?

As organizações governamentais utilizam frequentemente software autónomo para gerir o ciclo de vida da Gestão do Investimento Público (GIP). Tal como descrito no entrada anteriorDe acordo com a nossa análise, uma solução de software PIM abrangente requer elementos das categorias CPM, PPM, GRP, ERP e SCM. A nossa observação é que o software comercial de prateleira (COTS) e o software desenvolvido por medida utilizado pelos governos para os investimentos públicos raramente são integrados ou interligados de forma automatizada. Muitos especialistas consideram que o software autónomo é adequado para o que parecem ser funções autónomas, muitas vezes utilizadas exclusivamente por agências governamentais ou ministérios individuais.
Os sistemas autónomos não cumprem as conformidade, coerência, colaboração, abrangência e comunicação necessidades dos investimentos públicos. Eis alguns exemplos que vimos em implementações governamentais que carecem de integração:

  • Separação do planeamento do orçamento de capital ou das aquisições das estruturas de desempenho resultando em investimentos que não estão ligados a objectivos governamentais
  • Separação do software de planeamento orçamental operacional e de capital a falta de orçamentos de funcionamento e de manutenção quando o investimento de capital estiver concluído, o que resulta em infra-estruturas em ruínas ou em hospitais e escolas sem material
  • Separação entre planeamento orçamental e execução orçamental resultando na incapacidade de pagar os contratos plurianuais porque as autorizações plurianuais não foram integradas
  • Separação do planeamento orçamental e de tesouraria o que resulta numa má previsão de tesouraria e na necessidade de recorrer a mais instrumentos de dívida para financiar projectos
  • Separação da gestão do orçamento e da dívida resultando em financiamento insuficiente para investimentos públicos devido a previsões deficientes, ou em projectos de infra-estruturas parados por falta de fundos
  • Separação dos controlos das aquisições e das autorizações resultando em orçamentos excedidos ou subutilizados, violando as leis orçamentais e mergulhando os governos em atrasos (particularmente se usarem contabilidade de caixa)
  • Separação entre a aquisição e a gestão dos contratos resultando em pagamentos a fornecedores que não cumprem os requisitos contratuais ou os regulamentos financeiros
  • Separação da gestão de activos do planeamento orçamental resultando na utilização inadequada de activos, como frotas, e na falta de orçamentos para operações, reparações e substituição de activos no final da sua vida útil
  • Separação da M&A da execução e das operações do projecto em que os decisores e o público têm pouca noção dos resultados positivos dos investimentos em infra-estruturas
  • Falta generalizada de separação de funções quando os indivíduos têm a possibilidade de aprovar grande parte do ciclo do PIM sem uma supervisão efectiva, o que permite frequentemente práticas corruptas

Qualquer grande organização com várias aplicações pode beneficiar de uma forte integração. O principal risco dos sistemas não integrados é o tratamento das alterações de metadados. Isto é particularmente importante no sector público com a reforma e modernização da Gestão das Finanças Públicas (GFP). Os metadados, neste caso, referem-se a classificações de informação que precisam de ser alteradas em várias aplicações. Isto pode ser particularmente difícil quando algumas aplicações têm metadados codificados. Existem problemas de coordenação mesmo em situações em que os metadados podem ser ajustados entre muitos subsistemas PIM. Exemplos de questões de metadados que podem afectar muitos subsistemas PIM da reforma da GFP incluem

  • Orçamentação de programas onde um segmento COA adicional é adicionado para permitir a visualização de informações por programas e não apenas através da estrutura organizacional
  • Gestão de desempenho quando um segmento COA adicional é acrescentado ou o segmento do programa é actualizado para apoiar estruturas de desempenho alinhadas com os objectivos governamentais
  • Contabilidade de exercício quando são necessários elementos COA de acréscimo adicionais e a avaliação e depreciação do activo são controladas
  • Reforma dos contratos públicos quando as novas regras relativas a autorizações, contratos, fornecedores e pagamentos exigem novas classificações
  • Gestão de dinheiro com a Conta Única do Tesouro (TSA), que altera a natureza do planeamento da dívida e da gestão dos pagamentos

Como avaliar as necessidades de integração

Alguns observadores argumentarão que, nalguns casos, os riscos decorrentes da falta de integração não são elevados. É difícil integrar uma carteira de software COTS e de software desenvolvido à medida que utiliza diferentes estruturas de programação e diferentes mecanismos de integração. Temos visto governos a utilizar muitas práticas tecnológicas inadequadas para a integração, incluindo procedimentos armazenados e chamadas directas à base de dados.
A FreeBalance desenvolveu uma abordagem baseada no risco para determinar o risco de integração. Esta abordagem utiliza uma matriz de risco padrão que mostra o impacto por probabilidade. A falta de risco de integração aumenta para qualquer aplicação que:

  • Ciclo de vida: abrange muitos elementos do ciclo de vida, desde o planeamento até aos resultados
  • Pontos de integração lógica: toca muitos pontos de integração lógica com outras aplicações
  • Integração de aplicações lógicas: toca muitas aplicações com os pontos de integração lógica
  • Aplicações da categoriafazem parte de um conjunto de aplicações separadas para uma função geral, tais como múltiplas aplicações de planeamento orçamental para orçamentos de salários, de capital, recorrentes, de desenvolvimento e de dívida
  • Ciclo de compromissoinclui várias etapas no ciclo das autorizações, desde os orçamentos aos pagamentos, passando pelas autorizações e obrigações, em que os orçamentos podem ser excedidos
  • Risco de erroinclui grandes volumes de dados, como compras, ou grandes montantes monetários, como contratos

Avaliação dos riscos de integração
O processo que utilizamos identifica os riscos dos subsistemas PIM de muito elevado a muito baixo:

  • Muito elevado: probabilidade elevada e impacto elevado quando é necessária uma integração técnica rigorosa e quando a falta de capacidades de integração combinada com qualquer falta de funcionalidade resulta na substituição da aplicação
  • Alto: probabilidade elevada ou impacto elevado combinado com probabilidade média ou impacto médio, em que é necessário um plano de integração e podem ser necessárias actualizações das aplicações
  • MédioRisco médio: probabilidade média e impacto médio, em que é necessária uma visão da arquitectura empresarial da integração para todos os riscos médios a muito elevados, e as aplicações são migradas para um barramento de servidores de aplicações
  • BaixaAs aplicações de menor risco podem ser integradas através de ficheiros simples, chamadas a bases de dados ou outros mecanismos simples e as aplicações de risco baixo e médio só devem ser substituídas por aplicações integradas se faltarem funcionalidades importantes

Um cenário de problema de integração de aquisições

Descrevemos as razões pelas quais os sistemas autónomos de contratação pública electrónica não são uma boa ideia num post de 2014. Foram descritos os pontos de integração entre os contratos públicos e outros subsistemas de gestão das finanças públicas. O posto teve origem numa reunião com uma equipa que estava a desenvolver um sistema personalizado de "contratos públicos electrónicos" (e-GP). O chefe da equipa argumentou que o sistema GRP de back-office seria capaz de lidar com as autorizações porque os ministérios individuais garantiriam que havia orçamento antes de aprovar qualquer requisição ou ordem de compra. Também sugeriu que não existia tal coisa como "aquisições de back-office". A equipa demonstrou grande confiança nestas afirmações. Isto fez-me lembrar o ditado: "A confiança é aquela sensação que temos mesmo antes de compreendermos completamente o problema." O problema é o seguinte:

  • O organismo governamental verifica se existe orçamento suficiente para uma requisição de $10M para um investimento público e emite uma autorização (ou pré-empenho) no sistema back-office e emite um pedido de proposta no sistema e-GP
  • A autorização pode não estar estritamente relacionada com a aquisição porque o controlo é manual
  • Os fornecedores apresentam propostas em que a proposta vencedora pode ser inferior ao orçamento, exigindo uma anulação manual da autorização no GRP, ou pode ser superior ao orçamento, exigindo uma aprovação orçamental que siga os procedimentos de disciplina fiscal utilizados pelo governo
  • É provável que o contrato e a execução abranjam vários anos, daí a necessidade de apresentar autorizações plurianuais no GRP e no sistema de planeamento orçamental, e sempre que os montantes para os anos sejam provavelmente 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 orçamentais, partindo do princípio de que estas são válidas no direito dos contratos públicos
  • As entradas e devoluções de bens e serviços devem ser consideradas no GRP back-office
  • As sanções e os pagamentos por desempenho podem fazer parte do contrato, o que afecta o cálculo administrativo das autorizações e dos orçamentos
  • A falta de separação de funções no sistema e-GP, especialmente se esse sistema for responsável pela autorização de pagamentos, constitui um risco significativo

Tópicos

Contacto