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.

Presentación del tema: "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."— Transcripción de la presentación:

1 Mesa de ayuda Administració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 Rol dentro del proceso de Administración de Incidentes Responsabilidades principales Dueño del proceso de Administración de Incidentes Patrocina el proceso de Administración de Incidentes. Tiene la responsabilidad y la autoridad sobre los resultados globales del proceso Incident manager Coordina diariamente la ejecución de las actividades del proceso de Administración de Incidentes Incident Queue Manager Coordina el trabajo realizado por los Agentes de incidentes o por los Analistas de Incidentes de su localidad. Analista de Incidentes Es el experto en la materia (subject matter expert) dentro de cierto dominio de competencia En la mayoría de las veces, esta en el 2nd nivel de soporte. Analiza los incidentes y sus soluciones con el propósito de restaurar el servicio rápidamente Agente de Incidentes Es la interface inicial hacia la comunidad de usuarios. Maneja los requerimientos de los usuarios desde su inicio hasta su solución

8 Roles dentro de la solución de procesos de Administración de Incidentes y Administración de Problemas Rol dentro del proceso de Administración de Problemas Responsabilidades principales Dueño del proceso de Administración de Problemas Patrocina el proceso de Administración de Problemas. Tiene la responsabilidad y la autoridad sobre los resultados globales del proceso Problem Manager Coordina diariamente la ejecución de las actividades del proceso de administración de Problemas. Se asegura que se resuelvan los problemas. Problem Queue Manager Coordina el trabajo de los analistas de problemas de su localidad o área. Analista de Problemas Ejecuta análisis profundo de los problemas con el objeto de encontrar la causa que originó un problema y desarrolla soluciones

9 Roles dentro de la solución de procesos de Administración de Incidentes y Administración de Problemas Rol dentro del proceso de Administración del Conocimiento Responsabilidades principales Administrador del Conocimiento Establece y mantiene las bases de datos de conocimiento utilizadas por los procesos de Administración de Incidentes y Administración de Problemas y se asegura de la calidad, integridad de la información contenidos en ella

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 Valor del Status Significado
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 Valor del Status Significado New (Open) El incidente es registrado Pending -Wait on INFO Un usuario ha hecho un requerimiento de información enviado que no puede ser resuelto inmediatamente por el agente de incidentes. Pending - Wait on RFC Un usuario ha solicitado un requerimiento de Cambio (RfC). El incidente es registrado y un RfC se crea. El proceso de Control de cambios manejará la solicitud de cambio. Pending - Wait on SOL El incidente no puede ser resuelto sin tener que analizar la causa raíz. El proceso de Administración de problemas ha sido notificado. Pending - Wait on RFS Un usuario ha solicitado un servicio. El requerimiento es investigado y en caso de que pueda ser satisfecho, entonces se registra creando un requerimiento de servicio. La función de Administración de servicio maneja la atención.

13 Valor del Status Significado
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 Valor del Status Significado Assigned El incidente se ha clasificado y ha sido asignado Work in Progress El incidente ha sido aceptado y se esta trabajando en el. Resolved Una solución definitiva o temporal se ha establecido para corregir el incidente. Se esta en el proceso de contactar al usuario que lo originó con el objeto de verificar la efectividad de solución temporal o definitiva Closed La solución ha sido verificada y el incidente es cerrado

14 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 A D M I N S T R C Ó P R O B L E M A O T R O S P R O C E S O S Administración de incidentes

15 Valor del estatus Significado
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 Valor del estatus Significado New El problema esta siendo registrado Assigned El problema ha sido clasificado y ha sido asignado Work in Progress El problema ha sido aceptado y se esta trabajando en su solución. Pending - Wait on RFC Se requiere de una solicitud de cambio con el objeto de implementar una solución al problema registrado Resolved Se ha establecido una solución definitiva o temporal para un problema Closed La solución ha sido implementada y el problema se ha cerrado Cancelled En caso de que un RfC haya sido rechazado por el proceso de Control de Cambios, el problema se ha marcado como cancelado

16 Los valores de estatus cambian en función del avance de la solución del problema y se utilizan para dar seguimiento al avance C O N T R O L D E C A M B I O S Problem Management

17 Prioridad de Incidentes y Problemas

18 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 priority Description Prioridad Descripción 1 ‘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. 2 ‘Alto’ Un sistema o aplicación se puede utilizar pero con restricciones grandes. El rendimiento esta severamente degradado. 3 ‘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. 4 ‘Bajo’ Este problema no afecta directamente la productividad del usuario y por lo general esta confinado a un solo usuario.

19 Los valores de impacto y de severidad (o urgencia) contribuyen a establecer la prioridad de atención de un incidente o problema 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.

20 La prioridad se calcula a partir de los valores de impacto y severidad
Si el impacto es: Y la severidad es: Alto Medio Bajo 1 2 3 4 La prioridad resultante es

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

22 Tipo de Incidente Data Field Name Description
Incident Type (Incident Ticket) type of ticket being created Defined Values Incident Request for Change Request for Information Request for Service

23 Código de causa de incidentes y problemas
Nombre del campo Descripción Cause Code Causa raíz Valores definidos APPL – Errores de programas aplicativos USER ERROR – El incidente fue causado por un uso inapropiado CFG – Incidente causado por un error en la configuración CHGS –Incidente causado por cambios programados que no se consideraron CHGU - Incidente causado por cambios no programados que se tuvieron que hacer CND – No se pudo duplicar el error que originó el incidente DOCUMENT - Incidente causado por un error en la documentación EDCU - Incidente causado por entrenamiento insuficiente HARDWARE - Incidente causado por errores o problemas de hardware NETWORK - Incidente relacionado con la conectividad con la red NTF – No se encontró razón para iniciar este incidente. No se detectó dificultad o problema PSWD - Incidente causado por cualquier situación relacionada con password RESOLVED - Incidente fue resuelto por el usuario RESOURCE - Incidente causado debido a un problema de recursos SOFTWARE - Incidente causado por errores o problemas con el Software

24 Código de cierre de un ticket de incidentes
Nombre del campo Descripción Closure Code (Incident Ticket) Razón para cerrar el Ticket Valores definidos Successful: Successful with problems Unsuccessful Automatically closed Canceled No supported

25 Código de cierre de un ticket de problema
Nombre del campo Descripción Close Code (Problem Ticket) Razón para cerrar el ticket Valores definidos Replaced: Se reemplazó un componente de TI (CI) para resolver el problema Fixed: Un componente de TI (CI) se arregló para resolver el problema Previous Fix: Un problema fue resuelto por una corrección previa Cancelled: El problema fue cancelado antes de su solución regular Invalid: El problema fue creado por error

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 Actividades Salidas 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 Actividades Salidas
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 Actividades Salidas
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 Identificar ticket de problema vinculado con un incidente similar 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 Actividades Salidas
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 Actividades Salidas
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.

51 Cierre de problema Una vez que el cambio ha sido implementado exitosamente, se realiza la validación de que el problema haya sido finalmente resuelto. En caso de que la solución sea adecuada, se actualizará la base de datos de conocimiento y se cerrará el problema. Si no es adecuada, la investigación y diagnóstico deberá ser realizada nuevamente

52 Monitoreo de Problemas
Esta actividad monitorea el ciclo de vida de los problemas. La actividad inicia cuando se abre un problema y termina cuando se cierra.

53 Detección y registro del problema

54 Resumen Entradas Actividades Salidas
Problemas creados por el proceso de administración de incidentes Problemas creados por el proceso de administración de problemas a través del análisis de tendencias Actividades 1.1 Revisar incidentes 1.2 Analizar tendencias de incidentes 1.3 Crear un problema nuevo 1.4 Establecer severidad Salidas Problema registrado y clasificado

55 Clasificación y asignación

56 Resumen Entradas Actividades Salidas
Problemas desde el sub proceso de detección y registro Problemas desde el subproceso de investigación y diagnóstico Actividades 2.1 Asignar el problema 2.2 Aceptar el problema 2.3 Reclasificar el problema en caso requerido 2.4 Conjuntar la información del problema 2.5 Obtener información en caso requerido 2.6 Validar la información disponible del problema 2.7 Solicitar el cierre del problema en caso requerido Salidas Problema hacia el subproceso de investigación y diagnóstico

57 Investigación y diagnóstico

58 Resumen Entradas Actividades Salidas
Problemas desde el subproceso de clasificación y diagnóstico Actividades 3.1 Investigar el problema 3.2 Relacionar/Asociar con un error conocido 3.3 Diagnosticar el problema 3.4 Identificar la causa raíz 3.5 Documentar la causa raíz 3.6 Etiquetar el problema como error conocido 3.7 Notificar al proceso de administración de incidentes Salidas Error conocido Problema a resolver

59 Resolución

60 Resumen Entradas Actividades Salidas
Problema desde el sub proceso de investigación y diagnóstico Error conocido Actividades 4.1 Investigar la factibilidad de la solución 4.2 Creación de solución temporal o “workaround” 4.3 Revisión con el cliente 4.4 Documentar la solución temporal o el “workaround” 4.5 Crear la solución 4.6 Documentar a solución 4.7 Crear el RFC 4.8 Monitorear el RFC 4.9 Escalar el problema Salidas Requerimiento al proceso de control de cambios de un RFC Problema escalado a monitoreo de problema Registro de problema (ticket) para su cierre

61 Cierre del problema

62 Resumen Entradas Actividades Salidas
Problema resuelto desde el sub proceso de solución Actividades 5.1 Validar solución 5.2 Actualizar la base de datos de conocimiento en caso de ser requerido 5.3 Cerrar el problema Salidas Problema cerrado Notificar a administración de incidentes Nominar para la base de datos de conocimiento

63 Poblado de la Base de Datos de Conocimiento
Esta actividad revisa los registros de incidentes y problemas cerrados que han sido marcados como candidatos y determina cuales deben ser puestos a disposición de los procesos de análisis de problemas e incidentes.

64 Poblar las bases de datos de conocimiento con errores conocidos

65 Resumen Entradas Actividades Salidas
Marcar soluciones de incidentes y problemas para su inclusión a la base de datos de conocimiento Actividades Revisar candidatos Buscar réplicas en la base de datos de conocimiento Validar si existe o es nueva Crear o actualizar Salidas Problema cerrado Notificar a administración de incidentes Nominar para la base de datos de conocimiento

66 Escenarios UN ALUMNO DE CAMPUS CEM, REPORTA AL HELP DESK UN INCIDENTE INDICANDO QUE NO APARECE EL CURSO EN EL QUE ESTA INSCRITO UN PROFESOR DE CAMPUS CEM, REPORTA AL HELP DESK UN INCIDENTE INDICANDO QUE NO SE GUARDAN LOS CAMBIOS DE CONFIGURACIÓN QUE HA HECHO AL CURSO CON EL QUE ESTA TRABAJANDO UN ALUMNO DE CAMPUS CEM, REPORTA AL HELP DESK UN INCIDENTE INDICANDO QUE NO SE PUEDEN ABRIR LOS ARCHIVOS DE MICROSOFT OFFICE QUE VIENEN ANEXOS (ATTACHED) AL CURSO DE BLACKBOARD UN PROFESOR DE CAMPUS CEM, REPORTA QUE NO PUEDE ENTRAR A LOS SISTEMAS DE CORREO O DE BLACKBOARD (EN REALIDAD NO PUEDE ENTRAR A NINGÚN SISTEMA CORPORATIVO) EL ALUMNO LLAMA PARA REPORTAR QUE EL DESPLIEGUE DE LA PANTALLA ESTÁ ILEGIBLE EN LA APLICACIÓN DE BECAS EL PROFESOR LLAMA PARA REPORTAR QUE SU EQUIPO LAPTOP NO FUNCIONA EL EMPLEADO LLAMA PARA REPORTAR QUE NO PUEDE ACCEDER A SU BUZÓN DE CORREO PUES SE QUEDA COLGADA LA SESIÓN

67 Administración de Incidentes y Administración de Problemas Escenarios

68 En general, existen tres escenarios que representan la mayoría de los incidentes y problemas
Escenario 1: Existe una solución conocida o una solución temporal al incidente reportado. Escenario 2: No existe una solución conocida o una solución temporal para el incidente, pero se puede desarrollar una solución sin tener que realizar un análisis de causa raíz. Escenario 3: No hay una solución conocida o solución temporal para el incidente y se requiere realizar un análisis de causa raíz Para cada uno de los escenarios, se seguirán los flujos de los procesos en las siguientes láminas.

69 Escenario 1: Un usuario llama a la mesa de ayuda con un problema para el cual existe una solución conocida Detección y registro Identificar al usuario Determinar si es un nuevo requerimiento para abrir un ticket Validar la información del usuario (actualizar su perfil en caso requerido) Identificar el activo Clasificación y soporte inicial Establecer la prioridad, el impacto y la categoría Identificar y documentar los síntomas Identificar una solución o solución temporal. (en nuestro ejemplo se encuentra una solución) Resolución y recuperación Si se requiere un requerimiento de cambio, se genera en el proceso de Control de Cambios En caso contrario, se pide al cliente ejecutar la solución Verificar que la solución haya funcionado Cierre del incidente Verificar con el usuario que el problema haya sido resuelto antes de proceder a cerrar el Ticket Cerrar el ticket con los códigos apropiados

70 Escenario 2: en este caso, no existe una solución definitiva, pero se tiene una solución temporal que no requiere del análisis de la causa raíz Identificar al Usuario Determinar si es un nuevo requerimiento y abrir ticket Validar la información del cliente (Actualizar perfil en caso requerido) Identificar el activo Detección y registro Establecer la prioridad, impacto, severidad y categoría Identificar y documentar los síntomas Identificar una solución o solución temporal. (en este ejemplo, no hay solución Asignar el incidente para posterior análisis Clasificación y soporte inicial Investigación y diagnóstico Búsqueda por síntomas similares. Diagnóstico y determinación de la factibilidad de una solución temporal Resolución y recuperación ejecutar la solución temporal (utilizando el proceso de control de cambios en caso requerido Validar que la solución temporal sea exitosa Verificar que hayan sido resueltos los problemas con el usuario y solicitar su acuerdo para cerrar el ticket Determinar si alguna acción debe ser iniciada en relación a la base de datos de conocimiento Cerrar el ticket con los códigos apropiados Cierre del incidente

71 Escenario 3: En este caso, no existen síntomas similares o soluciones temporales y requiere de hacer análisis de causa raíz Identificar al usuario Determinar si es un requerimiento nuevo y abrir un ticket Validar la información del usuario (Actualizarla en caso necesario) Identificar al activo Detección y Registro Clasificación y soporte inicial Establecer la prioridad, impacto, severidad y categoría Identificar y documentar síntomas Buscar una solución conocida o una solución temporal (No se encuentra ninguna) Asignar para un análisis mas profundo Investigación y diagnóstico Búsqueda de síntomas similares – (en este caso no se encuentran) Búsqueda de una solución temporal – (En este caso no se encuentran) Identificar la necesidad de hacer un análisis de causa raíz Crear un nuevo registro de problema Detección y registro Establecer la prioridad, impacto, severidad y categoría Siguiente

72 Escenario 3 - continuación
El problema se asigna al analista de problemas correspondiente Se obtiene datos del problema Se obtiene otra información que pueda ayudar en el diagnóstico el problema Clasificación y Asignación Investigación y diagnóstico Comparara contra errores conocidos Determinar y documentar la causa raíz Identificar como un error conocido En caso de que sea posible una solución, crearla En caso de que no sea posible crear una solución, crear una temporal Crear un requerimiento de cambio RfC y ejecutar el proceso de Control de Cambios para implementarlo Resolución Validar la resolución implantada por el proceso de Control de Cambios Identificar si la solución es un candidato para el repositorio de la base de datos de conocimiento Cerrar el ticket de problema con los códigos apropiados Cierre del problema Verificar que el problema del usuario haya sido resuelto y pedir su acuerdo para cerrar el ticket Determinar si debe ser iniciada alguna acción relacionada con la base de datos de conocimiento Cerrar el ticket con los códigos apropiados Cierre del incidente

73 Gracias por su participación