1️⃣ Concepto ITIL y Buenas Prácticas en Gestión de Servicios TI

¿Qué es ITIL? (Information Technology Infrastructure Library)

ITIL (v3 y v4): Conjunto de PUBLICACIONES que documentan LAS MEJORES PRÁCTICAS para la gestión de SERVICIOS TI de alta calidad. NO es una norma obligatoria ni certificable directamente (como sí lo es ISO 20000), sino una GUÍA DE REFERENCIA que las organizaciones adoptan voluntariamente para mejorar cómo ofrecen y gestionan sus servicios TI.

Concepto de SERVICIO TI (Utilidad + Garantía)

Un Servicio TI = UTILIDAD (lo que hace) + GARANTÍA (cómo lo entrega). Ejemplo: el servicio «acceso a DIRAYA» tiene UTILIDAD (permitir abrir la historia clínica) pero debe garantizar DISPONIBILIDAD (99.9% del tiempo), RENDIMIENTO (respuesta <2 segundos), SEGURIDAD (acceso solo a usuarios autorizados), CONTINUIDAD (si un CPD cae, el otro toma relevo).

Marcos de Buenas Prácticas (contexto general)

Marco	Enfoque	Certificable	Aplicación SAS
ITIL v3/v4	Gestión de Servicios TI (ITSM)	NO (personas sí)	Organización de procesos, mejora continua
ISO/IEC 20000	Sistema de Gestión Servicios TI (SGSTI)	SÍ (organizaciones)	Certificación auditable del SGSTI
COBIT 2019	Gobernanza y Gestión TI	NO	Control interno, cumplimiento normativo
ISO/IEC 27001	Seguridad de la Información	SÍ	Protección datos clínicos (RGPD, LOPDGDD)

2️⃣ Enfoque hacia Procesos Integrados vs Enfoque Silos

Problema del Enfoque Tradicional: SILOS

Organizaciones TIC clásicas estructuran áreas por TECNOLOGÍA (no por valor):

• Área Servidores → responsables solo de servidores
• Área Comunicaciones → responsables solo de redes
• Área BBDD → responsables solo de bases de datos
• Área Soporte → recibe llamadas pero sin escalado claro

Resultado: Cuando DIRAYA «no va rápido», ¿quién es responsable? ¿Servidores? ¿Redes? ¿BBDD? ¿Aplicación? Nadie tiene visión INTEGRAL del SERVICIO. El médico sufre, las áreas se culpan, sin métricas de calidad.

Solución: Enfoque a PROCESOS (ITIL)

Gestionar por PROCESOS = gestionar por SERVICIOS y VALOR. Un proceso TI es una secuencia de actividades que, tomadas en conjunto, APORTAN VALOR (entregan un servicio). Procesos clave en ITIL:

• Gestión de Incidentes: Restaurar servicio cuando algo falla (médico llama porque no puede abrir DIRAYA → Service Desk abre ticket P1 → escala a CPD → se resuelve en 30 min).
• Gestión de Problemas: Si incidentes sobre DIRAYA se repiten cada semana (timeout conexión BD), identificar CAUSA RAÍZ (ej: conexión BD mal dimensionada) y resolver de forma PERMANENTE.
• Gestión de Cambios: Cuando se actualiza DIRAYA, coordinar pruebas, ventana de mantenimiento, comunicación a usuarios, plan de reversión → SIN SORPRESAS.
• Gestión de Configuración (CMDB): Tener inventario ACTUALIZADO de todos los CIs (Configuration Items: servidores, switches, BBDD, aplicaciones, usuarios, contratos) para entender QIÉN depende de QUÉ.

3️⃣ Ciclo de Vida del Servicio ITIL v3: 5 Fases Integradas

ITIL v3 estructura la gestión de servicios en 5 FASES interrelacionadas, formando un CICLO:

1. ESTRATEGIA DEL SERVICIO (Service Strategy) → Definir QUÉ servicios ofrecer, A QUIÉN, CON QUÉ VALOR
2. DISEÑO DEL SERVICIO (Service Design) → Especificar CÓMO construir esos servicios (arquitectura, SLAs, capacidad, seguridad)
3. TRANSICIÓN DEL SERVICIO (Service Transition) → Gestionar el PASO CONTROLADO de servicios a producción (cambios, despliegues)
4. OPERACIÓN DEL SERVICIO (Service Operation) → EJECUTAR el día a día, entregando servicios conforme a acuerdos (gestionar incidentes, problemas, peticiones)
5. MEJORA CONTINUA DEL SERVICIO (Continual Service Improvement, CSI) → ANALIZAR y MEJORAR basándose en métricas y aprendizajes de operación

El ciclo es ITERATIVO: CSI retroalimenta Estrategia (p.ej., si disponibilidad DIRAYA baja, CSI propone rediseñar CPD → alimenta nueva Estrategia). A continuación detallamos cada fase.

4️⃣ Estrategia del Servicio: Portfolio, Financiera, Demanda

Objetivo Estrategia

DECIDIR QUÉ SERVICIOS TI OFRECER, de forma alineada con NEGOCIO SAS (atender pacientes, garantizar historia clínica, facilitar toma decisiones clínicas), garantizando VALOR (beneficio para negocio) SUPERANDO COSTE y RIESGO.

Procesos Clave en Estrategia del Servicio

1. Gestión del Portfolio de Servicios (Service Portfolio Management)

El PORTFOLIO es la LISTA DE TODOS LOS SERVICIOS que TI ofrece (o considerando ofrecer). Se divide en 3 categorías:

• Servicios en Pipeline: En diseño/desarrollo. Aún no en operación. (Ej: nueva solución de teleconsulta)
• Servicios en Catálogo: En operación, activos. (Ej: DIRAYA, Receta Electrónica, Correo corporativo)
• Servicios Retirados: Ya no se ofrecen. (Ej: portal antiguo de citas, sistemas legacy)

¿Por qué gestionar Portfolio? Para PRIORIZAR: si tenemos presupuesto limitado, ¿inversión en DIRAYA versión 2.0 o en aplicación de oncología? Decisión estratégica.

2. Gestión Financiera de Servicios TI

Entender COSTES: infraestructura (CPD), licencias software, personal, mantenimiento. ASIGNAR costes a servicios (DIRAYA cuesta €X, correo €Y). Facilita decisiones presupuestarias y cálculo ROI (retorno inversión).

3. Gestión de la Demanda (Demand Management)

ANTICIPAR cómo evolucionará la DEMANDA (uso de servicios): ¿más citas online en 2025? ¿más teleconsultas? ¿más telemedicina? Permite planificar CAPACIDAD proactivamente (no esperar a que se sature).

5️⃣ Diseño del Servicio: SLM, Capacidad, Disponibilidad, Continuidad, Seguridad

Objetivo Diseño

CONVERTIR LA ESTRATEGIA EN SERVICIOS CONCRETOS, ROBUSTOS Y OPERABLES. No es suficiente «decidir ofrecer un servicio de teleconsulta»; hay que ESPECIFICAR:

• ¿Qué tecnología? (videoconferencia en la nube vs on-premise)
• ¿Qué capacidad? (máximo usuarios simultáneos, máximo consultas/día)
• ¿Qué disponibilidad? (99.5%, 99.9%, 99.99%)
• ¿Qué seguridad? (encriptación, autenticación, privacidad datos)
• ¿Qué continuidad? (si servidor principal cae, ¿qué ocurre? RTO=15min, RPO=0 datos)
• ¿Quién soporta y cómo? (Service Desk nivel 1, especialistas nivel 2, proveedor externo)

Procesos Clave en Diseño del Servicio

1. Gestión del Catálogo de Servicios (Service Catalogue Management)

El CATÁLOGO es la «CARTA DE SERVICIOS» que TI publica a usuarios: «Ofrecemos estos servicios, con estas características, estos horarios, este precio (si aplica)». Los usuarios SABEN QUÉ PUEDEN PEDIR. Ejemplos:

• Servicio «Acceso DIRAYA»: disponibilidad 99.9%, respuesta <2 seg, soporte 8:00-20:00 de lunes a viernes
• Servicio «Alta usuario corporativo»: máximo 5 días hábiles, requiere autorización jefe
• Servicio «Backup automático»: incluido, punto recuperación cada 24h

2. Gestión de Niveles de Servicio (Service Level Management, SLM)

DEFINIR ACUERDOS FORMALES entre TI y USUARIOS sobre CARACTERÍSTICAS del servicio.

• SLA (Service Level Agreement): Contrato TI ↔ USUARIO FINAL. «Garantizamos disponibilidad DIRAYA 99.9% mensual. Si cae más, compensación.»
• OLA (Operational Level Agreement): Contrato TI ↔ SOPORTE INTERNO. «Nivel 1 debe responder incidencia en 30 min. Si no puede resolver, escala a Nivel 2 en 2 horas.»
• UC (Underpinning Contract): Contrato TI ↔ PROVEEDORES EXTERNOS. «Nuestro proveedor de CPD debe garantizar 99.99% disponibilidad.»

¿Por qué importa? MEDIBLE y AUDITABLE. Si SLA dice 99.9% y estamos en 98.5%, PROBLEMA que debe resolverse. Si 99.95%, SLA cumplido.

3. Gestión de la Capacidad (Capacity Management)

PLANIFICAR RECURSOS (CPU, memoria, ancho banda, almacenamiento) para que servicios funcionen ÓPTIMOS bajo CARGA ESPERADA. Prevenir «cuello de botella» (ej: DIRAYA lento porque servidor al 100%).

4. Gestión de la Disponibilidad (Availability Management)

GARANTIZAR que servicios están DISPONIBLES cuando NECESARIOS (usuários acceden sin cortes no planificados). Técnicas:

• Redundancia: 2 CPDs en activo-activo (si uno cae, otro continúa)
• RAID: Discos espejados (si uno falla, datos en el otro)
• Balanceo carga: Distribuir peticiones entre varios servidores
• Monitorización: Alertas si un componente falla → acción rápida

5. Gestión de la Continuidad de Servicios TI (IT Service Continuity Management)

ASEGURAR RECUPERACIÓN RÁPIDA ante DESASTRES GRAVES (incendio CPD, ataque cibernético, fallo múltiple). Define:

• RTO (Recovery Time Objective): Máximo tiempo permisible para recuperar servicio. (Ej: DIRAYA RTO = 15 minutos)
• RPO (Recovery Point Objective): Máximo datos que se pueden perder. (Ej: DIRAYA RPO = 0 → backups cada 5 minutos)
• Plan de Recuperación: Pasos específicos, responsables, equipos, contactos para ejecutar recuperación.

6. Gestión de la Seguridad de la Información (Information Security Management)

PROTEGER DATOS CLÍNICOS (RGPD, LOPDGDD, ENS nivel ALTO). Incluye:

• Control acceso (solo usuarios autorizados)
• Encriptación (datos en tránsito y en reposo)
• Auditoría (quién accedió a qué, cuándo)
• Planes seguridad física (cerraduras CPD, CCTV, control acceso)

7. Gestión de Proveedores (Supplier Management)

GESTIONAR CONTRATOS con proveedores externos (CPD, Internet, software, servicios cloud, consultoras). Asegurar que cumplen SLAs, que no representan riesgos de seguridad, que tienen planes continuidad.

6️⃣ Transición del Servicio: Cambios, CMDB, Versiones, Conocimiento

Objetivo Transición

LLEVAR SERVICIOS NUEVOS O CAMBIOS SIGNIFICATIVOS DESDE DISEÑO/DESARROLLO A PRODUCCIÓN DE FORMA CONTROLADA, asegurando CALIDAD, SEGURIDAD y MINIMIZANDO RIESGOS DE DISRUPCIÓN ASISTENCIAL.

Procesos Clave en Transición del Servicio

1. Gestión de Cambios (Change Management) 🔴 CRÍTICA PARA EXAMEN

¿QUÉ ES UN CAMBIO? Cualquier MODIFICACIÓN a un elemento de la infraestructura o servicio que PUEDE AFECTAR a otros componentes o usuarios. Ejemplos:

• Actualizar DIRAYA versión 4.1 → 4.2
• Cambiar servidor BD de Hardware antiguo a nuevo
• Modificar regla firewall
• Instalar parche seguridad en equipos clínicos

¿POR QUÉ CONTROLAR CAMBIOS? Muchas interrupciones de servicio (caídas DIRAYA, historias clínicas no disponibles) ocurren JUSTO DESPUÉS de cambios sin control. Cambio mal testado → desastre.

TIPOS DE CAMBIOS ITIL:

Tipo Cambio	Descripción	Proceso	Autorización
ESTÁNDAR	Bajo riesgo, PREAUTORIZADO, repetitivo (ej: reiniciar servicio, copias de seguridad)	Ejecutar directamente (sin RFC)	Automática (predefinido)
NORMAL	Riesgo MEDIO, requiere AUTORIZACIÓN FORMAL, mayoría cambios en organizaciones reales	RFC → CAB → Autorización → Implementación → Evaluación	CAB (Change Advisory Board)
EMERGENCIA	URGENTE (fallo crítico, parche seguridad grave), proceso acelerado	ECAB (Emergency CAB) convoca en horas	ECAB (rápido)

PROCESO NORMAL CAMBIO:

1. RFC (Request for Change): Equipo solicita cambio (ej: «actualizar DIRAYA 4.2»). Define QUÉ, CUÁNDO, QUIÉN, RIESGOS POTENCIALES, PLAN REVERSIÓN.
2. CAB (Change Advisory Board): Comité que evalúa RFC (jefes áreas, arquitectos, Operations Manager). ¿Es necesario? ¿Riesgos aceptables? ¿Plan reversión sólido?
3. Autorización: CAB aprueba o rechaza.
4. Implementación: Equipo ejecuta cambio en ventana acordada (ej: sábado 2:00-4:00 AM para minimizar impacto).
5. Validación: Pruebas post-implementación (DIRAYA responde, usuarios acceden correctamente).
6. Evaluación (PIR, Post-Implementation Review): Análisis post-cambio. ¿Cumplió objetivos? ¿Problemas? → Aprendizaje.

2. Gestión de la Configuración y Activos (Service Asset and Configuration Management, SACM)

CMDB (Configuration Management DataBase): BASE DE DATOS CENTRAL que registra TODOS LOS CIs (Configuration Items) y sus RELACIONES.

¿Qué es un CI? Cualquier componente que forma parte de un servicio:

• Infraestructura: servidores, switches, routers, firewalls, SANs, equipos clínicos
• Software: DIRAYA, BBDD Oracle, SO Windows/Linux, aplicaciones
• Documentación: manuales, diseños, procedimientos
• Usuarios: cuentas, permisos, roles
• Contratos: con proveedores, licencias software

¿Por qué CMDB es crítica? Responde preguntas tipo «si retirar servidor DB01, ¿qué aplicaciones se cuelgan?» (impacto análisis) o «¿cuántos CPUs tenemos en total?» (inventario) o «¿cuándo vence el soporte de este switch?» (planificación renovación).

Elemento de configuración (CI) típico DIRAYA:

• Nombre: DIRAYA v4.2
• Tipo: Aplicación clínica
• Propietario: Jefe Aplicación Clínica
• Usuarios: 2000+ médicos, enfermeras
• Servidores depende: APP01, APP02 (activo-activo), BD01, BD02 (replica)
• Red: VLAN 100 (clínica)
• Backups: cada 5 minutos a repositorio externo
• SLA: 99.9% disponibilidad, respuesta <2 seg
• Soporte: Proveedor externo (contrato anual €150k)
• Documentación: Manual usuario v4.2, guía administrador, runbooks incidentes

3. Gestión de Versiones y Despliegues (Release and Deployment Management)

RELEASE = VERSIÓN de un servicio que se despliego en producción. Gestión de versiones coordina:

• Build: Compilar código (convertir código fuente en ejecutable)
• Test: Pruebas en entorno preproducción (igual a producción pero aislado)
• Deploy: Llevar versión a producción (instalación, configuración, migración datos)
• Rollback: Plan reversión si algo falla (revertir a versión anterior en minutos)

Ejemplo Release DIRAYA 4.1 → 4.2: Código nuevo compilado → Testear en preproducción 1 semana (buscar bugs) → Ejecutar cambio: parar DIRAYA 4.1, instalar 4.2, migrar datos → Validar: médicos acceden OK → Si falla: rollback a 4.1 en 15 minutos.

4. Gestión del Conocimiento (Knowledge Management)

Documentar TODO: Guías usuarios, manuales administrador, procedimientos incidentes (runbooks), arquitecturas, decisiones de diseño. Permite:

• Nuevos técnicos aprenden rápido (documentación centralizada)
• Evitar «autostop del servicio» cuando se va un experto (el saber está documentado)
• Auditoría (evidencias cómo se gestionó cada cambio/incidente)

7️⃣ Operación del Servicio: Incidentes, Problemas, Peticiones, Service Desk

Objetivo Operación

ENTREGAR SERVICIOS TI CONFORME A LOS ACUERDOS ESTABLECIDOS (SLAs), MANTENIENDO ESTABILIDAD Y DISPONIBILIDAD. Es la fase «día a día», donde usuarios interactúan con TI.

Procesos Clave en Operación del Servicio

1. Gestión de Incidentes (Incident Management) ⚡ CRÍTICA EXAMEN

¿QUÉ ES UN INCIDENTE? Interrupción NO PLANIFICADA de un servicio (o degradación calidad) que AFECTA a usuarios. Ejemplos:

• «No puedo acceder DIRAYA» → Incidente
• «DIRAYA va muy lento» → Incidente (degradación, aunque no caída total)
• «No funciona impresora de oncología» → Incidente
• «Recibí correo phishing» → Incidente de seguridad

¿QUÉ NO ES INCIDENTE?

• Cambio planificado (actualización DIRAYA sabado 2:00 AM) → NO incidente, es CAMBIO
• Petición de usuario («quiero acceso a aplicación X») → NO incidente, es PETICIÓN
• Problema estructural («DIRAYA se cuelga todas las semanas») → NO incidente individual, es PROBLEMA

OBJETIVO GESTIÓN INCIDENTES: RESTAURAR SERVICIO NORMAL LO ANTES POSIBLE, minimizando tiempo DOWN y impacto usuario. NO es «culpa TI o culpa usuario», es «volvamos a la normalidad YA».

PRIORIZACIÓN INCIDENTES (matriz Impact vs Urgencia):

Prioridad	Impacto (cuántas personas afectadas)	Urgencia (qué tan grave)	Tiempo Respuesta	Tiempo Resolución	Ejemplo SAS
P1 (CRÍTICA)	Múltiples usuarios/servicios críticos	Muy urgente (asistencia impedida)	< 30 minutos	< 4 horas	DIRAYA caído en hospital (no se pueden abrir historias)
P2 (ALTA)	Varios usuarios o un usuario crítico	Urgente	< 2 horas	< 8 horas	Servidor impresoras oncología lento
P3 (MEDIA)	Pocos usuarios	Moderada	< 8 horas	< 24 horas	Usuario no puede abrir correo (otros sí pueden)
P4 (BAJA)	1 usuario, impacto menor	Baja	< 24 horas	< 72 horas	Cambiar contraseña usuario

CICLO VIDA INCIDENTE (típico P1 DIRAYA):

1. DETECCIÓN (t=0 min): Médico llama Service Desk: «DIRAYA no abre». Service Desk abre TICKET incidente, prioridad P1.
2. RESPUESTA INMEDIATA (0-5 min): Técnico nivel 1 diagnostica: ¿es error usuario? ¿es servidor? Intenta soluciones básicas (reiniciar navegador, limpiar caché, verificar conectividad).
3. ESCALADO (5-15 min): Si nivel 1 no resuelve → escala a EQUIPO APLICACIÓN DIRAYA (nivel 2) o CPD si es problema infraestructura.
4. ANÁLISIS CAUSA (15-30 min): Técnico especializado revisa logs, monitorización: «El servidor BD01 no responde. Conexión red caída».
5. RESOLUCIÓN (30-60 min): Acciones correctivas: rebootear DB01, failover a BD02, validar recuperación datos. DIRAYA vuelve online.
6. COMUNICACIÓN (continuo): Service Desk actualiza ticket cada 15-30 min: «Estamos escalando… problema en BD… estimamos resolución 15 min… ¡RESUELTO!»
7. CIERRE (t=90 min): Ticket cierre. Service Desk confirma con usuario. Técnico crea PROBLEMA incidencia (para investigar por qué BD01 se desconectó).

2. Gestión de Problemas (Problem Management) 🔍 CRÍTICA EXAMEN

¿QUÉ ES UN PROBLEMA? CAUSA SUBYACENTE de uno o más incidentes (usualmente REPETITIVOS). Objetivo: ELIMINAR CAUSA RAÍZ para evitar incidentes futuros.

Diferencia Incidente vs Problema:

• INCIDENTE: «DIRAYA no abre hoy 10:30-11:15 AM» (síntoma, restauración rápida)
• PROBLEMA: «Servidor BD01 tiene puerto ethernet degradado (100 Mbps en lugar 1 Gbps) → timeout conexiones DB cada 2-3 días → incidentes recurrentes» (causa, solución permanente = cambiar puerto)

PROCESO PROBLEMA (RCA, Root Cause Analysis):

1. ANÁLISIS: Técnico especializado revisa incidentes similares (últimas 4 semanas: 7 caídas DIRAYA). ¿Patrón común?
2. BÚSQUEDA CAUSA RAÍZ (técnicas):
   • 5 Whys: «¿Por qué DIRAYA cae? → Timeout BD. ¿Por qué timeout? → Puerto lento. ¿Por qué lento? → Hardware envejecido. ¿Por qué no se cambió? → Desconocimiento. ¿Por qué no hay monitorización? → No presupuesto.»
   • Diagrama Ishikawa (espina de pescado): Analiza causas por categoría (Personas, Procesos, Infraestructura, Software)
   • Análisis logs/datos: Inspeccionar trazas sistema, métricas rendimiento, alertas monitorización
3. SOLUCIÓN: Cambiar puerto ethernet o switch que conecta BD01 a red
4. VALIDACIÓN: Post-cambio, 2 semanas sin incidentes DIRAYA relacionados → PROBLEMA RESUELTO

3. Gestión de Peticiones de Servicio (Request Fulfillment / Service Request Management)

¿QUÉ ES PETICIÓN? Solicitud de usuario de algo «rutinario» que NO es incidente ni cambio importante:

• «Quiero acceso a aplicación de análisis de costes»
• «Necesito aumentar cuota de almacenamiento»
• «Resetear contraseña»
• «Instalar software X (previamente aprobado)»

DIFERENCIA CON INCIDENTE: Petición es SOLICITADA por usuario. Incidente es PROBLEMA no solicitado. Petición sigue PROCESO PREDEFINIDO (puede estar automatizado). Gestión Peticiones asegura que solicitudes se atienden en tiempo SLA (ej: «acceso nuevo usuario en máximo 5 días hábiles»).

4. Service Desk (Función, No Proceso)

¿QUÉ ES SERVICE DESK? PUNTO ÚNICO DE CONTACTO entre USUARIOS y TI. Recibe incidentes, peticiones, preguntas. Funciones:

• Atender llamadas, emails, chat usuarios
• Registrar incidentes (abrir tickets)
• DIAGNOSTICAR problemas básicos (nivel 1: «reinicia equipo, borra caché»)
• ESCALAR a especialistas si necesario (nivel 2, nivel 3)
• ACTUALIZAR usuario sobre progreso
• CERRAR tickets con feedback usuario («¿está resuelto? ¿satisfecho?»)

En el SAS: Service Desk central es ayudaDIGITAL (teléfono, email, chat corporativo). Maneja miles de tickets mes. Herramienta: BMC Remedy (plataforma ITSM que registra, prioriza, escala incidentes/peticiones/problemas).

NIVELES SOPORTE (típicos):

• Nivel 1 (Service Desk): Contacto inicial, diagnostico básico, soluciones comunes
• Nivel 2 (Especialistas): Técnicos aplicaciones, infraestructura, comunicaciones. Casos complejos
• Nivel 3 (Proveedores/Expertos): Fabricantes software, consultoras especializadas. Problemas críticos/específicos

8️⃣ Mejora Continua del Servicio (CSI): Ciclo PDCA, Métricas, KPIs

Objetivo CSI

ANALIZAR DATOS DE OPERACIÓN (incidentes, disponibilidad, costes, satisfacción usuario) PARA IDENTIFICAR E IMPLEMENTAR MEJORAS INCREMENTALES A LO LARGO DEL CICLO DE VIDA.

Ciclo PDCA (Deming) en CSI

• PLAN (Planificar): Definir QUÉ medir (KPIs), DÓNDE recolectar datos, QUIÉN responsable
• DO (Ejecutar): Recolectar datos operacionales (incidentes, disponibilidad, tiempos respuesta, costes)
• CHECK (Verificar): Analizar: ¿disponibilidad DIRAYA realmente 99.9%? ¿Incidentes en aumento o descenso? ¿SLAs cumplidos?
• ACT (Actuar): Proponer mejoras basadas en análisis (p.ej.: «si disponibilidad DIRAYA 98.5% en lugar 99.9%, rediseñar CPD con más redundancia»)

Modelo 7 Pasos CSI

1. Definir QUÉ MEDIR: KPIs relevantes (disponibilidad, tiempo respuesta, MTTR, MTBF, satisfacción usuario)
2. RECOLECTAR DATOS: Herramientas monitorización, ITSM (BMC Remedy), logs sistemas
3. PROCESAR DATOS: Transformar datos brutos en métricas (p.ej.: logs → «disponibilidad DIRAYA 99.87% en octubre»)
4. ANALIZAR: Tendencias, comparaciones vs SLA, correlaciones (p.ej.: «caídas DIRAYA correlacionan con cambios en horarios pico»)
5. PRESENTAR: Reportes ejecutivos, dashboards. Comunicar hallazgos a liderazgo, usuarios, equipo TI
6. IMPLEMENTAR ACCIONES CORRECTIVAS: Sobre base hallazgos (p.ej.: «aumentar capacidad servidor APP01»)
7. REVISAR & MONITORIZAR: Validar que mejoras funcionan. Volver a Paso 1 (ciclo continuo)

Métricas/KPIs Típicos ITIL

Métrica	Definición	Ejemplo SAS
Disponibilidad	% tiempo servicio está UP / tiempo total	DIRAYA: (730 horas – 2 horas DOWN) / 730 = 99.73%
MTBF (Mean Time Between Failures)	Tiempo promedio entre incidentes	DIRAYA: falla cada 15 días en promedio
MTTR (Mean Time To Recover)	Tiempo promedio para resolver incidente desde detección	DIRAYA: 47 minutos promedio
SLA Compliance	% incidentes resueltos dentro SLA	P1: 95% resueltos <4h, P2: 92% resueltos <8h
Customer Satisfaction (CSAT)	Encuesta post-incidente: «¿satisfecho?» (1-5 puntos)	DIRAYA: CSAT 4.2/5 promedio
Coste por incidente	Gasto total TI / número incidentes	€5k por incidente P1 en promedio

9️⃣ Certificaciones: ITIL vs ISO 20000 vs COBIT vs ISO 27001

ITIL (Buenas Prácticas, NO Certificable Organización)

ITIL es publicaciones + formación/certificación PERSONAL:

• ITIL Foundation: Nivel entrada, conceptos generales. Examen de opción múltiple (40 preguntas, necesita 65% aciertos).
• ITIL Intermediate (niveles intermedios): Especialización en fases (Lifecycle pathway) o prácticas específicas (practitioner pathway). Requiere Foundation previo.
• ITIL Expert: Nivel superior, integrando múltiples intermedios. Permite «ITIL Master».
• ITIL 4 Certification Path: Foundation → Intermediate (5 módulos) → Expert → Master.

¿QUÉ CERTIFICA ITIL? Personas (profesionales TI) que entienden buenas prácticas, no organizaciones. Es «credencial de CV».

ISO/IEC 20000 (CERTIFICABLE ORGANIZACIÓN) 🏆 CRÍTICA PARA SAS

ISO 20000 es NORMA DE SISTEMAS DE GESTIÓN certificable para ORGANIZACIONES, que define requisitos formales para un SISTEMA DE GESTIÓN DE SERVICIOS TI (SGSTI). En el contexto público sanitario, es evidencia de profesionalismo.

ISO 20000-1 (Certificable): Requisitos para SGSTI. Define procesos, responsabilidades, documentación, métricas que una organización DEBE cumplir:

• Planificación e implementación servicio (incluye seguridad, continuidad)
• Provisión de servicios (incidentes, problemas, cambios)
• Monitorización y evaluación de servicios
• Mejora del servicio (análisis, acciones correctivas)

ISO 20000-2 (Guía, NO Certificable): Orientaciones cómo implementar ISO 20000-1 en diferentes contextos organizacionales.

¿QUÉ CERTIFICA ISO 20000? Organizaciones (SAS, un hospital, una consultora TI) que demuestran auditando que su SGSTI cumple norma. Auditoria EXTERNA cada año (para mantener certificación).

COBIT (Gobernanza TI, NO Certificable Organización)

COBIT: Framework (no norma) para GOBERNANZA TI + Gestión TI. Complementa ITIL enfocándose en CONTROL, RIESGO, CUMPLIMIENTO NORMATIVO.

• COBIT enfoque: «¿Están alineados objetivos TI con negocio? ¿Tenemos controles suficientes contra fraude/riesgos? ¿Cumplimos regulaciones?»
• ITIL enfoque: «¿Ofrecemos servicios de calidad? ¿Gestionamos incidentes? ¿Mejoramos continuamente?»

En organizaciones maduras, COBIT + ITIL + ISO 27001 se integran en un sistema de gobierno TI holístico.

ISO/IEC 27001 (Seguridad Información, CERTIFICABLE)

ISO 27001: Norma para SISTEMAS DE GESTIÓN DE SEGURIDAD DE LA INFORMACIÓN (SGSI). En sanidad pública, es CRÍTICA (datos clínicos protegidos por RGPD, LOPDGDD, ENS nivel ALTO).

• Control acceso (quién puede acceder DIRAYA)
• Encriptación (datos clínicos en tránsito/reposo)
• Gestión incidentes seguridad (ej: ataque cibernético, fuga datos)
• Planes continuidad ante ataque cibernético

Relación con ITIL: ITIL incluye Gestión Seguridad en fase Diseño. ISO 27001 es norma especializada que detalla cómo implementar seguridad. Típicamente organizaciones sanitarias adoptan ITIL + ISO 20000 + ISO 27001 en conjunto.

🔟 Implementación en el SAS: Herramientas, Normativa, Casos Reales

Herramientas ITSM en el SAS

1. BMC Remedy (Plataforma ITSM)

BMC Remedy: Plataforma integrada para gestionar INCIDENTES, PROBLEMAS, CAMBIOS, PETICIONES en el SAS. Registra todo en base de datos centralizada (similar a CMDB). Permite:

• Abrir tickets incidente (Service Desk atiende llamada → abre ticket)
• Priorizar automáticamente (matrix Impact/Urgencia)
• Asignar a equipos especialistas (escalado automático)
• Monitorizar SLA (alerta si ticket cerca vencer SLA)
• Reportes: tendencias incidentes, disponibilidad, satisfacción usuario

DIRECTA EXAMEN: Pregunta: «¿Qué herramienta gestiona incidentes en SAS?» Respuesta: BMC Remedy (o similares como ServiceNow, que algunas CCAA usan).

2. ayudaDIGITAL (Service Desk SAS)

ayudaDIGITAL: Servicio de soporte TI central SAS. Usuarios contactan via teléfono, email, chat cuando tienen problemas TI. ayudaDIGITAL registra en BMC Remedy, diagnostica, escala a especialistas CPD si necesario. Objetivos:

• Punto único contacto para problemas TI
• Diagnostico rápido nivel 1 (usuario reinicia, borra caché, verifica conectividad)
• Escalado si es nivel 2/3
• Comunicación proactiva («estamos trabajando… estimamos resolución X»)

3. Herramientas Monitorización (Zabbix, Nagios, Datadog, etc.)

Monitorización: Sistemas que vigilan infraestructura 24/7 y alertan si algo falla ANTES que usuarios lo noten (proactivo). Ejemplos métricas monitorizadas:

• CPU servidor DIRAYA > 80% → alerta
• Memoria BD01 < 500 MB libre → alerta
• Conexión red DB switch caída → alerta + Page técnico on-call
• Backup DIRAYA falla → alerta

BENEFICIO: Muchos incidentes se PREVIENEN (técnico actúa antes que falle servicio). Si falla, monitorización ayuda diagnosticar causa rápidamente (logs trazabilidad).

Normativa Aplicable SGSTI en SAS

Normativa	Aplicación en SAS	Relación ITIL
Ley 39/2015 (Procedimiento Administrativo)	Plazos respuesta, trazabilidad decisiones administrativas	Gestión documentación, auditoría
RD 311/2022 (ENS, Esquema Nacional Seguridad)	Requisitos seguridad TI nivel ALTO para organización crítica (sanidad)	Incidentes seguridad, planes continuidad, gestión acceso
RGPD + LOPDGDD	Protección datos clínicos, consentimiento, derecho olvido	Gestión acceso, encriptación, auditoría, incidentes seguridad
ISO/IEC 27001	SGSI (Sistema Gestión Seguridad Información)	Gestión seguridad fase Diseño, incidentes seguridad fase Operación
ISO/IEC 20000	SGSTI (Sistema Gestión Servicios TI), certificación opcional SAS	FRAMEWORK completo, todos procesos ITIL formalizados

Casos Reales SAS: DIRAYA

DIRAYA (Directorio Integrado de Atención Sanitaria de Andalucía) es servicio CRÍTICO SAS: Historia clínica electrónica, +2 millones pacientes, acceso diario +500k usuarios (médicos, enfermeras, administrativos).

¿Cómo ITIL aplica a DIRAYA?

• ESTRATEGIA: SAS decide: «DIRAYA debe estar disponible 99.9% (máximo 43 minutos caída/mes)». Justificación: si DIRAYA no funciona, asistencia se paraliza (histórico papel insuficiente).
• DISEÑO: Arquitectura DIRAYA: 2 CPDs redundantes (activo-activo), BD replicada, balanceo carga, failover automático, backups cada 5 minutos. SLA 99.9%, RTO 15 minutos, RPO 0 (cero datos perdidos).
• TRANSICIÓN: Actualización DIRAYA 4.1 → 4.2. RFC abierto por equipo desarrollo, CAB aprueba (riesgo bajo porque cambio bien testado), se ejecuta sábado noche, validación domingo mañana, usuarios acceden lunes sin problema.
• OPERACIÓN: Usuario de urgencias intenta abrir historia paciente, no responde. Llama ayudaDIGITAL (ticket P1), diagnostico rápido: «Conectividad urgencias-CPD caída». CPD reinicia switch red → conexión restaurada (5 minutos). Ticket cierre. Problema abierto para investigar por qué switch no tiene redundancia.
• CSI: Análisis últimas 3 meses: DIRAYA 99.5% (por debajo 99.9%). Causas: 4 caídas por conectividad, 2 por capacidad BD. Propuesta CSI: «Diseño nueva red con redundancia, aumentar CPUS BD». Aprobado presupuesto → Transición nueva arquitectura → Disponibilidad sube a 99.95%.

1️⃣1️⃣ Preguntas tipo SSPA y Cuestionario Autoevaluación (≥25)