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
¿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
No hay comentarios:
Publicar un comentario