CA Nimsoft Service Desk. Guía del analista

Transcripción

1 CA Nimsoft Service Desk Guía del analista Otoño 2013

2 Esta documentación, que incluye sistemas incrustados de ayuda y materiales distribuidos por medios electrónicos (en adelante, referidos como la "Documentación") se proporciona con el único propósito de informar al usuario final, pudiendo CA proceder a su modificación o retirada en cualquier momento. Esta documentación es propiedad de CA. Queda prohibida la copia, transferencia, reproducción, divulgación, modificación o duplicación de la totalidad o parte de esta Documentación sin el consentimiento previo y por escrito de CA. No obstante lo anterior, si dispone de licencias de los productos informáticos a los que se hace referencia en la Documentación, Vd. puede imprimir, o procurar de alguna otra forma, un número razonable de copias de la Documentación, que serán exclusivamente para uso interno de Vd. y de sus empleados, y cuyo uso deberá guardar relación con dichos productos. En cualquier caso, en dichas copias deberán figurar los avisos e inscripciones relativas a los derechos de autor de CA. Este derecho a realizar copias de la Documentación sólo tendrá validez durante el período en que la licencia aplicable para el software en cuestión esté en vigor. En caso de terminarse la licencia por cualquier razón, Vd. es el responsable de certificar por escrito a CA que todas las copias, totales o parciales, de la Documentación, han sido devueltas a CA o, en su caso, destruidas. EN LA MEDIDA EN QUE LA LEY APLICABLE LO PERMITA, CA PROPORCIONA ESTA DOCUMENTACIÓN "TAL CUAL" SIN GARANTÍA DE NINGÚN TIPO INCLUIDAS, ENTRE OTRAS PERO SIN LIMITARSE A ELLAS, LAS GARANTÍAS IMPLÍCITAS DE COMERCIALIZACIÓN, ADECUACIÓN A UN FIN CONCRETO Y NO INCUMPLIMIENTO. CA NO RESPONDERÁ EN NINGÚN CASO, ANTE VD. NI ANTE TERCEROS, EN LOS SUPUESTOS DE DEMANDAS POR PÉRDIDAS O DAÑOS, DIRECTOS O INDIRECTOS, QUE SE DERIVEN DEL USO DE ESTA DOCUMENTACIÓN INCLUYENDO A TÍTULO ENUNCIATIVO PERO SIN LIMITARSE A ELLO, LA PÉRDIDA DE BENEFICIOS Y DE INVERSIONES, LA INTERRUPCIÓN DE LA ACTIVIDAD EMPRESARIAL, LA PÉRDIDA DEL FONDO DE COMERCIO O LA PÉRDIDA DE DATOS, INCLUSO CUANDO CA HUBIERA PODIDO SER ADVERTIDA CON ANTELACIÓN Y EXPRESAMENTE DE LA POSIBILIDAD DE DICHAS PÉRDIDAS O DAÑOS. El uso de cualquier producto informático al que se haga referencia en la Documentación se regirá por el acuerdo de licencia aplicable. Los términos de este aviso no modifican, en modo alguno, dicho acuerdo de licencia. CA es el fabricante de esta Documentación. Esta Documentación presenta "Derechos Restringidos". El uso, la duplicación o la divulgación por parte del gobierno de los Estados Unidos está sujeta a las restricciones establecidas en las secciones , y (c)(1) - (2) de FAR y en la sección (b)(3) de DFARS, según corresponda, o en posteriores. Copyright 2013 CA. Todos los derechos reservados. Todas las marcas registradas, nombres comerciales, logotipos y marcas de servicios a los que se hace referencia en este documento pertenecen a sus respectivas empresas.

3 Información de contacto del servicio de Soporte técnico Para obtener soporte técnico en línea, una lista completa de direcciones y el horario de servicio principal, acceda a la sección de Soporte técnico en la dirección

4

5 Contenido Capítulo 1: Introducción 9 Acerca de CA Nimsoft Service Desk... 9 Descripción general Funciones principales Consideraciones generales Capítulo 2: Tratamiento del ticket y conceptos relacionados 15 Proceso de gestión de tickets Ticket y ciclo de vida del ticket Tipos de ticket Enrutamientos automáticos para acciones de workflow Tipos de cambios y aprobación de cambio Elementos de configuración y servicios afectados Relaciones del ticket Monitorización de conformidad del SLA Artículos de conocimiento y base de conocimiento Roles y grupos de soporte Organización y seguridad basada en la organización Capítulo 3: Detalles del espacio de trabajo 35 Descripción general Botón de acción y tipo de acciones Espacios de trabajo para analistas Espacio de trabajo Mis tickets Espacio de trabajo Catálogo de solicitudes Espacio de trabajo Elementos pendientes Espacio de trabajo Gestión del conocimiento Espacio de trabajo Gestión de la configuración Búsqueda de Service Desk Espacio de trabajo del bloc de notas Mi foro SD7ANAG--Change Calendar Acciones presentes en todos los espacios de trabajo Establecimiento como página principal Impresión de un espacio de trabajo Filtrado de listas Contenido 5

6 Las listas se ven en la vista de cuadrícula o de lista Capítulo 4: Gestión de tickets 59 Descripción general Detalles del ticket Registro de un ticket Registro de tickets mediante el catálogo de solicitudes Registro de tickets mediante la opción Crear una solicitud Aplicación de la plantilla del ticket cuando se crea un nuevo ticket Registro de tickets por correo electrónico Registro de un ticket desde una ventana de conversación Registro de un ticket desde el bloc de notas Consulta y gestión de las colas de tickets Filtrado de listas de tickets Visualización de los detalles de los tickets Adición de registros de trabajo en línea Realización de acciones masivas en los tickets Envío de comunicaciones de correo electrónico desde el ticket Envío de correo electrónico desde un ticket Planificación de un correo electrónico para que se envíe en una fecha y hora futuras Adición de un registro de ticket y su envío como correo electrónico Aplicación de una acción o actualización en un ticket Aplicación de una acción de workflow en un ticket Actualización de los detalles de un ticket, su descripción y la información adicional Visualización de detalles de las actividades del ticket Cómo ver las notificaciones de los acuerdos de nivel de servicio y responder a ellas Gestión de relaciones del ticket Cómo relacionar tickets o anular sus relaciones Creación de un ticket hijo para un ticket padre Creación de tickets de la tarea Marcado de un ticket como global o como relacionado con otro ticket global Relación de elementos de configuración con un ticket Consulta de los elementos de configuración relacionados y el gráfico de relaciones entre ellos Adición de detalles de solución de ticket Búsqueda en la base de conocimiento para encontrar una solución Uso de soluciones procedentes de tickets resueltos recientemente Envío de una solución de ticket como un artículo de conocimiento Envío de un ticket mediante el proceso de aprobación Enviar un ticket para aprobación Adición de contactos o grupos como aprobadores o revisores Creación de contactos como solicitantes o beneficiarios Guía del analista

7 Capítulo 5: Aprobación o revisión de tickets y envío de comentarios sobre el servicio 117 Aprobación o rechazo de un ticket Envío de comentarios de revisión Envío de comentarios sobre el servicio Capítulo 6: Gestión del conocimiento 121 Descripción general Detalles del artículo de conocimiento Creación y gestión de artículos de conocimiento Gestión de categorías de artículo de KB Creación y gestión de artículos de conocimiento Modificación de los artículos y gestión de las relaciones Configuración del estado del artículo de conocimiento como Aprobado Gestión de permisos para los artículos de conocimiento Configuración del estatus del artículo de conocimiento como Inactivo Creación y gestión de anuncios Capítulo 7: Gestión de la configuración 141 Descripción general Detalles del elemento de configuración Proceso de gestión de la configuración Creación de un registro de elemento de configuración nuevo mediante Crear nuevo Acción Copiar a Nuevo desde un elemento de configuración existente Gestión de los elementos de configuración relacionados Gestión de los grupos o contactos relacionados Gestión de los horarios de servicio Utilice Elementos de configuración en el tratamiento del ticket Relación de elementos de configuración con un ticket Consulta de los elementos de configuración relacionados y el gráfico de relaciones entre ellos Capítulo 8: Gestión de informes y cuadros de mandos 159 Descripción general Generación de informes estándares Informe estándar de planificación Modificación de los parámetros del informe y planificación de un informe estándar Configuración de un informe adhoc Acciones en los informes adhoc: Suprimir, Editar y Copiar a Nuevo Programación de informes Contenido 7

8 Modificación de la planificación de un informe adhoc Visualización y gestión de cuadros de mandos Capítulo 9: Gestión de los valores de configuración personales 177 Gestión del perfil de usuario Establecimiento de las preferencias de configuración regional Gestión del indicador Fuera de la oficina Guía del analista

9 Capítulo 1: Introducción En esta sección se proporciona una breve introducción a CA Nimsoft Service Desk, sus funciones clave e información sobre cómo pueden usar los analistas los diversos espacios de trabajo para gestionar las solicitudes de servicios de TI y soporte que realizan los usuarios finales. Se pueden revisar también las consideraciones generales y algunas limitaciones como el uso de caracteres especiales u otros factores que podrían impactar en la funcionalidad de la aplicación. Esta sección contiene los siguientes temas: Acerca de CA Nimsoft Service Desk (en la página 9) Descripción general (en la página 10) Funciones principales (en la página 11) Consideraciones generales (en la página 14) Acerca de CA Nimsoft Service Desk CA Nimsoft Service Desk es una aplicación de Service Desk que está disponible como parte de la oferta de CA IT Management SaaS y se puede acceder como parte de CA IT MaaS Portal. Se puede utilizar para gestionar la entrega de servicios y soporte de TI. Basada en principios de ITSM, CA Nimsoft Service Desk proporciona una plataforma integrada a los usuarios finales de soporte y servicios de TI para que lleguen a los equipos de provisión de servicios de TI con solicitudes de información o acceso a nuevos sistemas o servicios, o para informar de problemas con los sistemas o servicios existentes. El progreso de una solicitud se puede gestionar configurando acciones del workflow que guían la solicitud a través de un proceso de workflow predefinido. El diseño del workflow se puede configurar para gestionar distintos tipos de solicitudes categorizadas como Solicitud de servicio, Incidente, Problema y Cambio. Los procesos de workflow, los permisos para acceder a las diferentes funciones y registros de la aplicación se gestionan mediante el administrador de aplicaciones. Capítulo 1: Introducción 9

10 Descripción general Los usuarios pueden acceder a espacios de trabajo diferentes, en función de su rol dentro del servicio de soporte de TI. Los usuarios pueden acceder también a varias funciones de colaboración social, como un Foro en el que publicar y ver comentarios, seguir a otros usuarios y objetos (o dejar de seguirlos) y tener una conversación con otros usuarios de la organización mediante la herramienta Conversación. Para obtener más información sobre las funciones de colaboración, consulte la Ayuda de colaboración. Descripción general Las organizaciones utilizan las Tecnologías de la información para aumentar su productividad y eficacia. Para ello, los sistemas de TI y los servicios en la organización tienen que estar disponibles para los usuarios en todo momento y especialmente en el momento en que los usuarios necesitan estos servicios. Los equipos de soporte y servicios de TI tratan con una serie de servicios organizados que proporcionan soporte y ayuda a los usuarios de los sistemas y servicios de TI. Esto incluye la ayuda a los usuarios proporcionando información acerca de un producto y aplicación o servicio, proporcionando acceso a sistemas y servicios críticos y resolviendo algunas incidencias a las cuales se enfrentan los usuarios mientras utilizan los recursos de TI disponibles. También cubre las actividades relacionadas con actualizaciones y cambios realizados en la infraestructura y los servicios de TI que utiliza el cliente. El equipo de soporte de TI trabaja para garantizar que se responda a todas las solicitudes de soporte de TI según los procesos definidos y con un impacto mínimo al usuario. CA Nimsoft Service Desk es una herramienta que ayuda a los equipos de soporte de TI a utilizar procesos optimizados automatizados para garantizar que se cumplen las solicitudes de soporte y servicios de TI de los usuarios finales eficazmente y dentro de los límites de tiempo definidos. Para los analistas y aquellos involucrados en los equipos de provisión de servicios de TI; CA Nimsoft Service Desk proporciona una herramienta simple para consultar las solicitudes de los usuarios finales, determinar la acción necesaria en una solicitud y procesarla adecuadamente mediante una acción de workflow disponible. Los analistas pueden monitorizar la cola de tickets, consultar la prioridad de un ticket en su cola y planificar sus actividades en consecuencia. También pueden acceder a la base de conocimiento para consultar las soluciones a incidencias que ocurren frecuentemente así como utilizarla para resolver una incidencia abierta. 10 Guía del analista

11 Funciones principales Funciones principales Hay una serie de funciones que están disponibles para usuarios analistas que desempeñan la función de registrar, monitorizar y ofrecer soporte de TI. Algunas de las funciones clave disponibles para los analistas son: Envío de tickets por correo electrónico: Los correos electrónicos enviados al ID del correo electrónico de soporte darán lugar a la creación automática de tickets. Cualquier archivo adjunto del correo electrónico se relacionará como archivo adjunto al ticket. Obtención de actualizaciones sobre los tickets mediante correo electrónico: Se pueden enviar notificaciones de correo electrónico directamente desde el ticket cuando se realiza una acción automática o manual en el ticket. El analista que trabaja en el ticket puede elegir enviar notificaciones de correo electrónico manuales desde el ticket o puede enviar registros de trabajo como correos electrónicos para proporcionar actualizaciones del progreso del ticket. Actualización de ticket por correo electrónico: Las respuestas del correo electrónico a notificaciones del ticket están relacionadas automáticamente con el ticket y se añaden a la actividad del ticket. Los aprobadores de cambios pueden aprobar o rechazar un ticket respondiendo a la notificación de aprobación y actualizar el ticket con el estado de la aprobación. Solicitud de elementos mediante el catálogo de solicitudes: El catálogo de solicitudes muestra elementos de catálogo que se pueden usar para enviar tickets nuevos, incluido el registro de incidentes, problemas y cambios. El catálogo de solicitudes podría incluir también elementos de catálogo que se utilizan para enviar solicitudes de cumplimiento. El catálogo de solicitudes se puede usar para identificar y enviar rápidamente un ticket nuevo. Los elementos del catálogo de solicitudes establecen los valores de los campos esenciales, como la fuente, la prioridad, el tipo de cambio, etc., que conforman la base del enrutamiento automático que se aplica al enviar un ticket nuevo. Nota: Se recomienda utilizar el catálogo de solicitudes para enviar tickets nuevos, ya que los tickets nuevos que se registren usando una plantilla del catálogo de solicitudes se asignarán a los grupos de soporte adecuados y a las acciones oportunas. Consulta de los elementos pendientes: El panel Mis elementos pendientes en el espacio de trabajo Mis tickets muestra hasta tres elementos a la espera de una acción del usuario que ha iniciado sesión. Esto incluye tickets pendientes de aprobación o revisión y encuestas de comentarios sobre el servicio con una respuesta pendiente. Los usuarios pueden consultar como convenga las tareas pendientes y actuar sobre ellas. El espacio de trabajo Mis elementos pendientes también muestra tickets pendientes de aprobación o revisión y cualquier encuesta de evaluación sobre el servicio que esté pendiente. Capítulo 1: Introducción 11

12 Funciones principales Filtro de listas de tickets: Se pueden filtrar listas de tickets para mostrar solamente los tipos de tickets seleccionados, facilitando de esta forma la gestión de las colas de tickets. Se pueden guardar las preferencias de filtro y, tras iniciar sesión en el futuro, solamente se mostrará la lista filtrada. Llevar a cabo acciones masivas en los tickets: Se pueden seleccionar varios tickets de la lista y se puede aplicar una acción previamente seleccionada a todos los tickets seleccionados. Esto activará una acción rápida en varios tickets que requieran la misma acción. Edición de tickets en línea: Un ticket se puede editar dentro de la lista de tickets sin abrir el ticket en una nueva ficha o ventana. Los analistas pueden optar por abrir un ticket en una ficha nueva o en una ventana nueva, o aplicar una acción masiva en el ticket sin abrirlo. Los analistas pueden agregar también un registro de trabajo a un ticket dentro de la lista de tickets y ver la información del registro de trabajo antiguo para determinar la acción que hay que aplicar al ticket sin tener repasar el ticket en detalle. Consulta de artículos de conocimiento: Se puede poner a disposición de los analistas una base de conocimiento con artículos de conocimiento con procedimientos para resolver incidentes habituales, instrucciones para configurar sistemas y servicios, etc. El hecho de proporcionar artículos de conocimiento sobre incidencias frecuentes y procedimientos rutinarios dentro de la aplicación reduce la necesidad de que los analistas accedan a sistemas diferentes para obtener estas instrucciones rutinarias y, en consecuencia, se mejora la eficacia de los equipos de soporte. Puntuación de artículos de conocimiento: Los usuarios pueden puntuar un conocimiento y proporcionar comentarios sobre su uso, claridad y capacidad para resolver una pregunta, etc. Otros usuarios pueden utilizar esta puntuación para evaluar la utilidad de un artículo de conocimiento. Los equipos de soporte pueden utilizar también estos comentarios para mejorar la calidad de los artículos de conocimiento puestos a disposición de los usuarios. Creación de artículos de conocimiento: Los analistas, en función de los permisos que tengan asignados, pueden enviar artículos de conocimiento. Los usuarios que estén designados como administradores de la base de conocimiento pueden aprobar estos artículos y ponerlos disponibles en la base de conocimiento. Visualización de anuncios: Los usuarios pueden ver anuncios relacionados con cualquier noticia o información acerca de interrupciones conocidas que publica el administrador. Los usuarios pueden utilizarlos para planificar en consecuencia su uso de las TI. 12 Guía del analista

13 Funciones principales Búsqueda de elementos mediante la Búsqueda de Service Desk: Los usuarios pueden buscar tickets, artículos de conocimiento, etc. en el espacio de trabajo Búsqueda de Service Desk. Tras realizar una búsqueda consolidada en los diferentes registros de la aplicación se mostrarán todos los registros a los que tenga acceso el usuario que haya iniciado sesión y que coincidan con los criterios de búsqueda. Los usuarios pueden elegir si desean hacer una búsqueda general en todos los registros o bien limitar la búsqueda mediante los filtros disponibles. Configuración de las preferencias de configuración regional: Los usuarios pueden establecer sus preferencias de configuración regional para consultar la IU en el idioma deseado de la lista de configuraciones regionales admitidas disponibles. Una vez establecida, la IU se mostrará siempre en el idioma seleccionado hasta que se vuelvan a modificar las preferencias. Los usuarios también podrán consultar directamente los documentos de ayuda en el idioma de la configuración regional. Configuración del indicador de fuera de oficina y designación de un adjunto: Los usuarios pueden establecer un indicador que especifique que están fuera de la oficina y designar un ayudante para que actúe en su nombre. Todas las notificaciones de correo electrónico relacionadas con los tickets se dirigirán al adjunto durante el tiempo que se establezca el indicador de fuera de oficina. Generación de informes: Los usuarios finales pueden consultar o extraer un intervalo de informes relacionados con el ticket que el administrador ha puesto a su disposición. Los analistas también pueden configurar sus propios informes seleccionando parámetros de generación de informes para sus informes adhoc. También se pueden planificar informes para que se ejecuten según una planificación definida y que se envíen por correo electrónico a determinados destinatarios. Capítulo 1: Introducción 13

14 Consideraciones generales Consideraciones generales En esta sección se proporciona información acerca de las consideraciones especiales y las limitaciones conocidas relacionadas con el uso de la aplicación. Es posible que la funcionalidad no sea la prevista si no se cumplen las condiciones aquí especificadas. Límite de caracteres en correos electrónicos enviados para registrar un ticket o una respuesta a una notificación a partir de un ticket: Los correos electrónicos enviados al ID de soporte deben cumplir los siguientes límites de caracteres: 1. Los campos Para, CC, CCO y Asunto del correo electrónico enviado no deben superar los 512 caracteres. Si se supera este valor, la creación del ticket o su actualización podrían tener resultados inesperados. 2. El cuerpo del mensaje del correo electrónico no debe superar los 4000 caracteres. Si se supera, cuerpo del mensaje se truncará y se mostrarán solamente 4000 caracteres. Importante: Este límite podría ser inferior para idiomas como el japonés, que utiliza caracteres Unicode. Respuesta por correo electrónico a las notificaciones: Para responder a notificaciones por correo electrónico desde un ticket para actualizar el ticket existente, todas las respuestas deben cumplir las condiciones siguientes: 1. La línea del Asunto debe comenzar con Re:, RE: o FW: 2. La línea del Asunto debe contener el ID del ticket, por ejemplo, SRQ: Limitación relacionada con la búsqueda: Importante: Cuando una búsqueda contiene paréntesis de apertura y de cierre ( ), el sistema muestra un error. Para evitarlo, no se debe utilizar la combinación de paréntesis de apertura y cierre en los parámetros de búsqueda. 14 Guía del analista

15 Capítulo 2: Tratamiento del ticket y conceptos relacionados Los analistas trabajan extensamente con tickets y, además de trabajar en un servicio solicitado, adoptan medidas en un ticket como reclasificarlo en función de la naturaleza de la solicitud, determinando el progreso de la solicitud y actualizando detalles de la solución al ticket, etc. Los analistas, por tanto, deben tener una comprensión general de los conceptos de gestión del ticket. Esta sección proporciona conceptos de alto nivel relacionados con el tratamiento del ticket que serán útil a los analistas que trabajan con CA Nimsoft Service Desk. Esta sección contiene los siguientes temas: Proceso de gestión de tickets (en la página 15) Ticket y ciclo de vida del ticket (en la página 19) Tipos de ticket (en la página 20) Enrutamientos automáticos para acciones de workflow (en la página 23) Tipos de cambios y aprobación de cambio (en la página 25) Elementos de configuración y servicios afectados (en la página 27) Relaciones del ticket (en la página 28) Monitorización de conformidad del SLA (en la página 29) Artículos de conocimiento y base de conocimiento (en la página 31) Roles y grupos de soporte (en la página 32) Organización y seguridad basada en la organización (en la página 33) Proceso de gestión de tickets Los usuarios finales pueden introducir nuevas solicitudes ya sea enviando un correo electrónico al ID de soporte designado o desde la interfaz de usuario de la aplicación mediante un elemento del catálogo relevante del catálogo de solicitudes. Si no hay ningún elemento del catálogo disponible para una solicitud, los usuarios pueden utilizar la opción Crear nuevo para crear un ticket nuevo. Las solicitudes de usuarios finales se pueden enrutar automáticamente a distintos grupos de soporte en función de reglas de enrutamiento definidas durante la configuración de la aplicación. El enrutamiento automático coloca solicitud en un estado predeterminado para que puedan trabajar los analistas. Capítulo 2: Tratamiento del ticket y conceptos relacionados 15

16 Proceso de gestión de tickets Los analistas pueden revisar los tickets de su cola y determinar el curso de la siguiente acción. Las acciones del workflow que están disponibles para el analista se controlan según el estado del ticket y se gestionan mediante los permisos asignados por el administrador. El analista puede elegir una de las distintas acciones del workflow disponibles y mover la solicitud hacia su cumplimiento y cierre. 16 Guía del analista

17 Proceso de gestión de tickets El diagrama siguiente muestra el progreso general de una solicitud desde la creación al cierre. Capítulo 2: Tratamiento del ticket y conceptos relacionados 17

18 Proceso de gestión de tickets 18 Guía del analista

19 Ticket y ciclo de vida del ticket Según la naturaleza de la solicitud y según cómo se ha creado la solicitud, ésta se puede asignar al grupo de soporte adecuado. De lo contrario se deberá asignar la solicitud manualmente a un grupo de soporte distinto para su cumplimiento. También, en función de la naturaleza de la solicitud, el analista que trabaja en ella puede determinar que la solicitud se tiene que procesar como un incidente, un problema, un cambio o una solicitud de servicio. En tales casos, el analista puede crear un ticket nuevo de un tipo diferente a partir del ticket existente, para garantizar que la solicitud se gestione según los procesos adecuados. El objetivo final es asegurar que la solicitud se gestiona mediante los procesos adecuados y según los acuerdos de provisión de servicio acordados. Ticket y ciclo de vida del ticket Un ticket es un documento de transacción que registra toda la información relacionada con una solicitud enviada por o de parte de un usuario final o consumidor de soporte o de los servicios de TI. Un ticket tiene varios campos y secciones para los distintos tipos de información. Los campos del ticket contienen información que puede ser necesaria para entender completamente y cumplir la solicitud del usuario final sin tener que pedir al solicitante información adicional. Además de los campos de ticket estándares, el administrador de aplicaciones puede configurar y agregar campos personalizados para que estén disponibles en el ticket en función de la categorización del ticket. Una vez creado un ticket, se asigna a un grupo de soporte según las reglas de asignación configuradas por el administrador de la aplicación. El analista que tiene la propiedad del ticket determina después el curso de la siguiente acción del ticket. Depende de la naturaleza de la solicitud y de los procesos de soporte existentes. El administrador puede configurar acciones del workflow distintas para que estén disponibles en el ticket para controlar el progreso del ticket. Hay tres aspectos principales del progreso del ticket que se utilizan al generar el proceso de workflow: Fase: Se utiliza para ayudar a segmentar y definir los pasos en un proceso de workflow determinado. Durante un ciclo de vida del ticket, el ticket pasa por diversas fases y, en función de su progreso, puede volver de nuevo a una fase anterior. Como cada tipo de ticket tiene su propio progreso, las definiciones de fase difieren según el tipo de ticket. Capítulo 2: Tratamiento del ticket y conceptos relacionados 19

20 Tipos de ticket Estado: Hace referencia a la etapa actual (Problema, Incidente, Cambio o Solicitud de servicio) del ticket en su ciclo de vida, por ejemplo: Nuevo, En cola, Activo, Pendiente, Completado, Resuelto, Cerrado, etc. Hay estados fijos de tickets y definiciones de estado que no se pueden modificar. El ticket puede cambiar de un estado a otro, no necesariamente en un orden específico. Código de motivo: Se utiliza para asignar un motivo por el cual un ticket tiene un estado o fase determinados. Por ejemplo, se puede establecer un ticket con el estado Pendiente por diversos motivos como: Cliente pendiente, Distribuidor pendiente, Información pendiente, etc. mientras el estado se establece como Pendiente (el código de motivo define por qué está en ese estado). Importancia del ticket: al entrar en un ticket, se puede especificar la importancia de este mediante los campos Impacto, Urgencia y Prioridad. Si su administrador ha activado el cálculo de Prioridad automática, no se podrá modificar el campo de prioridad directamente. En tales casos, NSD calcula la prioridad en función de los campos Impacto y Urgencia. Estos campos están disponibles para todos los tipos de ticket, concretamente Problema, Incidente, Cambio y Solicitud de servicio. Se utiliza una combinación del estado del ticket y el código de motivo para gestionar las acciones del workflow disponibles en el ticket y para ayudar a gestionar el progreso del ticket. Los detalles sobre las fases y el progreso del ticket para cada tipo de ticket se muestran en los diagramas del workflow en la sección de gestión de tickets para cada tipo de ticket. Como el ticket progresa a través de su ciclo de vida, los registros del ticket acaban por incluir las actividades realizadas para resolver la solicitud. Esto incluye detalles de todas las transacciones del ticket incluyendo acciones manuales y automáticas y comunicaciones hacia y desde el ticket. Un ticket también lleva registros de los esfuerzos realizados para cumplir y cerrar la solicitud. Tipos de ticket En CA Nimsoft Service Desk hay cinco tipos de tickets: Solicitud de servicio: Este tipo de ticket se utiliza para registrar y gestionar solicitudes estándares de usuarios para obtener información o acceso a sistemas y servicios. Incluye solicitudes de información o soporte general no causado por la interrupción de un sistema o servicio existente. Las solicitudes de servicio se gestionan mediante procesos de workflow de gestión de solicitudes de servicio. Se puede monitorizar la respuesta a una solicitud de servicio para la conformidad del acuerdo de nivel de servicio para asegurar que se responde a la solicitud en un tiempo estipulado. 20 Guía del analista

21 Tipos de ticket Por ejemplo, un usuario final puede buscar información sobre si es posible configurar los correos electrónicos del trabajo para que se envíen y reciban en un teléfono móvil y obtener información sobre cómo configurarlo. Si es un servicio admitido, la información sobre cómo configurarlo se puede compartir con el solicitante y se puede cerrar la solicitud. Nota: Se puede relacionar un elemento de configuración con una solicitud de servicio. Ticket del incidente: Este tipo de ticket se utiliza para comunicar y gestionar incidencias como la interrupción, la indisponibilidad o la reducción en la calidad de un sistema o servicio al cual los usuarios ya acceden y utilizan. Un ticket de incidente se utiliza para identificar rápidamente la incidencia, encontrar una solución alternativa y restaurar la disponibilidad del servicio en el menor tiempo posible. Los tickets de incidentes se gestionan mediante procesos de workflow de la Gestión de incidentes. La disponibilidad de los sistemas y servicios se vincula normalmente a algunos acuerdos de nivel de servicio existentes y, por consiguiente, la respuesta y la resolución de estos tickets se monitoriza para el cumplimiento del acuerdo de nivel de servicio. Por ejemplo, un usuario final registra una solicitud que afirma que no se pueden enviar o recibir correos electrónicos desde el teléfono móvil. Este servicio está normalmente disponible para el solicitante pero se ha interrumpido causando dificultades al solicitante. Los analistas que trabajan en el ticket deben identificar la causa de la interrupción del servicio, restaurar el servicio rápidamente y comunicarse con el solicitante sobre su resolución. Nota: Se puede relacionar un elemento de configuración con un ticket de incidente. Ticket del problema: Este tipo de ticket se utiliza para investigar y resolver o mitigar incidencias principales que afectan a muchos usuarios, con el interés puesto en el análisis de la causa raíz y la resolución del problema. El equipo de Gestión de problemas suele registrar un ticket de problema para investigar una incidencia con un sistema existente o para examinar proactivamente un sistema o servicio existentes para eliminar incidencias potenciales. Los tickets de problemas se gestionan mediante procesos de workflow de la Gestión de problemas. Generalmente, el análisis de la causa raíz y su resolución es un proceso que consume mucho tiempo y por tanto el ticket del problema puede o no monitorizarse para el cumplimiento del acuerdo de nivel de servicio. Nota: Se puede relacionar un elemento de configuración con un ticket de problema. Capítulo 2: Tratamiento del ticket y conceptos relacionados 21

22 Tipos de ticket Petición de cambio: Este tipo de ticket se utiliza para registrar y gestionar peticiones de cambio en las infraestructuras o servicios de TI. Algunos cambios pueden afectar sólo al solicitante (o a un pequeño grupo de usuarios) mientras que otros pueden afectar a un gran número de usuarios. Como un cambio implica modificar un sistema o servicio existente y esto podría tener impacto en más de un usuario o en más de un sistema o servicio; todas las peticiones de cambio pasarán por un proceso de aprobación de cambios. En función de la naturaleza del cambio, el proceso de aprobación del cambio varía. Las peticiones de cambio se gestionan mediante los procesos de workflow de la Gestión de cambios. Los procesos de gestión de cambios difieren en función del tipo de cambio. Una petición de cambio puede o no monitorizarse para el cumplimiento del acuerdo de nivel de servicio, ya que el tiempo necesario para responder a un cambio y resolverlo está basado en muchos factores como obtener la aprobación para el cambio, etc. Nota: Se puede relacionar un elemento de configuración con una petición de cambio. Ticket de la tarea: Este tipo de ticket se utiliza para realizar un seguimiento y gestionar unidades más pequeñas de trabajo para la finalización de otro ticket (normalmente un ticket de cambio o de problema) y se registra como un ticket hijo de otro ticket. Los tickets de la tarea se registran cuando hay varias unidades más pequeñas de trabajo que se deben realizar para un ticket de cambio o de problema y cada tarea la pueden realizar personas distintas a la vez o de manera secuencial. Las tareas se gestionan como parte del proceso de workflow para el ticket padre para el cual se registra la tarea. Nota: Nunca se registran tickets de la tarea como tickets independientes; siempre se utilizan para dividir unidades individuales de trabajo realizado para resolver otro ticket. 22 Guía del analista

23 Enrutamientos automáticos para acciones de workflow Cuando se configura CA Nimsoft Service Desk se puede crear un catálogo de solicitudes con elementos del catálogo para los distintos tipos de solicitudes. Las solicitudes registradas mediante el catálogo de solicitudes darán lugar a la creación de un tipo de ticket adecuado, que incluirá la información correcta en los campos oportunos para enrutar automáticamente la solicitud al grupo de soporte adecuado. La clasificación de un ticket en el tipo de ticket correcto permite asegurarse de que se puedan aplicar los procesos de workflow adecuados al ticket y de que la solicitud se gestione mediante un proceso predefinido adecuado. Si una solicitud no se registra como el tipo de ticket correcto, los analistas pueden crear un ticket nuevo del tipo correcto a partir del ticket existente y gestionarlo según los procesos adecuados. Nota: La información proporcionada en este tema es aplicable a todos los tipos de ticket, concretamente, Cambio, Problema, Incidente y Solicitudes de servicio. Enrutamientos automáticos para acciones de workflow Los enrutamientos automáticos son reglas de enrutamiento de tickets que enrutan los tickets recién creados hasta las colas de los grupos de soporte adecuados según las condiciones de coincidencia, por ejemplo, fuente, CCTI de prioridad, etc. La asignación y el progreso de un ticket a través de su ciclo de vida están gestionados por los enrutamientos automáticos y las acciones del workflow configurados por el administrador de aplicaciones en función del proceso de tratamiento de solicitudes definido para cada tipo de ticket. Enrutamientos automáticos: Los enrutamientos automáticos se configuran para automatizar el proceso de asignación de un ticket a un grupo específico según criterios específicos. También ayudan a asegurar que el ticket se asigna a la cola del grupo de soporte adecuada y se puede trabajar en éste sin retrasos causados por el enrutamiento manual de tickets de un grupo de asignaciones predeterminado. Cuando se aplica un enrutamiento automático del ticket, se asigna el ticket a la cola del grupo de soporte adecuado. También se establecen valores para campos como Fase, Estado y Código de motivo, poniendo de esta forma el ticket en un estado conocido para que el analista empiece a trabajar en él. Algunos enrutamientos automáticos tienen plantillas de comunicación asociadas a ellos y envían notificaciones sobre la creación y asignación de tickets a las personas pertinentes. Importante: Un enrutamiento automático se aplica a un ticket solamente una vez cuando se crea un ticket por primera vez. Todos los enrutamientos o cambios subsiguientes se tienen que hacer mediante una acción de asignación manual a partir de las opciones disponibles en la lista desplegable Adoptar una medida del ticket. Capítulo 2: Tratamiento del ticket y conceptos relacionados 23

24 Enrutamientos automáticos para acciones de workflow Acciones del workflow: Las acciones del worfklow son el conjunto de acciones que se pueden llevar a cabo en un ticket y que guían al ticket hacia el cierre. Las acciones del workflow permiten la gestión de los tickets mediante un proceso definido. Las acciones del workflow son específicas de cada tipo de ticket y son un punto importante del diseño del workflow. Son acciones manuales que se ponen a disposición de analistas que trabajan en el ticket asignando permisos a acciones específicas de grupos de soporte o roles distintos. Una acción del workflow se puede configurar para estar disponible en un ticket en función de las condiciones coincidentes, es decir, el Estado, el Código de motivo, la Fase, etc. Ciertas opciones de las acciones del workflow están disponibles sin ninguna condición coincidente y, por consiguiente, estarán disponibles en un ticket en cualquier estado. Se pueden configurar también acciones del workflow para enviar notificaciones a los interesados cuando se ejecuta la acción. Algunos valores se pueden establecer también como campos necesarios antes de la ejecución de la acción del workflow. Cuando se ejecuta una acción del workflow en el ticket, se establecen ciertos valores del campo tal como se han configurado y el ticket se puede desplazar al estado siguiente, dirigiéndolo, de este modo, hacia el cierre. Algunas opciones de acción tienen una función especial asociada que puede automatizar todavía más la ejecución de una acción adicional (como Aceptar asignación, Reasignar en grupo, etc.). Según el tipo de acciones; algunas acciones del worfklow tienen una comunicación asociada a ellas. Nota: Como el acceso a una acción del workflow se controla mediante permisos, es posible que una acción disponible para el usuario no esté disponible para otro analista. El administrador de aplicaciones controla acceso a las acciones del workflow. 24 Guía del analista

25 Tipos de cambios y aprobación de cambio Tipos de cambios y aprobación de cambio El cambio se define como una agregación, modificación o eliminación de un sistema o servicio de TI existente como por ejemplo sistemas de software o hardware, configuraciones, documentación de acceso y de permisos, etc. Un cambio puede ser reactivo (en respuesta a un problema que se ha identificado) o proactivo (para evitar problemas potenciales o mejorar la provisión del servicio). Algunas peticiones de cambio son rutinarias por naturaleza, por ejemplo la agregación o eliminación de usuarios de un sistema o grupo o el aprovisionamiento de los sistemas con una nueva contratación. La cantidad de la planificación necesaria para tales solicitudes y el impacto potencial de estos cambios es relativamente menor. Otros tipos de cambios, por otro lado, necesitan una planificación detallada, revisiones de implementación posteriores meticulosas y una monitorización hasta que se logre un estado estable. La petición de cambio se puede clasificar en los cuatro tipos siguientes en función de factores como la naturaleza del cambio, el impacto, la urgencia, etc. Cambio estándar: Este tipo de cambio se recomienda para las solicitudes comunes relacionadas con sistemas y servicios de TI utilizados a menudo en la organización, por ejemplo la solicitud de un empleado para la instalación de un software, o el acceso a un sistema o base de datos. Tales solicitudes no necesitan un proceso de aprobación de cambios elaborado y se pueden aprobar a través de aprobadores contextuales como el gestor del solicitante o un aprobador asociado con un elemento de configuración. Cambio normal: Este tipo de cambio se recomienda para implementar cambios proactivos y planificados en sistemas y servicios de TI, por ejemplo implementando nuevos sistemas de seguridad de TI, lo cual tendrá impacto en cómo acceden los usuarios a los recursos de TI mediante una VPN. La implementación de un cambio de este tipo requeriría una investigación completa, planes de implementación de cambios detallados, varios niveles de revisión y aprobaciones, un tiempo de inactividad potencial durante la implementación y la revisión de implementación posterior para asegurar que el cambio se ha implementado correctamente. Cambio de emergencia: Este tipo de cambio se recomienda para situaciones reactivas en las cuales la implementación de un cambio es necesaria para o corregir o evitar un problema mayor con los sistemas o servicios existentes, por ejemplo cuando se produce un fallo en un servidor que conlleva un tiempo de inactividad para varios usuarios y, para corregir esto, el servidor defectuoso se tiene que reemplazar. Como el retraso en la implementación podría causar incidencias adicionales, en esta situación es necesario un proceso de aprobación e implementación más rápidos. Capítulo 2: Tratamiento del ticket y conceptos relacionados 25

26 Tipos de cambios y aprobación de cambio Cambio de reparación: Este tipo de cambio se utiliza normalmente para informar de un cambio después de que se haya implementado en una situación en la que el cambio se ha implementado sin un proceso de aprobación. Por ejemplo, se ha puesto en compromiso la seguridad de un servidor y se tiene que eliminar de la red para impedir una infracción de la seguridad. Los cambios de reparación no pasan por un proceso de aprobación y solamente se utilizan para registrar el cambio. Como la naturaleza de un cambio es siempre distinta, también son necesarios distintos tipos de aprobaciones para cada tipo de cambio. Mientras algunos cambios necesitan la aprobación de un aprobador contextual como por ejemplo el gestor del solicitante, otros cambios pueden pasar por distintos niveles de aprobación y pueden requerir la aprobación de uno o de todos los aprobadores. Para dar soporte a las necesidades de aprobación de los distintos tipos de cambios, se pueden asociar distintos tipos de aprobación con un ticket de cambio. Los tipos de aprobación que se pueden utilizar son los siguientes: Todos los aprobadores: Cuando se seleccione este tipo de aprobación, TODOS los aprobadores deberán aprobar el ticket. Si cualquier aprobador (aunque sea uno de todos los aprobadores asignados) rechaza el ticket, el proceso de aprobación terminará y se rechazará el cambio. Cualquier aprobador: Un cambio se aprobará en cuanto lo apruebe CUALQUIER aprobador. El proceso de aprobación de cambios no esperará la aprobación del resto de aprobadores; la aprobación sólo se rechazará cuando todos los aprobadores rechacen la propuesta. Cualquier aprobación o rechazo: Un solo aprobador del grupo de aprobación aprobará o rechazará un cambio. Se aplica la decisión del primer aprobador que responde (aprobar o rechazar) al proceso de aprobación. En este caso, el proceso de aprobación no espera a que el resto de aprobadores apruebe el cambio. Al configurar el proceso de gestión de cambios en CA Nimsoft Service Desk, las reglas para la aprobación de distintos tipos de cambios y los grupos de aprobación asociados con un cambio los configura el administrador. En algunos casos los analistas pueden seleccionar manualmente los aprobadores para una petición de cambio mientras en la mayor parte de las instancias los aprobadores se asocian a la petición de cambio en función de las condiciones configuradas por el administrador de aplicaciones. Las plantillas relacionadas con peticiones de cambios pueden estar disponibles para registrar distintos tipos de cambios. La utilización de la plantilla correcta para registrar la petición de cambio garantiza que se están aplicando automáticamente los procesos correctos al ticket. 26 Guía del analista

27 Elementos de configuración y servicios afectados Elementos de configuración y servicios afectados Un elemento de configuración es cualquier componente de la infraestructura de TI de la organización que debe gestionarse para proporcionar un servicio de TI. Todos los objetos de TI como hardware, software, dispositivos de conexión en red, unidades periféricas, documentación, etc. son ejemplos de elementos de configuración. Se puede crear un registro de todos los elementos de configuración en la organización y gestionarlo en CA Nimsoft Service Desk. A menudo una recolección de componentes de hardware y software funcionan conjuntamente para proporcionar un servicio de TI. Por ejemplo, se necesitan varios componentes como el host de correo, los servidores de correo, los buzones de correo y los equipos clientes, además de un software determinado para proporcionar el servicio de correo electrónico. Se puede crear un registro de todos estos servicios y guardarlo como un Elemento de configuración en CA Nimsoft Service Desk. Un elemento de configuración se puede relacionar con uno o más elementos de configuración en distintos dominios de relación, es decir: lógicos, de red, avanzado o de dominio del servicio. Un diagrama de relación se puede utilizar para ver cómo interactúan los elementos de configuración relacionados los unos con los otros. Esta información se puede utilizar para solucionar los problemas de algunas incidencias con el elemento de configuración. Los contactos se pueden relacionar con los elementos de configuración de diversos modos: como Propietario, Usuario, Aprobador del cambio, Revisor de cambios y Proveedor de soporte. La organización del propietario se convierte en la organización del Elemento de configuración. Los contactos asociados con el elemento de configuración como aprobador del cambio o revisor de cambios se pueden utilizar como aprobadores contextuales para los tickets de cambio relacionados con el elemento de configuración. Cuando se registra un ticket para comunicar una incidencia sobre un elemento de configuración, los elementos de configuración se podrán relacionar con el ticket y, en consecuencia, se podrá relacionar cada CI con un historial de todos los incidentes, problemas y cambios relacionados con un elemento de configuración. Estos podrán almacenarse y recuperarse. El hecho de relacionar un elemento de configuración con el ticket también permite que la gestión de toda la información relevante sea eficaz para el ticket en el formulario del ticket. Del mismo modo, si se registra un ticket para comunicar las incidencias con un servicio; los elementos de configuración relevantes se podrán relacionar con el ticket como Servicio afectado. Se pueden asociar elementos de configuración a un ticket si una incidencia comunicada se relaciona con un elemento de configuración, de manera que los datos históricos se puedan almacenar y extraer según sea necesario. El estado de un elemento de configuración indica si el CI se está utilizando actualmente o no, así como la etapa de su ciclo de vida en la que se encuentra el CI. Los analistas podrán ver los elementos de configuración en todos los estados excepto el de Desprovisto cuando relacionen un elemento de configuración a un ticket. Capítulo 2: Tratamiento del ticket y conceptos relacionados 27

28 Relaciones del ticket Nota: Se puede relacionar un elemento de configuración con un Problema, Incidente, Cambio o Solicitud de servicio. Relaciones del ticket Relaciones del ticket se refiere a los distintos tipos de registros que se pueden relacionar con un ticket. Se pueden relacionar tickets registrados en CA Nimsoft Service Desk con otros tickets o con elementos de configuración. También se pueden relacionar archivos adjuntos con un ticket para proporcionar información adicional sobre el ticket. La relación del ticket con otras entidades y cómo ayudan tales relaciones se explican a continuación: Ticket: Relaciones del ticket: Un ticket se puede relacionar con otro ticket de las tres maneras siguientes: Relación padre-hijo: Cuando un ticket nuevo se crea a partir de un ticket existente para un tratamiento más efectivo de la solicitud, los dos tickets comparten una relación padre-hijo. Por ejemplo, si un ticket de cambio se crea a partir de un ticket de problema (mediante una acción de creación del workflow de cambios) porque la resolución del problema exige la implementación de un cambio, el ticket de cambio y el ticket de problema comparten una relación padre-hijo. Como se crean tickets de la tarea solo para unidades completas de trabajo con otro ticket existente; los tickets de la tarea se registran siempre como tickets hijo para el ticket padre registrado. Relación del ticket global: Cuando se determina que varios incidentes más pequeños son debidos a una incidencia mayor, el ticket que hace referencia a la incidencia principal se puede marcar como Global y todos los tickets que informan sobre incidencias relacionadas se pueden relacionar con esta incidencia global. Por ejemplo, distintos usuarios han registrado varios tickets de incidente informando sobre pérdidas en la conectividad y se registra un incidente que informa que el servidor de red tiene algunos problemas de potencia. Se puede suponer que las incidencias sobre la conectividad son todas debidas al incidente con el servidor de red y que al resolver esta incidencia se deberían resolver los incidentes relacionados. Por consiguiente, el ticket registrado para el servidor de red se puede marcar como Global y todos los otros incidentes se pueden relacionar con éste. 28 Guía del analista