ITIL 4 - Key Practices
Curso ITIL 4 orientado a 'ITIL 4 - Practicas Clave', con foco en prácticas, flujos de valor, experiencia y decisiones operativas.
El curso 'ITIL 4 - Practicas Clave' se ha redactado para que el alumno vea cómo ITIL 4 se aterriza en trabajo real: soporte, gobierno, value streams, experiencia y mejora.
Modulo 01. Marco de practicas ITIL y criterios de priorizacion
Objetivo del modulo
Entender con precisión qué cubre 'Marco de practicas ITIL y criterios de priorizacion', para qué sirve dentro de ITIL 4 y cómo se aplica en la operación y mejora de servicios reales.
Desarrollo teorico
El bloque 'Marco de practicas ITIL y criterios de priorizacion' se estudia desde una perspectiva operativa de ITIL 4: definición precisa, propósito, relación con otras prácticas y ejemplo de aplicación en un servicio real.
'Marco de practicas ITIL y criterios de priorizacion' debe entenderse por su propósito y no solo por su nombre. En ITIL 4 siempre conviene identificar entradas, salidas y responsables. La práctica o capacidad se valora por su contribución al valor y a la experiencia. El diseño excesivamente burocrático suele restar eficacia operativa. Un ejemplo de servicio real ayuda a fijar el concepto y detectar límites.
Tabla de referencia
| Aspecto | Descripción |
|---|---|
| Propósito | Por qué existe el bloque |
| Uso | Cómo aparece en un servicio real |
| Riesgo | Qué falla si se aplica mal |
Procedimiento recomendado
- Definir propósito
- Relacionar con un servicio real
- Identificar métricas
- Revisar errores comunes
Escenario realista
Ejemplo aplicado: En un servicio corporativo, 'Marco de practicas ITIL y criterios de priorizacion' aporta decisiones y controles que deben verse en la operación diaria, no solo en documentación. La utilidad del ejemplo es que obliga a mirar el concepto no como teoría abstracta, sino como decisión operativa con consecuencias sobre soporte, riesgo, experiencia de usuario y gobierno.
Métrica o evidencia útil
Evidencia de uso real del concepto dentro del servicio.
Artefacto recomendado
Documento breve que aterrice 'Marco de practicas ITIL y criterios de priorizacion' a un servicio concreto.
Contenido ampliado
Este módulo se relaciona con el resto del curso 'ITIL 4 - Practicas Clave' porque aporta lenguaje, decisiones y criterios operativos que reaparecen en prácticas, flujos de valor y escenarios de examen o implantación.
Puntos clave
- 'Marco de practicas ITIL y criterios de priorizacion' debe entenderse por su propósito y no solo por su nombre.
- En ITIL 4 siempre conviene identificar entradas, salidas y responsables.
- La práctica o capacidad se valora por su contribución al valor y a la experiencia.
- El diseño excesivamente burocrático suele restar eficacia operativa.
Checklist operativa
- Definir propósito
- Relacionar con un servicio real
- Identificar métricas
- Revisar errores comunes
Errores frecuentes
- Usarlo como término decorativo sin cambiar ninguna decisión operativa.
- Confundir el propósito del módulo con tareas administrativas o burocráticas.
- No validar el concepto con un ejemplo de servicio reconocible.
Practica sugerida
Documento breve que aterrice 'Marco de practicas ITIL y criterios de priorizacion' a un servicio concreto.
Preguntas de autoevaluacion
- ¿Qué se debe exigir al aplicar este bloque en un servicio real?
- ¿Cuál es un error frecuente en este bloque?
Cierre
Si al terminar puedes explicar Marco de practicas ITIL y criterios de priorizacion usando un ejemplo de servicio real, nombrar sus elementos esenciales y relacionarlo con otras prácticas de ITIL 4, el módulo ya te habrá dado una base aplicable y no solo vocabulario.
Modulo 02. Incident management y request management
Objetivo del modulo
Entender con precisión qué cubre 'Incident management y request management', para qué sirve dentro de ITIL 4 y cómo se aplica en la operación y mejora de servicios reales.
Desarrollo teorico
Incident management persigue restaurar el servicio lo antes posible cuando la calidad se degrada o se interrumpe. Request management se ocupa de peticiones predefinidas y repetibles, como accesos, altas o pequeñas solicitudes estándar. La diferencia importa porque mezclar ambos flujos de trabajo distorsiona prioridades, SLAs y capacidad del service desk.
Un incidente es una interrupción no planificada o reducción de calidad; una request es una solicitud prevista y normalmente de bajo riesgo. Incident management prioriza impacto y urgencia para restaurar servicio; request management optimiza cumplimiento y experiencia en solicitudes frecuentes. Las peticiones estándar deben tener modelos de atención, aprobaciones y tiempos predefinidos. El service desk suele ser el punto de entrada de ambos tipos, pero la gestión posterior cambia. Métricas comunes son MTTR para incidentes y tiempo de cumplimiento para requests.
Tabla de referencia
| Aspecto | Incident | Request |
|---|---|---|
| Propósito | Restaurar servicio | Entregar una solicitud estándar |
| Ejemplo | Caída de VPN | Alta en grupo de correo |
| Métrica | MTTR | Fulfilment time |
Procedimiento recomendado
- Registrar y clasificar correctamente
- Determinar prioridad o modelo de request
- Asignar al flujo adecuado
- Comunicar estado y cerrar con validación
Escenario realista
Ejemplo aplicado: Un usuario llama porque no puede conectarse a la VPN: incidente. Otro pide acceso a una carpeta de proyecto: request. Ambos entran por el service desk, pero no deben tratarse con la misma cola ni los mismos objetivos. La utilidad del ejemplo es que obliga a mirar el concepto no como teoría abstracta, sino como decisión operativa con consecuencias sobre soporte, riesgo, experiencia de usuario y gobierno.
Métrica o evidencia útil
MTTR de incidentes críticos y tiempo medio de cumplimiento de solicitudes estándar.
Artefacto recomendado
Matriz de decisión para distinguir incidentes de requests en primera línea.
Contenido ampliado
Este módulo se relaciona con el resto del curso 'ITIL 4 - Practicas Clave' porque aporta lenguaje, decisiones y criterios operativos que reaparecen en prácticas, flujos de valor y escenarios de examen o implantación.
Puntos clave
- Un incidente es una interrupción no planificada o reducción de calidad; una request es una solicitud prevista y normalmente de bajo riesgo.
- Incident management prioriza impacto y urgencia para restaurar servicio; request management optimiza cumplimiento y experiencia en solicitudes frecuentes.
- Las peticiones estándar deben tener modelos de atención, aprobaciones y tiempos predefinidos.
- El service desk suele ser el punto de entrada de ambos tipos, pero la gestión posterior cambia.
Checklist operativa
- Registrar y clasificar correctamente
- Determinar prioridad o modelo de request
- Asignar al flujo adecuado
- Comunicar estado y cerrar con validación
Errores frecuentes
- Cerrar peticiones estándar como incidentes porque el canal de entrada es el mismo.
- Confundir el propósito del módulo con tareas administrativas o burocráticas.
- No validar el concepto con un ejemplo de servicio reconocible.
Practica sugerida
Matriz de decisión para distinguir incidentes de requests en primera línea.
Preguntas de autoevaluacion
- ¿Qué diferencia principal separa un incidente de una request en ITIL 4?
- ¿Qué métrica encaja mejor con service request management?
Cierre
Si al terminar puedes explicar Incident management y request management usando un ejemplo de servicio real, nombrar sus elementos esenciales y relacionarlo con otras prácticas de ITIL 4, el módulo ya te habrá dado una base aplicable y no solo vocabulario.
Modulo 03. Problem management y aprendizaje operativo
Objetivo del modulo
Entender con precisión qué cubre 'Problem management y aprendizaje operativo', para qué sirve dentro de ITIL 4 y cómo se aplica en la operación y mejora de servicios reales.
Desarrollo teorico
Problem management busca reducir la probabilidad y el impacto de incidentes identificando causas raíz, errores conocidos y acciones preventivas. No sustituye a incident management: lo complementa cuando la organización necesita dejar de repetir las mismas incidencias.
Se activa ante incidentes graves o recurrentes. Diferencia problema, known error y workaround. Puede trabajar de forma reactiva o proactiva. Necesita datos de incidentes, cambios, eventos y configuración. Su éxito se mide por reducción de recurrencia y tiempo perdido.
Tabla de referencia
| Término | Descripción | Ejemplo |
|---|---|---|
| Problem | Causa o posible causa desconocida | VPN cae cada lunes |
| Known error | Causa raíz documentada | Bug de versión identificado |
| Workaround | Solución temporal | Reiniciar servicio específico |
Procedimiento recomendado
- Detectar patrón o incidente mayor
- Abrir registro de problema
- Analizar causa raíz
- Definir workaround y corrección permanente
Escenario realista
Ejemplo aplicado: Cada lunes a las 8:00 la VPN se degrada. Incident management restaura, pero problem management revisa logs, capacidad y cambios del fin de semana hasta encontrar que un script reinicia de forma incorrecta un componente de autenticación. La utilidad del ejemplo es que obliga a mirar el concepto no como teoría abstracta, sino como decisión operativa con consecuencias sobre soporte, riesgo, experiencia de usuario y gobierno.
Métrica o evidencia útil
Número de incidentes recurrentes eliminados por trimestre.
Artefacto recomendado
Registro de problema con causa raíz, workaround y acción permanente.
Contenido ampliado
Este módulo se relaciona con el resto del curso 'ITIL 4 - Practicas Clave' porque aporta lenguaje, decisiones y criterios operativos que reaparecen en prácticas, flujos de valor y escenarios de examen o implantación.
Puntos clave
- Se activa ante incidentes graves o recurrentes.
- Diferencia problema, known error y workaround.
- Puede trabajar de forma reactiva o proactiva.
- Necesita datos de incidentes, cambios, eventos y configuración.
Checklist operativa
- Detectar patrón o incidente mayor
- Abrir registro de problema
- Analizar causa raíz
- Definir workaround y corrección permanente
Errores frecuentes
- Tratar problem management como un mero informe posterior sin acciones preventivas.
- Confundir el propósito del módulo con tareas administrativas o burocráticas.
- No validar el concepto con un ejemplo de servicio reconocible.
Practica sugerida
Registro de problema con causa raíz, workaround y acción permanente.
Preguntas de autoevaluacion
- ¿Cuál es el objetivo principal de problem management?
- ¿Qué es un known error?
Cierre
Si al terminar puedes explicar Problem management y aprendizaje operativo usando un ejemplo de servicio real, nombrar sus elementos esenciales y relacionarlo con otras prácticas de ITIL 4, el módulo ya te habrá dado una base aplicable y no solo vocabulario.
Modulo 04. Change enablement y control del riesgo
Objetivo del modulo
Entender con precisión qué cubre 'Change enablement y control del riesgo', para qué sirve dentro de ITIL 4 y cómo se aplica en la operación y mejora de servicios reales.
Desarrollo teorico
Change enablement garantiza que los cambios se valoren y autoricen con un nivel de control proporcional a su riesgo. El objetivo no es ralentizar, sino permitir cambios útiles con menos fallos y con visibilidad de impacto.
Clasifica cambios estándar, normales y de emergencia. Valora riesgo, impacto, ventanas y capacidad de rollback. No todos los cambios pasan por el mismo nivel de aprobación. Se apoya en configuración, testing, release y despliegue. La tasa de cambios fallidos es una métrica crítica.
Tabla de referencia
| Tipo | Riesgo | Tratamiento |
|---|---|---|
| Estándar | Bajo y repetible | Preautorizado |
| Normal | Variable | Evaluación y autorización |
| Emergencia | Alto pero urgente | Ruta acelerada y revisión posterior |
Procedimiento recomendado
- Clasificar tipo de cambio
- Evaluar riesgo e impacto
- Autorizar según modelo
- Implementar y revisar resultado
Escenario realista
Ejemplo aplicado: Actualizar certificados de un balanceador puede ser un cambio estándar si está modelado y probado; rediseñar rutas entre sedes exige evaluación más formal por su impacto en múltiples servicios. La utilidad del ejemplo es que obliga a mirar el concepto no como teoría abstracta, sino como decisión operativa con consecuencias sobre soporte, riesgo, experiencia de usuario y gobierno.
Métrica o evidencia útil
Porcentaje de cambios exitosos sin rollback ni incidente mayor asociado.
Artefacto recomendado
Modelo de evaluación de riesgo de cambios.
Contenido ampliado
Este módulo se relaciona con el resto del curso 'ITIL 4 - Practicas Clave' porque aporta lenguaje, decisiones y criterios operativos que reaparecen en prácticas, flujos de valor y escenarios de examen o implantación.
Puntos clave
- Clasifica cambios estándar, normales y de emergencia.
- Valora riesgo, impacto, ventanas y capacidad de rollback.
- No todos los cambios pasan por el mismo nivel de aprobación.
- Se apoya en configuración, testing, release y despliegue.
Checklist operativa
- Clasificar tipo de cambio
- Evaluar riesgo e impacto
- Autorizar según modelo
- Implementar y revisar resultado
Errores frecuentes
- Meter todos los cambios en un mismo circuito burocrático, incluyendo los estándar.
- Confundir el propósito del módulo con tareas administrativas o burocráticas.
- No validar el concepto con un ejemplo de servicio reconocible.
Practica sugerida
Modelo de evaluación de riesgo de cambios.
Preguntas de autoevaluacion
- ¿Cuál es la finalidad principal de change enablement?
- ¿Qué caracteriza a un cambio estándar?
Cierre
Si al terminar puedes explicar Change enablement y control del riesgo usando un ejemplo de servicio real, nombrar sus elementos esenciales y relacionarlo con otras prácticas de ITIL 4, el módulo ya te habrá dado una base aplicable y no solo vocabulario.
Modulo 05. Service desk y experiencia del usuario
Objetivo del modulo
Entender con precisión qué cubre 'Service desk y experiencia del usuario', para qué sirve dentro de ITIL 4 y cómo se aplica en la operación y mejora de servicios reales.
Desarrollo teorico
Service desk es la práctica que gestiona la demanda entrante y la experiencia diaria del usuario. Su valor no está solo en abrir tickets, sino en resolver, comunicar, enrutar correctamente y representar la percepción del consumidor frente al resto de la organización.
Actúa como single point of contact. Combina capacidades humanas, canales y conocimiento. Debe equilibrar resolución en primer nivel, experiencia de usuario y eficiencia. Es una fuente valiosa de feedback operativo. Sus métricas incluyen FCR, satisfacción y tiempo de respuesta.
Tabla de referencia
| Elemento | Importancia |
|---|---|
| SPOC | Evita dispersión de canales |
| FCR | Mide resolución en primer contacto |
| Knowledge | Acelera diagnóstico y autoservicio |
Procedimiento recomendado
- Recibir contacto
- Clasificar y resolver si es posible
- Escalar con contexto completo
- Comunicar seguimiento y cierre
Escenario realista
Ejemplo aplicado: Un service desk maduro no se limita a reenviar incidencias de Teams; usa categorías correctas, artículos de conocimiento y comunicación proactiva para reducir fricción y evitar contactos repetidos. La utilidad del ejemplo es que obliga a mirar el concepto no como teoría abstracta, sino como decisión operativa con consecuencias sobre soporte, riesgo, experiencia de usuario y gobierno.
Métrica o evidencia útil
First Contact Resolution y satisfacción del usuario.
Artefacto recomendado
Matriz de canales, colas y criterios de escalado.
Contenido ampliado
Este módulo se relaciona con el resto del curso 'ITIL 4 - Practicas Clave' porque aporta lenguaje, decisiones y criterios operativos que reaparecen en prácticas, flujos de valor y escenarios de examen o implantación.
Puntos clave
- Actúa como single point of contact.
- Combina capacidades humanas, canales y conocimiento.
- Debe equilibrar resolución en primer nivel, experiencia de usuario y eficiencia.
- Es una fuente valiosa de feedback operativo.
Checklist operativa
- Recibir contacto
- Clasificar y resolver si es posible
- Escalar con contexto completo
- Comunicar seguimiento y cierre
Errores frecuentes
- Medir solo volumen cerrado sin mirar calidad, recontactos o experiencia.
- Confundir el propósito del módulo con tareas administrativas o burocráticas.
- No validar el concepto con un ejemplo de servicio reconocible.
Practica sugerida
Matriz de canales, colas y criterios de escalado.
Preguntas de autoevaluacion
- ¿Qué papel define mejor al service desk?
- ¿Qué métrica se asocia especialmente al service desk?
Cierre
Si al terminar puedes explicar Service desk y experiencia del usuario usando un ejemplo de servicio real, nombrar sus elementos esenciales y relacionarlo con otras prácticas de ITIL 4, el módulo ya te habrá dado una base aplicable y no solo vocabulario.
Modulo 06. Knowledge management y autoservicio
Objetivo del modulo
Entender con precisión qué cubre 'Knowledge management y autoservicio', para qué sirve dentro de ITIL 4 y cómo se aplica en la operación y mejora de servicios reales.
Desarrollo teorico
Knowledge management garantiza que la información útil esté disponible, sea confiable y se reutilice en el momento adecuado. No consiste en acumular artículos; consiste en mejorar decisiones, autoservicio y velocidad de resolución.
Convierte información dispersa en conocimiento reutilizable. Debe integrar creación, revisión, publicación y retirada. Alimenta service desk, autoservicio, cambios y operación. La calidad importa más que el volumen de artículos. Un artículo obsoleto puede degradar soporte y confianza.
Tabla de referencia
| Aspecto | Mala práctica | Buena práctica |
|---|---|---|
| Creación | Escribir por obligación | Documentar soluciones repetibles |
| Revisión | Nunca caducar | Revisar por dueño y fecha |
| Uso | Sin feedback | Medir reutilización y utilidad |
Procedimiento recomendado
- Detectar necesidad de conocimiento
- Redactar con estructura clara
- Validar técnicamente
- Publicar y revisar ciclo de vida
Escenario realista
Ejemplo aplicado: Tras varias incidencias de restablecimiento MFA, el equipo crea un artículo con pasos validados, capturas y criterios de escalado. El service desk resuelve más rápido y el portal de autoservicio absorbe parte de la demanda. La utilidad del ejemplo es que obliga a mirar el concepto no como teoría abstracta, sino como decisión operativa con consecuencias sobre soporte, riesgo, experiencia de usuario y gobierno.
Métrica o evidencia útil
Porcentaje de resoluciones asistidas por artículos reutilizados.
Artefacto recomendado
Plantilla de artículo de conocimiento con dueño, alcance y fecha de revisión.
Contenido ampliado
Este módulo se relaciona con el resto del curso 'ITIL 4 - Practicas Clave' porque aporta lenguaje, decisiones y criterios operativos que reaparecen en prácticas, flujos de valor y escenarios de examen o implantación.
Puntos clave
- Convierte información dispersa en conocimiento reutilizable.
- Debe integrar creación, revisión, publicación y retirada.
- Alimenta service desk, autoservicio, cambios y operación.
- La calidad importa más que el volumen de artículos.
Checklist operativa
- Detectar necesidad de conocimiento
- Redactar con estructura clara
- Validar técnicamente
- Publicar y revisar ciclo de vida
Errores frecuentes
- Medir éxito por número de artículos publicados aunque nadie los use.
- Confundir el propósito del módulo con tareas administrativas o burocráticas.
- No validar el concepto con un ejemplo de servicio reconocible.
Practica sugerida
Plantilla de artículo de conocimiento con dueño, alcance y fecha de revisión.
Preguntas de autoevaluacion
- ¿Qué objetivo principal tiene knowledge management?
- ¿Qué indicador ayuda a saber si el conocimiento aporta valor?
Cierre
Si al terminar puedes explicar Knowledge management y autoservicio usando un ejemplo de servicio real, nombrar sus elementos esenciales y relacionarlo con otras prácticas de ITIL 4, el módulo ya te habrá dado una base aplicable y no solo vocabulario.
Modulo 07. Monitoring and event management
Objetivo del modulo
Entender con precisión qué cubre 'Monitoring and event management', para qué sirve dentro de ITIL 4 y cómo se aplica en la operación y mejora de servicios reales.
Desarrollo teorico
Monitoring and event management observa servicios y componentes para detectar cambios de estado significativos. La práctica transforma señales en eventos útiles y evita que soporte trabaje a ciegas o reaccione solo cuando el usuario ya sufre el impacto.
Distingue entre monitorización, evento, alerta y respuesta. No todo evento merece acción humana. La calidad de umbrales y correlación reduce ruido. Se relaciona estrechamente con incidentes, capacidad y disponibilidad. La observabilidad madura combina métricas, logs y trazas.
Tabla de referencia
| Concepto | Descripción |
|---|---|
| Evento | Cambio de estado significativo |
| Alerta | Notificación que requiere atención |
| Ruido | Señal sin valor operativo suficiente |
Procedimiento recomendado
- Definir qué condiciones deben observarse
- Crear umbrales y reglas de correlación
- Dirigir eventos a respuesta automática o humana
- Revisar falsos positivos y cobertura
Escenario realista
Ejemplo aplicado: Un incremento de latencia en VPN se detecta antes de una caída total. Si los eventos se correlacionan bien, el equipo actúa antes de que cientos de usuarios abran incidencias. La utilidad del ejemplo es que obliga a mirar el concepto no como teoría abstracta, sino como decisión operativa con consecuencias sobre soporte, riesgo, experiencia de usuario y gobierno.
Métrica o evidencia útil
Porcentaje de incidentes detectados antes de que el usuario los reporte.
Artefacto recomendado
Catálogo de eventos con umbrales y acciones asociadas.
Contenido ampliado
Este módulo se relaciona con el resto del curso 'ITIL 4 - Practicas Clave' porque aporta lenguaje, decisiones y criterios operativos que reaparecen en prácticas, flujos de valor y escenarios de examen o implantación.
Puntos clave
- Distingue entre monitorización, evento, alerta y respuesta.
- No todo evento merece acción humana.
- La calidad de umbrales y correlación reduce ruido.
- Se relaciona estrechamente con incidentes, capacidad y disponibilidad.
Checklist operativa
- Definir qué condiciones deben observarse
- Crear umbrales y reglas de correlación
- Dirigir eventos a respuesta automática o humana
- Revisar falsos positivos y cobertura
Errores frecuentes
- Generar miles de alertas sin priorización ni correlación.
- Confundir el propósito del módulo con tareas administrativas o burocráticas.
- No validar el concepto con un ejemplo de servicio reconocible.
Practica sugerida
Catálogo de eventos con umbrales y acciones asociadas.
Preguntas de autoevaluacion
- ¿Qué valor principal aporta monitoring and event management?
- ¿Cuál es un síntoma de mala monitorización?
Cierre
Si al terminar puedes explicar Monitoring and event management usando un ejemplo de servicio real, nombrar sus elementos esenciales y relacionarlo con otras prácticas de ITIL 4, el módulo ya te habrá dado una base aplicable y no solo vocabulario.
Modulo 08. Service configuration management
Objetivo del modulo
Entender con precisión qué cubre 'Service configuration management', para qué sirve dentro de ITIL 4 y cómo se aplica en la operación y mejora de servicios reales.
Desarrollo teorico
Service configuration management mantiene información fiable sobre elementos de configuración y sus relaciones para apoyar impacto, cambios, soporte y análisis. Su valor depende de la calidad y del uso, no de tener una CMDB enorme sin propósito.
Un CI no es exactamente lo mismo que un activo financiero. Lo importante son las relaciones útiles para operar y analizar impacto. La calidad de datos debe ser suficiente para el caso de uso, no perfecta en teoría. Cambios, incidentes y problemas se benefician de relaciones fiables. La reconciliación de fuentes evita duplicados y contradicciones.
Tabla de referencia
| Elemento | Rol |
|---|---|
| CI | Representa parte relevante de un servicio |
| Relación | Explica dependencia o impacto |
| CMDB | Repositorio de información de configuración |
Procedimiento recomendado
- Definir alcance de CIs
- Capturar relaciones útiles
- Acordar fuentes de verdad
- Revisar calidad para casos de uso concretos
Escenario realista
Ejemplo aplicado: Si una aplicación depende de una base de datos y de un balanceador, conocer esas relaciones permite evaluar mejor el impacto de un cambio o de un incidente en uno de esos componentes. La utilidad del ejemplo es que obliga a mirar el concepto no como teoría abstracta, sino como decisión operativa con consecuencias sobre soporte, riesgo, experiencia de usuario y gobierno.
Métrica o evidencia útil
Porcentaje de cambios evaluados con información de configuración útil.
Artefacto recomendado
Modelo mínimo de CI y relaciones para un servicio crítico.
Contenido ampliado
Este módulo se relaciona con el resto del curso 'ITIL 4 - Practicas Clave' porque aporta lenguaje, decisiones y criterios operativos que reaparecen en prácticas, flujos de valor y escenarios de examen o implantación.
Puntos clave
- Un CI no es exactamente lo mismo que un activo financiero.
- Lo importante son las relaciones útiles para operar y analizar impacto.
- La calidad de datos debe ser suficiente para el caso de uso, no perfecta en teoría.
- Cambios, incidentes y problemas se benefician de relaciones fiables.
Checklist operativa
- Definir alcance de CIs
- Capturar relaciones útiles
- Acordar fuentes de verdad
- Revisar calidad para casos de uso concretos
Errores frecuentes
- Intentar modelarlo todo desde el primer día sin un caso de uso claro.
- Confundir el propósito del módulo con tareas administrativas o burocráticas.
- No validar el concepto con un ejemplo de servicio reconocible.
Practica sugerida
Modelo mínimo de CI y relaciones para un servicio crítico.
Preguntas de autoevaluacion
- ¿Qué persigue service configuration management?
- ¿Qué afirmación es correcta sobre un CI?
Cierre
Si al terminar puedes explicar Service configuration management usando un ejemplo de servicio real, nombrar sus elementos esenciales y relacionarlo con otras prácticas de ITIL 4, el módulo ya te habrá dado una base aplicable y no solo vocabulario.
Modulo 09. Service level management y reporting
Objetivo del modulo
Entender con precisión qué cubre 'Service level management y reporting', para qué sirve dentro de ITIL 4 y cómo se aplica en la operación y mejora de servicios reales.
Desarrollo teorico
Service level management traduce expectativas del negocio en objetivos medibles y revisables. Los SLAs expresan compromisos formales de nivel de servicio; los XLAs intentan capturar la experiencia percibida por el usuario o cliente más allá de la métrica operativa clásica.
Un SLA no es una lista de deseos; debe ser medible y gobernable. Los XLAs complementan, no sustituyen, a los SLAs. Conviene definir pocas métricas útiles y revisarlas con el consumidor. Reporting sin conversación de servicio rara vez genera mejora. La revisión periódica evita mantener objetivos irrelevantes o inviables.
Tabla de referencia
| Elemento | Enfoque | Ejemplo |
|---|---|---|
| SLA | Compromiso formal medible | Disponibilidad 99,9% |
| XLA | Percepción de experiencia | Satisfacción postincidente |
| OLA | Acuerdo interno operativo | Resolución L2 en 2 horas |
Procedimiento recomendado
- Identificar expectativa del consumidor
- Definir métricas medibles
- Acordar reporting y revisión
- Usar resultados para mejorar
Escenario realista
Ejemplo aplicado: Un servicio puede cumplir disponibilidad del 99,9% y aun así generar mala experiencia si las interrupciones ocurren siempre a primera hora y el usuario recibe poca comunicación. Por eso conviene complementar SLA con medidas de experiencia. La utilidad del ejemplo es que obliga a mirar el concepto no como teoría abstracta, sino como decisión operativa con consecuencias sobre soporte, riesgo, experiencia de usuario y gobierno.
Métrica o evidencia útil
Cumplimiento de SLA y tendencia de satisfacción por servicio.
Artefacto recomendado
Ficha de nivel de servicio con SLA, OLA y XLA asociados.
Contenido ampliado
Este módulo se relaciona con el resto del curso 'ITIL 4 - Practicas Clave' porque aporta lenguaje, decisiones y criterios operativos que reaparecen en prácticas, flujos de valor y escenarios de examen o implantación.
Puntos clave
- Un SLA no es una lista de deseos; debe ser medible y gobernable.
- Los XLAs complementan, no sustituyen, a los SLAs.
- Conviene definir pocas métricas útiles y revisarlas con el consumidor.
- Reporting sin conversación de servicio rara vez genera mejora.
Checklist operativa
- Identificar expectativa del consumidor
- Definir métricas medibles
- Acordar reporting y revisión
- Usar resultados para mejorar
Errores frecuentes
- Firmar SLAs imposibles de medir o sin capacidad real de cumplimiento.
- Confundir el propósito del módulo con tareas administrativas o burocráticas.
- No validar el concepto con un ejemplo de servicio reconocible.
Practica sugerida
Ficha de nivel de servicio con SLA, OLA y XLA asociados.
Preguntas de autoevaluacion
- ¿Qué diferencia principal existe entre SLA y XLA?
- ¿Qué mala práctica es habitual en service level management?
Cierre
Si al terminar puedes explicar Service level management y reporting usando un ejemplo de servicio real, nombrar sus elementos esenciales y relacionarlo con otras prácticas de ITIL 4, el módulo ya te habrá dado una base aplicable y no solo vocabulario.
Modulo 10. Mapa de integracion entre practicas
Objetivo del modulo
Entender con precisión qué cubre 'Mapa de integracion entre practicas', para qué sirve dentro de ITIL 4 y cómo se aplica en la operación y mejora de servicios reales.
Desarrollo teorico
El bloque 'Mapa de integracion entre practicas' se estudia desde una perspectiva operativa de ITIL 4: definición precisa, propósito, relación con otras prácticas y ejemplo de aplicación en un servicio real.
'Mapa de integracion entre practicas' debe entenderse por su propósito y no solo por su nombre. En ITIL 4 siempre conviene identificar entradas, salidas y responsables. La práctica o capacidad se valora por su contribución al valor y a la experiencia. El diseño excesivamente burocrático suele restar eficacia operativa. Un ejemplo de servicio real ayuda a fijar el concepto y detectar límites.
Tabla de referencia
| Aspecto | Descripción |
|---|---|
| Propósito | Por qué existe el bloque |
| Uso | Cómo aparece en un servicio real |
| Riesgo | Qué falla si se aplica mal |
Procedimiento recomendado
- Definir propósito
- Relacionar con un servicio real
- Identificar métricas
- Revisar errores comunes
Escenario realista
Ejemplo aplicado: En un servicio corporativo, 'Mapa de integracion entre practicas' aporta decisiones y controles que deben verse en la operación diaria, no solo en documentación. La utilidad del ejemplo es que obliga a mirar el concepto no como teoría abstracta, sino como decisión operativa con consecuencias sobre soporte, riesgo, experiencia de usuario y gobierno.
Métrica o evidencia útil
Evidencia de uso real del concepto dentro del servicio.
Artefacto recomendado
Documento breve que aterrice 'Mapa de integracion entre practicas' a un servicio concreto.
Contenido ampliado
Este módulo se relaciona con el resto del curso 'ITIL 4 - Practicas Clave' porque aporta lenguaje, decisiones y criterios operativos que reaparecen en prácticas, flujos de valor y escenarios de examen o implantación.
Puntos clave
- 'Mapa de integracion entre practicas' debe entenderse por su propósito y no solo por su nombre.
- En ITIL 4 siempre conviene identificar entradas, salidas y responsables.
- La práctica o capacidad se valora por su contribución al valor y a la experiencia.
- El diseño excesivamente burocrático suele restar eficacia operativa.
Checklist operativa
- Definir propósito
- Relacionar con un servicio real
- Identificar métricas
- Revisar errores comunes
Errores frecuentes
- Usarlo como término decorativo sin cambiar ninguna decisión operativa.
- Confundir el propósito del módulo con tareas administrativas o burocráticas.
- No validar el concepto con un ejemplo de servicio reconocible.
Practica sugerida
Documento breve que aterrice 'Mapa de integracion entre practicas' a un servicio concreto.
Preguntas de autoevaluacion
- ¿Qué se debe exigir al aplicar este bloque en un servicio real?
- ¿Cuál es un error frecuente en este bloque?
Cierre
Si al terminar puedes explicar Mapa de integracion entre practicas usando un ejemplo de servicio real, nombrar sus elementos esenciales y relacionarlo con otras prácticas de ITIL 4, el módulo ya te habrá dado una base aplicable y no solo vocabulario.
Learning outcomes
- Distinguir las capacidades principales del curso y su propósito operativo.
- Aplicar terminología ITIL 4 a escenarios reales de servicio.
- Tomar mejores decisiones sobre experiencia, riesgo, soporte y mejora.
Target audience
Profesionales ITSM, service managers, leads de soporte, consultores y responsables de operaciones.
Prerequisites
Base equivalente a ITIL 4 Foundation o experiencia práctica en servicios.
Study guide
Guia de estudio
Ritmo sugerido
Foundation admite un ritmo de uno o dos módulos por sesión. La clave no es la velocidad, sino fijar definiciones y relaciones antes de pasar a prácticas y preguntas.
Plan orientativo
- Bloque 01: Marco de practicas ITIL y criterios de priorizacion. Objetivo: dominar la terminología y aplicarla a un ejemplo real.
- Bloque 02: Incident management y request management. Objetivo: dominar la terminología y aplicarla a un ejemplo real.
- Bloque 03: Problem management y aprendizaje operativo. Objetivo: dominar la terminología y aplicarla a un ejemplo real.
- Bloque 04: Change enablement y control del riesgo. Objetivo: dominar la terminología y aplicarla a un ejemplo real.
- Bloque 05: Service desk y experiencia del usuario. Objetivo: dominar la terminología y aplicarla a un ejemplo real.
- Bloque 06: Knowledge management y autoservicio. Objetivo: dominar la terminología y aplicarla a un ejemplo real.
- Bloque 07: Monitoring and event management. Objetivo: dominar la terminología y aplicarla a un ejemplo real.
- Bloque 08: Service configuration management. Objetivo: dominar la terminología y aplicarla a un ejemplo real.
- Bloque 09: Service level management y reporting. Objetivo: dominar la terminología y aplicarla a un ejemplo real.
- Bloque 10: Mapa de integracion entre practicas. Objetivo: dominar la terminología y aplicarla a un ejemplo real.
Metodo recomendado
- Lee primero la definición principal del módulo.
- Revisa la tabla comparativa y asegúrate de entender por qué existe.
- Reescribe con tus palabras el escenario realista.
- Contesta preguntas tipo test justificando cada distractor.
Evidencias de aprendizaje
- Diferencias con claridad utility frente a warranty.
- Sabes explicar SVS frente a SVC sin mezclar ambos conceptos.
- Puedes decir qué práctica usarías ante un incidente recurrente, un cambio o una petición.
1. ¿Qué se debe exigir al aplicar este bloque en un servicio real?
2. ¿Cuál es un error frecuente en este bloque?
3. ¿Qué diferencia principal separa un incidente de una request en ITIL 4?
4. ¿Qué métrica encaja mejor con service request management?
5. ¿Cuál es el objetivo principal de problem management?
6. ¿Qué es un known error?
7. ¿Cuál es la finalidad principal de change enablement?
8. ¿Qué caracteriza a un cambio estándar?
9. ¿Qué papel define mejor al service desk?
10. ¿Qué métrica se asocia especialmente al service desk?
11. ¿Qué objetivo principal tiene knowledge management?
12. ¿Qué indicador ayuda a saber si el conocimiento aporta valor?
13. ¿Qué valor principal aporta monitoring and event management?
14. ¿Cuál es un síntoma de mala monitorización?
15. ¿Qué persigue service configuration management?
16. ¿Qué afirmación es correcta sobre un CI?
Glosario del curso
Value stream
Secuencia específica de actividades y roles que convierte una demanda en valor.
MTTR
Mean Time to Restore Service. Tiempo medio para restaurar el servicio tras una interrupción.
Known error
Problema cuya causa raíz o workaround ya ha sido identificado.
SLA
Compromiso medible de nivel de servicio acordado con el consumidor.
XLA
Indicador orientado a experiencia percibida que complementa métricas operativas clásicas.
Lab / Workshop
Laboratorio o Taller
Objetivo
Elabora un taller aplicado del curso 'ITIL 4 - Practicas Clave' usando un servicio real, define prácticas implicadas, métricas y decisiones operativas.
Secuencia sugerida
- Elige un servicio real o simulado.
- Documenta consumidor, proveedor y resultado esperado.
- Identifica utility, warranty y prácticas involucradas.
- Dibuja un flujo o cadena de valor relacionada con la demanda principal.
- Contrasta tu diseño con el glosario y el examen.
Entregables
- Documento o tablero visual del servicio.
- Tabla de conceptos ITIL aplicados.
- Reflexión final sobre errores de interpretación detectados.
Integrative case study
Caso Practico Integrador
Escenario
Una organización madura en ITSM necesita mejorar el área 'ITIL 4 - Practicas Clave' con menos burocracia y más valor medible. El alumno debe proponer un rediseño usando los conceptos del curso.
Objetivo del caso
Usar el vocabulario y los conceptos del curso para ordenar un problema de servicio real, identificar valor, prácticas implicadas, riesgos y decisiones operativas.
Entregables esperados
- Mapa del servicio y consumidores.
- Lista de prácticas ITIL 4 implicadas y su papel.
- Riesgos detectados y propuesta de mejora priorizada.
- Resumen ejecutivo de una página.
Criterios de calidad
- Definiciones correctas y sin mezclar términos.
- Relación clara entre teoría y servicio real.
- Medidas propuestas coherentes con el problema descrito.
Recursos y Bibliografia Orientativa
Fuentes base del area
Estrategia recomendada
- Usa este curso como hilo conductor.
- Contrasta terminología y alcance con la documentación oficial del esquema ITIL 4.
- Si trabajas ya en un entorno ITSM, intenta mapear cada práctica a tu herramienta o proceso real.
Evaluation
Evaluacion del Curso
Preguntas abiertas de repaso
Pregunta 01
- Enunciado: Explica con un ejemplo real de servicio qué cubre 'Marco de practicas ITIL y criterios de priorizacion' y por qué no debe confundirse con otros conceptos de ITIL 4.
- Que se espera en la respuesta: definición precisa, ejemplo aplicado y distinción frente a un término cercano.
Pregunta 02
- Enunciado: Explica con un ejemplo real de servicio qué cubre 'Incident management y request management' y por qué no debe confundirse con otros conceptos de ITIL 4.
- Que se espera en la respuesta: definición precisa, ejemplo aplicado y distinción frente a un término cercano.
Pregunta 03
- Enunciado: Explica con un ejemplo real de servicio qué cubre 'Problem management y aprendizaje operativo' y por qué no debe confundirse con otros conceptos de ITIL 4.
- Que se espera en la respuesta: definición precisa, ejemplo aplicado y distinción frente a un término cercano.
Pregunta 04
- Enunciado: Explica con un ejemplo real de servicio qué cubre 'Change enablement y control del riesgo' y por qué no debe confundirse con otros conceptos de ITIL 4.
- Que se espera en la respuesta: definición precisa, ejemplo aplicado y distinción frente a un término cercano.
Pregunta 05
- Enunciado: Explica con un ejemplo real de servicio qué cubre 'Service desk y experiencia del usuario' y por qué no debe confundirse con otros conceptos de ITIL 4.
- Que se espera en la respuesta: definición precisa, ejemplo aplicado y distinción frente a un término cercano.
Pregunta 06
- Enunciado: Explica con un ejemplo real de servicio qué cubre 'Knowledge management y autoservicio' y por qué no debe confundirse con otros conceptos de ITIL 4.
- Que se espera en la respuesta: definición precisa, ejemplo aplicado y distinción frente a un término cercano.
Pregunta 07
- Enunciado: Explica con un ejemplo real de servicio qué cubre 'Monitoring and event management' y por qué no debe confundirse con otros conceptos de ITIL 4.
- Que se espera en la respuesta: definición precisa, ejemplo aplicado y distinción frente a un término cercano.
Pregunta 08
- Enunciado: Explica con un ejemplo real de servicio qué cubre 'Service configuration management' y por qué no debe confundirse con otros conceptos de ITIL 4.
- Que se espera en la respuesta: definición precisa, ejemplo aplicado y distinción frente a un término cercano.
Pregunta 09
- Enunciado: Explica con un ejemplo real de servicio qué cubre 'Service level management y reporting' y por qué no debe confundirse con otros conceptos de ITIL 4.
- Que se espera en la respuesta: definición precisa, ejemplo aplicado y distinción frente a un término cercano.
Pregunta 10
- Enunciado: Explica con un ejemplo real de servicio qué cubre 'Mapa de integracion entre practicas' y por qué no debe confundirse con otros conceptos de ITIL 4.
- Que se espera en la respuesta: definición precisa, ejemplo aplicado y distinción frente a un término cercano.