Primero el valor, después la herramienta — menos fricción, más previsibilidad.

---

Introducción

Pongámonos de acuerdo en algo: implementar ITIL (o cualquier gestión de servicios de TI) no es pulsar un botón. Es como la cocina de un restaurante en hora punta: mucha gente buena, muchas recetas buenas… y aun así el plato puede salir frío si la orquesta no está afinada.

El objetivo aquí es simple: una conversación directa para que identifiques dónde tropiezan los proyectos y cómo corregir el rumbo.

Los tropiezos campeones:

• Falta de implicación del equipo — un proceso “de despacho” no sobrevive al primer incidente.

• Falta de planificación adecuada — sin mapa, backlog y criterios de done, el equipo da vueltas en círculo.

• No considerar las necesidades del negocio — copiar al vecino da comida sin sabor (y sin valor).

• Falta de formación adecuada — herramienta sin contexto se vuelve clic; práctica sin propósito se vuelve burocracia.

• No considerar el mantenimiento — implementar es el comienzo; mejorar continuamente es el juego.

Si en algún párrafo piensas “oye, esto pasa aquí”, perfecto: marca ese punto como tu primer paso. Y, si quieres apoyo inmediato para alinear conceptos, echa un vistazo al curso ITIL 4 Foundation de PMG Academy — es un punto de partida sólido para que el equipo hable el mismo idioma y evolucione con consistencia.

---

Antes de empezar: los principios guía que salvan proyectos

Te lo digo claro: sin brújula, cualquier camino parece atajo. Usa los Principios Orientadores de ITIL 4 como filtro de decisión de principio a fin: foco en el valor, empezar donde estás, avanzar en iteraciones con feedback, colaborar con visibilidad, pensar de forma holística, simplicidad práctica y optimizar/automatizar cuando tenga sentido.
La fuente oficial describe estos principios de forma directa — merece la pena revisar la página de PeopleCert sobre la base de ITIL.

Para ayudarte, aquí van algunas traducciones del argot al día a día:

• Catálogo de servicios: el menú de lo que TI realmente entrega, con plazos, calidad y cómo pedirlo.

• Acuerdo de Nivel de Servicio (ANS): acuerdo formal de tiempo/calidad entre TI y el cliente interno.

• Base de conocimiento: artículos cortos que enseñan a resolver sin depender siempre del analista.

---

Error cero (bonus): empezar por la herramienta

En realidad, no error cero: error BÁSICO y, por desgracia, frecuente. 🙁

Este es el síntoma clásico: el proyecto empieza con la compra de la herramienta y solo después alguien pregunta “¿qué prácticas eran?”. Pausa dramática…

¿Cómo evitarlo?

Define objetivos de valor, mapea flujos de valor (de la solicitud a la entrega) y establece requisitos mínimos por práctica (incidentes, solicitudes, cambios) antes de seleccionar la herramienta. En la configuración, personalización mínima y entrega en MVP (producto mínimo viable) para validar rápido.

¿Cómo demostrar valor? Mira estos indicadores:

• % de requisitos cubiertos con funcionalidades nativas;

• reducción del tiempo medio de restauración (MTTR) tras cambios;

• caída del número de “apaños” y personalizaciones propietarias.

¿Ves? Simple, básico y funciona. Pruébalo y luego me cuentas.

Apoyo inmediato PMG: si necesitas alinear al equipo con un vocabulario común antes de la herramienta, un curso introductorio de ITSM/ITIL 4 ayuda a ahorrar idas y venidas — mira las opciones en PMG Academy.

---

1) Falta de implicación del equipo (y del negocio)

Sin personas, no hay gestión de servicios. Involucrar solo a TI crea ceguera: quien usa el servicio debe ser escuchado desde el inicio.

Cómo ajustarlo:

• Garantiza patrocinio ejecutivo y service owners (quién responde por el resultado).

• Construye el catálogo de servicios junto con las áreas de negocio.

• Planifica la comunicación por persona (quién necesita saber qué, cuándo y por qué canal).

Señales de que funciona:

• Adopción del portal de autoservicio (más del 60% de las solicitudes entran por ahí);

• satisfacción del usuario medida por servicio;

• service owners nombrados y activos.

---

2) Falta de planificación adecuada

Planificar no es tener un cronograma bonito. Es tener un guion por iteraciones, criterios de done y un plan claro de riesgos/beneficios.

Cómo ajustarlo:

• Diseña un plan por iteraciones (MVP → expansión) con criterios de done objetivos.

• Mapea el flujo de incidentes, solicitudes y cambios: entradas, salidas, colas e indicadores.

• Ata el plan a métricas de valor: tiempo de restauración, tasa de éxito de cambios, adopción del portal y satisfacción del usuario.

Fuente útil: el informe DORA – State of DevOps describe las cuatro métricas de rendimiento de entrega (frecuencia de despliegue, lead time de cambios, tasa de fallos de cambios y tiempo de recuperación) que ayudan a medir el flujo con claridad (cloud.google.com/devops/state-of-devops).

---

3) No considerar las necesidades del negocio (y el cumplimiento)

Copiar al vecino falla porque cada empresa tiene contexto, riesgo y prioridades diferentes.

Cómo ajustarlo:

• Traduce objetivos de negocio en objetivos e indicadores de nivel de servicio (SLO/SLI) y en ANS realistas.

• Atiende los requisitos legales: protección de datos (por ejemplo, GDPR/LGPD), auditorías y normas como ISO/IEC 20000.

• Para proveedores críticos, define contratos de soporte coherentes con lo que prometes al cliente.

Referencia base: los principios y prácticas de ITIL 4 dan estructura para alinear servicio y valor, reconocidos oficialmente por PeopleCert (ver la Guía ITIL 4).

---

4) Falta de formación adecuada (por rol) y gestión del conocimiento

Un “macro-curso genérico” la víspera del go-live no crea competencia — crea pánico.

Cómo ajustarlo:

• Rutas formativas por rol (p. ej., responsable de incidente crítico, responsable de problema, service desk).

• Servicio centrado en conocimiento (KCS): artículos cortos, creados y mejorados a partir de interacciones reales.

• Integración con ingeniería: las evidencias de cambio salen del pipeline (tests, seguridad, segregación), no de reuniones.

Dato útil: el seguimiento de métricas operativas sigue creciendo: el 80% de los profesionales de atención afirman medir la “resolución en el primer contacto” en 2024 (estudio State of Service, Salesforce — salesforce.com).

---

5) No considerar la operación y la mejora continua

Implementar es el inicio. Lo que sostiene el valor es la rutina de medir, aprender y ajustar.

Cómo ajustarlo:

• Mantén un backlog de mejora continua con cadencia (quincenal/mensual) y responsable claro.

• Realiza revisiones post-incidente sin caza de brujas; registra causas y tendencias y conviértelas en acciones preventivas.

• Usa observabilidad y monitorización para reducir ruido y anticipar fallos.

Sabes que funciona cuando: baja el ruido de alertas, disminuyen los incidentes repetidos y las acciones preventivas se completan — no se convierten en “tareas eternas”.

---

Bloques que casi siempre faltan en la primera iteración

Contexto rápido: estos puntos son “agujeros de valor” que, si se ignoran, hacen que todo lo demás patine. Elige 1–2 para atacar ahora, no todos a la vez.

• Incidente crítico (Major Incident): mando único, comunicación clara, página de estado.

• Cambio, versión y despliegue: gate en el pipeline, segregación de funciones; comité de cambios solo para excepciones.

• Configuración y activos (CMDB/SAM) en versión “lite”: alcance pequeño, data owner y reconciliación automática.

• Conocimiento (KCS) integrado con el service desk y el portal de usuario final.

• Solicitudes modeladas como catálogos reutilizables con plazos y automatizaciones simples.

• Proveedores con objetivos e integración coherentes con lo que prometes internamente.

Si quieres una visión base para alinear al equipo en estos bloques, ITIL 4 Foundation de PMG Academy ofrece el marco sin bloquear la práctica.

---

Micro-checklist de implantación (primera iteración)

Aviso previo: la idea es crear tracción y aprendizaje rápido. Esto no es un examen — es una guía para la acción.

• Mapa de servicios con responsables y objetivos/indicadores de nivel de servicio.

• Catálogo con las 20 solicitudes e incidentes más frecuentes (claridad de cómo pedir y plazos). ¡El tío Pareto encaja perfecto aquí!

• Herramienta configurada con lo mínimo necesario (sin personalización “mágica”).

• Operación funcionando: service desk colaborativo, incidente crítico, problema, cambio/versión básicos.

• Medición activa: tiempo medio de restauración, tasa de éxito de cambios, adopción del portal, satisfacción del usuario.

• Backlog de mejora con metas y fechas (quincenal/mensual).

Si quieres material de apoyo para convertir esto en un workshop, háblame y te envío un borrador; y mientras tanto, pásate por PMG Academy para ver rutas de formación que ayuden a sostener esta rutina sin drama.

---

Métricas de prueba de valor (ajusta metas por servicio)

Contexto rápido: medir bien es el antídoto contra la “sensación de progreso”. Elige 3–5 indicadores que muestren valor percibido y flujo saludable.

• Tiempo medio de restauración (tras incidente o cambio).

• Tiempo de entrega de cambios y frecuencia de despliegue (inspirados en DORA — ver el informe oficial en cloud.google.com/devops/state-of-devops).

• Tasa de éxito de cambios (menos rollback, menos corrección urgente).

• Adopción del portal de autoservicio (solicitudes e incidentes iniciados allí).

• Precisión de la base de configuración (elementos críticos reconciliados, sin “huérfanos”).

• Satisfacción del usuario por servicio y por persona.

---

Conclusión

Implantar gestión de servicios no es instalar software. Es alinear valor, adelgazar el flujo y medir resultados de una forma que el negocio entienda. Si evitas el error cero y cuidas los cinco puntos con iteraciones cortas, vínculos claros entre práctica y valor y un puñado de métricas útiles, la operación respira — y el cliente lo nota.

Resumen del espíritu: menos fricción, más previsibilidad.

¿Te gustó la charla? Describe tu escenario en dos líneas (tamaño del equipo, herramienta, mayores dolores) y te respondo con un borrador de primer paso para que lo pruebes ya la próxima semana.