Seleccione su oficina Quint:

Armonizando DevOps e ITIL®: El yin y el yang que ofrece un cambio efectivo

Harmonizing DevOps and ITIL
¿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

O

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

ITIL gives you Stability

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.

In Service Design

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.

Service Transition

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.

configuration management

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.

Service Operations

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.

Turbo boost: Lean IT

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.

Escrito por Joel Pomales, Senior Consultant en Quint Wellington Redwood.

Lean IT ITIL® DevOps

Próximos eventos