1. Introducción a la Gestión de Proyectos TIC en el Sector Público y Sanitario

1.1. ¿Qué es un Proyecto?

Definición PMBOK® (Project Management Body of Knowledge)

Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único.

Características clave:

• Temporal: Tiene inicio y fin definidos (vs operaciones continuas).
• Único: Resultado diferente de otros (aunque haya similitudes). Ej: Implementar Diraya en Hospital Virgen del Rocío ≠ implementar en Hospital Reina Sofía (contexto, usuarios, infraestructura… diferentes).
• Elaboración gradual: Se desarrolla en fases incrementales, refinando detalles progresivamente.

Proyecto vs Operación

1.2. ¿Qué es un Proyecto TIC?

Un proyecto TIC (Tecnologías de la Información y Comunicación) es aquel cuyo objetivo principal es desarrollar, implementar, actualizar o mejorar sistemas informáticos, infraestructuras tecnológicas, aplicaciones software, redes, seguridad informática…

Ejemplos proyectos TIC en el SAS:

• Desarrollo software: Crear nueva app móvil ClicSalud+ con funcionalidad videoconsulta.
• Implantación sistema: Desplegar sistema PACS nuevo en 5 hospitales andaluces.
• Migración: Migrar servidores Diraya de CPD on-premise a cloud Azure.
• Actualización: Actualizar versión Diraya de 5.2 a 6.0 en toda Andalucía.
• Infraestructura: Desplegar red 5G en hospitales de referencia.
• Seguridad: Implementar SOC (Security Operations Center) sanitario 24/7.
• Integración: Integrar Diraya con sistema de servicios sociales (proyecto SocioSalud, visto Tema 34).

1.3. Desafíos Específicos de Proyectos TIC en Sector Público

Los proyectos TIC en administraciones públicas (como el SAS) tienen desafíos particulares vs sector privado:

1. Complejidad Normativa y Burocracia

• Problema: Contratación pública rigurosa (LCSP), fiscalización previa Intervención, trámites múltiples (pliegos, licitación, adjudicación, firma contrato…) → proceso lento (6-12 meses desde inicio licitación hasta adjudicación).
• Impacto proyecto: Retrasos planificación, tecnología obsoleta cuando finalmente se contrata (mercado TIC evoluciona rápido).
• Mitigación: Planificar contrataciones con mucha anticipación, usar acuerdos marco SGAD (ya licitados, adjudicación rápida), flexibilidad pliegos (permitir equivalencias tecnológicas).

2. Multiplicidad de Stakeholders (Interesados)

• Problema: En sector público, MUCHOS interesados con intereses diversos/contradictorios:
  • Políticos: Quieren resultados visibles antes elecciones, priorizan imagen pública.
  • Directivos SAS: Quieren eficiencia, reducir costes, mejorar indicadores.
  • Profesionales sanitarios (usuarios finales): Quieren sistemas fáciles usar, que NO interrumpan trabajo clínico.
  • TIC: Quieren tecnología robusta, mantenible, segura.
  • Ciudadanos/pacientes: Quieren servicios accesibles, rápidos, privados.
  • Sindicatos: Representan trabajadores, velan por condiciones laborales (implantación NO debe sobrecargar).
  • Proveedores: Quieren maximizar beneficio, minimizar riesgos contractuales.
• Impacto proyecto: Requisitos contradictorios, cambios frecuentes alcance, resistencia al cambio, conflictos.
• Mitigación: Gestión proactiva stakeholders (identificar, analizar, involucrar, comunicar, negociar compromisos), governance fuerte (comité dirección proyecto con representación equilibrada).

3. Restricciones Presupuestarias Rígidas

• Problema: Presupuesto público limitado, asignado anualmente (ejercicio fiscal), difícil conseguir ampliaciones. Contratos cerrados (precio/alcance fijos).
• Impacto proyecto: Poco margen error, riesgo recortes alcance si aparecen imprevistos, tentación adjudicar «más barato» aunque no sea mejor (riesgo calidad).
• Mitigación: Estimaciones realistas (NO optimistas), gestión estricta cambios alcance (change control), reservas contingencia (aunque limitadas), enfoque value for money (no solo precio más bajo, sino mejor relación calidad-precio).

4. Sistemas Legacy y Deuda Técnica

• Problema: AAPP tienen sistemas antiguos (décadas), tecnologías obsoletas (COBOL, mainframes…), arquitecturas monolíticas rígidas. Alto acoplamiento, documentación escasa, dependencia proveedores antiguos (lock-in).
• Impacto proyecto: Integración compleja, migraciones arriesgadas (sistema crítico 24/7, NO puede caer), compatibilidad retroactiva obligatoria.
• Ejemplo SAS: Diraya tiene componentes de hace >20 años, migrar a arquitectura cloud manteniendo compatibilidad con módulos legacy es reto mayúsculo.
• Mitigación: Modernización incremental (estrategia strangler fig: envolver legacy con APIs modernas, migrar funcionalidades gradualmente), microservicios, inversión en refactoring técnico (aunque NO da rédito político inmediato).

5. Seguridad y Privacidad Críticas

• Problema: Datos de salud categoría especial (RGPD), ENS obligatorio (nivel ALTO para Diraya), ciberataques frecuentes (ransomware…).
• Impacto proyecto: Requisitos seguridad estrictos desde inicio (security by design), auditorías ENS, EIPD (Evaluación Impacto Protección Datos), incrementa coste/tiempo proyecto.
• Mitigación: Involucrar CISO (Chief Information Security Officer) y DPO (Data Protection Officer) desde fase planificación, formación seguridad equipo proyecto, threat modeling, pentesting antes producción.

6. Resistencia al Cambio y Gestión del Cambio Organizacional

• Problema: Empleados públicos (profesionales sanitarios, administrativos) pueden resistirse a nuevos sistemas (curva aprendizaje, temor tecnología, inercia «siempre lo hemos hecho así»).
• Impacto proyecto: Bajo uso sistema nuevo (fracaso adopción), sabotaje pasivo (seguir usando sistema antiguo), quejas, estrés laboral.
• Mitigación: Plan gestión cambio robusto (comunicación temprana/frecuente, formación intensiva, soporte post-implantación, embajadores digitales -early adopters entusiastas-, incentivos uso, diseño UX centrado usuario).

1.4. Importancia de la Gestión Profesional de Proyectos TIC

¿Por qué NO basta «ir haciendo» sin metodología formal?

Estadísticas industria (fuente: Standish Group Chaos Report, PMI Pulse of Profession):

• Solo ~35% proyectos TIC se consideran exitosos (entregados en plazo, presupuesto, alcance cumplido, calidad aceptable).
• ~50% proyectos sufren retrasos/sobrecostes significativos.
• ~15% proyectos fracasan totalmente (cancelados antes finalizar, o entregados pero NO usados).
• Sector público: Tasa fracaso históricamente PEOR que privado (aunque mejorando últimos años con profesionalización).

Causas principales fracaso proyectos TIC:

1. Requisitos incompletos/cambiantes (40% fracasos): NO saber QUÉ se quiere construir exactamente.
2. Falta apoyo ejecutivo (30%): Dirección NO respalda proyecto, falta autoridad PM, decisiones bloqueadas.
3. Recursos inadecuados (25%): Equipo insuficiente, sin competencias necesarias, sobrecargado.
4. Expectativas irreales (20%): Plazos/presupuestos imposibles, alcance demasiado ambicioso.
5. Falta planificación (20%): Empezar a desarrollar SIN plan, improvisar sobre la marcha.
6. Mala gestión riesgos (15%): NO identificar/mitigar riesgos, sorpresas tardías.
7. Comunicación deficiente (15%): Stakeholders desinformados, equipo descoordinado, expectativas desalineadas.

Beneficios gestión profesional proyectos:

• Mayor probabilidad éxito: Metodología comprobada reduce riesgos, incrementa predictibilidad.
• Control: Saber en todo momento estado proyecto (avance, costes consumidos, riesgos activos…).
• Eficiencia: Optimizar recursos, evitar desperdicios (retrabajo, duplicaciones…).
• Calidad: Definir y verificar estándares calidad, testing riguroso.
• Comunicación: Stakeholders informados, expectativas gestionadas, conflictos resueltos proactivamente.
• Aprendizaje: Lecciones aprendidas documentadas, mejora continua para futuros proyectos.

2. Principales Estándares y Marcos de Referencia en Gestión de Proyectos

2.1. PMBOK® (Project Management Body of Knowledge) – PMI

¿Qué es PMBOK®?

PMBOK® (Guide to the Project Management Body of Knowledge) es la guía estándar de gestión de proyectos más reconocida mundialmente, desarrollada por PMI (Project Management Institute), organización profesional con sede en EE.UU., fundada en 1969.

Versiones y evolución:

• PMBOK® 6ª edición (2017): Versión más extendida, enfoque tradicional (predictivo).
• PMBOK® 7ª edición (2021): Cambio paradigma → enfoque basado en principios y dominios, integra metodologías ágiles, híbridas.
• Adopción España: PMBOK® 6ª muy usado en grandes empresas consultoras (Indra, Everis, Atos…) que trabajan con SAS. PMBOK® 7ª adoptándose gradualmente.

PMBOK® 6ª Edición: 10 Áreas de Conocimiento

PMBOK® 6ª: 5 Grupos de Procesos

1. Iniciación: Autorizar proyecto, definir objetivos preliminares (Project Charter).
2. Planificación: Desarrollar plan detallado para ejecutar proyecto (WBS, cronograma, presupuesto, plan riesgos…).
3. Ejecución: Coordinar personas y recursos para realizar trabajo planificado.
4. Monitoreo y Control: Seguir, revisar y regular progreso, identificar desviaciones, tomar acciones correctivas.
5. Cierre: Finalizar formalmente proyecto, transferir productos, documentar lecciones aprendidas.

PMBOK® 7ª Edición: Cambio Paradigma

PMBOK® 7ª abandona enfoque rígido «áreas conocimiento + grupos procesos», adopta:

• 12 Principios gestión proyectos (ej: ser buen administrador, crear ambiente colaborativo, demostrar comportamientos liderazgo…).
• 8 Dominios rendimiento (stakeholders, equipo, enfoque desarrollo/ciclo vida, planificación, trabajo proyecto, entrega, medición, incertidumbre).
• Flexibilidad metodológica: Integra predictivo, ágil, híbrido según contexto proyecto.

2.2. PRINCE2 (PRojects IN Controlled Environments)

Origen: Metodología desarrollada por gobierno británico en 1989, refinada continuamente. Muy popular Reino Unido, países Commonwealth, creciente adopción Europa.

Filosofía: Enfoque basado en principios, temas y procesos, con énfasis en justificación comercial continua y gestión por excepción.

7 Principios PRINCE2

1. Justificación comercial continua: Proyecto debe tener razón de negocio válida durante toda su duración.
2. Aprender de la experiencia: Buscar, registrar y aplicar lecciones aprendidas.
3. Roles y responsabilidades definidos: Estructura organizativa clara con accountability.
4. Gestión por fases: Dividir proyecto en fases manejables con puntos de decisión.
5. Gestión por excepción: Autorizar tolerancias, escalar solo cuando se excedan.
6. Enfoque en productos: Definir claramente productos/entregables antes que actividades.
7. Adaptar al entorno: Metodología flexible, adaptable a contexto específico proyecto.

7 Temas PRINCE2

1. Business Case: Justificación económica/estratégica proyecto.
2. Organización: Estructura roles (Board Proyecto, Project Manager, Team Managers…).
3. Calidad: Requisitos calidad, criterios aceptación, técnicas aseguramiento.
4. Planes: Planificación basada en productos (Product Breakdown Structure).
5. Riesgos: Identificación, evaluación, tratamiento, monitorización.
6. Cambios: Control cambios configuración, issues, change requests.
7. Progreso: Monitorización avance, reporting, control desviaciones.

7 Procesos PRINCE2

1. Starting up a Project (SU): Pre-proyecto, verificar viabilidad.
2. Directing a Project (DP): Governance alto nivel por Board Proyecto.
3. Initiating a Project (IP): Crear fundamentos sólidos proyecto.
4. Controlling a Stage (CS): Gestión día a día por Project Manager.
5. Managing Product Delivery (MP): Coordinar entrega productos con teams.
6. Managing a Stage Boundary (SB): Transición entre fases.
7. Closing a Project (CP): Cierre formal, transferencia productos.

Aplicación PRINCE2 en sector público:

• Ventaja: Metodología diseñada originalmente para gobierno → encaja bien sector público (accountability, transparencia, justificación continua business case…).
• Adopción España: Menor que PMBOK® pero creciente, especialmente grandes proyectos transformación digital AAPP.
• SAS: Algunos elementos PRINCE2 podrían adaptarse (ej: Business Case riguroso, gestión por fases con gates de aprobación).

2.3. ISO 21500: Guidance on Project Management

¿Qué es ISO 21500?

Estándar internacional de ISO (International Organization for Standardization), publicado en 2012, que proporciona orientación sobre gestión de proyectos.

Características ISO 21500:

• No es metodología específica (como PMBOK® o PRINCE2), sino marco general que puede aplicarse a cualquier proyecto, independientemente tamaño, complejidad, duración.
• Estructura similar PMBOK®: 10 materias conocimiento + 5 grupos procesos, pero más genérico.
• Enfoque procesos: 39 procesos organizados matricialmente.
• Compatibilidad: Diseñado para ser compatible con otros estándares PM (PMBOK®, PRINCE2…).

10 Materias de Conocimiento ISO 21500:

Similares PMBOK®: Integración, Interesados, Alcance, Recursos, Tiempo, Costes, Riesgos, Calidad, Adquisiciones, Comunicación.

Aplicabilidad SAS:

• Ventaja: Al ser estándar ISO, tiene reconocimiento internacional oficial, útil para auditorías, certificaciones.
• Uso práctico: Más como referencia complementaria que metodología principal. Puede usarse para verificar que metodología corporativa (ej: MCMI SAS) cubre todos aspectos esenciales gestión proyectos.

2.4. PM² (PM Squared) – Metodología Comisión Europea

Origen y contexto

PM² es metodología gestión proyectos desarrollada por Comisión Europea para sus propios proyectos internos, publicada abiertamente para uso general. Primera versión 2007, versión actual 3.0 (2018).

¿Por qué Comisión Europea creó su propia metodología?

• Necesidad metodología específica sector público y entorno europeo.
• PMBOK® desarrollado para sector privado estadounidense, PRINCE2 para gobierno británico → no encajaban perfectamente contexto UE.
• Proyectos UE tienen características específicas: multinacionalidad, multilingüismo, regulación estricta, accountability democrática…

Filosofía PM²:

• Ligero pero completo: No demasiado burocrático, pero cubre todos aspectos esenciales.
• Fácil entender y aplicar: Lenguaje claro, plantillas prácticas.
• Flexible: Adaptable diferentes tipos/tamaños proyecto.
• Orientado resultados: Enfoque en entregables concretos y beneficios para stakeholders.

Estructura PM²: 4 Fases

1. Iniciating: Definir proyecto, obtener autorización, formar equipo inicial.
2. Planning: Desarrollar plan detallado (WBS, cronograma, presupuesto, riesgos…).
3. Executing: Realizar trabajo, gestionar equipo, comunicar progreso, controlar desviaciones.
4. Closing: Entregar productos, evaluar proyecto, documentar lecciones, celebrar éxito.

Artefactos PM² (documentos clave):

• Project Charter: Autorización formal proyecto.
• Project Handbook: Plan maestro proyecto (equivale Project Management Plan de PMBOK®).
• Work Breakdown Structure (WBS): Descomposición jerárquica trabajo.
• Risk Log: Registro riesgos identificados y respuestas.
• Issue Log: Registro problemas surgidos y resoluciones.
• Change Log: Registro cambios solicitados y aprobados.

Relevancia PM² para Junta Andalucía/SAS:

• Alta: Al ser metodología oficial UE, es referencia natural para proyectos cofinanciados fondos europeos (Next Generation EU, FEDER, FSE+…).
• Compatibilidad cultural: Diseñada para administraciones públicas europeas → encaja mejor contexto AAPP españolas que metodologías anglosajonas.
• Adopción España: Varias CCAA y ministerios empezando a adoptar PM² como referencia, especialmente proyectos con financiación UE.
• MCMI SAS: Probablemente influenciado por PM² (aunque no documentado públicamente).

2.5. COBIT 5 y su Relación con Gestión de Proyectos TIC

¿Qué es COBIT?

COBIT (Control Objectives for Information and Related Technologies) es marco de gobierno y gestión TIC desarrollado por ISACA (Information Systems Audit and Control Association).

Diferencia fundamental:

• PMBOK®, PRINCE2, PM² → Gestión de proyectos (enfoque temporal, crear producto único).
• COBIT → Gobierno TIC (enfoque continuo, gestionar función TIC organizacional).

¿Por qué incluir COBIT en tema gestión proyectos?

Porque proyectos TIC NO existen en vacío, sino dentro de marco gobierno TIC organizacional:

• Proyectos TIC deben alinearse con estrategia organizacional (COBIT proceso APO01).
• Proyectos consumen recursos TIC que deben gestionarse (COBIT proceso APO03).
• Productos proyectos TIC deben operarse y mantenerse tras entrega (COBIT proceso DSS01-06).
• Proyectos TIC deben cumplir requisitos regulatorios (ENS, RGPD…) (COBIT proceso MEA01-03).

COBIT 5: Estructura

• 5 Principios: Satisfacer necesidades stakeholders, cubrir empresa end-to-end, aplicar marco único integrado, habilitar enfoque holístico, separar gobierno de gestión.
• 7 Habilitadores: Principios/políticas, procesos, estructuras organizacionales, cultura/ética/comportamiento, información, servicios/infraestructura/aplicaciones, personas/habilidades/competencias.
• 37 Procesos organizados en 5 dominios:
  • EDM (Evaluate, Direct, Monitor): Gobierno (5 procesos).
  • APO (Align, Plan, Organize): Alineación, planificación, organización (13 procesos).
  • BAI (Build, Acquire, Implement): Construir, adquirir, implementar (10 procesos) ← MÁS RELEVANTE PARA PROYECTOS.
  • DSS (Deliver, Service, Support): Entregar, dar servicio, soportar (6 procesos).
  • MEA (Monitor, Evaluate, Assess): Monitorizar, evaluar, valorar (3 procesos).

Procesos COBIT más relevantes para gestión proyectos TIC:

• APO05: Gestionar portfolio proyectos/programas → priorización, asignación recursos, governance portfolio.
• BAI01: Gestionar programas e inversiones → Business case, aprobación inversiones TIC.
• BAI02: Gestionar definición requisitos → análisis necesidades, especificación requisitos.
• BAI03: Gestionar identificación y construcción soluciones → diseño, desarrollo, testing.
• BAI04: Gestionar disponibilidad y capacidad → dimensionado infraestructura, planning capacidad.
• BAI07: Gestionar aceptación cambio e implantación → go-live, gestión cambio organizacional.
• BAI08: Gestionar conocimiento → documentación, knowledge management, lecciones aprendidas.
• BAI09: Gestionar activos → inventario HW/SW, gestión configuración.
• BAI10: Gestionar configuración → control versiones, baseline management.

Aplicación COBIT en SAS:

• Macro-nivel: Subdirección TI SAS debería aplicar principios COBIT para gobierno/gestión global función TIC.
• Nivel proyectos: Proyectos TIC SAS deberían seguir procesos BAI relevantes (además metodología gestión proyectos tipo MCMI).
• Ejemplo: Proyecto migración Diraya cloud seguiría:
  • MCMI (metodología gestión proyecto específica).
  • COBIT BAI01 (business case, aprobación inversión).
  • COBIT BAI07 (gestión cambio organizacional).
  • COBIT DSS01-06 (operaciones post-migración).

3. Guías de Buenas Prácticas y Metodologías: Tradicional vs Ágil

3.1. Metodologías Tradicionales (Predictivas) vs Ágiles (Adaptativas)

Contexto histórico

La gestión de proyectos evolucionó en el s. XX en industrias tradicionales (construcción, aeroespacial, defensa), donde requisitos eran estables, cambios costosos. Resultado: metodologías predictivas (planificar todo por adelantado, ejecutar según plan).

En los años 90-2000, proyectos software se enfrentaban a:

• Requisitos cambiantes continuamente.
• Tecnologías evolucionando rápidamente.
• Necesidad entregar valor rápido (time-to-market).
• Fracasos metodologías tradicionales en software (proyectos retrasados, productos obsoletos al entregarse).

Respuesta: Manifiesto Ágil (2001), que dio origen metodologías ágiles (Scrum, XP, Kanban…).

Comparativa Fundamental

3.2. Metodología Waterfall (Cascada)

Descripción

Waterfall (Cascada) es la metodología predictiva clásica, fases secuenciales que «caen» como cascada:

1. Análisis de Requisitos: Recopilar y documentar TODOS los requisitos.
2. Diseño: Diseñar arquitectura, interfaces, bases de datos, algoritmos…
3. Implementación (Desarrollo): Codificar sistema según diseño.
4. Verificación (Testing): Probar sistema completo.
5. Mantenimiento (Despliegue y Soporte): Entregar a producción, soporte post-lanzamiento.

Cada fase debe completarse ANTES de pasar a siguiente. Metáfora: «cascada» → agua NO puede subir.

Cuándo usar Waterfall

• Requisitos muy claros y estables: Ej. regulación rígida, sistema con especificaciones técnicas detalladas.
• Cambios prohibitivos: Ej. hardware embebido, donde cambio post-fabricación es extremadamente caro.
• Cliente/sponsor exige documentación formal: Contratos públicos que requieren entregables documentales rigurosos.
• Equipo distribuido con poca comunicación: Documentación exhaustiva compensa falta interacción.
• Tecnología madura y probada: Poca incertidumbre técnica.

Ejemplos aplicación Waterfall en SAS

• Migración infraestructura CPD: Migrar 100 servidores físicos de CPD A a CPD B. Requisitos claros (inventario servidores, topología red…), cambios mínimos durante ejecución, fases bien definidas (análisis → diseño migración → ejecución migración → verificación).
• Actualización masiva hardware: Renovar 5.000 PCs en hospitales. Especificaciones HW detalladas, licitación cerrada, despliegue fase a fase por hospitales.
• Implantación sistema COTS (Commercial Off-The-Shelf): Instalar sistema ERP comercial estándar (ej: SAP). Producto predefinido, personalización limitada, fases análisis → configuración → testing → go-live.

Ventajas Waterfall

• Simplicidad conceptual: Fácil entender, estructura clara.
• Predecibilidad: Plan detallado, estimaciones estables (si requisitos NO cambian).
• Documentación completa: Trazabilidad, auditable, útil mantenimiento largo plazo.
• Roles y responsabilidades claras: Cada fase tiene responsables definidos.

Desventajas Waterfall

• Rigidez: Muy difícil/caro cambiar requisitos a mitad proyecto.
• Riesgo entrega tardía de valor: Cliente NO ve producto funcionando hasta final → riesgo descubrir tarde que NO es lo que necesitaba.
• Inadecuado para proyectos innovadores: Si hay incertidumbre técnica o requisitos emergentes, Waterfall falla.
• Efecto «Big Bang»: Todo el riesgo concentrado en go-live final (si falla, desastre total).

3.3. Metodologías Ágiles: Filosofía y Principios

Manifiesto Ágil (2001)

17 pioneros desarrollo software (Kent Beck, Martin Fowler, Jeff Sutherland, Ken Schwaber…) se reunieron y redactaron Manifiesto por el Desarrollo Ágil de Software.

4 Valores Fundamentales:

1. Individuos e interacciones sobre procesos y herramientas.
2. Software funcionando sobre documentación exhaustiva.
3. Colaboración con el cliente sobre negociación contractual.
4. Respuesta ante el cambio sobre seguir un plan.

(Nota: Se valoran elementos de la derecha, pero se valoran MÁS los de la izquierda)

12 Principios Ágiles (selección relevante para SAS):

• Satisfacer al cliente mediante entrega temprana y continua de software valioso.
• Aceptar cambios de requisitos, incluso en etapas tardías.
• Entregar software funcionando frecuentemente (semanas, no meses).
• Colaboración diaria entre negocio y desarrolladores.
• Proyectos se desarrollan en torno a individuos motivados, darles entorno y apoyo, confiar en que harán trabajo.
• Conversación cara a cara es método más eficiente comunicación.
• Software funcionando es medida principal de progreso.
• Desarrollo sostenible: promotores, desarrolladores, usuarios deben mantener ritmo constante indefinidamente.
• Atención continua a excelencia técnica y buen diseño mejora agilidad.
• Simplicidad (maximizar trabajo NO hecho) es esencial.
• Mejores arquitecturas/requisitos/diseños emergen de equipos auto-organizados.
• A intervalos regulares, equipo reflexiona sobre cómo ser más efectivo, ajusta comportamiento.

3.4. Scrum

¿Qué es Scrum?

Scrum es el marco ágil más popular (usado en ~70% proyectos ágiles). Desarrollado por Jeff Sutherland y Ken Schwaber en los 90, formalizado en Scrum Guide (versión actual 2020).

Filosofía Scrum: Desarrollo iterativo e incremental en Sprints (ciclos cortos, típicamente 2-4 semanas), con equipo auto-organizado, inspección y adaptación continuas.

Roles Scrum

• Product Owner (PO): Representa stakeholders, define/prioriza Product Backlog (lista requisitos), maximiza valor producto.
• Scrum Master (SM): Facilitador, coach, elimina impedimentos, asegura que equipo sigue Scrum correctamente.
• Development Team (Equipo Desarrollo): Profesionales que hacen el trabajo (diseño, desarrollo, testing…). Auto-organizados, multifuncionales, 3-9 personas.

Artefactos Scrum

• Product Backlog: Lista ordenada por prioridad de todo lo que se necesita en producto (user stories, requisitos técnicos, bugs…).
• Sprint Backlog: Subconjunto Product Backlog seleccionado para Sprint actual + plan entregarlo.
• Increment (Incremento): Suma de todos items Product Backlog completados durante Sprint + incrementos anteriores. Debe ser potencialmente entregable (Definition of Done cumplida).

Eventos Scrum

1. Sprint: Contenedor de todos demás eventos, duración fija (2-4 semanas), empieza inmediatamente tras finalizar anterior.
2. Sprint Planning: Planificar trabajo Sprint (qué se hará, cómo se hará). Máx 8h para Sprint 1 mes.
3. Daily Scrum (Daily Standup): Reunión diaria 15 min, equipo sincroniza trabajo, planifica próximas 24h, identifica impedimentos.
4. Sprint Review: Final Sprint, inspeccionar Incremento, adaptar Product Backlog si necesario. Máx 4h para Sprint 1 mes. Demo producto a stakeholders.
5. Sprint Retrospective: Final Sprint, equipo reflexiona sobre proceso, identifica mejoras. Máx 3h para Sprint 1 mes.

Flujo típico Scrum

Product Backlog → Sprint Planning → Sprint (2-4 sem) → Daily Scrum (15 min/día)
    ↓                                        ↓
Priorizado PO                        Desarrollo + Testing
    ↓                                        ↓
                                  Sprint Review (demo)
                                             ↓
                                  Incremento Potencialmente Entregable
                                             ↓
                                  Sprint Retrospective (mejora)
                                             ↓
                                  Siguiente Sprint...

Aplicación Scrum en SAS

• Desarrollo nuevas funcionalidades Diraya: Ej. módulo videoconsulta. PO = responsable funcional SAS, Scrum Master = líder técnico, Dev Team = desarrolladores + DBAs + diseñadores UX. Sprints 3 semanas, entregas incrementales a entorno pruebas, Sprint Review con médicos/enfermeras (usuarios finales).
• Evolución ClicSalud+: App móvil con cambios frecuentes basados en feedback usuarios. Scrum permite iteraciones rápidas, adaptación continua.
• Proyectos innovación (IA, Big Data): Alta incertidumbre técnica, requisitos emergentes → Scrum ideal.

Ventajas Scrum

• Entrega valor temprana y frecuente: Stakeholders ven progreso real cada Sprint.
• Adaptabilidad: Cambios requisitos bienvenidos, se priorizan en Product Backlog.
• Transparencia: Progreso visible (Burndown charts, Sprint Reviews…).
• Feedback continuo: Usuarios validan incrementos cada Sprint, correcciones rápidas.
• Motivación equipo: Auto-organización, empoderamiento, ritmo sostenible.

Desafíos Scrum en Sector Público

• Contratos cerrados: Scrum asume alcance flexible, pero contratos públicos suelen ser alcance/precio cerrado → tensión. Mitigación: Contratos por horas (time & materials) o sprints (difícil aprobar en AAPP), o híbrido (alcance marco + flexibilidad interna).
• Documentación mínima vs auditorías: Auditorías públicas requieren documentación exhaustiva. Mitigación: Documentación justa y suficiente (no mínima, pero no exhaustiva), automatizar generación documentación desde código/tests.
• Disponibilidad Product Owner: PO debe dedicar tiempo significativo (priorizar backlog, responder dudas, asistir Sprint Reviews…). En AAPP, PO suele ser directivo/responsable funcional con agenda apretada. Mitigación: Asignar PO dedicado (o Proxy PO), proteger tiempo agenda PO.

3.5. Kanban

¿Qué es Kanban?

Kanban (palabra japonesa: «tarjeta visual») es método gestión trabajo basado en visualización flujo y limitar trabajo en progreso (WIP – Work In Progress). Originado en manufactura Toyota (años 40), adaptado desarrollo software por David Anderson (2007).

Principios Kanban

1. Visualizar el flujo de trabajo: Tablero Kanban con columnas representando estados (ej: To Do → In Progress → Testing → Done).
2. Limitar WIP: Máximo X elementos en cada columna simultáneamente (evita sobrecarga, cuellos botella visibles).
3. Gestionar flujo: Optimizar tiempo ciclo (cuánto tarda ítem desde inicio a fin).
4. Hacer políticas explícitas: Definir claramente criterios mover ítem entre columnas (Definition of Done por columna).
5. Mejora continua (Kaizen): Revisar métricas (lead time, throughput…), experimentar mejoras.

Tablero Kanban típico

┌──────────┬──────────┬──────────┬──────────┬──────────┐
│  Backlog │  To Do   │Desarrollo│  Testing │   Done   │
│          │  WIP≤3   │  WIP≤2   │  WIP≤2   │          │
├──────────┼──────────┼──────────┼──────────┼──────────┤
│ [Task 10]│ [Task 5] │ [Task 2] │ [Task 1] │ [Task 4] │
│ [Task 11]│ [Task 6] │ [Task 3] │          │ [Task 7] │
│ [Task 12]│ [Task 8] │          │          │ [Task 9] │
│   ...    │          │          │          │          │
└──────────┴──────────┴──────────┴──────────┴──────────┘

Diferencias Kanban vs Scrum

• Iteraciones: Scrum usa Sprints fijos (2-4 sem). Kanban NO tiene iteraciones fijas, flujo continuo.
• Roles: Scrum define roles (PO, SM, Dev Team). Kanban NO prescribe roles específicos.
• Cambios: Scrum, cambios entre Sprints. Kanban, cambios en cualquier momento (añadir ítem al backlog, re-priorizar).
• Métricas: Scrum usa Velocity (story points/Sprint). Kanban usa Lead Time, Cycle Time, Throughput.
• Compromiso: Scrum, equipo se compromete a Sprint Backlog. Kanban, NO compromisos formales, flujo según capacidad.

Cuándo usar Kanban en SAS

• Soporte y mantenimiento: Service Desk SAS gestiona tickets soporte. Kanban perfecto: flujo continuo tickets (NO sprints), WIP limitado (técnicos NO saturados), visualización colas.
• Operaciones TIC: Tareas operativas (backups, monitorizaci ón, parches…) continuas, variadas, impredecibles. Kanban se adapta mejor que Scrum.
• Mejora continua sistemas existentes: Pequeñas mejoras Diraya (bugs, micro-features). Kanban permite flujo constante sin overhead Sprints.

Ventajas Kanban

• Flexibilidad máxima: Cambios continuos, adaptación inmediata.
• Simplicidad: Fácil implementar, pocas reglas.
• Transparencia visual: Tablero muestra estado real instantáneamente.
• Mejora flujo: Identificar cuellos botella, optimizar procesos.

Desafíos Kanban

• Falta estructura formal: Puede derivar en caos si equipo no disciplinado.
• Difícil planificación largo plazo: Sin sprints/releases fijos, complicado comprometer fechas.
• Requiere madurez equipo: Auto-organización, disciplina límites WIP.

4. Gestión de las Áreas Clave del Proyecto

Esta sección profundiza en las 10 áreas de conocimiento PMBOK®, con aplicación práctica a proyectos TIC del SAS.

4.1. Gestión del Alcance del Proyecto

Definición: Incluye procesos para asegurar que proyecto incluya TODO el trabajo requerido, y SOLO ese trabajo, para completarlo exitosamente.

Procesos clave:

1. Recopilar Requisitos

• Técnicas: Entrevistas stakeholders, workshops, focus groups, encuestas, análisis documentos, prototipado.
• Ejemplo SAS: Nuevo módulo telemedicina Diraya → entrevistas médicos especialidades (dermatología, psiquiatría…), workshops enfermeras, encuestas pacientes crónicos, análisis guías clínicas.
• Salida: Documento Requisitos (funcionales, no funcionales, técnicos, regulatorios…).

2. Definir Alcance

• Describir detalladamente producto/servicio que se entregará.
• Declaración Alcance: Incluye descripción producto, entregables principales, criterios aceptación, exclusiones explícitas (qué NO se hará).
• Ejemplo SAS: Alcance migración Diraya cloud:
  • Incluye: Migrar módulos clínicos core (HC, prescripción, PACS viewer), infraestructura Azure, formación profesionales, 6 meses soporte post-migración.
  • Excluye: Migrar módulos legacy descontinuados, rediseño UX completo (se hará en fase posterior), integración con sistemas externos NO prioritarios.

3. Crear WBS (Work Breakdown Structure – Estructura Descomposición Trabajo)

• Descomponer jerárquicamente alcance en paquetes trabajo manejables.
• Estructura típica WBS proyecto TIC SAS:

Proyecto Migración Diraya Cloud
├── 1. Gestión Proyecto
│   ├── 1.1. Planificación
│   ├── 1.2. Seguimiento y Control
│   └── 1.3. Cierre
├── 2. Análisis y Diseño
│   ├── 2.1. Análisis Infraestructura Actual
│   ├── 2.2. Diseño Arquitectura Cloud
│   └── 2.3. Plan Migración Datos
├── 3. Preparación Entorno Cloud
│   ├── 3.1. Aprovisionamiento Azure
│   ├── 3.2. Configuración Red (VPN, Firewall)
│   └── 3.3. Configuración Seguridad (ENS)
├── 4. Migración Datos y Aplicaciones
│   ├── 4.1. Migración Bases Datos
│   ├── 4.2. Migración Módulos Diraya
│   └── 4.3. Integración APIs
├── 5. Testing y QA
│   ├── 5.1. Testing Funcional
│   ├── 5.2. Testing Rendimiento
│   └── 5.3. Testing Seguridad (Pentesting)
├── 6. Formación y Gestión Cambio
│   ├── 6.1. Formación Profesionales
│   └── 6.2. Comunicación Usuarios
└── 7. Go-Live y Soporte
    ├── 7.1. Despliegue Producción
    └── 7.2. Soporte Post-Migración (6 meses)

4. Validar Alcance

• Obtener aceptación formal entregables por stakeholders.
• Ejemplo SAS: Sprint Review (Scrum) donde médicos validan nueva funcionalidad Diraya, firman acta aceptación.

5. Controlar Alcance

• Monitorizar estado alcance, gestionar cambios.
• Change Control: Proceso formal para solicitar/evaluar/aprobar cambios alcance.
• Ejemplo SAS: Médicos solicitan añadir función «firma electrónica múltiple» NO prevista originalmente → Change Request → Comité Control Cambios evalúa impacto (coste, plazo, riesgos) → aprueba/rechaza/difiere.

Riesgos gestión alcance SAS:

• Scope creep: Crecimiento descontrolado alcance (stakeholders piden «solo una cosita más» continuamente) → retrasos, sobrecostes. Mitigación: Change control riguroso, Product Owner disciplinado (priorizar, decir NO).
• Gold plating: Equipo añade funcionalidades NO solicitadas («porque mola») → desperdicio recursos. Mitigación: Enfoque valor cliente, Definition of Done estricta.

4.2. Gestión del Cronograma (Tiempo)

Objetivo: Asegurar que proyecto se completa en plazo previsto.

Procesos clave:

1. Definir Actividades

• Descomponer paquetes trabajo WBS en actividades específicas.
• Ejemplo: Paquete «2.2. Diseño Arquitectura Cloud» → Actividades: Seleccionar servicios Azure, diseñar topología red, definir estrategia backup, documentar arquitectura…

2. Secuenciar Actividades

• Identificar dependencias entre actividades.
• Tipos dependencias:
  • Fin-Inicio (FS): B NO puede empezar hasta que A termine (más común).
  • Inicio-Inicio (SS): B NO puede empezar hasta que A empiece.
  • Fin-Fin (FF): B NO puede terminar hasta que A termine.
• Ejemplo SAS: «Testing Seguridad» (pentesting) NO puede empezar hasta que «Migración Módulos Diraya» termine (dependencia FS).

3. Estimar Duración Actividades

• Técnicas:
  • Juicio experto: Consultar personas experimentadas.
  • Estimación análoga: Basada en proyectos similares pasados.
  • Estimación paramétrica: Usar datos históricos + parámetros (ej: desarrollar módulo = 10 días/KLOC).
  • Estimación tres puntos (PERT): Optimista, Pesimista, Más Probable → Duración Esperada = (O + 4M + P) / 6.
• Ejemplo SAS: Estimar «Migración Base Datos Diraya (500 GB)»:
  • Optimista: 3 días (todo perfecto).
  • Más Probable: 7 días (asumiendo incidencias menores).
  • Pesimista: 15 días (problemas graves compatibilidad).
  • Duración Esperada PERT = (3 + 4×7 + 15) / 6 = 7,67 días ≈ 8 días.

4. Desarrollar Cronograma

• Crear cronograma proyecto integrando actividades, secuencias, duraciones, recursos, restricciones.
• Herramientas: MS Project, Primavera, GanttProject, JIRA (para Agile).
• Técnicas:
  • Método Ruta Crítica (CPM): Identificar secuencia actividades con duración total más larga (ruta crítica) → cualquier retraso en ruta crítica retrasa proyecto completo.
  • Fast Tracking: Superponer actividades normalmente secuenciales → reduce plazo pero aumenta riesgo.
  • Crashing: Añadir recursos (personas, HW…) a actividades ruta crítica → reduce plazo pero aumenta coste.

5. Controlar Cronograma

• Monitorizar avance, identificar desviaciones, tomar acciones correctivas.
• Métricas:
  • Variación Cronograma (SV): SV = EV – PV (Earned Value – Planned Value). Positivo → adelantado, Negativo → retrasado.
  • Índice Desempeño Cronograma (SPI): SPI = EV / PV. >1 → adelantado, <1 → retrasado.
• Ejemplo SAS: Proyecto debería llevar 50% completado (PV=50%), pero lleva 40% real (EV=40%) → SV=-10%, SPI=0,8 → retrasado 20%, acciones correctivas necesarias (fast tracking, crashing, negociar plazo…).

4.3. Gestión de Costes

Objetivo: Completar proyecto dentro presupuesto aprobado.

Procesos clave:

1. Estimar Costes

• Desarrollar estimación costes recursos necesarios.
• Categorías costes proyecto TIC SAS:
  • Personal: Salarios equipo interno + honorarios consultores externos.
  • Hardware: Servidores, almacenamiento, red, equipos usuario.
  • Software: Licencias, suscripciones cloud, herramientas desarrollo.
  • Servicios: Consultoría, formación, soporte, auditorías.
  • Otros: Viajes, espacio oficina, materiales…
• Técnicas estimación: Análogas, paramétricas, bottom-up (sumar coste cada actividad WBS).
• Ejemplo SAS: Estimar coste proyecto migración Diraya cloud:
  • Personal: 10 FTE × 12 meses × 60k€/año = 600k€
  • Infraestructura Azure: 50k€/mes × 12 meses = 600k€
  • Consultoría especializada: 300k€
  • Formación: 100k€
  • Contingencia (10%): 160k€
  • Total: 1.760k€ ≈ 1,8M€

2. Determinar Presupuesto

• Agregar costes estimados actividades para establecer línea base coste.
• Reservas:
  • Reservas contingencia: Para riesgos identificados (5-15% típico).
  • Reservas gestión: Para riesgos desconocidos («unknown unknowns»), controladas por Dirección (5-10%).

3. Controlar Costes

• Monitorizar ejecución presupuestaria, identificar desviaciones.
• Gestión Valor Ganado (EVM – Earned Value Management):
  • PV (Planned Value): Valor trabajo planificado hasta fecha.
  • EV (Earned Value): Valor trabajo realmente completado.
  • AC (Actual Cost): Coste real incurrido.
  • CV (Cost Variance): CV = EV – AC. Positivo → bajo presupuesto, Negativo → sobre presupuesto.
  • CPI (Cost Performance Index): CPI = EV / AC. >1 → eficiente, <1 → sobrecostes.
• Ejemplo SAS: Proyecto debería costar 500k€ a fecha (PV=500k), ha completado trabajo valorado 450k€ (EV=450k), coste real 520k€ (AC=520k) → CV=-70k€, CPI=0,87 → sobrecostes 13%, acciones correctivas.

4.4. Gestión de la Calidad

Objetivo: Asegurar que proyecto y productos cumplen requisitos calidad.

Procesos clave:

1. Planificar Gestión Calidad

• Definir estándares calidad relevantes, cómo cumplirlos.
• Estándares aplicables SAS: ISO 9001 (calidad gestión), ISO/IEC 25010 (calidad software), ENS (seguridad), normativa sanitaria (protocolos clínicos).
• Métricas calidad: Tasa defectos, cobertura testing, disponibilidad sistema (uptime), satisfacción usuario…

2. Gestionar Calidad (Aseguramiento)

• Auditar requisitos calidad, resultados mediciones, asegurar que se usan estándares apropiados.
• Técnicas: Auditorías calidad, revisiones diseño, revisiones código (code reviews), análisis causa raíz defectos.
• Ejemplo SAS: Auditoría ENS proyecto migración Diraya cloud → verificar cumplimiento controles seguridad (cifrado datos tránsito/reposo, autenticación multifactor, logs auditoría…).

3. Controlar Calidad

• Monitorizar resultados actividades control calidad, verificar conformidad.
• Niveles testing proyecto TIC SAS:
  • Testing Unitario: Probar componentes individuales (funciones, clases). Automatizado (JUnit, pytest…).
  • Testing Integración: Probar interfaces entre componentes (APIs, bases datos…).
  • Testing Sistema: Probar sistema completo end-to-end.
  • Testing Aceptación Usuario (UAT): Usuarios finales (médicos, enfermeras) prueban sistema en condiciones reales, validan cumple necesidades.
  • Testing Seguridad: Pentesting, análisis vulnerabilidades (OWASP Top 10), auditoría ENS.
  • Testing Rendimiento: Carga, estrés (sistema soporta 10.000 usuarios concurrentes?), escalabilidad.
• Ejemplo SAS Diraya: UAT crítico → 100 médicos/enfermeras hospitales piloto prueban nueva versión Diraya durante 2 semanas, reportan bugs/incidencias, validan usabilidad → si aprobación ≥80%, go-live general.

4.5. Gestión de Recursos

Objetivo: Identificar, adquirir y gestionar recursos (humanos, materiales, equipamiento) necesarios.

Recursos proyectos TIC SAS:

• Humanos: Project Manager, analistas, desarrolladores, DBAs, arquitectos, especialistas seguridad, testers, formadores, usuarios clave (médicos, enfermeras representantes).
• Materiales: Hardware (servidores, PCs, tablets médicos…), software (licencias, herramientas), infraestructura cloud.

Procesos clave:

1. Estimar Recursos Actividades

• Determinar qué recursos (tipo, cantidad) se necesitan para cada actividad.
• Ejemplo: Actividad «Desarrollo Módulo Telemedicina» → necesita 2 desarrolladores Java backend, 1 desarrollador frontend React, 1 DBA, 1 especialista FHIR, durante 8 semanas.

2. Adquirir Recursos

• Obtener recursos: asignar personal interno, contratar externos, comprar/alquilar equipamiento.
• Desafío SAS: Personal TIC limitado, alta carga operativa → necesidad contratar consultoras externas (Everis, Indra, Atos…) vía licitación (proceso largo, visto Tema 32).

3. Desarrollar Equipo

• Mejorar competencias, interacción, ambiente equipo → incrementar rendimiento.
• Técnicas: Formación técnica, team building, colocación (ubicar equipo físicamente junto), herramientas colaboración (Teams, Confluence, JIRA…).

4. Dirigir Equipo

• Seguir desempeño miembros equipo, resolver conflictos, gestionar cambios equipo.
• Desafío proyectos híbridos SAS: Equipo mezcla personal interno SAS + consultores externos → diferencias culturales, contractuales (consultores facturan horas, personal interno NO) → necesario liderazgo integrador.

4.6. Gestión de Comunicaciones

Objetivo: Asegurar que información proyecto se genera, recopila, distribuye, almacena y dispone de forma oportuna y apropiada.

Procesos clave:

1. Planificar Gestión Comunicaciones

• Determinar necesidades información stakeholders, definir cómo comunicar.
• Matriz Comunicaciones típica proyecto SAS:

2. Gestionar y Controlar Comunicaciones

• Ejecutar plan comunicaciones, monitorizar efectividad.
• Herramientas: Email, MS Teams, SharePoint, Confluence, JIRA, paneles control (dashboards Power BI).

4.7. Gestión de Riesgos

Objetivo: Identificar, analizar y responder a riesgos proyecto (maximizar oportunidades, minimizar amenazas).

Procesos clave:

1. Identificar Riesgos

• Técnicas: Brainstorming, Delphi, entrevistas expertos, análisis DAFO, checklist riesgos proyectos similares.
• Ejemplos riesgos típicos proyectos TIC SAS:
  • Técnicos: Incompatibilidad tecnologías, bugs críticos, rendimiento insuficiente, fallo migración datos.
  • Organizacionales: Resistencia cambio usuarios, rotación personal clave, conflictos entre equipos.
  • Externos: Retraso proveedor, cambios regulatorios (nueva ley protección datos), ciberataque.
  • Gestión: Estimaciones erróneas, scope creep, falta apoyo Dirección, mala comunicación.

2. Analizar Riesgos (Cualitativo y Cuantitativo)

• Análisis Cualitativo: Priorizar riesgos según Probabilidad × Impacto.

3. Planificar Respuesta Riesgos

• Estrategias Amenazas:
  • Evitar: Eliminar causa raíz (ej: evitar tecnología inmadura, elegir alternativa probada).
  • Transferir: Pasar responsabilidad a tercero (ej: seguro, cláusula contractual penalización proveedor).
  • Mitigar: Reducir probabilidad/impacto (ej: backups redundantes, testing exhaustivo, formación usuarios).
  • Aceptar: NO hacer nada proactivamente, gestionar si ocurre (reserva contingencia).
• Ejemplo SAS: Riesgo «Fallo migración datos HC»:
  • Mitigación: Plan migración incremental (por fases, NO Big Bang), pruebas migraciones piloto, backup completo pre-migración, equipo rollback preparado, validación integridad datos automatizada.
  • Plan contingencia: Si fallo crítico migración → rollback a sistema anterior, posponer go-live.

4. Monitorizar Riesgos

• Seguir riesgos identificados, identificar nuevos, ejecutar planes respuesta, evaluar efectividad.
• Registro Riesgos (Risk Log): Documento vivo actualizado continuamente.

4.8. Gestión de Adquisiciones

Objetivo: Comprar/adquirir productos/servicios externos necesarios.

En sector público (SAS): Regido por LCSP (Ley Contratos Sector Público, vista Tema 32).

Procesos clave:

• Planificar Adquisiciones: Decidir QUÉ, CUÁNDO y CÓMO adquirir.
• Efectuar Adquisiciones: Licitación, evaluación ofertas, adjudicación, firma contrato (procedimiento administrativo riguroso).
• Controlar Adquisiciones: Gestionar relación proveedor, verificar entregables, gestionar pagos, cambios contractuales.

Desafío SAS: Plazos contratación largos (6-12 meses) vs necesidad agilidad proyectos TIC → tensión. Solución: Acuerdos marco SGAD (proveedores pre-homologados, adjudicación rápida).

4.9. Gestión de Interesados (Stakeholders)

Objetivo: Identificar personas/organizaciones impactadas por proyecto, analizar expectativas/influencia, gestionar compromiso para maximizar apoyo, minimizar resistencia.

Procesos clave:

1. Identificar Stakeholders

• Stakeholders típicos proyecto TIC SAS: Dirección SAS, directores hospitales, profesionales sanitarios (médicos, enfermeras), pacientes, sindicatos, TIC, proveedores, SGAD, DPO, CISO, Intervención…

2. Analizar Stakeholders

• Matriz Poder-Interés:

3. Gestionar Compromiso Stakeholders

• Comunicar, involucrar, gestionar expectativas, resolver conflictos.
• Ejemplo SAS: Médicos inicialmente resistentes nuevo sistema Diraya → estrategia: involucrar médicos líderes opinión (early adopters) en diseño, pilotos, embajadores digitales que evangelizan compañeros, formación intensiva, soporte on-site post-go-live.

5. Modelo Corporativo Marco de Implantaciones (MCMI) del Servicio Andaluz de Salud

5.1. Origen y Contexto del MCMI

Génesis

El Modelo Corporativo Marco de Implantaciones (MCMI) tiene su origen en el Modelo de Implantación específico de Diraya Atención Hospitalaria. Tras múltiples implantaciones de Diraya en hospitales andaluces, el SAS acumuló know-how y lecciones aprendidas valiosas que decidió formalizar en un marco metodológico corporativo aplicable a CUALQUIER sistema información, no solo Diraya.

Definición MCMI (oficial SAS)

«Modelo Marco para la estructuración de cualquier proceso de implantación en el ámbito del SAS, independientemente del producto implantado. Es una completa guía donde se detallan las líneas maestras de todas las actividades involucradas en un proceso de implantación en cualquier centro del SAS.»

Objetivos MCMI

• Normalizar: Establecer proceso estándar, NO inventar cada vez.
• Documentar: Catálogo entregables corporativo con plantillas reutilizables.
• Formar: Manual instrucciones para cualquier perfil involucrado (saber qué hacer, cuándo, cómo).
• Mejorar continuamente: Cada implantación alimenta modelo con experiencias, lecciones aprendidas.
• Reducir riesgos: Proceso probado reduce incertidumbre, errores, fracasos.

Alcance MCMI

MCMI NO normaliza definición alcance proyecto (eso es prerrequisito, decisión ya tomada). Normaliza CÓMO EJECUTAR implantación una vez alcance decidido.

Ámbito aplicación

• Sistemas hospitales: Diraya, PACS, RIS, LIS, farmacia, quirófano…
• Sistemas atención primaria: Diraya AP, agenda electrónica…
• Sistemas corporativos: ClicSalud+, Portal Profesionales…
• Infraestructura: Renovación CPDs, redes, puestos trabajo…

5.2. Las 8 Fases del MCMI

MCMI divide ciclo vida implantación en 8 fases secuenciales, cada una con objetivos, actividades, roles y entregables específicos.

Duración total típica proyecto implantación MCMI: 12-18 meses (variable según complejidad centro, alcance sistema).

5.3. Detalle de las 8 Fases MCMI

Fase 1: Análisis Preliminar de Situación (APS)

Objetivo: Obtener información relevante situación partida centro → conocer grado adecuación para implantación, complejidad proceso.

Actividades clave:

• Recopilar datos centro: Cartera Servicios, actividad asistencial, dimensionamiento (camas, consultas, quirófanos…), demografía pacientes.
• Inventario Sistemas Información actuales: HIS (Hospital Information System) existente, sistemas departamentales (PACS, RIS, LIS, farmacia…), integraciones entre ellos, infraestructura TI (servidores, red, puestos trabajo…).
• Identificar particularidades centro: Procesos específicos, servicios singulares (ej: hospital referencia transplantes → complejidad extra).

Entregables principales:

• FUNC01: Dimensionamiento ámbito implantación.
• FUNC02: Impacto implantación.
• SIST01: Catálogo Sistemas Información.

Roles protagonistas: Jefe Equipo Implantación, Perfil Funcional, Responsable TIC Centro.

Fase 2: Reingeniería de Procesos

Objetivo: Analizar circunstancias particulares centro, detectar puntos mejora y críticos, modelar integración procesos actuales con nuevo sistema.

Actividades clave:

• Sesiones exposición módulos nuevos: Equipo implantación presenta funcionalidades nuevo sistema (ej: módulo Urgencias Diraya).
• Contraste procesos: Centro indica cómo contrastan procesos implementados nuevo sistema con procesos actuales centro.
• Modelado integración: Definir forma óptima unir ambos conjuntos (nuevo sistema + procesos actuales) → cobertura completa, transición natural.
• Definir alcance migraciones: QUÉ datos migrar desde sistema origen (históricos completos? solo activos? qué profundidad temporal?), reglas negocio migración.
• Definir alcance integraciones: QUÉ sistemas deben integrarse con nuevo sistema (PACS, laboratorio, farmacia, RIS…), interfaces necesarias.
• Identificar riesgos tempranos: Procesos críticos 24/7 (Urgencias, UCI…), particularidades difíciles mapear, resistencia cambio prevista…

Entregables principales:

• FUNC03.X: Actas sesiones Reingeniería.
• MIGR02: Definición Alcance Migraciones.
• INTE03: Definición Alcance Integraciones.
• GEST04: Registro Riesgos (actualizado).
• GEST05: Informe Final Reingeniería Procesos.

Roles protagonistas: Perfil Funcional Equipo Implantación, Referentes Funcionales Centro (médicos, enfermeras, administrativos expertos procesos), Jefe Proyecto STIC.

Fase 3: Preimplantación

Objetivo: Adecuar centro hasta línea base necesaria para comenzar implantación propiamente.

Actividades clave (las MÁS INTENSAS técnicamente):

Área Funcional:

• Parametrización módulos centralizados: MACO (gestión profesionales), ESTRUCTURA (organización física/funcional hospital), BDU (Base Datos Usuarios), AGD (Agenda Diraya), Citaweb…
• Mapeo tablas maestras: Códigos diagnósticos (CIE-10), procedimientos (CIE-9-MC), medicamentos (Botplus), alergias… → mapeo sistema origen ↔ nuevo sistema.
• Parametrización específica módulos nuevos: Configurar flujos trabajo, permisos, formularios, alertas…

Área Migraciones:

• Desarrollar procesos extracción/transformación datos (ETL): Scripts SQL extraer datos sistema origen, transformarlos (limpiar, mapear, validar), formato carga nuevo sistema.
• Pruebas migración incrementales: Migraciones piloto con subconjuntos datos (catas) → validar calidad, ajustar procesos ETL.
• Coordinación proveedor N3 sistema origen: Necesario colaboración estrecha (conocen estructura BBDD, particularidades datos…).

Área Integraciones:

• Desarrollar interfaces integración: Adaptadores HL7, servicios web, ESB corporativo (OTI)…
• Pruebas conectividad: Verificar canal comunicación funcional (red, firewall, VPN…).
• Adecuación sistemas departamentales: Proveedores sistemas terceros (PACS, laboratorio…) deben adaptar sus sistemas a contratos integración corporativos SAS.

Área Sistemas:

• Aprovisionamiento entornos: Entornos RP (Reingeniería Procesos), PRE (Preproducción), PRO (Producción) → servidores, BBDD, almacenamiento, red…
• Certificación infraestructura: Verificar requisitos mínimos HW/SW cumplidos (capacidad, rendimiento, seguridad ENS…).
• Apertura comunicaciones: Firewall rules, VPNs, accesos remotos…

Entregables principales:

• FUNC08/09: Estructura física/funcional.
• FUNC10: Catálogo operadores, profesionales, perfiles.
• FUNC11: Parametrización sistema.
• FUNC12: Mapeos tablas maestras.
• MIGR03: Procesos extracción/transformación datos.
• INTE06: Procesos integración.
• SIST08: Checklist certificación requisitos mínimos.
• SIST10/11: Entornos PRE/PRO.

Duración: Fase más larga técnicamente (2-4 meses típicamente). Muchas actividades paralelas (funcional + migraciones + integraciones + sistemas).

Fase 4: Implantación

Objetivo: Ejecutar actividades directamente relacionadas con implantación: formación usuarios, testing exhaustivo, preparación arranque.

Actividades clave:

Área Formación:

• Plan Formación: Identificar colectivos (médicos, enfermeras, administrativos, TIC…), diseñar itinerarios formativos según rol.
• Material formación: Manuales usuario, vídeos tutoriales, casos prácticos, FAQs.
• Acciones formativas: Sesiones presenciales (aulas), online (webinars), on-the-job (formación puesto trabajo). Típicamente: 2-4 sesiones × colectivo, 4-8 horas/sesión.
• Certificación usuarios: Evaluación conocimientos post-formación, identificar usuarios necesitan refuerzo.

Área Funcional:

• Testing Funcional Circuitos: Probar end-to-end circuitos asistenciales completos (ej: paciente llega Urgencias → triaje → consulta médico → petición analítica → laboratorio → resultado → alta) en entorno PRE.
• Pruebas Aceptación Sistema (PAS): Usuarios clave (referentes) validan sistema cumple requisitos, usabilidad aceptable.

Área Migraciones:

• Pruebas migración cualitativas/cuantitativas: Validar datos migrados correctos (integridad referencial, rangos valores lógicos, completitud…), volumetría esperada.

Área Integraciones:

• Pruebas funcionales integraciones: Simular flujos reales (ej: petición analítica Diraya → mensaje HL7 → sistema laboratorio → resultado → mensaje HL7 → Diraya resultado visible).

Área Gestión:

• Elaborar Plan Arranque: Documento maestro: cronograma actividades arranque (al minuto), roles responsables, plan comunicación, plan transición (papel), checklist pre/post-arranque, plan rollback (si falla).
• Elaborar Plan Soporte Post-Arranque: Modelo soporte N0 (equipos mixtos: tutor equipo implantación + referente centro), ubicaciones soporte presencial, horarios, escalado incidencias…

Entregables principales:

• FORM03: Plan Formación.
• FORM04.X: Material Formación.
• FUNC05: Plan Pruebas Aceptación Sistema.
• FUNC07: Plan Pruebas Funcionales Circuitos.
• MIGR04/05: Planes pruebas migración.
• INTE05: Plan Pruebas funcionales integraciones.
• GEST11: Plan Comunicación Arranque.
• GEST12: Plan Transición Arranque.
• GEST15: Plan Arranque.
• GEST17: Plan Soporte.

Fase 5: Arranque (Go-Live)

Objetivo: Transición sistema origen → nuevo sistema. FASE MÁS CRÍTICA (hospital NO puede parar asistencia, disponibilidad 24/7 obligatoria).

Subfases Arranque (4):

5.1. Pre-Arranque

• Cuándo: Horas antes parada sistema origen (típicamente viernes noche, para tener fin semana transición).
• Actividades: Verificaciones finales sistema origen (backup completo, snapshot BBDD, checklist estado), comunicaciones usuarios (avisos go-live, instrucciones plan transición papel), preparativos equipo (guerra de salas, coordinación roles).

5.2. Transición

• Cuándo: Sistema origen parado, nuevo sistema aún NO disponible usuarios.
• Duración crítica: Minimizar (típico: 24-48h), hospital trabaja con papel (plan transición).
• Actividades:
  • Apagado sistema origen (momento T0).
  • Migración final datos: ETL producción (históricos + activos), validación volumetría/calidad.
  • Activación integraciones producción: ESB, interfaces HL7, servicios web…
  • Configuraciones sistemas terceros: Apuntar a nuevo sistema (URLs, IPs…).

5.3. Post-Transición

• Cuándo: Nuevo sistema levantado, ANTES apertura usuarios.
• Actividades:
  • Pruebas Aceptación Arranque: Validación referentes centro + equipo implantación: censos pacientes correctos? integraciones funcionan? datos críticos migrados OK? rendimiento aceptable?
  • Certificación arranque: Firma responsables centro → aprobación go-live usuarios.

5.4. Post-Arranque

• Cuándo: Sistema ya abierto usuarios (momento T+arranque).
• Actividades: Cargas datos caliente (NO críticos arranque), parametrizaciones complementarias (cuadros mando, explotación datos…), integraciones diferidas (proveedores NO disponibles noche/fin semana).

Características Arranque MCMI:

• Cronograma al minuto: Planificación precisa (ej: «03:15 – Iniciar migración tabla PACIENTES – DBA Juan García»).
• Plan Comunicación continua: Avisos proactivos tiempo real (email, SMS) a stakeholders clave sobre hitos (ej: «Migración datos completada OK», «Integraciones activas», «Sistema abierto usuarios»).
• Plan Transición (papel): Plantillas papel pre-diseñadas para registro actividad asistencial durante indisponibilidad sistema → posterior mecanización datos en nuevo sistema.
• Plan Rollback: Si fallo crítico insalvable → procedimiento vuelta atrás sistema origen (restaurar backup, reactivar integraciones antiguas…). Decisión Comité Dirección Proyecto.

Fase 6: Consolidación

Objetivo: Estabilizar uso nuevo sistema lo más rápido posible, soporte intensivo.

Duración: 4-6 semanas post-arranque.

Actividades clave:

• Soporte N0 24×7: Equipos mixtos (tutor N0 equipo implantación + referente N0 centro) en ubicaciones estratégicas hospital (Urgencias, UCI, Consultas, Admisión…). Presencial primeros días, luego telefónico/remoto.
• Resolución incidencias prioritaria: Soporte N3 proveedores dedicado proyecto (respuesta rápida bugs, configuraciones urgentes…).
• Monitorización indicadores: Tiempos respuesta sistema, errores integraciones, volumetría registros, satisfacción usuarios (encuestas rápidas).
• Validación censos/integraciones: Verificación continua datos correctos (NO descuadres censales, mensajes HL7 NO perdidos…).
• Ajustes parametrización: Refinamiento configuración según feedback usuarios real.

Modelo Soporte N0 (detalle MCMI):

• Usuario con duda/incidencia → consulta referente N0 centro (compañero formado).
• Referente N0 NO resuelve → escala tutor N0 equipo implantación (presente o contactable).
• Tutor N0 resuelve CON referente N0 presente → transferencia conocimiento continua (referente aprende resolución, próxima vez podrá resolver solo).
• Tutor N0 NO resuelve → escala CSU (Centro Soporte Usuarios SAS) → N3 proveedor.

Objetivo: Al final Consolidación, referentes N0 centro capaces resolver >80% consultas sin tutor equipo implantación.

Fase 7: Extensión

Objetivo: Ampliar alcance implantación (funcionalidades diferidas Fase 4), finalizar integraciones pendientes, consolidar transferencia conocimiento.

Duración: 8-12 semanas.

Actividades clave:

• Continuación soporte: Soporte N0 pasa a horario normal (NO 24×7), presencia reducida.
• Ampliación alcance: Módulos/funcionalidades pospuestos arranque (ej: telemonitorización pacientes crónicos, cuadros mando directivos, apps móviles complementarias…).
• Integraciones diferidas: Sistemas departamentales cuya integración NO era crítica arranque → implementación ahora.
• Sesiones afianzamiento conocimiento: Formación avanzada, resolución dudas recurrentes, casos uso complejos.
• Delegación liderazgo soporte a TIC centro: Servicio TIC centro asume responsabilidad soporte day-to-day, tutelado aún por equipo implantación (shadow support).

Preparación salida equipo implantación: Centro debe estar autónomo para cuando equipo implantación se retire.

Fase 8: Paso a N3

Objetivo: Transferir formalmente soporte proyecto a proveedores N3, cierre administrativo proyecto.

Duración: 2-4 semanas.

Actividades clave:

• Entrega documentación: Equipo implantación entrega a N3: informes finales, configuraciones aplicadas, modificaciones realizadas, problemas conocidos, FAQs, lecciones aprendidas…
• Recepción y análisis N3: Proveedores N3 revisan documentación, verifican completitud, solicitan aclaraciones.
• Comité Paso a N3: Reunión formal: Jefe Proyecto STIC, Jefe Equipo Implantación, Responsables N3, Responsable TIC Centro → revisión estado final proyecto, aprobación paso a N3 (o subsanación deficiencias detectadas).
• Cierre administrativo: Firma actas, liquidación contratos, archivo documental proyecto, celebración éxito equipo 🎉.

Post-cierre: Soporte continúa, pero ya NO es responsabilidad equipo implantación, sino N3 + TIC centro (BAU – Business As Usual).

5.4. Las 7 Áreas de Conocimiento MCMI

MCMI organiza actividades horizontalmente en 7 áreas conocimiento especializadas:

Códigos color iconos MCMI: Documentación MCMI usa códigos color/iconos para identificar área conocimiento cada actividad/entregable → facilita navegación, especialización RRHH.

5.5. Roles MCMI y Matriz RASCI

MCMI define roles específicos agrupados por organización:

Equipo Implantación (empresa/organización responsable ejecución):

• Jefe Equipo Implantación: Lidera equipo, coordina actividades, reporta avances, gestiona riesgos/cambios.
• Perfiles especializados: Funcional, Formación, Migración, Integración, Sistemas, (AYED).

Centro (hospital/centro salud donde se implanta):

• Responsable TIC Centro: Subdirector Provincial TIC o Jefe Servicio TI centro. Coordina recursos TI centro, facilita infraestructura, participa decisiones técnicas.
• Responsable Cartera y Servicios Centro: Gestiona elementos configuración centralizados (ESTRUCTURA, MACO…).
• Referentes Funcionales Centro: Profesionales sanitarios/administrativos expertos procesos negocio (médicos, enfermeras, supervisores…). Participan reingeniería, testing, formación compañeros, soporte N0.

STIC (Subdirección TIC SAS):

• Jefe Proyecto STIC: Project Manager corporativo, vela cumplimiento alcance/tiempo/coste, calidad resultado, governance proyecto.
• Área Sistemas STIC: Gestión infraestructura corporativa (CPDs, cloud, red troncal…). Servicio prestado por CTI (Centro Informático Científico Andalucía).
• OTI (Oficina Técnica Interoperabilidad): Vela cumplimiento normativa integración/interoperabilidad, gestiona ESB corporativo.
• Jefes Proyecto Módulos Centralizados: Responsables MACO, ESTRUCTURA, BDU… (trasversales múltiples proyectos).
• Responsables Funcionales STIC: Expertos procesos negocio ámbitos asistencial, profesionales, económico-financiero… Apoyo definición requisitos, validación soluciones.
• CSU (Centro Soporte Usuario): Service Desk SAS, niveles N1/N2.

Proveedores Soporte N3:

• N3 Producto Implantar: Proveedor nuevo sistema (ej: Everis para Diraya).
• N3 Producto Sustituir: Proveedor sistema origen legacy.
• N3 Sistemas Terceros Afectados: Proveedores sistemas departamentales integrados (PACS, laboratorio…).

Matriz RASCI: Para cada actividad MCMI, se define responsabilidad cada rol según:

• R (Responsible): Quien ejecuta tarea realmente.
• A (Accountable): Quien rinde cuentas (solo 1 por tarea). Aprueba resultado, responde ante dirección.
• S (Support): Quien apoya ejecución (ayuda activa a R).
• C (Consulted): Consultado (bidireccional: se le pide info/opinión, responde).
• I (Informed): Informado (unidireccional: se le notifica avances/resultados).

Ejemplo matriz RASCI actividad «Migración final datos producción» (Fase Arranque):

• R: Perfil Migración Equipo Implantación.
• A: Jefe Equipo Implantación.
• S: DBA Área Sistemas STIC, Soporte N3 Sistema Origen.
• C: Responsable TIC Centro, Perfil Funcional Equipo.
• I: Jefe Proyecto STIC, Referentes Funcionales Centro.

5.6. Catálogo de Entregables MCMI

MCMI define conjunto cerrado documentos (plantillas corporativas estandarizadas) generados durante proyecto, categorizados por área conocimiento.

Ejemplos entregables clave (selección):

• FUNC01: Dimensionamiento ámbito implantación.
• FUNC05: Plan Pruebas Aceptación Sistema.
• FUNC11: Parametrización sistema.
• FORM03: Plan Formación.
• MIGR02: Definición Alcance Migraciones.
• MIGR04/05: Planes pruebas migración (cualitativas/cuantitativas).
• INTE03: Definición Alcance Integraciones.
• SIST01: Catálogo Sistemas Información.
• SIST08: Checklist certificación requisitos mínimos.
• GEST04: Registro Riesgos.
• GEST05: Informe Final Reingeniería Procesos.
• GEST15: Plan Arranque.
• GEST17: Plan Soporte.
• GEST23: Informe Lecciones Aprendidas.

Beneficios catálogo entregables:

• Estandarización: Formato homogéneo proyectos.
• Reutilización: Plantillas aceleran documentación.
• Trazabilidad: Documentación completa auditable.
• Knowledge Management: Conocimiento corporativo preservado, NO dependiente personas concretas.

6. Cuestionario de Autoevaluación – 25 Preguntas Tipo Test

7. Mapa Conceptual y Referencias

        GESTIÓN PROYECTOS TIC
                |
        ┌───────┴───────┐
        |               |
    ESTÁNDARES      METODOLOGÍAS
    INTERNAC.          |
        |          ┌───┴───┐
    ┌───┴───┐      |       |
    |       |   TRADICIONAL ÁGIL
PMBOK®  PRINCE2  (Waterfall) (Scrum,
ISO21500  PM²              Kanban)
COBIT            |           |
    |            |           |
10 Áreas      Secuencial  Iterativo
Conocim.      Predictivo  Adaptativo
    |
┌───┴───────────────────────┐
|                           |
MCMI SAS               10 ÁREAS PMBOK
(Modelo                     |
Corporativo)        ┌───────┴───────┐
    |               |               |
8 FASES:        Alcance         Integración
1.APS           Cronograma      Calidad
2.Reingeniería  Costes          Recursos
3.Preimplant.   Comunicación    Riesgos
4.Implantación  Adquisiciones   Stakeholders
5.Arranque
6.Consolidación
7.Extensión
8.Paso N3
    |
7 ÁREAS:
-Funcional
-Formación
-Migraciones
-Integraciones
-Sistemas
-AYED (Explot.Datos)
-Gestión
    

8. Referencias Normativas y Bibliográficas