Mesa de ayuda Administración de incidentes y Administración de problemas

1. Mesa de ayudaAdministración de incidentes y Administración de problemas

2. Service Desk • Misión • El Service Desk es el punto focal para todas las peticiones de los usuarios de servicios de TI • Registrar y administrar el ciclo de vida de los incidentes, colocando énfasis en la rápida recuperación del servicio con mínimo impacto al negocio. • Help Desk, Línea de Servicio y Primer Nivel de Soporte son utilizados a menudo como sinónimos de Service Desk • Para los usuarios, el Service Desk está ahí para: • Proveer una interfase central de comunicación • Recuperar un servicio interrumpido lo antes posible

3. Service Desk • El Service Desk generalmente es visto como un grupo de especialistas quienes tienen el conocimiento requerido para procesar cualquier tipo de petición o incidente • La función de Service Desk puede alcanzar un alto grado de eficiencia tomando las siguientes medidas: • Definición de la mentalidad de “servicio” en la documentación de Service Desk. La tarea del Service Desk no consiste únicamente en “resolver un incidente” sino en la “recuperación inmediata del servicio del usuario” • Definición de procesos claros para soportar las actividades de los miembros del Service Desk (Incident Management Process) • Definición de relaciones cercanas entre Service Desk y otros miembros de procesos de ITSM, tales como Problem Management • Service Desk representa a la organización de TI desde el punto de vista del usuario

4. Service Desk • Actividades • Manejo de las llamadas • Registro y seguimiento de las peticiones de servicio, incluyendo incidentes, hasta el cierre y verificación con el usuario • Clasificación de incidentes y soporte inicial, incluyendo la canalización al segundo nivel, dentro de los niveles de servicio establecidos • Mantener informado al usuario sobre el estatus y prioridad de sus peticiones • Iniciar los procedimientos de escalación de acuerdo con el SLA • Coordinar el manejo de incidentes hasta su resolución con el segundo y tercer nivel de soporte • Ayudar a identificar problemas registrando todos los incidentes • Administrar la información y dar recomendaciones para la mejora de los servicios • Comunicar cambios planeados a los usuarios

5. Service Desk • Resumen • Service Desk es una función, no un proceso dentro de Service Management • Service Desk es el punto focal para todas las peticiones de servicio de los usuarios dirigidas a TI (incluyendo proveedores externos), y las administra de acuerdo con Service Level Agreements • Las responsabilidades de Service Desk incluyen: • Punto único de contacto • Incident Management • Primer nivel de soporte • Generación de reportes • Service Desk es la ventana del nivel de servicio ofrecido por la organización de TI • Mantener a los usuarios al día sobre el estatus y prioridad de sus peticiones • Provee la administración de información de los puntos relevantes relacionados con los servicios

6. Roles y Responsabilidades dentro del proceso

7. Roles dentro de la solución de procesos de Administración de Incidentes y Administración de Problemas

8. Roles dentro de la solución de procesos de Administración de Incidentes y Administración de Problemas

9. Roles dentro de la solución de procesos de Administración de Incidentes y Administración de Problemas

10. Flujo de los procesos de Administración de Incidentes y Administración de Problemas y su interrelación

11. Posibles estatus para incidentes y problemas

12. Con el propósito de poder dar seguimiento a un incidente a lo largo del sistema de control, se utilizan los valores de estatus y se mantienen en el registro del ticket del incidente

13. Con el propósito de poder dar seguimiento a un incidente a lo largo del sistema de control, se utilizan los valores de estatus y se mantienen en el registro del ticket del incidente

14. OTROSPROCESOS A D M I N I S T R A C I Ó N PROBLEMA S Administración de incidentes Conforme avanza la atención del incidente, los valores de estatus cambian y estos pueden ser utilizados para dar seguimiento al avance hasta su cierre

15. De manera similar, para dar seguimiento a problemas mediante el sistema, Se utilizan y mantienen los valores de estatus a lo largo del manejo del ticket

16. CONTROL DE CAMBIOS Problem Management Los valores de estatus cambian en función del avance de la solución del problema y se utilizan para dar seguimiento al avance

17. Prioridad de Incidentes y Problemas

18. priority 1 Description 2 ‘Alto’ Un sistema o aplicación se puede utilizar pero con restricciones grandes. El rendimiento esta severamente degradado. 3 4 ‘Bajo’ Este problema no afecta directamente la productividad del usuario y por lo general esta confinado a un solo usuario. Cada incidente o problema originan un impacto en las actividades del negocio. La combinación del impacto con la severidad establecen el nivel de prioridad Prioridad Descripción ‘Critico’ Se refiere a una caída mayor que afecta un gran número de usuarios. No se pueden cumplir compromisos críticos de negocio. ‘Medio’ Este tipo de problema debe ser resuelto; sin embargo, no resolverlo no impacta los niveles de servicio acordados. Un pequeño número de usuarios es afectado.

19. Impacto es una medida del grado en que se experimenta la degradación del servicio. Incluye factores como: Número de usuarios Alcance de la caída Tipo de servicio afectado Número de ocurrencias 1 = Alto impacto 2 = Impacto medio 3 = bajo impacto Severidad Se refiere a la velocidad de solución que se requiere. Incluye factores como: Disponibilidad de una solución temporal Duración de la caída Tiempo en que ha estado abierto el incidente 1 = Se requiere inmediatamente 2 = Se requiere en algunos días 3 = Se requiere en una semana o mas. Los valores de impacto y de severidad (o urgencia) contribuyen a establecer la prioridad de atención de un incidente o problema

20. La prioridad se calcula a partir de los valores de impacto y severidad Si el impacto es: Y la severidad es: La prioridadresultante es

21. Valores de Campos de los procesos de Administración de Incidentes y Administración de Problemas

22. Tipo de Incidente

23. Código de causa de incidentes y problemas

24. Código de cierre de un ticket de incidentes

25. Código de cierre de un ticket de problema

26. En el proceso de Administración de Incidentes

27. En el proceso de Administración de Problemas

28. Interacción entre los procesos

29. Detección y registro de Incidentes Esta actividad es el punto de entrada del proceso de Administración de Incidentes. Deben iniciar por esta actividad, todos los reportes de incidentes del área de TI reportados por usuarios. El propósito de esta actividad es el reconocimiento rápido y preciso de las fallas potenciales en el momento que ocurren para apoyar el diagnóstico y determinación del incidente y notificar a quien deba estar enterado. En esta actividad se obtiene la información que se necesita para crear el registro del incidente. La clave de esta actividad es la precisión y completitud de la información

30. Clasificación y soporte inicial El incidente puede ser una interrupción de servicio que se reporta, o bien una solicitud de cambio (RfC), un requerimiento de servicio o de información. Para un reporte de una interrupción de servicio, se deberá establecer la prioridad, impacto, severidad y categoría del incidente. En caso de que no se cuente con una solución disponible para restaurar el servicio, se asigna el incidente a el analista apropiado con el propósito de que haga su diagnóstico e investigación.

31. Investigación y Diagnostico Si la resolución inicial al incidente no es exitosa, se requerirá de un diagnóstico mayor con el objeto de hallar una manera de restaurar el servicio al usuario. En caso requerido, se involucrarán uno o mas analistas de incidentes. En el caso en que no se encuentre una manera de restaurar el servicio, puede involucrarse también al proceso de administración de Problemas.

32. Resolución y recuperación Si se requiere un RfC para resolver un problema, se involucra al proceso de Control de Cambios. En caso de que no sea requerido un RfC, la solución se comunica al cliente y se ejecuta. En caso de que la solución no lleve a una resolución adecuada, será requerido un diagnóstico mayor y en caso de que se requiera un análisis de causa raíz, se creará un registro de problema.

33. Cierre del incidente Si la resolución del incidente es adecuada o un problema asociado es resuelto, la solución es validada con el cliente. Si el cliente acepta la resolución, se cierra el incidente y se actualiza la base de datos de conocimiento en caso requerido. En caso de que el cliente no esté satisfecho con la solución, el incidente es escalado.

34. Monitoreo de Incidentes Este subproceso monitorea el ciclo de vida de todos los incidentes. El subproceso inicia cuando se abre un incidente y termina cuando un incidente se cierra.

35. Actividades del flujo de Administración de Incidentes • Detección y registro de incidentes • Clasificación y soporte inicial • Investigación y diagnóstico • Resolución y recuperación • Cierre de Incidentes • Monitoreo

36. Detección y Registro de Incidentes

37. Resumen • Entradas • Requerimiento de un usuario • Envío de incidente a través del proceso de administración de eventos • Información de un componente de configuración (configuration item o CI) • Actividades • 1.1 Identificar y validar la información del usuario • 1.2 Determinar si es un incidente nuevo o ya existe • 1.3 Identificar si se requiere actualizar información • 1.4 Validar la información del CI • 1.5 Reportar la información correcta del CI • Salidas • Registro del incidente que puede ser procesado en el subproceso de clasificación y soporte inicial • Reporte de corrección de información de un CI enviado al proceso de administración de configuraciones

38. Clasificación y soporte inicial

39. Resumen • Entradas • Registro de un incidente proveniente del sub proceso de detección y registro de incidente • Actividades • 2.1 Identificar el tipo de incidente • 2.2 Crear un RFC • 2.3 Atender un requerimiento de servicio • 2.4 Buscar y proveer información • 2.5 Establecer prioridad • 2.6 Crear un mensaje de alerta en la mesa de ayuda, si aplica • 2.7 Identificar los síntomas • 2.8 Buscar una solución definitiva o temporal y asignar el incidente • 2.9 Asignar/reasignar incidente • 2.10 Aceptar el incidente • 2.11 Reasignar el incidente al Queue manager y reclasificarlo si se requiere • Salidas • Incidente con solución definitiva o temporal que puede ser transferido al sub proceso de solución y recuperación • Incidente aceptado para ser transferido al subproceso de investigación y diagnóstico • Requerimiento de cambio (RFC) para ser transferido al proceso de control de cambios • Requerimiento de servicio para ser transferido al proceso de administración de servicios • Información requerida que pude ser proporcionada al usuario

40. Investigación y diagnóstico

41. Resumen • Entradas • Incidente asignado proveniente del sub proceso clasificación y soporte Inicial • Actividades • 3.1 Búsqueda de incidentes similares • 3.2 Asociar con incidente maestro • 3.3 Proveer estatus y número de incidentes • 3.4 Diagnóstico • 3.45 Identificar si requiere análisis de causa raíz • 3.5 Reasignación del incidente • 3.6 Aceptación del Incidente • 3.7 Reclasificación de incidente si se requiere • 3.8 Identificar ticket de problema vinculado con un incidente similar • 3.9 Creación de problema nuevo • 3.10 Asociar incidente a problema • Salidas • Diagnóstico de incidente con o sin solución temporal para ser transferida al sub proceso de solución y recuperación • Estatus y número de incidente proporcionado al usuario si el incidente fue asociado con un incidente maestro

42. Solución y recuperación

43. Resumen • Entradas • Solución de incidente en el sub proceso de clasificación y soporte inicial o en el sub proceso de investigación y diagnóstico • Cambio implementado • Servicio proveído • Incidente con una solución definitiva o temporal disponible identificada en el sub proceso de clasificación y soporte inicial • Actividades • 4.0 Registrar la solución al usuario • 4.1 Investigar si se requiere un RFC • 4.2 Crear un RFC para resolver un incidente • 4.3 Comunicar solución • 4.4 Ejecutar solución definitiva o temporal • 4.5 Validar solución de incidente • 4.6 Remover mensaje de alerta en la mesa de ayuda si aplica • Salidas • Requerimiento de cambio (RFC) • Solución comunicada al usuario • Solución exitosa o fallida del incidente • Incidente sin resolver para el sub proceso de investigación y diagnóstico • Incidente resuelto para el sub proceso cierre de incidente • Problema nuevo

44. Cierre del incidente

45. Resumen • Entradas • Requerimiento de información (RFI por sus siglas en inglés) • Incidente resuelto • Información de la solución al problema • Actividades • 5.1 Reclasificar si es necesario • 5.2 Validar la solución y solicitar el cierre • 5.3 Actualizar base de datos de conocimiento • 5.4 Cierre de incidente • Salidas • Incidente escalado • Cierre de incidente • Nominación de soluciones a la base de conocimiento

46. Flujo del proceso de Administración de Problemas

47. Detección y registro de problemas Esta actividad es el punto de inicio del proceso de Administración de Problemas Un nuevo problema se puede crear de dos maneras: 1.- Para los incidentes que no puedan ser asociados a un problema existente o que no puedan ser resueltos sin ejecutar un análisis a causa raíz se deberá generar un registro de problemas desde el proceso de Administración de Incidentes 2. Con base en el análisis de tendencias de incidentes, el proceso de Administración de problemas genera el registro de un nuevo Problema

48. Clasificación y asignación Para una óptima resolución de problemas, se asigna el problema al analista de problemas apropiado para su resolución. El analista obtiene la información disponible del problema con el propósito de determinar si es posible realizar el diagnóstico. En caso requerido, re puede realizar una reclasificación del problema

49. Investigación y diagnóstico En caso de que no sea posible asociar el problema existente con un error conocido, se realiza un análisis a nivel causa raíz. Cuando se encuentre la causa raíz, el problema se etiqueta como error conocido

50. Resolución En caso de que no sea posible encontrar la solución al problema, se creará una solución temporal en caso de ser posible. En el caso de que sea posible encontrar una solución, se generará una solicitud de cambio (RfC) y se pasará al proceso de Control de Cambios. El RfC se monitoreará para su aprobación y en caso de que el cambio sea implementado exitosamente, el problema estará listo para ser cerrado.