¿Fénix que cae o Fénix que asciende?
Noticias sobre el sistema central de nóminas del Gobierno de Canadá que utiliza el ERP PeopleSoft, cada vez más irónicamente llamado "Sistema de pago Phoenix", es desalentador. En CBC informa de que A finales de julio quedaban 228.000 casos. En el mes se añadieron miles de nuevos casos, lo que supuso una reducción neta de 18.000. La dirección En junio del año pasado, el Gobierno se comprometió a resolver los problemas antes de finales de octubre.. Mi feed de twitter muestra una gran frustración entre los funcionarios públicos. Muchos se preguntan por qué no se puede solucionar el problema.
Esta implantación de ERP se ha politizado mucho. La comunicación del Gobierno es vaga. La prensa política desconoce la tecnología y carece de capacidad para formular las preguntas adecuadas. El público no sabe cuál o cuáles son los problemas.
Creo que ya es hora de que el gobierno explique el problema o problemas tecnológicos subyacentes. De lo contrario, nos lleva a un sinfín de especulaciones. La falta de transparencia nos lleva a suponer que no hubo competencia alguna en la gestión del proyecto Phoenix por parte del Gobierno de Canadá. He conocido a muchos funcionarios públicos canadienses del ámbito de las tecnologías de la información que tienen una excelente capacidad de gestión de proyectos y conocimientos tecnológicos. Proyectos de ERP complicados y con tasas de éxito desalentadoras en la administración pública. Existen patrones que han surgido de otros fracasos de ERP gubernamentales: retraso en la entrega, exceso de presupuesto, pocos beneficios previstos... algunos proyectos abandonados. Es ilusorio pensar que supervisión ministerial hará resurgir al ave fénix mágicamente de sus cenizas.
Por lo tanto, voy a especular sobre lo que podría ser el problema basado en patrones en circunstancias similares, que cubren estos aspectos:
- Incentivos
- Calidad
- Gestión de proyectos
- Buenas prácticas
- Formación
- Tecnología ERP
- Sustitución
- Escalabilidad
Concluiré contemplando por qué a alguien debería importarle esto.
1. Cuando los incentivos conspiran para el fracaso de GovTech
El equipo gubernamental del proyecto recibía primas por cumplimiento de hitos. Se trata de un incentivo tóxico. Por un lado, anima a los funcionarios a jugar con los resultados y, por otro, crea un mecanismo de presión para que los proveedores den el visto bueno. Crea un entorno en el que los la definición de éxito puede verse comprometida. Esto puede llevar a los equipos de implementación a entregar un alcance y una calidad que ellos definen como exitosos, pero los usuarios no.
Los proveedores pueden aprovechar el mandato de entrega puntual para entregar con menor calidad o menor alcance. Los grandes proveedores saben cómo aprovechar los contratos. Tienen departamentos jurídicos que examinan los detalles del contrato. Según mi experiencia, siempre hay desfases entre los requisitos de las solicitudes de propuestas y las necesidades del gobierno. Puede que no se haya articulado bien el alcance de las funciones que han generado problemas. Puede haber un desfase importante entre el objetivo contractual legal fijado para el proveedor y la necesidad real.
Sospecho que los incentivos concedidos al equipo de implantación gubernamental implican que la dirección comprendía que el proyecto era arriesgado. Me parece que el planteamiento de contratación consistía en negar el fracaso mediante la contratación exclusiva de PeopleSoft, el principal paquete ERP de recursos humanos, y en asegurarse de que sólo las grandes empresas de integración de sistemas pudieran cumplir los requisitos del proveedor. Una forma de pensar del tipo "Nunca se ha despedido a nadie por comprar...".
2. ¿Está Phoenix atormentado por los bichos?
No está claro cómo se gestionaron 89.000 casos en junio. Mi impresión es que se gestionaron mediante soluciones alternativas en el sistema y mediante transacciones financieras fuera del sistema. ¿Hay fallos en el sistema que estén generando problemas? En caso afirmativo, ¿se deben a normas empresariales incorrectas o a determinadas funciones del sistema? La adición de 71.000 nuevos casos en un mes implica que no se han corregido los errores en las reglas o validaciones.
Muchas empresas de integración de sistemas culpan a los clientes de la falta de comunicación durante la recopilación de requisitos. Eso parece inconcebible en este caso. Las normas salariales del Gobierno de Canadá no son un misterio. Son complicadas, pero bien entendidas. Muchas personas empleadas por el gobierno las conocen, al igual que muchas del sector privado. Por ejemplo, muchos departamentos y organismos públicos han utilizado el software FreeBalance para elaborar presupuestos salariales y comprobar la calidad del sistema de nóminas heredado.
3. Los proyectos bajo presión se convierten en tragedias griegas
Existe una respuesta típica de la dirección a los proyectos sometidos a estrés: más supervisión. La supervisión supone más reuniones y más informes. Altera el flujo del proyecto. Aumenta la probabilidad de fracaso, como en una tragedia griega, al intentar evitar el fracaso. Es inevitable que Edipo mate a su padre y que su proyecto de ERP no se entregue a tiempo.
La gestión de proyectos en situaciones de estrés suele dar lugar a que se siga el criterio de la persona menos cualificada funcional y técnicamente del equipo: la persona más veterana. La voz del personal con conocimientos técnicos y funcionales suele quedar ahogada en la supervisión, el papeleo y los comités.
La tragedia de los comités es que informan a más comités. Las decisiones las toman cada vez más quienes carecen de conocimientos y contexto.
La respuesta típica de los comités es añadir más personal y trabajar más horas. Se añade más personal demasiado tarde en el proyecto. Este personal nunca se pone al día, interrumpiendo constantemente la productividad. Mientras tanto, trabajar más horas agrava los problemas de calidad, introduce nuevos errores y paraliza el proyecto.
4. Cuando las "mejores prácticas" son las peores
La contratación pública se basa a menudo en la noción de plazos previsibles alineados con el ciclo presupuestario. Los contratos gubernamentales típicos para software empresarial tienen hitos definidos basados en proyectos anteriores que utilizaron tecnologías diferentes. Los pagos se realizan en función de estos hitos definidos. Cualquier proyecto en el que los hitos no estén estrictamente definidos se considera arriesgado. Esto significa que la mayoría de los gobiernos evitan las metodologías ágiles en las adquisiciones complejas de TI. Las diferencias entre los requisitos y las necesidades reales se resuelven mediante órdenes de cambio. Las órdenes de cambio cuestan dinero. Se evitan los costes adicionales. A la larga, los costes son mucho más elevados debido a la falta de adecuación a las necesidades.
La previsibilidad también está asociada a la documentación y la supervisión. Las empresas de integración de sistemas dedican mucho tiempo a redactar análisis de carencias, especificaciones, casos de prueba y planes de aceptación, hasta el punto de que el éxito suele medirse por el número de árboles destruidos y el número de reuniones a las que se asiste. Esto compromete el éxito del proyecto. No se trata de evitar la documentación. Es que la documentación como ceremonia a menudo inhibe el éxito. Por ejemplo, el proceso de documentación suele utilizar como anclaje el sistema heredado en lugar del sustituto. Así, los equipos dedican más tiempo a determinar y documentar cómo el nuevo software funcionará como el software que se está sustituyendo. El enfoque más óptimo consiste en identificar los problemas que resolvía el software heredado y determinar si el software de sustitución resuelve esos problemas. A menudo resulta que el nuevo software tiene formas más elegantes de resolver los problemas.
Las administraciones públicas suelen especificar la composición del equipo del proyecto de integración de sistemas. Esto incluye el número de años de experiencia con el producto elegido, o en el ámbito de los RRHH. Esto puede no haber incluido la comprensión de la nómina en el Gobierno de Canadá, o los gobiernos en general. Además, los gobiernos suelen especificar el número de personas que debe aportar la empresa de integración. Estos equipos de proyecto pueden llegar a ser difíciles de manejar, lo que requiere operar en silos con frecuentes reuniones de contexto entre los grupos. Más no suele ser mejor en la implantación de software.
5. El enigma de la formación
Portavoces del Gobierno han indicado que la falta de formación fue uno de los causas profundas del problema. El gobierno se hizo cargo de la formación del integrador de sistemas, IBM. No es un planteamiento descabellado cuando el personal de la Administración tiene más experiencia práctica en nóminas. Pero muchos proyectos se resienten cuando se utiliza esta táctica para reducir costes. Los costes de formación pueden parecer terriblemente caros en una propuesta de gran envergadura. Es una partida presupuestaria que puede sobresalir como un pulgar dolorido, fácil de recortar para reducir costes.
Para obtener la máxima utilidad de cualquier programa informático empresarial es necesaria una formación suficiente. El personal del integrador de sistemas suele conocer mucho mejor el nuevo producto, y la formación impartida por el personal de la administración puede ser deficiente. Los programas de "formación de formadores" pueden hacer que los ciegos guíen a los ciegos. Además, la formación en software empresarial también presupone un mínimo de conocimiento del sector que puede no existir (aunque los clientes insistan en que ese conocimiento existe). A menudo es difícil para los funcionarios abstraer la formación genérica de un contexto empresarial en lecciones para el gobierno.
¿Es la falta de formación una causa fundamental? ¿Cómo puede la falta de formación dar lugar a cálculos no válidos que incluyan que algunos funcionarios no cobren? Debe haber una validación de la introducción de datos e informes de excepción que indiquen que no se está pagando a los funcionarios. Los informes presupuestarios también deberían mostrar cualquier diferencia entre la paga prevista y la real. Parece que la falta de formación contribuye a cientos de miles de casos, pero no es la causa principal.
6. Cuando se sustituye la tecnología heredada por un ERP heredado
Existe un malentendido común sobre el proyecto Phoenix. La mayoría de los observadores creen que el sistema fue "desarrollado" por IBM. El Gobierno de Canadá contrató exclusivamente a PeopleSoft. Es un pronunciamiento oficial del Consejo del Tesoro. IBM se convirtió en la empresa de integración de sistemas tras un proceso competitivo. El problema es que el gobierno está intentando eliminar la deuda técnica causada por el software heredado mediante la adquisición de ERP heredados. Esto significa que caer en "quiebra técnica"se ha retrasado. Pero el reloj de la tecnología de la información no se detiene.
De poco sirve sustituir los sistemas antiguos por lo que la Grupo Gartner llamadas "ERP heredado", que requiere más personalización que las aplicaciones empresariales más modernas. Las administraciones públicas suelen requerir más personalizaciones debido a normativas legislativas únicas. Estas personalizaciones introducen código nuevo. Cuantos más cambios en el código, mayor es la posibilidad de que surjan problemas de calidad. Más errores. Pérdida de integridad de los datos.
El problema de la calidad de los sistemas ERP altamente personalizados se agrava con el tiempo. Los cambios en la legislación introducen más personalización. La personalización dificulta las actualizaciones del producto, ya que es necesario examinar detalladamente el código huérfano para ver qué hay que cambiar. Si la personalización es una de las causas de este problema, el los problemas sólo van a empeorar.
7. Mito de la sustitución y la cartera
La mejora de la integración y la reducción de los costes totales son propuestas de valor típicas de muchos proyectos de ERP a gran escala. Sin embargo, muchos proyectos gubernamentales diseñados para sustituir varios sistemas por uno solo dan lugar a importantes sobrecostes. En estas circunstancias, podría haber problemas de gestión del cambio. Tengo la sensación de que los responsables de TI a menudo no entienden por qué se añadieron diferentes sistemas en primer lugar. Puede que estos sistemas necesiten una funcionalidad importante que aumente la huella de la personalización.
Es lógico que las funciones informáticas centralizadas logren economías de escala positivas que muchos sistemas individuales. Es razonable esperar que la formación y el mantenimiento de una única solución integrada sean menores que los de múltiples soluciones que funcionan de distintas maneras con tecnologías diferentes. Pero en la práctica no siempre es así. En primer lugar, los sistemas ERP suelen ser más complejos. Según nuestra experiencia, es posible que se necesite más personal para operar y mantener un gran sistema ERP que una colección de aplicaciones personalizadas y COTS. En segundo lugar, muchas soluciones ERP no están unificadas. Esto se debe a las numerosas adquisiciones realizadas por los proveedores de ERP, de modo que existen muchas tecnologías y bases de código en estas soluciones. Los proveedores de ERP despliegan versiones monolíticas de módulos que utilizan la misma tecnología y código base. Esto requiere una gestión de metadatos y estrategias de integración cuando se utiliza el mismo software porque la definición de algo en un módulo difiere de la de otros. El coste total a largo plazo puede ser mayor con un único ERP heredado que con una cartera de aplicaciones.
También hay algo fundamentalmente diferente en los sistemas ERP para todo el gobierno. En muchas organizaciones gubernamentales se producen retornos negativos cuando los departamentos y organismos más pequeños tienen que lidiar con procesos estandarizados muy complejos diseñados para departamentos mucho más grandes. También puede introducir más carga de trabajo para los departamentos y organismos con procesos legítimamente únicos. Por ejemplo, una entidad gubernamental que se ocupa de cuestiones de seguridad nacional tiene criterios de contratación muy complejos.
8. Cuando escalar no escala
Los grandes sistemas de nóminas tienen problemas de escalabilidad. Esto se debe a que cualquier nómina requiere miles de reglas. En abril de 2016 había más de 258.000 funcionarios públicos federales en el Gobierno de Canadá. Esto no incluye el número de funcionarios jubilados que reciben pensiones. Por lo tanto, es muy importante garantizar el escalado del sistema para los picos de actividad de las nóminas. PeopleSoft se basa en tecnología patentada. El escalado de PeopleSoft probablemente requiera algún método propio de equilibrio de carga para los procesos por lotes. Este método puede no ser elegante comparado con algunas de las técnicas disponibles hoy en día. Sin embargo, debería ser escalable a menos que, como ocurre con algunas implantaciones de Shared Services Canada, no se disponga de recursos informáticos suficientes.
¿Por qué es importante?
Phoenix es uno de los muchos grandes proyectos informáticos del Gobierno de Canadá que no han cumplido las expectativas, junto con la proyecto único de gestión de contenidos webEl Proyecto de correo electrónico de los Servicios Compartidos de Canadá, y otros Esto es dinero público que se ha desperdiciado. Parece que estas implantaciones costarán al Gobierno más que si se mantuviera el statu quo. Esto no augura nada bueno para los futuros grandes proyectos informáticos del Gobierno de Canadá.
Algunos observadores piensan que los funcionarios públicos tienen demasiados derechos. Una persona me respondió en Twitter que debería haber muchos menos empleados en Canadá. Su argumento parecía ser que los funcionarios públicos que pierden sus casas o no pueden pagar sus medicinas o su educación se lo tienen merecido. Parece haber una falta de empatía fuera de la Región de la Capital Nacional. Esa noción de burócratas improductivos sin nombre es un mito. Es cierto que los funcionarios públicos canadienses tienen buenos planes de pensiones, pero muchos ganan menos que sus homólogos del sector privado.
Mi observación es que los funcionarios públicos han pasado por oleadas de recortes, reducciones de plantilla, servicios compartidos y externalización hasta el punto de que sería difícil distinguir la calidad y la eficiencia del trabajo entre el sector público y el privado. Claro que hay burócratas oficiosos en el gobierno, pero también los hay en el sector privado. Empresas como Blackberry y Blockbuster cometieron errores críticos.
La proporción de personal con una misión en la Administración es mucho mayor que en el sector privado. La mayoría de los funcionarios que he conocido están ahí para marcar una diferencia positiva. Es algo de lo que rara vez se informa. Debería hacerse.