Texto de apoyo IM

Objetivo

Ya que la Gestión de Servicio de IT está orientada en torno a la entrega de niveles predeterminados de servicio a los usuarios finales, es sensato instalar una organización cuyos directivos sean:
Monitorizar el entorno de IT para el cumplimiento de esos niveles de servicio predeterminados y escalar adecuadamente incidentes en la entrega de servicio cuando surjan.
La función de la Gestión de Incidencia tiene la responsabilidad de resolver incidencias cuánto antes.
Ciertamente, la importancia del proceso de Gestión de incidencia se puede resumir como sigue: cuando un usuario experimenta un incidente el proceso de Gestión de Incidencias asegurará que el servicio del usuario estará conectado de nuevo tan pronto como sea posible.

El objetivo principal de la Gestión de Incidencias es:
Resolver el asunto de servicio tan pronto como sea posible, al menos dentro del tiempo objetivo documentado en el acuerdo de nivel de servicio
Mantener la comunicación viva entre la organización de IT y su cliente sobre el estatus con relación al asunto de servicio (p.ej. Escalada, tiempo estimado de resolución)
Evaluar una incidencia para determinar si es probable que vuelva a ocurrir o si es síntoma de un problema crónica. Si lo es, informar a un Director de Problemas al respecto

Actividades

Actividades de la gestión de incidentes:
Detección y grabación del incidente
Clasificación y apoyo inicial
Investigación y diagnóstico
Resolución y curación
Cierre del incidente
Propiedad, monitorización, rastreo y comunicación

Funciones y Responsabilidades

Los procesos abarcan la jerarquía de la organización. Por consiguiente es importante definir las responsabilidades asociadas a las actividades que tienen que realizarse en el proceso. Mantener flexible, es aconsejable para usar el concepto de las funciones de cada papel; en muchas organizaciones los papeles pueden ser combinados por el tamaño pequeño de la organización o por razones de costes. Por ejemplo, muchas organizaciones combinan las funciones de Gestión del Cambio y de Gestión de la Configuración. Una función o papel abarca un conjunto de responsabilidades, tareas y niveles de autorización.

Encargado de Incidentes

Un administrador o encargado de incidentes tiene las responsabilidades sobre:

• Llevar la eficiencia y la efectividad de los procesos de los procesos
• Producir el manejo de los informes y métricas
• Manejar el trabajo de los empleados del soporte de incidentes
• Monitorizar la efectividad del manejo de incidentes y de las recomendaciones principales para el mejoramiento
• Desarrollar y mantener el sistema de gestión de incidentes

Plantilla para la manejo de Incidentes

Las responsabilidades en primera línea (Service Desk) incluyen:

• El registro de incidentes
• Hacer un seguimiento de las demandas para apoyar los grupos cuando entren incidentes y no están completadas
• Soporte inicial y su correspondiente clasificación
• Propiedad, monitorización, seguimiento y comunicación
• Resolución y restablecimiento
• De los incidentes no asignadas a soporte de segunda línea
• Cierre de los incidentes

Soporte en segunda línea (grupos especiales que no deben estar dentro del grupo del Service Desk) estarán envueltos en las tareas como:

• Tratar el servicio de demandas
• Monitorizar los detalles de los incidentes, incluyendo el punto de configuración afectada
• Investigación de incidentes y diagnostico (incluyendo la resolución si es posible)
• Detectar posibles problemas y el encargo a ellos de la gestión del problema, con tal de aumentar los registros de problemas
• La resolución y restablecimiento de los incidentes asignados

Propiedad, monitorización, seguimiento y comunicación de las tareas cubre:

• Monitorizar el estado y la evolución hacia la resolución de todos los incidentes abiertos
• Mantener a los usuarios afectados informados sobre la evolución
• Escalar el proceso si es necesario

Descripción

Terminología

Algo que ocurre que no es parte del servicio acordado se llama una incidencia. La mayor parte del tiempo, esta incidencia está interrumpiendo el servicio, algunas veces sólo está reduciendo el servicio. Nosotros aún así lo llamamos una incidencia. Y, en 99 de cada 100 casos, esta incidencia es reactiva por lo que ya ha interrumpido o reducido el nivel de servicio, pero en esa única vez tenemos suerte y estamos pro-activos porque lo vemos venir. Incluso entonces, alzaremos esa incidencia pero con suerte lo resolveremos antes de que el cliente lo averigüe.
Un workaround es un método de evitar una Incidencia o un Problema, bien desde una solución temporal o bien desde una técnica que significa que el Cliente no depende de un aspecto particular del servicio que tiene un problema conocido. Es habitualmente la primera solución que restaura el servicio. No es una solución permanente pero algo que implementamos para hacer que el servicio continúe sin sobresaltos. Un workaround habitualmente reducirá el servicio. Redirigir trabajos de impresión a otra impresora en el mismo edificio es un workaround. El usuario puede obtener los impresos pero tendrá que andar una distancia para obtenerlo.
Una solicitud de servicio podría ser una solicitud de información o una solicitud de cambio relacionado con uno de los servicios que entrega tu organización. Es, de hecho, cada llamada que no es una incidencia.
De nuevo hablamos de la interrupción o reducción de SERVICIO DE PRINCIPIO A FINAL. Todo aquello que causa esta reducción o interrupción se llama una incidencia, no sólo si hablamos sobre parte de la tecnología que no funciona.

Inversiones y Rendimientos (Inputs y Outputs)

Inversiones (Inputs)

Muchas inversiones son necesarias para la Gestión de Incidencia.
Incidencias del Service Desk
Obvio, pero aún merece mención. El proceso no existe si no se registran incidencias.

Información de Configuración

La CMDB es uno de los mayores "proveedores” de información para este proceso. Las relaciones entre los Cl’s mismos pero también entre los Cl’s y expedientes de incidencias anteriores, errores conocidos, cambios y acuerdos de niveles de Servicio, la historia y más información detallada sobre los Cl’s es crucial para la solución de incidencias.

Respuesta de emparejar incidencias con problemas y KE (Errores Conocidos /Known Error)

Notificación de que una incidencia no se empareja con un problema y /o error conocido es información valiosa que nos puede ayudar a resolver la incidencia más rápidamente.

Detalles de resolución

Los detalles sobre resoluciones anteriores de incidencias- y no sólo los parecidos o los mismos- es de nuevo información valiosa para una rápida restauración del servicio.

Respuesta sobre RFC para efectuar resolución de incidencias
Feedback de la organización de Gestión de Cambios sobre los resultados del cambio para que podamos revisarlos.

Rendimientos (Outputs)

RFC para resolución de incidencias; Historial de Incidencias actualizado

Necesitamos RFC’s para la restauración de servicio que se debe alcanzar mediante cambios. Este proceso los generará.

Incidencias resueltas y cerradas

• La solución de incidencias y expedientes cerrados con toda la información necesaria sobre cómo se resolvió es información valiosa para la Gestión de Problemas

Comunicación a los Clientes

La comunicación durante el ciclo vital total de una incidencia es el rendimiento más importante de este proceso mediante el Service Desk a los clientes/usuarios finales

Información de Gestión (Informes)

Información de Gestión sobre los resultados y rendimiento del proceso.

El Ciclo de vida de la Incidencia

Aceptar el evento de servicio, Registrar y consultar la CMDB

La interacción del cliente ya no se restringe al contacto telefónico y personal. El servicio se puede realzar mucho y se puede extender al Cliente, los Usuarios y Personal de soporte al expandir los métodos para registrar, actualizar y consultar solicitudes.

El registro de datos de acuerdo a la interrupción o reducción del servicio es muy importante para:

• Localizar la incidencia a lo largo de la totalidad de su ciclo de vida
• Añadir información útil que puedan ayudar, informar y asistir organizaciones de soporte para que puedan encontrar una solución o un workaround (antes)
• Recoger información histórica para futuro uso

Coleccionar información (p.ej. Para informes) sobre un número de incidencias, eficiencia, disponibilidad y análisis de tendencias y otros procesos de gestión

Consultar la CMDB es necesario para obtener información sobre el servicio que se interrumpe, los datos de los Acuerdos de Nivel de Servicio, los CI’s relacionados a este servicio y esperamos relacionados con incidencias pasadas, errores conocidos y cambiar expedientes.

Clasificación

El Service Desk determina la prioridad de las incidencias a medida que las recibe.
Consultando con el Cliente, el Service Desk calculará la prioridad a partir del impacto y la urgencia de la incidencia.

Solucionar

Otros grupos de soporte empezarán a analizar la incidencia con el sólo propósito de encontrar una solución permanente, o —de no ser esto posible- encontrar un workaround

Cierre

Si se indica una solución permanente o un workaround esto lo implementaremos y restauraremos el servicio. El grupo de solución informará al Personal del Service Desk. El Personal del Service Desk investigará con el cliente si la solución/workaround ofrecidos han restaurado el servicio como se requiere. Si es el caso, entonces el Personal puede cerrar la incidencia.

Clasificación: Prioridad y Categoría

El Service Desk determina la prioridad de las incidencias a medida que las recibe.
Consultando con el Cliente, el Service Desk calculará la prioridad a partir del impacto y urgencia de la incidencia, considerada frente al criterio descrito en el Acuerdo de Nivel de Servicio y lo el Estatuto de Servicio…

El criterio típico debería incluir:

• Coste potencial de la no-resolución
• Amenaza de lesión a clientes o empleados
• Implicaciones legales
• Trastorno a clientes y empleados

El impacto no trata de la complejidad de la solución
Al priorizar las llamadas en este punto, el soporte de segunda línea puede determinar fácilmente qué llamadas necesitan atención más urgente y en qué orden. Prioridad no trata simplemente de poner las incidencias en cola para su resolución; también trata sobre los recursos (tiempo, Personal, destreza, investigación y soporte de terceros) que se asignarán a la resolución. En términos prácticos, a veces una incidencia de baja prioridad puede que se permita no alcanzar su tiempo objetivo de resolución, para que una incidencia de más alta prioridad pueda tratarse dentro de su objetivo.
La categorización se hace para agrupar incidencias en una categoría específica. La ventaja más grande es que esto podría ayudar a indicar la ruta de solución que se podría tomar, el grupo de solución que se debería elegir (para referir a la incidencia también) y la posible solución.

Clasificación: Emparejamiento

Después de la categorización la incidencia se debe contrastar con la base de datos de incidencias, problemas y errores conocidos para investigar si se informaron de incidencias con los mismos síntomas antes y averiguar si existen problemas y/o errores conocidos. Si existen, lo más probable es que haya un workaround que podamos utilizar para restaurar el servicio. Emparejar los síntomas con una base de datos de conocimientos existente también es algo que se puede hacer aquí.
Si la incidencia no se puede emparejar entonces es una incidencia única. La solución lo más probable es que no pueda encontrarse en el Service Desk y por lo tanto, tenemos que referirlo al siguiente nivel de soporte.

Dirigir incidencias

A menudo, nos referimos a los departamentos y grupos de soporte (especialistas) además Service Desk como grupos de soporte de segunda o tercera línea, teniendo más habilidades especialistas, tiempo u otros recursos para resolver incidencias. A este respecto, el Service Desk sería soporte de primera línea. Para la dirección tenemos — podríamos decir- un procedimiento tradicional:

• Paso 1. Intento de resolución de la Incidencia por parte del Service Desk: Llevar a cabo la evaluación inicial y buscar una solución o workaround. Si se encuentra una solución, cerrar la incidencia. Si no, referirlo al siguiente nivel.
• Paso 2. Asignar la Llamada de Servicio al soporte de 2 línea: Si no se puede encontrar ninguna solución en el Service Desk, referirlo al soporte de segunda línea. Si el soporte de 2 línea puede encontrar una solución, referir de nuevo al Service Desk que cerrará la incidencia. Si no, referirlo al siguiente nivel.
• Paso 3. Asignar la Llamada de Servicio al soporte de 3 línea: Si no se puede encontrar ninguna solución en el soporte de segunda línea, referirlo ¿1 soporte de tercera línea. Si el soporte de 3 línea puede encontrar una solución, referir de nuevo al Service Desk que cerrará la incidencia. Si no, referirlo al siguiente nivel.
• Paso 4. Asignar la Llamada de Servicio al Especialista: Si no se puede encontrar ninguna solución en el soporte de tercera línea, referir a un especialista. Si el especialista puede encontrar una solución, referir de vueltá al Service Desk que cerrará la incidencia.

ETC.

Si no está claro qué grupo de soporte debería investigar o resolver una incidencia relacionada con un usuario, el Service Desk, como dueño de todas las Incidencias, debería coordinar el proceso de Gestión de Incidencias. Si hay diferencias de opinión o surgen otros asuntos, entonces el Service Desk debería escalar la Incidencia al equipo de Gestión de Problemas.
Noten que soporte de tercera o x-línea puede incluir finalmente proveedores externos que pueden tener acceso directo a la herramienta de registro de la Incidencia (dependiendo en las normas de seguridad y asuntos técnicos).

Escalada y Referencia

Dirigir se llama escalada horizontal o referencia. Referimos la incidencia porque necesitamos más conocimiento.
Si necesitamos más soporte, más dinero y más poder (decisiones) para resolver una incidencia y que más personas trabajen en esta incidencia, es necesaria la escalada vertical. Pero también, informar a dirección de qué ocurre y mantenerles al día, o pedir su soporte porque el progreso del proceso falta, se llama escalada horizontal.
Debería haber un procedimiento para ambas escaladas. Y es muy importante que el Personal del Service Desk monitorice el progreso de la escalada.
Escalada o Referencia NUNCA convierte una incidencia en un problema, aunque pueda resultar en que la propiedad de una incidencia pase al Director de Problemas por razones administrativas y con ello la identificación de un problema asociado. Problemas no son sólo incidencias muy serias.

Informes de Gestión

Informar es MUY importante. La Mejora de Calidad está basada fundamentalmente en INFORMACION. Sin registro de alta calidad e informes flexibles no tenemos la información que necesitamos y entonces mejora de calidad no es posible, o al menos no al nivel que podríamos alcanzar.
La información, claro está también es importante:

• Para los Directores de Nivel de Servicio / Directores de Cuentas es importante tener la información para sus clientes, para que puedan en primer lugar dar toda la información acerca de nuestro rendimiento en relación con el rendimiento acordado en los Acuerdos de Niveles de Servicio. Pero esta información también nos da input para la negociación de los niveles de servicio en futuros Acuerdos de Nivel de Servicio. Por último pero no de menor importancia, podemos comprobar cómo lo hicimos y a veces es importante por el hecho de que la perspectiva del usuario no siempre es lo que hicimos en realidad.
• Para la Dirección (incidencias) es importante saber cómo rinde el proceso del Service Desk /gestión de Incidencias. ¿Cómo de efectivos son los empleados al manejar las llamadas? ¿Referimos las llamadas al grupo de soporte correcto? ¿Cuántas incidencias se resolvieron dentro del Service Desk / soporte de 1 línea? ¿Conseguimos alcanzar los términos de los Acuerdos de Nivel de Servicio? ¿Cómo rendimos al referir el tema? ¿Cómo fue nuestro progreso en general pero también con relación a los códigos de severidad?
• Para otras partes de la organización y los directores de procesos es, por ejemplo, importante saber cómo de fiables son los CIs. ¿Cuál fue el tiempo de Downtime de los CI’s? ¿Qué tipo de incidencias hemos tenido? Si las incidencias tenían que ver con cambios malos. Si las incidencias se relacionan con asuntos de capacidad. ¡O asuntos de seguridad!
• Para la motivación de los empleados del Service Desk. Podría usar todas las cifras de informe mencionado anteriormente para mostrar a los empleados si mejoran y cuánto. ¡Esta es una herramienta muy poderosa!

Informes sugeridos son:

• Revisiones diarias de Incidencias individuales y estatus de Problemas con referencia a niveles de Servicio

P.ej. áreas que requieren escalada en grupo, posibles faltas de seguridad; todas las Incidencias pendientes.

• Revisiones de gestión semanales

P.ej. disponibilidad de servicio; áreas mayores de Incidencias; Incidencias relacionadas que requieren que se generen expedientes de Problema; Errores conocidos y Cambios requeridos; faltas de servicio; satisfacción de Cliente; tendencias, servicios mayores que afectan el negocio: carga de trabajo de los empleados.

• Revisiones de gestión mensuales

P.ej. disponibilidad de servicio; rendimiento general, análisis de objetivos alcanzados y tendencias; alcance de objetivos de servicio individuales; percepciones y niveles de satisfacción del Cliente; necesidades de educación y formación del Cliente; Personal de soporte y rendimiento de terceros; rendimiento de aplicación y tecnología; contenido de la matriz de revisión e informes; coste de provisión /falta de servicio.

• Informes de servicio pro-activos Consideren los siguientes informes para ayudar a esto:
• Cambios programados para la siguiente semana
• Incidencias /Problemas /Cambios mayores de la semana anterior
• Incidencias de Clientes “No satisfechos” de semanas anteriores
• Artículos de semanas anteriores de infraestructura de bajo rendimiento (p.ej. servidor, red, aplicación)