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.

Slides:



Advertisements
Presentaciones similares
ADMINISTRAR EL DESEMPEÑO Y LA CAPACIDAD
Advertisements

Que es ITIL? ITIL® (IT Infrastructure Library) es el marco de procesos de Gestión de Servicios de TI más aceptado. ITIL® proporciona un conjunto de mejores.
SISTEMAS DE GESTIÓN DE LA SEGURIDAD DE LA INFORMACIÓN
Gestión de Recursos Informáticos Unidad Nº 3: Gestión de calidad y eficiencia.
Aclaraciones de la Realización del Producto
¿Qué es ITIL? “Information Technology Infrastructure Library”
CHARLA SISTEMA DE GESTIÓN AMBIENTAL ISO-14000
Sistemas de Calidad / ISO 9001:2000
PROCESOS ITIL Entrega Soporte Usuario Cliente Gestión de niveles
PRODUCTO NO CONFORME.
Service Delivery & Service Support ITIL Information Technology Infrastructure Library Grupo H Consultic.
Medición, Análisis y Mejora
SOPORTE A USUARIOS HELP DESK
Capítulo 3 Etapas de un Proyecto de simulación
MESA 3 Evaluación, seguimiento y mejora, auditorias internas y Revisión por la dirección Requisitos P
Lineamientos de Pruebas Integrales del GRP Financiero
Electivo Integración Normas de Calidad, Seguridad, Medio Ambiente y Riesgos en la Gestión de la Empresa. Profesor : Fernando Vargas Gálvez Ingeniero Civil.
GESTION NIVELES DE SERVICIO.
Gung Ho! Gung Ho! Gestión de los Stakeholders
Requerimientos /Metas:
ADMINISTRACIÓN DE REQUERIMIENTOS
Fundamentos de la Gerencia de Proyectos
MAESTRÍA DE GERENCIA EN SISTEMA
Implementación, Control y Cierre Procesos de Control
Glosarios de términos. TI: Tecnologías de información. Es la adquisición, procesamiento, almacenamiento y difusión de información de voz, imagen, texto.
Definición de Procesos y Políticas. 2 Marco de Procesos.
Control de Cambios.
MESA DE AYUDA SIRH Pucón, Noviembre 2013.
AUDITORIAS RESUMEN DE ASPECTOS RELEVANTE EN LA GESTION BASADO EN EL REFERENCIAL ISO 9001:2008.
GESTION DEL CAMBIO Los presencia continua de competencia, la internacionalización económica y la aparición de nuevas tecnologías de información e informática.
Ciclo de vida de la administración de servicios de TI
Operación del Servicio Equipo 4. La Operación del Servicio es la 4ª Fase del ciclo de vida del Servicio y la debemos asociar con: Ofrecer un Servicio.
HELPDESK ONEOrZERO LOPEZ- MICHETTI -MUÑOZ.
Administración Proyectos Jorge Baracaldo Robin Ochoa.
Entrega de Servicios de TI1Copyright 2008 Tecnotrend SC Entrega de Servicios de TI.
Modulo 7: Gestión de la Calidad Tema 4: ISO20000
La excelencia en el Soporte Técnico IT
Plan de Sistemas de Información (PSI)
Aplicaciones de Ingeniería de Software
Areas de Proceso del Modelo CMMI-DEV
Diseño del servicio ITIL..
COBIT KARYL LARA N.. ENTREGA Y SOPORTE A este Dominio le concierne la entrega real de los servicios requeridos, que cubre desde las operaciones tradicionales.
Programa de Auditoría Interna
Único punto de contacto del usuario con TI.
SGSI: Sistemas de Gestión de la Seguridad de la Información
GESTIÓN DE INCIDENTES.
Ciclo de vida de un sistema
TIPOS DE AUDITORÍAS EN SISTEMAS DE INFORMACIÓN
Introducción al proceso de verificación y validación.
Administración Integral del Proyecto
Análisis y Diseño de Aplicaciones
...Auditorias de sistemas de administración bajo ISO 19011: "
Seminario de TS Teresa Zorrilla Partner Enablement Manager.
REVISION Y AUDITORIA.
ANGIE PAOLA SOLANO CASTIBLANCO DAR SOPORTE A LOS PROCESOS NORMAS ISO DOC. JOHANA LÓPEZ CHAVEZ SENA 2010.
Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar [ Rational ]. Un requerimiento de software puede.
Introducción a la Administración de Proyectos
Identificación de entradas, salidas y herramientas de procesos de gestión del PMI Jairo A. Orozco L.
Conozca como implementar ITIL en su organización Angélica Guzmán Incident Management Consultor de Soluciones.
LAR 145 Capítulo C.
INFORME SEMESTRAL DE DESEMPEÑO GERENCIA TECNOLOGIAS DE LA INFORMACION Pedro Espinoza Diaz Gerente TI Julio a Diciembre 2012 MUNICIPALIDAD DE SAN BORJA.
ESTÁNDAR ISO/IEC INTERNACIONAL 27001
Marco de Trabajo para Indexación, Clasificación y Recopilación Automática de Documentos Digitales Javier Caicedo Espinoza Gonzalo Parra Chico.
EI, Profesor Ramón Castro Liceaga IV. AREAS DE EVALUACIÓN DE LA AUDITORIA EN INFORMÁTICA. UNIVERSIDAD LATINA (UNILA)
Identificación de entradas, salidas y herramientas de procesos de gestión del PMI Jairo A. Orozco L.
Planificación de Sistemas de Información
Procesos de Planeación
Nombre del campus Componente profesional
Verificación y Validación del Software
Ing. Sanchez Castillo Eddye Arturo Escuela Académica Profesional de Ingeniería de Sistemas.
Transcripción de la presentación:

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

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

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

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

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

Roles y Responsabilidades dentro del proceso

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

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

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

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

Posibles estatus para incidentes y problemas

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.

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

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

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

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

Prioridad de Incidentes y Problemas

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.

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.

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

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

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

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

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

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

En el proceso de Administración de Incidentes

En el proceso de Administración de Problemas

Interacción entre los procesos

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

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.

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.

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.

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.

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.

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

Detección y Registro de Incidentes

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

Clasificación y soporte inicial

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

Investigación y diagnóstico

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 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

Solución y recuperación

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

Cierre del incidente

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

Flujo del proceso de Administración de Problemas

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

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

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

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.

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

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.

Detección y registro del problema

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

Clasificación y asignación

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

Investigación y diagnóstico

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

Resolución

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

Cierre del problema

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

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.

Poblar las bases de datos de conocimiento con errores conocidos

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

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

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

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.

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

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

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

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

Gracias por su participación