1 puntos por GN⁺ 2024-09-20 | 1 comentarios | Compartir por WhatsApp
  • CUNYFirst era un proyecto para integrar la administración de la universidad y sus campus en un único sistema empresarial, pero recibió críticas porque el control central de CUNY Central habría prevalecido sobre la eficiencia
  • Para implementarlo correctamente se necesitaban hasta 1.000 millones de dólares, pero CUNY propuso un presupuesto menor, y solo quedó Oracle-PeopleSoft, que puso como condición configurarlo únicamente, sin personalizaciones
  • CUNY pagó a Oracle alrededor de 600 millones de dólares (US$600m), pero el trabajo se volvió más ineficiente, hasta el punto de requerir personal adicional para tareas que antes estaban automatizadas
  • En la operación real aparecieron problemas como una interfaz obsoleta, la renumeración de cursos, un modelo de seguridad que no encajaba con CUNY y una estructura de RR. HH. que tenía dificultades para manejar a personas con varios roles en distintos campus
  • Se espera que Brooklyn College y otros campus de la Wave 3 puedan adaptarse, pero sufrirán mayores molestias porque desaparecerán los sistemas complementarios existentes para horarios y reportes de calificaciones

Sistema administrativo integrado y controversia por el control central

  • El punto de partida de CUNYFirst era crear un sistema empresarial integrado que abarcara los procesos de trabajo de la universidad y sus campus
  • En principio, era una idea que podía reducir el costo de mantener sistemas duplicados de terceros y ofrecer mejor acceso a la información a la administración, el personal, los docentes y los estudiantes
  • Sin embargo, surgieron críticas de que la motivación estaba más inclinada al control sobre el conjunto de las actividades universitarias que a la eficiencia
    • La lógica era que, al controlar el catálogo, el bulletin, las constancias de calificaciones y los mecanismos relacionados, también se podía controlar en la práctica el currículo
    • CUNYFirst fue visto como uno de los medios para impulsar Pathways
    • También hubo críticas de que existía el objetivo de identificar y acceder a los fondos discrecionales de cada universidad

Una estructura de “solo configuración” creada por las condiciones del contrato

  • En las negociaciones previas a la compra de CUNYFirst, se planteó que una implementación adecuada requeriría hasta 1.000 millones de dólares
  • CUNY Central ofreció una suma mucho menor, y todos los oferentes salvo uno se retiraron
  • El que quedó, Oracle-PeopleSoft, advirtió que con ese nivel de presupuesto no personalizaría el sistema y solo lo configuraría
  • Debido a esta condición, en lugar de que Oracle se ajustara a la forma de trabajo existente de CUNY, los procesos de trabajo pasaron a ajustarse a Oracle
  • Como resultado, algunas funciones existentes desaparecieron, y el personal, los docentes y los estudiantes tuvieron que adaptarse a la nueva forma de trabajar

La carga operativa después de los 600 millones de dólares

  • CUNY pagó a Oracle alrededor de 600 millones de dólares por este sistema
  • El costo real superó el monto pagado a Oracle
    • Porque los procesos se volvieron más ineficientes
    • Surgieron situaciones en las que hubo que contratar a más personas para realizar tareas que antes estaban automatizadas
  • La carga se concentró en los HEOs y en parte del personal administrativo
    • Las personas que realmente sostienen la operación de la universidad asumieron trabajo adicional
    • Los HEOs tuvieron que realizar varios tipos de trabajo extra sin compensación
    • Parte de la carga surgió durante la transición, y otra parte provino de la propia estructura del sistema

Problemas revelados en el uso real

  • Se considera que CUNYFirst funciona, pero funciona mal
  • La interfaz recibió críticas por parecer una actualización de la tecnología 3270 bi-synch de principios de los años 90
    • Se evaluó que ni siquiera llegaba a Web 1.0, mucho menos a Web 2.0
  • Como CUNY no pagó por personalizaciones, hubo que renumerar los cursos
    • Este fue uno de varios cambios forzados menos visibles para el cuerpo docente
  • El modelo de seguridad tampoco encaja con la forma de operar de CUNY
    • Estudiantes de work-study terminan realizando tareas que requieren permisos amplios
    • Como resultado, se generan situaciones en las que pueden acceder a datos de otros estudiantes
  • La estructura de RR. HH. tiene dificultades para manejar a personas con múltiples roles en varios campus
    • No maneja bien la realidad de CUNY, donde una persona puede ser estudiante de posgrado en un campus, docente en otro y empleada administrativa de medio tiempo en un tercero
    • GM o Apple no operan así, pero CUNY sí tiene esa estructura

Campus de la Wave 3 y experiencia de pruebas

  • Se espera que Brooklyn College y otros campus de la Wave 3 terminen adaptándose a CUNYFirst
  • Otras instituciones de waves anteriores ya se han adaptado
  • Sin embargo, Brooklyn College podría sufrir mayores molestias porque tenía sistemas complementarios de primer nivel dentro de la universidad para gestión de horarios y reportes de calificaciones
    • Está previsto que muchos de estos sistemas complementarios desaparezcan
  • Las pruebas iniciales se realizaron siguiendo scripts de prueba proporcionados por el proveedor
    • Cuando una prueba fallaba varias veces, un ingeniero de Oracle iba a la habitación contigua, ajustaba algo y luego los testers volvían a intentarlo
    • También se dice que este proceso mejoró en cierta medida después
  • Por más incómodo que sea CUNYFirst para los usuarios individuales, desde la perspectiva de CUNY Central puede verse como un sistema exitoso que cumple el objetivo de control central

1 comentarios

 
GN⁺ 2024-09-20
Opiniones de Hacker News
  • Es interesante la perspectiva de que la oficina central de CUNY quería tanto una herramienta MIS centralizada para impulsar una agenda de operaciones centralizadas y de estilo corporativo, que terminó ignorando lo que implicaba la limitación de Oracle de ser solo configurable.
    Por lo que he visto o escuchado, especialmente en el área de operaciones de negocio, en general es mejor adaptar los procesos a una herramienta ya hecha que personalizar o crear software nuevo para procesos a medida. Las organizaciones son menos especiales de lo que creen, y los procesos personalizados muchas veces nacen más de las preferencias de los primeros empleados que de razones reales. La personalización no es un costo único: en cada actualización o upgrade posterior exige trabajo adicional o, como mínimo, pruebas; y cuanto más cerca se esté de los procesos estándar, mayor es también la probabilidad de cumplir con la normativa local.
    Dicho eso, el costo de usar procesos que no son óptimos para tu organización es difícil de cuantificar, mientras que el costo contractual de adquirir una solución a medida se ve con claridad, así que el equilibrio puede verse de esa manera.

    • Mi experiencia es exactamente la opuesta. Los intentos de cambiar los procesos para ajustarlos a herramientas ya hechas siempre fueron malos para todos, y al incorporar algunos sistemas como software interno totalmente a medida, la experiencia de usuario mejoró y los cambios se volvieron más rápidos.
      Si podemos comprar un producto que se ajuste a nuestras necesidades, lo compramos; si no, lo construimos, y de hecho construimos bastante. Tampoco estoy de acuerdo con eso de que “las organizaciones son menos especiales de lo que creen”. Si una organización es lo bastante grande, le surgen requisitos que otros no tienen. Ahora mismo seguimos trabajando en un proyecto para operar todo el negocio con software estándar de la industria, pero al final tendremos que agregar personalizaciones e integraciones a medida. No quisiera construir internamente software de esta complejidad, pero si nos dieran los recursos y la tarea, creo que podríamos hacerlo y obtener un mejor resultado.
    • Exacto. Me recuerda a una gran investigación sobre proyectos de implementación de SAP a fines de los años 90.
      Recuerdo que era una consultora de la zona de Chicago, y las implementaciones más exitosas incluían en el contrato una cláusula del estilo: “no modificamos SAP para ajustarlo a los procesos de negocio existentes; modificamos los procesos de negocio para ajustarlos a SAP”. Rechazaban a los clientes que no podían aceptar eso, así que los clientes quedaban satisfechos, los empleados sufrían menos burnout y no había proyectos de marcha mortal con costos que crecían sin fin.
    • Nunca vi que tuviera éxito el enfoque de “es mejor adaptar los procesos a una herramienta ya hecha”.
      Más bien construí varios negocios partiendo de la premisa de que las personas son imposibles de cambiar y el software es fácil de cambiar.
    • El caso emblemático es el desastre de 500 millones de euros que Lidl tuvo con SAP.
      [1] https://www.computerweekly.com/news/252446965/Lidl-dumps-500...
    • El problema es que los procesos de negocio que vienen con Oracle pueden ser terriblemente ineficientes.
      Peor aún, la integración de antiguos módulos de Siebel y antiguos módulos de PeopleSoft también puede reemplazarse por algo nuevo con otros procesos nuevos. En cualquier caso, parece que CUNY se habría ahorrado unos 300 millones de dólares contratando personal administrativo con Excel y formularios en papel. Da la impresión de que están quemando dinero en una pelea política con “p” minúscula para integrar la mayoría de las funciones de RR. HH., y los beneficios también son dudosos.
  • Entiendo que está de moda criticar a Oracle, pero esa cifra de 600 millones de dólares es difícil de creer
    Trabajé antes en este sector, y un contrato de 6 millones de dólares ya era enorme; 100 veces eso tiene aún menos sentido. En 2013, el presupuesto total de CUNY era de apenas 2.000 millones de dólares [0], y eso no era el presupuesto de TI, sino el presupuesto para operar todo el sistema universitario, incluidos varios campus, el profesorado, los edificios, etc. Las instituciones de educación superior eran conocidas por ser clientes especialmente tacaños, sobre todo a fines de los 2000, así que incluso las grandes empresas tecnológicas les aplicaban descuentos importantes frente a clientes normales. Incluso si los 600 millones de dólares fueran una cifra que suma varios años, personal y costos asociados, no creo que se acerque a eso; y un gasto de esa magnitud necesariamente habría aparecido en los informes financieros anuales de CUNY, pero no encontré nada al respecto
    [0] https://www.cuny.edu/wp-content/uploads/sites/4/media-assets...
    Además, encontré una solicitud de presupuesto por 175 millones de dólares del año pasado para migrar de PeopleSoft (Oracle) on-premises a la nube. Pero, por lo que he visto, solo el 10% al 20% del monto solicitado en un presupuesto termina yendo realmente al proveedor de software; las instituciones agregan de 3 a 5 veces más por si no reciben todo el financiamiento, o aprovechan para incluir en esa cifra muchos rubros, como contratar puestos que originalmente habrían sido difíciles de aprobar. Normalmente, estas cifras también son presupuestos multianuales aprobados por adelantado, como para 5 años. Dicho de otro modo, el costo anual real de migrar de PeopleSoft on-premises a PeopleSoft en la nube podría estar en el rango de 10 a 20 millones de dólares
    https://www.cuny.edu/wp-content/uploads/sites/4/page-assets/...

    • No creo que ninguna universidad pague 600 millones de dólares por un sistema así. El autor parece estar muy equivocado con el precio y algo paranoico respecto de las motivaciones de la universidad. Tal vez podrían ser 600 millones de dólares a lo largo de más de 10 años
      Para empezar, también me pregunto por qué eligieron Oracle. Hay varios proveedores especializados en software para universidades; algunos son decentes y la mayoría no tanto, pero parece tonto considerar una solución de Oracle que requiere un alto nivel de personalización para ajustarse a los requisitos de una universidad
    • Lo primero que pensé fue que con 800 millones de dólares podrías fundar tu propia startup que haga un HRMS y todavía te sobraría dinero para comprar un superdeportivo
    • Estoy de acuerdo. 600 millones de dólares parece una cifra demasiado grande
      Estoy implementando una solución de Oracle en una gran multinacional burocrática, y también es cierto que si se infla el presupuesto de 3 a 5 veces y se solicita con base en 5 años de costos operativos, las cifras pueden volverse absurdamente grandes. Para alguien que solo ve el número, parece no tener sentido, pero quienes han hecho implementaciones o renovado contratos conocen las cifras reales. Dicho eso, el costo de migración podría ser mayor que 10 o 20 millones de dólares. Los costos de contratistas también son enormes y a veces llegan a ser varias veces el costo del software
      Por lo que veo en mi trabajo actual, a veces el proveedor de software y el socio de implementación externo desarrollan relaciones cercanas con quienes toman las decisiones. Cuando eso pasa, los incentivos se desalinean mucho al gastar “dinero de la empresa”
    • Es cierto. El sector educativo es realmente tacaño y se resiste incluso a montos mucho menores, así que 600 millones de dólares es difícil de creer
    • Me recuerda al fracaso del exchange de seguros médicos del estado de Oregon. Oracle se llevó alrededor de 250 millones de dólares, pero no entregó un producto funcional, y al final todo terminó en demandas y un acuerdo
  • Al ver lo mal que la mayoría de los académicos y administradores universitarios manejan las operaciones reales desde una perspectiva de negocio, no sorprende que la academia esté hecha un desastre así hoy.
    Lamentablemente, este desorden se financia con préstamos estudiantiles que ni siquiera se pueden cancelar en una bancarrota, para títulos cuyo valor es muy dudoso. Si uno sigue el flujo del dinero y piensa quién termina pagando realmente por esto, y cómo, es bastante amargo. Toda esta estructura se mantiene viva gracias al programa de préstamos estudiantiles. Corríjanlo o elimínenlo y la academia estadounidense se vendría abajo.

    • Al ver lo mal que la mayoría de los administradores corporativos manejan las operaciones reales desde una perspectiva de negocio, no sorprende que el sector corporativo esté hecho un desastre así hoy.
    • Hace poco dejé un puesto de desarrollo de software en la academia, y la ineficiencia organizacional era una locura.
      Durante mi proceso de salida, el ingeniero líder dijo que idealmente quería contratar a 5 desarrolladores más. Eso llevaría al equipo a 15 personas: 8 desarrolladores, 2 de DevOps, 2 de UX, 1 diseñador gráfico, 1 PM y 1 gerente de ingeniería. Ese equipo solo mantiene dos cosas: el sitio web estático de la biblioteca y un servidor/visor de imágenes bastante básico para colecciones de bibliotecas y museos.
      Es cierto que la biblioteca necesita un sitio web, pero una o dos personas bastarían para mantenerlo. El visor de imágenes lo usaba poquísima gente. Pero no importa. Mientras los estudiantes sigan pagando matrícula, el equipo seguirá recibiendo presupuesto, y el mundo seguirá girando aunque los ingenieros se queden sentados viendo YouTube todo el día.
      El peor ejemplo fue que en mi primer 1:1 mi gerente me dijo: “No esperes mucho output de [SENIOR ENGINEER X]. No es un buen ingeniero”. La organización no quiere despedir a nadie. Como resultado, las personas que llevan más tiempo terminan a cargo.
      Dicho eso, despedir también es riesgoso porque contratar es muy difícil. Las bandas salariales se fijan a nivel de la universidad para todo el personal, así que el sueldo máximo de un ingeniero de software está muy por debajo del mercado. Peor aún, el director de la biblioteca hizo obligatorio el trabajo presencial, y la universidad está en una ciudad universitaria aislada. En las entrevistas no hay ninguna sesión de programación; no sé si eso se debe a procesos estilo empresa o simplemente a incompetencia.
      Para ser justos, estos problemas no son exclusivos de la academia; he visto cosas similares en organizaciones grandes. Paradójicamente, cuanto más a prueba de balas es el modelo de negocio, más espacio hay para que crezca la podredumbre dentro de la empresa.
    • Esto no suena a culpa de los académicos, ni siquiera de los administradores. Parece un cambio impulsado por el sistema universitario estatal.
      Leyendo entre líneas, parece una respuesta a la presión política para recortar costos y poner límites al currículo.
    • En la universidad donde estuve había un proceso increíble para la facturación interna.
      Todo era caro y requería ingresar datos en sistemas crípticos. Si algo podía hacerse internamente, tenía que hacerse internamente, aunque el costo fuera astronómico. Un software de 100,000 dólares de un proveedor externo seguramente terminaba costando más de 200,000 dólares después de pasar por varias áreas de IT. Había al menos 4 departamentos de IT, capas y capas de gerentes, y todo el mundo era muy importante.
    • Creo que a la mayoría de los académicos no les interesa en absoluto cómo funcionan las cosas.
      De hecho, diría que hay una falta deliberada de voluntad para entender la complejidad y los detalles necesarios para operar un sistema universitario, además de la realidad financiera precaria de la mayoría de las universidades. A veces algún académico asume un cargo administrativo para arreglar lo que ve roto, o para demostrar lo inteligente y acertado que es. Por lo general, el primer año es durísimo tanto para esa persona como para quienes la rodean, y genera un desastre verdaderamente espantoso.
      Después de más o menos un año, apenas empieza a darse cuenta de cuánto no sabe sobre operaciones universitarias, gestión de personas y liderazgo. Luego la reacción suele ser una de tres: renuncia al puesto administrativo y vuelve a dar clases como si nada hubiera pasado; se vuelve más humilde y empieza a colaborar de verdad, dejando de culpar a todos los demás; o se pone aún más terco y arruina todo hasta que lo despiden o hasta que se derrumba la organización a su cargo. Por supuesto, no todos son así, y los profesores que hacen bien la transición al liderazgo suelen ser bastante humildes desde el principio.
  • Hace algunos años hice una plataforma de gestión de clases para una universidad.
    Me pagaron 1,000 dólares por eso, que para mí, siendo estudiante universitario en ese momento, era una cantidad absurda de dinero, e incluso me reuní con el rector para proponerle que la usaran. En ese momento la universidad estaba considerando comprar software de Oracle, así que terminé compitiendo contra Oracle, y entonces sentí algo parecido a lo de este profesor.
    La universidad, por supuesto, eligió Oracle. Seguramente gastaron una fortuna, y probablemente fue la decisión correcta. Es muy posible que yo me hubiera aburrido rápido. Uno no le paga a Oracle porque sea una buena oferta o un buen producto, sino para no tener que volver a pensar en eso nunca más.
    No tengo una conclusión concreta. Ojalá hubiera mejores opciones en el mercado. Pero no quiero construirlas yo. Es un problema aburrido y los clientes no son muy buenos, así que la tecnología educativa es un sector horrible para vender. Oracle tiene un rango de precios que para ellos vale la pena, y también clientes dispuestos a pagar ese dinero.
    Espero que alguien vea este texto y, en lugar de irritarse por el desperdicio en la academia y el gobierno, vea un gran mercado que podría dominarse con un producto mejor. Aunque, considerando que este texto fue escrito en 2013, no estoy tan seguro.

    • También están pagando 5 millones de dólares al año por servidores y mantenimiento de software.
      En teoría no deberían tener que preocuparse por eso, pero justamente eso resalta aún más el desperdicio. A mí también me gustaría poder gastar 5 millones de dólares sin pensarlo.
    • La forma en que las empresas enfrentan estos problemas es vendiendo software más caro.
      Por eso Oracle se hace rica vendiendo software pésimo en áreas difíciles que nadie más quiere tocar.
    • Si puedes materializar el dinero como en una ensoñación, ya no hace falta pensarlo más.
      Aun así, quizá en algún lugar del mundo haya gente que de verdad se toma el tiempo de pensar en los costos innecesarios.
  • @dang — encontré un enlace mejor que parece ser una versión revisada del enlace actual: https://psc-cuny.org/clarion/2013/may/cunyfirst-users-last/
    Este artículo fue escrito por el profesor David Arnow en el blog del sindicato docente de Brooklyn College y trata sobre CUNYfirst, el sistema de inscripción a cursos y RR. HH. basado en PeopleSoft que vendió Oracle. Lo publico porque el sistema recibió atención recientemente en Twitter: https://x.com/ChocolateyCrepe/status/1836171439965446441

  • Parecería que debería haber unos 5 o 6 proveedores de “software de RR. HH. para universidades”.
    Si quieres 1.000 licencias, a 5.000 dólares anuales cada una, son 5 millones de dólares en total. La implementación tarda un año, y si mandan a 25 personas para instalarlo y capacitar a los usuarios, suma otros 25 millones de dólares. Si durante el año siguiente se crean integraciones con otro software y otros sistemas, son otros 25 millones de dólares. Según el proveedor, la cotización podría variar alrededor de ±25%. Si se programan 200 horas de reuniones y capacitación sobre el nuevo software para 500 personas, son otros 5 millones de dólares. Entonces, ¿de dónde salen los 540 millones de dólares restantes?

    • ¿Por qué el departamento de Ciencias de la Computación no se une con otras universidades y hace que los estudiantes lo construyan? Que lo publiquen como código abierto.
  • En esa época trabajaba en el departamento de TI de una escuela de CUNY. Era realmente un desastre ridículamente malo y nada intuitivo.
    A todos los estudiantes se les asignaba un número de Employee ID, y la inscripción a cursos se manejaba básicamente como una función adicional de comercio electrónico.

    • Aun así era mejor que lo que hacía SUNY 10 años antes.
      El número de credencial estudiantil era el número de Seguro Social, y estaba impreso en la credencial junto con el nombre y la foto. Las credenciales se perdían o las robaban con frecuencia.
    • A mí me parece mejor que una solución de 600 millones de dólares.
  • Si lo piensas, 600 millones de dólares es dinero suficiente para que alguien cree una empresa nueva solo para ganar este contrato y la llene con desarrolladores de primer nivel.

    • Si ese hubiera sido un costo inicial, habría habido mucha más diligencia debida sobre las alternativas.
      Pero sospecho que mucho antes de que el costo llegara a las 9 cifras ya se habría generado dependencia del proveedor.
    • O CUNY podría contratar desarrolladores con sueldos de nivel Silicon Valley y construirlo internamente.
      Como señalaron otros comentarios, no está claro si la cifra de 600 millones de dólares es exacta.
  • Sobre el hecho de que otros postores se retiraran, me da curiosidad saber exactamente cuál fue el gasto principal que hizo que la estimación del costo total llegara a 1.000 millones de dólares.
    Con 600 millones de dólares se puede crear una nueva plataforma de software desde cero, así que debe haber algo más que eso.

  • ¿Cómo se venden sistemas caros y basura que todos odian y que perjudican de verdad a la organización? Es broma, pregunto “para un amigo”.
    Hay varias formas en que las grandes decisiones de compra se toman mal. Un comité de personas que no saben lo que hacen y que, en conjunto, no logra coordinar una buena decisión; alguien que impulsa algo por buenas razones pero no sabe lo que hace; alguien que quiere dejarlo como logro propio pero no sabe lo que hace; alguien que solo piensa “a nadie lo despiden por comprarle a un proveedor viejo y famoso” y considera todo lo demás secundario; o alguien sobornado por el proveedor. El soborno puede tomar la forma de efectivo inmediato, citas prácticamente reales con un vendedor atractivo, o una carrera de puertas giratorias con el proveedor.
    Nunca vi el método del soborno directamente; lo escuché en las noticias. Pero definitivamente he visto todas las demás malas formas. ¿Habrá alguna otra?

    • Hay que estar dispuesto a gastar costos irrecuperables de 5 o 6 cifras respondiendo a una solicitud de propuestas larga y compleja.
      Y hay que trabajar con integradores de sistemas existentes que se quedarán con una gran parte.