Plan de Transformación Tecnológica

Sección 01 · Dónde estoy

Auditoría de equipos

Diagnóstico individualizado basado en los mapas de diagnóstico completados por cada equipo. Cuatro pilares por equipo: metodología real, relación con terceros, documentación y backlog — más fortalezas, riesgos y acciones concretas.

Filtrar por fase:

Todos

Desarrollo

Mantenimiento

Transversales

Innotutor Desarrollo

MyLXP Desarrollo

TutorLXP Desarrollo

Educa.Pro Desarrollo

Data Desarrollo

EducaPay Mantenimiento

EducaSign Mantenimiento

Educacloud Mantenimiento

Webs Desarrollo

Campus Desarrollo

Sistemas Transversal

Seguridad Por definir

Zoho Sin datos

Innotutor · EducaERPCore · AuthGate · ExternalWS

ERP central del grupo + API intermediaria + Autenticación · C# / .NET / SQL Server / Google Cloud · Equipo: Daniel Rodríguez, Viedma, Antonio Jiménez, Raúl Barea, Mishael Bonel, Ana Navas (PM)

Riesgo alto

⚙️

Metodología real

Scrum declarado al 60%. Daily 3 días/semana, sprints bisemanales. Los sprints raramente se cumplen. Cambios de prioridades muy frecuentes — "prácticamente SIEMPRE se rompe el ritmo del equipo" cuando llega algo urgente.
Sin canal único de peticiones. Llegan por: email (especialmente a Daniel y Viedma), Teams (mensajes directos, grupos, llamadas), visitas físicas a la mesa, Jira (minoría) y a través de la PM. Solo las que pasan por PM se filtran correctamente.
Sin ceremonias de mejora continua. No hay retrospectivas. Las reglas de equipo existen verbalmente pero "en pocas ocasiones se siguen al 100% el flujo o acuerdo".
Información de peticiones limitada. La PM lo señala explícitamente: "la información muchas veces es limitada, tanto para la PM como para el propio técnico". Muchas tareas se ejecutan sin estudio previo.
Fases de proyecto muy simplificadas: solo 3 fases declaradas (Inicio/Planificación → Desarrollo → Pruebas/Entrega). Sin fase de diseño, sin validación estratégica, sin estimación formal por Fibonacci.
QA solo cuando llega por canal oficial. La PM valida cuando la petición entra formalmente. Las que llegan por Teams o llamadas bypasean el QA por completo.
Reuniones reales: Daily (3 días/semana) + bisemanal (Chief + PM). Sin planning formal estructurada, sin sprint review definida, sin retro.

🔗

Relación con terceros

Integración rota activa: API web INEAF para comunicación de bajas — sin responsable asignado, sin fecha de resolución en el mapa.
25+ integraciones activas en Innotutor sin SLA documentado en ninguna: Plataforma (API, José Medina), Alfresco (API, José Medina), LDAP (WS, equipo), ZRU (API, Abel), EducaPay (API, Pedro Antonio), EducaERPCore (API, Antonio Jiménez), ExternalWS (API, equipo), Zeleris/SEUR/Correos/Correos Express/GLS/NACEX, dLocal, InnovaPay, ESCIC (BD), EducaLMS (API, Pedro Mancilla), AWS SES, EduConnect/3CX (API, Esteban Sierra), AuthGate (API, Antonio Jiménez), EducaSign (API, Esteban Sierra), SII-Hacienda (WS), remesas bancarias (XML), XML universidades.
ExternalWS: dependencias sin mapear. "Actualmente en la mayoría de ocasiones llegan a través de Teams, sin nada definido." Clientes activos no documentados — "proyectos no documentados podrían dejar de funcionar" ante cualquier cambio.
EducaERPCore: peticiones llegan directamente a Antonio Jiménez o Daniel Rodríguez por Teams. Solo las que vienen como incidencias de soporte de Jira o tareas planificadas siguen el canal formal.
Equipos que dependen de Innotutor: Plataforma, Publishing, Billing, Finance, Corporate, Student Success, Enrolment, Secretariat, TutorLXP/MyLXP — todos con peticiones diarias o semanales por múltiples canales sin filtro.
AuthGate: dependencia total de AWS Cognito. "Si fallara AWS Cognito, el proyecto quedaría inservible." Sin plan de contingencia documentado.

📄

Documentación

Innotutor: todo en NO. Arquitectura técnica, flujos y procesos clave, integraciones, manual de uso, histórico de decisiones técnicas, onboarding para nuevos miembros, fases y metodología, reglas de equipo — ninguno existe. Solo credenciales parciales en credenciales.educaedtech.com.
ExternalWS: solo manual de uso parcial. Sin arquitectura, integraciones, onboarding ni reglas de equipo. "El uso que hacen otros proyectos de este está solo en la cabeza de algún miembro." Impacto si esa persona falta: "Sería difícil saber qué se está usando y por quién."
EducaERPCore: parcialmente documentado. Arquitectura parcial en Confluence, flujos parciales, manual de uso parcial. Sin histórico de decisiones, sin onboarding técnico. Dependencia de Antonio Jiménez: "Para alguien sin conocimientos de arquitectura limpia llevaría mucho tiempo entender el funcionamiento."
AuthGate: el mejor documentado del equipo. Arquitectura, flujos e integraciones actualizados en Confluence. Sin manual de uso ni onboarding específico, pero base técnica documentada.
Documentación crítica ausente en Innotutor identificada por el equipo: "Documentación completa del proyecto y todos sus flujos y casos de uso" — incluyendo flujos, condiciones y usos que "solo están en la cabeza" de Daniel o Viedma.

📋

Backlog y estado

73 incidencias sin resolver en el Portal de Incidencias + incremento desde la salida de Germán Pastor y Kevin Almeida. Sin priorización formal ni fecha de resolución para ninguna.
Épicas activas sin roadmap de cierre claro: BD Producto (PM: Anabel Osuna, en curso con nuevos Shopify), Zoho (dirigido por Iván Cabanas, Daniel ejecuta), AuthGate (en QA desde 30/4/2026, valorar continuación), Matriz de ventas (Carlos Sánchez ↔ Daniel directo, sin PM), Secretaría (Viedma, peticiones de Maite Corral por correo), Billing (Viedma, peticiones de Alberto Ruiz/Laura Rodríguez).
Arrastrando demasiado tiempo: peticiones de Bonificada, Secretaría, Billing, B2B Content — pospuestas por urgencias entrantes que nunca cesan.
Lo que el equipo identifica como necesario pero no tiene: "Objetivos de organización. Objetivos de equipo. Motivación grupal." También: "Una propuesta clara de la dirección tecnológica del sistema (hacia dónde vamos y por qué)."

Fortalezas

Equipo con alto nivel técnico individual: Daniel Rodríguez (Tech Officer / arquitectura), Viedma (Tech Lead / dirección técnica), Antonio Jiménez (Senior / .NET, Google Cloud, arquitectura limpia). Conocimiento profundo del negocio acumulado en años.
EducaERPCore: arquitectura moderna y correcta (.NET 10, monolito modular, arquitectura limpia). Pensado desde el inicio para ser escalable y sustituir progresivamente ExternalWS. Swagger activo.
AuthGate resuelve el problema de dependencia del proveedor de identidad: centralizando la integración con Cognito, futuras migraciones de IdP impactan solo en un punto.
Infraestructura Google Cloud migrada completamente (finalizada noviembre 2026). Base técnica moderna para todos los proyectos del equipo.
Respuesta rápida ante incidencias cuando el proceso funciona. La PM tiene criterio para filtrar y gestionar cuando las peticiones entran por el canal correcto.

Riesgos

Bus factor crítico en Innotutor: "Muchísimos flujos, condiciones y usos" concentrados en Daniel Rodríguez y Viedma. Si alguno falta: "Se producirían muchos problemas con cada desarrollo que podría interferir con flujos desconocidos. Llevaría mucho tiempo encontrar ciertas funcionalidades."
ExternalWS: proyecto legacy en mantenimiento con integraciones activas no documentadas de MyLXP, TutorLXP, Campus y clientes externos. "Integraciones no documentadas podrían dejar de funcionar" ante cualquier cambio. Imposible eliminar sin inventario previo.
Sin objetivo común de equipo ni roadmap estratégico. El propio equipo verbaliza: "No existe un roadmap estratégico" y "Cambiaría la forma de trabajo — el poder hablar con los responsables y estudiar las urgencias reales de la organización."
EducaERPCore depende de una sola persona (Antonio Jiménez). "El proyecto depende únicamente de una persona — impacto: alto."
Intrusión de personas ajenas bypaseando la PM: directores y stakeholders llegan directamente a Daniel o Viedma, rompiendo el proceso y la estimación planificada.

Acciones prioritarias

1Inventariar ExternalWS urgentemente: recopilar de todos los equipos (internos y externos) los endpoints que usan y para qué. Sin este mapa no es seguro tocar nada del proyecto.

2Distribuir conocimiento de Innotutor: sesiones de pairing rotatorio forzado. Todos deben tener contexto de los módulos críticos antes de fin de Q2. Incluye documentar en Confluence durante el proceso.

3Canal único Jira sin excepciones: comunicar formalmente a Secretaría, Billing, Finance y todos los equipos que Teams y email se cierran como canal de petición para Innotutor y EducaERPCore.

4Sprint dedicado a las 73 incidencias: separar críticas de mejoras, cerrar duplicadas, descartar irrelevantes, estimar las que quedan. El backlog actual no permite priorizar nada con criterio.

5Definir objetivo de equipo único para el ciclo con Daniel, Viedma y Ana: qué es lo más importante que este equipo debe conseguir en los próximos 3 meses. Todo lo demás se evalúa frente a ese objetivo.

6Onboarding EducaERPCore: tiempo protegido para que Antonio Jiménez documente el manual de nuevas funcionalidades y el onboarding técnico. No puede seguir siendo "cuando haya tiempo".

MyLXP

LXP propietario · 14 verticales · Web + App móvil · Angular 19 / Python / MongoDB · AWS · Equipo: Fran Romero, David Ruiz, Miguel Alonso, Manuel Contreras, Gloria Delgado (UX/UI)

Riesgo medio

⚙️

Metodología real

Scrum real al ~80%. Sprints bisemanales, daily de pie a primera hora, planning, retrospectiva bisemanal — todas activas. El informe de sprint de MyLXP es la referencia para el resto del grupo.
Flujo de aprobación doble: (1) Diseño en Figma validado con solicitante — ningún desarrollo arranca sin prototipo aprobado. (2) Planning con estimación por Fibonacci y confirmación de alcance.
Doble filtro de priorización: desarrollos funcionales/negocio requieren validación de Ángel Encinar; mejoras técnicas, del responsable del proyecto. Ninguna tarea entra sin respaldo estratégico o técnico.
Reglas de equipo documentadas y seguidas: rotación de soporte por sprint (1 persona prioritaria, el resto ayuda en picos), revisión cruzada de código obligatoria, no desplegar viernes, Mac compartido disponible para todos, incidencias que afectan a múltiples usuarios → comunicar a Anabel Fernández y Patricia Ortiz.
Comunicación con solicitantes estructurada: se informa del sprint al validar la petición, se involucra activamente en UAT, se pacta fecha de despliegue conjuntamente. Estado de tareas en Jira en tiempo real.
El 20% que rompe el sprint: urgencias de Ángel Encinar (estrategia de negocio), cambios en sistemas integrados (Innotutor, Campus, TutorLXP) y soporte post-despliegue. Las tareas planificadas se arrastran al siguiente sprint con impacto directo en previsibilidad.

🔗

Relación con terceros

Innotutor: dependencia más crítica. Envía datos de usuarios, tickets y certificados. Tiempos de respuesta altos = principal punto de fricción. Sin SLA formal. Si Innotutor falla: datos incorrectos, errores en plataforma, sin descarga de certificados, errores en tickets.
Campus (Moodle): bidireccional. Importa la mayoría de datos y gestiona subida de documentos. Si Campus falla: los alumnos no ven actualizados sus progresos y no pueden acceder a los campus. Sin SLA.
TutorLXP: mismo equipo de desarrollo. David, Miguel y Manuel pueden asumir tareas de cualquiera de los dos proyectos de forma flexible. Coordinación directa y ágil sin fricción.
PHIA: widget nativo embebido. No crítico — su caída no rompe la plataforma. Comunicación prácticamente inexistente en el día a día.
Zoho y SalesIQ: integraciones técnicamente hechas pero no activadas. Sin decisión formal de estado. El equipo lo identifica como riesgo de nivel bajo pero pendiente de resolución.
Peticiones llegan por múltiples canales: Jira (formal y trazable), reuniones semanales con Ángel Encinar, Teams (frecuente e informal — riesgo de entrar sin validación). Ideal: todas terminan en Jira antes de desarrollar, pero no siempre ocurre.

📄

Documentación

Credenciales actualizadas en Vault + Confluence. Registro de incidencias actualizado.
Manual de proyecto: existe en Confluence pero desactualizado.
No documentado: arquitectura técnica, integraciones con sistemas externos (el conocimiento más crítico del equipo), manual de uso/operativa, onboarding para nuevos miembros, fases y metodología de proyecto, reglas de equipo (existen pero no están escritas).
Bus factor crítico en Manuel Contreras: "la mayor parte del conocimiento sobre las integraciones, incluyendo su funcionamiento y las distintas lógicas asociadas, reside en Manuel." Su ausencia generaría: "mayores tiempos de respuesta, bloqueos en el desarrollo y mayor incertidumbre a la hora de tomar decisiones técnicas."
Documentación urgente identificada por el equipo: mapa de integraciones entre sistemas (Innotutor, Campus, TutorLXP, PHIA, Moodle) con flujos, dirección y responsables; flujos de soporte por casuística (especialmente los poco frecuentes); documentación funcional en Confluence por funcionalidad/integración relevante.
Código heredado sin documentar de personas que ya no están. "Código muy antiguo hecho por gente que ya no está y que nos cuesta entender y cambiar cuando es necesario."

📋

Backlog y estado

Proyecto principal en curso: rediseño completo de todas las aplicaciones (web y app) — MYLXP-1719. A mitad de desarrollo, bloqueado parcialmente por diseños pendientes.
Histórico de entregas sólido: Masterclasses, Accesibilidad, Login Cognito, Webinars/Podcasts, Integración TutorLXP, DOTIA — todos finalizados con fecha comprometida.
Backlog pendiente con prioridad: Carta de bienvenida desde Zoho/Student Success (media — coordinación con Campus pendiente); conexión centro de ayuda MyLXP con Zoho Desk (media — coordinar Innotutor + Zoho + MyLXP); MyLXP Bonificado (media — requiere coordinación multi-equipo).
Deuda que arrastra: tests. El equipo lo identifica explícitamente — la planning no contempla tiempo para tests, ni para peticiones directas no planificadas, ni para problemas no detectados. "A veces es entendible que haya más carga de trabajo, pero no debe ser lo cotidiano."
Deuda técnica: backoffice en Angular 15 vs web en Angular 19. "Diferencia de versiones genera una brecha tecnológica que puede dificultar el mantenimiento." Sin plan de convergencia definido.

Fortalezas

El equipo más maduro metodológicamente del portfolio. Scrum real con todas las ceremonias, doble filtro de aprobación (estratégico + técnico), reglas de equipo escritas y seguidas, rotación de soporte.
Proceso de QA independiente con entornos DEV → UAT → PROD bien definidos. Participación activa del solicitante en UAT. Despliegues nunca en viernes.
Diseño integrado en el flujo: Gloria Delgado como UX/UI Designer garantiza prototipo validado antes de desarrollar. La mayoría de equipos no tienen este recurso.
Equipo compacto y compenetrado. Alta agilidad para repartir tareas. "Al ser pocos y llevar mucho tiempo juntos nos entendemos muy bien."

Riesgos

Manuel Contreras: single point of failure total en integraciones. Su ausencia = bloqueo inmediato en diagnóstico de incidencias y desarrollo de cambios en cualquier sistema integrado.
Brecha Angular 15 (backoffice) vs Angular 19 (web) creciendo sin plan de convergencia. Cada sprint que pasa, el coste de actualización aumenta.
Sin senior de referencia externo: "Se echa en falta alguien con mucha más experiencia del que aprender de verdad. Alguien que nos imparta buenas prácticas y que nos haga mejorar en el stack."
Sin permisos suficientes en AWS para gestionar operativa propia. Dependencia de terceros para tareas que deberían ser autónomas del equipo.

Acciones prioritarias

1Documentar integraciones de Manuel Contreras: sesiones de pairing + entrada en Confluence por cada integración (Innotutor, Campus, TutorLXP, PHIA). Prioridad de documentación número uno del equipo.

2Reservar capacidad fija para tests por sprint. Sin esta decisión explícita en la planificación, los tests seguirán desplazándose indefinidamente.

3Planificar actualización del backoffice a Angular 19 de forma incremental antes de que la brecha sea técnicamente inabordable.

5Gestionar ampliación de permisos en AWS para autonomía operativa del equipo.

TutorLXP

Plataforma de tutorización docente · Tickets, corrección actividades, masterclasses · Angular / Python / PostgreSQL · AWS · Equipo compartido con MyLXP (David Ruiz, Miguel Alonso, Manuel Contreras) · Sergio Bravo (revisión) · Gloria Delgado (UX/UI)

Riesgo medio

⚙️

Metodología real

Scrum real al 90–95%. Sprints bisemanales, daily, planning, retro — todas activas. El 5–10% se rompe por soporte, urgencias de MyLXP (equipo compartido) y peticiones de alta prioridad incorporadas a mitad de sprint.
Flujo de aprobación completo: petición validada por Cristina Bullejos → diseño en Figma → criterios de aceptación → estimación Fibonacci en planning → desarrollo → UAT con solicitante → deploy pactado.
Equipo compartido dinámicamente con MyLXP. Sin distribución fija de dedicación — se ajusta según carga de cada sprint. Sergio Bravo revisa código pero está principalmente en Educa.Pro.
Sin reglas de equipo formalizadas. La revisión previa al merge es el único acuerdo explícito, y puede flexibilizarse en casos excepcionales.
Falta de definición inicial en algunas peticiones: ej. integración API Google Meet arrancó sin claridad de negocio, requirió reuniones posteriores con B2B y B2C para concretar el alcance real.

🔗

Relación con terceros

MyLXP: creación de tickets, comunicaciones e importación de datos. Continua. Funciona bien — área de mejora: calidad de la importación de datos.
Educa.Pro: creación de tickets y comunicaciones. Continua. Funciona bien. Swagger activo en root.educa.pro/apidocs/swagger.
Innotutor: creación de tickets. Continua. Mayoritariamente bien. Área de mejora: documentación de la comunicación entre equipos.
Campus: inserción de datos vía API de TutorLXP. Continua. Sin documentación Swagger.
Hawkings (evaluador IA): integración pendiente de testeo. Cuando un alumno entrega actividad, Hawkings genera feedback automático antes de llegar al docente en TutorLXP. Varios desarrollos bloqueados esperando la parte de Campus.
Comunicaciones masivas: funcionalidad que no usan los tutores — no permite crear comunicaciones sin matrícula seleccionada. Pendiente de analizar si es bug o comportamiento esperado.

📄

Documentación

Credenciales: en Vault — actualizadas.
Vista general, contexto y branding, masterclasses con Google Service: documentados en Confluence y actualizados.
Flujos y procesos clave: parcial, actualizado en la parte existente. Integraciones: parcial.
Onboarding: existe en Confluence pero desactualizado. Tareas de mantenimiento: existe pero desactualizado.
No documentado: arquitectura técnica, manual de uso/operativa, fases y metodología, reglas de equipo, histórico de decisiones técnicas.
Flujo de datos entre TutorLXP e Innotutor, Campus, MyLXP y Educa.Pro no documentado. "En numerosas ocasiones se gestionan matrículas sin trazabilidad clara sobre el sistema de origen." Identificado por el equipo como deuda documentación más urgente.

📋

Backlog y estado

En testeo: integración con Evaluador Hawkings (corrección automática de actividades + revisión del docente).
En curso: reporte CSV semanal de tutorías — bloqueado por correos personales en remitente y por deploy automático pendiente de Infraestructuras.
Backlog activo: mejoras propuestas por docentes y coordinadores (media), integración Zoho Desk para reclasificación a Student Success (alta — estrategia).
No comenzado: sustituir a Innotutor en docencia bonificada — pendiente de requerimientos FUNDAE y coordinación entre equipos. Alta prioridad estratégica de dirección.
Lo que arrastra demasiado tiempo: tests automatizados y documentación — siempre desplazados por urgencias operativas. El equipo lo reconoce explícitamente.

Fortalezas

Scrum real con ceremonias completas y UAT con solicitante antes de producción. Equipo flexible que comparte carga con MyLXP según necesidad del sprint.
Arquitectura abierta — permite incorporar cualquier proveedor de tickets e integrarse con nuevas tecnologías sin rediseño mayor.
Sistema de permisos granular: cada docente solo ve las matrículas que le corresponden.
Informe CSV semanal automático con 17 campos por tutoría para seguimiento de negocio.

Riesgos

Flujo de datos entre TutorLXP y sus integraciones no documentado. Cada incidencia requiere re-analizar flujos ya implementados desde cero.
Sin tests automatizados suficientes con base de código creciente e integraciones complejas (Hawkings, masterclasses).
Educa-UI: librería de componentes en repositorio independiente — modificar cualquier componente requiere trabajar en un repo externo al proyecto principal.
Sin perfil senior de referencia. El propio equipo lo señala: "sin perfiles que superen 3 años, se han consolidado prácticas poco óptimas."

Acciones prioritarias

1Documentar el flujo de datos TutorLXP ↔ Innotutor, Campus, MyLXP y Educa.Pro en un diagrama en Confluence. Es la deuda de documentación más urgente del equipo.

2Completar el deploy automático del reporte CSV semanal — resolver el bloqueo de correo remitente y coordinar con Infraestructuras.

3Reservar capacidad por sprint para tests automatizados. Sin esta decisión explícita, seguirán postergándose.

4Aclarar el estado de comunicaciones masivas: ¿bug o comportamiento esperado? Documentar la decisión.

Educa.Pro · Educa Pharos

Plataforma de formación corporativa · LMS + integraciones empresariales · Python / Angular / PostgreSQL · AWS · Equipo: Sergio Bravo (Senior), Carlos Mulero, Fran Romero, Raúl Rodríguez, Gloria Delgado (UX/UI), Antonio Rodríguez (BI)

Riesgo bajo

⚙️

Metodología real

Scrum real con todas las ceremonias. Sprint Planning, Daily, Sprint Review y Retrospectiva cada 2 semanas. La mayoría del trabajo sigue el marco metodológico.
Flujo de aprobación robusto: refinement (contexto + criterios de aceptación) → diseño funcional con Gloria → Sprint Planning (estimación Fibonacci + inclusión en sprint) → desarrollo → revisión de código por otro miembro → QA → entrega.
Reglas de equipo documentadas y seguidas: todas las tareas en Jira, estados siempre actualizados, revisión de código obligatoria, no desplegar en viernes (salvo críticos), flujo DEV→UAT→PROD con validación en cada fase.
Peticiones formalizadas por Cristina García — principalmente vía Jira desde reuniones de refinement. Proceso de validación previo antes de que el equipo técnico las vea.
Excepciones frecuentes en la mayoría de sprints: urgencias de soporte, cambios de prioridad y modificaciones de criterios una vez iniciada la tarea.

🔗

Relación con terceros

Workday: integración vía SOAP — envío de cursos, matrículas y actualización de IDs. En desarrollo activo. Prioridad principal actual. Documentada en SharePoint.
SuccessFactors (SAP): sincronización de datos de usuarios — activa + nuevo desarrollo en curso.
EducaSign: firma de certificados — activa. Coordina con Esteban Sierra.
TutorLXP, Innotutor, Campus: activos. Buen funcionamiento general.
Acciona Datalake: sincronización de datos de usuarios — en desarrollo. Documentada en SharePoint.
Zoho: soporte y creación de leads — activo. Tiempos de respuesta elevados en ocasiones, algunos cambios no comunicados con antelación.
Bloqueos externos principales: tiempos de respuesta de clientes en integraciones (Workday, Acciona) y provisión de información necesaria para continuar desarrollos.

📄

Documentación

Flujos de soporte actualizados en Confluence. Credenciales en Vaultwarden. API documentada en SharePoint. Documentación de ciberseguridad actualizada en Confluence.
Histórico de decisiones técnicas: iniciado en Confluence — muy reciente, en construcción activa.
Arquitectura técnica: parcial en Confluence. Manual de uso: parcialmente desactualizado. Onboarding: parcial (solo equipo de diseño).
No documentado: fases y metodología de proyecto, reglas de equipo. Flujos funcionales y lógica de negocio dependen de conocimiento de ciertos miembros — Gloria trabaja activamente en documentar esto.
Deuda técnica crítica sin documentar: funcionalidad de itinerarios IA y asignación de competencias — desarrollada por equipo externo (Nucleoo) que ya no está. Sin documentación, alta complejidad, difícil de testear y mantener.

📋

Backlog y estado

Prioridad actual: integración con Workday. Principal ocupación del equipo. Bloqueo puntual por tiempos de respuesta del cliente.
En curso: migraciones de datos Pharos, accesibilidad (desarrollo continuo), reportes globales Power BI, integraciones Pharos. Histórico sólido: Asignación de cursos, Microcredenciales, Privados, Mi Aprendizaje — finalizados.
Masterclases: iniciado y pospuesto — menor prioridad frente a Workday. Lleva tiempo definido y retrasándose de forma recurrente.
Lo que debería ser prioritario pero no lo es: mejora de rendimiento de la plataforma y reducción de deuda técnica del frontend (Angular Material).

Fortalezas

Metodología más madura junto a MyLXP. Scrum completo, reglas escritas y seguidas, flujo DEV→UAT→PROD respetado, no despliegues en viernes.
Dashboards Power BI para clientes y BackOffice — valor diferencial para el negocio. Documentación de ciberseguridad activa y actualizada.
Gloria Delgado incorporada como recurso funcional — genera documentación de flujos, criterios de aceptación y UX de forma progresiva reduciendo dependencia de conocimiento tácito.

Riesgos

Funcionalidad de itinerarios IA y competencias (Nucleoo): sin documentar, sin tests, equipo externo que ya no está. Imposible mantener ni evolucionar con seguridad.
Deuda técnica Angular Material: inconsistencias en UI, complejidad de mantenimiento creciente.
App móvil con bajo uso relativo que consume capacidad desproporcionada. El propio equipo lo señala como su cambio prioritario si pudieran actuar mañana.

Acciones prioritarias

1Documentar la funcionalidad de itinerarios IA/competencias (Nucleoo): ingeniería inversa + sesiones con quien tenga más contexto. Sin esto no se puede mantener con seguridad.

2Crear onboarding técnico para desarrolladores (Gloria ya cubre el lado funcional; falta el técnico: arquitectura, entornos, reglas de equipo).

3Evaluar el scope de la app móvil: analizar si el coste de mantenimiento está justificado por el uso real.

Data

Data Warehouse · Business Intelligence · Looker + Power BI + Power Apps · GCP (BigQuery, Cloud Run, Airbyte) · Equipo: Tomás Torres (Tech Officer DevOps), Samuel Jiménez (Tech Lead), Álvaro Cruz (BI / 45% Finance), Vanesa Ortiz (PM)

Riesgo medio

⚙️

Metodología real

Scrum en implantación desde marzo 2026. Se mezcla con trabajo reactivo ad-hoc según incidencias y necesidades de negocio (principalmente Finance/Price). Se reforzará cuando el Data Warehouse tenga cronograma validado.
Dos sprints paralelos: (1) Run Sprint semanal — mantenimiento, incidencias y tareas cortas. (2) Build Sprint quincenal — proyecto Data Warehouse.
Reglas de equipo activas: todas las tareas en Jira, estados actualizados, tareas en QA con 5 días para revisarse (si no hay respuesta, se cierra), si el sprint acaba antes de revisión del cliente se da por finalizada y se abre tarea vinculada en el siguiente sprint.
Sin estimación formal todavía. La carga de cada tarea se comenta en la daily. Sin story points ni tiempo estimado — identificado como mejora pendiente explícita.
Interrupciones persistentes: muchas personas siguen escribiendo por Teams en paralelo al formulario. La interrupción no desaparece aunque el canal formal esté activo.

🔗

Relación con terceros

Airbyte: herramienta de extracción open source en VM de Google — activa. Responsable exclusivo: Samuel Jiménez.
Google Cloud Platform: BigQuery (DW), Cloud Run, Data Workflow — motor principal del proyecto.
Sin integraciones rotas ni en riesgo.
Dependencia de equipos fuente de datos (Innotutor, Zoho, Talented…) para la fase de extracción. Mejor planificación conjunta reduciría bloqueos.
Lookers legacy no siempre ofrecen información adecuada — impacta negativamente en toma de decisiones de los equipos que los consumen.

📄

Documentación

Arquitectura técnica, histórico de decisiones y onboarding: en Confluence, actualizados. Espacio ADA bien estructurado con documentación viva por proyectos.
Credenciales: en Google Secret — actualizadas.
Integraciones y manual de uso/operativa: parciales. Fases y metodología: parcial. Reglas de equipo: no formalizadas (existen no escritas).
Riesgo crítico documentado por el equipo: Power Apps suscripciones B2B solo en la cabeza de Álvaro Cruz, y arquitectura/restauración de Airbyte solo en Samuel Jiménez. Si Airbyte cae y Samuel no está, nadie puede levantarlo.

📋

Backlog y estado

En proceso: arquitectura Matriz de Ventas en el nuevo DW, traslado de datos Docuware a Data Warehouse con dashboard Power BI.
Dashboards Nóminas 2026: en validación por RRHH — falta asignar permisos de acceso.
Backlog activo: limpieza usuarios Looker (antes de julio — alta, reduce costes), Matriz de Ventas (media — trabajo comenzado por Devoteam sin terminar).
Proyectos no comenzados: esperando KPIs y datos operativos para reajustar cronograma del DW y planificar sprints Build con criterio real.
Trabajo actualmente reactivo: sin cronograma del DW validado, el equipo opera según peticiones urgentes de Finance y dirección.

Fortalezas

Documentación de equipo más completa entre los no-tech: arquitectura, onboarding, histórico de decisiones y espacio Confluence bien estructurado.
Stack moderno y coherente: GCP (BigQuery, Cloud Run), Airbyte open source, Power BI.
Deuda técnica legacy identificada y en migración activa. PM activa generando estructura desde su incorporación.

Riesgos

Samuel Jiménez: único ingeniero con contexto completo del proyecto DW. "Solo un ingeniero de datos con el contexto de todo el proyecto" — impacto alto.
Airbyte sin documentación de restauración. Si cae y Samuel no está, el proyecto se detiene.
Sin cronograma validado del DW. El equipo no puede planificar con más de 1 sprint de visión.
Sin story points ni estimación formal. La capacidad real del sprint es opaca.

Acciones prioritarias

1Documentar arquitectura y restauración de Airbyte con Samuel. Es el riesgo operativo más inmediato del equipo.

2Documentar Power Apps suscripciones B2B con Álvaro. Riesgo crítico identificado explícitamente.

3Validar y publicar el cronograma del Data Warehouse para que el Build Sprint tenga planificación real y el equipo deje de operar reactivamente.

4Introducir story points o estimación de tiempo en tareas. Sin estimación, la capacidad del sprint es opaca e imposible comunicar compromisos de entrega.

5Reforzar el canal único de peticiones — comunicar formalmente a todos los equipos que Teams no es canal válido para peticiones al equipo Data.

EducaPay

Pasarela de pagos propietaria · Fase de mantenimiento · Drupal 10 / PHP 8.4 / MariaDB · 4 entornos (Dev/Staging/Pre-prod/Prod) · David Paulino (PM) + Pedro Peláez (Dev)

Riesgo medio

⚙️

Metodología real

Metodología declarada al 100% pero vacía de proceso real. "Hasta marzo se realizaban dailys y weeklys, pero al entrar en fase de mantenimiento simplemente nos llamamos cuando hay alguna tarea." Sin ceremonias activas de ningún tipo.
Canal de trabajo: Teams. Todas las incidencias y desarrollos llegan por mensaje de Teams. Solo la creación de usuarios entra por Jira. El resto del trabajo no tiene trazabilidad formal.
Sin reglas de equipo formalizadas. Respuesta explícita en el mapa: "No". No hay acuerdos escritos de ningún tipo.
Flujo de despliegue ordenado con 4 entornos. Dev (automático) → Staging (manual, pruebas) → Pre-prod (réplica exacta de producción) → Producción (balanceador de carga, 3+ nodos). QA en staging antes de producción — primero PM, luego equipo solicitante si aplica.
Priorización clara para incidencias de cobro: "las incidencias/errores de cobro son prioritarias, lo primero es poder cobrar." Respuesta inmediata y criterio claro ante errores en producción.
Sprint semanal = backlog del proyecto sin planificación formal de capacidad ni estimación estructurada. El desarrollador estima "en base al conocimiento que tiene" sin proceso de Fibonacci ni validación externa.

🔗

Relación con terceros

3 bloqueos activos sin SLA ni dueño de seguimiento: (1) ZRU — nuevo dato requerido por Innotutor (account de ZRU), "pendiente de respuesta de ZRU". (2) Enlace no consigue notificar su pago — "bloqueo por cambio de prioridades". (3) InnovaPay/Adyen — importación que requiere datos de request inicial, "pendiente de recibir más información de InnovaPay o Financiero".
Error conocido de conversión activo: cobro en primera venta falla en medios distintos a ZRU. Para ZRU hay parámetro de error implementado; para Stripe, Adyen, dLocal y PayPal no está implementado. El equipo lo identifica como "lo que más os genera ruido e interrupciones".
Errores 500 activos en MyLXP: "hay notificaciones hacia algunos orígenes de MyLXP que generan errores 500." Sin tarea asignada, sin responsable, sin frecuencia ni impacto documentados.
Protocolo de fallo con proveedores: ante errores de servidor → contactar Sistemas; ante errores con proveedores de pago → avisar a Financiero para que se pongan en contacto. Sin SLA ni mecanismo de presión formal con ningún proveedor.
Integraciones activas documentadas: Innotutor (API REST, Ana Navas), Proveedores de pago Stripe/Adyen/dLocal/PayPal/ZRU (API REST, Pedro Peláez), Webs corporativas Drupal (Mónica Daza), Zoho vía calculadora (Damián Carbajo), MyLXP (Cristina Bullejos).
Dashboards activos: EducaPay tiene dashboard interno para efectividad de cobro por orden de pago, enlaces y medios de pago. Power BI externo generado por Financiero con datos de EducaPay.

📄

Documentación

La herramienta mejor documentada del portfolio. Todos en Confluence y actualizados: arquitectura técnica, flujos y procesos clave, integraciones con otras herramientas, manual de uso/operativa, planes de despliegue (con histórico de versiones).
530+ tests unitarios. Herramientas de calidad activas: PHP_CodeSniffer (calidad de código), PHPStan (detección automática de errores lógicos), DDEV (entorno local), Google Cloud (monitorización de alertas).
Planes de despliegue: documento "siguiente despliegue" + histórico de versiones en Confluence. Proceso formal de release documentado.
Sin onboarding técnico para nuevos miembros. Pedro Peláez es el único desarrollador Drupal del proyecto. Si falta: "sería necesario otro desarrollador que entienda la plataforma, a nivel técnico", sin guía de incorporación.
Sin tests E2E. El equipo identifica explícitamente: "no tenemos mucha cobertura y faltan pruebas E2E y UX/UI. Podría afectar a la capacidad de cobro o seguimiento de deuda." Había un agente IA para E2E pero está parado por costes.
Sin fases de proyecto, sin reglas de equipo. La transición a mantenimiento dejó estos documentos sin crear.

📋

Backlog y estado

En curso activo: "Revisar alertas en URLs de pago" (incidencia, 1 día estimado, Pedro Peláez).
3 ítems bloqueados sin fecha: ZRU (pendiente de respuesta del tercero), Enlace de pago (cambio de prioridades), InnovaPay/Adyen (información pendiente). Ninguno tiene dueño de seguimiento activo.
Pendientes sin sprint asignado: tests E2E con Calculadora (2 días), actualización parche de seguridad Drupal Core (por estimar), herramienta para PM de descarga de ratio de eficiencia de medios de pago (4 horas).
Sales Manager: descartado por decisión de dirección ("no se quiere evolucionar la herramienta"). Prioridad media, no comenzado. Decisión correcta pero sin comunicación formal al equipo ni actualización del roadmap.
Lo que el equipo identifica como prioritario pero no lo es: aumentar la cobertura de pruebas — aparece explícitamente dos veces en el mapa bajo "¿qué debería ser prioritario?" y "¿qué lleváis arrastrando?".

Fortalezas

Mejor documentación funcional del portfolio. Arquitectura, integraciones, operativa y planes de despliegue en Confluence — actualizados y accesibles para cualquier miembro del equipo.
530+ tests unitarios y 4 entornos bien definidos. Infraestructura de calidad para un equipo de 2 personas. Proceso de despliegue ordenado.
Plataforma estable. "Se ha conseguido estabilizar la herramienta tanto en los medios de pago nativos como en los que llegan a través de ZRU." Pedro Peláez con dominio técnico profundo y respuesta rápida ante incidencias.
Herramienta con impacto directo en negocio: genera órdenes de pago, vencimientos y enlaces de retoken. Dashboards de efectividad de cobro para Financiero.

Riesgos

Gestión 100% por Teams: incidencias y desarrollos sin trazabilidad, sin priorización formal, sin historial estructurado. Cualquier petición — urgente o no — entra por el mismo canal sin ningún filtro.
Pedro Peláez: único desarrollador Drupal del proyecto. Baja = cero capacidad de reacción técnica ante errores de código en producción.
3 bloqueos con terceros sin SLA y sin dueño activo. Si alguno afecta a flujo de cobro en producción, el impacto es directo en negocio sin mecanismo formal de presión.
Error de primera venta sin documentar ni priorizar. Impacto en conversión desconocido. Sin tarea asignada ni fecha de análisis.

Acciones prioritarias

1Migrar toda la gestión a Jira inmediatamente. Comunicar a Financiero, Innotutor y Ventas que Teams ya no es canal válido. Sin esto la trazabilidad es imposible.

2Establecer SLA con ZRU, InnovaPay y Adyen con escalación formal a David Paulino si no hay respuesta en 5 días hábiles. Los 3 bloqueos necesitan dueño y fecha límite.

3Sprint dedicado a tests E2E en flujos críticos: inicio de pago, confirmación, error y reintento. Estimación: 2 días según el equipo.

4Documentar el error de primera venta: frecuencia, medios afectados, impacto estimado en conversión y plan de resolución con fecha.

5Comunicar formalmente el estado del proyecto al equipo: ¿mantenimiento puro indefinido o habrá nuevas funcionalidades? La ambigüedad bloquea la planificación.

EducaSign

Firma electrónica eIDAS · Fase de mantenimiento · .NET 9 / React 19 / SQL Server · Google Cloud · Namirial SignBox · Esteban Sierra (10-15% dedicación) + Pablo Ybarra (Director)

Riesgo alto

⚙️

Metodología real

Scrum real durante desarrollo activo (hasta 2025). Planning Poker para estimación, refinamiento de backlog, dailys, demos al cierre de cada entrega — "se cumplían con bastante rigor".
En mantenimiento: metodología disuelta. Sin ceremonias. Marco de sprints de 2 semanas mantenido pero "la carga se va completando de forma reactiva, a medida que surgen tareas".
Flujo de peticiones informal: (1) contacto directo por Teams con Esteban para valorar viabilidad. (2) formalización por correo a Pablo Ybarra. El canal formal de peticiones es el correo — no Jira.
QA y desarrollo en la misma persona. "No existe una segregación real entre quien implementa y quien valida." Backend con xUnit iniciado pero no mantenido al ritmo de las últimas funcionalidades. Frontend sin tests. Sin linters ni formateadores.
Reglas implícitas bien establecidas y respetadas: no desplegar viernes, flujo obligatorio DEV→STG→PROD, MRs en GitLab, aviso a usuarios ante despliegues impactantes, peticiones solo válidas por correo al director.
Esteban en 3 proyectos simultáneos: EducaSign (10-15%), AuthGate y proyecto de Secretaría (recién iniciado). Capacidad real disponible para EducaSign: mínima e insuficiente para las tareas pendientes.

🔗

Relación con terceros

Namirial (SignBox Optimizer): imagen actual identificada como Legacy. Nueva imagen entregada en mayo 2025 — generó problemas, no se desplegó. Segunda imagen recibida 24/04/2026 — pendiente de pruebas en STG. El proveedor lleva 1 año esperando la actualización del cliente.
AWS Cognito, AWS SES, Google Cloud Storage: si falla cualquiera de estos tres servicios, EducaSign deja de ser operativa. Sin plan de contingencia documentado para ninguno.
Integraciones bidireccionales activas: Innotutor (envía docs vía API REST, recibe firmados por webhook), Talented (ídem), EducaERPCore (consulta información de firmas vía API), Amazon Cognito (autenticación), AWS SES (correo transaccional), GCS (almacenamiento documentos).
EducaPRO: integración implementada en entornos, pendiente de pasar a producción. Bloqueada por coordinación con el equipo de EducaPRO.
Universidades con onboardings bloqueados: ULA-Lottus (documentación pendiente de recibir), UCNE (revisión documental legal activa), SIUM (documentación pendiente). EUNEIZ bloqueada esperando integración de EducaERPCore. UTC-Lottus en curso pendiente de confirmación.
Equipo Legal como cuello de botella: "comunicación lenta, debido a la carga de trabajo del equipo de Legal." Sin vía rápida definida para consultas críticas del proyecto.

📄

Documentación

Manual de usuario actualizado. Manual de integración vía API para clientes externos actualizado. Swagger del proyecto protegido con contraseña (acceso equipo).
Arquitectura técnica: existe pero desactualizada. Flujos clave: parciales y desactualizados.
No documentado (crítico): modelo de datos/BD, despliegue e infraestructura en GCloud, seguridad (secretos, accesos, logs), plan de contingencia ante incidencias graves, protocolo de emisión/renovación/revocación de certificados digitales, guía de resolución de incidencias frecuentes (runbook), protocolo de generación de informes de consumo mensual.
Integración con Namirial: solo documentación del proveedor. Sin documentación interna de endpoints utilizados, autenticación propia ni casuísticas conocidas. Si Esteban falta, nadie puede adaptar la integración ante cambios de la API del proveedor.
Si Esteban no estuviera disponible mañana: no se podrían hacer despliegues ni resolver incidencias técnicas, no se podría atender soporte de usuarios de firma, los onboardings quedarían parados, no se podrían generar los informes de consumo mensuales para Finanzas ni adaptar la integración con Namirial.

📋

Backlog y estado

Backlog histórico sin depurar. Contiene tareas del alcance original del SaaS que ya no son relevantes. "No se ha realizado una limpieza formal."
En pausa por falta de capacidad: despliegue nueva imagen SignBox (pendiente desde mayo 2025, nueva imagen recibida 24/04/2026 sin fecha de pruebas), investigación timeouts en lotes elevados de documentos (hipótesis Cloud Run, sin foco confirmado, DevOps a la espera).
Funcionalidad de informes de consumo en backoffice: implementada a medias. Esteban hace las consultas manualmente a BD cada mes. Reduciría carga y daría autonomía a Finanzas.
No comenzados por falta de scope: Dashboard ejecutivo avanzado (media), sección FAQs en herramienta (media), funcionalidades del roadmap original MVP.
Lo que debería ser prioritario pero no lo es: documentación técnica, plan de contingencia, investigación timeouts, despliegue nueva imagen SignBox, automatización informe consumos, actualización suite tests. Todo postergado por falta de capacidad.

Fortalezas

Herramienta estable y operativa en producción. Academic Board, Student Success, Laboral y secretarías universitarias la utilizan diariamente sin incidencias significativas.
Stack tecnológico moderno y sin deuda obsoleta: .NET 9, React 19.2, Tailwind CSS, SQL Server, Docker. No hay tecnologías que reemplazar a corto plazo (excepción: imagen SignBox Legacy).
Pipeline CI/CD entre GitLab y Google Cloud consolidado y fiable. Flujo DEV→STG→PROD respetado con disciplina.
Esteban documentó el proyecto con rigor durante el desarrollo — el manual de usuario, integración vía API y decisiones técnicas tienen cobertura inusual para un proyecto de una persona.

Riesgos

Dependencia total en Esteban Sierra con 10-15% de dedicación efectiva: desarrollo, QA, soporte, onboardings, despliegues, gestión de certificados, auditorías, informes mensuales. La probabilidad de un problema por falta de capacidad es alta.
Sin plan de contingencia ante caída. Todos los dependientes (Innotutor, Talented, EducaPRO, EducaERPCore, universidades, equipos internos) quedarían sin servicio sin protocolo de comunicación ni escalado.
Nueva imagen del SignBox (Legacy) pendiente desde mayo 2025. Riesgo de incumplimiento contractual o de seguridad con Namirial que se alarga sin intervención activa.
Timeouts en lotes elevados: incidencia técnica activa sin foco identificado. Afecta directamente al uso en volúmenes grandes.

Acciones prioritarias

1Documentación crítica con tiempo protegido: backoffice, protocolo de certificados, despliegue GCloud, integración Namirial e infraestructura. Esteban mismo lo identifica como la única cosa que cambiaría mañana.

2Planificar el despliegue de la nueva imagen del SignBox en los próximos 30 días. Coordinar con DevOps. 1 año de deuda acumulada.

3Evaluar la carga real de Esteban en 3 proyectos simultáneos. Si EducaSign necesita capacidad real, hay que tomar una decisión de priorización o incorporar un segundo recurso.

4Formalizar canal de peticiones: formulario Jira como único canal oficial. Eliminar el flujo informal Teams→correo→Pablo Ybarra.

5Completar la funcionalidad de informes de consumo en backoffice para que Finanzas sea autónoma y Esteban no dedique tiempo a consultas manuales mensuales a BD.

Educacloud

Herramientas internas de producción educativa · Laravel PHP8 + Editor Online · Fase de transición a mantenimiento · Pedro Mancilla + David Medina + Javier Hernández (TL, baja paternal)

Riesgo medio · Transición a mant.

⚙️

Metodología real

Scrum al 80%. Sprints bisemanales, daily 3 días/semana, reunión bisemanal con Chief + PM. Reglas de equipo establecidas y seguidas.
Proyecto PHP8 bien calendarizado con fechas por fase. Las prioridades no cambian salvo urgencias o bloqueantes para otros equipos.
QA por MR bisemanales — los técnicos se revisan el trabajo entre sí. Para peticiones de terceros, revisión triple (técnico + PM + solicitante).
Incidencias editoriales siguen llegando por correo (aunque mejorando). Peticiones de elearning por correo aún.

🔗

Relación con terceros

Innotutor (Pedro Mancilla), Campus (David Medina): integraciones activas pero sin documentación de Swagger ni de contingencia.
Sistemas: crontab activo gestionado por Pedro Mancilla. Sin SLA formal.
Wizard: proyecto cesado en abril-mayo 2025 por decisión de dirección. Integración marcada como rota/inactiva en el mapa.
Biblioteca Multimedia: pendiente de decisión. Almacena vídeos de contenido educativo con problema inminente de espacio en disco. Requiere coordinación con Sistemas — aún no escalado.

📄

Documentación

PHP8: arquitectura, flujos, onboarding y reglas de equipo en Confluence — actualizado. Es el único proyecto bien documentado.
Proyectos anteriores (Educalab, SaaS, Wizard): sin documentación accesible. Pedro Mancilla es el conocimiento ambulante.
Integraciones de proyectos legacy: desconocidas para la PM. Wiki interna sin acceso para la PM actual.
Credenciales y accesos: no documentados en Confluence para ningún proyecto.

📋

Backlog

PHP8 es el proyecto central activo con tareas bien definidas y calendarizadas. Backlog ordenado.
Sistema de licenciamiento (PHP8): no comenzado, sin bloqueante claro más allá de prioridad media.
Revisión espacio de vídeos: prioridad alta marcada en el mapa, pero sin tarea activa asignada. El equipo ya sabe que se quedarán sin espacio.
Sin roadmap estratégico a futuro — el equipo opera sprint a sprint sin visión de qué viene después del PHP8.

Fortalezas

Equipo consolidado con buena comunicación interna y polivalencia técnica (Laravel, PHP, JS, SQL, Docker).
Metodología bien aplicada en el proyecto activo (PHP8). Reglas de equipo claras y seguidas.
Pedro Mancilla y David Medina: conocimiento profundo de un sistema crítico con más de 15 años de historia.

Riesgos

Pedro Mancilla y David Medina concentran todo el conocimiento de los proyectos legacy. Si se marchan, no hay documentación ni sustituto.
Vídeos sin espacio en disco: riesgo inminente identificado en el mapa pero sin tarea activa ni escalación a Sistemas.
Tech Lead (Javier Hernández) con baja paternal reciente — el proyecto estaba ya muy definido cuando tomó el rol. Cobertura técnica reducida.
Sin roadmap después del PHP8. Riesgo de perder equipo o capacidad sin saber qué viene.

Acciones prioritarias · Cierre de fase y transición a mantenimiento

1Escalar espacio en disco a Sistemas ahora. El equipo ya sabe que se quedarán sin espacio para vídeos de contenido educativo — es el bloqueo de producción más inmediato y más fácil de resolver si se actúa antes de que ocurra.

2Documentar proyectos legacy mientras Pedro Mancilla sigue en el equipo. Prioridad: inventario de integraciones activas (Innotutor WS, Campus WS, crontab de Sistemas), credenciales y accesos de todos los proyectos, y flujos críticos de Educalab. Cada semana que pasa sin esto aumenta el riesgo.

3Crear el onboarding técnico de Educacloud. Antes de cerrar la fase de desarrollo activo del PHP8, documentar el proceso de incorporación para que un nuevo miembro pueda operar el sistema sin depender de Pedro o David.

4Dar acceso a la PM a la Wiki interna. La PM actual no tiene acceso a la documentación de proyectos anteriores. Sin acceso, no puede gestionar ni priorizar correctamente.

5Definir el canal único de peticiones en Jira. Las incidencias editoriales y de elearning siguen llegando por correo. Al entrar en mantenimiento, centralizar en Jira es condición necesaria para operar con el check-in semanal.

Webs

Shopify · WordPress · Zoho CRM · BBDD central MySQL · 30+ proyectos lanzados en 12 meses

Riesgo medio

⚙️

Metodología real

Scrum al 60-70%. Sprints semanales. 100% cumplimiento de fechas de lanzamiento — aunque requiera trabajar fuera de horario y festivos.
Proceso de proyecto bien definido en 9 fases con kickoff interno, kickoff PO, diseño, validación, maquetación, pre-launch y go-live.
Reglas de equipo exhaustivas documentadas en Confluence: todo pasa por Jira, estimación por comentarios, estado diario obligatorio, ramas Git siempre.
El 30-40% es ad hoc: mantenimiento urgente, cambios de prioridad de dirección y context-switching constante por peticiones sin planificación previa.

🔗

Relación con terceros

Zoho (Bimind, Iván Cabanas, Gazela): dependencia crítica. 6+ meses de retrasos en venta automatizada multiproducto — bloqueó todos los proyectos nuevos.
Innotutor: dependencia crítica para sincronización de productos. Mejoró con Daniel Rodríguez como recurso compartido.
Publishing (Domingo): excelente — "parece uno más del equipo". Comunicación ágil y proactiva.
Marketing/Comercial: relación mala. Información siempre llega tarde. En 12 meses, 0 proyectos han entregado información en las fechas acordadas.

📄

Documentación

Documentación más completa del portfolio: arquitectura, flujos, integraciones, onboarding, metodología, reglas de equipo — todo actualizado en Confluence.
Cada proyecto tiene su espacio Confluence propio con ficha, requisitos, credenciales y material de referencia.
BBDD y arquitectura de sincronización (Daniel Rodríguez): parcialmente documentada — si Daniel falta, meses de pérdida de contexto.
Nuevo Zoho (venta automatizada, Jesús): no documentado hasta finalizar el proyecto. En curso, aún en riesgo.

📋

Backlog

8+ proyectos Shopify en standby por prioridades indefinidas de dirección: Euroinnova, Inesalud, Ineaf, Edusport, INESEM, Rededuca, Udavinci, Ceupe.
Capman: en standby desde diciembre — 3 sesiones de kickoff y correos enviados sin que el PO haya proporcionado información.
EduHub Core Fase 2: bloqueada esperando que Carlos Campos complete la parte de IA. Sin fecha.
Backlog de mantenimiento (Shopify + WordPress) bien gestionado y continuo. 100% capacidad disponible para esto.

Fortalezas

Velocidad de entrega excepcional: 30+ proyectos lanzados en 12 meses, todos en fecha comprometida. 0% de retrasos causados por el equipo Tech.
Documentación más madura del portfolio. Onboarding, metodología, procesos y reglas en Confluence y vídeos.
Equipo multidisciplinar real: front, back, APIs, BBDD, WordPress, SEO, diseño — integración completa end-to-end.
Ana Osuna: directora con visión completa del stack, criterio técnico sólido y transparencia radical en la comunicación.

Riesgos

Sin Product Owners definidos por marca. Ninguna vertical tiene una persona que centralice target, visión y objetivos. Genera fricción constante.
Sin roadmap formal de dirección. 8+ proyectos en standby sin criterio de priorización. El equipo no puede planificar más allá de 2 semanas.
Context-switching semanal por urgencias de dirección. Impacto en productividad y sostenibilidad del equipo a largo plazo.
La percepción interna de que "es el equipo Shopify" invisibiliza el alcance real. Genera decisiones sin incluir al equipo que luego son inviables técnicamente.

Acciones prioritarias

1Definir roadmap formal de dirección para proyectos Shopify pendientes. Sin esto, 8 proyectos seguirán en standby indefinido.

2Designar Product Owner formal por cada marca con conocimiento centralizado. Sin PO, el equipo actúa de detective en cada proyecto.

3Documentar la arquitectura BBDD de Daniel Rodríguez y el Zoho nuevo de Jesús antes de que finalicen o cambien de proyecto.

4Establecer SLA mínimo de entrega de información con equipos colaboradores. Sin fecha comprometida, el bloqueo es sistemático.

Campus (LMS)

Moodle 4.5 + ecosistema amplio · Portal del alumno · Alfresco · Sincroapp · Generador PDFs

Riesgo alto

⚙️

Metodología real

Scrum al 80%. Sprints bisemanales, daily, planning bisemanal con estimación de esfuerzo por José Medina.
Criterio claro de urgencias: solo se rompe el sprint si hay impacto en usuarios en producción o fechas comprometidas en acuerdos comerciales.
QA con solicitante cuando hay impacto funcional. QA interno cuando es puramente técnico.
Las tareas no se detallan en Jira — José traslada el contexto verbalmente en planning. Dependencia total en su figura para estimar y priorizar.

🔗

Relación con terceros

Innotutor: dependencia crítica para finalizaciones de matrícula y sincronización de datos. Falla Innotutor = falla Campus.
Integraciones pendientes activas: Innotutor (automatizaciones), Hawkings (corrección actividades), Zoho (encuestas).
Hawkings: dependencia externa para el evaluador. Varios desarrollos bloqueados esperando su API.
Zona gris recurrente: cuando falla algo entre Campus y MyLXP o Innotutor, no está claro quién debe diagnosticarlo y resolverlo.

📄

Documentación

Arquitectura técnica de Campus documentada en Confluence. Manual de uso y operativa parcialmente actualizado.
Sincroapp, Validador de documentación (heredado): sin documentación. Solo José Medina conoce estos proyectos.
Sin documentación de flujos clave, onboarding técnico, fases de proyecto ni reglas de equipo.
Generador de PDFs: documentación no localizada. Alfresco: documentación en SharePoint pero con lógica anterior a la migración a cloud.

📋

Backlog

Proyectos legacy pendientes de cierre activos: Campus multi (sin soporte de seguridad), Portal del alumno antiguo, LiveHelperChat. El equipo ya sufrió un pirateo por esto.
4 desarrollos actualmente bloqueados (importación multidioma MyLXP, seguimientos bonificados, tutores UTAMED, plugin Hawkings).
Traducción al chino (prioridad alta, Pablo Ybarra), integración Zoho Survey (prioridad alta, Lorena) — sin sprint asignado.
Documentación y formación interna identificadas como urgentes pero siempre desplazadas por urgencias operativas.

Fortalezas

Equipo técnico sólido y polivalente. Cubre todo el stack de forma autónoma (PHP, Laravel, React, GCP, infraestructura).
Criterio maduro para gestionar urgencias: filtro claro basado en impacto real, comunicación proactiva cuando algo se desplaza.
Cultura de apoyo entre perfiles. El conocimiento operativo está razonablemente distribuido en el equipo actual.

Riesgos

Proyectos legacy sin soporte de seguridad: el pirateo reciente fue una advertencia. Mientras sigan activos, el riesgo persiste.
José Medina como cuello de botella total: priorización, estimación, contexto técnico — todo pasa por él. Baja o sobrecarga = equipo parado.
Ecosistema demasiado amplio para el tamaño del equipo. La carga de soporte e integraciones deja poco margen para desarrollo planificado.

Acciones prioritarias

1Cerrar proyectos legacy con fecha comprometida: Campus multi, Portal del alumno antiguo y LiveHelperChat. Necesita decisión ejecutiva con recursos asignados.

2Documentar Sincroapp y Validador de documentación con José Medina antes de que el contexto se pierda. Reservar tiempo protegido.

3Definir protocolos de responsabilidad en zonas grises (Campus ↔ Innotutor, Campus ↔ MyLXP) para reducir fricción diagnóstica.

4Distribuir la capacidad de estimación y priorización — José Medina no puede ser el único punto de decisión del equipo.

Sistemas · Infraestructura · DevOps

Infraestructura, despliegues, soporte, seguridad básica y monitorización · Equipo: Tomás Torres (Tech Officer DevOps), Isaías Aranda (Tech Lead DevOps), Roberto Santiandreu (50% Sistemas / 50% Soporte), Vanesa Ortiz (PM)

Riesgo alto

⚙️

Metodología real

Trabajo 100% reactivo. Sin sprints ni metodología estructurada. El equipo responde incidencias y da soporte a otros equipos a demanda. Las tareas de mantenimiento preventivo "actualmente no se llevan a cabo, solo se revisan si surge alguna incidencia".
Sin estimación de esfuerzo. Las tareas no se estiman. La prioridad la decide el técnico según el sistema de clasificación de urgencias (ver SLA en el mapa).
Sin sprints ni ciclos de trabajo definidos. "El equipo trabaja de forma reactiva." Las únicas reglas formales son: no hacer nada en producción directamente, no desplegar los viernes, resolver incidencias críticas de forma inmediata.
Canal de peticiones en mejora: las peticiones llegan por Teams, en persona, emails y tareas en otros equipos. Desde marzo se están desviando al formulario de incidencias o a la PM para filtrar. También se pide a otros equipos que asignen a la PM en lugar de a Isaías directamente.
Reunión semanal con Devoteam (Isaías, Guillem de Devoteam, Vanesa) como única reunión recurrente — rol de consultoría externa.

🔗

Relación con terceros

Todos los equipos dependen de Sistemas. Infraestructura, despliegues, accesos, soporte técnico — ningún equipo puede publicar, desplegar ni resolver incidencias de infraestructura sin Sistemas.
Webs corporativas: despliegue/hosting — activa. Campus: infraestructura — activa. Herramientas internas: integraciones varias — parcial.
Zona gris amplia: "existe zona gris debido a la falta de información respecto a quién es el responsable de cada herramienta, proyecto y activo digital." Las consultas llegan a Sistemas porque son el equipo con más antigüedad y contexto.
Bloqueos externos frecuentes: algunas tareas dependen de validación por parte de terceros tecnológicos (ej. verificación por Google). Sin SLA ni mecanismo de presión.
Herramientas de monitorización activas: Zabbix, Nagios, Kuma (uptime), HAProxy (balanceo), GLPI (gestión de incidencias e inventario).

📄

Documentación

Desde marzo 2026 se ha implementado Confluence para el equipo. La documentación se elabora de forma reactiva según necesidades — sin tiempo para hacerlo de forma paralela al trabajo operativo.
Manual de uso/operativa: parcial en Confluence — incompleto, faltan más procesos.
Credenciales: en credenciales.educaedtech.com — existe un manual "pero no sabemos dónde".
No documentado: arquitectura técnica, flujos y procesos clave, integraciones, histórico de decisiones técnicas, onboarding para nuevos miembros, fases y metodología, reglas de equipo.
Conocimiento crítico solo en Isaías: repositorio, Innotutor (infra), autenticación, OpenLDAP, Campus (infra)… "Aunque hubiese documentación, el riesgo de tener solo un técnico en el equipo es crítico."
El equipo es explícito: "No es cuestión de documentación, es cuestión de tener más personal que conozca los procesos."

📋

Backlog y estado

El equipo trabaja en los proyectos de otros equipos. No tienen backlog de producto propio — todas las tareas son de soporte, infraestructura o mejora para otros.
En curso: múltiples tareas de mantenimiento y mejora en el proyecto OEI de Jira (OEI-1009, OEI-1463, OEI-1555, OEI-1773, OEI-2026, OEI-2146, OEI-2402, OEI-2697, OEI-2801) — sin descripción de contenido en el mapa.
Arrastrando demasiado tiempo: migración de Hetzner a Google — "todavía en proceso".
Hay información alojada en servidores Hetzner que debería haberse migrado — tecnología que debería reemplazarse.
IA en exploración activa: Claude para soporte operativo, ChatGPT y Rovo (Atlassian) para documentación, configuración de IA en 3CX para llamadas en Student Success (Roberto en curso).

Fortalezas

Alta capacidad de respuesta ante incidencias críticas. Conocimiento técnico profundo y compromiso — el equipo actúa con rapidez cuando hay una caída o incidente grave.
Stack de monitorización completo y activo: Zabbix, Nagios, Kuma, GLPI. Visibilidad sobre el estado de infraestructura en tiempo real.
Sistema de clasificación de urgencias (Niveles 1–4) documentado y usado por el equipo para priorizar sin ambigüedad.
Consultoría semanal con Devoteam (Guillem) como referencia técnica externa para decisiones de infraestructura.

Riesgos

Isaías Aranda: único técnico con conocimiento profundo de la infraestructura crítica. El equipo lo documenta textualmente como riesgo alto con solución propuesta: "contratar más personal". Sin Isaías, la capacidad de respuesta ante incidencias P1 y P2 quedaría gravemente comprometida.
Trabajo 100% reactivo sin mantenimiento preventivo. Los sistemas no se revisan proactivamente — solo cuando algo falla. Esto incrementa la probabilidad de incidentes graves.
Falta de capacidad: identificada como riesgo alto en el mapa. El equipo no puede documentar, mejorar procesos ni hacer mantenimiento preventivo porque toda la capacidad va a responder urgencias.
Zona gris generalizada: no está documentado quién es responsable de cada herramienta, proyecto o activo digital. El equipo lo pide explícitamente: "un documento simple con el responsable de cada tecnología/proyecto."
Migración de Hetzner a Google todavía en proceso — tecnología legacy activa que añade complejidad operativa.

Acciones prioritarias

1Evaluar la incorporación de un segundo técnico de infraestructura. El equipo lo identifica como su único riesgo crítico. Sin esto, todas las demás mejoras son parches sobre el problema de fondo.

2Crear el inventario de responsables por herramienta/proyecto: documento simple con propietario técnico de cada activo digital, comunicado al resto de la organización. El equipo lo pide explícitamente para reducir el ruido de consultas.

3Completar la migración de Hetzner a Google. Mientras haya infraestructura en Hetzner, hay complejidad operativa adicional y riesgo de inconsistencias.

4Documentar los procesos críticos de Isaías (repositorio, Innotutor infra, autenticación, OpenLDAP, Campus infra) — aunque sea de forma incremental, con tiempo protegido.

5Consolidar el canal único de peticiones y comunicar formalmente a todos los equipos que Isaías y Tomás no son el canal de entrada — la PM o el formulario de incidencias son el punto de contacto válido.

Seguridad

Equipo transversal de seguridad tecnológica · Mapa de diagnóstico pendiente de definición

Por definir

🔐

Mapa de diagnóstico no iniciado

El equipo de seguridad no tiene aún un mapa de diagnóstico completado. Su alcance, composición, metodología y relación con el resto de equipos están pendientes de definición formal.

Sin organigrama definido Sin metodología documentada Sin backlog registrado Sin integraciones mapeadas

Contexto desde otros mapas

Educa.Pro: documentación de ciberseguridad activa y actualizada en Confluence. El equipo tiene documentado un proceso de seguridad, pero no está claro si hay un equipo de seguridad transversal que lo coordine.
Campus: sufrió un incidente de seguridad (pirateo) por proyectos legacy sin soporte de seguridad activo. Sin protocolo de seguridad transversal documentado que hubiera podido prevenirlo.
Sistemas: la seguridad básica y monitorización forman parte del alcance de Sistemas según su mapa, pero no está definido qué cubre un equipo de seguridad específico vs. qué cubre Sistemas.

Próximos pasos

1Definir el alcance y composición del equipo de seguridad: ¿es un equipo propio, una función dentro de Sistemas, o una responsabilidad distribuida? Esta decisión determina todo lo demás.

2Completar el mapa de diagnóstico una vez definido el equipo — usando la misma plantilla del resto de mapas en Confluence.

3Mapear la relación con Sistemas y clarificar qué cubre cada equipo en materia de seguridad, monitorización y respuesta ante incidentes para evitar zonas grises.

Zoho CRM

CRM y herramientas de negocio · Gestión comercial

Sin diagnóstico completado

⚠️

Mapa de diagnóstico vacío

El equipo Zoho no completó el cuestionario de diagnóstico. La plantilla está creada en Confluence pero sin ninguna respuesta. Sin esta información, no es posible hacer un diagnóstico real ni identificar riesgos con datos del equipo.

Sin datos de metodología Sin documentación evaluable Sin backlog registrado

Próximos pasos

1Completar el mapa de diagnóstico de Zoho en Confluence — es el primer paso antes de cualquier planificación. Sin datos, no hay base para decidir.

2Sesión de diagnóstico con el responsable del equipo para completar los pilares: metodología actual, terceros, documentación y backlog real.

3Del contexto externo (mapa de Innotutor y Webs) sabemos que hay bloqueos de 6+ meses con venta automatizada multiproducto. Esto requiere atención inmediata independientemente del diagnóstico.

Hallazgos transversales

Patrones que se repiten en la mayoría de equipos independientemente de su tecnología, tamaño o madurez. No son problemas aislados — son síntomas estructurales que el Plan de Transformación debe abordar de forma transversal.

⚠️

Hallazgo crítico

Bus factor generalizado

Prácticamente todos los equipos tienen una o dos personas que concentran el conocimiento crítico del sistema. La ausencia de cualquiera de ellos —Innotutor, MyLXP, Campus, Data, EducaSign, EducaCloud, Sistemas— generaría una parada inmediata o una degradación severa del servicio. No es un problema de talento, es un problema de estructura.

📄

Hallazgo crítico

Documentación como deuda, no como práctica

En todos los equipos, la documentación existe en estado parcial, desactualizado o directamente ausente. Las integraciones críticas, las arquitecturas y los flujos de negocio viven en la cabeza de las personas. Cuando alguien se va, se lleva el sistema consigo. Documentar no es una tarea pendiente — es una deuda que crece cada sprint.

🔗

Hallazgo importante

Dependencias entre equipos sin protocolo

Los equipos se bloquean entre sí con frecuencia — Innotutor bloquea a MyLXP, MyLXP bloquea a TutorLXP, Data depende de Zoho e Innotutor, Webs depende de decisiones de Zoho. No hay SLAs internos, no hay protocolo de escalación y no hay visibilidad compartida de dependencias activas. Cada equipo ve su backlog; nadie ve el cuello de botella global.

🧩

Hallazgo importante

Ausencia de metodología homogénea

Cada equipo ha desarrollado su propia forma de trabajar: sprints de distinta duración, canales de petición distintos (Teams, email, Jira, WhatsApp), criterios de priorización propios y distintos niveles de formalidad. Ningún equipo tenía un roadmap formal con hitos, fechas comprometidas y criterios de éxito visibles para el resto de la organización. La ausencia de un marco común y de una planificación compartida hace imposible medir, comparar o predecir capacidad a nivel de área — y deja a negocio sin visibilidad de cuándo llegará qué.

🏗️

Hallazgo estructural

Deuda técnica acumulada sin plan

La presión de entrega continua ha dejado en varios equipos capas de código heredado sin documentar, sin tests y sin propietario activo. En algunos casos —EducaPRO, EducaCloud, EducaSign— la deuda técnica es tan profunda que evolucionar el sistema implica un riesgo real de rotura sin capacidad de reparación. No es deuda técnica ordinaria — es fragilidad estructural.

🔒

Hallazgo estructural

Terceros sin SLA ni dueño

Varios equipos acumulan bloqueos activos con proveedores externos —ZRU, InnovaPay, Adyen, Namirial, Zoho— sin que haya un propietario de seguimiento, un SLA definido ni un protocolo de escalación. Los bloqueos de terceros se enquistan durante meses sin presión formal ni visibilidad ejecutiva, afectando a flujos de negocio críticos como el cobro o la firma digital.

Sección 03 · Qué tenemos que hacer

Objetivos estratégicos por tecnología

Plan Tecnológico 2026–2027. Objetivos estratégicos por herramienta con su línea de negocio, y objetivos operativos del equipo con criterio de medición y fecha.

Los tres vectores estratégicos del grupo

Tres apuestas que concentran la mayor parte de la energía del área de tecnología en 2026–2027. Detrás de cada prioridad del roadmap hay una justificación financiera, estratégica y operativa.

Pilar 01

Venta y Captación

Migramos las webs para frenar la caída de SEO e intentar mejorar el tráfico orgánico con un nuevo diseño que mejore la conversión.

Adaptamos Zoho con la creación de flujos para potenciar la venta automática y aumentar el LTV con automatizaciones basadas en el comportamiento del alumno y crosselling.

Pilar 02

Delivery

Impulsamos Phia One para mejorar el servicio primordialmente en B2B, con B2B Content en exploración y B2C en el horizonte.

Zoho como destino de migración de los equipos de postventa y Student Success.

Automatización de tutorías a través del Evaluador de Hawkings.

Pilar 03

Producto

Generación de contenido a través de EducaLLM e integración con nuestras herramientas y procesos.

Vector 01

Zoho One

CRM único del Grupo

— Venta automática

— Módulo del Estudiante

— Zoho Desk + Agentes IA

€ Justificación financiera

120.000 € / año

Ahorro en coste empresa/año derivado de las salidas habilitadas por la automatización de procesos con Zoho One. A esto se suma el impacto en ingresos por la escala de la venta automática y la crossventa sobre la base de alumnos existente — pendiente de cuantificar.

↗ Justificación estratégica

Los tres pilares de Zoho One forman un sistema de crecimiento integrado: venta automática, módulo del estudiante y Zoho Desk con agentes IA. Sin este triángulo, escalar en volumen implica escalar en plantilla.

⚙ Eficiencia operativa

Zoho One permite sacar procesos de herramientas legacy y centralizarlos en una plataforma moderna. Esto descarga a los equipos de ventas, marketing, postventa y Student Success de tareas repetitivas, elimina errores de coordinación entre herramientas y libera capacidad para trabajo de mayor valor.

Vector 02

Migración de webs

WordPress como estándar de marca

— Freno de la caída del tráfico + Mejoras de SEO

— Mejorar la captación

€ Justificación financiera

520.917 € – 1,97 M€

Las mejoras vinculadas a la migración — conversión, SEO/GEO, velocidad y UX — se traducen directamente en este incremento de ingresos brutos anuales en B2C.

↗ Justificación estratégica

La prioridad no es solo crecer — es frenar la caída de tráfico orgánico que estamos sufriendo e intentar recuperar posicionamiento. La migración a WordPress unificado es la base técnica que lo hace posible: permite construir una identidad digital coherente, aplicar mejoras de conversión de forma transversal y habilitar el posicionamiento SEO/GEO a escala sin depender de perfiles especializados por marca.

⚙ Eficiencia operativa

Los desarrollos actuales están sobre tecnologías heterogéneas con parches acumulados y deuda técnica significativa. Cada cambio menor requiere conocimiento especializado de la plataforma original, ralentiza los despliegues y genera riesgo de rotura. La migración a WordPress elimina esta fragmentación y permite al equipo trabajar con un estándar único, predecible y mantenible.

Vector 03

Hawkings

Innovación y ventaja competitiva

— EducaLLM

— Phia One

— Evaluador

€ Justificación financiera

Aumento ventas B2B +1,1 M€

Ahorro Publishing + Student Success +875K€

Total impacto Hawkings ~1,975 M€

EducaLLM, Phia One y el Evaluador generan impacto tanto en ingresos como en reducción de estructura operativa en los equipos de publishing y Student Success.

↗ Justificación estratégica

Somos una EdTech. La innovación no es opcional — es el relato, la promesa y la ventaja competitiva. Hawkings es donde ese relato se hace real: IA aplicada a la creación de contenido, a la experiencia del alumno y a la evaluación. Pero más allá del relato, Hawkings es una palanca de negocio concreta: vender más (top line) a través de una propuesta diferenciada en B2B y una mejor experiencia en B2C, y ahorrar más (bottom line) eficientando procesos en docencia, publishing y Student Success. Hawkings no es un proyecto de innovación aislado — es el soporte transversal de todo el roadmap.

⚙ Eficiencia operativa

EducaLLM acelera la creación de contenido formativo. El Evaluador mejora la calidad del feedback al alumno y reduce la carga docente. Phia One eleva la experiencia del alumno en el consumo. Procesos que hoy requieren intervención manual se automatizan, liberando capacidad en los equipos de publishing y Academic.

Impacto económico combinado de los tres vectores

1,51 M€ – 2,96 M€

Ahorro + ingresos / año · escenario conservador – optimista

Zoho One

120K€

ahorro CE/año

Migración Webs

521K – 1,97M€

ingresos B2C/año

Hawkings

~1,975 M€

ventas B2B + ahorro

Todos

Zoho

TutorLXP

Phia One

Webs

MyLXP

EducaLLM

Educa.Pro

SalesIQ

Innotutor

EducaPay

Campus

3CX

EducaSign

Educacloud

Data

Sistemas

⚙️

Zoho

Consecución de Zoho como CRM del Grupo

▼

🎓

TutorLXP

Herramienta única de gestión de la tutorización

▼

✨

Phia One

Sustituir a Moodle para la mejora de la experiencia del alumno

▼

🛒

Webs · Shopify · WordPress

Consecución de las migraciones a WordPress

▼

📱

MyLXP

Tecnología única para el alumnado

▼

🤖

EducaLLM

Establecer EducaLLM como herramienta corporativa de creación de contenido formativo

▼

🏢

Educa.Pro

Herramienta de formación corporativa

▼

💬

SalesIQ / WhatsApp

Herramienta de comunicación comercial y postventa

▼

🗄️

Innotutor

Base de conocimiento de todos los procesos y datos — sin ejecución

▼

💳

EducaPay / ZRU

Decidir si queremos que sea la tecnología de pago del grupo

▼

🎓

Campus (LMS)

Estabilización y sustitución progresiva por herramientas como Phia One

▼

📞

3CX

Gestión de comunicaciones telefónicas

▼

✍️

EducaSign

Estabilización de la herramienta

▼

☁️

Educacloud

Estabilización del proyecto — roadmap estratégico pendiente de decidir

▼

📊

Data

Consecución del Data Warehouse y KPIs ejecutivos

▼

🖥️

Sistemas

Commodity al servicio de tecnología

▼

	Q2						Q3						Q4						Q1 2027
	ABR		MAY		JUN		JUL		AGO		SEP		OCT		NOV		DIC		ENE		FEB		MAR
	1-15	16-30	1-15	16-31	1-15	16-30	1-15	16-31	1-15	16-31	1-15	16-30	1-15	16-31	1-15	16-30	1-15	16-31	1-15	16-31	1-15	16-28	1-15	16-31
Always — Mantenimiento, incidencias y peticiones recurrentes
Always on ▾ ver peticiones	Mantenimiento continuo · incidencias · peticiones recurrentes
Peticiones canalizadas en el always on Peticiones Facturación Peticiones Secretaría Peticiones B2B Content Peticiones Formación Bonificada Integraciones con Zoho Matriz de ventas Soporte Automatizaciones OPS
Estratégico
Facturación productos/servicios académicos
APIs módulo del estudiante · Business Schools
↳ Fase 1 · Solo lectura (datos visibles en Zoho, edición en Innotutor)
↳ Fase 2 · Bidireccional (lectura y escritura desde ambas herramientas)
Integración módulo del estudiante University
SAAS Secretaría
B2C — Matrícula automática · Refinamiento
B2B — Matrícula automática · Refinamiento
Integraciones MyLXP Bonificado
DB Producto · pendiente decisión
Operativo
Inventariar ExternalWS urgentemente
Distribuir conocimiento de Innotutor
Canal único Jira sin excepciones
Definir objetivo de equipo único
Onboarding EducaERPCore
Mejora de las cartas de bienvenida
Cierre de los campus antiguos
Authgate

	Q2						Q3						Q4						Q1 2027
	ABR		MAY		JUN		JUL		AGO		SEP		OCT		NOV		DIC		ENE		FEB		MAR
	1-15	16-30	1-15	16-31	1-15	16-30	1-15	16-31	1-15	16-31	1-15	16-30	1-15	16-31	1-15	16-30	1-15	16-31	1-15	16-31	1-15	16-28	1-15	16-31
Always — Mantenimiento, incidencias y peticiones recurrentes
Always on	Mantenimiento continuo · incidencias · peticiones recurrentes
Estratégico
Rediseño
Módulo de Alumni
Integración con Zoho Desk · alineado con Innotutor y TutorLXP
Integración requisitos de finalización — Carta de bienvenida Zoho
Integración Servicios Académicos — Crosselling / Conversión
Integración con agentes automatización servicio postventa
Añadir brandbook alineado con las webs por marca 🔒 bloqueado · brandbook equipo Webs
MyLXP Bonificada
Operativo
Documentar todas las integraciones: Innotutor, Campus, TutorLXP, PHIA
Reservar capacidad fija para tests en cada sprint
Planificar actualización de backoffice a Angular 19 de forma incremental
Traducción al chino

	Q2						Q3						Q4						Q1 2027
	ABR		MAY		JUN		JUL		AGO		SEP		OCT		NOV		DIC		ENE		FEB		MAR
	1-15	16-30	1-15	16-31	1-15	16-30	1-15	16-31	1-15	16-31	1-15	16-30	1-15	16-31	1-15	16-30	1-15	16-31	1-15	16-31	1-15	16-28	1-15	16-31
Always — Mantenimiento, incidencias y peticiones recurrentes
Always on	Mantenimiento continuo · incidencias · peticiones recurrentes
Estratégico
Integración Evaluador Hawkings
Tutorización formación bonificada
Integración con Zoho Desk · alineado con Innotutor
Operativo
Documentar el flujo de datos TutorLXP ↔ Innotutor, Campus, MyLXP y Educa.Pro
Completar el deploy automático del reporte CSV semanal
Reservar capacidad por sprint para tests automatizados
Aclarar el estado de comunicaciones masivas
Mejoras propuestas por los docentes
Mejoras propuestas por los coordinadores

	Q2						Q3						Q4						Q1 2027
	ABR		MAY		JUN		JUL		AGO		SEP		OCT		NOV		DIC		ENE		FEB		MAR
	1-15	16-30	1-15	16-31	1-15	16-30	1-15	16-31	1-15	16-31	1-15	16-30	1-15	16-31	1-15	16-30	1-15	16-31	1-15	16-31	1-15	16-28	1-15	16-31
Always — Mantenimiento, incidencias y peticiones recurrentes
Always on	Mantenimiento continuo · incidencias · peticiones recurrentes
Estratégico · Pendiente de confirmar
Migración a WordPress por marca
↳ INESEM
↳ INEAF
↳ REDEDUCA
↳ INESALUD
↳ EDUSPORT
↳ CEUPE
Lanzamiento Euroinnova
Operativo
Designar Product Owner formal por cada marca
Documentar arquitectura BBDD y Zoho

	Q2						Q3						Q4						Q1 2027
	ABR		MAY		JUN		JUL		AGO		SEP		OCT		NOV		DIC		ENE		FEB		MAR
	1-15	16-30	1-15	16-31	1-15	16-30	1-15	16-31	1-15	16-31	1-15	16-30	1-15	16-31	1-15	16-30	1-15	16-31	1-15	16-31	1-15	16-28	1-15	16-31
Always — Mantenimiento, incidencias y peticiones recurrentes
Always on	Mantenimiento continuo · incidencias · peticiones recurrentes
Estratégico
Integración del Evaluador
Envío de requisitos de finalización a MyLXP
Integraciones tutorizar desde TutorLXP formación bonificada
Plan de migración a Phia One 🔒 bloqueado · depende de Hawkings
Operativo
Sesiones periódicas de transferencia de conocimiento
Documentar Sincroapp y el Validador de documentación
Cierre de campus antiguos

Nombre	Equipo	Empresa	Salario bruto/año	Coste empresa/año	Timing
Carlos Castelo	Shopify	Euroinnova Business School	42.000 €	55.464 €	Ya salido
Victor Pérez Torney	Shopify	Mercantil	—	30.000 €	Junio 2026
Ismael Pérez	Shopify	Mercantil	—	30.000 €	Junio 2026
Yoelkys Rodríguez	Shopify	Mercantil	—	30.000 €	Junio 2026
TOTAL AHORRO			—	−236.832 € CE/año

Nombre	Equipo	Empresa	Salario bruto/año	Coste empresa/año	Estado
José Sánchez	Shopify / BD Producto	Educa EdTech	47.000 €	62.004 €	Laboral · Por confirmar
Jorge González (Kai)	Shopify / BD Producto	Educa EdTech	45.000 €	59.364 €	Laboral · Por confirmar
Osuna Jurado, Anabel	—	—	—	59.436 €	Laboral · Por confirmar
Santodomingo Fuenmayor, Jossue David	—	—	—	30.000 €	Laboral · Por confirmar
Castellanos, Jeison	—	—	—	30.000 €	Laboral · Por confirmar
Rodríguez, Ariel	Shopify	—	—	30.000 €	Laboral · Por confirmar
Hernández Jimeno, Javier	EducaCloud	—	—	50.448 €	Laboral · Por confirmar
Rodríguez, Marta	EducaCloud	—	—	36.984 €	Laboral · Por confirmar
TOTAL IMPACTO POTENCIAL			—	−358.236 € CE/año

Perfil	Equipo	Justificación	Salario bruto/año (est.)	Coste empresa/año (est.)	Estado
Data Engineer	Data	Escalar el Data Warehouse y reducir el bus factor en el equipo de datos	~45.000–55.000 €	~66.000 €	Potencial
Full Stack Web Developer #1	Webs	Refuerzo equipo de desarrollo web	35.000 €	~46.200 €	Potencial
Full Stack Web Developer #2	Webs	Refuerzo equipo de desarrollo web	35.000 €	~46.200 €	Potencial
TOTAL COSTE ENTRADAS POTENCIALES			—	+158.400 € CE/año

Plan de TransformaciónTecnológica

La línea de comunicación

Auditoría

Mapa tecnológico

Objetivos por equipo

Roadmap

Metodología

Organigrama

Impacto económico

Auditoría de equipos

Innotutor · EducaERPCore · AuthGate · ExternalWS

Metodología real

Relación con terceros

Documentación

Backlog y estado

Fortalezas

Riesgos

Acciones prioritarias

MyLXP

Metodología real

Relación con terceros

Documentación

Backlog y estado

Fortalezas

Riesgos

Acciones prioritarias

TutorLXP

Metodología real

Relación con terceros

Documentación

Backlog y estado

Fortalezas

Riesgos

Acciones prioritarias

Educa.Pro · Educa Pharos

Metodología real

Relación con terceros

Documentación

Backlog y estado

Fortalezas

Riesgos

Acciones prioritarias

Data

Metodología real

Relación con terceros

Documentación

Backlog y estado

Fortalezas

Riesgos

Acciones prioritarias

EducaPay

Metodología real

Relación con terceros

Documentación

Backlog y estado

Fortalezas

Riesgos

Acciones prioritarias

EducaSign

Metodología real

Relación con terceros

Documentación

Backlog y estado

Fortalezas

Riesgos

Acciones prioritarias

Educacloud

Metodología real

Relación con terceros

Documentación

Backlog

Fortalezas

Riesgos

Acciones prioritarias · Cierre de fase y transición a mantenimiento

Webs

Metodología real

Relación con terceros

Documentación

Backlog

Fortalezas

Plan de Transformación
Tecnológica