¿Estás pensando en descansar de los procesos basados en ITIL porque has

oído que ‘hacer DevOps’ es mejor? ¿Crees que tus prácticas actuales de
gestión de servicios son lentas, infladas y que no tienes posibilidad de
transición a DevOps? Deshacerse de ITIL no es necesariamente un buen
movimiento; sería únicamente una receta para el desastre. Vamos a examinar
cómo DevOps e ITIL pueden proporcionar equilibrio y serias mejoras a tus
capacidades.

Si trabajas en TI en cualquier tipo de capacidad, es difícil escapar de la

atracción de DevOps. Del mismo modo que una estrella del pop del momento,
se ha vuelto muy frecuente en las principales publicaciones de TI y en las redes
sociales. En pocas palabras, han revolucionado completamente el sector.
DevOps tiene también un efecto involuntario: ha proporcionado a muchos de
los detractores de ITIL otra bala para disparar contra la antigua infraestructura,
darla por muerta y enterrarla. Sin embargo, aquellos que piensan de esta
manera se están equivocando, ya que ITIL aporta más de lo que creen. Antes
de analizar cómo ITIL puede servir a tus iniciativas DevOps, vamos a explorar
la ‘mala reputación’ de ITIL, y cómo evolucionó a través de los años. Para
algunos, ITIL siempre ha significado mucho trabajo y muchos gastos. Hay
demasiados planes, bases de datos, procesos, documentos, y artefactos. De
hecho, esta acepción de trabajo duro refleja algo de verdad: si tuvieses que
llevar a cabo ‘ITIL’ tal y como se presenta en los libros, tu trabajo sólo giraría en
torno a gestionar tu sistema de gestión de servicios (SMS), y no a los servicios
que estás proporcionando. Esto ha dado lugar a que muchas organizaciones
permanezcan dentro de los límites de lo que ya saben hacer (incidente,
cambio) antes de que llegara ITIL, y en ocasiones, con las cosas que ellos
creen que comprenden (problema, conocimiento, configuración, disponibilidad).
Una parte de la culpa recae en muchos de los proveedores de Gestión de
Servicios de TI (ITSM). Desde los viejos tiempos de ITIL v2, los proveedores
prometen soluciones ‘ITIL®-in-a-box’ que prometen ‘resultados rápidos’ y ‘el
cumplimiento de ITIL’. Lo que sucede después es lo siguiente:

a.) Las Organizaciones tienden a permanecer dentro de la zona de confort que

proporciona la herramienta, ignorando otros elementos que necesitan incluirse
en la gestión y gobierno de los servicios

b.) No están satisfechos con lo que la herramienta proporciona, así que tienden
a buscar funcionalidades que no están incluidas, porque piensan que existe
una necesidad que nadie planteó y para la que no se ha construido ningún
requisito.

Además, muchas personas (y consultores) se convirtieron en ‘puristas de ITIL’.

Estas eran personas que declararon pública y frecuentemente que ITIL tenía
que aplicarse ‘a pies juntillas’. Intentaron convertir ITIL en un estándar, pero
está claro que no lo es. Esto derivó en trabajo innecesario y en actividades sin
valor añadido que provocaron la fatiga en muchas personas hacia ITIL. Este
trabajo innecesario se reflejó en nuevas tareas cotidianas, y supuso demasiado
para que las organizaciones pudiesen manejarlo. Por ejemplo, si se tarda más
de cinco minutos en rellenar un ticket de incidente, o una petición de cambio,
es probable que se haya sobre-diseñado y sobre-pensado el proceso de
ejecución de las actividades.

Muchas organizaciones comenzaron ‘haciendo’ ITIL porque pensaron que sería

una gran idea o porque pensaron que necesitaban ser ‘compatibles con’ ITIL
para realizar su trabajo. Por desgracia, muchas ignoraron el hecho de que ITIL
requiere salir fuera y comprender a los clientes y sus requisitos. Todos lo
conseguimos; históricamente, a aquellas personas de TI no les gustaba
realmente tratar con esos clientes molestos. Saben muy poco sobre lo que
hacen. Odiamos explicarles qué es el lenguaje SQR, lo que hace un firewall y
qué scripts se ejecutan en qué momentos y para qué. Somos maestros de
nuestro reino, y desde fuera no nos entienden. Ellos no se preocupan por todo
eso. Simplemente quieren procesar una factura y moverla de un sitio a otro.

Conoce al nuevo jefe…

Introduce DevOps, que ha venido con la promesa de cambiar el viejo, estático
mundo de la antigua TI mediante la destrucción de las viejas costumbres y
golpeando rápidamente a la burocracia y antiguos estilos de trabajo. Y sí, eso
significa dar patadas a ITIL, a muchos marcos de soporte y estándares para
dejarlos atrás. Esto llegó con grandes intenciones, pero si ITIL no funcionaba
antes en una compañía, no hay forma de que DevOps beneficie ahora a esa
organización. De hecho, puede realmente hacer que empeoren las cosas.
DevOps no es simplemente hacer las cosas más rápido. Sí, es un cambio
cultural, pero el cambio de la cultura por sí sola no es suficiente. DevOps se
queda corto en tratar cómo entender y aproximarse a los clientes, cómo
gestionar el riesgo, cómo hacer diseño de calidad, transiciones, y así
sucesivamente. Amplificar los ciclos de feedback está muy bien, pero si la parte
de cultura y diseño no es buena, ¡se está amplificando lo malo! De modo que
DevOps no es una varita mágica, y tampoco lo es ITIL. Ambos son enfoques
para la transformación de la cultura y modos en los que trabaja una
organización. Permíteles funcionar conjuntamente con el objetivo de
proporcionar motor para un profundo cambio cultural en la organización. En
este ambiente tecnológico tan rápido y dinámico, ITIL está lejos de suponer un
lastre. ITIL todavía puede aportar un método de trabajo y diseño estructurado y
organizado con los servicios de TI y sus ciclos de vida. Aporta perspectivas e
ideas sobre cómo desarrollarlos, lo que se debe considerar al acercarse a los
clientes para reunir requisitos y comprender sus objetivos de negocio, la forma
de medir la demanda, y la manera de mejorar los servicios. DevOps trae el
trabajo colaborativo, las tasas de despliegue rápido, una entrega más ágil y un
enfoque hacia el trabajo importante. ¿Cómo funcionarán exactamente ITIL y
DevOps juntos?

ITIL aporta estabilidad

La fase del ciclo de vida de Estrategia de Servicio proporciona información
relacionada con los servicios existentes y los propuestos a través de la gestión
del portfolio de servicios. Mediante la gestión de la demanda, se pueden
entender los perfiles de cada usuario y los patrones de la actividad de negocio.
Es en la Estrategia de Servicio donde podrás identificar la manera en la que los
servicios permiten los resultados de negocio, y también donde podrás definir
los modelos de tus servicios. Antes de comenzar con DevOps, querrás
entender exactamente quiénes son tus clientes, qué es lo que quieren, y de
qué manera puedes proporcionar valor. Querrás estar seguro de que
comprendes sus requisitos, cómo se observa el éxito desde una perspectiva
empresarial, y definir las funciones vitales del negocio (VBFs). Esto asegurará
que existe un propósito detrás de lo relacionado con DevOps.

En el diseño de Servicio, realiza actividades que solidifiquen lo que se había

visualizado durante la estrategia y asegura que el servicio esté ‘listo para su
uso’. Los procesos de gestión de disponibilidad, capacidad, seguridad de la
información y continuidad del servicio TI aseguran que tus servicios estarán
donde se acordó con el cliente. Esta es una de las fases del ciclo de vida más
importantes y más valiosas en ITIL. Tener un servicio bien diseñado facilitará la
transición desde ‘Dev’ a ‘Ops’ porque estarás trabajando con un paquete de
diseño sólido apoyado por todos los recursos de la organización sin
ambigüedad ni desviación. Es importante, por ello, asegurarse de diseñar el
modelo en su preciso alcance. Situ cliente no preguntó por un aspecto en
concreto, ¿por qué debería ir en tu paquete de diseño? No será justo para las
operaciones si estuviesen hechas para dar soporte a algo que los clientes no
quieren o buscan.

La Transición del Servicio es el gran orquestador. Cuenta con todos los

procesos que permiten una transferencia limpia entre el diseño y las
operaciones. De todos los procesos en este ciclo de vida, la planificación y
soporte a la transición es uno de los más olvidados, y es un grave error. Define
la estrategia de transición, coordina todos los recursos y capacidades
necesarias, y proporciona supervisión de todas las actividades de la transición.
¿Quieres asegurar que todas tus Operaciones estén listas para manejar
cualquier cosa que realice el Desarrollo? Dedica tiempo a comprender esta
fase y cómo integrar todos los elementos para proporcionar una buena
transición.

El proceso de gestión de la configuración y su asociada base de datos de

gestión de la configuración (CMDB) están dentro del ámbito de la Transición de
Servicio. Podrías estar pensando, “Mi organización trató de
construir/implementar un CMDB, fracasó de forma espectacular y empleamos
tanto tiempo y dinero en ello que no queremos hacerlo otra vez”. Podría haber
fracasado porque fuiste demasiado ambicioso en cuanto al tamaño y amplitud
del proyecto. Piensa en el alcance que estableciste en el Diseño de Servicio. Si
el cliente no preguntó por un aspecto, y no lo diseñaste para ello, ¿por qué
estás realizando un seguimiento de esa funcionalidad? Realiza un seguimiento
de los elementos de configuración (CIs) que sean absolutamente necesarios
para el alcance de los servicios, abstrae algunos de los servicios de soporte y
elementos de configuración (CIs) según corresponda. Utiliza la automatización
sabiamente siempre que corresponda, y usa acuerdos de nivel operacional
(OLAs) o registros de riesgos para documentar y monitorizar aquellos CIs que
estén excluidos del ámbito de aplicación. Además asegura que el proceso de
gestión del conocimiento se mantenga fuerte. La gestión del conocimiento no
sirve únicamente para el Help Desk; proporciona información a todos los
demás procesos del ciclo de vida en ITIL. Fortalece tus recursos para registrar
todo conocimiento que se encuentre, ya que beneficiará en la mejora de la
estrategia, el diseño, la transición y las operaciones.

Las Operaciones de Servicio es dónde empezamos a ver los resultados. Aquí

es donde el usuario final interacciona con lo que ha sido diseñado, y si se hizo
un buen trabajo, es donde ven el valor en lo que están pagando. Si no hiciste
las tareas en el diseño, aquí es donde los usuarios se darán cuenta de ello, y
donde se quejarán. En este punto clave es donde debemos elevar a la gente
de operaciones, especialmente a los agentes de Service Desk, entre las fases
de diseño y transición (Dev) y proporcionarles la oportunidad de contribuir.
Podrías pensar que los agentes de Service Desk no tienen nada con lo que
contribuir en el desarrollo de un servicio. Piensa de nuevo, porque son los que
están directamente en sintonía con lo que los usuarios están viendo y
sintiendo. Pueden aportar datos, perspectivas, ideas, visión y conocimiento. La
Mejora Continua del Servicio (CSI) proporciona las herramientas necesarias
para medir y mejorar los procesos, actividades, y alimentar toda esa
información y trasladarla al resto de fases del ciclo de vida a través del registro
de CSI y los planes de mejora de servicio.

Verdadera sinergia
DevOps e ITIL necesitan trabajar en una vía de doble sentido, pero a fin de que
puedan trabajar mejor juntos, echa un vistazo a cómo los procesos y
actividades actuales generan desperdicios. Esto se cumple especialmente con
ITIL, ya que, si se toma literalmente puede generar bastante poco y que no
aporte ningún valor a la organización, a los clientes o usuarios. Uno de los
principios fundamentales de DevOps es aportar rapidez en la entrega y en las
operaciones, y es una de las razones por las que ITIL ha sido rechazado en los
últimos tiempos debido a que se percibe como un montón de trabajo. Como se
menciona anteriormente, ITIL aporta un surtido de ideas relacionadas con la
estabilidad del servicio, el diseño y el rigor de la transición.

Activación del Turbo: Lean IT

Una de las maneras en las que DevOps e ITIL pueden trabajar juntos es
examinando los procesos y actividades a través de unas lentes de Lean, ya
que te permite examinar cómo tus actividades apoyan a los resultados del
cliente, cómo esas actividades fluyen a través de tu organización, y cómo
identificar actividades derrochadoras y eliminarlas. Lean IT es la extensión de
lean manufacturing y de los principios de lean service para el desarrollo y la
gestión de productos y servicios de tecnología de la información. La
preocupación principal de Lean IT está en la identificación y la eliminación de
desperdicios de productos y servicios, donde el desperdicio es algo que no
añade ningún valor. El desperdicio, en cada uno de sus tres tipos, puede ocurrir
en cualquiera de las cinco fases del ciclo de vida de ITIL y puede realmente
arrastrar hacia abajo las actividades DevOps y es esto, no ITIL en sí, lo que va
a dejar DevOps atrás. Además de la identificación y la gestión de los
desperdicios, Lean IT también se ocupa de otros elementos relacionados con la
ejecución de los procesos en una organización, y funciona bien dentro de la
estructura de ITIL. Por ejemplo:
 La identificación y aplicación de pequeñas mejoras en el tiempo a través de la
ejecución de eventos Kaizen: Una aproximación a la resolución de problemas y
la base para la mejora continua (ITIL’s CSI).
 Identificación de los cinco elementos clave: rendimiento, proceso, organización
y comportamiento y actitud (aplicable a través del ciclo de vida de ITIL).
 Identificación de la Voz del Cliente (VoC) y de la cadena de valor ( aplicable a
través de la cadena de valor, pero especialmente útil en la definición de la
estrategia y el diseño de actividades).

DevOps + ITIL + Lean IT = GO!

Así pues, ¿deseas empezar a utilizar DevOps e ITIL juntos como compañeros?
Genial. No te precipites a ciegas en ello. Primero debes considerar lo siguiente:

 Comienza con lo que tienes. Consigue datos relacionados con la ejecución de

tus procesos, los resultados de negocio sustentados por las métricas existentes
por los indicadores clave de rendimiento. Si consideras que tu información está
incompleta, ¡habrás descubierto la primera oportunidad de mejora aquí!
 Observa la documentación de los procesos relacionados con ITIL de manera
crítica, con un ojo hacia la consecución del sistema más adecuado para tu
organización. Si en algún punto que ya hayas hecho todo con ITIL, sientes que
la inversión no supuso buenos rendimientos, o que la gente se hartó de ello y
no siguieron lo que se documentó, podrías optar por el uso de los principios
Lean IT para identificar desperdicios, y aprovechar esas disciplinas para
identificar y permitir oportunidades de mejora.
 Esto también es aplicable a las herramientas de ITSM. Si tu proveedor te
vendió ITIL ‘fuera de la caja’ o si sólo se tradujeron las malas prácticas de una
herramienta a otra; echa un vistazo a todas esas actividades derrochadoras e
inicia varias actividades de mejoras.
 Habla con los clientes. No especules sobre lo que hacen. Rompe los muros y
trasládate a su mesa. Acompáñales, y entiende exactamente cómo la TI
contribuye a su negocio. Si dicen que están demasiado ocupados para
ayudarte, sigue buscándoles. Acércate al negocio SME que estará más que
feliz de compartir contigo la manera en la que trabaja, y después acércale a tus
actividades de coordinación de la transición y a tu diseño. ¡Verás las cosas
desde distintas perspectivas!
 Asegúrate de que comprendes los servicios que estás entregando. ¿No tienes
una cartera de servicios? ¡No hay problema! De nuevo, comienza con lo que
tienes, pero asegúrate que de comprendas lo que será necesario lo más pronto
posible.
 No esperes que las operaciones hagan el Ops en DevOps si no los involucras
en la estrategia, el diseño y las actividades de transición. Inclúyelos desde el
principio, y apórtales el poder para que sean los propietarios del diseño del
servicio y de la transición al igual que los arquitectos empresariales,
desarrolladores y managers de proyectos. ¡Y bajo ningún concepto los
infravalores!
 Junto con la identificación de los desperdicios, Lean IT introduce además
cambios culturales y de comportamiento mediante la búsqueda de una cultura
de mejoras y respeto al individuo y a su trabajo. Utiliza esto para intercambiar
una cultura de culpa por una cultura de mejora, respeto al individuo y a su
trabajo.

Si lo eliges, podrías hacer DevOps sin ITIL. Pero tal y como se explica, DevOps
por sí solo no será tan exitoso como se espera. Utiliza ITIL sabiamente,
especialmente a través de la aplicación de los principios de Lean IT, y podrás
comenzar a recorrer el camino de las actividades DevOps en tu organización.