¿Ha quedado oficialmente obsoleto el gran ERP para los servicios compartidos de la administración pública? class=

¿Ha quedado oficialmente obsoleto el gran ERP para los servicios compartidos de la Administración?

Doug Hadden, Vicepresidente de Productos

Gartner ha puesto el último clavo en el ataúd del gran valor del software de planificación de recursos empresariales (ERP). Cuando Gartner dice que el software ERP principal "muy personalizado" es ahora "heredado", está oxidado. ¿Qué significa esto para los servicios compartidos de ERP de todo el gobierno? Mala idea. Mala relación calidad-precio. Gartner lo llama "ancla". (Me recuerda a la crítica de un automóvil de Europa del Este allá por los 80: "acelera como si estuviera encadenado al garaje".

Gartner afirma que el sector del software empresarial ha entrado en una fase "postmoderna". Vamos a "deconstruir" lo que dice Gartner. Y sus implicaciones para los servicios compartidos de la Administración.

Gran personalización

Gran personalización del ERP = falta de flexibilidad para cambiar y adaptarse a la reforma legal y a la mejora de los procesos fiscales. La idea de que los servicios compartidos de ERP proporcionan agilidad es una mito. La estandarización del ERP puede reducir los costes de administración en el gasto de flexibilidad. En cambio, el software de planificación de recursos gubernamentales (GRP) no requiere una gran personalización: todo es cuestión de configuración.

Y no se deje engañar por la noción de implantaciones "vainilla" en la administración. Resulta chocante lo dispares que son los sistemas departamentales del mismo fabricante que utilizan la misma versión en las administraciones públicas. El coste de mantener las personalizaciones, añadir nuevas personalizaciones para reflejar las cambiantes normativas y gestionar estas personalizaciones durante una actualización de versión es horrendo.

Un observador del Gobierno de Canadá sugirió que todas las implantaciones de FreeBalance estaban personalizadas de forma única. Sólo 1 de 28. El software estaba configurado de forma diferente y había algunos informes e interfaces personalizados, pero no código personalizado en el núcleo financiero. 

Acoplamiento estrecho a débil

Los principales proveedores de ERP venden la noción de "soluciones integradas". Esto tiene sentido porque uno pensaría que los módulos de software del mismo proveedor se integrarían "sin problemas". Es una afirmación muy extendida. Sin embargo, los clientes de ERP descubren que necesitan herramientas de "gestión de metadatos" para la integración. Porque, al parecer, las definiciones de datos de un módulo no están unificadas con las definiciones de otros.

Cuando se le preguntó por la "gestión de metadatos" en el FreeBalance Accountability Suite...señalo las pantallas de configuración. No necesitábamos encontrar una solución o "workaround" para un mal diseño de software. (Algunos proveedores de ERP de nivel 2 tienen metadatos unificados).

Gartner predice que las soluciones estarán poco acopladas entre las aplicaciones in situ y en la nube. Este método de integración ligera permite flexibilidad entre las opciones de software. También es útil para aplicaciones personalizadas cuando las normativas gubernamentales son demasiado exclusivas para las aplicaciones comerciales. Resulta que el soporte de estándares para la integración elimina una carga administrativa. (Algunos proveedores de ERP y de aplicaciones en la nube admiten estándares de integración e interfaces poco acopladas).

El mito del ERP único para la administración pública

Gartner señala que los principales proveedores de software empresarial han realizado tantas adquisiciones que es imposible lograr una integración perfecta. Los proveedores de ERP vendían antes esta idea para vender más cosas al mismo cliente. (Un amigo mío lo llama LUFO o "carga y -bueno, tendrás que rellenar los espacios en blanco").

Los principales proveedores de ERP han adquirido tantas aplicaciones horizontales y verticales. Con tanto middleware. Con muchos socios comerciales que añaden funcionalidades adicionales. Sin embargo, no pueden satisfacer plenamente las necesidades de los clientes en una amplia gama de sectores sin una costosa personalización.

Los departamentos de marketing de estos grandes proveedores han cometido muchos errores. Ha habido mucho trabajo creativo para redefinir la "innovación" como características adicionales. O "nube" como lo que ya tienen.

Me he encontrado con esta opinión de que el ERP es "probado y verdadero". Se ha probado y es realmente complicado y caro. Con altos índices de fracaso y sobrecostes, sobre todo en la administración pública.

El mito de la empresa

He escuchado muchos discursos para profesionales de la informática y las finanzas en los gobiernos hablando de la noción de tratar al gobierno como una empresa. Suele tener mucha resonancia entre los políticos. (Creo que encaja con la narrativa de los gobiernos como ineficaces y necesitados de una mano política fuerte).

El hecho de que una clase de software lleve la palabra "empresa" no significa que una clase de software con la palabra "gobierno" no sea de escala empresarial. Francamente, si la categoría se hubiera llamado originalmente BRP, los grandes proveedores estarían hablando de cómo los gobiernos necesitan ser gestionados como empresas.

La aspiración de los gobiernos de funcionar como empresas es errónea. Las empresas funcionan para obtener beneficios. Los gobiernos funcionan para lograr resultados sociales, donde el concepto financiero clave son los presupuestos. El software de planificación de recursos empresariales (ERP) ha puesto trabas a los gobiernos que intentan gestionar sus presupuestos. Hay países que disponen de ERP para la gestión financiera pero no lo utilizan para la gestión presupuestaria. Hay países que tienen una gestión presupuestaria automatizada, gracias al ERP, que está anticuada. Y el número de veces que he oído hablar de aplicaciones ERP que superan inadvertidamente el presupuesto es deprimente. (Un antiguo responsable de finanzas me contó lo que era ir al parlamento a admitir que habían gastado por encima de lo votado. No fue agradable).

¿Qué deben hacer los gobiernos?

  1. Examinar la cartera de necesidades no metiéndola con calzador en un producto de un proveedor - utilizar el mapeo de componentes empresariales proceso para determinar dónde se puede optimizar el valor, qué debería ser vainilla, qué podría adquirirse a través de la nube, qué podría personalizarse y qué debería construirse a medida.
  2. Utilizar estándares abiertos y código abierto para el desarrollo a medida o utilizar una plataforma de software gubernamental
  3. Desarrollar nuevas normas de integración que reconozcan los estándares del sector, como los servicios web, y ofrezcan interfaces de acoplamiento flexible.
  4. Desarrollar un plan de migración para abandonar cualquier aplicación que requiera personalización en un lenguaje propietario: pasar a Java, Ruby, Python, C++, incluso C#.
  5. Desarrollar un plan de migración para pasar a aplicaciones web puras, no a la actual generación de aplicaciones ERP que habilitan para la web el antiguo código cliente/servidor.
  6. Analice la inversión actual y el coste real en lugar del coste potencial de comprar o alquilar algo nuevo y compare el coste total de propiedad a 5 o 10 años. Una inversión de $1M en nueva tecnología podría ahorrar $500.000 en costes anuales sólo por mantener las luces encendidas del ERP actual.
  7. Sea más exigente con los proveedores: es dinero público. No acepte esfuerzos de segunda categoría. No aceptes la idea de que el fabricante de software no debe estar en la estructura de gobierno. Cualquier fabricante que no esté dispuesto a trabajar con usted no tiene ningún compromiso.

Temas

Contacto