Guía de implementación rápida del workflow de CA Nimsoft Service

Transcripción

CA Nimsoft Service Desk
Guía de implementación rápida del
workflow
Otoño 2013
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 12.212, 52.227-14 y 52.227-19(c)(1) - (2) de FAR y en
la sección 252.227-7014(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.
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
http://www.ca.com/worldwide.
Contenido
Capítulo 1: Introducción
7
Descripción general ...................................................................................................................................................... 7
Funciones principales ................................................................................................................................................... 8
Tickets y gestión de tickets ................................................................................................................................... 9
Enrutamientos automáticos ................................................................................................................................ 10
Opciones de acción de workflow ........................................................................................................................ 11
Aprobación del ticket .......................................................................................................................................... 13
Plantillas de ticket ............................................................................................................................................... 14
Plantillas de comunicación .................................................................................................................................. 15
Roles y grupos de soporte ................................................................................................................................... 16
Umbrales y objetivos de los acuerdos de nivel de servicio ................................................................................. 17
Capítulo 2: Registros de aplicaciones listos para usar
19
Grupos de soporte...................................................................................................................................................... 19
Roles ........................................................................................................................................................................... 21
Umbrales y objetivos de gestión de nivel de servicio ................................................................................................ 24
Capítulo 3: Workflow de gestión de solicitudes
27
Descripción general de la gestión de solicitudes ....................................................................................................... 27
Proceso de workflow de solicitud de servicio ............................................................................................................ 29
Registros relacionados con las solicitudes de servicio ............................................................................................... 31
Plantillas de ticket de solicitud de servicio.......................................................................................................... 31
Plantillas de comunicación de solicitud de servicio ............................................................................................ 31
Enrutamientos automáticos de las solicitudes de servicio ................................................................................. 32
Opciones de acción del workflow para las solicitudes de servicio ...................................................................... 34
Capítulo 4: Workflow de gestión de incidentes
39
Descripción general de la gestión de incidentes ........................................................................................................ 39
Ciclo de vida de los tickets de incidente..................................................................................................................... 41
Registros relacionados con los tickets de incidente ................................................................................................... 43
Plantillas de ticket de incidente .......................................................................................................................... 43
Plantillas de comunicación de incidentes ........................................................................................................... 43
Enrutamiento automático de incidentes ............................................................................................................ 44
Opciones de acción del workflow para incidentes .............................................................................................. 45
Contenido 5
Capítulo 5: Workflow de gestión de problemas
51
Descripción general de la gestión de problemas ....................................................................................................... 51
Ciclo de vida de los tickets de problema .................................................................................................................... 53
Registros relacionados con los tickets de problema .................................................................................................. 55
Plantillas de ticket de problema .......................................................................................................................... 55
Plantillas de comunicación de problemas ........................................................................................................... 57
Enrutamientos automáticos de problemas ......................................................................................................... 58
Opciones de acción del workflow para problemas ............................................................................................. 59
Capítulo 6: Workflow de gestión de cambios
63
Descripción general de la gestión de cambios ........................................................................................................... 63
Ciclo de vida de una solicitud de cambio ................................................................................................................... 64
Cambio estándar ................................................................................................................................................. 66
Cambio normal .................................................................................................................................................... 69
Cambio de emergencia ....................................................................................................................................... 72
Cambio de reparación ......................................................................................................................................... 75
Registros relacionados con la gestión de cambios ..................................................................................................... 77
Plantillas de ticket de cambio ............................................................................................................................. 78
Plantillas de comunicación de cambios............................................................................................................... 81
Cambios de enrutamientos automáticos ............................................................................................................ 82
Opciones de acción del workflow para cambios ................................................................................................. 83
Grupos de aprobación de cambios ..................................................................................................................... 99
Capítulo 7: Problemas conocidos y aspectos que hay que tener en cuenta
101
Problemas conocidos ............................................................................................................................................... 101
No hay ningún grupo de soporte relacionado con el rol Gestión de la configuración. ..................................... 102
No hay ninguna plantilla de ticket Informar sobre una interrupción para los analistas ................................... 103
Los usuarios no podrán registrar solicitudes de servicio desde la interfaz de usuario ..................................... 104
Las condiciones de coincidencia son incorrectas para la acción del workflow Retirar cambio ........................ 106
No se ha relacionado ninguna plantilla de comunicación con la acción de workflow Enviar para la
aprobación ........................................................................................................................................................ 107
Aspectos que hay que tener en cuenta .................................................................................................................... 109
6 Guía de implementación rápida del workflow
Capítulo 1: Introducción
Este documento proporciona información acerca de las configuraciones de workflow
listas para usar disponibles cuando se crea una nueva instancia de Nimsoft Service Desk.
Proporciona información acerca de los diversos registros de la aplicación que están
disponibles de forma predeterminada y listos para usar para proporcionar asistencia
para llevar a cabo la tarea de diseño del workflow. Además, proporciona el diseño del
workflow para cada tipo de ticket, así como los registros de configuración que forman
parte de cada diseño del workflow.
Se puede optar por utilizar las configuraciones disponibles de workflow tal como están o
modificarlas para que se adapten a sus necesidades específicas de proceso de soporte.
Antes de modificar las configuraciones de workflow, se recomienda revisar el diseño
existente e identificar los cambios que desea hacer.
Después, hay que crear un diagrama de flujo de proceso que describa el proceso de
workflow deseado, que identifique los diferentes registros que se necesitan para dar
soporte al flujo y, a continuación, aplicar las modificaciones.
Nota: Se recomienda finalizar todas las acciones de configuración de la aplicación antes
de realizar las tareas para modificar o personalizar las configuraciones de workflow.
Para obtener información detallada acerca de cómo configurar la aplicación con datos
relevantes de la aplicación y conocer el modelo de permisos y su influencia en la
interacción entre los usuarios y la aplicación, consulte la Guía del administrador.
Esta sección contiene los siguientes temas:
Descripción general (en la página 7)
Funciones principales (en la página 8)
Descripción general
Los workflows listos para el uso se han diseñado en función de las prácticas
recomendables de la gestión del servicio ITIL y mediante las funciones clave de Nimsoft
Service Desk. Después de configurar la aplicación con los datos necesarios; como
Organización, Contacto, etc., se pueden relacionar los contactos con los grupos de
soporte existentes. Estos se pueden configurar como parte de las configuraciones listas
para el uso y conseguir rápidamente un valor de tiempo mediante los workflows listos
para usar con pocas modificaciones o sin modificaciones.
Capítulo 1: Introducción 7
Funciones principales
Se pueden registrar tickets enviando un correo electrónico al ID de correo electrónico
de soporte o desde la aplicación a través de una plantilla del ticket existente o de la
opción Crear nuevo. También se pueden configurar otras interfaces automatizadas para
integrarse con el proceso de creación de tickets; por ejemplo, se pueden configurar las
alarmas desde los sistemas de monitorización de Nimsoft para dar lugar a la creación de
tickets.
Cuando se crea el ticket, se le pueden aplicar enrutamientos automáticos. Estos
establecen el ticket en el estado predeterminado para que los analistas puedan trabajar
en él. A partir de este momento, el progreso del ticket en su ciclo de vida se puede
gestionar mediante un proceso de workflow definido.
Las configuraciones del workflow listas para usar incluyen enrutamientos automáticos y
acciones del workflow que gestionan el ticket durante su ciclo de vida. Cada tipo de
ticket tiene su propio y único diseño de workflow, incluyendo los enrutamientos
automáticos que asignarán el ticket a un grupo de soporte adecuado en función de las
condiciones coincidentes con el ticket, las opciones de acción del workflow que estarán
disponibles en las distintas etapas del ticket, de acuerdo con la fase de ticket y las
condiciones coincidentes.
Además de los enrutamientos automáticos y las opciones de acción que gestionan el
progreso del ticket; las configuraciones listas para usar incluyen plantillas de
comunicación para gestionar las notificaciones cuando se ejecuta una acción y plantillas
del ticket para registrar los tipos de tickets específicos para garantizar el adecuado
enrutamiento automático del ticket.
En las siguientes secciones se explican las diversas entidades asociadas a cada workflow
y los detalles sobre cómo se gestiona la progresión del ticket a través del workflow.
Los workflows listos para usar se han diseñado para utilizar algunas funciones clave del
registro y la gestión de tickets en Nimsoft Service Desk.
Cuando se instala una instancia nueva de la aplicación, algunos datos de la aplicación de
muestra (como los Grupos de soporte, los Roles, las Plantillas del ticket y las Plantillas de
comunicación) que forman parte del diseño de workflow se instalan también en los
enrutamientos automáticos y las acciones del workflow que constituyen el núcleo del
diseño de workflow. Algunos objetivos de acuerdos de nivel de servicio y ciertas reglas
de umbral también están configurados y disponibles para su uso.
Las configuraciones listas para usar se pueden modificar para que se ajusten a cualquier
proceso de soporte de TI específico. También se pueden crear acciones de workflow
adicionales o enrutamientos automáticos modelados en las configuraciones disponibles
y ampliar así la funcionalidad para aprovechar más si cabe las funciones disponibles en
Nimsoft Service Desk.
Para obtener más detalles sobre la serie de conceptos de gestión de tickets
implementados en Nimsoft Service Desk, así como información sobre las diversas
configuraciones relacionadas con los workflows, consulte la Guía de administración.
Tickets y gestión de tickets
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.
Los tickets tienen campos y fichas diferentes donde se puede registrar la información
específica relacionada. Además de los campos de ticket estándares, el administrador de
aplicaciones puede configurar y agregar campos personalizados al ticket. La información
de estos campos se puede utilizar para comprender mejor la solicitud y ofrecer servicio
para ella.
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.
En Nimsoft Service Desk, hay cinco tipos de tickets:
■
Solicitud de servicio: se utiliza para registrar y gestionar solicitudes estándares de
los usuarios para acceder a los sistemas y servicios.
■
Ticket del incidente: se utiliza para comunicar y gestionar incidencias como la
interrupción, la ausencia de disponibilidad o la reducción de la calidad de un
sistema o servicio que los usuarios utilizan y a los que tienen acceso.
■
Ticket de problema: este tipo de ticket se utiliza para investigar y resolver o mitigar
incidencias importantes 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.
■
Solicitud de cambio: se utiliza para registrar y gestionar solicitudes de cambio en la
infraestructura de TI o en los servicios que afectan a muchos usuarios. Por
consiguiente, implica un proceso de aprobación de cambios basado en el tipo de
cambio.
■
Ticket de la tarea: se utiliza para seguir y gestionar unidades más pequeñas de
trabajo con objeto de finalizar un ticket (normalmente un ticket de cambio o de
problema). Se registra como un ticket hijo de otro ticket.
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.
La gestión de tickets es el sistema que gestiona el progreso de un ticket hacia su cierre.
Cada tipo de ticket (excepto los tickets de la tarea) tiene su propio proceso de workflow
único, que gestiona el progreso del ticket hacia su cierre. Las configuraciones de
workflow listas para usar forman parte de este proceso de gestión de tickets y se han
configurado teniendo en cuenta las prácticas recomendadas del sector y casos de uso
comunes.
Hay tres aspectos principales en el progreso de un ticket, que se incluyen como parte
del workflow listo para usar:
■
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.
■
Estado: Hace referencia a la etapa actual del ticket en su ciclo de vida; como Nuevo,
En cola, Activo, Pendiente, Completado, Resuelto, Cerrado, Archivado, etc. Hay
estados fijos de tickets y las definiciones de estado 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).
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.
Enrutamientos automáticos
Los enrutamientos automáticos son reglas de enrutamiento de ticket que se pueden
aplicar para enrutar los tickets hasta las colas de los grupos de soporte adecuados en
función de la coincidencia con condiciones como la fuente, la prioridad, etc. Los
enrutamientos automáticos se configuran para automatizar el proceso de asignación de
un ticket a un grupo específico basándose en determinados criterios.
La configuración de enrutamientos automáticos bien definidos garantiza que el ticket se
asigne a la cola adecuada y se pueda trabajar en él sin los retrasos que suele provocar el
enrutamiento manual de los tickets.
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.
En las configuraciones listas para usar, los enrutamientos automáticos están diseñados
para activarse en función de la fuente del ticket o de otras condiciones que coincidan,
por ejemplo, el Código de motivo.
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 y envían notificaciones sobre la creación de los
tickets y su asignación los interesados pertinentes.
Nota: Se recomienda que los tickets nuevos se creen usando una plantilla de ticket, ya
que las plantillas tienen valores de campo definidos que se corresponden con las
condiciones de coincidencia de los enrutamientos automáticos y garantizan que las
acciones del workflow correctas estén disponibles en el ticket al efectuar la asignación.
Los tickets nuevos que se hayan creado usando plantillas tienen más posibilidades de
que se actúe sobre ellos.
También se recomienda que, al crear plantillas de ticket nuevas, si los valores de campo
definidos se corresponden con las condiciones de coincidencia de los enrutamientos
automáticos existentes, se usen las mismas reglas de enrutamiento para las plantillas de
enrutamiento más nuevas.
Opciones de acción de workflow
Las opciones Acción del workflow son el conjunto de acciones que se pueden realizar en
un ticket; las cuales dirigen al ticket hacia el cierre. Las acciones del workflow permiten
la gestión de los tickets mediante un proceso definido. Las opciones Acción del
workflow, específicas de cada tipo de ticket, son un punto importante del diseño del
workflow. Estas acciones son manuales y están a disposición de los analistas que
trabajan en el ticket. Los permisos controlan el acceso a las acciones del workflow.
Las opciones Acción del workflow se pueden configurar para estar disponibles 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.
En las configuraciones listas para usar, hay una serie de opciones de acción de workflow
disponibles para cada tipo de ticket. En función de la fase en la que esté el ticket y de
otras condiciones de coincidencia, las diferentes opciones de acción disponibles en el
ticket permiten un progreso controlado del ticket hacia su 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.
Los atributos principales de las acciones de workflow listas para usar son:
■
Orden de clasificación estructurado, que controla el orden en el que se muestran
las diferentes acciones en la lista desplegable Adoptar una medida. Esto se hace de
forma coherente para todos los tipos de ticket. Por ejemplo:
■
Todas las acciones Tomar propiedad pertenecen al orden de clasificación 100.
■
Todas las acciones Volver a asignar pertenecen al orden de clasificación 200.
■
Todas las acciones Definir como pendiente pertenecen al orden de clasificación
300.
■
Todas las acciones Resolver pertenecen al orden de clasificación 900.
■
Descripción clara de cada acción del workflow, en la que se explica por qué y
cuándo se debe ejecutar cada acción. La descripción se muestra cuando el usuario
pasa el cursor sobre una acción de la lista desplegable. Esto se hace como forma de
ayudar a los analistas para que seleccionen la acción adecuada, ya que se les ofrece
información sobre qué resultado se alcanzará al llevar a cabo cada acción.
■
Convenciones de denominación coherentes para las acciones del workflow en todos
los tipos de tickets. Esto aporta uniformidad a la nomenclatura y facilita el uso por
parte de los analistas.
Algunas acciones de workflow especiales, como Resolver a la primera llamada para
incidentes, se han configurado para habilitar las tendencias. Al ejecutar esta acción, el
ticket pasa a una fase de Resolución en la primera llamada.
Se puede elaborar un informe para identificar el número de tickets que están en esta
fase, lo que ayudará a identificar qué tipo de incidencias puede gestionar el soporte de
nivel 1. Esta información se puede utilizar para construir una mejor base de
conocimiento para que se use en el nivel 1 y se puedan resolver más incidentes en la
primera llamada, lo que mejoraría la calidad del soporte.
Nota: Al crear nuevas acciones de workflow, se recomienda seguir el orden de
clasificación y la convención de denominación del workflow listo para usar y, además,
proporcionar una descripción clara para una acción del workflow. Una descripción clara
puede ayudar a los analistas a decidir qué acción se debe realizar.
Aprobación del ticket
La aprobación es el proceso de pedir el permiso de aprobadores designados para
continuar con una acción que se ha solicitado. ITIL recomienda que una organización
configure un proceso de aprobación para todas las peticiones de cambio de la
infraestructura de TI. Al incluir un proceso de aprobación de cambio, la organización
puede garantizar que todos los cambios propuestos se analicen, justifiquen y validen
antes de la implementación. El proceso de implementación de cambio también
garantiza que todos los cambios estén bien planificados e incluyan la implementación y
los planes de verificación, así como un plan de retroceso. En algunas organizaciones, los
usuarios piden la aprobación para solicitudes estándares, como la adquisición de
sistemas o servicios.
El administrador de Service Desk puede configurar un proceso de aprobación para todos
los tipos de tickets, como los tickets de solicitud de servicio, incidente, problema,
cambio y tarea. Para configurar el proceso de aprobación, el administrador de Service
Desk puede configurar grupos de aprobación para cada ticket y relacionar aprobadores
y revisores con los grupos de aprobación. El administrador de Service Desk puede
configurar una acción del workflow con el fin de que el analista la considere para enviar
un ticket a aprobación. El administrador de Service Desk puede configurar también un
proceso de aprobación de varios niveles, para que el ticket pase por múltiples niveles de
aprobaciones.
El administrador de Service Desk puede configurar grupos de aprobación formados por
individuos seleccionados que sean miembros del comité asesor de cambios (CAB) o del
consejo asesor de cambios de emergencia (ECAB). El administrador de Service Desk
puede configurar también grupos de aprobación que estén formados por aprobadores
contextuales. Un aprobador contextual se identifica a partir del ticket que se envía para
aprobación. Por ejemplo, los contactos como los aprobadores o los revisores de un
elemento de configuración (CI) relacionado o el gestor del solicitante pueden ser un
aprobador contextual.
Cuando un ticket se envía para aprobación, se envía una notificación por correo
electrónico a los aprobadores y revisores relacionados. Para que los aprobadores y
revisores puedan enviar sus comentarios de aprobación o revisión deben iniciar sesión
en la aplicación o responder a la notificación por correo electrónico.
Nota: De forma predeterminada, el enrutamiento de aprobación se configura solamente
para las peticiones de cambio. Se puede activar el enrutamiento de aprobación para
otros tipos de ticket.
Plantillas de ticket
En el contexto del soporte de TI, hay varias solicitudes que se repiten con frecuencia,
como la solicitud de permisos para usar un dispositivo o servicio o para acceder a ellos,
la adición de usuarios a un sistema o servicio o su eliminación, los avisos sobre la
indisponibilidad de un sistema o servicio o la solicitud de alguna modificación estándar
(por ejemplo, la actualización a la última versión del software).
Para estas solicitudes frecuentes, las plantillas de ticket se pueden configurar y ponerlas
a disposición de los usuarios mediante la asignación de permisos a los roles o grupos de
soporte relevantes.
Las plantillas de ticket son un sistema de recolección de información normalizado para
solicitudes que se pueden anticipar. También facilitan la aplicación efectiva de
enrutamientos automáticos, basados en campos definidos en la plantilla. De esta forma,
los tickets registrados mediante la plantilla se pueden asignar directamente a un
individuo o grupo concretos, lo que agiliza la respuesta a la solicitud.
Una plantilla de ticket se puede relacionar con cualquier tipo de ticket y se puede
configurar estableciendo valores de campo para cualquiera de los campos de ticket
estándares, así como para los campos personalizados de dicho tipo de ticket. Si hay que
seguir una regla de asignación especial para los tickets registrados mediante esta
plantilla (si están definidos los campos Asignado al individuo o Asignado al grupo), el
administrador puede anular los enrutamientos automáticos para ese tipo de ticket para
evitar que se apliquen.
En función de los valores de campo definidos, se podrían aplicar enrutamientos
automáticos al ticket para configurarlo en el estado adecuado. Las opciones de acción
que en ese momento pasan a estar disponibles en el ticket permiten llevarlo hacia su
cumplimiento y cierre.
Se pueden configurar plantillas de ticket de la tarea y relacionarlas con los grupos o
flujos de tareas. Esto facilita la automatización del proceso de creación, enrutamiento y
finalización de las tareas que se requiere para completar una solicitud.
En la configuración lista para usar, se configuran plantillas de ticket para incidentes,
problemas y gestión de cambios. La gestión de problemas y cambios también tienen un
grupo de tareas y un flujo de tareas relacionados, respectivamente. Estas plantillas se
pueden adaptar. También se pueden configurar plantillas nuevas en función de
requisitos específicos.
Nota: Se recomienda analizar la actividad de los tickets existentes para identificar los
cinco o diez tipos principales de solicitudes más repetidas y desarrollar plantillas del
ticket para estas solicitudes. Al configura las plantillas, preste atención especialmente a
los atributos específicos requeridos que permiten a los analistas trabajar en el ticket sin
tener que interactuar más con el solicitante.
Se pueden configurar estas plantillas y asignar permisos a los roles o grupos de soporte
relevantes. Se recomienda encarecidamente que los usuarios empleen las plantillas para
registrar las solicitudes, ya que así se garantiza la aplicación de enrutamientos
automáticos adecuados para el ticket y que las acciones de workflow apropiadas estén
disponibles en el ticket. Para los analistas es más fácil trabajar con los tickets registrados
mediante plantillas y, si el solicitante proporciona toda la información relevante, se
reducen los retrasos al trabajar con la solicitud.
Plantillas de comunicación
Las plantillas de comunicación son plantillas de correo electrónico configuradas
previamente con un asunto y un cuerpo del mensaje estándares configurados por el
administrador de la aplicación. Las plantillas de comunicación se pueden usar para
enviar notificaciones a partir de la aplicación, los tickets, la planificación de comentarios
sobre el servicio, etc.
Se pueden utilizar plantillas de comunicación para notificaciones automatizadas que
pueden estar relacionadas con enrutamientos automáticos y acciones de workflow o
umbrales de objetivo de los acuerdos de nivel de servicio. Cuando se aplica un
enrutamiento automático al ticket, se ejecuta una acción de workflow en el ticket o se
infringe un umbral de objetivo de un acuerdo de nivel de servicio, se envía una
notificación a través de la plantilla de comunicación relacionada a los destinatarios
identificados en el campo Enviar a de la plantilla.
El permiso para las plantillas de comunicación se puede conceder a roles y grupos de
soporte. Los analistas que trabajan en el ticket pueden utilizar la plantilla para enviar
comunicaciones manuales desde el ticket.
La opción Agregar un campo del formulario permite configurar las plantillas de
comunicación para que obtengan información a partir del ticket o de los formularios
relacionados. El campo seleccionado se establece como marcador de posición en la
plantilla de comunicación y se rellena con la información del contexto cuando se genere
el registro de comunicación.
Los destinatarios de la comunicación también se pueden obtener a partir del contexto
de la comunicación, por ejemplo, Enviar a ${tr.person1_alt_email}. Esto permite enviar
la notificación al contacto que solicitó el ticket.
En las configuraciones listas para usar, las plantillas de comunicación están asociadas
con enrutamientos automáticos seleccionados y acciones de workflow, que envían
notificaciones automáticas a los destinatarios asociados (por ejemplo, Solicitante,
Beneficiario, Asignado a contacto o grupo de soporte, etc.) sobre la ejecución del
enrutamiento automático o la acción de workflow. Algunas plantillas de comunicación
se han configurado también para notificar los casos en los que se incumplan los
umbrales del acuerdo de nivel de servicio.
Para aprovechar aún más esta función, se puede asignar un ID de correo electrónico al
grupo de soporte, lo que permite enviar una notificación al ID del grupo de soporte en
lugar de a cada contacto individual relacionado con el grupo de soporte.
Nota: Consulte la Guía de administración para obtener información sobre cómo procesa
la aplicación los correos electrónicos entrantes y salientes. Las plantillas de
comunicación se pueden localizar y ponerlas a disposición de los usuarios en el idioma
que prefieran. Consulte la Guía del administrador para obtener más detalles sobre cómo
se pueden localizar las plantillas de comunicación y los aspectos relacionados con los
detalles de comunicación visibles en un ticket.
Roles y grupos de soporte
Un grupo de soporte es una agrupación de contactos según sus ubicaciones geográficas,
habilidades o tareas concretas para las cuales se utiliza la aplicación. Esta agrupación de
contactos se puede utilizar para funciones como el enrutamiento de tickets basado en
habilidades, la asignación y aprobación de tickets, etc.
Un rol es una agrupación de contactos y grupos de soporte en un solo banner según la
cantidad de funciones realizadas mediante la aplicación. Esta agrupación de contactos y
grupos de soporte se utiliza para gestionar permisos eficazmente.
Conjuntamente, los grupos de soporte y los roles se pueden utilizar para gestionar
eficazmente acciones como la asignación de permisos y la gestión de la asignación de
tickets, notificaciones, etc.
En Nimsoft Service Desk, la posibilidad que tiene un usuario de acceder a diversas
entidades (como elementos del menú de navegación, opciones de la barra de
herramientas del ticket, opciones de acción de workflow, plantillas de comunicación,
plantillas del ticket, etc.) se controla mediante permisos. Los permisos se pueden
gestionar mejor asignando permisos a roles o grupos de soporte, lo cual se puede
heredar después a partir de contactos relacionados con roles o grupos de soporte.
Hay un conjunto de roles y grupos de soporte definidos y disponibles listos para usar.
En las configuraciones listas para usar, los roles se han usado para gestionar los
permisos para las opciones del menú de navegación, las opciones de acción de
workflow, las plantillas del ticket, etc. Los grupos de soporte se han relacionado con el
rol según las diversas funciones que se supone que deben realizar usando aplicación. Se
ha comprobado que esto es una buena práctica para implementar una solución de
gestión de servicios.
Los grupos de soporte que se han configurado listos para usar se han usado para la
acción de asignación de tickets y para enviar comunicaciones desde los tickets, según
proceda. Los contactos pueden estar relacionados con los grupos de soporte y su
interacción con los tickets se puede controlar mediante el grupo de soporte al que
pertenecen.
Nota: La funcionalidad de los grupos de soporte se puede mejorar configurando un
Grupo de escalado siguiente para los grupos de soporte que trabajan con tickets,
teléfonos e ID de correo electrónico de grupos de soporte. Esto permite gestionar
eficazmente las acciones por incumplimiento de los umbrales de los acuerdos de nivel
de servicio. También se pueden configurar horarios comerciales del grupo de soporte
para gestionar mejor las asignaciones a equipos de soporte dispersos geográficamente.
Es muy recomendable que los contactos estén relacionados con los grupos de soporte
existentes, ya que estos grupos de soporte se han utilizado como parte de
enrutamientos automáticos y de plantillas de comunicación listas para usar. Asimismo,
se ha asignado permiso para las acciones del workflow a los grupos de soporte
disponibles listos para usar.
Se recomienda también que los nuevos grupos de soporte que se están configurando
estén relacionados con los roles listos para usar existentes que proceda. Esto
garantizará que el modelo de permisos implementado listo para usar se pueda
aprovechar por completo.
Umbrales y objetivos de los acuerdos de nivel de servicio
La gestión de nivel de servicio se ocupa del proceso de negociación de acuerdos de nivel
de servicio y de garantizar su cumplimiento. La gestión de nivel de servicio tiene la
responsabilidad de asegurar que todos los procesos de gestión del servicio de TI, los
acuerdos de nivel operativo y los contratos de soporte se adecuan a los objetivos del
nivel de servicio acordados.
La gestión de nivel de servicio monitoriza y se comunica en los Objetivos del servicio,
que se miden con una métrica del servicio, como el Tiempo de respuesta, el Tiempo de
resolución, etc.
En las configuraciones listas para usar, se han configurado algunos umbrales y objetivos
de servicio para aplicarlos a diferentes métricas de servicio con objeto de monitorizar
los acuerdos de nivel de servicio. En función de las condiciones de coincidencia del
ticket, el objetivo se aplica al ticket y este se monitoriza para comprobar su conformidad
con el acuerdo de nivel de servicio. Según las reglas de umbral, se envían notificaciones
o el ticket se asigna al grupo de escalado siguiente.
Nota: En las configuraciones listas para usar, se han configurado objetivos de acuerdo
de nivel de servicio principalmente para incidentes. Si lo desea, se puede extender esta
función a otros tipos de tickets.
Capítulo 2: Registros de aplicaciones listos
para usar
Cuando se instala una instancia nueva de Nimsoft Service Desk, un conjunto de
entidades definidas por el sistema (como los contactos definidos por el sistema, los
grupos de soporte, las plantillas de comunicación, etc.) se instala también de forma
predeterminada.
Si se opta por instalar las configuraciones listas para usar, también se instalarán los
grupos de soporte, los roles, las plantillas de comunicación, las plantillas de ticket, los
enrutamientos automáticos, las acciones de workflow y los objetivos del acuerdo de
nivel de servicio que forman parte de las configuraciones de workflow listas para usar.
En esta sección se proporciona información acerca de los registros de la aplicación listos
para usar, como los grupos de soporte, los roles, etc., que se incluyen como parte de las
configuraciones de workflow listas para usar. Los registros específicos de ticket, como
las plantillas, los enrutamientos automáticos y las acciones de workflow específicas para
cada tipo de ticket se enumeran como parte del diseño de workflow para cada tipo de
ticket.
Grupos de soporte (en la página 19)
Roles (en la página 21)
Umbrales y objetivos de gestión de nivel de servicio (en la página 24)
Grupos de soporte
Los grupos de soporte son una parte integral del diseño de workflow listo para usar. Los
tickets se asignan a los grupos de soporte, tal y como se haya definido en los
enrutamientos automáticos. El acceso a las diferentes opciones de acción de workflow
se gestiona mediante permisos asignados a los grupos de soporte.
Capítulo 2: Registros de aplicaciones listos para usar 19
Grupos de soporte
En la tabla que aparece a continuación, se enumeran los grupos de soporte que están
disponibles y listos para usar, así como los permisos asignados a ellos.
ID del
grupo
Nombre del
grupo de
soporte
Utilizado para
Finalidad
11
Service Desk (L1) Permiso, notificación y
asignación
Este es el grupo de soporte de nivel 1 que gestiona el
primer nivel de evaluación de los tickets. En función de las
condiciones de coincidencia, los tickets se enrutan de
forma automática a este grupo de soporte para realizar
otras acciones.
20
Aprobadores de Notificación y grupo de
cambios
aprobación
Este grupo de soporte se utiliza para poner en cola los
tickets que deben revisar los responsables de la gestión de
cambios.
21
CAB
Notificación y grupo de
aprobación
Este es el Foro de aprobación de cambios, que permite
agrupar contactos que están involucrados en el proceso de
aprobación de cambios.
22
ECAB
Notificación y grupo de
aprobación
Este es el Foro de aprobación de cambios de emergencia,
que permite agrupar contactos que están involucrados en
el proceso de aprobación de cambios.
28
Gestor de
cambios
Permiso, notificación y
grupo de aprobación
Este grupo de soporte se utiliza para agrupar contactos
que son gestores de cambios.
29
Grupo de
instalaciones
Permiso, notificación,
asignación y escalado
de acuerdos de nivel de
servicio
Este grupo de soporte se ha creado como grupo de
muestra para gestionar tareas específicas. En el diseño del
workflow listo para usar, este grupo de soporte gestiona
las tareas que forman parte de la plantilla del ticket Nuevo
empleado de aprovisionamiento.
30
Soporte para
equipos de
escritorio
Este grupo de soporte se utiliza para agrupar a los analistas
que proporcionan soporte para equipos de escritorio.
servicio
31
Soporte para
Este grupo de soporte se utiliza para agrupar a los analistas
servidores (nivel asignación y escalado
que proporcionan soporte para servidores de nivel 2.
2)
servicio
32
Configuración
Este grupo de soporte puede estar relacionado con el rol
Gestión de la configuración y se ocupa de tareas
de acuerdos de nivel de vinculadas con la gestión de elementos de configuración.
servicio
Roles
Además de los grupos de soporte anteriores, que se configuran para los workflows listos
para usar, los tres grupos de soporte siguientes están disponibles de forma
predeterminada:
■
Administración: este soporte es para los contactos designados como
administradores de aplicaciones. Los contactos de este grupo de soporte tienen
acceso a todas las funcionalidades de las aplicaciones y a todas las opciones del
menú de navegación. Además, pueden crear o modificar todos los tipos de registros
de la aplicación.
■
Autoservicio: este grupo de soporte es para todos los contactos que son usuarios
finales del soporte de TI. Los contactos con licencia de autoservicio se agregan
automáticamente a este grupo de soporte y tienen acceso a la interfaz de usuario
de autoservicio.
■
Público: este grupo de soporte se utiliza para agrupar a todos los contactos que no
son miembros de los grupos de soporte de autoservicio ni de administración. Se
puede utilizar para asignar permisos comunes a todos los contactos que no sean
usuarios de autoservicio. En el diseño de workflow listo para usar, este grupo se ha
utilizado con poca frecuencia.
Roles
Los roles se pueden utilizar como una forma efectiva de gestionar los permisos. Los
contactos y los grupos de soporte pueden estar relacionados con un rol y los permisos
se pueden asignar al rol en cuestión. Los contactos y los grupos de soporte heredan los
permisos asignados al rol.
Los roles son un aspecto importante del diseño de workflow listo para usar, puesto que
el acceso a los informes y a los distintos tipos de tickets se gestiona mediante permisos
asignados a diferentes roles.
En la siguiente tabla, aparecen los roles configurados y disponibles listos para usar.
Nombre del rol
Grupos de soporte
relacionados
Detalles del permiso
Supervisor de
Service Desk
Ninguno
Tiene permisos para las opciones de acción del workflow para
volver a abrir los tickets cerrados o resueltos y para acceder a
los informes de Tendencias y métricas en el menú de
navegación
Roles
Autoservicio
predeterminado
■
Autoservicio
Tiene acceso a todos los elementos del menú de navegación en
la interfaz de usuario de autoservicio y a todas las acciones
disponibles para todos los usuarios de autoservicio.
Este rol también tiene acceso a las siguientes plantillas de ticket:
Administrador
■
Gestión de cambios ■
■
■
Administración
■
Servidor web de aprovisionamiento (muestra)
■
Informar sobre una interrupción
■
Nuevo empleado de aprovisionamiento (muestra)
Este rol no se ha utilizado en el workflow listo para usar.
realizar acciones relacionadas con los tickets de cambio. Tiene
Aprobadores de
acceso a las opciones Crear cambio (mediante una plantilla),
cambios
Enumerar solicitudes de cambio, Cambios planificados y Buscar
Gestores de cambios solicitudes de cambio en el menú de navegación y también tiene
acceso al Informe de antigüedad de los tickets abiertos.
Service Desk (L1)
Gestión de
problemas
■
Service Desk (L1)
■
Solicitud de cambio normal (agente)
■
Solicitud de cambio estándar (agente)
■
Solicitud de cambio de emergencia (agente)
■
Solicitud de cambio de reparación (agente)
■
Nuevo empleado de aprovisionamiento (muestra)
realizar acciones relacionadas con tickets de problema. Tiene
acceso a las opciones Problema del informe (mediante plantilla),
Enumerar problemas, Buscar tickets de problema e Informes en
el menú de navegación.
Este rol también tiene permiso para las siguientes plantillas de
ticket:
■
Informe del problema (agente)
■
Problema proactivo (agente)
■
Informar de un error conocido (agente)
■
Revisiones del ticket anteriores al cierre del problema
(grupo de tareas)
■
Problema - Resolver tickets relacionados (tarea)
■
Problema - Revisar artículos de conocimiento (tarea)
Roles
Aprobadores de
cambios
■
Aprobadores de
cambios
■
CAB
■
ECAB
Tiene permisos para las acciones de workflow para aprobar
cambios manualmente y pasar el cambio a la fase de
implementación. Además, puede acceder a los elementos de
Gestión de cambios en el menú de navegación, incluidas las
opciones Crear cambio (mediante una plantilla), Mis tareas de
aprobación, Buscar solicitudes de cambio, Cambios planificados
e Informes
■
Crear solicitud de reparación (agente)
■
■
■
Gestión de
incidentes
■
Service Desk (L1)
Tiene permiso para las acciones de workflow relacionadas con
los tickets de incidente. Tiene acceso a los elementos
relacionados con la gestión de incidentes en el menú de
navegación, por ejemplo, Enumerar incidentes, Notificar
incidente, Notificar incidente (mediante plantilla), Buscar
incidentes e Informes.
Gestión de
solicitudes de
servicio
■
Service Desk (L1)
Tiene permisos para las acciones de workflow para realizar
acciones relacionadas con las solicitudes de servicio. Tiene
acceso a los elementos relacionados con la gestión de
solicitudes en el menú de navegación, por ejemplo, Solicitud del
registro (mediante plantilla), Buscar solicitudes de servicio e
Informes.
Gestión de la
configuración
Tiene permisos para acceder a los elementos del menú de
Nnavegación relacionados con la gestión de la configuración, por
i ejemplo, Crear elemento de configuración, Buscar elementos de
nconfiguración e Informes.
g
u
n
o
Gestión del
conocimiento
Ninguno
navegación relacionados con la gestión del conocimiento, por
ejemplo, Crear artículo de KB, Buscar artículos de KB, Gestionar
categoría del artículo de KB e Informes.
Solicitante del
cambio
Ninguno
navegación relacionados con el registro de tickets de cambio,
por ejemplo, Crear cambio (mediante una plantilla), Buscar
solicitudes de cambio y Cambios planificados.
Umbrales y objetivos de gestión de nivel de servicio
Gestor de cambios
■
Gestor de cambios
Tiene permisos para acciones de workflow relacionadas con el
envío de cambios para su aprobación, la retirada de cambios de
su aprobación, la aprobación de cambios para su
implementación y la interrupción del proceso de aprobación.
■
Crear solicitud de reparación (agente)
■
■
■
Nota: Se recomienda que los nuevos grupos de soporte que se vayan a configurar estén
relacionados con estos roles y que dichos roles se utilicen para gestionar los permisos
con mayor eficacia.
La gestión de nivel de servicio se ocupa de identificar los servicios de TI y de definir
acuerdos de nivel de servicio que especifiquen las condiciones relacionadas con la
disponibilidad de un servicio. En Nimsoft Service Desk, se pueden definir objetivos de
servicio basados en las métricas de servicio disponibles y configurar umbrales de
cumplimiento e incumplimiento para evaluar la prestación de un servicio con respecto a
los acuerdos de nivel de servicio establecidos.
En la siguiente tabla figuran los objetivos de servicio que están disponibles como parte
de las configuraciones de workflow listas para usar.
Objetivo del
servicio
Métrica de
servicio
Se aplica al Condiciones
tipo de
coincidentes
ticket
Tiempo de
Tiempo de
Incidente
respuesta ante respuesta (24X7)
incidentes de
prioridad crítica
■
Tipo de ticket
= Incidente
■
Código de
prioridad del
ticket = 1
(crítica)
Tiempo de
respuesta ante
incidentes de
■
Tiempo de
respuesta
(horario
Incidente
Tipo de ticket
= Incidente
Valor de
umbral
(minuto
s)
Umbral Acción si se incumple
de
el umbral
incump
limient
o
> 15
No
Enviar notificación por
correo electrónico
>= 30
Sí
correo electrónico
> 45
No
correo electrónico
prioridad alta
comercial del
grupo de
soporte)
Tiempo de
respuesta ante
incidentes de
prioridad media
Tiempo de
respuesta
(horario
comercial del
grupo de
soporte)
Incidente
■
Código de
prioridad del
ticket = 2
(alta)
>= 60
Sí
correo electrónico
■
Tipo de ticket
= Incidente
> 105
No
correo electrónico
■
Código de
prioridad del
ticket = 3
(media)
>= 120
Sí
correo electrónico
■
Tipo de ticket
= Incidente
> 45
No
correo electrónico
■
Código de
prioridad del
ticket = 1
(crítica)
>= 60
Sí
correo electrónico
> 225
No
correo electrónico
> = 240
Sí
correo electrónico
> 465
No
correo electrónico
>= 480
Sí
correo electrónico
Tiempo de
Tiempo de
resolución de
resolución
incidentes de
(24X7)
prioridad crítica
Incidente
Tiempo de
resolución de
incidentes de
prioridad alta
Hora de
resolución
(horario
comercial del
grupo de
soporte)
Incidente
Tiempo de
resolución de
incidentes de
prioridad media
Hora de
resolución
(horario
comercial del
grupo de
soporte)
Incidente
Ejemplo
genérico de
tiempo de
respuesta en 4
horas
Tiempo de
Solicitud de ■
respuesta (24X7) servicio,
solicitud de
cambio y
tarea
■
Ninguno
> 120
No
correo electrónico
Ninguno
>= 240
Sí
correo electrónico
Ejemplo
genérico de
tiempo de
resolución en 8
horas
Tiempo de
resolución
(24X7)
Ninguno
> 120
No
correo electrónico
> 240
No
Asignar a grupo de
escalado siguiente
■
Tipo de ticket
= Incidente
■
Código de
prioridad del
ticket = 2
(alta)
■
Tipo de ticket
= Incidente
■
Código de
prioridad del
ticket = 3
(media)
Solicitud de ■
servicio,
solicitud de
cambio y
tarea
>= 480
Sí
correo electrónico
Nota: Los objetivos de los acuerdos de nivel de servicio genéricos de muestra se han
configurado como un ejemplo para mostrar acciones como la de Asignar a grupo de
escalado siguiente. Estos objetivos se pueden modificar para crear otros más específicos
para los diferentes tipos de ticket.
Capítulo 3: Workflow de gestión de
solicitudes
Las solicitudes estándares de un usuario final que desea información o consejo sobre el
uso de un sistema o servicio o que solicita una modificación o un cambio estándar en un
servicio disponible se pueden gestionar mediante solicitudes de servicio. Los usuarios
finales también pueden usar solicitudes de servicio para informar sobre las incidencias
que les surjan.
En esta sección se proporciona información acerca del proceso de gestión de solicitudes
y el diseño de workflow listo para usar para gestionar las solicitudes de servicio.
Nota: Si un ticket debe pasar por un proceso de aprobación, debería procesarse como
ticket de cambio y no como solicitud de servicio.
Descripción general de la gestión de solicitudes (en la página 27)
Proceso de workflow de solicitud de servicio (en la página 29)
Registros relacionados con las solicitudes de servicio (en la página 31)
Descripción general de la gestión de solicitudes
La gestión de solicitudes es el proceso de gestionar una solicitud de servicio durante su
ciclo de vida. Esto incluye el registro, el enrutamiento, el control y la entrega del servicio
solicitado.
La gestión de solicitudes implica establecer un proceso de cumplimiento de solicitudes
que pretende:
■
Canalizar la solicitud del usuario para servicios estándares que tienen un proceso de
aprobación predefinido.
■
Crear y proporcionar los componentes de los servicios estándares solicitados (p. ej.,
licencias y medios de software).
■
Ayudar con la información general, por ejemplo, los servicios de disponibilidad y el
procedimiento para obtenerlos y la gestión de las quejas o los comentarios de los
usuarios.
Todos los tickets registrados por los usuarios finales en los que no se haya utilizado una
plantilla dan lugar a una solicitud de servicio nueva. Las solicitudes por correo
electrónico de los usuarios (a menos que se configuren específicamente para otra cosa)
también dan lugar a la creación de una solicitud de servicio.
Capítulo 3: Workflow de gestión de solicitudes 27
Descripción general de la gestión de solicitudes
En función de la naturaleza de la solicitud, una solicitud de servicio se puede gestionar
según el workflow de gestión de solicitudes o un ticket de cambio, problema o incidente
puede haberse registrado desde la solicitud de servicio inicial y procesarse según el
procedimiento pertinente para el ticket.
Proceso de workflow de solicitud de servicio
Las solicitudes de servicio normalmente pasan por tres fases desde su creación hasta el
cierre: aceptación, cumplimiento y cierre. En función de la fuente del ticket, se podría
prescindir de la fase de aceptación y el ticket pasaría directamente a la fase de
cumplimiento.
En el siguiente diagrama, se muestra el progreso de una solicitud de servicio:
Registros relacionados con las solicitudes de servicio
Las acciones de workflow, enrutamiento automático y plantillas que forman parte de
este diseño de workflow aparecen en las siguientes secciones.
La configuración de workflow lista para usar incluye registros de configuración clave que
facilitan el diseño de workflow y permiten al ticket avanzar por dicho diseño de
workflow.
Los siguientes registros de configuración de workflow forman parte del diseño de
workflow de gestión de solicitudes.
Plantillas de ticket de solicitud de servicio
No hay plantillas de ticket para las solicitudes de servicio que estén disponibles y listas
para usar.
Se pueden configurar plantillas para solicitudes relacionadas con sistemas o servicios
que los usuarios suelan solicitar con frecuencia en su organización y ponerlas a
disposición de los usuarios finales que corresponda.
Plantillas de comunicación de solicitud de servicio
Las siguientes plantillas de comunicación relacionadas con las solicitudes de servicio
están disponibles como parte de las configuraciones de workflow listas para usar:
Nombre de
plantilla
Enviar a
Finalidad
Solicitud de
${tr.assigned_to_group_nam Indica al grupo de soporte que se le ha asignado un ticket.
servicio_Asignar_g e}
rupo
Solicitud del
${tr.person1_alt_email}
servicio_Pendiente
_cliente
Indica al solicitante que el ticket se ha configurado como
pendiente de información por parte del solicitante y le indica
que proporcione la información en cuestión.
Solicitud del
servicio_Cambiar
Indica al solicitante que, para facilitar la aprobación de la
solicitud, se ha creado una solicitud de cambio a partir de la
solicitud de servicio.
Solicitud de
servicio_Cancelada
Indica al solicitante que la solicitud de servicio se ha
cancelado.
Solicitud de
${tr.assigned_to_individual_ Indica a una persona que se le ha asignado un ticket mediante
servicio_Asignació name}
la opción de acción Asignar al individuo.
n_individuo
Solicitud del
servicio_Aceptar
Indica al solicitante que un agente de Service Desk ha
aceptado la asignación de solicitud de servicio.
Solicitud de
servicio correcta
completado correctamente.
Solicitud de
servicio_Errónea
Indica al solicitante que la solicitud de servicio no se ha
Solicitud de
servicio_Cierre
erróneo
Indica al solicitante que se va a proceder al cierre de la
solicitud de servicio que ha tenido un cumplimiento erróneo.
Solicitud de
servicio_Volver a
abrir
reabierto.
Solicitud de
servicio_Reconoce
r
Indica al solicitante que la solicitud de servicio se ha creado
tal y como se ha solicitado.
Aviso de tarea
completada
${assigned_to_individual_na Indica al usuario asignado que el ticket de la tarea relacionada
me}
se ha completado correctamente.
Aviso de tarea
fallida
${assigned_to_individual_na Indica al usuario asignado que una tarea relacionada no se ha
me}
Las plantillas de comunicación están relacionadas con enrutamientos automáticos y
acciones de workflow y permiten informar a los interesados sobre la ejecución de una
acción en el ticket.
Además de estas plantillas que se crean como parte del diseño de workflow listo para
usar, encontrará también varias plantillas de comunicación definidas por el sistema que
se pueden asociar con notificaciones sobre el acuerdo de nivel de servicio, los
enrutamientos automáticos y las acciones de workflow.
Enrutamientos automáticos de las solicitudes de servicio
En las configuraciones de workflow listas para usar, se han configurado enrutamientos
automáticos para aplicarlos a los tickets en función de su fuente.
En la siguiente tabla encontrará una lista de los enrutamientos automáticos
configurados y disponibles listos para usar en las solicitudes de servicio.
Nombre del
enrutamiento
automático
Orden
Condiciones
coincidentes
Enrutamiento
automático de
solicitud de servicio
(correo electrónico)
950
(Fuente = Correo ■
electrónico)
Enrutamiento
automático de
(Web)
Enrutamiento
automático de
(agente)
950
950
(Fuente = Web)
NO (Fuente =
Web)
Y
NO (Fuente =
Correo
electrónico)
Establecer campos y Establecer
valores de campos
Comunicación
relacionada
assigned_group_id =
Service Desk (L1)
Solicitud de
servicio_Asignar_grupo
■
Fase = Aceptación
Solicitud de
servicio_Reconocer
■
Código de motivo = Solicitud
de servicio de correo
electrónico
■
Estado = Nuevo
■
Prioridad = Media
■
assigned_group_id =
Service Desk (L1)
Solicitud de
servicio_Asignar_grupo
■
Fase = Aceptación
Solicitud de
servicio_Reconocer
■
Código de motivo = Solicitud
de servicio Web
■
Estado = Nuevo
■
Fase = Cumplimiento
■
Código de motivo = En curso
■
Estado = Activo
Solicitud del
servicio_Aceptar
Dado que las solicitudes de servicio las inicia normalmente el usuario final, es necesario
informar al solicitante sobre la creación del ticket y su asignación. Por consiguiente, la
mayoría de los enrutamientos automáticos para las solicitudes de servicio tienen una
plantilla de comunicación asociada.
Cuando se aplica un enrutamiento automático, se informa al solicitante sobre la
creación del ticket y al grupo de soporte asignado se le informa sobre la asignación del
ticket. Esto garantiza que la comunicación sobre el ticket se envía a los interesados
principales.
Opciones de acción del workflow para las solicitudes de servicio
Las opciones de acción son acciones de workflow que facilitan el avance del ticket por
un proceso de workflow definido. Las opciones de acción que están disponibles en un
ticket dependen de las condiciones de coincidencia, por ejemplo, el Estado, el Código de
motivo, la Fase, etc. y se pueden utilizar para controlar el progreso del ticket a través de
su ciclo de vida.
Las opciones de acción se pueden configurar para controlar acciones como la imposición
de valores de campos obligatorios al ejecutar la opción de acción. La definición de
valores de campo al realizar la ejecución y la activación de notificaciones automáticas al
ejecutar la acción. Las opciones de acción pueden tener también asociadas funciones
especiales, como Enviar para la aprobación, lo que permite automatizar aún más las
acciones asociadas.
En la siguiente tabla, encontrará las opciones de acción que están disponibles con las
configuraciones de workflow listas para usar.
Nombre de la
opción de
acción
Función especial
Tomar
Aceptar
propiedad de la asignación
nueva solicitud
Tomar
propiedad
Aceptar
asignación
Condiciones
coincidentes
Establecer campos y
Establecer valores de
campos
Campos
obligatorios
Comunicación
(Estado = Nuevo)
■
Fase =
Cumplimiento
Ninguno
■
Código de motivo =
En curso
Solicitud del
servicio_Acept
ar
■
Estado = Activo
■
Código de motivo = Ninguno
En curso
■
Estado = Activo
Y
(Fase =
Aceptación)
NO (Estado =
Resuelto, Estado
= Cerrado o
Estado = Nuevo)
Ninguno
Reasignar al
grupo
Reasignar al
individuo
Asignar al grupo
Asignar al
individuo
Reasignar en Mi Asignar al
grupo
individuo
Configurar
distribuidor
pendiente
Ninguno
Configurar el
cliente
pendiente
Ninguno
(Estado = Activo)
(Estado = Activo)
(Estado = Activo)
(Estado = Activo)
(Estado = Activo)
(Estado =
Pendiente)
■
Asignación
■
Estado = En cola
■
Asignación
■
Estado = En cola
■
Asignación
■
Estado = En cola
■
Suministrador
■
Estado = Pendiente
■
Descripción
Visible por el
del registro
cliente
(Work_View_Type) de trabajo
= Sí
■
Código de motivo =
Cliente
■
Estado = Pendiente
■
Work_Type = Nota
del cliente
■
Reanudado
■
Estado = Activo
Solicitud de
servicio_Asign
ar_grupo
Solicitud de
servicio_Asign
ación_individu
o
Solicitud de
servicio_Asign
ación_individu
o
Ninguno
Solicitud del
servicio_Pendi
ente_cliente
Reanudar
solicitud
pendiente
Ninguno
Ninguno
Crear solicitud
de cambio
vinculada
Crear cambio
(Estado = Activo)
■
Cambio vinculado
creado
Ninguno
Convertir
solicitud de
servicio en
incidente
Crear incidente
(Estado = Activo)
■
Fase = Cierre
Ninguno
Ninguno
■
Código de motivo =
Incidente creado
■
Estado = Cerrado
Convertir
solicitud de
servicio en
solicitud de
cambio
Completado
como correcto
Crear cambio
Ninguno
(Estado = Activo)
Fase = Cierre
■
Código de motivo =
La solicitud de
cambio se ha
creado
correctamente
■
Estado = Cerrado
■
Asignado al grupo = Ninguno
Service Desk (L1)
■
Cumplimiento
erróneo = No
■
Fase = Cierre
■
Código de motivo =
Cumplido
■
Estado = Resuelto
■
Días para el cierre
automático = 5
■
Cumplimiento
erróneo = Sí
■
Fase = Cierre
■
Código de motivo =
Cumplimiento
erróneo
■
Estado = Cerrado
NOT
■
Fase = Cierre
(Estado =
Resuelto) O BIEN
■
(Estado =
Cerrado)
Código de motivo =
Cancelado
■
Estado = Cerrado
(Estado =
Cerrado) O BIEN
■
Fase =
Cumplimiento
(Estado =
Resuelto)
■
Código de motivo =
Reabrir
■
Estado = Activo
■
Ninguno
(Estado = Activo)
Y
(Fase =
Cumplimiento)
Fallo de
cumplimiento
Ninguno
(Estado = Activo)
Y
(Fase =
Cumplimiento)
Cancelar y
cerrar solicitud
de servicio
Ninguno
Reabrir y tomar Aceptar
propiedad
asignación
Suprimir
Ninguno
solicitud de
servicio
(administrador)
Ninguno
■
Ninguno
Ninguno
Solicitud de
servicio
correcta
Ninguno
Solicitud de
servicio
errónea
Ninguno
Ninguno
Ninguno
Solicitud de
servicio_Volver
a abrir
Ninguno
Ninguno
Nota: Las acciones de workflow como Reasignar en Mi grupo se pueden usar para
gestionar colas de tickets y distribuir la carga de trabajo entre los miembros de un grupo
de soporte. Como no hay que comunicar al solicitante las acciones de este tipo, la
notificación sobre la asignación del ticket se envía solamente al individuo asignado.
incidentes
Las incidencias que registran los usuarios (o las interfaces automatizadas) sobre un
sistema existente o las posibles incidencias que pudieran repercutir en el servicio se
registran como tickets de incidente. La gestión de incidentes se ocupa de la gestión y el
procesamiento de los tickets de incidente para garantizar la resolución de la incidencia
con un impacto mínimo para el usuario.
En esta sección se proporciona información acerca del proceso de gestión de incidentes
y el diseño de workflow listo para usar para gestionar los tickets de incidente.
Descripción general de la gestión de incidentes (en la página 39)
Ciclo de vida de los tickets de incidente (en la página 41)
Registros relacionados con los tickets de incidente (en la página 43)
Descripción general de la gestión de incidentes
ITIL define un incidente como cualquier evento que no forma parte de la operación
estándar del servicio y que causa o puede causar una interrupción o una reducción en la
calidad del servicio. Un incidente puede deberse a una incidencia conocida o existente,
o ser resultado de un fallo en el dispositivo u objeto de TI.
El objetivo de la gestión de incidentes es restaurar las operaciones normales con la
mayor brevedad y con el menor impacto posible en el negocio o en el usuario a un
precio que resulte rentable y con unos niveles de servicio definidos. La gestión de
incidentes no intenta identificar la causa raíz del incidente, sino que su misión es lograr
que se reanuden las operaciones normales teniendo en cuenta los acuerdos de nivel de
servicio consensuados.
El proceso de registro y detección de un incidente, la clasificación y el soporte inicial, la
investigación y el diagnóstico, la resolución, la recuperación y el cierre final del incidente
forman parte del proceso de gestión de incidentes.
El proceso de gestión de incidentes implica establecer un proceso de restauración del
servicio cuyos objetivos son:
■
Canalizar los informes de los usuarios acerca de interrupciones en un servicio o la
disminución de su calidad.
■
Posibilitar la validación y el diagnóstico de los incidente registrados.
Capítulo 4: Workflow de gestión de incidentes 39
Descripción general de la gestión de incidentes
■
Gestionar el proceso que garantice la resolución de los incidentes y la restauración
del servicio.
■
Monitorizar la conformidad con los acuerdos de nivel de servicio definidos para
restaurar los servicios y su disponibilidad.
Ciclo de vida de los tickets de incidente
Los tickets de incidente normalmente pasan por cuatro fases desde su creación hasta el
cierre: aceptación, diagnóstico, investigación y cierre. En función de la fuente del ticket,
se podría prescindir de la fase de aceptación y el ticket pasaría directamente a la fase de
diagnóstico.
En el siguiente diagrama se muestra el progreso de los tickets de incidente:
Registros relacionados con los tickets de incidente
workflow.
Los siguientes registros de configuración de workflow forman parte del diseño de
workflow de gestión de incidentes.
Plantillas de ticket de incidente
Las siguientes plantillas de ticket se ofrecen como parte de las configuraciones listas
para usar de la gestión de incidentes:
Nombre de
plantilla
Categorí Description (Descripción)
a
Establecimiento de
campos
Permiso
Informe e
interrupción
General
■
Administración (grupo
de soporte)
Autoservicio: informar sobre una
interrupción a Service Desk
Fuente = Web
Autoservicio
predeterminado (rol)
Nota: La casilla de verificación Anular el enrutamiento automático está sin marcar en la
plantilla de ticket. Se aplicará un enrutamiento automático al ticket creado mediante
esta plantilla y se asignará a un grupo de soporte adecuado.
Cuando se aplica el enrutamiento automático, los otros campos (por ejemplo, Asignado
al grupo, Estado, Código de motivo y Fase) se definirán tal y como se hayan configurado
en los enrutamientos automáticos.
Plantillas de comunicación de incidentes
Las siguientes plantillas de comunicación están disponibles como parte de las
configuraciones de workflow de gestión de incidentes listas para usar:
Nombre de plantilla
Enviar a
Finalidad
Asignación individual ${tr.assigned_to_individual_ Indica a una persona que se le ha asignado un ticket
del
name}
mediante la acción del workflow Asignar al individuo.
incidente/problema
Asignación de grupo
del
incidente/problema
${tr.assigned_to_group_nam Indica al grupo de soporte que se le ha asignado un ticket
e}
mediante la acción del workflow Asignar al grupo.
Enrutamiento
automático del
incidente (Web)
Indica al solicitante que el ticket de incidente se ha
registrado y se ha asignado a una cola de grupo de soporte.
Incidente aceptado
Indica al solicitante que la asignación del incidente se ha
aceptado y se está trabajando en él.
Incidente resuelto
Indica al solicitante que el incidente se ha resuelto.
Incidente reabierto
reabierto.
Cliente pendiente del ${tr.person1_alt_email}
incidente
Indica al solicitante que el incidente se ha establecido
como pendiente y que requiere información adicional por
parte del solicitante.
Incidente grave
Service Desk (L1)
Indica a los grupos de soporte de Service Desk que un
incidente se ha catalogado como Principal.
Incidente cancelado
${person1_alt_email}
cancelado.
Aviso de tarea
completada
${assigned_to_individual_na Indica al usuario asignado que el ticket de la tarea
me}
relacionada se ha completado correctamente.
Aviso de tarea fallida ${assigned_to_individual_na Indica al usuario asignado que una tarea relacionada no se
me}
ha completado correctamente.
Las plantillas de comunicación están relacionadas con enrutamientos automáticos y
acciones de workflow y permiten informar a los interesados sobre la ejecución de una
acción en el ticket.
Enrutamiento automático de incidentes
automáticos para aplicarlos a los tickets en función de su fuente.
En la siguiente tabla encontrará una lista de los enrutamientos automáticos
configurados y disponibles listos para usar en los tickets de incidente.
Nombre del
enrutamiento
automático
Orden
Condiciones
coincidentes
Establecer campos y
Establecer valores de campos
Comunicación
relacionada
Enrutamiento
automático
predeterminado para
incidentes
950
(Fuente = Web)
■
assigned_group_id =
Service Desk (L1)
■
Fase = Aceptación
Enrutamiento
automático de
incidentes a través de
Web
■
Código de motivo =
Incidente creado
■
Estado = Nuevo
■
Fase = Diagnóstico
■
Código de motivo = En
curso
■
Estado = Activo
Agente
predeterminado para
incidentes
950
NO (Fuente =
Web)
Ninguno
Nota: Cuando los usuarios finales crean el ticket, se aplica un enrutamiento automático
en función de la fuente del ticket y se informa al solicitante sobre la creación del ticket.
A continuación, el ticket pasa a la fase Aceptación.
Sin embargo, si un analista que trabaja en el ticket registra un incidente, la fase
Aceptación se omite y el ticket pasa directamente a la fase Diagnóstico. El workflow listo
para usar está diseñado de esta forma porque se supone que, si un analista registra un
ticket, se trata de un incidente válido que Service Desk ha aceptado y que se puede
trabajar en el diagnóstico y la resolución del incidente.
Opciones de acción del workflow para incidentes
Son las acciones de workflow disponibles para los tickets de incidente para parte del
diseño de workflow de gestión de incidentes.
configuraciones de workflow listas para usar para la gestión de incidentes.
Nombre de la Función especial Condiciones
opción de
coincidentes
acción
Establecer campos y
campos
Campos Comunicación
obligator
ios
Aceptar nuevo Aceptar
incidente
asignación
■
Fase = Diagnóstico
Ninguno
■
Código de motivo =
En curso
■
Estatus = Activo
(Estatus = Nuevo)
Incidente
aceptado
Tomar
propiedad
Reasignar al
grupo
Reasignar al
individuo
Reasignar en
Mi grupo
Aceptar
asignación
NO (Estatus =
Resuelto, Estatus =
Cerrado o Estatus =
Nuevo)
Asignar al grupo (Estatus = Activo)
Asignar al
individuo
Asignar al
individuo
Configurar
distribuidor
pendiente
Ninguno
Configurar el
cliente
pendiente
Ninguno
(Estatus = Activo)
(Estatus = Activo)
(Estatus = Activo)
(Estatus = Activo)
Asignación de
grupo del
incidente/problem
a
Ninguno
Asignación
individual del
incidente/problem
a
Ninguno
Asignación
individual del
incidente/problem
a
Ninguno
Ninguno
Estatus = Activo
■
Código de motivo =
Asignación
■
Estatus = En cola
■
Código de motivo =
Asignación
■
Estatus = En cola
■
Código de motivo =
Asignación
■
Estatus = En cola
■
Código de motivo =
Suministrador
■
Estatus = Pendiente
■
Descripci Incidente
Tipo de trabajo
pendiente del
visible por el cliente ón del
registro
cliente
= Sí
de
Código de motivo = trabajo
Cliente
Estatus = Pendiente
■
Tipo de trabajo =
Nota del cliente
■
Código de motivo =
En curso
■
Estatus = Activo
■
Fase = Investigación Ninguno
■
Código de motivo =
Asignación
■
Estatus = En cola
(Estatus = Activo)
■
Problema vinculado
creado
Ninguno
(Estatus = Activo)
■
Código de motivo =
Cambio vinculado
creado
Ninguno
Ninguno
Ninguno
Asignar para
la
investigación
Asignar al grupo (Estatus = Activo)
(Estatus =
Pendiente)
Y
(Fase = Diagnóstico)
Crear solicitud Crear cambio
de cambio
vinculada
Ninguno
■
■
Reanudar
solicitud
pendiente
Crear problema
Ninguno
Código de motivo =
En curso
■
Crear ticket
del problema
vinculado
Ninguno
■
Ninguno
Ninguno
Asignación de
grupo del
incidente/problem
a
Crear
incidente
vinculado
Crear incidente
(Estatus = Activo)
■
Código de motivo =
Incidente vinculado
creado
Ninguno
Ninguno
Convertir
incidente en
solicitud de
servicio
Crear solicitud
de servicio
(Estatus = Activo)
■
Fase = Cierre
Ninguno
Ninguno
■
Código de motivo =
La solicitud de
servicio se ha
creado
correctamente
■
Estatus = Cerrado
■
Fase = Cierre
Ninguno
Ninguno
■
Código de motivo =
La solicitud de
cambio se ha creado
correctamente
■
Estatus = Cerrado
■
Asignado al grupo =
Service Desk (L1)
Ninguno
Incidente resuelto
■
Fase = Cierre
■
Código de motivo =
A la espera del
cierre
■
Estatus = Resuelto
■
automático = 5
■
Ninguno
Ninguno
Y
Asignado al grupo =
Service Desk (L1)
(Fase = Diagnóstico) ■
Fase = Cierre
Convertir
incidente en
solicitud de
cambio
Resolver
incidente
Crear cambio
Ninguno
(Estatus = Activo)
(Estatus = Activo)
Y
(Fase =
Investigación)
Resolver a la
primera
llamada
Ninguno
(Estatus = Activo)
■
Código de motivo =
Resolución en la
primera llamada
■
Estatus = Resuelto
■
automático = 5
Declaración
de incidentes
importantes
Incidente
importante
resuelto
Ninguno
(Estatus = Activo)
■
Fase = Incidente
principal
■
Código de motivo =
Incidente principal
■
Severidad =
Principal
■
Estatus = Activo
■
Fase = Cierre
■
Código de motivo =
Resolución del
incidente grave
■
Estatus = Resuelto
■
automático = 5
Y
(Fase = Diagnóstico
o Investigación)
Ninguno
Ninguno
Ninguno
Incidente principal
Ninguno
Incidente resuelto
Cerrar
incidente
resuelto
Ninguno
(Estatus = Resuelto) ■
Estatus = Cerrado
Ninguno
Ninguno
Eliminar del
incidente
grave
Ninguno
(Fase = Incidente
principal)
■
Ninguno
Cancelar y
cerrar
incidente
Ninguno
NO (Estatus =
Resuelto) O BIEN
(Estatus = Cerrado)
■
Fase = Cierre
■
Código de motivo =
Cancelado
■
Estatus = Cerrado
Reabrir
incidente
resuelto
Reabrir
incidente
cerrado
Aceptar
asignación
Aceptar
asignación
Suprimir
Ninguno
(administrado
r)
(Estatus = Resuelto) ■
(Estatus = Cerrado)
Ninguno
Ninguno
Incidente
cancelado
Incidente
reabierto
■
Código de motivo =
Reabrir
■
Estatus = Activo
■
■
Código de motivo =
Reabrir
■
Estatus = Activo
■
Ninguno
Ninguno
Incidente
reabierto
Ninguno
El diseño de workflow de gestión de incidentes tiene dos opciones de acción que son
específicas para los incidentes:
■
Resolver a la primera llamada: esta acción del workflow está concebida como un
medio para evaluar las incidencias que gestiona el soporte de nivel 1 directamente,
sin ayuda de otros grupos de soporte. Analizar estos datos ayuda a mejorar la
eficacia del equipo de nivel 1, ya que se crean más artículos de conocimiento que se
pueden utilizar para aplicarlos a incidentes habituales.
■
Informar sobre un incidente grave: esta acción del workflow está diseñada para
realizar un seguimiento del número de incidencias graves detectadas. Si es
necesario, se puede crear un ticket de problema basado en el incidente grave para
resolver la causa raíz de dicho incidente.
problemas
Un problema es la causa desconocida de uno o varios incidentes. A menudo se identifica
como un resultado de varios incidentes registrados por numerosos usuarios.
Normalmente, un problema se comunica cuando un incidente es tan grave que un
elemento de configuración podría producir un fallo o cuando la disponibilidad del
servicio se ve gravemente afectada.
En esta sección se proporciona información acerca del proceso de gestión de problemas
y el diseño de workflow listo para usar para gestionar los tickets de problema.
Descripción general de la gestión de problemas (en la página 51)
Ciclo de vida de los tickets de problema (en la página 53)
Registros relacionados con los tickets de problema (en la página 55)
Descripción general de la gestión de problemas
La gestión de problemas trata de determinar y eliminar la causa raíz de la incidencia
para que esta no se vuelva a repetir. Por lo general, los tickets de problema se registran
antes de que se produzca un fallo crítico, para identificar la causa raíz de los incidentes y
evitar que se produzca un fallo. También se pueden registrar tickets de problema para
revisar un fallo y adoptar medidas correctivas o para prevenir de forma proactiva
posibles interrupciones en los servicios críticos.
El objetivo de la gestión de problemas es minimizar los impactos adversos de los
incidentes o problemas que causan los errores en la infraestructura de TI, así como
iniciar acciones para evitar que se repitan los incidentes relacionados con esos errores.
La gestión de problemas trata de descubrir y resolver la causa raíz de los incidentes que
dieron lugar a la creación del ticket de problema.
El objetivo de la gestión de problemas es resolver las incidencias de forma que no se
repitan en el futuro y minimizar su impacto, en caso de que el incidente no se pueda
prevenir totalmente. Se pretende analizar la causa para llegar a la raíz del problema e
identificar la forma de resolverlo. En caso de que la resolución del problema necesite un
cambio, se registrará un ticket de cambio para implementarlo antes de resolver el ticket
de problema.
Capítulo 5: Workflow de gestión de problemas 51
Descripción general de la gestión de problemas
El proceso de gestión de problemas implica el establecimiento de un proceso de análisis
de la causa raíz que pretende:
■
Categorizar los informes de los problemas existentes o potenciales de un servicio o
un dispositivo.
■
Activar el diagnóstico del problema registrado.
■
Gestionar el proceso de forma que se pueda controlar el error y controlar las
interrupciones existentes o potenciales, con objeto de llegar al cierre del problema.
Ciclo de vida de los tickets de problema
Los tickets de problema normalmente pasan por cuatro fases desde la creación hasta el
cierre: categorización, diagnóstico, control de errores y cierre. Todos los tickets de
gestión de problemas, con independencia de su fuente, se inician en la fase de
categorización y, a continuación, se trabaja en ellos para cerrarlos según proceda.
En el siguiente diagrama se muestra el progreso de los tickets de problema:
Registros relacionados con los tickets de problema
workflow.
Los tickets de tarea y las plantillas de ticket de tarea se incluyen como parte del diseño
de workflow de gestión de problemas. Los siguientes registros de configuración de
workflow forman parte del diseño de workflow de gestión de problemas.
Plantillas de ticket de problema
Las siguientes plantillas de ticket se ofrecen como parte de las configuraciones listas
para usar de la gestión de problemas:
Nombre de
plantilla
Categoría Descripción
Establecimiento de campos
Permiso
Informe del
problema
(agente)
General
■
Código de motivo = Informe del
problema
de soporte)
■
Descripción del síntoma =
Escriba una descripción del
problema.
■
Detalles del síntoma =
Especifique los detalles del
problema.
Problema
proactivo
(agente)
General
Asigna un ticket al
grupo de gestión de
problemas para su
revisión.
Registra un problema ■
y lo asigna al
generador de
■
informes.
Código de motivo = Problema
proactivo
Detalles del síntoma = Para un
problema proactivo, cree una
descripción y asigne una clase.
Sustituya estos detalles por una
descripción detallada del
problema.
Gestión de problemas
(rol)
de soporte)
(rol)
Informar de
un error
conocido
Problema Resolver
tickets
relacionados
(ticket de
tarea)
General
Plantilla para dirigir la ■
creación de un error
conocido
Código de motivo = Error
conocido
de soporte)
■
Estado = Nuevo
(rol)
■
Detalles del síntoma = Para un
error conocido, cree una
descripción y asigne una clase,
una causa y una resolución.
Sustituya estos detalles por una
descripción detallada del
problema.
Problema Tarea de gestión de
■
problemas
estándares: antes del ■
cierre, asegúrese de
■
que todos los tickets
relacionados se hayan
resuelto
satisfactoriamente.
Problema Problema Tarea estándar de
Revisar
gestión de problemas,
artículos de
antes del cierre
conocimiento
asegúrese de que
todo el conocimiento
(Ticket de la
relacionado se revisa
tarea)
y/o se retira.
Código de motivo = Ejecución
Estado = En cola
de soporte)
Descripción de tareas = Busque (rol)
los tickets relacionados con este
problema y resuélvalos antes de
cerrar este ticket de problema.
■
Nombre de la tarea = Resolver
tickets relacionados
■
ID del grupo asignado = Gestión
de problemas
de soporte)
■
Código de motivo = Ejecución
(rol)
■
Estado = En cola
■
Descripción de tareas = Revise el
conocimiento relacionado con
este problema antes del cierre.
Cambie el estado o retire los
artículos, según sea necesario.
■
Nombre de la tarea = Revisión
de conocimientos
Nota: Preste atención a lo siguiente:
■
La casilla de verificación Anular el enrutamiento automático está sin marcar en la
plantilla de ticket. Se aplicará un enrutamiento automático al ticket creado
mediante esta plantilla y se asignará a un grupo de soporte adecuado.
■
Hay dos tickets de tarea (Problema - Resolver tickets relacionados y Problema Revisar artículos de conocimiento) que forman un grupo de tareas relacionado con
los tickets de problema. Se trata de plantillas de muestra y no están directamente
vinculadas al workflow de gestión de problemas listo para usar. El workflow se
puede modificar para incluir estas tareas en la resolución de problemas y el cierre
del proceso.
Plantillas de comunicación de problemas
configuraciones de workflow de gestión de problemas listas para usar:
Nombre de
plantilla
Enviar a
Finalidad
Asignación
individual del
incidente/problem
a
${tr.assigned_to_individual_
name}
Indica a una persona que se le ha asignado un ticket
mediante la acción del workflow Asignar al individuo.
Asignación de
grupo del
incidente/problem
a
${tr.assigned_to_group_nam Indica al grupo de soporte que se le ha asignado un ticket
e}
Cliente pendiente
del problema
Indica al solicitante que el ticket de problema está a la
espera de información del cliente.
Aviso de tarea
completada
${assigned_to_individual_na
me}
Indica al usuario asignado que el ticket de la tarea
relacionada se ha completado correctamente.
Aviso de tarea
fallida
${assigned_to_individual_na
me}
Indica al usuario asignado que una tarea relacionada no se
ha completado correctamente.
Enrutamientos automáticos de problemas
automáticos para aplicarlos a los tickets en función de su fuente. En la siguiente tabla
encontrará una lista de los enrutamientos automáticos configurados y disponibles listos
para usar en los tickets de problema.
Nombre del
enrutamiento
automático
Orden
Valor predeterminado
del problema
950
Condiciones
coincidentes
Establecer campos y Establecer Comunicación
valores de campos
relacionada
Ninguno
■
assigned_group_id =
N
i
Fase
n = Categorización
g
Código de motivo =
u
Valoración
n
Estatus
= En cola
o
■
Fase = Categorización
Ninguno
■
Código de motivo =
Problema proactivo
■
Estatus = En cola
■
assigned_group_id =
■
Fase = Categorización
■
Código de motivo = Errores
conocidos
■
Estatus = En cola
■
assigned_group_id =
■
■
■
Problema proactivo
Errores conocidos
900
950
Código de motivo
= Problema
proactivo
Código de motivo
= Errores
conocidos
Ninguno
Nota: En el diseño de workflow listo para usar, se considera que los tickets de problema
se registrarán y gestionarán mediante el rol Gestión de problemas y que los tickets de
problema se registrarán usando plantillas de ticket listas para usar. Como el ticket se
registra mediante el rol Gestión de solicitudes, no hay ninguna plantilla de comunicación
relacionada con los enrutamientos automáticos para informar a los solicitantes sobre la
creación de tickets ni sobre la acción de asignación.
Opciones de acción del workflow para problemas
configuraciones de workflow listas para los tickets de problema.
Nombre de la
opción de
acción
Función
especial
Condiciones
coincidentes
Tomar
propiedad
Aceptar
asignación
NO (Estado =
■
Resuelto, Estado =
Cerrado o Estado =
■
Nuevo)
En curso
(Estado = Activo)
■
En curso
■
Estado = En cola
■
En curso
■
Estado = En cola
■
En curso
■
Estado = En cola
■
Información
■
Estado = Pendiente
■
Visible por el
cliente = Sí
■
Código de motivo =
Cliente
■
Estado = Pendiente
■
Tipo de trabajo =
Nota del cliente
■
En curso
■
Estado = Activo
Reasignar al
grupo
Reasignar al
individuo
Reasignar en
Mi grupo
Asignar al
grupo
Asignar al
individuo
Reasignar en
grupo
Configurar
información
pendiente
Ninguno
Configurar el
cliente
pendiente
Ninguno
Reanudar
trabajo en
ticket
pendiente
Ninguno
(Estado = Activo)
(Estado = Activo)
(Estado = Activo)
(Estado = Activo)
(Estado =
Pendiente)
Establecer campos y
campos
Campos
obligatorios
Comunicación
Ninguno
Estado = Activo
Descripción
del registro
de trabajo
Asignación de
grupo del
incidente/probl
ema
Asignación
individual del
incidente/probl
ema
Asignación
individual del
incidente/probl
ema
Ninguno
Cliente
pendiente del
problema
Ninguno
Asignar para el
diagnóstico
(autoservicio)
(Estado = Activo)
A
Y
c
(Fase = e
Categorización)
p
t
a
r
CCTI_Class
Ninguno
CCTI_Class
Asignación de
grupo del
incidente/probl
ema
CCTI_Class
Asignación
individual del
incidente/probl
ema
Ninguno
Ninguno
■
Código de motivo =
En curso
■
Esperando el
cambio
Ninguno
■
Estado = Pendiente
■
Fase = Diagnóstico
■
Código de motivo =
En curso
■
Fase = Diagnóstico
■
Código de motivo =
Asignación
■
Estado = En cola
■
Fase = Diagnóstico
■
Código de motivo =
Asignación
■
Estado = En cola
■
Fase = Control de
errores
(Fase =
Diagnóstico)
(Estado = Activo)
a
s
i
g
n
a
c
i
ó
n
Asignar para el
diagnóstico
(grupo)
Asignar para el
diagnóstico
(individual)
Promover a
error conocido
Esperando el
cambio
Asignar al
grupo
(Estado = Activo)
Y
(Fase =
Categorización)
Asignar al
individuo
(Estado = Activo)
Y
(Fase =
Categorización)
Ninguno
(Estado = Activo)
Y
Ninguno
Y
(Fase = Control de
errores)
Y
NO (Código de
motivo =
Esperando el
cambio)
Crear solicitud
de cambio
vinculada
Crear cambio
Cierre del
problema
Ninguno
(Estado = Activo)
Reabrir
problema
Esperando un
cambio vinculado
Ninguno
■
Fase = Cierre
Ninguno
Ninguno
■
Código de motivo =
Cerrado
■
Estado = Cerrado
■
Fase = Cierre
Ninguno
Ninguno
■
Código de motivo =
Cancelado
■
Estado = Cerrado
■
Fase = Diagnóstico
Ninguno
Ninguno
■
Código de motivo =
En curso
■
Estado = Activo
■
Ninguno
Ninguno
Ninguno
Y
(Fase = Control de
errores)
(Estado = Activo)
Y
Fase = Control de
errores
Cancelar y
cerrar
problema
■
Ninguno
Aceptar
asignación
Suprimir
Ninguno
(administrador)
NO (Estado =
Resuelto O BIEN
Estado = Cerrado)
(Estado = Cerrado)
Ninguno
Nota: Las configuraciones de workflow listas para usar para los tickets de problema no
tienen una acción de workflow específica para crear o gestionar las tareas relacionadas
con la gestión de problemas ni tampoco acciones relacionadas con la resolución de
problemas.
Se recomienda configurar una acción del workflow para los tickets de resolución de
problemas. Con esta acción de workflow, se puede asociar una función especial
denominada Crear tareas automáticamente para crear tareas que implementen la
resolución y garanticen que todos los tickets relacionados con la tarea se hayan cerrado
y que todos los artículos de conocimiento se hayan actualizado antes de resolver el
ticket de problema.
Capítulo 6: Workflow de gestión de cambios
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).
En esta sección se proporciona información acerca del proceso de gestión de cambios y
el diseño de workflow listo para usar para gestionar las solicitudes de servicio.
Descripción general de la gestión de cambios (en la página 63)
Ciclo de vida de una solicitud de cambio (en la página 64)
Registros relacionados con la gestión de cambios (en la página 77)
Descripción general de la gestión de cambios
La gestión de cambios es el proceso de gestionar un ticket de cambio durante su ciclo de
vida. Esto incluye la configuración de procesos para la clasificación del tipo de cambio, la
aprobación y revisión de un cambio (incluido un proceso de aprobación de varios niveles
donde proceda), la implementación de un cambio y el cierre de la solicitud de cambio.
El objetivo de la gestión de cambios es garantizar que se utilizan los procedimientos y
los métodos normalizados para el tratamiento eficaz e inmediato de todos los cambios.
Las tecnologías están cambiando a un ritmo muy rápido y es necesario que las ofertas
de servicios de TI se adapten a estos cambios. Si los cambios no están bien planificados,
se pueden generar problemas. Por lo tanto, es necesario un enfoque gestionado y
controlado adecuadamente en relación con el cambio en los servicios y sistemas de TI.
La gestión de cambios pretende minimizar todas interrupciones no deseadas en el
servicio de TI existente provocadas por la implementación de los cambios. Para ello, se
configuran grupos de aprobación adecuados compuestos por individuos que pueden
ofrecer argumentos sobre un cambio y decidir si se debe proceder con él o no. Este
proceso se facilita con la configuración de acciones de workflow que garantizan que,
una vez aprobado, el ticket de cambio pasará por las fases relevantes de
implementación y revisión posterior a la implementación.
Capítulo 6: Workflow de gestión de cambios 63
Ciclo de vida de una solicitud de cambio
La gestión de cambios implica la configuración de un proceso para gestionar con
eficiencia los cambios. Sus objetivos son los siguientes:
■
El cambio se debe clasificar mediante un tipo de cambio adecuado y se debe
procesar mediante un workflow para ese tipo de cambio.
■
El cambio se debe tramitar mediante un proceso de aprobación de cambios
adecuado y específico para el tipo de cambio.
■
El cambio se debe implementar según un proceso definido, con tareas para
garantizar que todos los aspectos del cambio se implementan de forma adecuada.
■
La implementación del cambio se debe revisar para minimizar el riesgo de negocio
global y asegurarse de que el cambio se registre en todos los sistemas relacionados
antes del cierre.
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.
■
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.
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.
Las configuraciones listas para usar para la gestión de cambios incluyen un proceso de
workflow personalizado para cada tipo de cambio. Además, se ha asociado un tipo de
aprobación relevante con los diferentes tipos de cambios.
Nota: Se recomienda encarecidamente que las nuevas solicitudes de cambio se
registren usando la plantilla de ticket adecuada para el tipo de cambio relevante. Esto
garantizará que se asocie el proceso de aprobación de cambio correcto al cambio
correspondiente.
Cambio estándar
Los
cambios estándares normalmente pasan por cinco fases desde su creación hasta el
cierre: generación del cambio, aprobación del gestor, implementación, revisión
posterior a la implementación estándar y cierre.
En función de si el ticket se aprueba o rechaza en la fase de aprobación del gestor, se
aplica la acción pertinente tras la aprobación o el rechazo y, en consecuencia, el ticket
avanza a la fase de implementación o retrocede a la fase de generación del cambio.
En el siguiente diagrama se muestra el progreso de un cambio estándar durante su ciclo
de vida:
Nota: Las opciones acción de workflow que comienzan por zz (por ejemplo, zzGestor
aprobado) son para acciones de back-end del sistema (es decir, en respuesta a otra
acción), y se utilizan para automatizar una acción posterior. Por ejemplo, la acción
zzGestor aprobado la podría ejecutar el motor de aprobación cuando el gestor del
solicitante apruebe el ticket. Además, se puede utilizar para hacer avanzar el ticket a la
fase de implementación.
Estas acciones de workflow no se muestran en la lista desplegable Adoptar una medida
y no están disponibles como acciones manuales para los analistas.
Cambio normal
Los
cambios normales suelen pasar por seis fases desde la creación hasta el cierre:
generación del cambio, aprobación del gestor, revisión del gestor de cambios,
implementación, revisión posterior a la implementación normal y cierre.
Los cambios normales tienen un proceso de aprobación de dos etapas. La primera etapa
es la fase de aprobación del gestor. Una vez que el ticket se aprueba en esta fase, la
acción automática (zzGestor aprobado) lo pasa a la fase de revisión del gestor de
cambios, que es la fase siguiente del proceso de aprobación.
La fase de revisión del gestor de cambios está formada por dos fases adicionales: la fase
de aprobación de CAB y la de revisión del CAB. El gestor de cambios puede realizar una
de las siguientes acciones manuales, lo que hará que el ticket pase a la fase siguiente:
■
La acción del workflow Aprobar para la implementación hará que el ticket pase
directamente a la fase de implementación.
■
La acción del workflow Enviar para revisión del CAB hará que el ticket pase a la fase
de revisión del CAB y que se configure con el tipo de aprobación Cualquier
aprobación o rechazo. De esta forma, el ticket se podrá aprobar o rechazar según la
respuesta del primer aprobador que responda a la notificación de aprobación.
■
Las acciones del workflow Enviar para aprobación de CAB o Enviar para aprobación
urgente harán que el ticket pase a la fase de aprobación de CAB y que se configure
con el tipo de aprobación Todos los aprobadores. De esta forma, TODOS los
aprobadores tendrán que aprobar el ticket. Con un único rechazo que se produzca,
el ticket se rechazará por completo.
Según la naturaleza del cambio y otros procesos de la organización, el gestor de cambios
puede decidir cómo se debe proceder con el cambio.
En el siguiente diagrama se muestra el progreso de un cambio normal durante su ciclo
de vida:
Cambio de emergencia
Los cambios de emergencia suelen pasar por cinco fases desde la creación hasta el
cierre: generación del cambio, revisión del gestor de cambios, implementación, revisión
posterior a la implementación de emergencia y cierre de emergencia.
La diferencia principal entre el proceso de los cambios de emergencia y de los cambios
normales es que los primeros carecen de la fase de aprobación del gestor. Una vez que
se genera el cambio, este va directamente en la fase de revisión del gestor de cambios.
La fase de revisión del gestor de cambios está formada por dos fases adicionales: la fase
de aprobación del ECAB y la de revisión del ECAB. El gestor de cambios puede realizar
una de las siguientes acciones manuales, lo que hará que el ticket pase a la fase
siguiente:
■
La acción del workflow Aprobar para la implementación hará que el ticket pase
directamente a la fase de implementación.
■
La acción del workflow Enviar para revisión del ECAB hará que el ticket pase a la
fase de revisión de ECAB y que se configure con el tipo de aprobación Cualquier
aprobación o rechazo. De esta forma, el ticket se podrá aprobar o rechazar según la
respuesta del primer aprobador que responda a la notificación de aprobación.
■
La acción del workflow Enviar para aprobación del ECAB hará que el ticket pase a la
fase de aprobación del ECAB y que se configure con el tipo de aprobación Todos los
aprobadores. De esta forma, TODOS los aprobadores tendrán que aprobar el ticket.
Con un único rechazo que se produzca, el ticket se rechazará por completo.
Según la naturaleza del cambio y otros procesos de la organización, el gestor de cambios
puede decidir cómo se debe proceder con el cambio. En función de si el cambio se
aprueba o se rechaza, el ticket seguirá avanzando.
En el siguiente diagrama se muestra el progreso de un cambio de emergencia durante
su ciclo de vida:
Cambio de reparación
Registros relacionados con la gestión de cambios
Como los cambios de reparación se crean para registrar un cambio después de
implementarlo (sin pasar por el proceso de aprobación), los cambios de reparación
pasan por tres fases desde la creación hasta el cierre: registro del cambio, revisión de
reparación y cierre de la reparación.
A diferencia de otros tipos de cambios, los cambios de reparación no tienen un ciclo de
aprobación asociado ni tampoco una fase de implementación extendida, porque la
finalidad principal de registrar un cambio de reparación es cuando el cambio ya se ha
implementado sin haberlo aprobado primero.
En el siguiente diagrama se muestra el progreso de un cambio de reparación durante su
ciclo de vida:
En las siguientes secciones se describen las acciones de workflow, enrutamiento
automático y plantillas que forman parte del diseño de workflow de todos los tipos de
tickets de cambio.
workflow.
Los tickets de tarea y las plantillas de ticket de tarea se incluyen como parte del diseño
de workflow de gestión de cambios. Los siguientes registros de configuración de
workflow forman parte del diseño de workflow de gestión de cambios.
Plantillas de ticket de cambio
Las plantillas de ticket son formularios de tickets rellenos previamente con valores
proporcionados para algunos campos importantes del ticket, en función de la finalidad y
la audiencia a la que esté destinada la plantilla. Una plantilla de ticket puede tener
valores definidos para campos seleccionados y algunos campos se pueden configurar
como campos obligatorios, lo que instaura un proceso estandarizado para registrar las
solicitudes. El enrutamiento automático efectivo de los tickets registrados mediante la
plantilla también es más fácil, ya que se definen campos como la fuente, la persona a la
que se han asignado, etc.
Las siguientes plantillas de ticket se ofrecen como parte de las configuraciones de
workflow listas para usar:
Nombre de
plantilla
Categoría
Descripción
Establecimiento de campos
Permiso
Solicitud de
cambio normal
(agente)
General
Crea una solicitud de
cambio normal.
■
Tipo de cambio = Normal
■
Administración
■
Código de motivo = Agente
normal
■
Gestión de cambios
(rol)
Solicitud de
cambio
estándar
(agente)
General
cambio estándar.
■
Tipo de cambio = Estándar
■
Administración
■
estándar
■
Gestión de cambios
(rol)
Solicitud de
cambio de
emergencia
(agente)
General
cambio de
emergencia.
■
Tipo de cambio =
Emergencia
■
Administración
■
■
de emergencia
Gestión de cambios
(rol)
Crear solicitud
de reparación
(agente)
General
Crear solicitud de
reparación
■
Tipo de cambio =
Reparación
■
Administración
■
■
de reparación
Gestión de cambios
(rol)
■
Administración
■
Gestión de cambios
(rol)
■
Autoservicio
predeterminado
(rol)
Nuevo
Servicios Nuevo empleado de
■
empleado de
de
aprovisionamiento
aprovisionamie empleado con un plazo de 5 días
■
nto (muestra)
■
ccti_id = Provisión Empleado
Descripción = Solicitud de
nuevo empleado de
aprovisionamiento
Motivo del cambio = Nuevo
empleado que se une a la
organización
Servidor web
Servicios
de
IT
aprovisionamie
nto (muestra)
Oficina de
Servicios
aprovisionamie de
nto (ticket de
empleado
tarea)
Plantilla de muestra
■
para el
aprovisionamiento del
servidor web.
Plantilla de tarea de
muestra que forma
parte de un flujo de
tareas - Nuevo
empleado de
aprovisionamiento
ID del grupo asignado =
Soporte para servidores
(nivel 2)
■
ccti_id = Provisión - Servidor
- Web
■
Descripción = Solicitud de
aprovisionamiento de
servidor nuevo
■
Fase = Generar un cambio
■
Código de motivo = Nuevo
cambio
■
Motivo del cambio = Nueva
solicitud de servidor web
■
Estatus = En cola
■
Instalaciones
■
ccti_id = Provisión - Oficina Muebles
■
Fase = Iniciado
■
Código de motivo = Nueva
solicitud
■
Descripción = Creación de
oficina, escritorio, mesa,
silla, otros
■
Nombre de la tarea =
Aprovisionamiento de las
instalaciones de oficina
■
Administración
■
Autoservicio
predeterminado
(rol)
■
Público
■
Administración
■
Público
Equipo de
Servicios
aprovisionamie de
nto (ticket de
empleado
tarea)
Cuentas de red Seguridad
de
aprovisionamie
nto (ticket de
tarea)
Servidor web
de
aprovisionamie
nto (ticket de
tarea)
Aprovision
amiento
de
servidor
muestra que forma
tareas - Nuevo
empleado de
aprovisionamiento
muestra que forma
tareas - Nuevo
empleado de
aprovisionamiento
■
■
ccti_id = Aprovisionamiento
- Equipo personal
■
Fase = Iniciado
■
Estatus = En cola
■
Descripción =
Aprovisionamiento de
equipo personal nuevo
■
Equipo de
aprovisionamiento
■
Administración
■
ccti_id = Seguridad Aprovisionamiento - Cuenta
■
Fase = Iniciado
■
cuenta
■
Estatus = En cola
■
Descripción = Configuración
de acceso de red
■
Solicitud de acceso de red
■
muestra que forma
tareas Aprovisionamiento de ■
servidor web
Soporte para equipos de
escritorio
Soporte para servidores
(nivel 2)
ccti_id = Provisión - Servidor
- Web
■
Fase = Generar tarea
■
tarea
■
Estatus = En cola
■
Descripción = Configuración
de un nuevo servidor web.
■
Aprovisionamiento del
servidor web
■
Administración
■
Público
■
Administración
■
Administración
Actualizar base Configurac Plantilla de tarea de
■
de datos de
ión
muestra que forma
gestión de la
■
configuración
tareas (ticket de tarea)
Aprovisionamiento de
servidor web
Gestor de cambios
■
Administración
■
Público
ccti_id = Infraestructura Actualizar - Elemento de
configuración
■
Fase = Generar tarea
■
tarea
■
Estatus = En cola
■
Descripción = Actualización
de CMDB con datos sobre el
nuevo servidor recién
creado
■
Actualización de CMDB
Nota: Preste atención a lo siguiente:
■
La casilla de verificación Anular el enrutamiento automático está sin marcar en la
plantilla de ticket. Se aplicará un enrutamiento automático al ticket creado
mediante esta plantilla y se asignará a un grupo de soporte adecuado.
■
Hay dos flujos de tareas, con plantillas de ticket de tarea relacionadas. El workflow
se puede modificar para incluir estas tareas en el proceso de implementación de
cambios.
Plantillas de comunicación de cambios
configuraciones de workflow de gestión de cambios listas para usar:
Nombre de
plantilla
Enviar a
Finalidad
Cambiar cliente
pendiente
Indica al solicitante que el ticket de cambio está a la espera
de información del cliente.
Cambiar asignación ${tr.assigned_to_individual
individual
_name}
Indica a una persona que se le ha asignado un ticket mediante
la acción del workflow Asignar al individuo.
Cambiar asignación ${tr.assigned_to_group_na
de grupo
me}
Indica al grupo de soporte que se le ha asignado un ticket
El cambio se ha
cerrado con
excepciones
Indica al solicitante que la solicitud de cambio se ha cerrado
con excepciones.
El cambio se ha
cerrado sin
excepciones
Indica al solicitante que la solicitud de cambio se ha cerrado
sin excepciones.
Aviso de tarea
completada
${assigned_to_individual_n
ame}
Indica al usuario asignado que el ticket de la tarea relacionada
se ha completado correctamente.
Aviso de tarea
fallida
${assigned_to_individual_n
ame}
Indica al usuario asignado que una tarea relacionada no se ha
se pueden asociar con notificaciones de aprobación, enrutamientos automáticos y
acciones de workflow.
Cambios de enrutamientos automáticos
automáticos para aplicarlos a los tickets en función de su fuente. En la siguiente tabla
encontrará una lista de los enrutamientos automáticos configurados y disponibles listos
para usar en las solicitudes de cambio.
Nombre del
enrutamiento
automático
Orden
Cambio de reparación 900
Solicitud de cambio
normal (agente)
900
Condiciones
coincidentes
Establecer campos y
Establecer valores de campos
Código de motivo ■
= Crear solicitud
de reparación
■
Fase = Registrar cambio
■
cambio
■
Estado = Activo
= Agente normal
Tipo de cambio =
Reparación
■
■
cambio
■
Estado = Activo
Comunicación
relacionada
Ninguno
Ninguno
Solicitud de cambio de 900
emergencia (agente)
Solicitud de cambio
estándar
= Agente de
emergencia
950
Ninguno
Ninguno
Tipo de cambio =
Emergencia
■
■
cambio
■
Estado = Activo
■
Tipo de cambio = Estándar
■
■
cambio
■
Estado = Activo
Nota: En el diseño de workflow listo para usar, se considera que los solicitantes no
introducirán nuevas solicitudes de cambio directamente. Las solicitudes de cambio las
registrarán los responsables del Service Desk (nivel 1) u otros grupos de soporte
mediante la creación de un cambio a partir de un ticket de problema, de incidente o de
solicitud de servicio.
Dado que las notificaciones para crear los tickets de cambio se activan mediante las
acciones de workflow correspondientes, los enrutamientos automáticos no tienen
asociada ninguna notificación para el solicitante. Si los procesos de soporte así lo exigen,
puede relacionar una plantilla de comunicación con estos enrutamientos automáticos.
Opciones de acción del workflow para cambios
configuraciones de workflow listas para usar para los tickets de cambio.
Nombre de la Función
opción de
especial
acción
Condiciones
coincidentes
Establecer campos y
campos
Tomar
propiedad
NO (Estado =
Resuelto, Estado =
Cerrado)
■
Código de motivo Ninguno
= En curso
■
Estado = Activo
Aceptar
asignación
Y
Campos
Comunicación
obligatorios
Ninguno
NO (Código de
motivo = Aprobación
pendiente)
Reasignar al
grupo
Reasignar al
individuo
Asignar al
grupo
Asignar al
individuo
Reasignar en
Mi grupo
(Estado = Activo)
■
Y
= Asignación
NO (Código de
■
pendiente)
Estado = En cola
(Estado = Activo)
= En curso
■
Y
NO (Código de
■
pendiente)
Estado = En cola
(Estado = Activo)
■
R
Y
e
NO (Código
a de
■
motivo = sAprobación
pendiente)
i
g
n
a
r
= Asignación
Estado = En cola
Cambiar
asignación de
grupo
Cambiar
asignación
individual
Cambiar
asignación
individual
e
n
g
r
u
p
o
Configurar
información
pendiente
Ninguno
Configurar el
cliente
pendiente
Ninguno
(Estado = Activo)
■
Y
= Información
NO (Código de
■
pendiente)
Estado =
Pendiente
(Estado = Activo)
Visible por el
cliente = Sí
■
Y
NO (Código de
■
pendiente)
Código de motivo
= Cliente
■
Estado =
Pendiente
■
Tipo de trabajo =
Nota del cliente
Descripción
del registro
de trabajo
Ninguno
Cambiar cliente
pendiente
Reanudar
trabajo en
ticket
pendiente
Ninguno
Enviar para
revisión de la
gestión de
cambios
(Estado = Pendiente) ■
(Estado = Activo)
A
Y
c
(Tipo de cambio
=
e
Reparación)
p
Y
t
NO (Fase a= Revisión
r
de reparación)
= En curso
■
Estado = Activo
■
Fase = Revisión
de reparación
■
Código de motivo
= Revisión de
reparación
■
Fase = Cierre de
la reparación
■
Código de motivo
= Cancelado
■
Estado = Cerrado
■
Fase = Cierre de
la reparación
■
Código de motivo
= Solicitud de
cambio de
reparación
cerrada
■
Estado = Cerrado
■
Fase = Cierre de
la reparación
■
Código de motivo
= Cancelado
■
Estado = Cerrado
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
El cambio se ha
cerrado sin
excepciones
Ninguno
Ninguno
a
s
i
g
n
a
c
i
ó
n
Cancelar y
Ninguno
cerrar cambio
(Estado = Activo)
Y
(Tipo de cambio =
Reparación)
Cierre del
cambio
Ninguno
(Estado = Activo)
Y
(Fase = Revisión de
reparación)
Y
(Tipo de cambio =
Reparación)
Cancelar y
Ninguno
cerrar cambio
(Estado = Activo)
Y
(Tipo de cambio =
Reparación)
Cierre del
cambio
Ninguno
(Estado = Activo)
■
Fase = Cierre de
la reparación
■
Código de motivo
= Solicitud de
cambio de
reparación
cerrada
■
Estado = Cerrado
■
Fase = Revisión
de reparación
■
Código de motivo
= Reabrir
■
Estado = Activo
■
Fase = Revisión
del gestor de
cambios
■
Código de motivo
= Gestor
aprobado
■
Estado = Activo
■
Fase = Generar
un cambio
■
Código de motivo
= Gestor
rechazado
■
Estado = Activo
Y
(Fase = Revisión de
reparación)
Y
(Tipo de cambio =
Reparación)
Reabrir y
tomar
propiedad
zzGestor
aprobado
zzGestor
rechazado
Aceptar
asignación
(Estado = Cerrado)
Y
Fase = Cierre de la
reparación
Ninguno
Ninguno
(Estado = zzActivo)
(Estado = zzActivo)
Ninguno
El cambio se ha
cerrado sin
excepciones
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
Enviar para
aprobación
del gestor
Enviar para
aprobación
(Estado = Activo)
■
appr_action_id
when_ approved
= zzGestor
aprobado
■
appr_action_id_w
hen_ rejected =
zzGestor
rechazado
■
Fase de
aprobación =
Aprobación del
gestor
■
Tipo de
aprobación =
Cualquier
aprobación o
rechazo
■
Código de motivo
= Aprobación
pendiente
■
Estado = Activo
■
Fase = Generar
un cambio
■
Código de motivo
= Cambio retirado
■
Estado = Activo
■
Fase =
Implementación
■
Código de motivo
= CAB aprobado
■
Estado = Activo
Y
(Fase = Generar un
cambio)
Y
(Tipo de cambio =
Normal)
Y NO
(Código de motivo =
Aprobación
pendiente)
Retirar de la
aprobación
del gestor
Retirar de la
aprobación
(Estado = Activo)
Y
(Fase = Aprobación
del gestor)
Y
Aprobación
pendiente)
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
Y
(Tipo de cambio =
Normal)
zzCAB
aprobado
Ninguno
(Estado = zzActivo)
zzCAB
rechazado
Retirar
cambio
Ninguno
Retirar de la
aprobación
(Estado = zzActivo)
(Estado = Activo)
■
Fase = Cierre
normal
■
Código de motivo
= CAB denegado
■
Estado = Activo
■
Fase = Generar
un cambio
Y
(Fase = Aprobación ■
de CAB, Revisión del
CAB)
Y
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
Código de motivo
= Cambio retirado
■
Estado = Activo
■
Fase =
Implementación
■
Código de motivo
= Aprobado
Aprobación
pendiente)
Y
(Tipo de cambio =
Normal)
Aprobar para Ninguno
la
implementaci
ón
(Estado = Activo)
Y
(Fase = Revisión del
gestor de cambios)
Y
(Tipo de cambio =
Normal)
Enviar para
aprobación
urgente
Enviar para
aprobación
(Estado = Activo)
■
Ninguno
appr action id
when approved =
zzGestor
aprobado
■
appr action id
when rejected =
zzGestor
rechazado
■
Fase de
aprobación =
Aprobación de
CAB
■
Tipo de
aprobación =
Todos los
aprobadores
■
Fase =
Aprobación de
CAB
■
Código de motivo
= Aprobación
pendiente
Y
gestor de cambios)
Y
(Tipo de cambio =
Normal)
Ninguno
Enviar para
Enviar para
aprobación de aprobación
CAB
(Estado = Activo)
■
Ninguno
appr action id
when approved =
zzGestor
aprobado
■
appr action id
when rejected =
zzGestor
rechazado
■
Fase de
aprobación =
Aprobación de
CAB
■
Tipo de
aprobación =
Todos los
aprobadores
■
Fase =
Aprobación de
CAB
■
Código de motivo
= Aprobación
pendiente
Y
gestor de cambios)
Y
(Tipo de cambio =
Normal)
Ninguno
Enviar para
revisión del
CAB
Enviar para
aprobación
(Estado = Activo)
■
Ninguno
appr action id
when approved =
zzGestor
aprobado
■
appr action id
when rejected =
zzGestor
rechazado
■
Fase de
aprobación =
Aprobación de
CAB
■
Tipo de
aprobación =
Cualquier
aprobación o
rechazo
■
Fase = Revisión
del CAB
■
Código de motivo
= Aprobación
pendiente
■
Fase = Revisión
posterior a la
implementación
normal
■
Código de motivo
= La
implementación
se ha completado
correctamente
■
Estado = Activo
■
Fase = Revisión
posterior a la
implementación
normal
■
Código de motivo
= Se ha producido
un fallo durante
la
implementación
Y
gestor de cambios)
Y
(Tipo de cambio =
Normal)
La
Ninguno
implementaci
ón se ha
completado
correctament
e
(Estado = Activo)
Y
(Fase =
Implementación)
Y
(Tipo de cambio =
Normal)
Se ha
Ninguno
producido un
fallo durante
la
implementaci
ón
(Estado = Activo)
Y
(Fase =
Implementación)
Y
(Tipo de cambio =
Normal)
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
¿Desea cerrar Ninguno
el cambio
como
correcto?
(Estado = Activo)
Y
(Tipo de cambio =
Normal)
Cerrar cambio Ninguno
con
excepciones
(Estado = Activo)
(Fase = Revisión
posterior a la
implementación
normal)
(Tipo de cambio =
Normal)
(Estado = Activo)
zzGestor
estándar
rechazado
Ninguno
Ninguno
Código de motivo
= El cambio se ha
completado
correctamente
■
Estado = Cerrado
■
Fase = Cierre
normal
■
Código de motivo
invertido
= El cambio se ha
completado con Descripción
del registro
excepciones
de trabajo
Estado = Cerrado
Tipo de
registro de
trabajo
■
■
Fase = Coste
estándar
■
Código de motivo
= Cancelado
■
Estado = Cerrado
■
Fase =
Implementación
■
Código de motivo
= Gestor
aprobado
■
Estado = Activo
■
Fase = Generar
un cambio
■
Código de motivo
= Gestor
rechazado
■
Estado = Activo
Y
(Tipo de cambio =
Estándar)
zzGestor
estándar
aprobado
■
Y
Y
Cancelar y
Ninguno
cerrar cambio
Fase = Cierre
normal
Y
(Fase = Revisión
posterior a la
implementación
normal)
(Estado = zzActivo)
(Estado = zzActivo)
Ninguno
■
El cambio se ha
cerrado sin
excepciones
Visible por el El cambio se ha
cliente
cerrado con
excepciones
Tiempo
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
Enviar para
aprobación
del gestor
Enviar para
aprobación
(Estado = Activo)
■
Ninguno
appr action id
when approved =
zzGestor estándar
aprobado
■
appr action id
when rejected =
zzGestor estándar
rechazado
■
Fase de
aprobación =
Aprobación del
gestor
■
Tipo de
aprobación =
Cualquier
aprobación o
rechazo
■
Fase =
Aprobación del
gestor de
cambios estándar
■
Código de motivo
= Aprobación
pendiente
■
Fase = Generar
un cambio
■
Código de motivo
= Cambio retirado
Y
(Fase = Generar un
cambio)
Y
(Tipo de cambio =
Estándar)
Retirar de la
aprobación
del gestor
Retirar de la
aprobación
(Estado = Activo)
Y
Aprobación
pendiente)
Ninguno
Ninguno
Ninguno
Y
(Fase = Aprobación
del gestor)
Y
(Tipo de cambio =
Estándar)
La
Ninguno
implementaci
ón se ha
completado
correctament
e
(Estado = Activo)
(Estado = Activo)
■
Código de motivo
= Se ha producido
un fallo durante
la
implementación
■
Fase = Coste
estándar
■
Código de motivo
= El cambio se ha
completado
correctamente
■
Estado = Cerrado
■
Fase = Coste
estándar
■
Código de motivo
invertido
= El cambio se ha
del registro
excepciones
de trabajo
Estado = Cerrado
Tipo de
registro de
trabajo
Y
(Fase = Revisión
posterior a la
implementación
estándar)
Y
(Tipo de cambio =
Estándar)
con
excepciones
(Estado = Activo)
Y
(Fase = Revisión
posterior a la
implementación
estándar)
Y
(Tipo de cambio =
Estándar)
Cancelar y
Ninguno
cerrar cambio
(Estado = Activo)
■
■
Fase = Cierre
normal
■
Código de motivo
= Cancelado
■
Estado = Cerrado
Y
(Tipo de cambio =
Normal)
El cambio se ha
cerrado sin
excepciones
Fase = Revisión
posterior a la
implementación
estándar
(Fase =
Implementación)
(Estado = Activo)
Ninguno
■
(Tipo de cambio =
Estándar)
el cambio
como
correcto?
Ninguno
Código de motivo
= La
implementación
se ha realizado
correctamente
Y
Y
Ninguno
■
(Fase =
Implementación)
(Tipo de cambio =
Estándar)
Se ha
Ninguno
producido un
fallo durante
la
implementaci
ón
Ninguno
Fase = Revisión
posterior a la
implementación
estándar
Y
Y
Ninguno
■
cliente
cerrado con
excepciones
Tiempo
Ninguno
Ninguno
Cancelar y
Ninguno
cerrar cambio
(Estado = Activo)
Fase = Cierre de
emergencia
■
Código de motivo
= Cancelado
■
Estado = Cerrado
■
Fase =
Implementación
■
Código de motivo
= Aprobado
■
Fase =
Implementación
■
Código de motivo
= ECAB aprobado
■
Estado = Activo
■
Fase = Cierre de
emergencia
■
Código de motivo
= ECAB denegado
■
Estado = Cerrado
Y
(Tipo de cambio =
Emergencia)
Aprobar para Ninguno
la
implementaci
ón
■
(Estado = Activo)
Y
(Fase = Generar un
cambio)
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
Y
(Tipo de cambio =
Emergencia)
Y
NO (Código de
pendiente)
zzECAB
aprobado
zzECAB
rechazado
Ninguno
Ninguno
(Estado = zzActivo)
(Estado = zzActivo)
Enviar para
aprobación
del ECAB
Enviar para
aprobación
(Estado = Activo)
■
Ninguno
appr action id
when approved =
zzECAB aprobado
■
appr action id
when rejected =
zzECAB rechazado
■
Fase de
aprobación =
Aprobación del
ECAB
■
Tipo de
aprobación =
Todos los
aprobadores
■
Fase =
Aprobación del
ECAB
■
Código de motivo
= Aprobación
pendiente
■
Ninguno
appr action id
when approved =
zzECAB aprobado
■
appr action id
when rejected =
zzECAB rechazado
■
Fase de
aprobación =
Revisión del ECAB
■
Tipo de
aprobación =
Cualquier
aprobación o
rechazo
■
Fase = Revisión
del ECAB
■
Código de motivo
= Aprobación
pendiente
Y
(Fase = Generar un
cambio)
Y
(Tipo de cambio =
Emergencia)
Enviar para
revisión del
ECAB
Enviar para
aprobación
(Estado = Activo)
Y
(Fase = Generar un
cambio)
Y
(Tipo de cambio =
Emergencia)
Ninguno
Ninguno
Retirar
cambio
Retirar de la
aprobación
(Estado = Activo)
■
Fase = Generar
un cambio
■
Código de motivo
= Cambio retirado
■
Estado = Activo
■
Fase = Revisión
posterior a la
implementación
de emergencia
■
Código de motivo
= La
implementación
se ha realizado
correctamente
■
Estado = Activo
■
Fase = Revisión
posterior a la
implementación
de emergencia
■
Código de motivo
= Se ha producido
un fallo durante
la
implementación
■
Estado = Activo
■
Fase = Cierre de
emergencia
■
Código de motivo
= Cambio
completado
correctamente
■
Estado = Cerrado
Y
Aprobación
pendiente)
Y
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
Ninguno
El cambio se ha
cerrado sin
excepciones
(Fase = Aprobación
del ECAB O Fase =
Revisión del ECAB)
Y
(Tipo de cambio =
Emergencia)
La
Ninguno
implementaci
ón se ha
completado
correctament
e
(Estado = Activo)
Y
(Fase =
Implementación)
Y
(Tipo de cambio =
Emergencia)
Se ha
Ninguno
producido un
fallo durante
la
implementaci
ón
(Estado = Activo)
Y
(Fase =
Implementación)
Y
(Tipo de cambio =
Emergencia)
el cambio
como
correcto?
(Estado = Activo)
Y
(Fase = Revisión
posterior a la
implementación de
emergencia)
Y
(Tipo de cambio =
Emergencia)
con
excepciones
(Estado = Activo)
Fase = Cierre de
emergencia
■
Código de motivo
invertido
= El cambio se ha
del registro
excepciones
de trabajo
Estado = Cerrado
Tipo de
registro de
trabajo
Y
(Fase = Revisión
posterior a la
implementación de
emergencia)
Y
(Tipo de cambio =
Emergencia)
Suprimir
Ninguno
solicitud de
cambio
(administrado
r)
Ninguno
cliente
cerrado con
excepciones
Tiempo
■
■
■
Ninguno
Ninguno
Ninguno
Además de las acciones de workflow anteriores, que forman parte del diseño principal
de workflow, las configuraciones listas para usar para cambios también contienen las
siguientes acciones de workflow para registrar y gestionar las tareas relacionadas:
■
Iniciar tareas de aprovisionamiento: esta acción de workflow está disponible
cuando un ticket se envía mediante la plantilla Nuevo empleado de
aprovisionamiento o cuando se cumplen las condiciones de coincidencia de esa
plantilla. Al ejecutar esta acción, la fase del ticket se establece como Tarea, con el
código de motivo La tarea está en progreso.
■
Iniciar tarea de aprovisionamiento: esta acción de workflow está disponible
cuando se envía un ticket mediante la plantilla de aprovisionamiento del servidor
web o cuando se cumplen las condiciones de coincidencia de esa plantilla. Al
ejecutar esta acción, la fase del ticket se establece como Tarea, con el código de
motivo La tarea está en progreso.
■
zzTarea correcta: esta acción de workflow es una acción de back-end que se activa
cuando todas las tareas del flujo de tareas se han completado correctamente. La
ejecución de esta acción establece la fase del ticket como Revisión posterior a la
implementación estándar, con el código de motivo La tarea se ha completado
correctamente.
■
zzTarea fallida: esta acción de workflow es una acción de back-end que se activa
cuando se ha producido un fallo en su terminación. La ejecución de esta acción
establece la fase de ticket como Implementación, con el código de motivo Se ha
producido un fallo en la tarea.
Grupos de aprobación de cambios
Para implementar el proceso de aprobación de cambios, el administrador puede
configurar grupos de aprobación con diferentes condiciones de coincidencia, por
ejemplo, Tipo de cambio, CCTI, etc. Cuando se registra un ticket de cambio que cumple
las condiciones de coincidencia, los grupos de aprobación se relacionan
automáticamente con el ticket.
Se pueden seleccionar aprobadores o revisores contextuales para que sean miembros
del grupo de aprobación, o bien designar contactos individuales específicos como
aprobadores y revisores en ese grupo de aprobación.
Los siguientes grupos de aprobación se configuran como grupos de muestra en las
configuraciones listas para usar.
Nombre del grupo de aprobación
Condiciones coincidentes
Descripción
Grupo de aprobación de cambios
durante gestión de aprobación
${appr_phase} = Aprobación del
gestor
Este grupo de aprobación se
relaciona con un ticket de cambio
cuando el ticket está en la fase de
aprobación del gestor. El gestor del
solicitante se elige en el contexto
del ticket como el aprobador.
CAB Approval Change Approval
Group (Grupo de aprobación de
cambios durante aprobación del
ECAB)
${appr_phase} = Aprobación del CAB Este grupo de aprobación se
aprobación de CAB.
Se pueden seleccionar contactos
para relacionarlos con este grupo de
aprobación.
ECAB Approval Change Approval
Group (Grupo de aprobación de
cambios durante aprobación del
ECAB)
${appr_phase} = Aprobación del
ECAB
Este grupo de aprobación se
aprobación del ECAB.
Se pueden seleccionar contactos
para relacionarlos con este grupo de
aprobación.
Se pueden modificar las condiciones de coincidencia para adaptarlas a las necesidades
de su organización y configurar grupos de aprobación adicionales en función de los
grupos anteriores.
Nota: Actualmente no hay ningún contacto relacionado con estos grupos de aprobación.
Será necesario seleccionar aprobadores y revisores de entre los contactos configurados
en su instancia y relacionarlos con los grupos de aprobación.
Únicamente los contactos de esos grupos de soporte que se pueden utilizar para la
aprobación estarán disponibles en la búsqueda de nombres que se muestra para
seleccionar aprobadores y revisores para los grupos de aprobación.
Capítulo 7: Problemas conocidos y aspectos
que hay que tener en cuenta
Esta sección contiene información acerca de algunos problemas conocidos y
limitaciones del diseño de workflow listo para usar, así como sugerencias para
solucionarlos. En esta sección también se enumeran algunos aspectos clave que se
deben tener en cuenta sobre el diseño de workflow o los cambios de configuración
realizados para garantizar el soporte del diseño de workflow.
Problemas conocidos (en la página 101)
Aspectos que hay que tener en cuenta (en la página 109)
Problemas conocidos
Se han identificado los siguientes errores y omisiones con las configuraciones listas para
usar (todavía están pendientes de resolución en la versión actual):
■
No hay ningún grupo de soporte relacionado con el rol Gestión de la configuración.
■
No hay ninguna plantilla de ticket Informar sobre una interrupción para los
analistas.
■
Los usuarios no podrán registrar solicitudes de servicio desde la interfaz de usuario.
■
Las condiciones de coincidencia son incorrectas para la acción del workflow Retirar
cambio.
■
No se ha relacionado ninguna plantilla de comunicación con la acción del workflow
Enviar para la aprobación.
Estas incidencias y las soluciones alternativas sugeridas se explican en las secciones
siguientes.
Capítulo 7: Problemas conocidos y aspectos que hay que tener en cuenta 101
Problemas conocidos
No hay ningún grupo de soporte relacionado con el rol Gestión de la
configuración.
La relación entre el rol Gestión de la configuración y el grupo de soporte Configuración
se ha roto:
Se ha creado un rol denominado Gestión de la configuración, con permisos para las
opciones relacionadas con la gestión de la configuración en el menú de navegación.
Asimismo, se ha creado un grupo de soporte llamado Configuración.
Para que funcione el modelo de permisos, el grupo de soporte Configuración debe estar
relacionado con el rol Gestión de la configuración. Sin embargo, esta relación no existe
en las configuraciones listas para usar.
Solución:
Relacione el grupo de soporte Configuración con el rol Gestión de la configuración.
Siga los pasos siguientes:
1.
Haga clic en Gestionar roles en Configuración de la aplicación, en el menú de
navegación
Se abrirá el formulario Gestionar roles y todos los roles existentes se mostrarán en
la tabla.
2.
Haga clic en el rol Gestión de la configuración en la tabla.
Los detalles del rol Gestión de la configuración se mostrarán en el formulario.
3.
Haga clic en Agregar grupo en el formulario que muestra el rol Gestión de la
configuración.
Se mostrará la búsqueda con Grupos de soporte que se puede utilizar para los
permisos.
4.
Seleccione la casilla de verificación situada junto al grupo de soporte Configuración
en la lista de grupos que se muestra y haga clic en Seleccionar.
El grupo de soporte Configuración se relacionará con el rol Gestión de la
configuración.
Ahora puede relacionar los contactos con el grupo de soporte Configuración. Estos
contactos heredarán los permisos asignados al rol Gestión de la configuración.
Problemas conocidos
No hay ninguna plantilla de ticket Informar sobre una interrupción para los
analistas
El rol Gestión de gestión de incidentes carece de permisos para la plantilla de ticket
Informar sobre una interrupción:
El diseño del workflow Gestión de incidentes considera que los analistas registrarán los
tickets de incidente mediante la plantilla de ticket Informar sobre una interrupción, cuya
fuente configurada es un agente.
Sin embargo, esta plantilla de ticket no existe en las configuraciones listas para usar.
Para que funcione el diseño de workflow, los tickets nuevos que registren los analistas
deberán registrarse configurando manualmente el campo Fuente como Agente.
Solución:
Configure una plantilla de ticket con los valores de campo correctamente definidos y
active los permisos para que la puedan usar los miembros de Service Desk (nivel 1) y
otros grupos de soporte relevantes.
1.
Haga clic en Gestionar plantillas del ticket, en Herramientas del workflow, en el
menú de navegación.
Se mostrará el formulario Gestionar plantillas del ticket. Se puede crear una nueva
plantilla de ticket mediante este formulario.
2.
Seleccione Incidente en la lista desplegable Tipo de ticket para configurar la plantilla
de ticket para los tickets de incidente.
3.
(Opcional) Especifique una categoría para la plantilla.
Nota: Se recomienda categorizar las plantillas de ticket, especialmente si se tiene
previsto configurar plantillas para tipos diferentes de solicitudes.
4.
Especifique un nombre de plantilla que le ayude a identificar la plantilla y su uso.
Por ejemplo, Informar sobre una interrupción (agente).
5.
(Opcional) Especifique una definición para la plantilla que ayude a los usuarios a
identificar qué plantilla se debe utilizar para cada cosa y haga clic en Aplicar
cambios.
Las fichas Establecer campos y Permisos no se activan y ahora se pueden establecer
valores de campo que coincidan con las reglas de enrutamiento automático para el
correcto enrutamiento de los tickets de incidente.
6.
Seleccione Fuente como Campo para establecer en la lista desplegable que
muestra los campos que se pueden definir en la plantilla de ticket y seleccione
Agregar.
El campo de selección correspondiente para seleccionar la fuente se mostrará en la
columna Valor.
Problemas conocidos
7.
Seleccione Agente en la lista desplegable que muestra los posibles valores para el
campo Fuente y haga clic en Aplicar cambios para guardar el valor del campo
Fuente.
La configuración básica para hacer coincidir los tickets de incidente creados usando
la plantilla con el enrutamiento automático adecuado no está completa. Si es
necesario, se pueden establecer valores del campo adicionales.
A continuación, la ficha Permisos se puede utilizar para asignar permisos para la
plantilla de ticket al rol Gestión de incidentes. De forma predeterminada, los
permisos para la plantilla están disponibles para el grupo de soporte
Administración.
8.
Haga clic en el botón Gestionar permisos en la ficha Permisos.
Se mostrará la búsqueda del Editor de permisos. Se mostrarán todos los grupos de
soporte que se pueden utilizar para los permisos y todos los roles configurados.
9.
Elija el rol Gestión de incidentes en la lista que se muestra, haga clic en Agregar y
cierre el Editor de permisos.
El permiso para la nueva plantilla de ticket estará ahora disponible para el rol
Gestión de incidentes. Los tickets registrados mediante la plantilla seguirán los
enrutamientos automáticos y el diseño de workflow propios de los tickets de
incidente.
Los usuarios no podrán registrar solicitudes de servicio desde la interfaz de
usuario
Los usuarios no podrán registrar solicitudes de servicio nuevas mediante la interfaz de
usuario:
Los analistas relacionados con el rol Gestión de solicitudes de servicio u otros roles o
grupos de soporte no podrán registrar solicitudes de servicio nuevas desde la interfaz de
usuario, ya que no tienen acceso a opción Registrar solicitud de servicio del menú de
navegación y porque no hay plantillas de ticket relacionadas con solicitudes de servicio
en las configuraciones listas para usar.
Además, los usuarios de autoservicio no podrán crear solicitudes de servicio utilizando
la interfaz de usuario, ya que no tienen acceso a la opción Enviar solicitud del menú de
navegación y no hay ninguna plantilla del ticket relacionada con las solicitudes de
servicio.
Se considera que las solicitudes de servicio las registran los usuarios de autoservicio a
través del correo electrónico y que se aplicará el enrutamiento apropiado al ticket.
Problemas conocidos
Solución:
Una solución alternativa recomendada es identificar las solicitudes más importantes que
se clasificarían como solicitudes de servicio y configurar plantillas de ticket para estas
solicitudes. A continuación, se pueden asignar permisos para estas solicitudes al rol
Gestión de solicitudes o al rol Autoservicio predeterminado.
Otra solución alternativa consiste en asignar permisos a la opción Registrar solicitud de
servicio al rol Gestión de solicitudes de servicio y a la opción Enviar solicitud al rol
Autoservicio predeterminado.
Se les puede asignar permiso a las opciones del menú de navegación Enviar solicitud a
los usuarios de autoservicio y Registrar solicitud de servicio a los analistas.
1.
Haga clic en Gestionar menú de navegación, en Servicios de infraestructura de
administración, en el menú de navegación.
Este formulario permite asignar y gestionar permisos para diferentes opciones del
Para asignar permiso para la opción Crear nuevo a los usuarios de autoservicio:
2.
Seleccione Página principal de autoservicio en el filtro del nombre del formulario.
La lista se filtrará y la tabla mostrará los formularios relacionados con la interfaz de
usuario de autoservicio.
3.
Seleccione la opción Enviar solicitud (ID del formulario 218) en la lista.
Los detalles del formulario se mostrarán en el formulario que se muestra a
continuación.
4.
Haga clic en la ficha Permisos y en el botón Gestionar permisos de la ficha de
permisos.
Se mostrará la búsqueda del Editor de permisos.
5.
Seleccione el rol Default Self-Service (Autoservicio predeterminado), haga clic en
Agregar y cierre el editor de permisos.
Los usuarios de autoservicio no tendrán acceso a la opción Enviar solicitud del
Para asignar permiso a los analistas para que puedan acceder a la opción Registrar
solicitud de servicio, siga el procedimiento descrito anteriormente para filtrar la
lista mediante el grupo Gestión de solicitudes del menú de navegación.
Nota: Se recomienda configurar plantillas de ticket para la solicitud de servicio y asignar
permisos a los roles relevantes para gestionar mejor esta función.
Problemas conocidos
Las condiciones de coincidencia son incorrectas para la acción del workflow
Retirar cambio
La acción del workflow Retirar de la aprobación para los cambios normales tiene una
condición de coincidencia incorrecta:
La acción del workflow Retirar de la aprobación está diseñada para que esté disponible
para los tickets de cambio cuando el Estatus es Acción, el Código de motivo es
Aprobación pendiente, la Fase es Aprobación de CAB o Revisión del CAB y el Tipo de
cambio es Normal.
Debido a un error durante la configuración, la condición coincidente para Fase se
configura como Fase = Aprobación de CABRevisión del CAB en lugar de Aprobación de
CAB|Revisión del CAB. A causa de esta incorrección en las condiciones de coincidencia,
esta acción del workflow no estará disponible en el ticket en el estado deseado.
Solución:
Corrija la configuración para las condiciones de coincidencia, para que esté disponible
en el estado deseado:
1.
Haga clic en Gestionar acciones del workflow en Herramientas del workflow, en el
Se mostrará el formulario Gestionar acciones de workflow.
2.
Escriba Retirar cambio en la ventana de búsqueda para localizar la acción del
workflow.
Nota: Compruebe las condiciones de filtro para asegurarse de que la opción Tipo de
ticket esté configurada como Cambiar o Todo.
Hay dos acciones de workflow denominadas Retirar cambio, una con las
condiciones de coincidencia para el Tipo de cambio de emergencia y otra con
condiciones de coincidencia para el Tipo de cambio normal.
3.
En la lista, haga clic en la acción de workflow Retirar cambio.
Los detalles de la opción de acción de workflow se mostrarán en el siguiente
formulario. La ficha Condiciones coincidentes mostrará las condiciones de
coincidencia configuradas para la acción de workflow.
Si la acción seleccionada es para un cambio normal, se mostrará la configuración
incorrecta en las condiciones de coincidencia (Fase = Aprobación de CAB Revisión
del CAB). Haga clic en la condición de coincidencia existente y el formulario
siguiente se rellenará con los detalles disponibles. Este comportamiento se puede
modificar para corregir el error.
4.
Reconstruya las condiciones de coincidencia para la acción de workflow:
a.
Tipo de coincidencia = Incluir
b.
Estatus = Activo
Problemas conocidos
c.
Código de motivo = Aprobación pendiente
d.
Fase = Aprobación de CAB|Revisión del CAB
e.
Nota: El carácter | (pleca) permite definir más de una opción para un atributo
determinado, por ejemplo, Fase = Aprobación de CAB o Fase = Revisión del CAB.
5.
Haga clic en Aplicar cambios.
Las condiciones de coincidencia para la acción del workflow se mostrarán en el
campo.
6.
Revise las condiciones de coincidencia para garantizar que se hayan construido
correctamente.
La configuración necesaria para que la acción de workflow Retirar cambio tenga el
estado adecuado ha finalizado.
Para probar la configuración, cree un cambio Normal y procéselo hasta la fase
Enviar para la aprobación. Una vez que el cambio se haya enviado para su
aprobación, se debe mostrar la acción de workflow Retirar cambio.
No se ha relacionado ninguna plantilla de comunicación con la acción de
workflow Enviar para la aprobación
No hay ninguna plantilla de comunicación asociada con la acción de workflow Enviar
para la aprobación:
Las acciones de workflow Enviar para la aprobación no tienen asociadas plantillas de
comunicación para informar a los aprobadores y revisores sobre la acción que se está
ejecutando.
Se ha observado que los usuarios de las soluciones de gestión de servicios no desean
fomentar la práctica de aprobar las solicitudes de cambio mediante la respuesta a las
notificaciones de correo electrónico. Por ello, las plantillas de comunicación no están
relacionadas con esta acción del workflow por diseño.
Solución:
Hay dos plantillas de comunicación definidas por el sistema que se pueden utilizar para
informar a los aprobadores y revisores sobre un cambio que se haya enviado para su
aprobación:
■
Notificación del aprobador manual (ID -22)
■
Notificación del revisor manual (ID -23)
Esta plantilla se puede relacionar con algunas de las acciones de workflow Enviar para la
aprobación o con todas ellas.
Problemas conocidos
Por ejemplo, las plantillas de comunicación se pueden relacionar con la acción del
workflow Enviar para aprobación del gestor.
1.
Haga clic en Gestionar acciones del workflow en Herramientas del workflow, en el
Se mostrará el formulario Gestionar acciones de workflow.
2.
Escriba Enviar para aprobación del gestor en la ventana de búsqueda para localizar
la acción de workflow.
Nota: Compruebe las condiciones de filtro para asegurarse de que la opción Tipo de
ticket esté configurada como Cambiar o Todo.
3.
En la lista, haga clic en Enviar para aprobación del gestor.
Los detalles de la acción de workflow se mostrarán en el siguiente formulario. Se
puede usar la ficha Comunicaciones para relacionar las plantillas de comunicación.
4.
Haga clic en el botón Agregar plantilla de la ficha Comunicaciones.
Se mostrará la búsqueda de Plantillas de comunicación. Desde esta búsqueda se
pueden relacionar las comunicaciones con la acción de workflow.
5.
Marque la casilla de verificación Incluir los definidos por el sistema para incluir las
plantillas de comunicación definidas por el sistema en la lista y haga clic en Buscar.
Se mostrará una lista con las plantillas de comunicación disponibles.
6.
Seleccione las plantillas Notificación del aprobador manual y Notificación del revisor
manual en la lista y, a continuación, haga clic en Seleccionar.
Las plantillas de comunicación seleccionadas se relacionarán con la acción del
workflow y se enviará una notificación mediante estas plantillas a los contactos que
figuran como Aprobadores y Revisores para el ticket de cambio.
Aspectos que hay que tener en cuenta
Aspectos que hay que tener en cuenta
Además de lo explicado anteriormente, tenga en cuenta las siguientes limitaciones de
las configuraciones listas para usar:
■
No se ha probado la funcionalidad de la aplicación de la respuesta de correo
electrónico entrante para las notificaciones de tickets (por ejemplo, las
actualizaciones de los tickets como respuesta a la aprobación o al rechazo de un
ticket de cambio).
■
Tampoco se ha estudiado la funcionalidad de configurar varios buzones de correo y
relacionar uno de ellos con un tipo de ticket. Se supone que los correos electrónicos
darán lugar a la creación de una solicitud de servicio.
■
La categorización basada en CCTI de los tickets y los elementos de configuración, y
el uso de CCTI para crear enrutamientos automáticos de tickets no se han probado,
ya que el sistema de categorización varía de una organización a otra.
Al configurar nuevas acciones de workflow y enrutamientos automáticos o plantillas de
ticket usando el diseño existente, preste atención a lo siguiente:
■
El valor Fuente se ha usado como una condición de coincidencia para los distintos
tipos de tickets. Se ha agregado el valor nuevo Agente para el campo Fuente como
parte del diseño de workflow listo para usar. Hay que tener en cuenta esta
particularidad al configurar plantillas de ticket y acciones de workflow para
ajustarse al diseño de workflow existente.
■
El Código de motivo se ha configurado como condición de coincidencia para las
acciones de workflow y enrutamiento automático relacionadas con las solicitudes
de cambio. Hay que tener esto en cuenta al configurar plantillas adicionales,
acciones de workflow o reglas de enrutamiento automático.
■
Se deberán seguir con atención las definiciones de Fase y Código de motivo al
configurar registros adicionales, ya que los errores podrían provocar el fallo de los
enrutamientos automáticos o las acciones de workflow.

Guía de implementación rápida del workflow de CA Nimsoft Service

Transcripción

Documentos relacionados

H E CH O S : M anifiesta NO haber iniciado acciones administrativas

Guía de uso de Tickets de Soporte Para poder recibir soporte

Lección 13.1 WorkFlow. Concepto

a2 Punto de Ventas