Modulo 01. Marco de practicas ITIL y criterios de priorizacion

Objetivo del modulo

Comprender como ITIL 4 organiza sus 34 practicas en tres categorias, por que las llama practicas en vez de procesos, y como una organizacion decide cuales activar, con que profundidad y en que orden. Establecer criterios de priorizacion basados en valor, riesgo y contexto organizativo.

Resultados esperados

• Explicar la diferencia entre practica y proceso en terminologia ITIL 4.
• Clasificar las 34 practicas en sus tres categorias: general management, service management y technical management.
• Definir criterios para priorizar que practicas activar primero.
• Relacionar la priorizacion de practicas con el contexto del servicio (criticidad, madurez, riesgo).
• Evitar el error de intentar implementar todas las practicas a la vez con la misma formalidad.

Desarrollo teorico

ITIL v3 hablaba de 26 procesos y cuatro funciones. ITIL 4 reemplaza ambos conceptos por 34 practicas. El cambio de terminologia no es cosmetico; refleja un cambio de enfoque. Un proceso es una secuencia de actividades con entradas y salidas definidas. Una practica es un conjunto de recursos organizativos disenados para realizar trabajo o conseguir un objetivo. La diferencia clave es que la practica incluye personas, competencias, herramientas, informacion, flujos de trabajo, roles y gobernanza, no solo una secuencia de pasos.

Estructura de las 34 practicas

ITIL 4 clasifica las practicas en tres categorias:

14 practicas de gestion general (general management practices): Aplicables a toda la organizacion, no solo a TI. Incluyen: architecture management, continual improvement, information security management, knowledge management, measurement and reporting, organizational change management, portfolio management, project management, relationship management, risk management, service financial management, strategy management, supplier management, workforce and talent management.

17 practicas de gestion de servicios (service management practices): El nucleo operativo de la gestion de servicios. Incluyen: availability management, business analysis, capacity and performance management, change enablement, incident management, IT asset management, monitoring and event management, problem management, release management, service catalog management, service configuration management, service continuity management, service design, service desk, service level management, service request management, service validation and testing.

3 practicas de gestion tecnica (technical management practices): Capacidades tecnicas especificas. Incluyen: deployment management, infrastructure and platform management, software development and management.

Por que no implementar todo a la vez

Un error frecuente en organizaciones que adoptan ITIL es intentar implementar las 34 practicas simultaneamente con el mismo nivel de formalidad. Esto produce sobrecarga, burocracia innecesaria y frustracion. No todos los servicios necesitan las mismas practicas con la misma intensidad. Un servicio de correo corporativo para 5.000 usuarios necesita incident management, problem management y change enablement maduros. Una aplicacion interna usada por 10 personas puede funcionar con practicas minimas.

Criterios de priorizacion

La decision de que practicas activar primero y con que profundidad depende de varios factores:

1. Criticidad del servicio: Un servicio que soporta procesos de negocio criticos (facturacion, produccion, atencion al paciente) necesita practicas robustas de incident management, change enablement, availability management y service continuity management. Un servicio de menor impacto puede funcionar con menos formalidad.

2. Dolor operativo actual: Si la organizacion sufre incidentes recurrentes, la prioridad es incident management y problem management. Si los cambios generan caidas frecuentes, la prioridad es change enablement. Si los SLAs se incumplen sistematicamente, la prioridad es service level management. Priorizar segun el dolor real, no segun la lista del framework.

3. Madurez organizativa: Una organizacion que no tiene un service desk funcional no deberia priorizar architecture management o portfolio management. Hay un orden logico: las practicas basicas de operacion (incident, request, change, service desk) suelen ser el cimiento sobre el que se construyen practicas mas avanzadas.

4. Requisitos regulatorios y de cumplimiento: En industrias reguladas (salud, finanzas, gobierno), information security management, risk management y service continuity management pueden ser obligatorias antes que cualquier optimizacion operativa.

5. Dependencias entre practicas: Algunas practicas se habilitan mutuamente. Problem management necesita datos de incident management. Change enablement se beneficia de service configuration management. Service level management requiere measurement and reporting. Activar una practica sin sus dependencias reduce su efectividad.

Modelo de priorizacion por capas

Este modelo no es rigido; se adapta al contexto. Una organizacion con infraestructura critica puede necesitar monitoring and event management en la capa 1. Una organizacion con fuerte dependencia de proveedores puede necesitar supplier management desde el inicio.

Practica como capacidad viva

Una practica no se "implementa" una vez y se olvida. Una practica se desarrolla, se mide, se mejora y se adapta. Cada practica tiene un nivel de madurez que puede evaluarse:

• Nivel 0: La practica no existe o es ad hoc.
• Nivel 1: La practica existe pero es reactiva y poco consistente.
• Nivel 2: La practica esta definida, con responsables y flujos basicos.
• Nivel 3: La practica se mide, se revisa y se mejora.
• Nivel 4: La practica esta optimizada e integrada con otras practicas.

No todas las practicas necesitan estar en nivel 4. El nivel objetivo depende de la criticidad del servicio y del valor que la practica aporta.

Contenido ampliado

Puntos clave

• ITIL 4 tiene 34 practicas (no procesos): 14 general, 17 service, 3 technical.
• Una practica incluye personas, herramientas, informacion y flujos de trabajo, no solo pasos.
• No se deben implementar todas las practicas a la vez con la misma formalidad.
• La priorizacion se basa en criticidad del servicio, dolor operativo, madurez, regulacion y dependencias.
• Las practicas tienen niveles de madurez; no todas necesitan estar en el nivel maximo.

Checklist operativa

• Identificar cuales de las 34 practicas estan activas de verdad en la organizacion (no solo documentadas).
• Clasificar los servicios por criticidad para determinar que practicas necesitan mayor formalidad.
• Detectar el dolor operativo actual: que tipo de incidentes, fallos o carencias genera mas impacto.
• Validar que las practicas activas tienen responsable, metricas y mecanismo de revision.
• Revisar las dependencias entre practicas antes de activar una nueva.

Errores frecuentes

• Intentar implementar las 34 practicas simultaneamente sin priorizar.
• Tratar las practicas como procesos documentados en vez de capacidades vivas.
• Activar practicas avanzadas (portfolio, architecture) sin tener las basicas (incident, change) funcionando.
• Ignorar las dependencias entre practicas.
• Aplicar la misma formalidad a todos los servicios independientemente de su criticidad.

Practica sugerida

Haz un inventario de practicas en tu organizacion: cuales estan activas, en que nivel de madurez, y cuales faltan. Despues, identifica el mayor dolor operativo actual (incidentes recurrentes? cambios fallidos? falta de visibilidad? SLAs incumplidos?) y determina que practica deberia priorizarse para reducir ese dolor. Justifica la priorizacion con criterios de valor, riesgo y dependencias.

Preguntas de autoevaluacion

1. Cuantas practicas tiene ITIL 4 y en que tres categorias se dividen?
2. Que diferencia hay entre un proceso y una practica en ITIL 4?
3. Por que no es recomendable implementar todas las practicas a la vez?
4. Nombra cuatro criterios para priorizar que practicas activar primero.
5. Que practicas considerarias basicas (capa 1) para cualquier organizacion de servicios?

Cierre

El marco de practicas de ITIL 4 no es una lista que hay que completar; es un catalogo de capacidades que cada organizacion activa segun su contexto. La clave no esta en cuantas practicas se implementan, sino en cuales aportan mas valor al servicio con el menor coste y riesgo. Priorizar con criterio, empezar por lo basico, medir resultados y evolucionar. Esa es la diferencia entre adoptar ITIL como un checklist burocratico y adoptarlo como un modelo de mejora real.

Modulo 02. Incident management y service request management

Objetivo del modulo

Dominar las dos practicas de gestion de servicios que generan mayor volumen de trabajo operativo diario: incident management y service request management. Comprender sus propositos diferenciados, flujos de trabajo, metricas, conexiones con otras practicas y errores criticos que degradan la operacion cuando ambas se confunden.

Resultados esperados

• Definir incidente y service request con precision ITIL 4.
• Describir el flujo completo de gestion de un incidente desde deteccion hasta cierre.
• Explicar el procedimiento de major incidents y su diferencia con incidentes regulares.
• Disenar modelos de cumplimiento para service requests.
• Identificar metricas clave para cada practica y sus trampas habituales.
• Justificar por que mezclar ambos flujos degrada prioridades y SLAs.

Desarrollo teorico

Incident management

Proposito ITIL 4: Minimizar el impacto negativo de incidentes restaurando la operacion normal del servicio lo antes posible.

Un incidente es una interrupcion no planificada de un servicio, o una reduccion de la calidad de un servicio. La palabra clave es "no planificada": una ventana de mantenimiento programado no es un incidente aunque el servicio no este disponible. Una reduccion de calidad (el servicio funciona pero con latencia excesiva) tambien es un incidente.

Ciclo de vida de un incidente

1. Deteccion y registro: El incidente puede detectarse de tres formas: reportado por el usuario (via service desk, portal, chat), detectado por monitorizacion (evento que genera alerta automatica), o identificado por personal tecnico durante operacion rutinaria. Todo incidente debe registrarse, incluso si se resuelve en el primer contacto. Sin registro no hay datos para problem management, mejora ni reporting.

2. Clasificacion y priorizacion: La clasificacion describe el tipo de incidente (red, aplicacion, acceso, hardware). La priorizacion se basa en dos factores:

   • Impacto: Cuantos usuarios o procesos de negocio estan afectados. Un servicio de facturacion caido afecta a toda la empresa; un equipo portatil con fallo afecta a un usuario.
   • Urgencia: Cuanto puede esperar la resolucion sin que el dano aumente significativamente.

   La combinacion de impacto y urgencia determina la prioridad (critica, alta, media, baja). La prioridad define tiempos de respuesta y resolucion segun SLA.

3. Diagnostico y escalado: El primer nivel (L1, normalmente service desk) intenta diagnosticar y resolver con scripts, base de conocimiento o procedimientos estandar. Si no puede, escala a segundo nivel (L2, equipos especializados) o tercer nivel (L3, ingenieria, proveedor). El escalado debe incluir contexto completo: que se ha probado, que datos se han recogido, que impacto tiene. Un escalado sin contexto hace perder tiempo al siguiente nivel.

   Existen dos tipos de escalado:

   • Funcional: A un equipo con mas competencia tecnica.
   • Jerarquico: A un nivel de gestion superior cuando se necesitan decisiones de negocio, recursos adicionales o comunicacion ejecutiva.

4. Resolucion y recuperacion: Aplicar la solucion (puede ser un workaround temporal o una correccion definitiva). Verificar que el servicio funciona correctamente para el usuario. La resolucion de un incidente NO requiere encontrar la causa raiz; eso es responsabilidad de problem management.

5. Cierre: Confirmar con el usuario que el servicio esta restaurado. Documentar la resolucion. Actualizar la base de conocimiento si aplica.

Major incidents

Un major incident es un incidente con impacto significativo en el negocio que requiere una gestion coordinada mas alla del procedimiento habitual. Caracteristicas:

• Equipo de respuesta dedicado (Major Incident Team).
• Canal de comunicacion separado y frecuente con stakeholders y direccion.
• Cadencia de actualizaciones definida (cada 30 minutos, cada hora, segun politica).
• Post Incident Review (PIR) obligatoria tras la resolucion para documentar lecciones aprendidas, acciones correctivas y alimentar problem management.

Metricas de incident management

Service request management

Proposito ITIL 4: Soportar la calidad acordada de un servicio gestionando todas las peticiones de servicio predefinidas e iniciadas por el usuario de manera efectiva y amigable.

Una service request es una peticion formal del usuario para algo que esta predefinido y normalmente es de bajo riesgo: solicitar acceso a una carpeta, pedir un equipo nuevo, solicitar informacion, pedir alta en un grupo de distribucion, solicitar un reinicio de contrasena.

Diferencias clave con un incidente

Modelos de cumplimiento (fulfilment models)

Cada tipo de request debe tener un modelo predefinido que especifique:

• Pasos para cumplir la solicitud.
• Aprobaciones necesarias (si las hay).
• Tiempo objetivo de cumplimiento.
• Automatizacion posible (muchas requests se pueden automatizar completamente).

Ejemplo: una solicitud de acceso a una carpeta de red puede tener el siguiente modelo: (1) el usuario solicita via portal, (2) se requiere aprobacion del propietario de la carpeta, (3) aprobada la solicitud, se ejecuta automaticamente via script, (4) el usuario recibe confirmacion. Tiempo objetivo: 4 horas laborables.

Las requests que no tienen modelo predefinido y requieren evaluacion caso a caso probablemente no son requests sino cambios o proyectos.

Metricas de service request management

Por que no mezclar ambos flujos

Cuando incidentes y requests comparten la misma cola y los mismos SLAs, se producen varios problemas:

• Las requests inflan el volumen de "incidentes" y distorsionan metricas como MTTR.
• Los incidentes criticos compiten por atencion con requests de bajo riesgo.
• Las requests no se miden con metricas apropiadas (fulfilment time) sino con metricas de incidentes.
• El service desk pierde capacidad de priorizar porque todo se trata igual.

Contenido ampliado

Puntos clave

• Un incidente es una interrupcion no planificada; una request es una peticion predefinida de bajo riesgo.
• La prioridad de un incidente se determina por impacto + urgencia.
• Los major incidents requieren equipo dedicado, comunicacion separada y revision post-incidente.
• Las service requests deben tener modelos de cumplimiento predefinidos.
• Mezclar ambos flujos distorsiona metricas, prioridades y capacidad del service desk.
• La resolucion de un incidente no implica encontrar la causa raiz.

Checklist operativa

• Verificar que incidentes y requests tienen flujos separados con colas y metricas distintas.
• Confirmar que existe un procedimiento documentado para major incidents con PIR obligatorio.
• Comprobar que las requests mas frecuentes tienen modelos de cumplimiento con pasos, aprobaciones y tiempos definidos.
• Revisar que el escalado incluye contexto completo, no solo reasignacion.
• Validar que las metricas de cada practica miden lo correcto (MTTR para incidentes, fulfilment time para requests).

Errores frecuentes

• Registrar requests como incidentes porque entran por el mismo canal.
• No diferenciar major incident del procedimiento regular de incidentes.
• Escalar sin contexto, obligando al siguiente nivel a empezar de cero.
• Cerrar incidentes prematuramente para mejorar MTTR sin verificar con el usuario.
• No tener modelos de cumplimiento para las requests mas frecuentes.
• Medir FCR sin validar que la resolucion fue efectiva (no solo rapida).

Practica sugerida

Toma las 10 solicitudes mas frecuentes que recibe tu service desk. Clasifica cada una como incidente o service request. Para las que son requests, define un modelo de cumplimiento basico: pasos, aprobacion necesaria, tiempo objetivo, posibilidad de automatizacion. Para las que son incidentes, verifica que se priorizan por impacto y urgencia, no por orden de llegada.

Preguntas de autoevaluacion

1. Cual es la diferencia fundamental entre un incidente y una service request?
2. Que dos factores determinan la prioridad de un incidente?
3. Que caracteristicas tiene un major incident que lo diferencian de un incidente regular?
4. Que debe incluir un modelo de cumplimiento de service request?
5. Por que mezclar incidentes y requests en la misma cola degrada la operacion?

Cierre

Incident management y service request management son las dos practicas que mas contacto directo tienen con el usuario. Si funcionan bien, el usuario percibe un servicio responsive y controlado. Si funcionan mal (mezcla de flujos, priorizacion arbitraria, cierres prematuros, escalados sin contexto), el usuario percibe caos. La clave esta en separar los flujos, definir modelos claros y medir lo que importa: para incidentes, la velocidad y calidad de restauracion; para requests, la eficiencia y experiencia de cumplimiento.