ITIL: ¿Qué es y para qué sirve? (parte 4)

Éste es el cuarto y último artículo de una serie que pretende explicar, desde un punto de vista pragmático, qué es ITIL y para qué puede ser usado en las organizaciones hoy en día. En esta entrega revisaremos algunas recomendaciones a tomar en cuenta a la hora de implantar ITIL.

En los artículos anteriores revisamos qué es ITIL, revisamos lo que es la “declaración de aplicabilidad” (SOA, por sus siglas en inglés) y algunas cuestiones importantes antes de embarcarse en la implantación de procesos basados en ITIL. Pasemos ahora a ver algunas recomendaciones de cómo empezar dicha implantación.

Sin duda hay múltiples opiniones diferentes sobre el orden en que debiera planearse una implantación de ITIL. Las recomendaciones aquí expuestas son formuladas a partir de las charlas con algunos colegas y de mi experiencia particular, y no pretenden establecer una ley absoluta, sólo son eso, recomendaciones personales: a grandes rasgos yo vería el proyecto como sigue:

  1. Planeación del proyecto.
  2. Definición del catálogo de servicios.
  3. Implantación de procesos para estabilizar servicios.
  4. Implantación de procesos para mejorar servicios.
  5. Implantación de procesos para mejora continua.

Es importante mencionar que no estableceré aquí un plan detallado de cómo implantar ITIL, lo que haré será dejar de lado algunas cuestiones obvias y me concentraré en aquellos puntos que me parecen más relevantes y que he visto pueden ser causa de conflictos importantes en dicha implantación.

Planeación del proyecto

Antes que nada hay que definir bien la ruta a seguir antes de empezar a andar, es importante que el equipo encargado de la implantación considere los siguientes grupos de actividades:

  • Establecimiento de la declaración de aplicabilidad (SOA, por sus siglas en inglés): como ya mencioné en un artículo anterior, no es recomendable adoptar sólo ITIL y en realidad es necesario tener una mezcla de estándares, metodologías y mejores prácticas que cubra las necesidades particulares y el cumplimiento regulatorio de cada organización. La definición de cuáles se emplearán, y qué partes  de cada cosa serán implantadas se resume en el SOA.
  •  Definición de alcances,  responsabilidades y nivel de autoridad, sobre todo de los dueños de cada proceso: cada área y cada persona deben tener claro su rol en el proceso de implantación de ITIL. En especial es muy importante que se definan los dueños de cada proceso, normalmente llamados “process managers”, y que ellos entiendan claramente cuáles son sus funciones, sus responsabilidades y lo que se espera de ellos.
  •  Definición del plan de comunicación: si se tiene en cuenta que más que tecnología, la implantación de ITIL es un cambio organizacional, entonces queda claro que un programa de comunicación eficiente es uno de los pilares de un proyecto exitoso. Más aún, un programa de comunicación bien hecho facilitará a todos los miembros de la organización el cambio requerido.
  • Establecimiento de los lineamientos del plan de mejora continua: como dice el dicho “Roma no se construyó en un día”. Así pues, es imposible tener un proyecto que implante todos los procesos al 100% de una sola vez, al contrario, se debe establecer una hoja de ruta (road map) que considere ciclos de mejora continua para el todo y para cada una de las partes, de tal manera que la organización y sus procesos entren en un círculo virtuoso en el que se mantiene una evolución constante, alcanzando niveles de madurez cada vez más altos sin grandes sobresaltos y sin sobre esforzar todo mundo.

 

Definición del catálogo de servicios

El catálogo de servicios es uno de los pilares de toda implantación de procesos basados en ITIL, y tristemente es obviado o subestimado en muchas ocasiones. Definitivamente debe hacerse un esfuerzo importante para definir qué servicios proporciona el área de TI a sus clientes, de tal manera que todo mundo sepa qué se puede esperar al respecto. Como suelo decir en los cursos de ITIL que he impartido: ¿a quién se le ocurriría llegar a un restaurante de hamburguesas muy famoso (ese del arco dorado) y pedir una orden de tacos al pastor?, y aún si hubiera alguien que lo hiciera, probablemente la respuesta del empleado sería señalarnos, con algo de sorna, el menú para recordarnos lo que ahí se vende.

Por un lado, el catálogo de servicios dará una guía clara para definir, priorizar y desplegar los servicios proporcionados a los clientes, siempre alineados con los objetivos del negocio (no de TI), y por el otro, ayuda a comunicar clara mente el valor de lo que entrega TI y qué tan bien se desempeña.

Implantación de procesos para estabilizar servicios

En la mayoría de las organizaciones que no han implantado ITIL, aún en las más maduras, es frecuente encontrarse con cosas como las siguientes:

  • Los usuarios de TI experimentan fallas repetitivas y en ocasiones pareciera que “nadie hace nada” para encontrar una solución.
  • No hay mecanismos claros y canales únicos para reportar las fallas y para dar seguimiento a las mismas.
  • El personal de TI es constantemente interrumpido por usuarios finales.
  • Buena parte del tiempo de la gente de TI se consume en atender emergencias (lo urgente siempre quita tiempo a lo importante).

Puesto que uno de los primeros frutos de una implantación de ITIL debiera ser la estabilización de los servicios de TI, recomiendo que la implantación empiece en este orden: mesa de ayuda, administración de incidentes, administración de problemas, administración de cambios, administración de liberaciones y administración de configuraciones. Si se hace así, se obtendrán los siguientes beneficios:

  • Interacción inmediata con los usuarios, que se verán involucrados y beneficiados de la implantación de ITIL desde los primeros esfuerzos pues desde el inicio notarán mejoras en la disponibilidad, confiabilidad y estabilidad de la infraestructura de TI.
  • La implantación no será tan problemática pues en una gran cantidad de organizaciones ya se efectúan muchas de las actividades de estos procesos y sólo falta estandarizarlas, documentarlas y formalizarlas.
  • Se puede ayudar rápidamente al cumplimiento regulatorio, en especial en cuestiones que tienen que ver con SOX y Cobit.
  • Los canales de comunicación entre TI y sus usuarios serán más eficiente, proporcionando mejoras cuantitativas y cualitativas en el seguimiento a las fallas y requerimientos.
  • Por todo lo anterior, se ganará impulso y credibilidad en el proyecto.

Seguramente algunos lectores se preguntarán por qué no empezar por el proceso de administración de configuraciones. De hecho, cuando uno empieza a estudiar ITIL, podría parecer obvio que por ahí hay que empezar: ¿a quién se le ocurriría implantar procesos que modifican o requieren datos de la configuración de la infraestructura (la famosa CMDB y los CI que la componen), sin antes tener dicha información? Creo que así debiera ser en un mundo ideal donde tenemos todo el tiempo, todo el dinero y toda la gente capacitada para implantar ITIL en un solo esfuerzo inmediato, pero en el mundo real debemos optar por aproximaciones sucesivas que nos permitan ir mejorando poco a poco, ganando credibilidad y estableciendo un proceso de madurez gradual.

Uno de los problemas principales de iniciar con el proceso de administración de configuraciones es que implantarlo requiere mucho esfuerzo y no tendrá impacto significativo inicial en la eficiencia y la efectividad de los servicios. Lo mejor parece ser empezar a trabajar con la información que se tenga a la mano y dejar el proceso de administración de configuraciones para una etapa posterior.

Implantación de procesos para mejorar servicios

En una siguiente etapa recomiendo continuar con la administración de configuraciones y con una serie de procesos que ayudarán a mejorar los servicios y a proporcionar al negocio mejores dividendos de su inversión en TI, por ejemplo:

  • Administración de niveles de servicio.
  • Administración de la continuidad.
  • Administración financiera de TI.
  • Administración de la demanda.

La idea aquí es continuar elevando la madurez de lo que se empezó a implantar en la etapa anterior y empezar a incluir procesos que no sólo estabilizarán los servicios sino que empezarán a mostrar mejoras en los mismos, ayudando a la organización a saber qué está obteniendo de TI no sólo a nivel de usuarios sino también como negocio.

Implantación de procesos para mejora continua

Finalmente quedaría la implantación de procesos que permitan establecer una cultura permanente de mejora continua, como son:

  • Administración de la disponibilidad.
  • Administración de la capacidad.
  • Administración del conocimiento.
  • Generación de estrategia.

¿Por qué dejar estos procesos al final si la mejora continua y la estrategia deberían plantearse desde el principio? Porque es más fácil y más barato. Y no hay que caer en el error de decir que no se planeará ni se revisarán alcances antes de empezar (para eso se tiene una planeación de proyecto), lo que estoy diciendo aquí es que la implantación formal de estos procesos se dejará al final, debido a su complejidad, al costo y a la interdependencia que tienen con procesos implantados antes de ello.

¿Y qué sigue? Pues precisamente el ciclo de mejora continua, mejorando en cada vuelta del ciclo el nivel de madurez de lo ya implantado e incorporando el resto de los procesos y funciones.

Conclusiones

La adopción de ITIL no es fácil, rápida ni barata. Un buen proyecto llevará al menos un par de años, si no es que más, y requerirá un considerable esfuerzo para convertirse en una nueva forma de vida para la organización. Aléjese de aquellos que prometen hacerlo en menos de 6 meses, pero también aléjese de aquellos que no ofrezcan logros importantes, sobre todo en manejo de incidentes, en los primeros 6 meses de implantación.

Recuerde siempre que ITIL, como muchas otras cosas sólo es un medio para obtener mejores servicios de TI que ayuden al negocio a lograr sus objetivos, no hay que convertir los medios en el fin, buscar la eficacia antes que la eficiencia, no  hacer de ITIL una religión dogmática, rígida e intransigente y recordar que el mantra del área ideal de TI es “el negocio manda y vivimos para los usuarios, no al revés”. En otras palabras, parafraseando a Esther Dyson,  no dejes tu sentido común de lado, piensa primero en lo que quieres mejorar y como los estándares, mejores prácticas y marcos de referencia pueden ayudarte a hacerlo. No pienses primero en ellos…

[email protected]

Para consultar la primera parte de esta serie, oprima aquí.

Para consultar la segunda parte de esta serie, oprima aquí.

Para consultar la tercera parte de esta serie, oprima aquí.

Héctor Acevedo Juárez. CISSP, CISA, CGEIT, ITIL y MCSE

Trabaja en Scitum desde el año 2004. Actualmente es Subdirector Comercial para Latam y Servicios paquetizados. Previamente se desempeñó como Gerente de Soluciones de Servicios para Latinoamérica, Gerente de Preventa de Servicios Administrados, subgerente SCISO y consultor de procesos. Anteriormente trabajó como Gerente de Tecnologías de Información para NextiraOne México, S.A. de C.V., Gerente de Informática en Intersys y cuenta con experiencia en la operación y planeación de infraestructura de TI y en valoración, diseño e implantación de procesos de TI. Ha impartido cursos y conferencias sobre Lotus Notes, sistemas operativos Microsoft, CobiT, auditoría de sistemas, ITIL, temas varios de redes y telecomunicaciones. Es fundador y editor en jefe de la revista Magazcitum (www.magazcitum.com.mx) 

Tags:

  52 comments for “ITIL: ¿Qué es y para qué sirve? (parte 4)

  1. Ignacio
    14/11/2018 at 2:21 AM

    Hola, Héctor.

    He leído todo el artículo porque estoy tratando de entender lo que es ITIL y aunque tu exposición es bastante más clara que lo que pone, por ejemplo, en la Wikipedia, sigo echando de menos ideas más concretas. Todo esto de ITIL me suena a palabrería vacía sin demasiado significado. Parece que todo el que habla de este tema se haya propuesto no dejar claro de qué trata lo que se explica. No hay ni un solo ejemplo concreto de las funciones finales de las personas implicadas en estos proyectos, a qué se dedicarán, cómo lo harán, quiénes lo harán…

    Es decir, suena a vender humo: Todo es muy bonito, una vez implantado, el departamento de TI irá muy bien, es la mejor metodología, los servicios TI se administran por procesos… La palabra “administrar” está por todas partes, al igual que las palabras “servicios” y “procesos”, pero no se concreta nada. ¿De qué procesos estamos hablando? ¿Qué se administra? ¿En serio, ni un solo ejemplo de servicio? Es teoría demasiado genérica, es imposible hacerse una idea de los conceptos reales de los que se está hablando.

    Es como si digo: “Para la gestión de una empresa es necesario que todos los actores implicados sean conscientes de su rol en el entramado empresarial y que se creen comisiones y subcomisiones con tareas bien precisas. Dichas comisiones serán las encargadas de gestionar sus respectivos departamentos y serán imprescindibles para mejorar la comunicación interdepartamental de los empleados, los cuales deberán asumir sus funciones usando las metodologías propuestas”. Posiblemente sea cierto, no lo sé, pero lo que tengo claro es que cualquiera que trate de aprender a llevar una empresa con consejos como éste fracasará estrepitosamente, porque no he dicho nada, sólo me he inventado una frase vacía poniendo palabras rimbombantes una detrás de la otra.

    Yo venía a aprender qué es ITIL y en qué consiste y me he quedado igual o peor que antes. Esto es lo que he sacado en claro de ITIL: es algo de difícil implantación que sirve para algo y suena a importante pero no tengo la más mínima idea de qué es, para qué sirve, cómo se utiliza ni de qué forma mejora los problemas existentes, que tampoco sé cuáles son.

    Me gustaría leer un par de ejemplos de cómo se gestionan las tecnologías de la información en una empresa antes y después de instaurar ITIL. Pero ejemplos concretos, algo del estilo: “Antes la conexión a Internet de los empleados fallaba a menudo por esto y aquello, pero desde que el empleado tal utiliza la técnica que recibe este nombre y de esta forma específica, los resultados han mejorado”. O bien: “Antes el servicio de correo que se ofrece a los usuarios externos tenía problemas de rendimiento, pero cuando hicimos esto concreto aplicando esta buena práctica de ITIL que se llama así, se solucionó el problema”. O bien: “Los empleados siempre tenían problemas con su hardware, pero hicimos tal cosa enfocada de esta manera y ahora las incidencias son mínimas”. Entiendo que no todas las empresas son iguales, pero no estamos hablando de las frutas de una frutería y de los DVDs de una gran tienda online, estamos hablando de TI, que es algo que muchas empresas tienen en común (aunque a escalas diferentes) y cuyos problemas todas quieren solucionar.

    Tiene que ser posible explicar brevemente qué diantres es ITIL y para qué sirve sin tener que leer 30 libros que preveo tan llenos de palabrería como escasos en contenido.

    Saludos y perdón por la crítica.

  2. 14/11/2018 at 7:31 PM

    Hola Ignacio

    Nada que perdonar, al contrario, agradezco mucho tu mensaje y la crítica, sobre todo por lo bien pensada que está.

    Coincido en varias cosas contigo, por favor disculpa las fallas del texto, que son solo mías. Agregaría que una pequeña parte del problema también viene del hecho de que ITIL dice qué hacer, pero no dice nada de los cómos y mucho menos de los cuántos.

    Prometo que en una siguiente edición de la revista estaré publicando algunos ejemplos del tipo de los que pides en tu penúltimo párrafo. Te pido un poco de paciencia para que puedas leerlo.

    Saludos
    Carpe diem

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.