Consistencia sin conexión es coste; conexión sin consistencia es caos — por qué “ITIL vs. el resto” es una falsa elección

Una inmersión honesta en el debate reciente sobre ITIL 4, “Humanising IT”, “Value-Engineering” y la supuesta “crisis de los frameworks” — y cómo salir del ruido con un modelo operativo simple, integrado y verificable.

Antes de empezar: un contexto rápido (y 7 preguntas directas)

Probablemente llegaste aquí porque oíste que “ITIL se ha vuelto caro”, que “no sirve para DevOps” o que “existen alternativas modernas”. Antes de comprar una nueva etiqueta, haz una comprobación honesta de tu realidad:

• Cuando alguien dice “servicio” en tu empresa, ¿significa valor percibido o una cola de tickets?

• ¿Tus cambios pasan por una reunión de aprobación o por evidencias en el pipeline (tests, seguridad, segregación de funciones, progressive delivery)?

• ¿Cuáles son tus SLO? ¿Quién los firmó? ¿Cómo utilizas el error budget en la toma de decisiones?

• ¿Ha bajado tu MTTR en los últimos 90 días? ¿Y la tasa de fallos de cambio?

• ¿Los indicadores de experiencia (CSAT/NPS y EX de los equipos) aparecen en el comité ejecutivo tanto como los SLA?

• ¿Los principios de ITIL 4 (keep it simple & practical, start where you are, focus on value) aparecen en las herramientas del día a día — o solo en la pared?

• ¿Has invertido más en certificación que en adopción? ¿Por qué?

He pasado horas leyendo contribuciones cualificadas — acuerdos, críticas y provocaciones — y he destilado aquí lo que es señal (lo que cambia resultados) y lo que es ruido (lo que solo cambia la etiqueta). Si alguna pregunta de arriba te incomodó, perfecto: este texto es para ti.

1) El fin del mundo (que no ocurrió)

En los últimos días volví a los orígenes: me detuve a leer, con calma, decenas de comentarios de profesionales a los que respeto — gente que vive la operación, que enseña, que diseña políticas, que defiende auditorías y que sufre cuando estas se atascan. Entre elogios, críticas y provocaciones, la narrativa que más resonó fue la de un supuesto “dilema” en torno a ITIL y la idea de que “nuevos enfoques” estarían señalando por fin una salida.

Aquí va mi punto de partida: no existe dilema cuando hay una falsa dicotomía. “ITIL vs. alternativa” es una mala pregunta. El problema nunca fue ITIL, como tampoco lo fue DevOps, SRE, SIAM o cualquier otra etiqueta. El problema aparece cuando confundimos consistencia con burocracia y conexión humana con improvisación.

Si tu organización elige “consistencia sin conexión”, compras coste. Si elige “conexión sin consistencia”, compras caos. El valor nace entre ambas — exactamente en el punto donde un lenguaje común (ITIL 4) se encuentra con comportamiento, diseño y automatización (DevOps/SRE/HCD) y, cada vez más, con IA con guardrails.

2) Qué está realmente en disputa

Hay tres disputas de fondo en esta conversación:

• Lenguaje vs. comportamiento. ITIL 4 aporta vocabulario, artefactos y un Sistema de Valor del Servicio. Es esencial para la alineación y la gobernanza. Pero el vocabulario sin comportamientos (acuerdos de trabajo, feedback honesto, foco en outcomes) no cambia la realidad del usuario.

• Proceso vs. herramienta. Cuando el proceso vive fuera de la herramienta, nace un ritual paralelo que nadie respeta. Cuando el proceso está embebido (reglas, automatizaciones, plantillas), la experiencia fluye — y la gobernanza aparece en las evidencias, no en memorandos.

• Control humano vs. automatización. Aprobar cambios “en la reunión” es costoso y lento. Controlar en el pipeline (tests, seguridad, segregación de funciones, progressive delivery) es más seguro, más rápido y más auditable. No es menos gobernanza — es otra gobernanza.

“Humanising IT” habla de experiencia; “Value-Engineering” exige evidencia. La síntesis madura no elige uno u otro — une experiencia + ingeniería.

3) Del aula al gemba: dos implementaciones que he visto

Empresa A hizo todo “correctamente”: oleada de certificaciones, una decena de procesos mapeados, muchos formularios nuevos. El backlog de cambios creció, la tasa de éxito mejoró un poco, pero el MTTR y la percepción del usuario quedaron prácticamente iguales. Moraleja: conformidad sin experiencia.

Empresa B empezó más pequeña: definió 2 flujos de valor críticos, trató el servicio como producto (con owner, SLO y presupuesto), implantó cambios por riesgo dentro del pipeline y entrenó post-mortems sin culpa. En el trimestre siguiente, el MTTR bajó, la tasa de fallos de cambio se desplomó y la gente empezó a notar la diferencia. Moraleja: experiencia con consistencia.

No fue un milagro de etiqueta. Fue disciplina de adopción.

4) Cómo conciliar ITIL 4, DevOps/SRE y Diseño sin inventar moda

• Empieza por el servicio como principio de valor. Si “servicio” se trata como un departamento de bajo prestigio, pierdes patrocinio. Si se ve como una capacidad que permite resultados deseados con gestión de riesgos y costes, el juego cambia. Nombra un owner, define SLO que importen al cliente y crea un roadmap que hable de experiencia, no solo de SLA.

• Mueve el control al pipeline. La aprobación manual se convierte en cola; la evidencia automática se convierte en confianza. Policy-as-code, feature flags y progressive delivery transforman el change de ceremonia en ingeniería. ¿Auditoría? Más fácil — pruebas con logs y gates, no con actas de reuniones.

• SRE más allá del buzzword. SLO diseñados con el cliente, error budget para equilibrar estabilidad y evolución, y post-mortems sin culpa que produzcan acciones de mejora reales.

• SMO ligero. Una pequeña unidad (o capítulo) que orquesta prácticas, datos y mejora continua — no para vigilar personas, sino para habilitar equipos y evitar regresiones. El SMO garantiza que el proceso viva en la herramienta y que las métricas conversen entre áreas.

• IA con guardrails. La adopción de IA elimina tareas repetitivas y amplía el servicio, pero exige roles claros, gestión de riesgos, MLOps/ModelOps y telemetría de EX/CX para no “optimizar” lo que no importa.

5) Cuando la crítica procede — y cómo abordarla

• “Se volvió burocrático.” De acuerdo: a veces ocurre. La salida pasa por políticas ligeras, runbooks cortos, change models automatizados y SLA de ciclo para el trabajo interno.

• “Se volvió producto, perdió valor.” También sucede. Cuando el estándar se vende como fin en sí mismo, el foco se aleja del usuario. Remedio: métricas de valor/flujo/experiencia visibles para el comité ejecutivo y capacitación accesible en el día a día.

• “Muchas alternativas, pocos resultados.” Llama a esto framework fatigue. La respuesta es arquitectura: un diseño que deje claro qué es núcleo (lenguaje común, incident/change/request, mejora) y qué es opcional por contexto (SRE/DORA para Producto, FinOps/IA para Plataforma, trazas de auditoría reforzadas para Regulatorios).

6) Juzga por evidencias, no por etiquetas

Antes de “migrar de doctrina”, pregúntate:

• ¿Qué mejoró, numéricamente, en fiabilidad, velocidad y experiencia?

• ¿Cómo se sostiene el enfoque en entornos de alto riesgo y auditoría?

• ¿Existe un ecosistema (personas, contenido, prácticas) para escalar?

• ¿Cómo conversa con lo que ya funciona (ITIL/ISO/COBIT/DevOps) sin crear retrabajo?

Si la respuesta es débil, el problema no es tu “doctrina” — es el proceso de adopción.

7) Conclusión

El debate reciente aportó algo valioso: la urgencia de reconectar consistencia y conexión. Lo que pagó la cuenta en las organizaciones que observé fue una combinación mucho menos glamurosa de lo que el marketing sugiere: ITIL 4 como lengua franca, SRE/DevOps como ingeniería del flujo, diseño centrado en las personas como práctica diaria, automatización como control y datos como árbitro.

Consistencia sin conexión es coste. Conexión sin consistencia es caos. El valor ocurre en el encuentro de ambas.