Las cinco prácticas ITIL 4 con las que conviene empezar

ITIL 4 describe 34 prácticas de gestión, agrupadas en prácticas generales, de gestión de servicios y de gestión técnica. Ninguna organización necesita implantarlas todas a la vez, y casi ninguna podría hacerlo bien. Este artículo propone un punto de partida concreto: cinco prácticas y un service desk, qué debe tener cada una como mínimo, cómo medirla y en qué orden conviene abordarlas.

Por qué no empezar por las 34

El catálogo completo de prácticas es una referencia, no un plan de implantación. Querer cubrirlo entero desde el primer día suele producir tres síntomas reconocibles: procesos documentados que nadie sigue, una herramienta de gestión de servicios configurada a medias y equipos que perciben ITIL como trámite y no como ayuda.

El propio marco empuja en otra dirección. Entre sus principios guía están empezar donde estás, progresar de forma iterativa con retroalimentación y mantenerlo simple y práctico. Dentro del sistema de valor del servicio, las prácticas son recursos que se combinan para ejecutar la cadena de valor; no son casillas que haya que marcar.

La pregunta útil, entonces, no es "cuántas prácticas tenemos" sino "qué flujos de trabajo de la operación diaria todavía dependen de la memoria y la buena voluntad de las personas". En casi cualquier área de TI, la respuesta apunta a los mismos lugares: cómo se atiende lo que se rompe, cómo se evita que vuelva a romperse, cómo se cambia lo que está en producción, cómo se entrega lo que los usuarios piden y cómo se acuerda qué es un buen servicio.

La base: un service desk con una sola puerta de entrada

Antes que cualquier proceso, la operación necesita un punto único de contacto. El service desk es la práctica que captura la demanda de incidentes y solicitudes y la canaliza. Sin él, cada práctica recibe trabajo por un canal distinto (correo, chat, pasillo, llamada directa al especialista) y ninguna métrica es confiable.

Un service desk mínimo viable tiene canales definidos y publicados, un registro obligatorio de todo contacto, criterios claros para distinguir un incidente de una solicitud y una regla simple de escalamiento. No hace falta un equipo grande: hace falta que todo pase por ahí.

La métrica que conviene mirar primero es la resolución en el primer contacto, acompañada de la satisfacción del usuario al cerrar. El error frecuente es convertirlo en un despachador de tickets que solo reasigna, sin capacidad ni conocimiento para resolver lo simple.

Las cinco prácticas, una por una

Gestión de incidentes

Propósito: limitar el daño que causan los incidentes devolviendo el servicio a la normalidad cuanto antes.

Proceso mínimo viable: registro, categorización sencilla, prioridad calculada a partir de impacto y urgencia, diagnóstico, escalamiento, resolución y cierre con confirmación del usuario. Además, un procedimiento separado para incidentes mayores, con un responsable de coordinación y una cadencia de comunicación definida.

Métrica clave: tiempo de restauración por prioridad, expresado como porcentaje de incidentes resueltos dentro del objetivo. El promedio solo esconde los casos extremos.

Error frecuente: que la prioridad la decida quien reporta, o que haya tantas categorías y niveles que nadie los use igual. Cuatro niveles de prioridad y una matriz visible suelen bastar.

Gestión de problemas

Propósito: lograr que los incidentes ocurran menos y duelan menos, encontrando lo que realmente los causa y gestionando soluciones temporales y errores conocidos.

Proceso mínimo viable: un criterio explícito para abrir problemas (todo incidente mayor y todo incidente que se repita, por ejemplo, tres veces en un mes), un análisis con responsable y fecha, un registro de errores conocidos con su solución temporal accesible para el service desk y un vínculo con habilitación de cambios para la corrección definitiva.

Métrica clave: recurrencia de incidentes asociados a problemas ya analizados. Si la recurrencia no baja, el análisis no está llegando a la causa.

Error frecuente: mezclarlo con incidentes. Un incidente se cierra cuando el servicio vuelve; un problema se cierra cuando la causa se elimina o se acepta formalmente. Mantener el incidente abierto "hasta saber qué pasó" distorsiona ambas métricas.

Habilitación de cambios

Propósito: que la mayor cantidad posible de cambios salga bien, con el riesgo evaluado, cada cambio autorizado y el calendario bajo control.

Proceso mínimo viable: tres tipos de cambio (estándar, normal y de emergencia), una autoridad de cambio definida para cada nivel de riesgo, un calendario visible y una revisión posterior de los cambios fallidos. El nombre de la práctica no es casual: ITIL 4 pasó de "control" a "habilitación" para subrayar que el objetivo es que los cambios ocurran bien, no que ocurran menos.

Métrica clave: tasa de éxito de cambios, leída junto con el tiempo de ciclo desde la solicitud hasta la implementación.

Error frecuente: un comité que revisa todos los cambios por igual. Eso alarga los plazos, empuja a los equipos a evitar el proceso y no mejora la tasa de éxito.

Gestión de solicitudes de servicio

Propósito: resolver las solicitudes predefinidas que inician los usuarios (accesos, equipos, información, cambios menores preaprobados) con eficiencia y buena experiencia.

Proceso mínimo viable: un catálogo corto con las solicitudes más frecuentes, cada una con su formulario, aprobación (si aplica), pasos de cumplimiento y plazo comprometido. Empezar con diez o quince tipos bien resueltos es mejor que con cien mal definidos.

Métrica clave: porcentaje de solicitudes cumplidas dentro del plazo comprometido, y como segunda lectura, la proporción que se cumple de forma automatizada.

Error frecuente: registrar las solicitudes como incidentes. Una alta de usuario no es una falla. Mezclarlas infla el volumen de incidentes y oculta dónde está la oportunidad de automatizar.

Gestión del nivel de servicio

Propósito: acordar objetivos de desempeño claros, anclados en las necesidades del negocio, y seguir y gestionar la entrega frente a ellos.

Proceso mínimo viable: una lista de servicios con su dueño de negocio, dos o tres medidas por servicio que reflejen lo que el usuario experimenta, un informe periódico y una reunión de revisión con el cliente interno. Los acuerdos formales pueden venir después, cuando haya datos para sostenerlos.

Métrica clave: cumplimiento de los objetivos acordados, contrastado con la satisfacción declarada por el negocio. Si el cumplimiento es alto y la satisfacción es baja, el acuerdo mide lo equivocado.

Error frecuente: medir la disponibilidad de componentes técnicos en lugar del resultado que recibe el usuario. Es el origen del conocido "efecto sandía": verde por fuera, rojo por dentro.

Tabla resumen

Práctica	Mínimo viable	Métrica clave	Error frecuente
Service desk	Punto único de contacto, registro obligatorio	Resolución en el primer contacto	Despachar sin resolver
Gestión de incidentes	Prioridad por impacto y urgencia, procedimiento de incidente mayor	Restauración dentro del objetivo por prioridad	Prioridad subjetiva, demasiados niveles
Gestión de problemas	Criterio de apertura, registro de errores conocidos	Recurrencia de incidentes	Confundir problema con incidente
Habilitación de cambios	Tres tipos de cambio, autoridad por riesgo, calendario	Tasa de éxito de cambios	Comité único para todo
Gestión de solicitudes de servicio	Catálogo corto con plazos	Cumplimiento dentro del plazo	Registrar solicitudes como incidentes
Gestión del nivel de servicio	Medidas por servicio, revisión periódica	Cumplimiento frente a satisfacción	Medir componentes, no resultados

Una secuencia sugerida

No hay un orden único, pero sí dependencias. Recomendamos avanzar por tramos cortos, cada uno con un resultado visible, en lugar de un gran proyecto con una fecha final lejana. La duración de cada tramo depende del tamaño de la operación; como ejemplo, seis a ocho semanas por tramo es un ritmo razonable para un área mediana.

1. Service desk, incidentes y solicitudes. Se implantan juntos porque comparten la puerta de entrada. El primer logro es separar ambos flujos y registrar todo.
2. Habilitación de cambios. Con los incidentes ya registrados, es posible ver cuántos se originan en cambios. Ese dato justifica el proceso ante los equipos técnicos y orienta qué cambios declarar estándar primero.
3. Gestión de problemas. Necesita historial de incidentes para detectar recurrencias. Empezar antes suele terminar en análisis sin datos.
4. Gestión del nivel de servicio. Se puede empezar a conversar con el negocio desde el primer tramo, pero los objetivos formales conviene fijarlos con al menos unos meses de datos reales de incidentes y solicitudes.
5. Revisión y ampliación. Con la base funcionando, se evalúa qué otras prácticas (gestión del conocimiento, gestión de la configuración, monitoreo y gestión de eventos) aportan más valor según los cuellos de botella observados.

Cómo saber que la base está lista

La señal no es tener todos los procesos documentados. Es poder responder, con datos y sin reconstruir nada a mano, preguntas como estas:

• ¿Cuántos incidentes de prioridad alta tuvimos el mes pasado y cuántos se restauraron dentro del objetivo?
• ¿Qué porcentaje de esos incidentes se originó en un cambio?
• ¿Cuáles son los cinco incidentes más recurrentes y qué problema tiene abierto cada uno?
• ¿Qué solicitudes concentran el mayor volumen y cuáles podrían automatizarse?
• ¿Qué servicio tiene peor satisfacción del negocio, aunque sus indicadores técnicos estén en verde?

Si el equipo puede responderlas, la operación tiene una base sobre la cual crecer. Si no, agregar prácticas solo suma complejidad. En ese caso conviene volver al tramo anterior y cerrar las brechas antes de avanzar.

Una última recomendación: la herramienta acompaña al proceso, no lo reemplaza. Plataformas como ServiceNow, Jira Service Management u otras permiten configurar estos flujos, pero ninguna decide por ti qué es un incidente mayor ni quién autoriza un cambio de alto riesgo. Esas decisiones son de diseño y de gobierno, y deben tomarse antes de configurar.