Gestión de eventos simplificado

Gestión de Eventos es uno de los nuevos procesos en la última edición de ITIL. En mi opinión su función principal debe ser la de transformar datos (eventos) en información útil para poder anticiparse a males mayores. El libro de Operación del Servicio presenta un flujo muy detallado de las actividades, métodos y técnicas del proceso. Quizás demasiado detallado para organizaciones que no cuenten con una arquitectura TI excesivamente compleja. En el post de hoy me gustaría compartir un flujo más "simplificado" para las organizaciones más pequeñas.

Notificación de Evento

Las herramientas de monitorización reciben alertas de los distintos activos que forman la infraestructura TI, según los parámetros que se hayan establecido en dichas herramientas. Es decir si la parametrización de las herramientas de monitorización está configurada de tal forma que solo deben generar un evento cuando la capacidad de un disco duro alcance el 90%, no se tendrá ninguna “noticia” de este disco hasta que se alcance el umbral fijado. Debido a esto es muy importante que los “propietarios” o responsables de los distintos activos junto con el equipo de Gestión de Eventos establezcan dichos parámetros para que con la antelación suficiente los sistemas de monitorización avisen de un futuro problema.

Filtrado
La cantidad de eventos que se pueden llegar a generar de todos los activos monitorizados es un número lo suficientemente alto como para que sea necesario hacer un filtrado antes de pasar a su registro en la herramienta de ITSM. Que se realice este filtrado no quiere decir que solo se traspase información de caídas o interrupciones en los servicios de negocio. Si se filtra demasiado la Gestión de Eventos pierde su sentido puesto que no podrá alcanzar su objetivo de “ayudar” a otros procesos ITIL a anticiparse a futuros problemas. El filtrado debe ser consecuente con los objetivos que se busquen para la Gestión de Eventos.

Registro y clasificación
Una vez que se ha filtrado un evento y se decide traspasarlo a la herramienta de Gestión del Servicio ITSM, debe entrar en funcionamiento un mecanismo para que los datos se traspasen de forma automática. Este mecanismo debe realizar el registro del evento atendiendo a una serie de parámetros. Obtener una prioridad para el evento es un punto muy importante, puesto que esta será la que desencadene las siguientes acciones del proceso de Gestión de Eventos.

¿Tratamiento urgente?
Según la prioridad del evento y si este necesita un tratamiento urgente se debe traspasar toda la información necesaria para que el proceso de Gestión de Incidencias se haga cargo de la situación. En caso contrario el evento será almacenado con el objetivo de su posterior análisis.

Estudio de Tendencias
Con la periodicidad marcada por las políticas del proceso de Gestión de Eventos, el equipo de trabajo debe realizar un análisis de tendencias para detectar si eventos que aún no han tenido un impacto directo en la infraestructura pueden llegar a tenerlo en un futuro. Este estudio es fundamental a la hora de transformar una monitorización simplemente reactiva en un proceso proactivo.

¿Cuales son vuestras experiencias con la Gestión de Eventos?

Alberto Álvarez Álvarez

Entrevista con Oscar Corbelli

En el día de hoy tengo el inmenso placer de compartir con vosotros la entrevista que he realizado al "maestro" Oscar Corbelli. Recientemente galardonado con el premio al mejor instructor itSM 2011 y autor del libro "Las trampas de la integración", para mi Oscar es un referente y si alguno de vosotros aún no lo conoce mi consejo es que lo haga a través de su blog.

- ¿Qué beneficios crees que aporta la implantación de ITIL en una organización TI?
Todos los que tu imaginación pueda crear, sólo que depende de las personas. Podemos mencionar la mayor calidad en la entrega de servicios a través de claras definiciones de diseño; mejor soporte a usuarios a través de buenos procedimientos de incidencias y obviamente ITIL es la base para alinear y coordinar los servicios con los objetivos del cliente y crear valor agregado en los servicios. Esto se logrará siempre y cuando sucedan dos hechos anteriores: 

1. Compromiso total del negocio con el proyecto de implantación. 
2. Definir el nuevo marco cultural para que las personas decidan si se adhieren o no al mismo. (ver pág. 220 de “Las trampas de la integración") 

Dos temas que da para hablar varias horas, pero ineludibles para conseguir éxito en la implantación de ITIL.

- ¿Qué pasos se deben seguir para implantar ITIL con éxito?
No hay pasos predeterminados que deban tomarse como reglas, pero habrá aspectos en común en todas las organizaciones, como por ejemplo los mencionados en el punto anterior, que serán el inicio de un proyecto, con un responsable y que habrá que gestionar. Quizá la cuestión más difícil es decidir por dónde iniciar, es decir cuáles procesos comenzar a implantar. Las recomendaciones aquí será identificar dónde están los “cuellos de botella” que impiden mejorar. Lo más probable es que el día a día sea el inicio, es decir con todas las actividades relacionadas a dar soporte y resolución de problemas de usuarios, pero no debe tomarse como excusa para no hacer las otras acciones. Lo que quiero decir es que siempre deberá tenerse como objetivo implantar todas las fases del ciclo de vida del servicio.

Es imposible implantar ITIL con éxito si la dirección superior (TI y Negocio) no tienen la formación básica de la gestión basada en el ciclo de vida. Los dirigentes del negocio deben saber que la gestión de servicios es una actividad de su negocio y las inversiones TI son decisiones de negocio.

- ¿Se puede implantar ITIL en cualquier tamaño de organización, PYME, gran empresa, Administración Pública...?
Si, sin ninguna duda. La diferencia estará en los tiempos necesarios para explicar y convencer. Es importante contestarse la pregunta ¿qué quiere el CEO que haga su CIO? Y luego considerar con quiénes cuentas. No puedes desconocer que siempre habrá algunos perdedores. 

Si piensas en la implantación en una PYME el consejo es considerar implantar 5 procesos (Estrategia, Diseño, Transición, Operación y Mejora continua) que tendrán actividades (subprocesos) en cada uno de ellos; de esta forma tendrás el foco completo del ciclo de vida.

- Respecto a la última edición de ITIL, la 2011, ¿qué parte del ciclo de vida crees que es más crítico para una organización (Estrategia, Diseño, Transición, Operación o Mejora Continua)?
Mi visión de criticidad en ITIL es que no podemos enfocarnos o dar prioridad a una o dos fases, sino a todas ellas. Fíjate que se llama “ciclo de vida” del servicio. ¿Dejarías de atender a tu hijo durante la etapa que va de la pubertad a la adolescencia? ¿Dejarías la educación de tu hijo sólo a cargo de la escuela? 

- ¿Cómo ves el futuro de ITIL?
La nueva edición 2011 ha mejorado mucho y por fin a nucleado todas las opiniones de la industria, mucho más cerca del negocio. Fíjate que ahora no sólo hablamos de valor agregado sino también de valor realizado. Es decir que TI está llegando hasta el consumidor de los productos o servicios de su cliente. El futuro será un CIO transformador del negocio de su cliente, por lo que la gestión se los servicios será una herramienta más para esa integración. El futuro de la biblioteca será desarrollar con más amplitud las acciones que consigan la integración. (quizás ayude lo que he planteado en “Las trampas de la integración"). 

ITIL deberá asegurar que TI comprenda el mercado y al negocio y facilitar el cambio organizacional. Este último punto está presente en el libro de Transición, pero habrá que mejorarlo en las siguientes ediciones.

Lo que me preocupa es su implantación en España; aun creemos que todo es muy difícil, que cuesta mucho, que la gente, etc. etc.; seguimos dando excusas basados en esquemas socio-culturales, cuando en realidad el problema es el liderazgo.

Oscar, gracias por tu colaboración.

Alberto Álvarez Álvarez

Incrementar la solución en el primer contacto

Que gran objetivo, ¿verdad? Cuando he tenido que realizar las funciones de usuario final "enfrentándome" a un Service Desk siempre tengo la sensación de que los agentes tienen el trabajo más desagradecido de toda la organización TI. Quiero tener una solución inmediata y a veces se me olvida lo difícil y estresante que es su trabajo. Por lo general suele ser el peor remunerado y es el grupo donde es más factible realizar mediciones de todo tipo para evaluar su desempeño: tiempos de llamada, número de llamadas atendidas por agente, tiempo de timbre, tiempos de desconexión,... Por otra parte he tenido la suerte de poder realizar "escuchas" en diferentes proyectos y la verdad es que habitualmente me reconforta ver la profesionalidad con la que los agentes desarrollan su trabajo. Bien por ellos!

Incrementar el índice de solución en el primer contacto es un requerimiento habitual del negocio y de los propios usuarios finales, conseguirlo no es tarea fácil pero PODEMOS!! En mi opinión hay que potenciar los siguientes aspectos:

• Procedimientos de solución. Todos, repito, todos los grupos de la organización deben facilitar documentos claros y concisos para que los agentes de Service Desk puedan aplicar soluciones inmediatas. Una o dos páginas puede ser un documento "utilizable" por un agente.

• Formación continua. Los cambios constantes en la infraestructura TI de cualquier organización deben ser dados a conocer incluso de forma previa a que sucedan al Service Desk.

• Automatización de soluciones. La creación de herramientas internas para dar solución a incidencias del estilo desbloqueo de usuarios o eliminar trabajos en la cola de impresión facilitan y disminuyen considerablemente los tiempos de solución.

• Procedimientos diagnóstico. Es muy difícil aplicar una solución válida si no se sabe cual es el problema.

• Divide y vencerás. Aunque pueda parecer un contrasentido dividir el Service Desk en pequeños grupos de conocimiento redunda en un incremento de la solución en el primer contacto. Eso si tiene sus desventajas y es necesario evaluar detenidamente este punto antes de llevarlo a la práctica.

Cualquier tiempo que se dedique a mejorar el funcionamiento del Service Desk tendrá un retorno inmediato: aumento de la satisfacción del usuario. 

¿Estáis de acuerdo?

¿Que soléis hacer en vuestras organizaciones?

Alberto Álvarez Álvarez

Categorización de incidencias

"La mejor estructura no garantizará los resultados ni el rendimiento. Pero la estructura equivocada es una garantía de fracaso."

Peter Drucker

Cuando el "padre del management" pronunció esta frase seguro que no estaba pensando ni mucho menos en como se deben categorizar las incidencias, pero creo que es muy importante tenerla presente a la hora de crear una estructura para clasificar las incidencias. No es lo mismo tener datos que tener información y agrupar de forma correcta las incidencias es fundamental para obtener información útil y no simples datos estadísticos. Vamos por partes.

En primer lugar, en el apartado del libro de Operación de Servicio dedicado a la   "Categorización de las incidencias" se enumeran una serie de pasos "para alcanzar un conjunto correcto y completo de categorías...". En mi opinión falta el paso más importante de todos hablar con el negocio. La organización TI esta al servicio del negocio, y por lo tanto hay que tener muy en cuenta su opinión a este respecto. Un informe de incidencias para un CEO o Director General que refleje que ha habido X número de incidencias de categoría Hardware/Servidor/Placa de Memoria/Tarjeta probablemente no le diga nada, sin embargo si el informe hace referencia al número de incidencias que ha sufrido el Servicio de Negocio Y le será de mucha más utilidad.

Por otra parte además de tener una estructura coherente con los objetivos del negocio, es muy importante que la información sea fiable. Habitualmente la categorización de una incidencia forma parte de la actividad inicial de registro, en el caso de que la solución corra a cargo de una segunda o tercera linea es casi  seguro que la categoría variará. En la última edición de ITIL se recomienda utilizar una categoría de cierre lo cual me parece muy acertado pero discrepo en que ésta tenga que ser revisada por el Centro de Atención al Usuario. Creo que es más apropiado que la revisión se haga por parte del grupo que ha solucionado la incidencia que será el que tenga toda la información necesaria para realizar una categorización correcta.

Hay organizaciones que disponen de distintos tipos de categorización (inicial, final, operativa...). Mi recomendación es que se utilice única y exclusivamente aquella(s) que suponga(n) un beneficio para el negocio. En la simpleza está el éxito.

¿Que opináis?

También podéis dejar vuestra opinión en el grupo de LinkedIn itSMF en español.

Alberto Álvarez Álvarez

Organizar una petición.

A día de hoy todavía existen organizaciones en las que una petición de servicio tiene el mismo tratamiento que una incidencia. Para mí esto es un error de bulto y según recomienda el conjunto de mejores prácticas, ITIL, estas dos entidades han de ser gobernadas por procesos independientes. Las actividades reflejadas para el proceso de Gestión de Peticiones en el libro de Operación del servicio, me parecen poco detalladas y voy a intentar aportar mi granito de arena.

En la edición en español la primera actividad tiene un título no muy afortunado, Selección de menús, pero esto es lo de menos. Estoy totalmente de acuerdo en que una petición de servicio es un proceso muy adecuado para poner en producción un interfaz web estilo "carrito de la compra" que de la oportunidad al usuario final de realizar su solicitud de forma on-line. Por favor, hay que erradicar definitivamente el formulario en papel.

La siguiente actividad, Aprobación Financiera. Desde mi punto de vista, tal y como se puede leer entre lineas, es una actividad que no debe estar asociada a cada una de las peticiones. Lo aconsejable es marcar unas limitaciones económicas y que solo en caso de rebasar estas, se pida aprobación financiera. Hay algo en esta actividad que yo asociaría a la anterior y es precisamente el informar al usuario de cual es el coste de la petición y si es necesaria una autorización previa.

Otra aprobación. Si se necesitan tantas aprobaciones ¿quizás estamos hablando de un cambio?.

Cumplimiento. Apartados como este son los que me animan a compartir mis experiencias.
Para llevar a cabo una petición de servicio es bastante habitual que intervengan distintos grupos o equipos de trabajo, cada uno puede llevar a cabo distintas tareas dentro de la misma solicitud. Trabajar en base a tareas es muy recomendable por varias razones:

• En múltiples ocasiones hay tareas que se pueden llevar a cabo de forma paralela. Si se trata como una incidencia es muy difícil por no decir imposible que se puedan ejecutar distintas tareas al mismo tiempo.
• Trabajar en base a tareas permite establecer un orden lógico, por ejemplo antes de dar de alta un usuario en el sistema de correo electrónico hay que comprobar que existe en el directorio activo.
• Si se utilizan tareas será mucho más sencillo obtener una planificación e incluso una industrialización del proceso.
• Se facilita la trazabilidad de la ejecución.

Si la organización adopta esta forma de trabajar mediante tareas, es muy importante que se tenga en cuenta como un factor más a la hora de implantar una nueva herramienta de gestión de servicio.

La última actividad, Cierre. Ayuda a tú Service Desk, implementa un buen procedimiento que permita al usuario cerrar sus propias peticiones de forma automática.

Y en tú organización, ¿incidencias y peticiones se tratan de la misma forma?

Alberto Álvarez Álvarez

Otra forma de medir, los percentiles

Los que somos padres alguna vez nos hemos preocupado por los famosos percentiles en los que habitualmente  los pediatras "enmarcan" a nuestros hijos. Imaginemos la siguiente conversación:

- Pediatra: Su hijo está en el percentil 42 de talla". 
- Padres: ¿Y eso que quiere decir? ¿Nuestro hijo va a ser bajito? 
- Pediatra: No, lo que significa es que 42 de cada 100 niños son más bajitos que el suyo.
- Padres: Buff, que susto!


El pediatra tranquiliza a los padres comentando que cualquier percentil ya sea alto o bajo no es preocupante a menos que este por debajo o por encima de unos criterios establecidos.

No, no voy a cambiar el contenido de Traicionando ITIL, pero la introducción me parece adecuada para hablar de otra forma de medir los resultados del trabajo realizado, los percentiles. Estos se consideran como una medida de posición no central, es decir permiten conocer puntos característicos de una distribución que no son los valores centrales. Los percentiles ponen a nuestra disposición unos resultados distintos a las tan frecuentemente utilizadas "medias".

¿Por qué utilizar los percentiles? En diversos proyectos en los que he participado existían una cantidad ingente de mediciones y muchas de ellas basadas en medias, especialmente aquellas relativas a tiempos. Tiempo medio de solución, tiempo medio de respuesta, tiempo medio de llamada,etc... Por ejemplo: el tiempo medio de solución de las incidencias del mes es de 6 horas. Dependiendo de los objetivos establecidos este tiempo puede ser alto, bajo o todo lo contrario. Sin embargo alguna vez ocurre que los datos no coinciden con la percepción que tiene el usuario, es en ese momento en el que hay que desconfiar de la media.

Como siempre voy a intentar explicar el objetivo a través de un ejemplo práctico. Dada la siguiente tabla en la que se muestran una relación de incidencias con su tiempo de solución, el valor del tiempo medio resultante es 1,76.

Supongamos que el tiempo medio establecido como indicador contractual es 2, a pesar de que el resultado esta en "verde", una serie de usuarios consideran que los tiempos de solución son demasiado elevados. Si calculamos cuál es el percentil que supone el valor 2 para esta serie de datos obtendremos un 73,60%, lo que quiere decir que mas de un 25% de las incidencias relacionadas han superado el umbral establecido como tiempo de solución.

¿A pesar del cumplimiento del indicador, se está dando un buen servicio? ¿Que opináis?

Alberto Álvarez Álvarez


PD. En el apartado "Enlaces de interés" hemos añadido el blog de Oscar Corbelli, sencillamente, un maestro!!!

Congreso anual itSMF

El pasado lunes y martes tuvo lugar el congreso anual del itSMF España, itgsmVision11. Este año ha sido celebrado junto con ISACA. En el día de hoy dejo un lado los post sobre ITIL para transmitir mi mas sincera enhorabuena a toda la organización del evento. Las diversas ponencias a las que he podido asistir han resultado muy enriquecedoras y conferencias de este tipo resultan un oasis en medio de la vorágine del día a día. Seguir así.

Os animo a que dejéis vuestra opinión sobre el congreso.

Alberto Álvarez Álvarez

Arboles de decisión, que solución adoptar. (y II)

En el post anterior se iniciaba el desarrollo de un modelo de predicción para encontrar cual es la solución más viable en la situación expuesta, un árbol de decisión. Debido a problemas presupuestarios una organización tiene que enfrentarse un año más a la imposibilidad de llevar a cabo un "plan renove" en su parque de pc's. Con estas premisas se barajan tres posibles soluciones para intentar mitigar el crecimiento de incidencias de lentitud en los puestos de trabajo del usuario final.

Una vez se ha elaborado la matriz el siguiente paso es dibujar el árbol de decisión. Según los datos previos el resultado obtenido es el siguiente:

Paso a paso:

• Dibujamos un árbol con tres ramas principales: Reinstalación, + Memoria y + Disco Duro.
• De cada una de ellas salen otras 3. Cada una de ellas representa la probabilidad y el impacto económico reflejado en la matriz.
• Por último hay que calcular el valor para cada rama principal, el número destacado en rojo. La fórmula es bien sencilla. Reinstalación = (0.4*120) + (0.5*90) + (0.1*3) = 96.

Una vez obtenidos los valores para las tres ramas principales la decisión adecuada es la de mayor peso, para el ejemplo que hemos seguido la Ampliación de memoria parece ser la solución a adoptar. De todas formas hay que dejar bien claro que cualquier método que se utilice para la ayuda a la toma de decisiones no es más que eso, una ayuda. El conocimiento del entorno y las posibilidades y el sentido común, pueden hacer variar el resultado obtenido.

¿En algún examen ITIL os habéis encontrado con algún supuesto en el que se pudiera aplicar este método?

¿ Creéis que en los cursos de preparación para obtener la certificación ITIL, deberían aparecer más ejemplos de este tipo?

Alberto Álvarez Álvarez

Arboles de decisión, que solución adoptar. (I)

Continuamente estamos hablando sobre como el departamento TI puede aportar valor al negocio. Sin ir más lejos el congreso anual del itSMF España este año tiene como título "Integrándonos con el negocio", definitivamente estoy convencido que desde TI si se puede aportar valor al negocio. El post de hoy es el primero de una miniserie sobre como tomar decisiones basadas en un modelo de predicción, los árboles de decisión. Enmarcados en las matemáticas discretas sus aplicaciones abarcan ámbitos tan variopintos como puede ser el de la inteligencia artificial o la economía, y por qué no también el de la gestión de servicios TI. Traicionando ITIL, nace con una vocación eminentemente práctica a si que me voy a saltar la parte teórica y entraré directamente a compartir un posible uso como herramienta de ayuda en la toma de decisiones.

Antes de dibujar un árbol y evaluar su resultado lo primero de todo es describir cuál es el problema e identificar detalladamente todas las alternativas. Os propongo tomar como base el siguiente supuesto (o quizás no es tan supuesto):

Tras un largo período en el que debido a un recorte de presupuesto (seguro que os suena ¿verdad?) no se han podido renovar los pc's, desde Gestión de Problemas y a través de un Informe de Tendencias se ha detectado que existe un incremento en el número de incidencias en los puestos de los usuarios, "mi pc es muy lento". Como sigue habiendo problemas económicos se sabe que la alternativa de un "plan-renove" es inviable. Antes de emitir un informe definitivo sobre la situación hay que evaluar que decisión tomar dentro de las posibilidades existentes, siempre intentando incurrir en el menor coste posible.

Con un presupuesto tan limitado solo se han podido identificar tres posibles soluciones:

• Formateo y re-instalación de los pc's afectados.
• Ampliación de memoria.
• Cambio de disco duro.

La elección correcta depende de la probabilidad de éxito en la mitigación del tipo de incidencia comentado y se ha decidido asignar un porcentaje como el siguiente:

• Probabilidad alta de éxito 40%.
• Probabilidad media de éxito 50%.
• Probabilidad baja de éxito 10%.

Con la ayuda de la Gestión Financiera se ha evaluado una matriz de beneficios que detalla el análisis de costes para las acciones mencionadas. El resultado obtenido es el siguiente:

En el próximo post se verá como aplicar la información disponible a un árbol de decisión para su posterior evaluación.

Incidencias vs Peticiones. ¿Qué tiene mayor prioridad?

Que yo sepa ITIL no aclara esta cuestión y antes o después suele surgir en el trabajo diario de las organizaciones de soporte. La teoría dice que una incidencia siempre es mucho más urgente que una petición de servicio debido a que estas últimas se suelen relacionar con acciones panificables. Como siempre digo la teoría lo soporta todo, pero en ocasiones la cruda realidad nos dice lo contrario.

Ante una incidencia de máxima prioridad y una petición de servicio también de máxima prioridad, ¿que hay que atender primero? Hace unos días abrí un debate en Linkedin sobre si una solicitud de reseteo de password debería registrarse como una incidencia o como una petición, la respuesta fue unánime: petición. Ahora bien si un usuario necesita que su password sea reseteada, ¿puede esperar a la "cola" de la planificación?

Cierto es que en este caso lo importante no es el concepto sino darle una solución rápida al usuario. Por lo general el flujo de trabajo de las incidencias es el más "ágil" de todos los procesos y esto puede llevar a pensar que en un ejemplo como el anterior lo más aconsejable es saltarse la teoría. Cada organización debe tomar su propia decisión al respecto (adopt & adapt) pero... ¿hay alguna forma de seguir la teoría al pie de la letra sin perjudicar al usuario?

Lo habitual es que los técnicos que se encargan de tratar las incidencias sean los mismos que los que se dedican a las peticiones de servicio. Si el dimensionamiento lo permite, lo ideal sería tener a un recurso dedicado a realizar labores de "dispatcher". Esta persona debe tener unas directrices claras para poder tomar una decisión y repartir la carga de trabajo al equipo de técnicos correspondiente. Si no es posible disponer del "dispatcher" y la organización no es lo suficientemente madura existe el riesgo de que peticiones que no pueden esperar sean encoladas y retrasadas en el tiempo.

Self Service Desk Service

Sírvase usted mismo. Está es la filosofía de cualquier cualquier Self-Service y creo que a día de hoy este concepto no ha evolucionado lo suficiente como para decir que los usuarios disponen de autoservicios de calidad. En la mayoría de ocasiones su implementación es debida a una necesidad de descargar de trabajo al Service Desk y al resto de grupos operativos. Si este es el motivo que origina la puesta en marcha de un autoservicio el fracaso estará casi asegurado. Las organizaciones TI están obligadas a aportar valor y para eso deben tener más empatía con el usuario final. ITIL promueve el uso de buenas prácticas como por ejemplo la implementación de FAQ's pero, ¿es esto suficiente?, ¿el concepto de "autoservicio" es idéntico al de "hágalo usted mismo"?

Cuando pienso como actúan los usuarios finales (cada día que pasa me cuesta menos, ¿será por qué ya soy uno más?), siempre recuerdo una frase que escuche hace un tiempo a una persona con una dilatada experiencia en las relaciones entre TI y el negocio, "cada negocio con su negociado", es decir un usuario final vive en mundo distinto al de TI. Por supuesto que hay un nexo común, el uso de las TI, como manejar esta intersección es el centro del nudo gordiano que toca "desatar" desde la gestión de servicios. Implementar un self-service es  una tarea que hay que mimar si se quiere tener una herramienta que beneficie tanto al negocio como a TI.

Para mi, los factores críticos de éxito son los siguientes:

• Tener claro que incidencias/peticiones son mas frecuentes en la organización. En un post anterior ya se habló de este tema.
• Por muy recurrente que sea una incidencia/petición, no quiere decir que se pueda incluir en un self-service. Según lo complejo de la solución se debe incluir o no en el servicio.
• Disponer de herramientas "transparentes" para el usuario final que realicen las tareas necesarias para dar solución. Si no se dispone de presupuesto para contar con aplicativos software, hay que utilizar procedimientos de solución claros y concisos.
• Diseñar con sumo cuidado el argumentario al que se van a tener que enfrentar el usuario final para dar con la solución a su incidencia/petición.

Nunca hay que perder de vista que el lenguaje utilizado por el negocio suele ser distinto al que se emplea desde TI. Es necesario realizar un esfuerzo en encontrar un punto intermedio en el que ambas partes se encuentren confortables. Como en todos los servicios, la fase de Mejora Continua, formará parte activa de la evolución del self-service y puesto que es una herramienta orientada al usuario contar con su opinión es fundamental para adaptarlo a sus necesidades.

Pensar como un usuario es el quid de la cuestión: "no soy un experto en TI", "busco una solución rápida a mis problemas", "si el self-service es un servicio de calidad continuaré utilizándolo". El objetivo es facilitar el trabajo, no convertir al usuario en un técnico.

Alberto Álvarez Álvarez

Gestión de peticiones, un proceso a industrializar.

Cada vez que llevo el coche a la revisión en el taller oficial, se produce la misma situación (además de pagar una cuantiosa factura). Consultan el historial, le echan un rápido vistazo y me dicen al detalle que es lo que voy a tener que pagar y cuando voy a poder pasar a recogerlo. Si en el transcurso de la revisión detectan algo anómalo (no planificado) enseguida me llaman para notificarme las "buenas noticias". Para mi esto es un buen servicio.

Hasta dónde yo se no hay truco, lo que hay es una muy buena planificación, cada tarea que se lleva a cabo en el taller esta descrita y me atrevo a decir que hasta procedimentada, además tiene asociada un tiempo que es el que posteriormente viene reflejado en la factura (si no hay imprevistos). Tiempo, parámetro fundamental para cualquier proceso de planificación.

¿Cómo aplicar el funcionamiento de un taller a la Gestión de Peticiones?

En mi opinión simplemente hay que hacer una extrapolación a lo que he comentado anteriormente.Cualquier usuario final, incluso el más exigente, se encontrará satisfecho si a la hora de realizar una petición al Service Desk tuviera una respuesta inmediata del tiempo en el que va a ser solucionada la misma. Esto pasa por aplicar la industrialización al proceso de Gestión de Peticiones.

Lo primero es conseguir una relación de las distintas tareas que se pueden llevar a cabo dentro de cada petición que el usuario pueda hacer a través del catálogo. A cada una de ellas hay que asociarle un tiempo de ejecución. Ya estoy escuchando alguna voz que dice que esto es imposible: "esto de la informática no es igual que la mecánica de coches", "la misma tarea unas veces te llevará una hora y otras veces lo hará tres", ... hay que hacer un esfuerzo se puede conseguir. 

El resto es lo más sencillo, para saber la carga de trabajo actual en horas lo único que hay que hacer es multiplicar el número de tareas sin resolver en el momento actual, por el tiempo estimado. Si además somos capaces de saber las horas que el equipo de trabajo va a dedicar a realizar dichas peticiones, la planificación será coser y cantar.

Quizás los resultados obtenidos al principio no sean del todo exactos pero tampoco llevará mucho más esfuerzo acercarse a la realidad. Si no existe experiencia previa el estimar un tiempo para cada tarea será una cuestión de prueba y error o mejor dicho de aproximación, pero es posible conseguirlo.

Detalles a tener en cuenta:

• Las tareas no siempre son unitarias, es decir una petición puede conllevar más de una repetición. No es lo mismo que se pida instalar un procesador de textos en un pc que en cien. Con lo cual otro factor a tener en cuenta es el número de repeticiones.

• Antes de dar el paso de comunicar un tiempo estimado al usuario hay que estar seguro de que se va a poder cumplir. En mi opinión es peor dar un tiempo y no cumplir que no dar ningún tiempo.

• El obtener la carga de trabajo en horas además de ayudar a obtener una mejor planificación también permitirá tener un dimensionamiento más adecuado del número de recursos necesario.

Sigo empeñado en haceros parte activa del blog, con lo cual hoy dejo algunas preguntas abiertas esperando vuestras opiniones:

¿Que proceso debe ser el encargado de realizar está "buena práctica"? ¿Gestión de Peticiones? ¿Gestión de la Capacidad? ¿Los dos? ¿Otro distinto?...

Alberto Álvarez Álvarez

Incidencias nuevas vs recurrentes. Ley de Pareto

Peter Drucker considerado por muchos como el padre del Management dijo en una ocasión:

"Innovar es encontrar nuevos o mejorados usos a los recursos de que ya disponemos"

Los buenos propósitos que se suelen tener al inicio de un proyecto, en cuanto a la revisión de incidencias, suelen diluirse como un azucarillo en el café a medida que pasa el tiempo. Al principio se invierten muchos esfuerzos en documentar la aparición de "nuevas incidencias" pero habitualmente esta buena practica se va perdiendo con el paso del tiempo. Siguiendo el consejo de Drucker es de obligado cumplimiento innovar en un aspecto tan importante como es la repetición de las incidencias. Parece lógico pensar que no es posible que todos los días aparezca una incidencia totalmente distinta a las anteriores, aceptando que esto es así no queda otro camino que aceptar que la mayor parte de las incidencias se repiten de forma recurrente.

¿Cómo identificar que tipo de incidencias surgen con mayor frecuencia? Según mi experiencia un método tan sencillo como eficaz es el de aplicar la Ley de Pareto. Aunque su creador aplicó este principio a temas para nada relacionadas con la Gestión de Servicios TI, en la actualidad se aplica en distintos ámbitos entre ellos el control de calidad. También conocida como la ley del "80-20", su filosofía es la de "pocos problemas son vitales y muchos triviales". La primera vez que utilicé esta norma me parecía casi imposible que se cumpliese, los resultados obtenidos me hicieron cambiar de opinión radicalmente. Antes de exponer un ejemplo práctico es importante que quede bien claro un concepto, de nada sirve utilizar este o cualquier otro principio si los datos de origen no son fiables.

¿Cómo llevar a la práctica la Ley de Pareto en la Gestión de Incidencias? Lo primero que hay que hacer es obtener por ejemplo una relación de los distintos tipos de incidencias junto con sus volúmenes. Una tabla tan sencilla como la siguiente es mas que suficiente:

Simplemente hay que hacer hincapié en dos pequeños detalles, la lista esta ordenada de mayor a menor por el volumen de incidencias para cada tipo de incidencia. Por otra parte cualquier tipo o agrupación que se signifique por la categoría "Otros", debe ir siempre al final de la lista independientemente del volumen o cantidad a la que haga referencia. Una vez hecho esto el siguiente paso es calcular los porcentajes que representa cada tipo de incidencia respecto al total. Una vez hecho esto lo único que queda es representar los datos obtenidos en un gráfico como el siguiente:

La conclusión a la que se puede llegar observando el gráfico es: los 4 primeros tipos de incidencias representan casi un 80% del total de incidencias, lo cual quiere decir que el resto de incidencias supondrán el 20% restante. En este ejercicio (realizado con datos reales) se puede ver que la Ley de Pareto se cumple casi con total exactitud. Si los esfuerzos se centran en mejorar la solución sobre 4 tipos de incidencias se estará trabajando en mejorar un 80% del volumen total de incidencias.

Puede que en alguna ocasión el ejercicio no sea tan fiel a Pareto como el ejemplo que he reflejado, pero lo que si es cierto que siempre se puede encontrar una relación aproximada, si no es el famoso 80-20 será un 70-30 o incluso un 60-40, pero todo aquello que sea simplificar la búsqueda del conjunto de incidencias sobre el que hay que trabajar redundará en el beneficio del proceso.

En el siguiente post, ahondaremos un poco más sobre este tema que me parece muy interesante, incidencias nuevas vs recurrentes.

Una última cosa os animo a que dejéis vuestros comentarios en el blog, cualquier opinión siempre es enriquecedora y a todos nos ayudará a mejorar en este complicado mundo de la Gestión de Servicios.

Alberto Álvarez

Hablan nuestros clientes

Hoy aparcamos nuestras experiencias en el mundo de la Gestión de Servicios TI y del conjunto de mejores prácticas ITIL, para compartir con todos vosotros un caso de éxito en uno de nuestros clientes. Corporación Alimentaría Peñasanta (muchos de vosotros lo identificareis por Central Lechera Asturiana). Os dejamos la entrevista que Socinfo llevo a cabo al Director de TI. Solo tenéis que hacer clic en el play para escuchar la entrevista.

Gestión de Incidencias. Mapa de escalados.

La Gestión de Incidencias siempre tiene una espada de Damocles encima de la cabeza, el tiempo de solución. Siempre y cuando los tiempos sean acordes a los indicadores establecidos en el ANS no habrá ningún problema, la necesidad de mejora llega en el momento en el que este tiempo se demora en exceso. Los retrasos a la hora de solucionar una incidencia suelen motivarse por diferentes razones: dimensionamiento inadecuado, conocimiento insuficiente del entorno,..., y por último mi "favorito" el escalado infinito. Suele ser bastante frecuente encontrarse con incidencias que han pasado de forma reiterada por distintos grupos de soporte, los cuales siempre encuentran una justificación para escalar la incidencia: "he revisado mi parte y está todo bien", "la configuración es la adecuada", "seguro que es un problema del servidor",...

Para evitar este traspaso incontrolado de incidencias de un grupo a otro hay dos factores que se me antojan más que necesarios:

• Realizar un diagnóstico inicial lo más certero posible.
• Disponer de un mapa de escalados.

Ya comenté en su momento la conveniencia de trabajar sobre procedimientos diagnósticos que faciliten al Service Desk la tarea de identificar de forma inequívoca cual es el(los) elemento(s) afectado(s) por una incidencia. Aunque esto solo no será suficiente para encaminar las incidencias al grupo de soporte adecuado, hay que diseñar un Mapa de escalados. Este será la herramienta que se pondrá a disposición del Service Desk para que puedan distribuir de forma correcta las incidencias.

¿Qué hay que tener en cuenta a la hora de crear un mapa de escalados? Tal y como he comentado en otros post todo depende del nivel de madurez con el que cuente la organización. Lo ideal es que el mapa de escalados este embebido en la herramienta de gestión del servicio aunque quizás en la etapa de implantación y durante un corto período de tiempo se puede utilizar una simple hoja de Excel (cuantas menos hojas de Excel se utilicen mucho mejor). Pero en mi opinión hay algo todavía mucho más importante a tener en cuenta y son los criterios a seguir para asignar las incidencias a uno u otro grupo.

¿Cuales son estos criterios? En primer lugar hay que identificar de forma detallada que alcance tiene cada equipo de trabajo dentro de la gestión de incidencias. Este detalle tiene aún más relevancia si tenemos grupos de trabajo con un ámbito común pero con distinto alcance, por ejemplo un grupo N2 Unix y otro N3 Unix. Hay que tener muy claro que tipo de incidencias debe resolver cada grupo.

El otro criterio a tener en cuenta es la categorización o clasificación de las incidencias. En un post previo hablaba sobre la idoneidad de asociar el activo afectado y las preguntas a las que dar respuesta a la hora de clasificar una incidencia: ¿dónde reside el fallo? y ¿que ha provocado el fallo?.

Una vez establecidos los criterios anteriores, la creación del Mapa de escalados será una cuestión de mapeo entre estos y los equipos o grupos de trabajo que tenga la organización. Es importante que esta herramienta de escalados sea puesta en conocimiento de todos los integrantes de la organización. Por último y como todo en este mundo de la gestión de servicios, el Mapa de escalados debe ser una herramienta dinámica, a medida que la organización vaya madurando (sobre todo en lo que a documentación de soluciones tipo se refiere), es muy aconsejable que el alcance en cuanto a la solución de incidencias vaya adecuándose a los niveles menos especializados.

Alberto Álvarez

Gestión de incidencias. Reutilizar información.

Hace ya unos años que el hombre que más dinero ha ganado en este mundo de IT dijo: "El poder está en la información". Estoy seguro de que ni mucho menos se refería a nada que tenga que ver con ITIL, pero creo que la famosa frase viene como anillo al dedo a la hora de hablar de la información de que dispone cualquier organización dentro del proceso de Gestión de Incidencias. Generalmente este proceso es el que más cantidad de registros ocupará dentro de la aplicación de Service Management.

El valor de reutilizar dicha información no es lo suficientemente valorado por las organizaciones y precisamente es una fuente de conocimiento al alcance de todos. El problema reside básicamente en como se organizan los datos relativos a las incidencias. En un post anterior, ya hice referencia a una forma de clasificar o categorizar las incidencias. Esta agrupación es muy interesante a la hora de saber que tipo de incidencias son más recurrentes, pero hay otra parte de una incidencia que también hay que tener muy en cuenta, la solución.

Ser capaz de reutilizar la información disponible en la solución de una incidencia arroja al menos dos beneficios importantes:

• Medir la homogeneidad en la forma de solucionar las incidencias.
• Poner a disposición de los técnicos con menos experiencia una base de conocimiento bien organizada.

Cómo todo en este mundo de la gestión de servicios TI, enfrentarse a este reto no supone una tarea fácil. La  documentación ocupa un lugar privilegiado en el "top ten" de los trabajos más odiados por parte de los técnicos dedicados al mundo del soporte. Es necesario dar unas instrucciones muy claras de como se debe llevar a cabo si queremos disponer de información reutilizable y además hay que ser muy constante a la hora de "perseguir" la correcta aplicación de las directrices establecidas.

En la mayoría de las herramientas con las que he tenido contacto a lo largo de mi experiencia en la gestión de servicios IT, la información relativa a la solución suele estar vinculada a un extenso campo de texto en el que el técnico que soluciona una incidencia, describe de su "puño y letra" que es lo que ha hecho para resolverla. Uno de los contenidos más repetidos es el famoso "Incidencia solucionada" que como podréis imaginar no aporta nada a la hora de reaprovechar la información. 

Como ya es habitual os doy mi opinión de como llevar a cabo esta tarea. Desde mi punto de vista una buena práctica es la de "divide y vencerás". Extraer información útil de un campo de texto libre, es una tarea que no se la deseo ni al peor de mis enemigos. La solución pasa por intentar acotar la información que debe introducir un técnico a la hora de documentar una solución. Por ejemplo se puede dividir el campo solución en base a los resultados que queramos obtener:

• Es muy útil poder asociar el código del "Procedimiento de solución" utilizado, en el caso de que se haya utilizado un procedimiento estandard. 
• También es importante saber si se ha utilizado alguna herramienta (homologada o no) para dar solución a la incidencia.
• Si la solución de la incidencia ha sido a través de la ejecución de un cambio, es de obligado cumplimiento asociarlo con la incidencia antes de ser solucionada.

En resumen hay que pensar como deseamos reutilizar la información y adaptar el método a tal objetivo. Disponer de información estructurada siempre es más útil que utilizar campos de libre contenido.

¿Cuál es tu opinión?

Alberto Álvarez 

Gestión de Incidencias. Prioridad.

En las antiguas galeras romanas el sonido del tambor era el encargado de marcar el ritmo que los galeotes debían emplear a la hora de bogar (remar). En la gestión de incidencias, la Prioridad, es la encargada de dar orden a la solución de las mismas. En el libro de Operación del Servicio y en todos los foros de ITIL se hace referencia a unas tablas en las que cruzar la urgencia y el impacto para calcular la Prioridad adecuada. Consejo, si estas a punto de establecer las prioridades de las incidencias, ten a mano una caja de aspirinas por que el dolor de cabeza será grande.

Independientemente de los valores que se utilicen tanto para la urgencia como para el impacto (alto, medio, bajo,etc), y del nivel de Prioridad obtenido (crítico, alto, medio, bajo, ...), el quid de la cuestión está en determinar a que entidad vamos a asociar el resultado. Hay organizaciones en las que se asocia a los CI's, sin embargo en otras se asocia al servicio de negocio afectado. Mi opinión es que este último caso es el más adecuado pero, ¡cuidado!, si no se hace bien el resultado será una Gestión de Incidencias ineficiente y además en lugar de aportar valor al negocio se producirá el efecto contrario. Un ejemplo práctico: para el "Servicio de impresión" de una organización el impacto asociado es alto, además el usuario indica al Service Desk que tiene la máxima urgencia (caso bastante habitual, el usuario siempre tiene prisa). La Prioridad resultante obviamente será la más alta y el servicio de microinformática se verá movilizado rápidamente para resolver una incidencia que en lugar de tener un tiempo de solución de 1 hora podría haber sido tranquilamente de 8 horas.

Con esto que quiero decir, definir unos servicios (tecnológicos o de negocio) es una tarea bastante compleja, aunque necesaria a la hora de aportar valor al negocio, si además la prioridad de las incidencias la realizamos en función de los servicios establecidos, corremos el riesgo de bascular la carga de trabajo de forma poco óptima. Para aquellas organizaciones pequeñas o para las que están empezando lo más conveniente es utilizar un sistema de prioridad asociada al tipo de CI. A medida que la organización vaya madurando se debe trabajar en la definición de los servicios y asociarles la prioridad correspondiente.  

Cómo establecer un primer nivel de prioridad, asociando la misma a los distintos CI's:

1. A través de una relación de todos los CI's con los que cuenta la organización, realizar un agrupamiento lógico cuyo resultado será una tabla con los distintos tipos de activos (del puesto cliente, elementos de comunicaciones, servidores de aplicaciones, servidores de ficheros...).
2. Establecer, conjuntamente con la parte de negocio, el impacto que producirá una incidencia para cada tipo de activo.
3. Fijar los niveles de urgencia que podrá requerir el usuario.
4. Realizar la tabla cruzada para obtener la Prioridad resultante.

Una vez hecho esto y configurada la aplicación de gestión del servicio, los agentes del Service Desk solo deberían preocuparse de asociar el activo afectado y la urgencia transmitida por el usuario. El ritmo del tambor tendrá mayor o menor frecuencia, el grupo encargado de dar solución a la incidencia organizará su carga de trabajo en función a una Prioridad consensuada.

Una vez haya dado mi opinión sobre como definir los servicios de negocio volveré a hablar sobre este tema que tantos dolores de cabeza provoca.

Alberto Álvarez

ITIL es comunicación.

La comunicación es un aspecto fundamental en cualquier organización, y si hablamos de una organización orientada a ITIL, quizás lo es más. A lo largo de los distintos libros de ITIL en cualquiera de sus versiones hecho en falta un apartado específico y dedicado a la comunicación entre los diferentes actores implicados. Aunque es cierto que se hacen ciertas referencias a este tema no estaría de más profundizar un poco en ello.

En primer lugar y actuando como continuo emisor y receptor de información tenemos el Service Desk. Por una parte, recibe información del usuario final por todos los canales de entrada habilitados, y por otra, es el encargado de comunicar al usuario el estado de las incidencias o peticiones de servicios así como confirmar el cierre de las mismas. En esta última parte el Service Desk necesita de la colaboración del resto de grupos y la verdad en raras ocasiones la tiene. Ante la típica pregunta de un usuario preguntando "¿cómo va lo mio?", los agentes del Service Desk tienen que tener un mensaje distinto al socorrido "estamos en ello". ¡Ánimo! no es una tarea fácil que todos los integrantes de la organización documenten todas sus actuaciones, para que el Service Desk disponga de información actualizada.

Otro de los momentos en el que los agentes necesitan tener información de primera mano es cuando se produce una incidencia masiva o "major incident". Por ejemplo, ante el aluvión de contactos en el caso de que internet deje de funcionar, el Service Desk tiene que ser el primero en ser informado. Además lo ideal sería que tuvieran una estimación del tiempo que se tardará en resolver la incidencia de tal manera que pueda informar a los usuarios de cuando va a ser restablecido el servicio afectado. A día de hoy muchas de las aplicaciones de gestión de servicios IT incorporan una especie de marquesina en la que continuamente se puede mostrar este tipo de información. En el caso de que tú herramienta no disponga de esta funcionalidad existe software alternativo que realiza esta misma función. Lo mejor sería que la mayor parte de la información que se muestre a los agentes del Service Desk sea actualizada de forma automática, tarea nada complicada si el impacto de las incidencias esta bien organizado. Situar en la misma ubicación a los integrantes del Service Desk y del equipo de Monitorización de sistemas, también ayudará a que ante caídas en los sistemas la información fluya rápidamente y la respuesta al usuario final sea la más adecuada posible. 

Por lo general los agentes de Service Desk estarán saturados de trabajo, es por esto que es muy deseable que la información que les llegue sea: clara, concisa y escueta. En lugar de decir "Error Winsock proxy del servidor  Gondor" es mucho más útil decir "El servicio de Internet esta caído". Mas adelante hablaremos de los tiempos estimados de solución, pero es muy aconsejable informar de cuanto tiempo se tardará en restaurar el servicio afectado.

Las puestas en producción de nuevas aplicaciones así como los cambios importantes en la infraestructura, deben ser notificados con antelación suficiente junto con aquellos usuarios y servicios que pueden verse afectados. El Service Desk se encargará de transmitir esta información al usuario final y dispondrá de ella ante posibles incidencias.

En este post me he centrado en la comunicación que se debe tener con el Service Desk pero no hay que olvidarse que, tener una comunicación fluida entre todos los integrantes de la organización IT es fundamental para alcanzar unos objetivos comunes. Los responsables de los procesos tienen la obligación de mantener una relación estrecha y fluida. Las reuniones operativas deben ser principalmente eso, o·p·e·r·a·t·i·v·a·s. Deben tener un orden estructurado y el objetivo de estas es aportar soluciones rápidas, pero de este tema hablaré otro día.

Alberto Álvarez

Gestión de problemas, el eterno ausente.

Como ya he tratado en otros post, uno de los objetivos principales que debería tener cualquier organización que siga el conjunto de mejores prácticas ITIL es disminuir el número de incidencias. Para alcanzar esta meta un paso fundamental es la implementación del proceso de Gestión de Problemas. Por lo general este proceso es el gran ausente dentro de los proyectos, mi experiencia me indica que el problema reside en ese tsunami llamado "el día a día", capaz de llevarse por delante al mejor de los gestores.

Qué se suele entender por la Gestión de Problemas ITIL:

• Una agrupación de incidencias.
• Se suele utilizar únicamente para buscar la causa de los "major incidents".
• Un proceso el cual es una perdida de tiempo y recursos.
• Una única persona a la que se le encomienda esta tarea.

Craso error. Este proceso es sin duda uno de los que más nos puede ayudar al tan buscado "alineamiento con el negocio". Su rendimiento al principio puede que no sea muy notable, pero a medida que vayamos madurando el beneficio obtenido será grande.

Uno de los pilares para que la Gestión de Problemas tenga éxito es el confeccionar un buen equipo de trabajo. Por si no he hecho suficiente énfasis, repito, equipo de trabajo. Ningún proceso ITIL debería ser llevado a cabo por un único individuo y quizás el mas claro exponente sea este. Ahora estarás pensando ¿y de dónde saco yo estos recursos?, ¿mi presupuesto no llega para dedicar a varias personas a este proceso?. La respuesta es: utiliza un workaround. Si no dispones de personal suficiente, selecciona a personas dentro de tú equipo actual y dedica parte de su tiempo a trabajar en este proceso. El perfil que debes buscar es el siguiente:

• Autodidacta. Recuerda que la tarea que le vas a encomendar es de investigación, necesitas a personas que sean capaces de incrementar sus conocimientos de manera autosuficiente.
• Conocimientos técnicos multidisciplinares. En la búsqueda de la causa raíz de una incidencia será necesario tocar distintos palos dentro de los sistemas de información.
• Constante. Hay que buscar soluciones definitivas, no es suficiente con soluciones temporales, el objetivo es erradicar la(s) incidencia(s).
• Hambre de conocimiento. Siempre he dicho que hace más el que quiere que el que puede. 

Es fundamental que el tiempo dedicado sea en exclusividad. No se hará un buen trabajo si se intenta buscar solución a una incidencia y al mismo tiempo buscar una solución definitiva. Además hay que tener en cuenta que el Gestor del proceso debería dedicarse en exclusiva al mismo. Si no puede ser así el Gestor de Incidencias nunca debe ser el mismo que el de Problemas. Fundamentalmente por una cuestión de objetivos. Las incidencias deben solucionarse cuanto antes, sin embargo para los problemas es preferible invertir más dedicación con el objetivo de encontrar la causa del fallo.

Aunque habrá más post dedicados a la Gestión de Problemas, una reflexión más sobre este proceso. Los responsables de Gestión de incidencias y Gestión de Problemas deben tener una relación fluida y continua. Prácticamente han de ser inseparables, el uno(a) sin el otro(a) no tendrán éxito en sus funciones, tienen que comunicarse continuamente y deben construir una simbiosis perfecta.

Alberto Álvarez

Gestión de incidencias. El valor para el negocio (II).

En el último post hablé de como clasificar las incidencias una vez registradas en la plataforma de gestión de servicios TI. Esto permitirá obtener información que es muy distinto a una simple recopilación de datos. Pues bien una vez que dispongamos de información útil, es necesario trabajar con ella para conseguir un objetivo, "valor para el negocio". Mi propuesta es elaborar un "Plan de acción" que permita identificar áreas de mejora y establecer una meta medible.

Un plan de acción relacionado con el proceso de Gestión de Incidencias debe contener tres partes claramente diferenciadas:

• Identificación de tendencias negativas.
• Acciones a llevar a cabo para revertir una situación negativa.
• Indicadores esperados una vez implementadas estas acciones.

Si se lleva a cabo una buena clasificación de incidencias, identificar repeticiones de las mismas o carencias en los sistemas de información, será una tarea sencilla y casi me atrevería a decir que automática. En esta primera parte del plan de acción es conveniente detallar de forma numérica estas situaciones. La información resultante en la estadística mostrada esta directamente relacionada con los niveles de clasificación que se hayan implementado. Siguiendo las recomendaciones de la primera parte de este post, se pueden detectar: necesidades de formación en las distintas aplicaciones puestas en producción, puestos clientes que necesitan ser renovados o patrones de fallos en algún elemento de comunicaciones.

Una vez hecho el retrato de que "esta pasando" con las incidencias llega el momento de tomar decisiones. Es importante detallar a bajo nivel las acciones que se van a emprender para cada una de las áreas de mejorada reflejadas en la parte anterior del plan. Por ejemplo si una de las propuestas consiste en impartir una formación al usuario final en una determinada aplicación, se debe fijar un temario y las fechas en las que se llevará a cabo la misma. Puede ser que la solución pase por implementar un cambio en la infraestructura, en este caso la planificación y puesta en marcha del mismo será encomendada al proceso de Gestión de Cambios.

Por último y quizás lo más importante, hay que fijar la mejora que se espera conseguir una vez implementadas las acciones a llevar a cabo. En muchas ocasiones este punto se convierte en un verdadero conflicto. El miedo a establecer unas metas que posteriormente no sean alcanzadas influye en el establecimiento de los indicadores de mejora. Mi consejo es que hay que quitarse este miedo. Si las dos primeras partes del plan de acción se han trabajado de forma correcta, lo que es seguro es que obtendremos una mejora, mayor o menor pero al fin y al cabo una mejora.

Una vez que se hayan llevado a cabo todas las acciones contenidas en el plan y se haya alcanzado el período establecido, lo único que falta por hacer es medir nuevamente. En un informe de cierre se debe hacer un resumen del plan de acción y reflejar el grado de consecución de las metas prefijadas.

Por supuesto que todo esto esta muy relacionado con el proceso de Mejora Continua del Servicio pero esto es harina de otro costal.

Alberto Álvarez

Gestión de incidencias. El valor para el negocio (I).

La implantación de cualquier proceso ITIL en una organización debe tener como objetivo principal el de "ayudar" a la parte de negocio a conseguir sus objetivos. El proceso de Gestión de Incidencias es uno de los que más puede aportar desde mi punto de vista. La misión fundamental de este proceso es la de restaurar cuanto antes un mal funcionamiento de los sistemas de información. Pero, ¿que más debe hacer un buen proceso de Gestión de Incidencias? Aportar valor añadido.

La pregunta es inmediata ¿y como se consigue esto?. En mi opinión la Gestión de Incidencias debe trabajar, codo con codo, con la Gestión de Problemas para conseguir una meta común, disminuir el número de incidencias. Si se consigue esto, el negocio se verá satisfecho y además el valor añadido será fácil de demostrar. En los próximos post voy a hablar de dos conceptos que se me antojan decisivos a la hora  de plantearse este reto:

• Informe de tendencias.
• Plan de acción.

Elaborar un informe de tendencias debería ser una tarea constante en el tiempo. A través de él se consigue fotografiar que es lo que esta fallando en los sistemas de información, es decir encontrar donde está la herida. El problema para elaborar este tipo de informes aparece cuando hay un volumen muy elevado de elementos a observar. ¿Cómo elaborar este informe y no morir en el intento? En primer lugar tenemos que conseguir una agrupación concisa de todas las incidencias. Para ello entra en juego la "Categorización", es decir como clasificar las incidencias. El diseño de las distintas categorías va a incidir directamente en los resultados de los informes del proceso y muy concretamente en el de tendencias. Utilizar más de cuatro niveles dificultará, y mucho, el trabajo de los Agentes del Service Desk a la hora de registrar la incidencia, si además en cada nivel se incluye un número muy elevado de términos acabaremos consiguiendo una clasificación poco eficaz. 

Crear una codificación clara y concisa es el reto a conseguir. Mi propuesta es. crear un sistema en que cada nivel de la clasificación responda a una pregunta directa: ¿cuál es el elemento afectado?, ¿dónde reside el fallo?, ¿que ha provocado el fallo?

Por lo general el primer nivel de la categorización se dedica siempre al mismo criterio: hardware y software, es más si nos fijamos en el ejemplo que aporta el libro de Operación del Servicio estos son los conceptos propuestos. Para mi esto es un error muy grave. La mayoría de las herramientas actuales permiten que a la hora de registrar una incidencia se le asocie un "ci", o elemento de configuración, afectado. Dependiendo del nivel de detalle de la CMDB, la identificación del elemento será más o menos concisa pero cuando menos podremos tener claro si lo que ha fallado es la parte hardware o la parte software. Si se sigue este método el primer nivel de la clasificación "tradicional" nos lo podemos ahorrar.

¿Dónde reside el fallo? Es un mal funcionamiento por parte del usuario o por el contrario ha sido un fallo debido a los sistemas de información. Facilitar la respuesta a esta pregunta servirá para que el negocio tenga una primera información muy valiosa, supongo que os imagináis cuál.

¿Qué ha provocado el fallo? Ha sido un error en la configuración, una avería física (orientado a hardware), es un error de aplicación, es la BB.DD... Es importante recordar que todas las respuestas deberían ser lo más sencillas posibles con el objetivo de facilitar la tarea de los agentes del Service Desk a la hora de hacer una primera clasificación de las incidencias (en otra ocasión trataré un tema muy controvertido "clasificación inicial vs clasificación final). Con esto podremos identificar si son mis proveedores de software los que no están haciendo un buen trabajo o el departamento de administración de sistemas, ¿verdad?

Cada organización debe plantearse sus propias preguntas y respuestas para atender a la clasificación de las incidencias, pero una pregunta que deberían tener en común todas las organizaciones es ¿que información quiere el negocio?, en base a su respuesta se deberían organizar los niveles de clasificación.

Una vez las incidencias se encuentran clasificadas de forma lógica y enfocada a las necesidades del negocio, elaborar un informe de tendencias es una tarea relativamente sencilla, y se habrá dado el primer paso para aportar valor añadido. el próximo post tratará sobre el "Plan de acción".

Alberto Álvarez

Service Desk. Canales de entrada.

En los distintos proyectos en los que he tenido la suerte de participar, he visto distintos canales de entrada puestos a disposición del usuario final. También es cierto que principalmente por muchos canales que existan, los usuarios suelen utilizar dos fundamentalmente: teléfono y correo electrónico. Sobre como gestionar el primero ya hemos hablado en un post anterior, "Dimensionar el Service Desk". Pero hoy me gustaría hablar especialmente del segundo, el correo electrónico.

A nivel personal siempre he dicho que el email es un invento del mismísimo diablo, pero para un Centro de Atención a Usuarios es una herramienta más para comunicarse con el usuario, y como tal en el Acuerdo de Nivel de Servicio puede que se establezcan unos tiempos específicos para su tratamiento. Hace un tiempo un cliente, al que venimos prestando servicio desde hace mucho tiempo, me planteo una queja sobre el tratamiento que se le estaba dando a los correos electrónicos por parte de los agentes. Concretamente el problema residía en que las peticiones de alta de usuario (recibidas siempre a través de email), se estaban registrando con retraso. Por otra parte una vez registradas el Service Desk termina su función y son otros los técnicos encargados de proceder al alta del usuario en los sistemas de información, con lo cual el retraso acumulado no solo afecta a la primera línea de soporte.

El proyecto en cuestión, como la mayoría de los proyectos hoy en día, tiene un dimensionamiento muy ajustado (la crisis económica). El número de agentes que tratan las llamadas de los usuarios y sus correos electrónicos, es insuficiente. Ante la queja del cliente, una de las propuestas surgidas en el proyecto fue: "dedicar una persona en exclusiva a realizar el tratamiento de este canal de entrada".

¿Es esta una solución adecuada?

Rotundamente NO!

Dadas las circunstancias del proyecto desviar un recurso para realizar esta tarea, no hará otra cosa que debilitar la atención telefónica, de por si ya bastante mermada. Por otra parte, el registro de este tipo de peticiones es mecánica y consiste principalmente en un copy/paste del correo del usuario en el sistema de gestión de incidencias/peticiones.

Por circunstancias que no vienen al caso, el proyecto en cuestión no dispone de un canal "web" para que el usuario pueda registrar automáticamente esta petición. Mi propuesta fue clara, hay que implementar este canal y además de forma urgente. El valor añadido de un agente de Service Desk para este tipo de peticiones es nulo. Mediante el canal web la petición puede llegar automáticamente al técnico encargado de llevar a cabo las altas en los sistemas de información de manera inmediata. Es más si se utilizan otro tipo de herramientas (más adelante dedicaré un post a este tema) combinadas con el canal web, la ejecución de esta tarea se podría llevar a cabo de forma automática y en pocos segundos, cosa que aumentaría y mucho la satisfacción del usuario final y por supuesto del cliente.

Con este ejemplo intento transmitir:

• En tiempos de crisis o en proyectos excesivamente ajustados hay que optimizar al máximo las tareas repetitivas.
• Saturar el Service Desk no es una solución valida ante este tipo de problemas.
• A día de hoy un canal "web" se me antoja fundamental y la mayoría de las herramientas ponen a disposición del usuario final un formulario ajustable a las necesidades de cada organización.
• Ayuda y mucho revisar los procedimientos de actuación y no simplemente basar las soluciones en un mayor dimensionamiento del proyecto.

¿Cual es tú opinión?

Alberto Álvarez

Service Desk. Diagnóstico inicial de las incidencias

Dentro del flujo del proceso de Gestión de Incidencias, existe una estación que me parece fundamental a la hora de tener un proceso eficaz y de valor para la parte de negocio, el diagnóstico inicial.  En el libro de Operación del servicio se hace una muy breve descripción sobre que se debería hacer en este punto del flujo y creo que en él radica la parte más importante de todo el tratamiento de una incidencia.

Si el diagnóstico inicial no es correcto la incidencia con total seguridad se resolverá en un tiempo excesivo, tendrá un escalado incorrecto y necesitará de un segundo contacto para poder solucionarla. Por supuesto esto llevará consigo una insatisfacción por parte del usuario y un más que probable incumplimiento del Acuerdo de Nivel de Servicio. 

A través del siguiente ejemplo (real) explico mi teoría:

• Usuario: "Buenos días, no puedo entrar en la aplicación X ...".

Tras una breve conversación realizando una serie de preguntas...

• Agente Service Desk: "He registrado los datos que me ha facilitado, su número de incidencia es la YYYY, a continuación voy a pasar su incidencia a mis compañeros para que le den solución, buenos días..."

Por lo general si el Agente de Service Desk no tiene suficiente experiencia la incidencia será clasificada dentro de la categoría de Software y como subcategoría el nombre de la aplicación. El paso siguiente será proceder al escalado de la misma y con muchas probabilidades de que llegue al grupo especialista en dicha aplicación. El punto clave para llevar a cabo el mejor tratamiento de esta incidencia esta precisamente en la "conversación" que mantiene el Agente de Service Desk con el usuario final.

Este es el momento adecuado para realizar un diagnóstico que debe tender en la mayoría de las ocasiones a ser un diagnóstico inequívoco, si lo que buscamos es tener un proceso de gestión de incidencias eficaz y optimizado al máximo. Para conseguir esto se deberían seguir las siguientes pautas:

• Las preguntas que se hacen por parte del Service Desk tienen que estar orientadas a encontrar que es lo que verdaderamente no funciona.
• Los agentes de Service Desk deben tener a su disposición procedimientos diagnósticos, lo más automatizados posibles que ayuden a diagnosticar la incidencia.
• Hay que comunicar al Service Desk todas las  incidencias graves (major incidents).
• Si se quiere obtener un proceso homogéneo no podemos depender exclusivamente del conocimiento de los agentes. 

Volviendo al caso que exponía anteriormente, ¿que es lo que no funcionaba? Pues la solución final fue tan simple como volver a conectar el cable de red a la toma de la pared. Esta incidencia (repito, real como la vida misma), fue solucionada en un tiempo superior a las 4 horas, pasó por 4 grupos distintos (Service Desk, soporte funcional, comms y soporte in-situ). Todo este tiempo y los distintos escalados se podrían haber evitado con la ejecución de un simple ping...

En resumen si queremos evitar escalados incorrectos y tiempos excesivos de solución, hay que prestar mucha atención a un punto muy concreto dentro del flujo de incidencias, el diagnóstico.

Alberto Álvarez

Gestión de Incidencias. Tiempos de escalado.

Dentro del capítulo dedicado a la Gestión de Incidencias en el libro de Operación del Servicio hay un escueto apartado dedicado a lo que en la traducción al castellano se denomina "Escalas de tiempo". Quizás una traducción más acorde sea "Tiempos de escalado", puesto que en realidad está hablando del tiempo que tiene que pasar para que una incidencia sea escalado de un grupo de soporte a otro.

En este (repito), escueto apartado, se puede ver la siguiente cita:

"Las herramientas de Gestión del Servicio deben usarse para automatizar escalas de tiempo (tiempos de escalado) y escalar la incidencia como requieran unas reglas predefinidas."

Una buena frase pero bastante ambigua, ¿que son estas reglas predefinidas? En resumen lo que nos están diciendo es que dependiendo del tipo de incidencia y una vez transcurrido un tiempo pre-acordado, la incidencia debe pasar de un grupo de soporte a otro. Desde mi punto de vista para llevar esto a cabo, la organización de soporte debe estar en un grado de madurez muy alto. El forzar de forma automática un escalado puede llevar a situaciones en las que un grupo reciba una incidencia sin que el grupo anterior haya trabajado nada con ella. Esto generará tensiones entre los distintos grupos y empezarán a surgir las típicas quejas: "...es que las incidencias llegan sin documentar", "...esta incidencia ya la han resuelto en otras ocasiones", ...

Es cierto que para cumplir unos indicadores establecidos en un ANS, es necesario medir muy bien los tiempos y tener unos tiempos de escalado automáticos ayuda desde un punto de vista de Gestión. Sin embargo no parece muy operativo, a no ser que la Gestión de Incidencias sea un proceso muy maduro. De todas formas siempre hay un camino intermedio y este es del que me gustaría hablar. Creo que para una organización que esta empezando, es suficiente identificar aquellas incidencias que si se van a escalar de forma automática y solo aquellas que estén muy bien definidas. Lo primero que hay que tener claro es:

• Qué tipo de incidencias van a ser resueltas y por cada grupo de soporte. 
• Muy importante, hay que tener en cuenta la criticidad de la incidencia (en otra ocasión le dedicaremos un post a este tema). 

Teniendo despejadas estas dos dudas mi consejo es crear una matriz inicial o lo que es lo mismo establecer las reglas predefinidas. Este podría ser un pequeño ejemplo:

Matriz-Tiempos de escalado

En esta pequeña matriz se puede ver como un mismo tipo de incidencia (Impresora de Urgencias) tiene un tiempo de escalado distinto en función de la criticidad. Este dato se me antoja fundamental si queremos implementar unos tiempos de escalado automáticos. De no ser así corremos el riesgo de involucrar a un determinado grupo sin necesidad. Cada organización es distinta y los tiempos de escalado tendrán que adaptarse en función de las necesidades particulares.

Alberto Álvarez

Dimensionar el Service Desk (y II)

Tengo claro que el dimensionamiento de la primera línea de contacto es fundamental para que el servicio de soporte tenga unas raíces firmes y capaces de alimentar el buen funcionamiento del resto de la organización TI.  Que el Centro de Atención a Usuarios no funcione adecuadamente es un factor clave de fracaso para el servicio completo, de ahí que sea tan importante realizar un buen trabajo inicial. En el post anterior comencé a explicar que procedimiento sigo para dar con el número adecuado de agentes del Service Desk, voy a terminar de contar los últimos pasos.

Tal y como os decía para llevar a cabo esta tarea utilizo una aplicación basada en las fórmulas de Erlang C y había descrito hasta el punto en el que una vez introducidos los parámetros adecuados, la herramienta estaba en disposición de especificar el número de agentes requeridos para cumplir con el Acuerdo de Nivel de Servicio establecido. El último paso y no menos importante es el de introducir en la herramienta el número de agentes por tramo horario que configurarán el servicio final. Es aquí cuando hay que comenzar a "jugar" con el dimensionamiento para llegar a la configuración final más adecuada. Una vez que la aplicación nos muestra el número de agentes requeridos por cada tramo horario, el resultado final puede variar y mucho dependiendo del sobre o infradimensionamiento que apliquemos para los distintos tramos horarios.

La herramienta que yo utilizo, permite introducir además del número de técnicos por tramo horario, los descansos de que van a disponer o las pausas para comer. Estos tiempos son importantes y si no se tienen en cuenta, el dimensionamiento no será adecuado y no se cumplirá el objetivo marcado. Una vez introducidos el número de agentes, la aplicación indica cual es el porcentaje alcanzado según los parámetros introducidos (los que señalé en el primer post). Normalmente el número de llamadas entrantes varia dependiendo de la hora del día,  las horas de entrar a trabajar de los usuarios los cambios de turno o las pausas para tomar el café, suelen reflejarse de manera clara en la gráfica de llamadas entrantes por tramo horario. En los picos esta claro que el dimensionamiento será mayor y los valles suelen ser los períodos más adecuados para que los agentes del Service Desk descansen o realicen otras tareas establecidas para la primera línea de soporte.

Habitualmente se suele realizar un dimensionamiento paralelo a los datos que nos requiere la calculadora de Erlang, pero ojo, no es el método más eficiente desde mi punto de vista. Os aconsejo que "juguéis" con el número de recursos, sobre todo estableciendo un sobredimensionamiento en aquellos tramos de más volumen de llamadas entrantes y todo lo contrario en aquellos tramos de menor actividad en las llamadas.

Por último os dejo unas apreciaciones personales:

• El dimensionamiento del Centro de Atención a Usuarios es una tarea dinámica. Varia y mucho dependiendo del mes o por ejemplo de la fecha de puesta en producción de una nueva aplicación.
• Es muy importante que tengamos claro que la mayoría de las aplicaciones que utilizan las fórmulas de Erlang, solo tienen en cuenta los tiempos de las llamadas entrantes. Otras tareas que realiza un agente o por ejemplo el tiempo de las llamadas salientes no se tienen en cuenta.
• Este tipo de herramientas no solo se pueden utilizar para establecer un dimensionamiento futuro, también es muy recomendable utilizarlas para saber en que hemos fallado una vez que tenemos datos reales de como ha ido una jornada.
• El que un recurso a tiempo parcial se incluya en el equipo de agentes del Service Desk, puede llegar a variar de forma considerable el objetivo alcanzado.
• El tiempo medio de llamada es un dato primordial para las fórmulas de Erlang. Trabajar con los agentes para bajar este tiempo influirá y mucho en el dimensionamiento del Service Desk.

Alberto Álvarez