ITIL o no ITIL, esa es la cuestión

0

Cuando se definen procesos para la gestión de servicios de TI es fácil encontrarse con preguntas para las que no hay una respuesta clara. En esos casos es normal escuchar: “ITIL recomienda…” Dependiendo de la audiencia, la respuesta puede ser seguir la recomendación de ITIL o que alguno de los asistentes responda con: “Yo no creo en ITIL. Es muy bonito en el papel, pero cuando lo aplicas descubres que no es la mejor solución”.

En este artículo reviso el concepto de ITIL y algunas recomendaciones sobre su aplicación.

¿Para qué está diseñado ITIL?

Para responder a esta pregunta hay que revisar el origen de ITIL. Las raíces de ITIL se ubican en la necesidad del gobierno británico de controlar los contratos con sus proveedores de TI. El gobierno británico es una organización muy grande, con un montón de contratos de TI diferentes, que en aquel momento carecían de un lenguaje, metodología o herramientas de control comunes. El gobierno británico creó entonces un conjunto de recomendaciones y buenas prácticas que todos los proveedores deberían seguir: ITIL.

De aquí podemos deducir que ITIL fue diseñado para:

  • Una gran organización
  • Cultura anglosajona

La gestión de una empresa pequeña es muy diferente de la de un gobierno. Por lo que afirmar que las mejores prácticas son las mismas en ambos casos, es simplemente mentira. Además la cultura de gestión y de forma de hacer las cosas cambia de un lugar a otro, por lo que afirmar que las buenas prácticas británicas aplican a todo el mundo, también es mentira.

Tamaño de la empresa

A ITIL le pasa como a PMBOK, lo diseñaron pensando a lo grande. Cuanto más grande sea tu organización, más se puede confiar en las buenas prácticas de ITIL. Para organizaciones pequeñas hay que simplificar las prácticas y no caer en la burocracia. Y para las más pequeñas puede ser incluso recomendable romper algunas reglas. Por ejemplo ITIL recomienda que los roles de gestor de incidencias y de problemas no recaigan en la misma persona porque provocarían un conflicto de intereses. Si tu departamento de soporte de TI tiene 5 personas, lo más recomendable es que una sola persona sea el responsable de gestión de incidencias, problemas y cambios (además de técnico experto).

Consideraciones sobre la cultura

Hay dos tipos de cultura a considerar. La cultura de tu organización y la cultura de tu región. La primera es “la forma de hacer las cosas” en tu organización. Es algo que se puede cambiar y no debe servir de excusa para no aplicar buenas prácticas. Por ejemplo decir que no diferenciamos entre incidencias y peticiones porque “de siempre hemos tenidos tickets” es una mala excusa.

En cambio la cultura de la región es un aspecto muy importante a considerar. Hay acciones que algún país se consideran como símbolo de calidad y en otras como molestia. Es decir, hay buenas prácticas en ITIL que en una determinada región pueden no ser tan buenas. Y esta cultura puede llegar a ser un aspecto muy local a tener en cuenta si prestamos servicio en zonas con distinta cultura. Como anécdota, hace 10 años en una charla de café un madrileño y un mallorquín hablaban sobre la atención que daban los vendedores del Corte Inglés. Al madrileño le molestaba que no le viniesen a atender y al mallorquín le molestaba que le “acosasen” y no le dejasen comprar tranquilo. Esto mismo se puede aplicar en servicios de TI en los que en un sitio consideran símbolo de calidad que el Centro de Atención al Usuario te llame para confirmar la correcta resolución del caso y en otro son unos pesaos que siempre están llamando en vez de arreglar cosas.

Por ejemplo, ITIL recomienda que la urgencia sea determinada por el usuario. Puede que esto en UK funcione, pero en España, ya os digo yo que no. Si le preguntas a un usuario como de urgente es su problema, te dirá que de la máxima urgencia, y si le preguntas como de crítico es su trabajo, te dirá que es el más importante. Y más aún cuando vea que la velocidad a la que le resuelven el caso depende de esa respuesta. Por lo tanto para determinar la urgencia es mejor preguntarle al usuario indirectamente el grado bloqueo que sufre y determinar la urgencia a partir de ahí, como ya expuse en priorizando incidencias.

Pensamiento final

Como norma general, sigue las recomendaciones de ITIL si no hay un claro motivo para no hacerlo. También considera el motivo de esa razón para no hacerlo. Si el origen es “Esta no es la manera en la que solemos hacer las cosas en la empresa”, no lo aceptes. Si el origen es un motivo relacionado con restricciones de nuestros clientes, cultura de la región o tamaño de la organización, entonces lo podemos aceptar.

ITIL

About author

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert y va en camino de certificarse como PMP. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Idiso, empresa de servicios de distribución hotelera, como responsable del equipo de desarrollo web.

No comments

Te puede interesar...

Diseñando el WBS

Uno de los grandes conceptos que aprendí de leer la guía del PMBOK® es el WBS, o Estructura de Descomposición de Trabajo. Pasé de una ...