1. INTRODUCCIÓN: PROYECTOS TIC EN EL SECTOR PÚBLICO SANITARIO

1.1. Concepto de proyecto y diferencia frente a operación

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. Singularidades de los proyectos 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. Proyectos TIC en el sector público sanitario

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), gobernanza 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, penpruebas 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 del 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. Gobierno, valor y criterios de éxito

¿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 de 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, pruebas riguroso.
• Comunicación: Stakeholders informados, expectativas gestionadas, conflictos resueltos proactivamente.
• Aprendizaje: Lecciones aprendidas documentadas, mejora continua para futuros proyectos.

2. PMI Y PMBOK: ESTÁNDAR, PRINCIPIOS, DOMINIOS Y PROCESOS

2.1. PMI, The Standard for Project Management y PMBOK

El Project Management Institute publica estándares y guías que constituyen uno de los cuerpos de conocimiento más influyentes de la disciplina. A fecha de actualización de este tema, la referencia vigente es PMBOK Guide, octava edición, publicada en noviembre de 2025 junto con The Standard for Project Management como ANSI/PMI 99-001-2025. Esta edición mantiene el enfoque de entrega de valor y adaptación al contexto, articula seis principios básicos y siete dominios de desempeño —gobernanza, alcance, cronograma, finanzas, interesados, recursos y riesgo— y recupera orientación de procesos de forma no prescriptiva.

¿Qué es PMBOK®?

La PMBOK® Guide reúne y organiza conocimiento, modelos, métodos y prácticas de dirección de proyectos. La publica el Project Management Institute (PMI), asociación profesional fundada en 1969. No debe tratarse como una metodología cerrada: su aplicación exige seleccionar y adaptar las prácticas al contexto, la gobernanza, el riesgo y el ciclo de vida del proyecto.

Visión clásica de PMBOK: diez áreas de conocimiento

Cinco grupos de procesos de la visión clásica

1. Iniciación: Autorizar proyecto, definir objetivos preliminares (acta de constitución).
2. Planificación: Desarrollar plan detallado para ejecutar el proyecto (WBS, cronograma, presupuesto, plan riesgos…).
3. Ejecución: Coordinar personas y recursos para realizar el 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.

Evolución hacia principios, dominios y entrega de valor

La séptima edición desplazó el centro de gravedad desde la enumeración de procesos hacia principios y dominios de desempeño. La octava conserva la orientación a valor y adaptación, reorganiza el estándar en seis principios y siete dominios y reincorpora orientación de procesos sin convertirla en una secuencia obligatoria. Por tanto, el director del proyecto debe combinar el conocimiento clásico con el enfoque vigente y seleccionar un ciclo predictivo, adaptativo o híbrido según el contexto.

3. PRINCE2, ISO 21500/21502, PM² Y MARCOS COMPLEMENTARIOS

3.1. PRINCE2 7

Origen: Método de origen británico, evolucionado durante décadas. La versión vigente es PRINCE2 7, lanzada en 2023, que refuerza la dimensión humana, la sostenibilidad, la gestión de datos y la compatibilidad con enfoques predictivos, ágiles e híbridos.

Filosofía: Enfoque basado en principios, prácticas 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 rendición de cuentas.
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 del proyecto.

7 Prácticas PRINCE2

1. Business Case: Justificación económica/estratégica proyecto.
2. Organización: Estructura roles (Junta de Proyecto, director del proyecto, responsables de equipo…).
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. Incidencias: gestión de problemas, solicitudes de cambio y desviaciones respecto de la línea base.
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 Junta de Proyecto.
3. Initiating a Project (IP): Crear fundamentos sólidos proyecto.
4. Controlling a Stage (CS): Gestión día a día por director del proyecto.
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 el sector público

Su énfasis en la justificación continua, los roles de gobierno, la gestión por fases y las tolerancias resulta compatible con proyectos sometidos a control presupuestario, rendición de cuentas y puntos formales de decisión. No obstante, PRINCE2 debe adaptarse al tamaño y al riesgo del proyecto y coordinarse con la contratación pública, la arquitectura corporativa, la seguridad y los procedimientos internos del organismo.

3.2. Familia ISO 21500/21502

La familia ISO 21500/21502 separa actualmente los conceptos generales de la orientación práctica. ISO 21500:2021 establece el contexto organizativo y los conceptos subyacentes de la gestión de proyectos, programas y carteras. ISO 21502:2020 proporciona orientación de alto nivel sobre prácticas de dirección de proyectos aplicables a cualquier organización y a cualquier enfoque de entrega, incluidos los modelos predictivo, incremental, iterativo, adaptativo e híbrido.

Esta separación evita un error frecuente: afirmar que ISO 21500:2021 conserva sin más la estructura de procesos de la edición de 2012. Para estudiar la práctica de gestión de proyectos la referencia directa es ISO 21502; para el vocabulario y el encuadre conceptual, ISO 21500/21502. La serie se completa, entre otras, con ISO 21505 sobre gobernanza, ISO 21508 e ISO 21512 sobre valor ganado, e ISO 21511 sobre estructuras de desglose del trabajo.

3.3. PM² de la Comisión Europea

Origen y contexto

PM² es una metodología de dirección de proyectos desarrollada por la Comisión Europea y abierta posteriormente a otras organizaciones. La versión 3.1 de su guía de dirección de proyectos se publicó en 2023. Integra prácticas de estándares y metodologías reconocidos, pero las articula con una gobernanza, unos roles, unas fases y unos artefactos propios.

Finalidad de PM²

La Comisión Europea buscó un lenguaje común y un conjunto proporcionado de prácticas para proyectos desarrollados en un entorno institucional complejo, con múltiples organizaciones, requisitos de control, diversidad cultural y necesidad de trazabilidad. El método pretende facilitar la colaboración y la rendición de cuentas sin imponer una burocracia desproporcionada.

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 el trabajo, gestionar el equipo y producir los entregables; la monitorización y el control actúan de forma transversal durante todo el proyecto.
4. Closing: Entregar productos, evaluar proyecto, documentar lecciones, celebrar éxito.

Artefactos PM² (documentos clave):

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

Relevancia para las administraciones públicas

PM² es especialmente útil como referencia en proyectos europeos o interadministrativos porque aporta artefactos normalizados, una estructura de gobierno explícita y un vocabulario compartido. Su utilización no sustituye a los procedimientos corporativos del SAS ni permite inferir una relación histórica con el MCMI que no esté documentada; ambos marcos deben estudiarse por separado.

3.4. COBIT 2019 como marco de gobierno complementario

COBIT 2019 no es una metodología de dirección de proyectos. Es un marco de gobierno y gestión de la información y la tecnología empresarial. Su utilidad en este tema consiste en situar los proyectos dentro del sistema de gobierno: selección de inversiones, alineamiento con objetivos corporativos, control de beneficios, gestión de riesgos y transición de las soluciones a la operación.

¿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 y PM²: referencias para la dirección y gestión de proyectos temporales orientados a resultados únicos.
• COBIT: marco de gobierno y gestión de la información y la tecnología a escala organizativa.

¿Por qué incluir COBIT en tema gestión de 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).

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

• APO05: Gestionar portfolio proyectos/programas priorización, asignación recursos, gobernanza 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, pruebas.
• BAI04: Gestionar disponibilidad y capacidad dimensionado infraestructura, planificación capacidad.
• BAI07: Gestionar aceptación cambio e implantación go-live, gestión del cambio organizacional.
• BAI08: Gestionar conocimiento documentación, knowledge management, lecciones aprendidas.
• BAI09: Gestionar activos inventario HW/SW, gestión de la configuración.
• BAI10: Gestionar configuración control versiones, baseline management.

Aplicación COBIT en SAS:

• Nivel corporativo: el gobierno TIC del SAS puede utilizar objetivos y prácticas de COBIT para alinear inversiones, riesgos, recursos y resultados.
• Nivel de proyecto: los proyectos TIC deben coordinar sus prácticas de construcción e implantación con la gobernanza corporativa y, cuando proceda, con el 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 del cambio organizacional).
  • COBIT DSS01-06 (operaciones post-migración).

4. ENFOQUES PREDICTIVOS, ÁGILES E HÍBRIDOS

4.1. Enfoques predictivo, adaptativo e híbrido

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

4.2. Ciclo en 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 pruebas 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).

4.3. Agilidad: valores 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.

4.4. Scrum

¿Qué es Scrum?

Scrum es el marco ágil más popular (un marco ágil ampliamente utilizado). 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 de duración fija de un mes o menos, con equipo autogestionado, inspección y adaptación continuas.

Roles Scrum

• Product Owner (PO): representa las necesidades de producto y maximiza su valor, define/prioriza Product Backlog (lista requisitos), maximiza valor producto.
• Scrum Master (SM): Facilitador, coach, elimina impedimentos, asegura que equipo sigue Scrum correctamente.
• Developers (Equipo Desarrollo): Profesionales que hacen el trabajo (diseño, desarrollo, pruebas…). 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: evento de quince minutos para que los Developers inspeccionen el progreso hacia el Objetivo del Sprint y adapten el Sprint Backlog.
4. Sprint Review: inspección del resultado del Sprint con los interesados y adaptación del Product Backlog cuando proceda.
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, Developers = 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.

4.5. Kanban y gestión del flujo

¿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, Developers). 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.

5. GESTIÓN DEL ALCANCE Y DE LOS REQUISITOS

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 (Penpruebas)
├── 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.

5.3. Control integrado de cambios

La línea base del alcance no debe modificarse mediante acuerdos informales. Toda solicitud de cambio debe describir la necesidad, el valor esperado, el impacto sobre cronograma, coste, calidad, seguridad, contratación y operación, así como la alternativa de no realizarla. El órgano con autoridad aprueba, rechaza o aplaza el cambio y actualiza las líneas base y la trazabilidad.

6. GESTIÓN DEL CRONOGRAMA: GANTT, REDES, CPM Y PERT

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» (penpruebas) 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…).

6.4. Holguras y camino crítico

La holgura total indica cuánto puede retrasarse una actividad sin retrasar la fecha final del proyecto. La holgura libre mide el retraso posible sin afectar al comienzo temprano de una sucesora. La holgura independiente es más restrictiva: considera que las precedentes terminan lo más tarde posible y las posteriores empiezan lo antes posible.

7. GESTIÓN DE COSTES Y VALOR GANADO

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 de 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.

7.3. Lectura conjunta de indicadores EVM

En gestión del valor ganado se utilizan el valor planificado PV, el valor ganado EV y el coste real AC. La variación de coste es CV = EV - AC y la variación de cronograma es SV = EV - PV. Los índices son CPI = EV / AC y SPI = EV / PV; valores inferiores a uno indican, respectivamente, ineficiencia de coste o retraso respecto del plan.

CV = EV - AC
SV = EV - PV
CPI = EV / AC
SPI = EV / PV

8. 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 pruebas, 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 de 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 pruebas 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: Penpruebas, 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.

8.3. Calidad del producto TIC sanitario

La calidad debe traducirse en criterios verificables: adecuación funcional, disponibilidad, rendimiento, seguridad, privacidad, interoperabilidad, accesibilidad, usabilidad, mantenibilidad y recuperabilidad. Las pruebas de aceptación por usuarios no sustituyen a las pruebas técnicas, ni estas reemplazan la validación clínica y organizativa.

9. GESTIÓN DE RECURSOS Y EQUIPOS

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

Recursos proyectos TIC del SAS:

• Humanos: director del proyecto, 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 (proveedor adjudicatario, Indra, proveedor especializado…) 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.

9.3. Matrices de responsabilidad

Las matrices RACI y RASCI evitan ambigüedades. R ejecuta, A rinde cuentas y aprueba, C es consultado, I es informado y, en RASCI, S presta apoyo activo. Como regla de diseño debe existir un único Accountable por actividad.

10. GESTIÓN DE LAS COMUNICACIONES Y DE LA INFORMACIÓN

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).

10.3. Canales y sobrecarga comunicativa

Con n participantes, el número potencial de canales bilaterales es n(n-1)/2. El crecimiento cuadrático explica por qué añadir personas a una reunión o a un equipo no aumenta linealmente la capacidad: también incrementa coordinación, posibles malentendidos y tiempo de sincronización.

canales = n × (n - 1) / 2

El plan debe precisar destinatarios, contenido, periodicidad, responsable, formato, clasificación de la información y mecanismo de escalado.

11. GESTIÓN DE RIESGOS E INCIDENCIAS

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 del 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, pruebas 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.

11.4. Riesgo, incidencia y reserva

Un riesgo es un acontecimiento incierto; una incidencia es un hecho que ya se ha materializado. Las respuestas a amenazas incluyen evitar, mitigar, transferir y aceptar; para oportunidades se emplean explotar, mejorar, compartir y aceptar. La reserva de contingencia cubre riesgos identificados y forma parte de la línea base de costes; la reserva de gestión atiende trabajo no previsto dentro del alcance global y queda fuera de esa línea base.

12. GESTIÓN DE ADQUISICIONES Y CONTRATACIÓN PÚBLICA TIC

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).

12.2. Particularidades de la contratación pública

En el SAS, la adquisición debe coordinar la dirección de proyecto con el órgano de contratación, los responsables funcionales y técnicos, seguridad, protección de datos e intervención económica cuando proceda. El contrato fija obligaciones, entregables, niveles de servicio, penalidades, aceptación y régimen de cambios; no elimina la responsabilidad de la Administración sobre el gobierno, la supervisión y la validación del resultado.

El expediente debe anticipar dependencias entre licitación y cronograma. Un retraso en pliegos, adjudicación, formalización o disponibilidad presupuestaria puede convertirse en el camino crítico real, aunque el desarrollo técnico esté correctamente planificado.

13. GESTIÓN DE INTERESADOS Y DEL CAMBIO ORGANIZATIVO

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.

13.3. Participación y adopción

En sistemas clínicos, la aceptación no se obtiene únicamente mediante comunicación unidireccional. Requiere participación de referentes, validación de circuitos, pruebas de usabilidad, formación adaptada al puesto y soporte durante el arranque. La matriz poder-interés orienta el esfuerzo: alto poder y alto interés exige gestionar estrechamente; alto poder y bajo interés, mantener satisfecho; bajo poder y alto interés, mantener informado.

14. MCMI DEL SAS: OBJETO, ESTRUCTURA Y PRINCIPIOS

14.1. Objeto y alcance del modelo

El Modelo Corporativo Marco de Implantaciones es el marco del Servicio Andaluz de Salud para estructurar cualquier proceso de implantación con independencia del producto. Su origen está en el modelo específico utilizado en las implantaciones de Diraya Atención Hospitalaria y recoge conocimiento y lecciones aprendidas de esos despliegues.

El modelo parte de una delimitación muy relevante: no normaliza la decisión inicial sobre qué alcance debe tener una implantación, sino que toma el alcance acordado como prerrequisito y normaliza cómo ejecutar el proceso. Por tanto, complementa —pero no reemplaza— la gestión de cartera, el estudio de viabilidad, la contratación, el desarrollo del producto o el gobierno del servicio.

14.2. Componentes estructurales

El MCMI organiza la implantación en ocho fases. Cada fase se descompone en procesos y actividades y, para cada actividad, identifica su alcance, los documentos y entregables utilizados y los perfiles participantes. Horizontalmente, las actividades se clasifican en siete áreas de conocimiento, lo que facilita la especialización de los recursos y la trazabilidad.

• Fases: APS, Reingeniería de Procesos, Preimplantación, Implantación, Arranque, Consolidación, Extensión y Paso a N3.
• Áreas: FUNC, FORM, MIGR, INTE, SIST, AYED y GEST.
• Gobierno operativo: roles del equipo de implantación, del centro, de la STIC y de los proveedores de soporte N3.
• Documentación: catálogo corporativo de entregables y plantillas estandarizadas.

15. LAS OCHO FASES DEL MCMI

15.1. 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.

15.2. 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.

15.3. 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).

15.4. Fase 4: Implantación

Objetivo: Ejecutar actividades directamente relacionadas con implantación: formación usuarios, pruebas 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.

15.5. Fase 5: Arranque (Go-Live)

Objetivo: Transición sistema origen nuevo sistema. fase de especial criticidad (hospital NO puede parar asistencia, disponibilidad 24/7 obligatoria).

Subfases Arranque (4):

5.1. Pre-Arranque

• 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.
• 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.

15.6. Fase 6: Consolidación

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

Actividades clave:

• Soporte N0 según el modelo y periodo de consolidación: 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.

15.7. Fase 7: Extensión

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

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.

15.8. Fase 8: Paso a N3

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

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).

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

16. ÁREAS, ROLES, RASCI Y ENTREGABLES DEL MCMI

16.1. Siete áreas de conocimiento

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.

16.2. Roles 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, pruebas, formación compañeros, soporte N0.

STIC (Subdirección TIC SAS):

• Jefe Proyecto STIC: director del proyecto corporativo, vela cumplimiento alcance/tiempo/coste, calidad resultado, gobernanza 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: proveedor adjudicatario 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.

16.3. Catálogo corporativo de entregables

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 verificación de 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.

17. APLICACIÓN INTEGRADA, CRITERIOS DE ÉXITO Y MAPA CONCEPTUAL

17.1. Correspondencia entre la dirección de proyectos y el MCMI

El MCMI debe interpretarse como un marco de implantación especializado. La gestión del alcance, cronograma, costes, calidad, recursos, comunicaciones, riesgos, adquisiciones e interesados continúa siendo necesaria. El área GEST concentra muchas de esas actividades, pero su eficacia depende de la coordinación con las áreas funcional, formación, migración, integración, sistemas y análisis y explotación de datos.

17.2. Criterios de éxito en una implantación sanitaria

Una implantación no termina en el instante del go-live. El éxito exige que los circuitos sean operativos, los datos sean íntegros, las integraciones estén controladas, la infraestructura soporte la carga, los usuarios conozcan el sistema, el soporte pueda resolver incidencias y el centro alcance autonomía progresiva. Consolidación, Extensión y Paso a N3 existen precisamente para evitar un cierre prematuro.

17.3. Ideas clave para el repaso

• Proyecto es temporal y orientado a un resultado único; operación es continua y repetitiva.
• PMBOK es una guía y estándar; PRINCE2 y PM² ofrecen estructuras metodológicas; ISO 21502 proporciona orientación general.
• No existe un enfoque universal: el ciclo predictivo, adaptativo o híbrido se selecciona y adapta al contexto.
• La triple restricción se amplía con calidad, riesgos, recursos, interesados, beneficios, seguridad y valor.
• El MCMI normaliza la ejecución de una implantación con alcance previamente acordado.
• MCMI: ocho fases, siete áreas, actividades codificadas, RASCI y catálogo de entregables.