Diferencia entre revisiones de «Nexus: software de gestión del sistema educativo de la Comunidad de Madrid»

De Enciclopedia del fracaso digital de las AAPP
Saltar a: navegación, buscar
(Presentación del caso)
(Presentación del caso)
Línea 17: Línea 17:
  
 
La Comunidad de Madrid, tiene las competencias de educación en su territorio. Dentro de dichas competencias, la gestión de los estudiantes en todo su ciclo de vida, desde su entrada en el sistema de educación hasta su finalización en educación básica o secundaria, requiere una serie de actividades de alta complejidad, a raíz de la cual se articulan la situación de cada estudiante con la oferta de los centros y la disponibilidad de recursos.  
 
La Comunidad de Madrid, tiene las competencias de educación en su territorio. Dentro de dichas competencias, la gestión de los estudiantes en todo su ciclo de vida, desde su entrada en el sistema de educación hasta su finalización en educación básica o secundaria, requiere una serie de actividades de alta complejidad, a raíz de la cual se articulan la situación de cada estudiante con la oferta de los centros y la disponibilidad de recursos.  
En el año 2010, la Comunidad de Madrid adquirió la licencia de un software de la compañía alemana SAP, denominado [https://archive.sap.com/documents/docs/DOC-8194 Student Cycle Life Management] para su instalación e implantación para realizar estas tareas en el sistema SICE (Sistema de Información de Centros Educativos) <ref>[https://algoquedaquedecir.blogspot.com/2017/10/programas-gestion-educacion-madrid.html Programas gestión educación Madrid] </ref>
+
En el año 2010, la Comunidad de Madrid adquirió la licencia de un software de la compañía alemana SAP, denominado [https://archive.sap.com/documents/docs/DOC-8194 Student Cycle Life Management] para su instalación e implantación para realizar estas tareas en el sistema NEXUS <ref>[https://algoquedaquedecir.blogspot.com/2018/04/nexus-educacion.html Nexus educación] para sustituir 
 
+
SICE (Sistema de Información de Centros Educativos) <ref>[https://algoquedaquedecir.blogspot.com/2017/10/programas-gestion-educacion-madrid.html Programas gestión educación Madrid] </ref>, cosa que no se realizó por el fracaso del proyecto.
 
 
 
 
  
 
== Fracaso nº 1==
 
== Fracaso nº 1==

Revisión del 22:34 9 jul 2021

Nombre del caso

Nombre Nexus: software de gestión del sistema educativo de la Comunidad de Madrid
Organismo Informática de Comunidad de Madrid (actualmente Madrid digital)
Web (si procede) -
Finalidad Gestión del sistema educativo de la Comunidad de Madrid
Fecha de creación 2010

Presentación del caso

La Comunidad de Madrid, tiene las competencias de educación en su territorio. Dentro de dichas competencias, la gestión de los estudiantes en todo su ciclo de vida, desde su entrada en el sistema de educación hasta su finalización en educación básica o secundaria, requiere una serie de actividades de alta complejidad, a raíz de la cual se articulan la situación de cada estudiante con la oferta de los centros y la disponibilidad de recursos. En el año 2010, la Comunidad de Madrid adquirió la licencia de un software de la compañía alemana SAP, denominado Student Cycle Life Management para su instalación e implantación para realizar estas tareas en el sistema NEXUS Error en la cita: Etiqueta de apertura <ref> sin su correspondiente cierre </ref>, cosa que no se realizó por el fracaso del proyecto.

Fracaso nº 1

Datos
Fecha de detección 2010
Activo No

Descripción general del caso

¿Qué debería pasar?

La adquisición de la licencia de SAP SLCM por parte de la Comunidad de Madrid suponía una apuesta por la digitalización de:

  1. La gestión de los astudiantes, desde admisiones a matriculaciones y titulación
  2. El registro de calificaciones de los estudiantes
  3. La gestión de espacios, aulas, recursos y centros de toda la red pública de la Comunidad de Madrid
  4. La comunicación con los padres de los alumnos.

La herramienta, construida ofrecía este tipo de funcionalidade, pero requería una adaptación en dos sentidos:

  1. Ampliar funcionalidades. Existen requisitos funcionales ausentes del sistema, como por ejemplo, la elección de la asignatura de religión y la asignación de horarios.
  2. La parametrización del sistema para hacerlo funcionar. Más allá de estas adaptaciones, el sistema requiere tanto la concreción de las reglas de gestión como la instanciación de entidades (centros, alumnos, profesores, aulas) a una escala muy grande.


¿Qué sucede realmente?

SLCM es un software especializado en la gestión de centros educativos, pero en una escala y con una homogeneidad muy concreta, es empleado en universidades especialmente. En términos generales esto supone un currículum escolar más acotado, un número de centros más abordable, un menor número de alumnos y un sistema de gestión de asignaturas más simple, dado que la educación universitaria deja gran discrecionalidad a los alumnos y las reglas de negocio son menores en cantidad y complejidad. El software, por lo tanto, presentaba importantes limitaciones a la hora de gestionar:

  1. Enseñanzas muy variadas, que van desde la educación infantil a la FP, pasando por educaciones artísticas.
  2. Reglas de negocio muy específicas, que parten de la división de grupos por religión, a la realización de concursos para acceso a conservatorios.
  3. Números de actores en el sistema muy variados con reglas diferentes. El número de alumnos del sistema público de la Comunidad de Madrid supera on mucho los de la mayoría de universidades. Existen reglas como, por ejemplo, pasar de curso, o proximidad a centros que no existen en el sistema universitario en su conjunto.
  4. La extensión de recursos es más amplia y compleja que la de una universidad, requiriendo abordar desde salones de actos a aulas en centros rurales, para poder asignar alumnos y grupos y planificar las asignaturas. Las necesidades de espacios en las educaciones infantiles y básicas no son las mismas que en las universidades.

Una vez adjudicado el concurso a INDRA, se planteó un problema evidente: gran parte de las funcionalidades necesarias para el sistema no las cubría el software, de manera que:

  1. Indra no se hace responsable de cubrir necesidades que debería cubrir el producto.
  2. SAP no se hace responsable de las carencias del producto que estaban ahí cuando se contrató
  3. La Comunidad de Madrid no está dispuesta a ceder las funcionalidades necesarias para gestionar el sistema.

Adicionalmente, el software es relativamente nuevo en España, y se tiene que convocar una certificación por parte de SAP muy próximo al cierre de licitación para poder cumplir los requisitos de personal señalados en el contrato.


Inicialmente SAP asume el coste de una bolsa de horas de programación para adaptar el caso de negocio, que se cubrirán con personal de su centro de desarrollo de Bangalore. Al terminar el primer sprint de funcionalidades, el resultado no se ajusta a lo esperado.

Tras 4 años, en 2015, se cancela el proyecto, pero tras haberse pagado el primer tercio del contrato (5,5 millones de euros) [1] adquiriendo la herramienta RAICES de la Junta de Andalucía por 2,2 Millones, con menos funcionalidades, pero más adaptadas al caso de un sistema de educación básica y media público. [2], aunque parece que tiene también sus problemas de implementación y desarrollo [3]

¿Qué causas parecen más probables?

En primer lugar hay que considerar que la Comunidad de Madrid compró el software a partir de un estudio previo de Deloitte que recomendaba su implementación [4]. Adicionalmente, pese a que el concurso definía los alcances, y la participación en la licitación supone la aceptación de las condiciones, posiblemente el contratista no conocía o no valoró las dificultades adicionales al desarrollo del proyecto. Por último, el proveedor, siendo consciente de las limitaciones del modelo, decide cubrir la adaptación del caso de negocio con personal que tiene un ámbito formativo y cultural muy alejado del caso a adaptar, lo que dificulta enormemente la explicación, comprensión y adaptación, agotando varios sprints en entender un aspecto tan básico como formalizar la matrícula dependiendo de si un alumno ha elegido religión o la materia alternativa.

En resumen, hay un desconocimiento compartido entre las partes de los diferentes aspectos de desajuste entre el sistema educativo y la herramienta, y un rechazo a asumir los costes necesarios para hacer esta adaptación ni por parte del proveedor de software, ni del contratista, ni del contratante. El sistema no es viable y se abandona.

Valoración del caso

Tema Datos
Nivel de fracaso Fracaso absoluto
Causas técnicas 5
Falta de Recursos 4
Normativa inadecuada 0
Diseño 5
Cultura 4
Público 0