¿Se puede aplicar realmente ITIL en una PYME?

Directores y Técnicos que se han formado o hasta certificado en ITIL olvidan sus principios a las pocas semanas ante la imposibilidad de aplicación en sus Departamentos, o simplemente por aplazarla hasta llegar a olvidar qué aspectos podrían mejorar en sus servicios de Soporte utilizando estas Mejores Prácticas.
Los cientos de certificados que se expiden anualmente en España, no se corresponden con el número de Empresas donde se aplica. Las razones suelen ser una o varias de las siguientes:

1. Demasiadas urgencias que aplazan su planificación e implantación

2. Dirección no convencida de su utilidad y poco proclive a apoyar en la práctica su implantación.

3. Efecto parálisis por análisis. ITIL ofrece tantas posibilidades que no se sabe por donde empezar y se aplaza eternamente, hasta que se olvidan sus conceptos.

Yo mismo he sufrido las 3 alguna vez durante mis 25 años de Dirección de Equipos de IT, En muchas ocasiones donde se primaba por las Direcciones el mantener profesionales certificados con objeto de ganar concursos de adjudicación de Proyectos y nada más.

Donde mejor podemos comprobar implantaciones de ITIL adecuadas es en los equipos de soporte de empresas fuertemente tecnológicas como DELL, HP, APPLE o Microsoft, cuyo nivel de madurez en atención a usuarios está muy por delante del resto, que continúan utilizando metodologías obsoletas de resolución de incidencias.

Y eso que los principios de ITIL pueden aplicarse en cualquier Empresa o Departamento que preste servicios internos o externos, estén relacionados o no con Sistemas de Información. La hoja de ruta, según el marco ITIL, consiste primero  en definir la Estrategia con la que orientaremos nuestros servicios, después realizaremos el Diseño que utilizaremos para llevarlos a cabo, y a continuación definiremos la táctica (Transición/Gestión de Cambios y las Operaciones para llevarlos a cabo). Todos estos pasos son susceptibles de mejorarse mediante el Proceso de Mejora Continua.

La aplicación de ITIL en las empresas españolas aparte de escasa, es bastante deficiente, al menos desde la experiencia de usuario: Sólo hay que llamar a cualquiera de las 3 operadoras de Telecomunicaciones más importantes de España para reportar cualquier incidencia y comprobaremos como tendremos que hablar primero con un contestador automatizado de opciones, y luego hasta con 3 técnicos de nivel 1, sin que se escale al siguiente nivel hasta hacernos perder 20 o 30 minutos. En todas las interacciones deberemos indicar nuestro problema desde cero, una y otra vez.

Si la llamada se corta y volvemos a llamar, comenzamos desde cero de nuevo.

Este escenario español se salta el principio fundamental de ITIL, que se basa en la satisfacción del cliente/usuario, y no en el interés particular de la Empresa de Servicios de que no agobien de llamadas a su reducido número de especialistas de Soporte, poniendo barreras de contestadores automáticos IVR  y personal sin cualificación 

Es importante recordar que ITIL es un conjunto de Mejores Prácticas y que puede ser implantado parcialmente, no necesariamente como un todo, dependiendo de las dimensiones de la Empresa, el Departamento de IT, el número de Clientes/Usuarios y el número de Servicios soportados.

En los equipos de soporte IT que he dirigido, nuestra implantación progresiva mientras manteníamos temporalmente el modelo anterior, fue así:

1º Definición del Portfolio y del Catálogo de Servicios (Estrategia y Diseño del Servicio)

Dejar bien claro por escrito a disposición de la Dirección y de los técnicos de IT, cuáles son exactamente los servicios que se atenderán por mucha presión que se reciba (nada de softwares sin licencia, portátiles personales de usuarios, etc) En caso de intentos de colarnos servicios no soportados, los técnicos deben escalar el caso  a la Dirección IT y comprobar si se pueden soportar e incluir en el Catálogo o rechazar "amablemente"

2º Definición de Niveles de Servicio (SLA). (Diseño del Servicio)

Dejar bien claro por escrito a disposición de cada Empresa o cada Departamentos internos afectados cuáles son exactamente los servicios que se atenderán. Es posible agrupar clientes y Departamentos en un mismo SLA, típico y por tanto mantener un número reducido de ellos.

En Departamentos de IT internos, no es necesaria la firma de aceptación del resto de Departamentos, si obtenemos la del Director General o del Comité de Dirección. Tampoco hace falta incluir penalizaciones ya que los servicios no tienen coste directo.

(Es interesante incluir en los mensajes de cierre de incidencias un coste "virtual" del servicio según los minutos empleados, para concienciar a los usuarios de que no es gratuito e inducirles así a no abrir incidencias indiscriminadamente sin reiniciar antes sus equipos, por ejemplo).

3º Definir el proceso de Gestión de Incidencias y Problemas y definir los roles de sus gestores.(Operación del Servicio)

Diferenciar las Incidencias de los Problemas es el paso más importante de la gestión del Departamento de IT. Todos los mensajes que se reciban son incidencias por definición y la misión nº 1 del equipo es cerrarlas cuanto antes. Para ello hay que reparar el fallo o avería como prioridad principal, o bien utilizar un "parche" que permita seguir trabajando al usuario mediante una solución alternativa temporal mientras hallamos la causa de su incidencia (por ejemplo sustituyendo su ordenador por otro mientras reparamos el suyo).

Esos cierres de incidencia con "parches" temporales dan lugar a la apertura de un Problema por el gestor de incidencias que debe ser resuelto, ya con menor urgencia, por el gestor de problemas.

Lógicamente, para poder soportar este modelo, es necesario disponer de alternativas, como por ejemplo:

- Dispositivos de repuesto

- Contratos de mantenimiento externos

- Base de Datos de Conocimiento (Transición del Servicio) o de Errores Conocidos (Operación del Servicio)

Un error común es confundir al gestor de Problemas con el gestor de Incidencias de nivel 2. Las incidencias no se escalan a Problemas sino que se cierran adecuadamente o con un "parche". En ambos casos se cierran, pero en el segundo además se abre un Problema, que es una criatura completamente distinta (su resolución no es urgente, puede suspenderse hasta la mejora de versión del recurso, etc). Las incidencias y los problemas pueden tener gestores de varios niveles, en función a la especialización que requiera cada servicio,

Otro error común es pensar que cada rol es un individuo diferente. Por el contrario, una misma persona puede ejercer varios roles, aunque es cierto que algunos roles no es aconsejable que recaigan en la misma persona.

3º b. Considerar las peticiones igual que las incidencias. 

Aunque la resolución de incidencias debe ser prioritaria, en la práctica las peticiones pueden simplificarse gestionándolas de la misma manera y por los mismos roles.

4º Externalizar el soporte externo para los recursos clave.

Muchos Departamentos de IT cometen el error de tratar de arreglarlo todo ellos solos. Intentan formarse o certificarse en tecnologías tan dispares como servidores HP iLO, Windows Server, SAP o Navision, Project, etc, 

A medio plazo la actualización de conocimientos y la especialización es inviable y acaba generando el fracaso del equipo de soporte, o el sobredimensionamiento de profesionales en nómina.

Una opción mucho más viable y sencilla es contratar el soporte de cada recurso que requiera especialización o que sea clave para el Negocio.

Lo sé, Esto convierte al equipo de Soporte en un Service Desk de gestores de tráfico que se encarga de dirigir cada incidencia o petición al servicio externo que corresponda. Y...?

Siempre me gusta poner a mis equipos el ejemplo de un Controlador Aéreo, que es capaz de gestionar todo el tráfico del aeropuerto y las comunicaciones con los pilotos teniendo a su disposición los equipos necesarios de controladores de torre, "aparca-aviones", conductores de escaleras, camionetas encargadas del equipaje, etc, sin tener que bajar ellos mismos a pista a hacer todos esos trabajos.

5º Service Desk

Con las definiciones anteriores preparadas, es importante tener en cuenta lo siguiente para poner en marcha un CAU (Centro de Atención a Usuarios):

- Disponer de una herramienta de gestión de tickets (peticiones e incidencias). Si es un software específico como ManageEngine, mejor. Si no, una base de datos ACCESS o una hoja EXCEL. Lo que sea, pero hay que llevar un registro de tickets.

- Disponer de los procedimientos de resolución de incidencias y problemas bien documentados, y en formato de listado de pasos uno a uno.

- Disponer de Check-Lists de comprobación de incidencias, problemas e incluso peticiones, para evitar olvidos y garantizar la estandarizacicón en la resolución por parte de todo el equipo.

- En Departamentos de IT internos, a partir de un número de usuarios superior a 20 o 30 es imprescindible evitar la atención telefónica o presencial sustituyéndola por e-mails o por un software de tickets. De esta forma, es el mismo usuario quien abre la incidencia o petición mediante su mensaje y se evita el mayor ladrón de tiempo del Planeta: el teléfono.

- Si el Service Desk va a dar soporte a Clientes externos vía telefónica, hay que tenerlo en cuenta durante el Diseño del Servicio para dimensionar adecuadamente la infraestructura y el SLA en relación a horarios de atención y por supuesto al precio.

Es posible ampliar la implantación ITIL hasta toda la extensión que define el modelo, aunque son muy pocas las Empresas en el Mundo que llegan a ese nivel, ya que la metodología abarca prácticamente todas las posibilidades necesarias para cualquier Empresa de cualquier servicio en el mundo, (tanto de Sistemas de Información como otros, insisto), Sin embargo rara vez encontraremos una Empresa donde se necesite implantar todo el modelo.

Si somos capaces de arrancar con estos mínimos, en el plazo de 6 meses tendremos una implantación ITIL básica pero eficiente, que podemos ir actualizando y perfeccionando con ayuda de todos los integrantes del equipo de IT, en base a la experiencia diaria, dando así sentido al proceso de Mejora Continua.

Francisco Navarro

ITIL v4 Foundation Certificated
ITIL v2011 Foundation Certificated
ITIL v2011 Service Operation Certificated