viernes, 3 de octubre de 2008

Gestión de incidencias, gestión de peticiones o, simplemente, gestión de tareas








En esta entrada voy a hablar de mi particular visión acerca de la gestión de incidencias y peticiones en los Help Desk, Service Desk, etc.


En la versión 2 de ITIL, el proceso de gestión de peticiones de servicio estaba incluido en el proceso de gestión de incidencias. Se entendía (y yo sigo entendiendo) que la manera de tratar las peticiones de servicio era bastante similar a la manera de tratar las incidencias. Si tenemos presente que las peticiones de servicio son aquellas solicitudes realizadas por los usuarios tales como, solicitar un PC nuevo, una conexión VPN, un restore, etc, podemos entender que se gestionen de forma parecida a las incidencias.

En la versión 3 de ITIL, ambos procesos se separaron. No me parece mal a nivel teórico. A nivel práctico sigo pensando que en ITIL versión 2 ya quedaba claro: al categorizar distinguimos entre incidencias y peticiones de servicio y luego clasificamos en función de la categoría elegida.

Tenemos, por tanto, por un lado gestión de incidencias y por otro gestión de peticiones. Sin embargo a mi me gusta hablar simplemente de gestión de tareas.

Para razonar lo anterior, empezaremos hablando de cómo se gestiona una incidencia o una petición de servicio. Se puede hacer, básicamente, de dos maneras:


1.- En lo que podríamos llamar "modo estrella": el operador del help desk recibe la llamada, el correo, lo que sea. El operador lo intenta resolver él en primera instancia y si no lo consigue lo pasa a un técnico. El técnico realiza la acción necesaria y devuelve la incidencia al operador. El operador la cierra si ya está resuelta o se la trasmite a otro técnico para que lo haga. Este segundo técnico devuelve la incidencia al operador y este la cierra si está resuelta o la envía a otro técnico....Aquí he exagerado el escalado, no suele haber tantos niveles.

Si se trata de una petición de servicio, lo mismo. El operador traspasa la petición al primer técnico para que realice la tarea. Una vez realizada, el técnico se la devuelve al operador para que este se la pase al siguiente técnico necesario para resolver la petición....

2.- También es posible que los diferentes técnicos implicados conozcan (o esté documentado), para cada tipo de incidencia y petición de servicio, quien es el siguiente que debe hacer algo. De esta manera. sólo el último, devolverá la incidencia o petición al operador de help desk para su cierre. Sinceramente, bastante difícil.

Todavía existe una tercera opción, la que a mi me gusta:

a) Para todas los tipos de incidencias y peticiones de servicio, definimos las tareas necesarias, quien las ha de realizar (grupo o persona) y las dependencias entre ellas.

b) Insertamos esta información en la herramienta y la asociamos a la clasificación de las incidencias y peticiones de servicio.

c) La herramienta nos permite la posibilidad de añadir o quitar tareas a las ya definidas por defecto.

d) Los diferentes técnicos y no técnicos que han de resolver la incidencia o petición de servicio trabajan únicamente con tareas de manera que ellos sólo ven en la herramienta aquellas tareas que pueden realizar. El flujo de las mismas ya está definido en la herramienta.

La gran mayoría de herramientas de nivel medio-alto permiten trabajar con flujos de tareas. Sin embargo, no se suelen utilizar porque no se ha realizado el trabajo previo de definir lo expresado en el punto a); o porque no se mantienen actualizadas; pero, sobretodo, por cuestión de precio.

Trabajando con flujos de tareas nos interesa que toda la organización de TI y, seguramente, parte de la organización fuera de TI, trabaje con la herramienta. Si, por ejemplo, el departamento de compras está fuera de TI y trabaja con nuestra herramienta, podremos asignarle la tarea de compra de un PC nuevo cuando entre un empleado en nuestra empresa.

El problema reside en que la gran mayoría de estas herramientas se licencian por puesto de trabajo y, entonces, se intenta minimizar el número de personas que necesitan trabajar con ella.







2 comentarios:

Adelina Bonet dijo...

Estoy totalmente de acuerdo con la premisa que comentas en referencia a que "no se ha realizado el trabajo de definir (...)", pero personalmente, considero que este ejercicio de definición debe hacerse en primer lugar, a un nivel mucho más conceptual, es decir, antes de pasar a definir las tareas y responsabilidades, debe quedar claro que es una incidencia y que es una petición de servicio, ya que es bastante habitual que la línea que las separa sea un tanto "flexible" (por no llamarla indeterminada)y sujeta a interpretaciones. Pongamos por ejemplo una petición de reset de password de acceso a la red. Generalmente se considera una petición de servicio, pero no deja de ser una incidencia puesto que el usuario en cuestión, no puede validarse en el dominio y por tanto acceder a las aplicaciones y recursos de red corporativos.
Me resulta curioso que en muchos casos, este trabajo de definición se centre primeramente en las posibilidades de la herramienta de Service Desk
antes que en la definición o mejor dicho, en la "estandarización" de estos conceptos. Ya que por más que la herramienta incluya todas las posibilidades de registro, si el operador de Service Desk no tiene clara esta diferenciación, pobablemente tenderá a utilizar siempre la opción más fácil (especialmente en un Service Desk en el que el tiempo de atención dedicado al usuario esté controlado y determinado por un volumen de llamadas entrantes muy elevado). En consecuencia, tendremos errores en la identificación y registro de llamadas (peticiones o incidencias) que tendrán una clara repercusión en la veracidad de los niveles SLA que se obtengan de la herramienta.

David Ortega dijo...

Estoy totalmente de acuerdo.