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

Dimensionar el Service Desk

Es cuando menos sorprendente que en la última "entrega" de ITIL, el Centro de Servicio al Usuario o Service Desk, solo se dediquen unas pocas líneas a la función clave de cualquier organización de soporte. De las más de sesenta páginas que se le dedicaron en la entrega anterior enmarcado dentro del Soporte de Servicio, hemos pasado  a apenas dos páginas y media. Desde mi punto de vista, el buen funcionamiento del día a día de cualquier centro orientado al soporte, tiene que cuidar con el máximo detalle la organización del Service Desk. Una de las tareas que más quebraderos de cabeza puede llegar a dar, es el correcto dimensionamiento del número de agentes que tienen que formar parte de la primera línea de soporte.

Como punto de partida en este primer post dedicado al Service Desk, me gustaría hablaros de como dimensionamos en Seresco esta función. No es ningún secreto que un estándar internacionalmente reconocido para llevar a cabo esta tarea es utilizar las fórmulas de Erlang. Para aquellos que todavía no lo sabéis, Agner Krarup Erlang  (1878-1928) fue un matemático Danes que en 1909 público su primer artículo acerca de la teoría de colas. Pues sí has leído bien, actualmente se están utilizando unas fórmulas que se desarrollaron hace más de un siglo! Claro está que a día de hoy ya no se utiliza el papel y el lápiz para trabajar con este conjunto de fórmulas, existen diversidad de aplicaciones software que realizan este cometido por nosotros.

No os voy a hablar de ninguna en concreto, pero si que me gustaría compartir con vosotros las principales características de este tipo de software. Lo primero que hay que tener claro es cual es el nivel de servicio que hemos acordado para nuestro Centro de Servicio al Usuario, el indicador principal que se suele utilizar es el número de llamadas que hay que atender (responder) antes de un determinado número de segundos. Las calculadoras de Erlang C, solicitan los valores que queremos alcanzar junto con al menos otros dos datos muy importantes. El tiempo medio estimado para cada llamada que tendrán que atender los agentes del Service Desk y el tiempo administrativo (wrap-up) del que queremos que disponga el agente una vez finalizada la llamada en curso.

Ademas también hay que introducir el porcentaje de llamadas que se pueden llegar a "perder" o lo que suele ser más habitual, el porcentaje de llamadas en las que un usuario puede llegar a escuchar el famoso mensaje "todos nuestros operadores están ocupados...". Por último el dato más importante, el número estimado de llamadas entrantes, habitualmente este dato es solicitado por tramo horario. Tras la introducción de estos datos el software esta ya en disposición de devolver el número de agentes requeridos para cumplir con el indicador establecido en el Acuerdo de Nivel de Servicio para el Service Desk.

En mi opinión es muy importante tener muy en cuenta los siguientes aspectos:

• Las calculadoras de Erlang están orientadas a realizar estimaciones en base al número de llamadas entrantes. Es decir si los agentes llevan a cabo otras funciones como por ejemplo realizar llamadas salientes para confirmar el cierre de incidencias o peticiones, registrar correos electrónicos,etc... este tiempo no es tomado en cuenta con lo cual el dimensionamiento puede variar.
• El wrap-up o tiempo administrativo es un parámetro con el que podemos jugar a la hora de forzar el número de agentes requerido. Mucho cuidado con este parámetro, a no ser que la dinámica de los agentes este muy clara, reducir excesivamente este tiempo influirá directamente en la calidad del registro de incidencias y peticiones.
• En mi opinión si se sigue a rajatabla el dimensionamiento estimado y los volúmenes establecidos son correctos es muy difícil no alcanzar el objetivo establecido. Es más, los datos que arrojan estas fórmulas a mi gusto son excesivamente conservadores y puede que en algún tramo el número de agentes requerido nos de alguna pequeña sorpresa.

En próximos post seguiremos ahondando en esta tarea tan fundamental como lo es el dimensionar adecuadamente el Centro de Atención a Usuarios.

Alberto Álvarez

Traicionando ITIL

Nuestro blog nace con la vocación de compartir experiencias recogidas a lo largo de diferentes proyectos de gestión TI en los últimos años. El objetivo principal es abrir un debate sobre temas tangibles de la gestión de procesos según ITIL y exponer métodos puestos en producción, que además sirven de ayuda a la integración de las TI y el negocio. Desde Seresco atesoramos experiencia y conocimiento suficientes para aportar nuestro granito de arena al entorno de la gestión de proyectos TI. 

Con una periodicidad semanal transmitiremos nuestra visión sobre distintas partes de la gestión TI y concretamente con todo lo relacionado con el conjunto de mejores prácticas ITIL. Esperamos que esta iniciativa sea recibida de buen grado y compartáis con nosotros vuestros comentarios, experiencias y puntos de vista. 

El título “Traicionando ITIL”, surge con la idea de completar este estándar internacionalmente reconocido, aterrizando todo aquello que en los libros suena demasiado etéreo y está falto de ejemplos prácticos. ITIL es algo más que hacer un examen para conseguir una certificación, aunque parece que cada vez más, esto se está convirtiendo en una práctica en España. Compartir experiencias es, desde nuestro punto de vista, el objetivo principal de ITIL y nuestro blog estará encaminado a esta idea.

Os damos a todos la bienvenida, nos leemos...