O Big ERP está oficialmente obsoleto para os serviços partilhados da administração pública? class=

O Big ERP é Oficialmente Obsoleto para Serviços Partilhados do Governo?

Doug Hadden, VP de Produtos

Gartner colocou o último prego no caixão do grande valor do software de planeamento de recursos empresariais (ERP). Quando a Gartner diz que o software ERP principal "fortemente personalizado" é agora "legado" - é ferrugem. O que é que isto significa para os serviços partilhados de ERP a nível governamental? Má ideia. Má relação custo-benefício. A Gartner chama-lhe uma "âncora". (Faz-me lembrar a crítica a um automóvel da Europa de Leste nos anos 80: "acelera como se estivesse acorrentado à garagem".

A Gartner afirma que o sector do software empresarial atingiu uma fase "pós-moderna". Vamos "desconstruir" o que a Gartner está a dizer. E as implicações para os serviços partilhados da administração pública.

Personalização pesada

Forte personalização do ERP = falta de flexibilidade para mudar e adaptar-se à reforma legal e a processos fiscais melhorados. A noção de que os serviços partilhados de ERP proporcionam agilidade é uma mito. A normalização do ERP pode reduzir os custos administrativos no custo da flexibilidade. O software de Planeamento de Recursos Governamentais (GRP), por outro lado, não requer uma grande personalização - é tudo uma questão de configuração.

Além disso, não se deixe enganar pela noção de implementações "normais" na administração pública. É um pouco chocante como os sistemas departamentais do mesmo fabricante que utilizam a mesma versão são desiguais nas administrações públicas. Os custos de manutenção das personalizações, de adição de novas personalizações para reflectir a evolução da regulamentação e de gestão destas personalizações durante uma actualização de versão são terríveis.

Um observador do Governo do Canadá sugeriu que todas as implementações do FreeBalance eram personalizadas de forma única. Apenas 1 de 28. O software foi configurado de forma diferente e havia alguns relatórios e interfaces personalizados, mas nenhum código personalizado no núcleo financeiro. 

Acoplamento apertado a frouxo

Os principais fornecedores de ERP vendem a noção de "soluções integradas". Isto faz sentido porque seria de esperar que os módulos de software do mesmo fornecedor se integrassem "sem problemas". Esta é uma afirmação que tem sido amplamente aceite. No entanto, os clientes de ERP descobrem que precisam de ferramentas de "gestão de metadados" para a integração. Porque, aparentemente, as definições de dados de um módulo não estão unificadas com as definições de outros.

Quando questionado sobre a "gestão de metadados" na FreeBalance Accountability SuiteAponto para os ecrãs de configuração. Não precisámos de encontrar uma solução ou "solução alternativa" para uma má concepção do software. (Alguns fornecedores de ERP de nível 2 têm metadados unificados).

A Gartner prevê que as soluções serão fracamente acopladas entre aplicações no local e na nuvem. Este método simples de integração permite flexibilidade entre as escolhas de software. Também é útil para aplicações personalizadas quando os regulamentos governamentais são demasiado exclusivos para aplicações comerciais. Acontece que o suporte de normas para integração elimina uma carga administrativa. (Alguns fornecedores de ERP e de nuvem estão dando suporte a padrões de integração e interfaces de acoplamento frouxo).

Mito do ERP único e abrangente para a Administração Pública

A Gartner salienta que os principais fornecedores de software empresarial efectuaram tantas aquisições que é impossível conseguir uma integração perfeita. Antigamente, os fornecedores de ERP vendiam essa noção para vender mais coisas ao mesmo cliente. (Um amigo meu chama-lhe LUFO ou "load up and -well, you'll need to fill in the blanks").

Os principais fornecedores de ERP adquiriram muitas aplicações horizontais e verticais. Tanto middleware. Com muitos parceiros comerciais que acrescentam funcionalidades adicionais. No entanto, não conseguem satisfazer plenamente as necessidades dos clientes numa vasta gama de sectores sem uma personalização dispendiosa.

Os departamentos de marketing destes grandes vendedores têm-se desviado muito do seu objectivo. Tem havido muito trabalho criativo para redefinir "inovação" como funcionalidades adicionais. Ou, "nuvem" como o que eles já têm.

Deparei-me com a ideia de que o ERP é "experimentado e verdadeiro". Já foi experimentado e é verdadeiramente complicado e dispendioso. Com elevadas taxas de insucesso e custos excessivos, nomeadamente na administração pública.

O mito da empresa

Já ouvi muitos discursos para profissionais de TI e financeiros em governos que falavam sobre a noção de tratar a administração pública como uma empresa. Tende a ter muita ressonância com os políticos. (Penso que se enquadra na narrativa de que os governos são ineficientes e precisam de uma mão política forte).

A noção de que uma classe de software tem a palavra "empresa" não significa que uma classe de software com a palavra "governo" não seja à escala da empresa. Francamente, se a categoria se tivesse chamado originalmente BRP, os grandes fornecedores estariam a dizer que os governos precisam de ser geridos como empresas.

A aspiração dos governos de quererem funcionar como empresas é errónea. As empresas funcionam para obter lucros. As administrações públicas funcionam para alcançar resultados sociais em que o conceito financeiro fundamental são os orçamentos. O software ERP tem prejudicado os governos que tentam gerir os orçamentos. Há países que têm ERP para a gestão financeira mas não o utilizam para a gestão orçamental. Há países que têm uma gestão orçamental automatizada, graças ao ERP, que é antiquada. E o número de vezes que ouvi falar de aplicações ERP que excederam inadvertidamente o orçamento é deprimente. (Um antigo responsável financeiro contou-me como foi ter de ir ao parlamento admitir que tinham ultrapassado o orçamento. Não foi nada agradável).

O que é que os governos devem fazer?

  1. Examinar a carteira de necessidades, não a encaixando num produto do fornecedor - utilizar o mapeamento de componentes comerciais processo para determinar onde o valor pode ser optimizado, o que deve ser vanilla, o que pode ser adquirido através da nuvem, o que pode ser personalizado e o que deve ser construído à medida
  2. Utilizar normas abertas e fontes abertas para desenvolvimento personalizado ou utilizar uma plataforma de software governamental
  3. Desenvolver novas normas para a integração que reconheçam as normas da indústria, como os serviços Web, e forneçam interfaces fracamente acopladas
  4. Desenvolva um plano de migração para abandonar qualquer aplicação que exija personalização numa linguagem proprietária - mude para Java, Ruby, Python, C++, até mesmo C#
  5. Desenvolver um plano de migração para passar a utilizar aplicações puramente Web - e não a actual geração de aplicações ERP que activam na Web o antigo código cliente/servidor
  6. Veja o investimento actual e o custo real em vez do custo potencial de comprar ou alugar algo novo e compare o Custo Total de Propriedade a 5 ou 10 anos. Um investimento de $1M em nova tecnologia pode poupar $500.000 em custos anuais para manter as luzes acesas no actual ERP
  7. Ser mais exigente com os fornecedores - trata-se de dinheiro público. Não aceitem esforços de segunda categoria. Não aceite a noção de que o fabricante de software não deve fazer parte da estrutura de governação. Qualquer fabricante que não esteja preparado para trabalhar consigo não tem qualquer compromisso.

Tópicos

Contacto