Espectacular noticia la que encontramos en theregister.com sobre un acuerdo prejudicial de la Universidad de…
Espectacular noticia la que encontramos en theregister.com sobre un acuerdo prejudicial de la Universidad de California con Oracle en un litigio monumental sobre el proyecto ERP en el que se encuentra la Universidad.
La universidad alegó que el software en la nube no podía satisfacer sus necesidades tras años de retrasos en la revisión de los sistemas financieros.
UCLA y Oracle han resuelto una disputa sobre un problemático proyecto ERP originalmente presupuestado en $120 millones, con el proveedor condonando $1.31 millones en tarifas pendientes y otorgando $3.1 millones en créditos contra futuros cargos.
En mayo, el Comité de Cumplimiento y Auditoría de la Universidad de California recomendó un acuerdo antes de UCLA con Oracle, que la Junta de Regentes aprobó.
Según documentos publicados en respuesta a una solicitud de la Ley de Registros Públicos de California, UCLA dejó de pagar su suscripción a Oracle en septiembre de 2024 debido a lo que describió como deficiencias en la funcionalidad de gestión de subvenciones.
UCLA y Oracle firmaron su primer acuerdo relacionado con el proyecto –llamado Ascend– en noviembre de 2017. El proyecto tenía una fecha revisada de entrada en funcionamiento para enero de 2025, pero se detuvo a mediados de 2024. El acuerdo registra la alegación de UCLA de que «los Servicios ERP en la Nube no funcionaron como se garantizaba en el Acuerdo de Oracle».
«Los Servicios ERP en la Nube carecían de suficiente funcionalidad para satisfacer los requisitos de la Universidad y no pudieron ser utilizados por la Universidad como se esperaba», decía el documento, visto por The Register.
Continuaba diciendo que «la Universidad incurrió en costes y retrasos debido a la incapacidad de los Servicios ERP en la Nube para satisfacer los requisitos de la Universidad». Añadía: «Como resultado, Oracle incumplió el Acuerdo de Oracle».
Bajo el acuerdo, UCLA aceptó pagar a Oracle $350,000 de los $1.66 millones en facturas pendientes. Oracle luego condonó el saldo restante –$1.31 millones– y abonó $3.1 millones contra futuras tarifas de Oracle. Estos créditos expiran a finales de mayo de 2028.
El acuerdo establece que la universidad no debe hacer declaraciones públicas sobre sus términos, los cuales deben permanecer confidenciales, aunque ambas partes reconocieron que UCLA está sujeta a la Ley de Registros Públicos de California.
The Register ha solicitado comentarios a Oracle.
El acuerdo fue obtenido por el residente de California Eric Guyer, fundador de la consultoría independiente de costes de Oracle, Advizant.
En una publicación en redes sociales, dijo que los créditos sugerían que UCLA continuaría con el proyecto de alguna forma, con Oracle como el proveedor principal.
Guyer sugirió que Oracle probablemente descontó su software para conseguir el «codiciado» logo de UCLA. Estimó el valor total de la suscripción en alrededor de $12 millones durante diez años.
Dijo que Oracle tiende a actuar de manera decisiva cuando las facturas impagas con términos contractuales claros la acorralan. «Esto es raro a pesar de la fama de su naturaleza litigiosa. Todos tienen un límite. En cualquier caso, la reclamación de UCLA probablemente fue a Oracle porque era el más fácil de señalar con el dedo: los consultores venden esfuerzo, no resultados, y al personal interno solo se le puede despedir».
Sin embargo, dijo que el cliente promedio no debería concluir que reclamar un incumplimiento y detener el pago sea aconsejable.
«Puede ser efectivo, pero es un camino extremadamente doloroso», afirmó. «En este caso raro, Oracle aceptó ceder ante una implementación mal planificada a cambio del silencio de UCLA en el ferozmente competitivo mercado de la educación superior. En otras luchas públicas de implementación, Oracle atacó primero o contrademandó, con comunicados de prensa a juego».
UCLA atiende a unos 49,000 estudiantes y gestiona un presupuesto de alrededor de $11 mil millones.
Un informe de 2025 [PDF] presentado al Comité de Finanzas y Estrategias de Capital de la Junta de Regentes de la Universidad de California decía que entre los «Principales Problemas, Riesgos y Desafíos» que enfrentaba el liderazgo del proyecto de UCLA se encontraba «la falta de respuesta de Oracle –particularmente en lo que respecta a los costes de licencias y soporte». Añadió que el presupuesto original del proyecto de $120 millones se revisó a la baja a $98.9 millones, con $13.5 millones restantes a 31 de diciembre de 2024.
El informe, que cubría el período hasta diciembre de 2024, decía que el proyecto comenzó en abril de 2018 y se esperaba originalmente que finalizara en julio de 2020. El documento lo describió como una «iniciativa integral de transformación empresarial» para modernizar las operaciones financieras, presupuestarias y de administración de investigación de la universidad, migrando a Oracle Cloud SaaS. También incluyó la adaptación de cualquier sistema conectado al sistema financiero principal.
El módulo de adquisiciones, BruinBuy Plus, entró en funcionamiento en enero de 2024, pero la entrada en funcionamiento principal de «Oracle Financials se ha pausado desde el 2 de agosto [de 2024] y está siendo objeto de una evaluación del programa», decía el documento.
Entre los planes de mitigación en la revisión se encontraba «finalizar la decisión de continuar con el proveedor actual o explorar alternativas» basándose en una reevaluación de la herramienta y el proveedor.
Según el documento del acuerdo, la Universidad comunicó a Oracle por correo electrónico el 20 de junio de 2025 que la «Universidad quería rescindir el proyecto Ascend y los Servicios ERP en la Nube».
En mayo, un portavoz de UCLA dijo en un comunicado a The Register: «La Universidad continúa evaluando el camino más efectivo para la modernización de los sistemas financieros».
Según los términos del acuerdo de conciliación, la Universidad y Oracle han acordado no presentar más reclamaciones por daños relacionados con la disputa contractual, y ninguna de las partes ha admitido responsabilidad.
Según un informe del periódico del campus Daily Bruin, UCLA seguía utilizando software de sistemas financieros heredados diseñado en los años 80, cuando el presupuesto era solo el siete por ciento de su tamaño actual. Era una «reliquia antigua de sistema» basada en mainframe, dijo al periódico la exmiembro del comité directivo del proyecto Reem Hanna-Harwell.
El Daily Bruin informó que se habían gastado al menos $213 millones y citó una presentación en asamblea de mayo de 2024 que proyectaba costes totales de aproximadamente $286 millones.
¿Qué piensa Gemini del caso?
Gemini dixit:
El artículo aporta bastantes pistas sobre las causas del fracaso, y al combinarlas con los informes de auditoría citados se aprecia que no fue un simple problema técnico, sino una combinación de deficiencias funcionales, gestión del proveedor, retrasos y escalada de costes.
1. El ERP de Oracle no cubría los requisitos funcionales de UCLA
Esta es la acusación central de la universidad.
Según el acuerdo, UCLA sostuvo que:
«ERP Cloud Services lacked sufficient functionality to meet the University’s requirements»
Es decir, la solución Oracle Cloud ERP no disponía de capacidades suficientes para satisfacer las necesidades de UCLA, especialmente en áreas relacionadas con la gestión de subvenciones e investigación. La universidad llegó a afirmar que el sistema «no podía utilizarse como se esperaba».
2. Problemas en la gestión de subvenciones (Grants Management)
UCLA dejó de pagar sus suscripciones de Oracle en septiembre de 2024 debido a lo que describió como carencias en la funcionalidad de grants management. En una universidad de investigación de primer nivel, esta capacidad es crítica porque gestiona miles de proyectos financiados por organismos públicos y privados.
Esto sugiere que el ERP estándar no se adaptaba adecuadamente a la complejidad de los procesos de investigación académica.
3. Retrasos masivos del programa
La transformación ERP comenzó en 2018 y originalmente debía finalizar en julio de 2020. Sin embargo:
- El proyecto seguía en marcha en 2024.
- El despliegue principal de Oracle Financials fue suspendido el 2 de agosto de 2024.
- La fecha revisada de puesta en marcha era enero de 2025.
- El programa quedó paralizado para ser reevaluado. [UCLA settl…f the bill]
Para un proyecto inicialmente previsto en unos dos años, hablamos de varios años adicionales de retraso.
4. Escalada de costes
El proyecto se presupuestó inicialmente en 120 millones de dólares. Posteriormente:
- El artículo menciona un presupuesto revisado de 98,9 millones.
- El periódico universitario Daily Bruin informó de que ya se habían gastado al menos 213 millones.
- Una presentación interna proyectaba costes totales cercanos a 286 millones de dólares. [UCLA settl…f the bill]
Aunque las cifras proceden de fuentes distintas, todas apuntan a un fuerte sobrecoste respecto a las expectativas iniciales.
5. Falta de respuesta del proveedor
Un informe presentado al Consejo de Regentes de la Universidad de California identificó explícitamente como uno de los principales riesgos:
«Oracle’s lack of responsiveness»
especialmente en lo relacionado con:
- costes de licencias
- soporte del proveedor [UCLA settl…f the bill]
Este punto es particularmente interesante porque aparece en un informe de gobierno del proyecto, no únicamente en las reclamaciones legales posteriores.
6. Complejidad extrema de la transformación
El proyecto Ascend no consistía solo en implantar un ERP.
La iniciativa buscaba:
- Modernizar finanzas.
- Presupuestos.
- Administración de investigación.
- Integrar o sustituir numerosos sistemas satélite conectados al sistema financiero principal. [UCLA settl…f the bill]
Este es un patrón común en muchos fracasos ERP: el proyecto se convierte en una transformación institucional completa y la complejidad crece mucho más de lo previsto.
7. Modernizar un entorno heredado muy antiguo
UCLA seguía utilizando sistemas financieros diseñados en los años 80.
Un antiguo miembro del comité de dirección describió la plataforma heredada como:
«an ancient relic of a system»
La migración desde un entorno tan antiguo suele implicar:
- procesos muy personalizados,
- dependencias ocultas,
- problemas de calidad de datos,
- resistencia al cambio organizativo.
Mi lectura del caso
Más allá de la disputa legal, el patrón recuerda a otros fracasos ERP universitarios y del sector público:
- Se subestima la complejidad de la institución.
- Se confía en que el SaaS estándar cubrirá procesos muy específicos.
- Aparecen gaps funcionales.
- Se introducen personalizaciones y soluciones alternativas.
- Se acumulan retrasos y costes.
- La relación cliente-proveedor se deteriora.
- Finalmente se renegocia o se replantea el proyecto.
Lo más llamativo del caso UCLA es que Oracle aceptó créditos de 3,1 millones de dólares y la cancelación de 1,31 millones en facturas pendientes, algo poco habitual en disputas ERP de esta magnitud, lo que indica que ambas partes tenían incentivos para evitar que el conflicto llegara a juicio. [UCLA settl…f the bill]
El Informe de Auditoría
Aunque ni Gemini ni yo hemos logrado encontrar el PDF de la auditoría sobre el estado del programa Ascend y que fue presentado al Comité de Estrategias Financieras y de Capital de los Regentes de la Universidad de California, a partir de las referencias cruzadas, se pueden extraer varias conclusiones sólidas sobre las causas del fracaso: [theregister.com], [assets.the…gister.com]
Principales hallazgos del informe
1. El proyecto estaba prácticamente seis años retrasado
El programa Ascend comenzó en abril de 2018 y tenía una fecha objetivo de finalización en julio de 2020. Sin embargo, en 2026 seguía sin completarse y había sido pausado desde agosto de 2024 para una reevaluación completa. [theregister.com], [assets.the…gister.com]
Esto indica un problema estructural de planificación y ejecución, no un simple retraso operativo.
2. Oracle fue identificado explícitamente como un riesgo del proyecto
Uno de los puntos más relevantes del informe es que la dirección del proyecto incluyó entre los principales riesgos:
«Oracle’s lack of responsiveness, particularly regarding licensing costs and support»
Es decir:
- escasa capacidad de respuesta del proveedor,
- problemas relacionados con licencias,
- problemas de soporte. [theregister.com], [assets.the…gister.com]
Es poco habitual que un proveedor aparezca formalmente en un informe de riesgos de esta forma.
3. La universidad llegó a cuestionar la continuidad con Oracle
El informe menciona un plan de mitigación que contemplaba:
- finalizar la decisión sobre continuar con el proveedor actual o explorar alternativas. [theregister.com], [assets.the…gister.com]
Cuando un proyecto ERP entra en una fase en la que se evalúa sustituir al proveedor principal, normalmente significa que la confianza entre cliente y proveedor se ha deteriorado gravemente.
4. El despliegue financiero principal fue suspendido
Aunque el módulo de compras BruinBuy Plus sí entró en producción en enero de 2024, el componente principal:
Oracle Financials fue suspendido el 2 de agosto de 2024 y pasó a una fase de evaluación del programa. [theregister.com], [assets.the…gister.com]
Esto sugiere que los problemas más graves se concentraban en el núcleo financiero de la solución.
5. Complejidad excesiva del alcance
Ascend no era una actualización tecnológica simple.
El propio proyecto se definía como:
una iniciativa integral de transformación empresarial para modernizar las operaciones financieras, presupuestarias y de administración de investigación mediante Oracle Cloud SaaS. [theregister.com], [assets.the…gister.com]
Además, incluía la adaptación o sustitución de numerosos sistemas conectados al ERP principal. [theregister.com], [assets.the…gister.com]
Este patrón es muy similar a otros grandes fracasos ERP del sector público y universitario.
6. Dependencia de sistemas heredados extremadamente antiguos
La universidad seguía operando sobre sistemas financieros desarrollados en los años 80. [theregister.com], [dailybruin.com]
Migrar desde una plataforma tan antigua suele provocar:
- procesos altamente personalizados,
- dependencias no documentadas,
- dificultades de integración,
- resistencia organizativa al cambio.
7. Replanificaciones continuas
Según la investigación del periódico universitario Daily Bruin, el proyecto quedó paralizado en 2019 y pasó por múltiples ciclos de replanteamiento antes del relanzamiento como «Ascend 2.0» en 2022. [dailybruin.com]
El artículo cita literalmente:
«One timeline after the other was not met» («No se cumplía un calendario tras otro»). [dailybruin.com]
8. Escalada masiva de costes
Los datos recopilados por Daily Bruin muestran:
- Presupuesto inicial: 120 millones USD.
- Gasto estimado realizado: al menos 213 millones USD.
- Estimación total proyectada: aproximadamente 286 millones USD. [dailybruin.com]
Esto representa uno de los indicadores más claros de un programa en dificultades.
Mi conclusión como caso de estudio ERP
Este caso encaja perfectamente en el patrón de los grandes fracasos ERP institucionales:
| Factor | Evidencia |
|---|---|
| Alcance demasiado ambicioso | Transformación financiera, presupuestaria e investigación simultáneamente |
| Sistema heredado muy antiguo | Plataforma financiera de los años 80 |
| Mala alineación funcional | UCLA alegó que Oracle no cubría requisitos clave |
| Problemas con el proveedor | Riesgo formal por «lack of responsiveness» |
| Retrasos extremos | De 2020 a más allá de 2026 |
| Sobrecostes masivos | De 120 M$ a una proyección de 286 M$ |
| Pérdida de confianza | Evaluación de alternativas a Oracle |
| Acuerdo legal posterior | Resolución extrajudicial y concesión de créditos por Oracle |
Lo que hace especialmente interesante este caso es que la causa raíz no parece ser una única decisión errónea, sino la combinación de complejidad organizativa + brechas funcionales del SaaS + deterioro de la relación cliente-proveedor, una combinación muy frecuente en los grandes proyectos ERP del sector público.