¿Hacia una declaración de dependencia de los proveedores de software? class=

¿Hacia una declaración de dependencia de los proveedores de software?

Publicado el en Tecnología gubernamental

De vez en cuando alguien capta el zeitgeist de las TI empresariales.  Frank ScavoPresidente de Strativa lo ha hecho en una entrada de su blog: ¿Es hora de declarar la independencia de los proveedores de software? (y un Podcast de Diginomica con una entrevista de Dennis Howlett). Frank ha sido testigo del aumento de empresas que desarrollan software a medida desde cero. ¿Ha cambiado el cálculo de crear o comprar? ¿Deberían las organizaciones declararse independientes de los proveedores de software independientes (ISV) como FreeBalance?
No se trata tanto de que las organizaciones declarar la independencia de los ISV, ya que éstos deben declarar la dependencia en los clientes.
[A continuación encontrará una Declaración de dependencia del cliente del proveedor de software de diez puntos; si no le interesa, pase por alto el contenido gubernamental].

Mercado público: construir o comprar

El mercado de TI gubernamental se distingue del empresarial por la mayor proporción de software a medida y heredado. Lo vemos en nuestro mercado principal: Planificación de Recursos Gubernamentales (GRP), especialmente en los países en desarrollo y las economías emergentes. Los expertos en Gestión de las Finanzas Públicas (PFM) consideran que la creación de Sistemas de Información para la Gestión Financiera (FMIS) a medida es una opción legítima:

En el podcast, Scavo señala que las organizaciones "no deberían construir un libro mayor". Sin embargo, el libro mayor es fundamental para la gestión financiera de las administraciones públicas. Esto se complica aún más por el hecho de que los gobiernos operan utilizando la contabilidad de compromisos.
Sé lo complicado que es construir un libro mayor con múltiples niveles de controles agregados de los compromisos, e informar del "saldo libre" presupuestario en tiempo real. Recuerdo una conversación con un consultor de una prestigiosa consultoría de desarrollo nacional cuando le dije que FreeBalance era totalmente compatible con la contabilidad de compromisos. Me preguntó si estaba seguro, porque la contabilidad de compromisos es muy complicada.
¿Por qué tantos respetados expertos en gestión de las finanzas públicas opinan que los gobiernos deberían considerar la posibilidad de redactar sistemas de contabilidad de compromisos a medida?

¿Cómo hemos llegado a esto?

  1. Poder asimétrico
    • Scavo describe cómo los ISV ejercen un enorme poder una vez instalado el software
    • Los gobiernos pueden verse atrapados en pilas tecnológicas de planificación de recursos empresariales (ERP) de bases de datos, middleware y lenguajes de programación propietarios (por no hablar del hardware para computación en memoria).
    • El software desarrollado a medida limita el poder de los vendedores sobre los gobiernosaunque esto puede ser un ilusión de control
  2. Mal comportamiento de los ISV
    • Scavo describe cómo algunos ISV aprovechan el poder asimétrico para actuar mal, lo que se denomina "wallet cracking" (acuñado por Brian Sommer), lo que incluye demandar a los clientes, cobrar por el acceso indirecto y aumentar los precios de mantenimiento.
    • Los gobiernos tienen la responsabilidad de gastar el dinero público de forma eficaz, para lograr una "buena relación calidad-precio" cuando búsqueda de rentas No se debe tolerar el comportamiento de los ISV
    • El software desarrollado a medida reduce las oportunidades de captación de rentas de los proveedoresaunque los gobiernos no pueden evitar por completo a los proveedores de tecnología
  3. Fracaso estrepitoso de un ERP en la administración pública
  4. Personalización del código
    • Scavo señala que gran parte de los productos comerciales disponibles en el mercado son "inflexibles" y requieren una adaptación significativa para satisfacer las necesidades (y las necesidades de los clientes). El Grupo Gartner ha llegado a considerar este software como "heredado")
    • Los requisitos gubernamentales difieren significativamente de las necesidades empresariales, lo que implica largos ciclos de personalización del código (hasta el punto de que muchos expertos en PFM lo denominan "Customized-off-the-Shelf"), que dan lugar a problemas de calidad, con el coste adicional de mantener y actualizar el código huérfano.
    • El software desarrollado a medida parece tener la misma complejidad para los gobiernos que el ERP. (aunque, como sostengo más adelante, la GRP es mucho menos compleja).
  5. Previsibilidad del software
  6. Mal comportamiento de SI
    • Scavo también señala que los grandes integradores de sistemas suelen ser los culpables de los fallos de implantación, ya que a menudo impulsan una personalización innecesaria para aumentar los ingresos. Michael Krigsman llama al "Triángulo del Diablo“
    • Los gobiernos suelen preferir contratar a grandes integradores de sistemas como mecanismo para reducir el riesgo
    • El software desarrollado a medida puede dejar fuera de juego a los grandes integradores de sistemasaunque muchos proyectos de aplicaciones a medida se subcontratan a IS

¿Se enfrentan los gobiernos a dos feas alternativas?

No se trata ni de ERP COTS ni de FMIS desarrollados a medida para las administraciones públicas. Existe la alternativa GRP, como nuestro FreeBalance Accountability Suite. Government Resource Planning es un software diseñado exclusivamente para la administración pública. FreeBalance es el primer GRP mundial con implantaciones en unos 30 países.
Algunos observadores asumen que GRP ha heredado todos los males de COTS. Otros asumen que los ISV de GRP no pueden competir con los grandes proveedores de ERP. He aprendido algunas lecciones en este asunto de GRP:

  1. Software de dominio único
    • En una ocasión, un alto funcionario del Ministerio de Hacienda se rió de mí en una conferencia cuando le dije que el software FreeBalance estaba configurado en su mayoría para cumplir los requisitos: esta configuración es la que acelera las implantaciones, reduce los costes de los proyectos (especialmente en comparación con las soluciones ERP), y permite flexibilidad futura para el cambio, algo que llamamos "activación progresiva“
    • Algunos observadores ven muy poca diferencia entre "configuración" y "personalización". diferencia significativadonde algunos vendedores denominan incorrectamente scripts de programación a la configuración y los generadores de código y las suites de flujo de trabajo se presentan a menudo como "configuración".
    • El hecho de centrarnos en la administración pública nos da una idea de la falta de dominio de muchas grandes empresas, como el gran proveedor de ERP que dice a los clientes del sector público que los controles presupuestarios de las partidas son una "práctica recomendada".
  2. Economías de escala
    • El mercado de los ERP despegó en los años 90 impulsado por el efecto 2000 y los ISV, que aprovecharon las funcionalidades de un mercado para ofrecer mayor calidad y mejor soporte, logrando economías de escala en comparación con los proveedores "best-of-breed". el software multimercado se ha hinchado
    • Las economías de escala disminuyen a medida que se accede a nuevos mercados: muchos vendedores han sido adquiridos para rellenar carteras de productos, creando lo que Ned Lily de xTuple llama al "Cementerio ERP", donde los grandes proveedores se enfrentan a una complejidad asombrosa para mantener tantas tecnologías adquiridas.
    • Los grandes proveedores utilizan bases de datos, middleware y lenguajes de programación patentados para bloquear a los clientes en pilas tecnológicas, lo que requiere una inversión significativa en un momento en que los ISV ágiles utilizan alternativas de código abierto.
  3. Producto y proceso integrales
    • Muchos ISV tratan de escalar a través de sus socios VAR e integradores de sistemas hasta el punto de que pierden el conocimiento del cliente y disminuyen las tasas de éxito de la implantación, lo que aleja a los ISV de la realidad del cliente.
    • Por otra parte, los ISV suelen buscar contratos de consultoría con clientes estratégicos para impulsar las prioridades de sus productos, y a menudo me pregunto cómo se siente la mayoría de los clientes cuando se les considera no estratégicos.
    • Vemos a todos los clientes como estratégicos, porque como nuestros Presidente y Director General, Manuel Pietra a menudo dice: "sólo tenemos un cliente por país: el gobierno, y estamos en él de por vida"

Declaración de dependencia del cliente

Muchos de los puntos se inspiran en la ¿Es hora de declarar la independencia de los proveedores de software? entrada de blog que incluye Web APis, código abierto, low-code/no-code.
Los vendedores independientes de software (ISV) deben admitir y comprometerse a servir primero a los clientes para construir negocios financieramente sostenibles.

  1. Responsabilidad social de las empresas: Los códigos de conducta de los ISV deberían reconocer que los clientes son la principal comunidad para los esfuerzos de responsabilidad social, y deberían prohibir comportamientos atroces de búsqueda de rentas.
  2. Accesibilidad ejecutiva: Los ejecutivos de los ISV deben ser accesibles a los clientes para mejorar el soporte de los productos, los procedimientos de la empresa y la comprensión de los clientes.
  3. Crear valor: Los ISV deben centrarse en la creación de valor como principal vehículo para la retención de clientes, y reconocer que el valor puede no provenir de la adición de características y puede provenir de algo fuera de los productos, como servicios o cambios en los procesos.
  4. Conocimientos especializados: Los ISV no deberían entrar en nuevos mercados verticales u horizontales a menos que adquieran experiencia en el desarrollo y la gestión de productos.
  5. Gobernanza de la aplicación: Los ISV deberían formar parte de la estructura de gobierno del programa para implantaciones importantes, en lugar de adoptar un enfoque de "no intervención", con el fin de orientar a socios y clientes.
  6. Adaptabilidad flexible: Los ISV deben reducir la carga de personalización del código mediante técnicas de configuración sin código y de bajo código para acelerar las implantaciones, mejorar los cambios futuros y reducir los costes de los clientes.
  7. Gestión de funciones: Los ISV deben comprometerse a reducir las necesidades de personalización del código de implementación con un marco claro de cómo se añadirán las funciones importantes a las hojas de ruta de los productos.
  8. Innovación cooperativa: Los proveedores de software independientes deberían comprometerse con la innovación impulsada por el cliente, con un marco claro de cómo se facilitará la innovación y el desarrollo cooperativos.
  9. Sistemas abiertos: Los ISV deben comprometerse a apoyar y utilizar sistemas abiertos de eficacia probada, incluido el código abierto, para ofrecer a los clientes más opciones tecnológicas y reducir al mismo tiempo la dependencia de los sistemas propietarios.
  10. Plataformas empresariales: Los ISV deben tratar de proporcionar API y reutilizar las plataformas de productos para permitir el desarrollo personalizado cuando esté justificado, eliminando al mismo tiempo el cobro a los clientes por funcionalidades ya pagadas.

Mi pensamiento sobre la declaración surgió de mi blog invitado de 2014 en ZDNet: Fallos informáticos, cambios de poder y redes sociales editado por Michael Krigsman. Los clientes pueden unirse aprovechando las redes sociales. En aquel momento señalé algunos cambios de comportamiento interesantes en las principales empresas de software empresarial:

Desde entonces, SAP ha cambiado su modelo de "acceso indirecto.

¿Es sólo un mundo de construcción frente a compra para los gobiernos?

Scavo señala que las plataformas empresariales de suites de aplicaciones, como el Plataforma de rendición de cuentas FreeBalancepuede aprovecharse para desarrollar software a medida. No se trata de una elección binaria entre construir o comprar. Existen alternativas híbridas de construcción y compra.
Muchos gobiernos buscan construir software utilizando un Entorno de Desarrollo Integrado (IDE) estándar utilizando una tecnología. Una "plataforma de gobernanza" es un enfoque híbrido que incluye todos los aspectos de construcción de las plataformas tecnológicas con la reutilización de las funciones de compra utilizadas por el GRP COTS. Además, el low-code/no-code puede permitir lo que antes era desarrollo a medida en GRP Suites como una alternativa más de compra que de construcción.
SIFM COTS o a medida: más allá de la elección binaria

¿Cómo pueden los gobiernos tomar la decisión correcta entre construir o comprar?

Scavo identifica una serie de factores que pueden ayudar a los gobiernos a tomar mejores decisiones de construcción frente a otras que he intentado esquematizar.
Construir, opciones híbridas y comprar

  1. Especificidad industrial: Muchas soluciones ISV se crearon para otros mercados. esto tiene importantes consecuencias para los gobiernos que tienen tantas necesidades únicas
    • Considere la posibilidad de comprar cuando se escribe software para la administración pública, el diseño del producto es importante
    • Considere la posibilidad de construir cuando no existe ningún programa informático disponible para la función gubernamental, especialmente cuando se trata de una necesidad estatutaria única
  2. Riesgo del producto: Construir una funcionalidad compleja, como un libro mayor, es arriesgado, y la flexibilidad para el cambio es importante - esto tiene importantes consecuencias para los gobiernos que esperan futuras modernizaciones y reformas
    • Considere la posibilidad de comprar cuando las necesidades de huella del producto son complicadas y se prevén cambios futuros
    • Considere la posibilidad de construir cuando las necesidades de huella de producto son modestas y se prevén pocos cambios en el futuro.
  3. Riesgo de integración: Los programas informáticos no deben considerarse silos de cajas negras - esto tiene importantes consecuencias para los gobiernos que carecen de metadatos y controles de integración en todos los ciclos presupuestarios
    • Considere la posibilidad de comprar cuando las necesidades de integración funcional son elevadas -por ejemplo, en la gestión de adquisiciones, activos e inversiones públicas, donde los desajustes de interfaz pueden tener consecuencias materiales, como retrasos en los pagos y superaciones ilegales de los presupuestos- o la información del sistema es fundamental para los responsables de la toma de decisiones y la transparencia fiscal.
    • Considere la posibilidad de construir cuando las funciones operan de forma autónoma con una necesidad limitada de contabilización en los sistemas financieros centrales.

Temas

Contacto