Ideas de HVIT para cambiar tu foma de trabajar
4 Ideas de HVIT en ITIL4 que Cambiarán tu Forma de Trabajar
Cuando escuchas la palabra "ITIL", ¿qué te viene a la mente? Si eres como la mayorÃa, probablemente pienses en procesos pesados, burocracia, manuales enormes y una forma de trabajar que parece diseñada para frenar cualquier atisbo de agilidad. Durante años, ITIL ha cargado con la reputación de ser un marco rÃgido, más adecuado para la era de los mainframes que para el ritmo frenético del mundo digital actual.
Pero, ¿y si te dijera que esa percepción está obsoleta? En la era de la transformación digital, el nuevo ITIL 4, y en particular su guÃa de "High-velocity IT" (TI de Alta Velocidad),esconde una filosofÃa sorprendentemente moderna, ágil y, sobre todo, centrada en las personas. Lejos de ser un conjunto de reglas prescriptivas, es una colección de modelos mentales diseñados para prosperar en la complejidad y la incertidumbre.
Este artÃculo destila cuatro de las ideas más impactantes y contraintuitivas de esta guÃa. Son conceptos que no solo desafÃan lo que creÃas saber sobre ITIL, sino que tienen el potencial de transformar radicalmente la forma en que tu equipo de tecnologÃa piensa, colabora y entrega valor.
--------------------------------------------------------------
1. Para ser estable, cambia constantemente (pero en pequeño)
La creencia tradicional en TI era simple: el cambio es el enemigo de la estabilidad. Cada despliegue era un riesgo, cada modificación una potencial fuente de caos. Por lo tanto, el objetivo era minimizar los cambios para mantener los sistemas funcionando sin interrupciones.
ITIL 4 invierte esta lógica por completo, explicando que al reducir el tamaño de los cambios, se reduce el riesgo de interrupción. Cambios más pequeños y frecuentes mejoran la capacidad de la organización para cambiar, reduciendo asà el riesgo de disrupción. La verdadera estabilidad no proviene de evitar el cambio, sino de abrazarlo a través de modificaciones pequeñas y frecuentes.
Este concepto es increÃblemente poderoso porque libera a los equipos del miedo paralizante al despliegue. En lugar de ver el cambio como una amenaza, lo convierte en un músculo que se fortalece con el ejercicio constante. La agilidad deja de ser enemiga de la resiliencia para convertirse en su principal herramienta. Cuando cambiar es una rutina de bajo riesgo, la organización se vuelve inherentemente más estable y adaptable, sentando las bases para una TI de alta velocidad.
---------------------------------------------------------------
2. Olvida la deuda técnica, tu mayor problema es la "deuda social"
En el mundo de la tecnologÃa, todos conocemos el concepto de "deuda técnica": los atajos y soluciones rápidas en el código que, a largo plazo, ralentizan el desarrollo futuro. Es un problema real, pero la guÃa de "High-velocity IT" nos alerta sobre una deuda mucho más peligrosa y a menudo invisible: la deuda social.
En el prefacio del documento, el editor principal, Mark Smalley, hace una afirmación sorprendente para un texto de gestión de TI:
"Many organizations not only have accrued technical debt in their software as a result of taking conscious or unconscious shortcuts, they also have a considerable social debt that needs repayment."
Esta "deuda social" se refiere al coste de una cultura de trabajo tóxica, la falta de seguridad psicológica, el agotamiento del personal y la erosión de la confianza. La guÃa de "High-velocity IT" es radical al afirmar que la velocidad sostenible es imposible de alcanzar sobre una base de desconfianza y agotamiento. La idea es revolucionaria porque sitúa a las personas en el centro absoluto de la alta velocidad. No puedes tener equipos rápidos e innovadores si la gente tiene miedo a hablar o a fallar. Pagar la deuda social, creando un entorno de confianza, no es un lujo secundario; es el prerrequisito fundamental para la agilidad sostenible.
---------------------------------------------------------------
3. Deja de buscar la "causa raÃz": la catástrofe nunca tiene un solo culpable
Una de las prácticas más arraigadas en la gestión de incidentes es el análisis de "causa raÃz" (Root Cause Analysis). La idea es que, tras un fallo, podemos investigar hasta encontrar ese único error, ese único culpable —ya sea una persona, un proceso o una pieza de código— que originó todo el problema.
La guÃa de ITIL 4, basándose en la ciencia de los sistemas complejos, destroza esta idea. Sostiene que en los sistemas digitales modernos, que son inherentemente complejos, los grandes fallos casi nunca tienen una sola causa. En cambio, son el resultado de una combinación impredecible de múltiples fallas latentes que han estado presentes en el sistema durante mucho tiempo.
El texto cita al investigador Richard Cook para subrayar este punto de forma contundente:
"Post-accident attribution to a ‘root cause’ is fundamentally wrong."
El impacto de esta idea es profundo. Cambia el objetivo de un post-mortem de "encontrar al culpable" a "entender el sistema". Fomenta una cultura sin culpa (blameless culture),donde los ingenieros pueden analizar los fallos de forma abierta y honesta sin miedo al castigo. Esta cultura sin culpa no es un simple ejercicio de recursos humanos; es un acelerador de la innovación. Cuando los equipos no temen el castigo, experimentan más, se recuperan de los fallos más rápido y, en última instancia, entregan valor a una velocidad que las culturas basadas en el miedo no pueden igualar.
------------------------------------------------------------------
4. "Terminado" no es cuando entregas el código, es cuando el cliente obtiene valor
Para muchos equipos de desarrollo, la definición de "terminado" (Definition of Done) significa que el código está escrito, probado y es "potencialmente desplegable". Los equipos de DevOps llevan esto un paso más allá, considerando el trabajo terminado cuando el código ha sido desplegado en producción y está disponible para los usuarios.
ITIL 4 propone una definición aún más radical y centrada en el servicio. Argumenta que desde una perspectiva de servicio, donde el valor se co-crea entre el proveedor y el consumidor, el trabajo no está realmente terminado hasta que el cliente logra su objetivo.
"From a co-creational service perspective, a better way to define work as ‘done’ is when users have achieved the desired outcomes from their investments."
Piénsalo por un momento. Esto significa que la responsabilidad del equipo de TI no termina en el momento del despliegue. El trabajo continúa hasta que se confirma que los usuarios no solo tienen acceso a la nueva funcionalidad, sino que la están utilizando de manera efectiva y están obteniendo el valor por el cual se hizo la inversión. Esta mentalidad fomenta una verdadera propiedad de extremo a extremo y alinea completamente el trabajo tecnológico con los resultados del negocio, asegurando que la velocidad de entrega se traduzca en velocidad de creación de valor real.
------------------------------------------------------------------
5. Técnicas para Alta velocidad en TI
Conclusión
Estas cuatro ideas demuestran que ITIL 4, lejos de ser un manual de procesos obsoleto, es una guÃa estratégica y moderna para navegar la complejidad del entorno digital. Prioriza la cultura sobre los procesos, la agilidad mental sobre los planes rÃgidos y los resultados de valor sobre las métricas de actividad. Nos invita a cuestionar algunas de las "verdades" más arraigadas en la gestión tecnológica.
Al adoptar estas ideas contraintuitivas —cambiar constantemente para ser estables, priorizar la deuda social, abandonar la caza de brujas de la "causa raÃz" y redefinir nuestro trabajo en torno al valor del cliente—, podemos empezar a construir organizaciones tecnológicas verdaderamente ágiles, resilientes y humanas.Considerando estas ideas, ¿cuál es la primera "regla sagrada" de tu equipo que necesita ser cuestionada?
ArtÃculo por Alexander Ramos | PRAKTIVA
Publicado 16 Oct 2025
