1. INTRODUCCIÓN Y ENCUADRE DE LA PLANIFICACIÓN INFORMÁTICA

La planificación informática determina cómo una organización utilizará la información, los sistemas y las tecnologías para cumplir su misión. En una organización sanitaria pública, esta decisión afecta a la continuidad asistencial, la seguridad de la información, la coordinación entre niveles, la experiencia de ciudadanía y profesionales, el uso de recursos y la capacidad de innovar. Por ello no puede reducirse a prever compras, renovar equipos o confeccionar un calendario de proyectos.

El punto de partida es el alineamiento: cada capacidad digital debe relacionarse con un objetivo institucional, un proceso y un resultado esperado. El punto de llegada no es una tecnología concreta, sino un estado futuro gobernable, sostenible y medible. Entre ambos extremos se sitúan el diagnóstico, la arquitectura objetivo, la cartera de iniciativas, la asignación de recursos, la gestión del cambio, el seguimiento y la revisión.

1.1. Relevancia para el TFA-STI

El personal TFA-STI participa en la traducción entre necesidades organizativas y decisiones tecnológicas. Puede analizar procesos y requisitos, valorar sistemas existentes, preparar alternativas, documentar arquitectura, coordinar proyectos, seguir contratos, definir indicadores, gestionar riesgos y facilitar la implantación. Su aportación no consiste únicamente en conocer herramientas: debe comprender el servicio público, distinguir hechos de preferencias y producir información útil para decidir.

Esta función exige trabajar con perfiles directivos, asistenciales, administrativos, jurídicos, económicos y técnicos. Una necesidad clínica puede implicar identidad, datos, integración, seguridad, continuidad, soporte, formación y contratación. El TFA-STI debe identificar esas dependencias y evitar que cada unidad resuelva localmente un problema que requiere una capacidad corporativa o un estándar común.

1.2. Enfoque de estudio para oposición

El tema combina tres bloques examinables. Primero, los niveles de planificación y su relación. Segundo, el Plan de Sistemas de Información como instrumento que conecta objetivos, requisitos, situación actual, modelos objetivo y proyectos. Tercero, el proceso PSI de Métrica versión 3, especialmente el orden y contenido de sus nueve actividades.

Conviene estudiar cada actividad mediante cuatro preguntas: qué problema resuelve, qué información recibe, qué producto genera y con qué actividad puede confundirse. Memorizar solo la numeración es insuficiente; los distractores suelen intercambiar requisitos, sistemas actuales, modelo objetivo, arquitectura y plan de acción.

2. CONCEPTO, FINALIDAD Y COMPONENTES DE LA PLANIFICACIÓN INFORMÁTICA

2.1. Concepto y alcance

Planificar es decidir anticipadamente, con información incompleta, una dirección y un conjunto coherente de acciones. En el ámbito informático incluye información, aplicaciones, datos, integraciones, infraestructura, seguridad, servicios, personas, proveedores, presupuesto y gobierno. Debe abarcar el ciclo de vida completo: ideación, adquisición o construcción, implantación, operación, evolución, conservación de información y retirada.

La planificación es sistemática porque utiliza criterios y evidencias; integrada porque relaciona negocio y tecnología; participativa porque necesita conocimiento distribuido; selectiva porque los recursos son limitados; y adaptativa porque el contexto cambia. Un plan que no prioriza, no asigna responsabilidad o no establece revisión es una declaración de intenciones.

2.2. Objetivos

• Alinear inversiones y capacidades digitales con objetivos de salud, asistencia, gestión y servicio público.
• Racionalizar el mapa de sistemas, reduciendo duplicidad, fragmentación, obsolescencia y soluciones sin gobierno.
• Gobernar la información, definiendo fuentes autorizadas, calidad, semántica, acceso, conservación y reutilización.
• Optimizar recursos considerando coste total, capacidad interna, contratos, operación, evolución y retirada.
• Gestionar riesgos de seguridad, privacidad, continuidad, dependencia, cumplimiento y cambio organizativo.
• Coordinar iniciativas mediante prioridades, dependencias, programas, proyectos y hoja de ruta.
• Medir valor con líneas base, metas, indicadores y propietarios de beneficios.

2.3. Principios

Los principios proporcionan criterios estables frente a decisiones cambiantes. Entre los más útiles están orientación a valor público, necesidad antes que solución, reutilización antes que duplicación, interoperabilidad, seguridad y privacidad desde el diseño, accesibilidad, modularidad, portabilidad, sostenibilidad, trazabilidad y responsabilidad clara. Un principio debe ser aplicable: ha de indicar cómo evaluar una propuesta y cómo gestionar una excepción.

2.4. Componentes de un sistema de planificación

2.5. Valor público frente a retorno económico

En el sector público no toda inversión se justifica por ingresos o ahorro directo. El valor puede consistir en seguridad del paciente, continuidad, accesibilidad, equidad, calidad, cumplimiento, reducción de carga administrativa, mejor decisión o sostenibilidad. Esto no elimina la disciplina económica: deben compararse alternativas, coste de oportunidad, coste total y capacidad de mantener la solución.

3. NIVELES DE PLANIFICACIÓN: ESTRATÉGICO, TÁCTICO Y OPERATIVO

Los niveles estratégico, táctico y operativo se distinguen por su horizonte, objeto, responsable y grado de detalle. No son compartimentos independientes: la estrategia orienta, la planificación táctica traduce y la operación ejecuta; a su vez, los resultados operativos proporcionan evidencia para revisar los niveles superiores.

3.1. Nivel estratégico

Define la dirección a medio y largo plazo: qué resultados se pretenden, qué papel tendrá la tecnología, qué capacidades son prioritarias y qué tolerancias de riesgo existen. Lo aprueban órganos directivos con responsabilidad sobre misión, recursos y rendición de cuentas. Sus productos incluyen estrategias digitales, principios, objetivos, modelos de gobierno y grandes líneas de inversión.

La estrategia no debe convertirse en una colección de tendencias. Debe expresar resultados, población afectada, restricciones y criterios de éxito. «Impulsar inteligencia artificial» es demasiado genérico; «mejorar una decisión concreta con modelos evaluados, supervisados y gobernados» permite derivar capacidades y controles.

3.2. Nivel táctico

Traduce la dirección en capacidades, arquitectura, cartera, programas y planes plurianuales o anuales. Decide qué iniciativas se proponen, cómo se priorizan, qué dependencias existen, qué recursos y contratos se necesitan y qué unidades participan. El PSI se sitúa principalmente en este enlace estratégico-táctico, aunque contiene decisiones con impacto estratégico y produce un plan de acción que se concretará operativamente.

En este nivel se equilibran transformación y sostenimiento. Una cartera formada solo por nuevas funcionalidades ignora continuidad, obsolescencia, seguridad, calidad del dato y retirada. La planificación táctica debe reservar capacidad para habilitadores y deuda técnica, aunque su beneficio sea indirecto.

3.3. Nivel operativo

Organiza la ejecución de corto plazo: proyectos, iteraciones, despliegues, cambios, mantenimiento, soporte, capacidad, continuidad y tareas. Utiliza calendarios, planes de proyecto, tableros de trabajo, ventanas de cambio, procedimientos, turnos y cuadros de operación. Su objetivo es producir y sostener servicios dentro de los niveles y límites aprobados.

La operación no es meramente reactiva. Debe anticipar demanda, gestionar problemas, automatizar controles, probar recuperación y aportar métricas. Una incidencia repetida puede revelar una brecha de arquitectura o de capacidad que deba escalarse al nivel táctico.

3.4. Comparación

3.5. Cascada y retroalimentación

La trazabilidad descendente relaciona objetivo, capacidad, requisito, sistema, proyecto, servicio e indicador. La retroalimentación ascendente utiliza adopción, incidentes, costes, riesgos y resultados para revisar supuestos. Si la operación no puede sostener una arquitectura, el problema no se resuelve ocultando la métrica: debe revisarse capacidad, diseño o prioridad.

4. CICLO DE PLANIFICACIÓN, DIAGNÓSTICO, ESTADO OBJETIVO Y HOJA DE RUTA

La planificación informática no es una actividad puntual ni un documento aislado, sino un ciclo de decisión. Parte de una misión y de objetivos institucionales, observa la situación actual, identifica brechas, diseña un estado objetivo, selecciona iniciativas, asigna recursos y establece cómo se comprobará el resultado. Después vuelve a comenzar con la evidencia obtenida. Cuando se limita a enumerar compras o proyectos pierde su carácter de planificación y se convierte en una lista de deseos.

4.1. Entradas de la planificación

Las entradas proceden de varios planos. En primer lugar están la estrategia sanitaria, los compromisos de servicio, la normativa y el presupuesto. En segundo lugar aparecen las necesidades de procesos asistenciales, de gestión y de soporte. En tercero se encuentran las capacidades y restricciones tecnológicas: aplicaciones existentes, datos, integraciones, infraestructura, contratos, competencias profesionales, deuda técnica, riesgos y calendario de obsolescencia. Finalmente deben considerarse las expectativas de ciudadanía, profesionales, órganos directivos, responsables de seguridad, protección de datos, arquitectura y control.

Una necesidad no debe formularse como la adquisición de un producto. La expresión «necesitamos la herramienta X» adelanta la solución y dificulta comparar alternativas. Una formulación madura describe el problema, la población afectada, el resultado perseguido, las restricciones y la evidencia que permitirá saber si se ha resuelto. Por ejemplo, «reducir el tiempo medio de conciliación de identidades y mejorar la trazabilidad de altas, bajas y cambios» es una necesidad; «comprar un gestor de identidades concreto» es una opción de solución.

4.2. Diagnóstico de situación

El diagnóstico combina visión funcional y tecnológica. Debe inventariar procesos, información, aplicaciones, interfaces, infraestructuras, contratos, costes, niveles de servicio, incidencias, riesgos y capacidades. El inventario no es suficiente: hay que valorar criticidad, cobertura funcional, calidad, mantenibilidad, seguridad, interoperabilidad, dependencia de proveedor, coste total y adecuación a la arquitectura corporativa. Dos aplicaciones que hacen aparentemente lo mismo pueden tener perfiles muy distintos si una es fuente autorizada de datos y otra una réplica departamental sin gobierno.

4.3. Estado objetivo y análisis de brecha

La planificación define un estado objetivo suficientemente concreto para orientar decisiones, sin pretender congelar cada detalle de diseño. Incluye capacidades de negocio, información, sistemas, datos, integraciones, infraestructura, seguridad, operación y gobierno. El análisis de brecha compara ese objetivo con el estado actual y determina qué debe conservarse, evolucionarse, consolidarse, sustituirse o retirarse. La brecha no siempre se resuelve con software: puede exigir rediseño de proceso, formación, calidad del dato, cambio organizativo, capacidad de soporte o ajuste contractual.

4.4. Priorización y hoja de ruta

Las iniciativas compiten por presupuesto, personas, atención de usuarios, ventanas de implantación y capacidad de cambio. Por ello se priorizan con criterios explícitos: alineamiento, beneficio, urgencia legal, reducción de riesgo, criticidad, dependencia, coste, esfuerzo, madurez de requisitos y capacidad disponible. Una matriz de puntuación ayuda, pero no sustituye el juicio directivo: la puntuación debe ser trazable, revisable y acompañarse de análisis cualitativo.

La hoja de ruta ordena iniciativas en oleadas y hace visibles dependencias. Los proyectos habilitadores —identidad, integración, calidad del dato, observabilidad, infraestructura o seguridad— pueden no producir por sí solos un beneficio visible para el usuario, pero ser imprescindibles para otros. Si se prioriza solo lo que presenta un retorno inmediato, la organización acumula fragilidad y deuda técnica. La planificación debe equilibrar transformación, continuidad, cumplimiento y sostenimiento de servicios existentes.

4.5. Seguimiento y revisión

El plan debe contener responsables, hitos, indicadores, tolerancias y reglas de escalado. Se controla tanto la ejecución —plazo, coste, alcance, riesgo— como la realización de beneficios. Entregar un sistema no demuestra que el problema se haya resuelto. Deben medirse adopción, calidad, tiempos, seguridad, disponibilidad, satisfacción y resultados del proceso. Las desviaciones relevantes pueden exigir replanificar la cartera o revisar la arquitectura objetivo.

La revisión periódica evita que el plan quede obsoleto. Debe incorporar cambios normativos, presupuestarios, tecnológicos y organizativos, nuevos riesgos y aprendizaje de proyectos. La planificación adaptativa mantiene una dirección estable, pero permite modificar secuencias y soluciones cuando cambia la evidencia. No debe confundirse adaptabilidad con ausencia de gobierno: los cambios han de registrarse, justificarse y aprobarse por el nivel competente.

5. EL PLAN DE SISTEMAS DE INFORMACIÓN: CONCEPTO, ALCANCE Y PRODUCTOS

5.1. Concepto y finalidad

El Plan de Sistemas de Información establece un marco de referencia para que los sistemas soporten los objetivos y procesos de la organización. Analiza necesidades y situación actual, define modelos de información y sistemas, selecciona una arquitectura tecnológica y organiza los proyectos necesarios para evolucionar. Su alcance puede ser corporativo o corresponder a un dominio suficientemente relevante y coherente.

El PSI no equivale a inventario, presupuesto, plan anual, plan de seguridad ni diseño de una única aplicación. Integra esas perspectivas cuando afectan al conjunto, pero mantiene una visión transversal. Su nivel de detalle debe permitir decidir prioridades y coherencia sin sustituir el análisis y diseño de cada proyecto.

5.2. Alcance, horizonte y condiciones de inicio

El alcance se define por unidades, procesos, información, sistemas, interfaces y relaciones externas. Debe indicar explícitamente qué queda fuera y qué dependencias se observarán. El horizonte depende del ritmo de cambio, la capacidad y los ciclos presupuestarios y contractuales; lo importante es distinguir dirección, transición y revisiones, no fijar una cifra universal.

Antes de iniciar se necesita patrocinio, responsabilidad, acceso a información, participación de áreas afectadas y capacidad para aprobar resultados. Un PSI sin órgano decisor puede producir un buen diagnóstico, pero no una transformación. También debe acordarse el nivel de profundidad: no todos los sistemas y procesos requieren el mismo análisis.

5.3. Entradas y productos

Las entradas incluyen estrategia, procesos, normativa, presupuesto, antecedentes, inventarios, contratos, métricas, riesgos y necesidades. Los principales productos son catálogo de requisitos, valoración de sistemas actuales, modelo de información, modelo de sistemas, arquitectura tecnológica, plan de proyectos, mantenimiento del PSI y propuesta aprobada.

5.4. Arquitectura de información y plan de acción

La arquitectura de información integra modelo de información, modelo de sistemas de información y arquitectura tecnológica. El plan de acción contiene los proyectos y el plan de mantenimiento del propio PSI. Esta estructura permite separar la descripción del futuro de la secuencia utilizada para alcanzarlo.

5.5. Distinción frente al EVS y al proyecto

El Estudio de Viabilidad del Sistema analiza alternativas para una necesidad concreta y pertenece al proceso de Desarrollo de Sistemas de Información de Métrica v3. El PSI tiene una visión global y proporciona resultados que pueden alimentar estudios posteriores. Un proyecto, por su parte, concreta alcance, entregables, cronograma, coste y ejecución de una iniciativa aprobada.

En el examen TFA-STI SAS 2019, turno libre, pregunta 32, se exigió reconocer que el EVS se incluye en Desarrollo de Sistemas de Información y no en Planificación.

6. MÉTRICA VERSIÓN 3: ESTRUCTURA, INTERFACES, PARTICIPANTES Y TÉCNICAS

Métrica versión 3 proporciona una metodología de referencia para sistematizar la planificación, el desarrollo y el mantenimiento de sistemas de información. Su valor reside en ordenar actividades, participantes, productos, técnicas e interfaces de apoyo. No es una ley ni convierte automáticamente su uso en obligatorio para toda Administración; cada organización puede adoptarla, adaptarla o complementarla mediante sus normas y modelos internos.

6.1. Tres procesos principales y subdivisión del desarrollo

La estructura general distingue Planificación de Sistemas de Información, Desarrollo de Sistemas de Información y Mantenimiento de Sistemas de Información. El proceso de desarrollo se descompone en Estudio de Viabilidad del Sistema, Análisis del Sistema de Información, Diseño del Sistema de Información, Construcción del Sistema de Información e Implantación y Aceptación del Sistema. Esta jerarquía explica por qué el EVS no es una actividad del PSI, aunque utilice sus resultados como entrada.

6.2. Interfaces de apoyo

La metodología contempla interfaces de gestión de proyectos, seguridad, aseguramiento de la calidad y gestión de la configuración. No son fases aisladas al final. Aportan prácticas transversales para planificar recursos, tratar riesgos, comprobar productos y controlar versiones y cambios. En un PSI moderno deben complementarse con privacidad, arquitectura empresarial, interoperabilidad, gobierno del dato, continuidad y gestión de proveedores.

6.3. Participantes y responsabilidad

La calidad del PSI depende de la participación de perfiles directivos, funcionales y técnicos. La dirección aporta objetivos, prioridades y capacidad de decisión; los responsables de procesos explican necesidades y restricciones; los usuarios conocen la operación real; los especialistas de sistemas, datos, seguridad, infraestructura e interoperabilidad analizan viabilidad y coherencia; y el equipo del plan integra evidencias y prepara la propuesta.

La participación no elimina la responsabilidad. Conviene establecer una matriz RACI: quién responde del resultado, quién ejecuta, quién debe ser consultado y quién informado. El responsable último no puede delegar la decisión estratégica en el proveedor ni en el equipo redactor. Tampoco debe confundirse consulta con derecho de veto: las discrepancias se documentan y escalan conforme al modelo de gobierno.

6.4. Técnicas de trabajo

Entre las técnicas útiles se encuentran entrevistas, sesiones de trabajo, análisis documental, modelado de procesos, catálogo de requisitos, matrices requisito-sistema, análisis de impacto, DAFO, análisis coste-beneficio, evaluación de riesgos, diagramas de contexto, modelos de información y planificación de actividades y recursos. La técnica se selecciona por la decisión que debe soportar; usar muchas técnicas sin una pregunta clara solo genera documentación.

7. PSI 1 A PSI 3: INICIO, ORGANIZACIÓN E INFORMACIÓN RELEVANTE

7.1. PSI 1: Inicio del Plan de Sistemas de Información

El inicio determina por qué se necesita el plan, cuál es su ámbito preliminar y quién asume la responsabilidad. Sus tareas son PSI 1.1 Análisis de la necesidad del PSI, PSI 1.2 Identificación del alcance y PSI 1.3 Determinación de responsables. El objetivo no es diseñar todavía sistemas, sino confirmar que existe mandato, necesidad, patrocinio y una delimitación inicial razonable.

El análisis de necesidad relaciona el PSI con cambios organizativos, deficiencias de información, obsolescencia, dispersión de soluciones, nuevos servicios, requisitos normativos o estrategia institucional. La identificación del alcance establece procesos, unidades y relaciones que se estudiarán. La determinación de responsables identifica promotor, dirección, jefatura de proyecto y unidades implicadas, evitando que el plan nazca sin capacidad real de decisión.

7.2. PSI 2: Definición y organización del PSI

Esta actividad convierte el mandato inicial en un trabajo gobernable. Contiene cuatro tareas: PSI 2.1 Especificación del ámbito y alcance, PSI 2.2 Organización del PSI, PSI 2.3 Definición del plan de trabajo y PSI 2.4 Comunicación del plan de trabajo. La cuarta tarea es una omisión frecuente en resúmenes y constituye una buena trampa de examen.

La especificación profundiza en procesos, áreas, objetivos y límites. La organización define participantes, grupos de trabajo, mecanismos de coordinación y productos a revisar. El plan de trabajo establece actividades, calendario, recursos, técnicas y entregables. La comunicación asegura que los participantes conocen propósito, responsabilidades, dedicación, hitos y vías de escalado. Un plan técnicamente correcto puede fracasar si las personas no saben qué se espera de ellas.

7.3. PSI 3: Estudio de la información relevante

PSI 3 reúne y valora antecedentes que condicionan el plan. Sus tareas son PSI 3.1 Selección y análisis de antecedentes y PSI 3.2 Valoración de antecedentes. Se estudian planes anteriores, estrategias, normas, auditorías, arquitectura, contratos, inventarios, proyectos en curso, estadísticas de servicio, riesgos y decisiones pendientes.

La valoración no consiste en copiar documentación. Debe determinar vigencia, fiabilidad, alcance, contradicciones y efectos. Un inventario reciente puede estar incompleto; un plan antiguo puede contener principios aún válidos; una auditoría puede identificar un riesgo no tratado; un contrato próximo a finalizar puede condicionar la secuencia. El producto útil es una síntesis de restricciones y oportunidades, no un repositorio indiscriminado.

8. PSI 4 Y PSI 5: REQUISITOS Y SISTEMAS DE INFORMACIÓN ACTUALES

8.1. PSI 4: Identificación de requisitos

Esta actividad determina qué información y capacidades necesitan los procesos incluidos en el plan. Sus tareas son PSI 4.1 Estudio de los procesos del PSI, PSI 4.2 Análisis de las necesidades de información y PSI 4.3 Catalogación de requisitos. El resultado es un catálogo estructurado, priorizado y trazable, no una lista de preferencias tecnológicas.

El estudio de procesos identifica actividades, actores, eventos, entradas, salidas, decisiones y problemas. El análisis de necesidades pregunta qué información se requiere, con qué calidad, oportunidad, granularidad, seguridad y responsabilidad. La catalogación normaliza el requisito, elimina duplicidades, registra origen y prioridad y establece relaciones con procesos y objetivos. Deben incluirse requisitos funcionales y no funcionales: disponibilidad, rendimiento, usabilidad, accesibilidad, privacidad, interoperabilidad, auditabilidad y continuidad.

8.2. PSI 5: Estudio de los sistemas de información actuales

PSI 5 analiza los sistemas existentes en relación con los requisitos. Comprende PSI 5.1 Alcance y objetivos del estudio de los sistemas de información actuales, PSI 5.2 Análisis de los sistemas de información actuales y PSI 5.3 Valoración de los sistemas de información actuales. La primera tarea decide qué sistemas requieren profundidad; la segunda recoge arquitectura, funciones, datos, interfaces, tecnología y operación; la tercera valora adecuación y posibilidades de evolución.

No todos los sistemas merecen el mismo esfuerzo. Se priorizan los críticos, los que soportan procesos incluidos, los que concentran datos relevantes, los que presentan riesgo u obsolescencia y los que condicionan múltiples iniciativas. La valoración debe separar hechos de opiniones y considerar cobertura, calidad, estabilidad, mantenibilidad, costes, seguridad, interoperabilidad, contrato, soporte y satisfacción.

8.3. Relación entre PSI 4 y PSI 5

Los requisitos y los sistemas actuales se analizan de forma coordinada, pero no son lo mismo. PSI 4 pregunta qué necesita la organización; PSI 5 determina cómo lo cubren hoy los sistemas. Si se empieza por la tecnología existente, se corre el riesgo de limitar la necesidad a lo que ya se conoce. Si se ignoran los sistemas actuales, se proponen soluciones inviables o duplicadas. La matriz requisito-sistema permite identificar cobertura completa, parcial, inexistente y redundante.

9. PSI 6 Y PSI 7: MODELO DE SISTEMAS Y ARQUITECTURA TECNOLÓGICA

9.1. PSI 6: Diseño del modelo de sistemas de información

PSI 6 transforma requisitos y valoración del presente en el modelo objetivo. Sus tareas son PSI 6.1 Diagnóstico de la situación actual y PSI 6.2 Definición del modelo de sistemas de información. El diagnóstico sintetiza brechas, duplicidades, dependencias, riesgos y oportunidades. La definición establece sistemas, límites, responsabilidades, relaciones, información intercambiada y cobertura de requisitos.

El modelo no tiene por qué reproducir la estructura orgánica. Los sistemas deben organizarse alrededor de capacidades y procesos, evitando silos que impidan continuidad. Debe aclarar fuentes autorizadas, sistemas consumidores, servicios compartidos y reglas de integración. También ha de señalar componentes transversales —identidad, notificación, firma, interoperabilidad, terminologías, gestión documental, observabilidad— cuya reutilización reduce duplicidad y riesgo.

9.2. PSI 7: Definición de la arquitectura tecnológica

PSI 7 determina el soporte tecnológico del modelo de sistemas. Incluye PSI 7.1 Identificación de las necesidades de infraestructura tecnológica y PSI 7.2 Selección de la arquitectura tecnológica. La primera deriva necesidades de procesamiento, almacenamiento, comunicaciones, puestos, plataformas, disponibilidad, seguridad, operación y escalabilidad. La segunda compara alternativas y selecciona una arquitectura coherente con principios y restricciones.

La selección debe considerar coste total, capacidad, rendimiento, resiliencia, operabilidad, competencias, soporte, portabilidad, seguridad, cumplimiento, sostenibilidad y estrategia de salida. En un ámbito sanitario se exige especial atención a continuidad, tiempos de respuesta, trazabilidad, segregación, recuperación y gestión de cambios. La tecnología más novedosa no es necesariamente la más adecuada: debe demostrar valor y encaje.

9.3. Arquitectura empresarial y arquitectura de solución

El PSI trabaja a nivel de arquitectura empresarial o de dominio: establece principios, capacidades y modelos comunes. Cada proyecto desarrollará después su arquitectura de solución dentro de ese marco. Si el PSI baja a decisiones excesivamente detalladas, envejece rápido y limita alternativas; si es demasiado genérico, no permite controlar coherencia. La profundidad adecuada es la que permite aprobar o rechazar iniciativas de forma consistente.

10. PARTICIPANTES, PSI 8 Y PSI 9: PLAN DE ACCIÓN, REVISIÓN Y APROBACIÓN

10.1. Participantes

El PSI necesita representación directiva, funcional y técnica. El promotor justifica la necesidad y facilita capacidad de decisión; la dirección del plan coordina trabajo y productos; responsables de proceso y usuarios aportan operación real; especialistas de sistemas, datos, arquitectura, seguridad, privacidad, infraestructura, interoperabilidad, contratación y servicios analizan condiciones; y los órganos competentes revisan y aprueban.

10.2. RACI, participación y conflicto

La matriz RACI distingue responsable último, ejecutor, consultado e informado. Evita comités en los que todos participan pero nadie decide. La consulta debe incluir personas afectadas y conocimiento operativo, pero la aprobación corresponde al órgano competente. Las discrepancias se documentan con alternativas, impacto, riesgo y recomendación.

Los proveedores pueden aportar conocimiento, nunca sustituir la responsabilidad ni definir por sí solos necesidad, arquitectura o aceptación del riesgo. El PSI debe preservar independencia suficiente para comparar opciones, controlar dependencia y exigir transferencia de conocimiento.

10.3. PSI 8: Definición del plan de acción

PSI 8 convierte el modelo objetivo en una transición ejecutable. Sus tareas son PSI 8.1 Definición de proyectos a realizar y PSI 8.2 Elaboración del plan de mantenimiento del PSI. La primera identifica proyectos, objetivos, prioridad, dependencias, recursos e hitos. La segunda establece cómo se revisará y versionará el propio plan.

El mantenimiento del PSI no es el mantenimiento de aplicaciones ni de infraestructura. Define revisiones ordinarias y extraordinarias, responsables, control de cambios, registro de decisiones y análisis de impacto sobre arquitectura y cartera.

10.4. PSI 9: Revisión y aprobación

PSI 9 consta de PSI 9.1 Convocatoria de la presentación, PSI 9.2 Evaluación y mejora de la propuesta y PSI 9.3 Aprobación del Plan de Sistemas de Información. La propuesta se contrasta con los responsables, se incorporan mejoras justificadas y finalmente se aprueba por el órgano competente.

La aprobación confirma dirección, prioridades, recursos, tolerancias y responsabilidades. No implica ejecutar automáticamente todos los proyectos: cada iniciativa deberá superar las decisiones de cartera, presupuesto, contratación y viabilidad que correspondan.

11. DEL PSI A LA CARTERA, LOS PROGRAMAS, LOS PROYECTOS Y EL ROADMAP

El PSI no termina con una lista de proyectos. Debe conectarse con la gestión de cartera, la programación presupuestaria y el gobierno de arquitectura. La cartera decide qué iniciativas entran, continúan, se reorientan o se detienen. El PSI proporciona criterios y dependencias; la cartera gestiona la decisión continua bajo capacidad limitada.

11.1. De capacidad a iniciativa

Una capacidad objetivo puede requerir varios proyectos: rediseño de proceso, migración de datos, integración, infraestructura, formación y retirada de legado. Agruparlos en un programa permite coordinar beneficios y dependencias. La unidad de priorización no debe ser siempre el proyecto aislado, porque un proyecto habilitador puede parecer poco rentable si se separa de las capacidades que hace posibles.

11.2. Criterios de cartera

11.3. Roadmap y dependencias

El roadmap organiza iniciativas en horizontes. Un primer horizonte estabiliza y prepara; otro despliega capacidades prioritarias; un tercero consolida, escala o retira legado. La secuencia debe respetar dependencias de datos, arquitectura, contratación, infraestructura, formación y operación. La representación temporal no es un compromiso inmutable: incluye supuestos, hitos de decisión y criterios para avanzar.

11.4. Presupuesto y contratación

La planificación debe considerar tiempos de preparación, licitación, adjudicación, implantación y transición. Un proyecto no está financiado por aparecer en el PSI. Debe existir programación presupuestaria, expediente adecuado y capacidad interna de dirección y aceptación. Las prescripciones deben expresar requisitos y estándares, no convertir el plan en una decisión anticipada de marca. La estrategia de salida, portabilidad y transferencia de conocimiento forma parte del coste y del riesgo.

11.5. Retirada y deuda técnica

La cartera debe reservar capacidad para retirada, actualización de componentes, reducción de deuda técnica y mejoras de operación. Implantar una solución sin apagar la anterior duplica costes y superficies de riesgo. La retirada exige inventariar datos, interfaces, usuarios, obligaciones de conservación, evidencias de auditoría y dependencias ocultas. El cierre es un producto planificado, no una consecuencia automática del alta del nuevo sistema.

12. GOBIERNO Y MARCOS COMPLEMENTARIOS: ISO/IEC 38500, COBIT E ITIL

12.1. ISO/IEC 38500:2024

ISO/IEC 38500:2024 ofrece principios para los órganos de gobierno sobre el uso eficaz, eficiente y aceptable de las tecnologías de la información. Su foco no es dirigir tareas técnicas, sino asegurar que el uso actual y futuro de la tecnología se evalúa, se dirige y se monitoriza como parte del gobierno de la organización. El PSI aporta evidencias para esas decisiones: valor, riesgo, recursos, responsabilidades y resultados.

El órgano de gobierno debe evaluar propuestas y contexto, dirigir mediante políticas y prioridades y monitorizar rendimiento y conformidad. La dirección ejecutiva traduce esa orientación en planes y operación. Esta separación no crea dos mundos aislados: exige información comparable, escalado de excepciones y rendición de cuentas.

12.2. COBIT 2019

COBIT 2019 es un marco de gobierno y gestión de información y tecnología empresarial. Su modelo núcleo contiene 40 objetivos agrupados en cinco dominios. EDM —Evaluate, Direct and Monitor— corresponde a gobierno. Los dominios de gestión son APO —Align, Plan and Organize—, BAI —Build, Acquire and Implement—, DSS —Deliver, Service and Support— y MEA —Monitor, Evaluate and Assess—.

COBIT distingue seis principios para un sistema de gobierno y tres principios para el marco de gobierno. Entre los primeros están proporcionar valor a las partes interesadas, enfoque holístico, sistema dinámico, separación entre gobierno y gestión, adaptación a las necesidades de la empresa y cobertura de extremo a extremo. Los principios del marco se refieren a basarse en un modelo conceptual, ser abierto y flexible y alinearse con estándares relevantes. Confundir ambos grupos es una trampa habitual.

12.3. ITIL 4 y gestión de servicios

ITIL 4 complementa al PSI desde la gestión de servicios. El sistema de valor del servicio y sus prácticas ayudan a diseñar cómo se operarán, soportarán y mejorarán las capacidades previstas. La planificación debe considerar catálogo, niveles de servicio, disponibilidad, capacidad, continuidad, seguridad, cambios, incidencias, problemas, conocimiento, proveedores y mejora continua.

ITIL no sustituye la planificación estratégica ni es una norma certificable para organizaciones. ISO/IEC 20000 establece requisitos de un sistema de gestión de servicios; ITIL ofrece orientación y prácticas. Un PSI que solo diseña la construcción y no la operación transfiere costes y riesgos a explotación.

12.4. Integración de marcos

Métrica v3 organiza el proceso del PSI; ISO/IEC 38500 orienta el gobierno; COBIT integra objetivos de gobierno y gestión; ITIL 4 aporta gestión del servicio; ENS, ENI y protección de datos establecen obligaciones y condiciones. No son alternativas excluyentes. Deben utilizarse proporcionalmente y sin duplicar documentación, asignando a cada evidencia una finalidad de decisión.

13. SEGURIDAD, PRIVACIDAD, INTEROPERABILIDAD, CONTINUIDAD Y CUMPLIMIENTO

La planificación debe integrar obligaciones y riesgos desde el inicio. Seguridad, privacidad, interoperabilidad, contratación y continuidad no son anexos posteriores, sino condiciones que modifican requisitos, arquitectura, coste, secuencia y responsabilidades.

13.1. Esquema Nacional de Seguridad

El Real Decreto 311/2022 regula el ENS y exige política y organización de seguridad, categorización, análisis y gestión del riesgo, medidas proporcionales, vigilancia, respuesta, continuidad y auditoría. En el PSI se identifican sistemas y servicios afectados, criticidad, brechas y proyectos transversales. La categorización no se deduce solo del tipo de dato: se valoran las dimensiones y consecuencias aplicables.

13.2. Protección de datos

El RGPD y la Ley Orgánica 3/2018 exigen licitud, finalidad, minimización, exactitud, conservación limitada, integridad, confidencialidad y responsabilidad proactiva. El PSI debe prever privacidad desde el diseño, roles, flujos de datos, accesos, trazabilidad, conservación, transferencias y evaluaciones de impacto cuando procedan. Que un proyecto sea útil no convierte automáticamente todo tratamiento en necesario.

13.3. Interoperabilidad

El Real Decreto 4/2010 regula el ENI. La interoperabilidad organizativa define acuerdos, procesos y responsabilidades; la semántica asegura significado común; y la técnica utiliza estándares y mecanismos compatibles. En salud, conectar sistemas sin terminología, contexto y gobierno puede transportar datos que no se interpretan de forma segura.

13.4. Contratación y suministro

La Ley 9/2017 obliga a justificar necesidad, respetar concurrencia y definir prescripciones adecuadas. La planificación debe considerar preparación, licitación, adjudicación, transición, control de ejecución y finalización. Se valoran ciclo de vida, portabilidad, interoperabilidad, seguridad, niveles de servicio, documentación, propiedad de datos, transferencia y estrategia de salida. Una marca solo puede aparecer en los supuestos y condiciones legalmente admisibles.

13.5. Continuidad y resiliencia

La indisponibilidad de un servicio sanitario puede afectar la asistencia. El PSI debe identificar dependencias, objetivos de recuperación, estrategias, procedimientos degradados y pruebas. La continuidad incluye personas, identidad, comunicaciones, datos, proveedores y operación; no se resuelve únicamente duplicando infraestructura.

13.6. Gobierno del dato

El modelo de información asigna propiedad, custodia y fuentes autorizadas; establece calidad, metadatos, linaje, clasificación, acceso, conservación y uso secundario. Fuente autorizada no significa copia física única, sino responsabilidad definida y reglas de sincronización. La analítica necesita datos confiables y finalidad gobernada.

13.7. Integración en las actividades PSI

14. APLICACIÓN AL SSPA Y ESTRATEGIA DE SALUD DIGITAL DE ANDALUCÍA 2030

La planificación informática del SSPA debe alinearse con la Estrategia de Salud Digital de Andalucía 2030, aprobada por Acuerdo del Consejo de Gobierno de 23 de diciembre de 2025 y con vigencia de 2026 a 2030. La estrategia surgió de la formulación inicial 2024-2028, pero la prolongación de su elaboración motivó la denominación final ESDA 2030. Por ello, mantener 2024-2028 como periodo vigente es incorrecto.

14.1. Misión, visión y objetivos generales

La misión es contribuir a preservar y promover la salud utilizando la tecnología como apoyo a la atención y elemento transformador del SSPA. Su visión es alcanzar una organización sanitaria madura digitalmente que preste servicios de alto valor. Se articula en cuatro objetivos generales:

1. Mejorar y evolucionar los servicios digitales de salud según las necesidades reales de las personas y su contexto.
2. Mejorar la toma de decisiones aprovechando el valor y la calidad del dato y del conocimiento.
3. Impulsar la transformación digital de la organización, fortaleciendo capacidades y modernizando la salud.
4. Fomentar la innovación en el ecosistema digital del SSPA y respaldar iniciativas transformadoras.

14.2. Pilares y programas

Los tres pilares transversales son gobernanza digital, humanización digital y capacitación digital. La gobernanza define decisiones y responsabilidad; la humanización exige que la tecnología mejore la experiencia y evite exclusión; la capacitación desarrolla competencias y adopción. Los seis programas corporativos son analítica avanzada, ciberseguridad, gestión del cambio y capacitación, gestión y soporte, infraestructura tecnológica y sistemas de información.

14.3. Alineamiento asistencial y directivo

La planificación TIC no puede ser un silo técnico. Debe relacionarse con planificación asistencial, calidad, recursos humanos, infraestructuras, contratación, investigación y gestión económica. Las unidades funcionales participan en necesidades y beneficios; los órganos TIC aseguran arquitectura, seguridad y operación; la dirección decide prioridades y acepta riesgos dentro de sus competencias.

14.4. Aplicación prudente de ejemplos

Los ejemplos de planificación en el SAS deben distinguir información oficial de supuestos didácticos. No deben presentarse como hechos arquitecturas concretas, ubicaciones de centros de datos, tecnologías obligatorias, cifras de despliegue o resultados de incidentes sin una fuente verificable. Para estudiar, es válido construir casos hipotéticos siempre que se indiquen como tales y se utilicen para aplicar criterios de PSI.

15. SEGUIMIENTO, INDICADORES, BENEFICIOS Y REVISIÓN ADAPTATIVA

15.1. Cuadro de mando del plan

El cuadro de mando combina indicadores de ejecución y de resultado. Los primeros muestran proyectos iniciados, hitos, gasto, riesgos y dependencias. Los segundos muestran beneficios: reducción de tiempos, mejora de disponibilidad, calidad de datos, adopción, satisfacción, seguridad o disminución de tareas manuales. Un plan puede ejecutar el presupuesto y no producir valor; por eso ambas perspectivas son necesarias.

15.2. Líneas base, metas y propietarios

Cada indicador necesita definición, fuente, frecuencia, línea base, meta, tolerancia y propietario. La línea base permite comparar; la meta expresa el cambio esperado; la tolerancia determina cuándo actuar; y el propietario responde de interpretar y promover medidas. Los datos deben ser fiables y su coste de obtención proporcional al valor de la decisión.

15.3. Revisión adaptativa

La revisión puede ser trimestral para cartera y anual para una actualización estructurada, además de revisiones extraordinarias por cambios relevantes. Debe examinar supuestos, beneficios, capacidad, riesgos, arquitectura y contexto. No todo retraso justifica replanificar; algunas desviaciones se gestionan dentro del proyecto. Se escala cuando afecta objetivos, dependencias, tolerancias o viabilidad global.

15.4. Gestión de beneficios

Los beneficios deben tener propietario funcional, no solo técnico. El proyecto entrega capacidad; el área usuaria cambia proceso y comportamiento para realizar el beneficio. Por ejemplo, una agenda digital no reduce demoras por sí sola si las reglas de programación, los datos y la gestión de huecos no cambian. El plan debe incluir acciones no tecnológicas y medición posterior a la implantación.

15.5. Aprendizaje y mejora

Las revisiones postimplantación, incidentes, auditorías y métricas alimentan el mantenimiento del PSI. Se registran decisiones, excepciones, patrones reutilizables y causas de desviación. El objetivo no es buscar culpables, sino mejorar estimaciones, arquitectura, requisitos y gobierno. La mejora continua debe evitar repetir pilotos sin criterios de escalado o mantener proyectos que ya no justifican su inversión.

16. CASO PRÁCTICO INTEGRADO DE PLAN DE SISTEMAS DE INFORMACIÓN

El siguiente caso es hipotético y sirve para aplicar el proceso. Un conjunto de centros necesita mejorar la gestión de solicitudes internas relacionadas con equipamiento y servicios. Existen formularios distintos, correos, hojas de cálculo y aplicaciones locales. La dirección quiere reducir tiempos, mejorar trazabilidad y disponer de información comparable sin perder requisitos legítimos de cada centro.

16.1. Inicio y organización

PSI 1 documenta la necesidad, delimita inicialmente los procesos de solicitud, aprobación, provisión y cierre, e identifica responsables. PSI 2 concreta el ámbito, forma grupos con usuarios, responsables funcionales, TIC, seguridad, datos y contratación, establece calendario y comunica dedicación y entregables. PSI 3 revisa procedimientos, contratos, auditorías, catálogos, estadísticas e iniciativas existentes.

16.2. Requisitos y situación actual

PSI 4 identifica requisitos: catálogo común, reglas configurables, identidad, segregación de funciones, trazabilidad, notificaciones, integración, accesibilidad, informes, conservación y continuidad. PSI 5 inventaría soluciones actuales y valora cobertura, coste, seguridad, calidad y posibilidad de reutilización. Se detecta que una plataforma corporativa cubre gran parte de la necesidad, pero requiere componentes adicionales y normalización de datos.

16.3. Modelo y arquitectura objetivo

PSI 6 propone un modelo con portal de solicitudes, motor de procesos, catálogo común, servicios de identidad y notificación, repositorio de evidencias, integración con sistemas maestros y analítica. Define qué sistema es fuente de cada dato y qué variantes se permiten. PSI 7 determina necesidades de disponibilidad, rendimiento, registro, respaldo, integración y operación, y compara alternativas de evolución de la plataforma frente a nueva adquisición.

16.4. Plan de acción y aprobación

PSI 8 define proyectos: gobierno del catálogo, piloto funcional, integraciones, migración, formación, despliegue por oleadas y retirada de formularios locales. Establece dependencias y un plan de mantenimiento del PSI. PSI 9 presenta la propuesta, incorpora observaciones sobre capacidad y transición y obtiene aprobación condicionada a un piloto con criterios de éxito.

17. CONCLUSIONES, ESTRATEGIA DE ESTUDIO Y MAPA CONCEPTUAL

17.1. Síntesis del tema

La planificación informática es un sistema de decisiones que conecta misión, procesos, información y tecnología. Los niveles estratégico, táctico y operativo difieren, pero forman una cadena. El PSI ocupa el enlace central: identifica necesidades, estudia el presente, diseña modelos objetivo y organiza la transición.

Métrica v3 estructura el PSI en nueve actividades. PSI 1 a 3 inician, organizan y estudian antecedentes; PSI 4 y 5 analizan requisitos y sistemas actuales; PSI 6 y 7 definen modelo y arquitectura; PSI 8 y 9 establecen proyectos, mantenimiento del plan, revisión y aprobación. Esta lógica es más importante que una memorización aislada.

17.2. Errores que deben evitarse

• Comenzar por una marca o producto y adaptar después la necesidad.
• Confundir inventario con diagnóstico o arquitectura tecnológica con arquitectura de información completa.
• Tratar el PSI como plan anual, proyecto único, presupuesto o plan exclusivo de seguridad.
• Omitir operación, retirada, cambio, datos, contratación o capacidad interna.
• Aprobar iniciativas sin propietario de beneficio, línea base ni indicador.
• Presentar como hechos corporativos ejemplos no respaldados por fuentes.

17.3. Método de estudio

Construye una tabla con las nueve actividades, tareas, entradas, productos y confusiones. Practica casos breves: dado un problema, identifica en qué actividad se analiza; dado un producto, determina qué decisión soporta. Separa las versiones de COBIT y recuerda que ISO/IEC 38500 orienta gobierno, mientras Métrica organiza el proceso PSI.

Repasa las perlas reales citadas: en 2019 se preguntó por COBIT 5 y por la ubicación del EVS; en 2025 se preguntó por el principio de adaptación de COBIT 2019, el alineamiento de planificación TIC y el documento de medio-largo plazo. Utiliza estas referencias para comprender el tipo de distractor, no para limitar el estudio a su redacción.

17.4. Mapa conceptual final

17.5. Reglas de examen

• PSI tiene nueve actividades; recuerda PSI 2.4, PSI 8.2 y las tres tareas de PSI 9.
• EVS pertenece al proceso de Desarrollo de Sistemas de Información, no al PSI.
• PSI 4 identifica requisitos; PSI 5 estudia sistemas actuales; PSI 6 define el modelo objetivo.
• PSI 7 selecciona arquitectura tecnológica; PSI 8 organiza proyectos y mantenimiento del plan.
• COBIT 2019 tiene 40 objetivos en cinco dominios; EDM es gobierno.
• No mezcles principios del sistema de gobierno COBIT con principios del marco.
• La estrategia andaluza vigente es ESDA 2030, con horizonte 2026-2030.
• El PSI conecta estrategia, arquitectura, cartera y ejecución; no es un plan anual ni un plan de seguridad.