Tratamiento del ticket y conceptos relacionados

Este artículo contiene los siguientes temas:

Como analista se trabaja ampliamente con tickets. Además de trabajar en un servicio solicitado, se pueden realizar varias acciones en un ticket. Se puede volver a clasificar un ticket que se basa en la naturaleza de la solicitud. Se puede determinar el progreso de la solicitud, los detalles de la solución de actualización del ticket y mucho más.

Como analista, se debe tener una visión general de los conceptos de gestión de tickets. Este artículo proporciona conceptos generales relacionados con el tratamiento de tickets en ServiceAide Cloud Service Management.

Proceso de gestión de tickets    

Se pueden registrar solicitudes nuevas enviando un correo electrónico al ID de soporte designado o desde la interfaz de usuario de la aplicación. Se pueden registrar solicitudes mediante un elemento del catálogo relevante del Catálogo de solicitudes. Las solicitudes se enrutarán automáticamente a distintos grupos de soporte en función de los siguientes criterios:

• Naturaleza de la solicitud
• Cómo se ha creado la solicitud
• Reglas de enrutamiento

El administrador gestiona y controla los permisos y las acciones de workflow disponibles. En función de la solicitud o de la incidencia, se puede crear un incidente, un problema, un cambio o una solicitud de servicio. También se puede crear un ticket de un tipo de ticket diferente de un ticket existente. El resultado es asegurarse de que la solicitud se gestiona mediante los procesos adecuados dentro de los acuerdos de entrega del servicio acordados.

Ticket y ciclo de vida del ticket

Un ticket es un documento de transacción que registra toda la información relacionada con una solicitud. Los campos del ticket contienen información necesaria para comprender y cumplir la solicitud del usuario final. El administrador puede configurar y agregar campos personalizados para que estén disponibles en el ticket y que se basan en la categorización del ticket. Una vez se haya creado el ticket; se asignará a un grupo de soporte. El administrador configura las reglas de asignación. Hay tres aspectos principales del progreso del ticket que se utilizan al generar el proceso de workflow:

• Fase: durante el ciclo de vida del ticket, el ticket pasa por diversas fases. En función de su progreso, el ticket puede pasar a una fase anterior. Las definiciones de fase difieren según el tipo de ticket.
• Estado: el estado hace referencia a la etapa actual del ticket en su ciclo de vida. Pueden ser Nuevo, En cola, Activo, Pendiente, Completado, Resuelto y Cerrado. Los estados de ticket fijos no se pueden modificar. Un ticket puede cambiar de un estado a otro, no necesariamente en un orden específico.
• Código de motivo: se utiliza para asignar el motivo por el que un ticket se encuentra en un determinado estado o fase. Por ejemplo, un ticket se puede establecer en estado pendiente por varios motivos como Cliente pendiente, Distribuidor pendiente o Información pendiente.

Se utiliza una combinación del estado del ticket y del código de motivo para gestionar las acciones del workflow disponibles y para gestionar el progreso del ticket. A medida que un ticket progresa, crece para incluir actividades hacia la resolución, cumplimiento y cierre de la solicitud. El progreso del ticket también incluye acciones manuales y automáticas y comunicaciones hacia y desde el ticket. El administrador puede configurar acciones del workflow distintas para que estén disponibles en el ticket para controlar el progreso del ticket.

Tipos de ticket

En CA Cloud Service Management, existen cinco tipos de tickets:

• Solicitud de servicio: se utiliza para registrar y gestionar las solicitudes estándar de los usuarios para obtener información o acceso a los sistemas y servicios. Las solicitudes de servicio se gestionan mediante procesos de workflow de cumplimiento de solicitudes de servicio y se monitorizan para su conformidad con el acuerdo de nivel de servicio. Por ejemplo, un usuario final busca obtener información sobre cómo instalar y configurar correos electrónicos de trabajo para dispositivos móviles.

• Ticket de incidente: se utiliza para comunicar y gestionar incidencias como una interrupción, falta de disponibilidad, reducción de la calidad de un sistema o del servicio. Los tickets del incidente se gestionan mediante procesos de workflow de gestión de incidentes. La respuesta y resolución de estos tickets se monitoriza para el cumplimiento del acuerdo de nivel de servicio. Por ejemplo, una solicitud se registra cuando el usuario final no puede enviar o recibir correos electrónicos desde el teléfono móvil. Este servicio normalmente está disponible para el solicitante y el servicio se ha interrumpido. Identifique la causa de la interrupción del servicio, restaure el servicio rápidamente y comuníquese con el solicitante sobre la resolución.

• Ticket de problema: se utiliza para investigar, resolver o mitigar incidencias principales que afectan a muchos usuarios. Los tickets del problema se gestionan mediante procesos de workflow de gestión de problemas. Por lo general, la resolución y el análisis de causa raíz toman tiempo y estos tickets pueden o no estar monitorizados para el cumplimiento del acuerdo de nivel de servicio.

• Petición de cambio: se utiliza para registrar y gestionar una petición de cambio en la infraestructura de TI o servicios. Algunos cambios pueden afectar solo al solicitante (o a un grupo pequeño de usuarios), mientras que otros afectan a muchos usuarios. Todas las peticiones de cambio pasan por un proceso de aprobación de cambio. Según la naturaleza del cambio, el proceso de aprobación varía y se gestiona mediante los procesos de workflow de gestión de cambios. Una petición de cambio puede monitorizarse para el cumplimiento del acuerdo de nivel de servicio. El tiempo necesario para responder y resolver un cambio se basa en factores como, por ejemplo, la obtención de la aprobación.

• Ticket de tarea: se utiliza para realizar un seguimiento y gestionar unidades más pequeñas de trabajo para la finalización de otro ticket. Un ticket de tarea se registra como un hijo de otro ticket. Un ticket de tarea generalmente es un ticket de cambio o problema. Cada tarea se puede gestionar de una vez por personas distintas o de manera secuencial.
  
  

Acciones de workflow y asignación automática de tickets

Las reglas de enrutamiento enrutan los tickets que se han creado recientemente a las colas de los grupos de soporte apropiados. El enrutamiento se basa en las condiciones coincidentes como la fuente o categorización de CCTI de prioridad.

El administrador gestiona y configura las acciones de workflow y las reglas de asignación automática responsables del progreso y de la asignación de tickets. Este progreso y la asignación de tickets se basan en el proceso de gestión de solicitudes que se ha definido para cada tipo de ticket.

• Asignación automática de tickets: son reglas de asignación automática que enrutan los tickets nuevos a las colas de los grupos de soporte adecuados en función de las condiciones coincidentes como la fuente y el CCTI de prioridad. La categorización de CCTI también es importante para generar informes. Las reglas de asignación establecen valores para campos como Fase, Estado y Código de motivo. Ciertas reglas de asignación disponen de plantillas de comunicación asociadas y se encargan de enviar notificaciones al crear un ticket y asignarlo a los interesados pertinentes. 

• Acciones del workflow: son un conjunto de acciones que se pueden llevar a cabo en un ticket. Cuando se ejecuta una acción del workflow en el ticket, algunos valores de campo se establecen tal y como se ha configurado y el ticket se mueve al estado siguiente. Las acciones del workflow son específicas de cada tipo de ticket y son un punto importante del diseño del workflow. Los workflows son acciones manuales que se hacen disponibles a los analistas asignando permisos a diferentes grupos de soporte o roles. Una acción del workflow está configurada y disponible en un ticket basándose en las condiciones coincidentes como Estado, Código de motivo y Fase. Algunas opciones de las acciones del workflow están disponibles sin ninguna condición coincidente en un ticket en cualquier estado.

Se pueden configurar también acciones del workflow para enviar notificaciones a los interesados. Algunos valores pueden configurarse como campos obligatorios antes de la ejecución de la acción del workflow. Algunas opciones de acción tienen funciones especiales asociadas, que pueden automatizar aún más la ejecución de una acción adicional (como, por ejemplo, Aceptar asignación o Reasignar).

Tipos de cambios y aprobación de cambio

El cambio se define como una adición, modificación o eliminación de un sistema o servicio de TI existente. El cambio puede formar parte de los sistemas de software o hardware, configuraciones, acceso y así sucesivamente. Un cambio puede ser reactivo (en respuesta a un problema) o proactivo (para evitar problemas potenciales o mejorar la entrega de servicios). Por ejemplo, la agregación o eliminación de usuarios de un sistema o grupo o el aprovisionamiento de los sistemas con una nueva contratación.

La petición de cambio se puede clasificar en los cuatro tipos siguientes:

• Cambio estándar: se recomienda este tipo de cambio para las solicitudes comunes. Por ejemplo, una solicitud de un empleado para la instalación de software o el acceso a un sistema o base de datos. Un aprobador contextual o un aprobador que se asocia con un elemento de configuración aprueba dichas solicitudes de .
• Cambio normal: este tipo de cambio se recomienda para implementar cambios proactivos y planificados. Por ejemplo, la implementación de nuevos sistemas de seguridad de TI que afecta al modo en que los usuarios acceden a los recursos de las TI mediante una VPN. Dicho cambio requiere una investigación completa, planes detallados de implementación de cambios, varios niveles de revisión y aprobación. Dicho cambio requiere tiempo de inactividad potencial durante la implementación y un cambio implementado durante la revisión posterior a la implementación.
• Cambio de emergencia: este tipo de cambio se recomienda para situaciones reactivas en las que implementar un cambio es necesario para corregir o evitar un problema más grave. Por ejemplo, si se produce un error en un servidor que conlleva un tiempo de inactividad para varios usuarios, debe reemplazarse el servidor defectuoso. En tales situaciones, es necesario tener un proceso de aprobación e implementación más rápido.
• Cambio de reparación: este tipo de cambio se utiliza normalmente para comunicar un cambio después de la implementación sin un proceso de aprobación. Por ejemplo, si se ha puesto en peligro la seguridad de un servidor, debe eliminarse de la red. Un cambio de reparación no pasa por un proceso de aprobación y solo se utiliza para registrar el cambio. La naturaleza de un cambio es diferente y requiere diferentes tipos de aprobaciones. Algunos cambios necesitan la aprobación por parte de un aprobador contextual como el gestor del solicitante; otros requieren varios niveles de aprobación. A veces se requiere la aprobación de uno o de todos los aprobadores. Se pueden asociar distintos tipos de aprobación con un ticket de cambio. Los tipos de aprobación que se pueden establecer son:
• Todos los aprobadores: cuando se selecciona este tipo de aprobación, TODOS los aprobadores deben aprobar el ticket. Si un aprobador (incluso uno que se encuentre entre todos los aprobadores asignados) rechaza el ticket, el proceso de aprobación finaliza rechazando el cambio.
• Cualquier aprobador: un cambio se aprobará en cuanto lo apruebe CUALQUIER aprobador. La aprobación se rechaza solamente cuando todos los aprobadores rechazan la propuesta.
• Cualquier aprobación o rechazo: un solo aprobador del grupo de aprobación rechaza o aprueba un cambio. Se aplica la decisión del primer aprobador que responde (aprobar o rechazar) al proceso de aprobación. El administrador configura las reglas para la aprobación de distintos tipos de cambio y los grupos de aprobación que se asocian con un cambio. En algunos casos, se pueden seleccionar manualmente los aprobadores para un cambio.

Elementos de configuración y servicios afectados

Un elemento de configuración es cualquier componente de una organización y su infraestructura de TI. Un elemento de configuración gestiona y ofrece un servicio de TI. Por ejemplo, hardware, software, dispositivos de red, periféricos y documentación. ServiceAide Cloud Service Management crea y gestiona un registro de todos los elementos de configuración de la organización. Por ejemplo, hosts de correo, servidores y equipos cliente con el software esencial son necesarios para proporcionar un servicio de correo electrónico. Se crea un registro de todos los servicios y se guarda como un elemento de configuración en ServiceAide Cloud Service Management.

Un elemento de configuración se puede relacionar con uno o más elementos de configuración en distintos dominios de relación como, por ejemplo, lógicos, de red, avanzado o del servicio. Esta información se puede utilizar para solucionar los problemas de algunas incidencias con el elemento de configuración. Cuando se registra un ticket para comunicar una incidencia sobre un elemento de configuración, el elemento de configuración puede relacionarse con el ticket. Por lo tanto, se crea un historial de todos los incidentes, problemas y cambios relacionados con el elemento de configuración que puede almacenarse y recuperarse. Si se registra un ticket para comunicar las incidencias con un servicio, el elemento de configuración relevante puede relacionarse con el ticket como servicio afectado.

Se pueden relacionar contactos con los elementos de configuración como propietario, usuario, aprobador del cambio, revisor de cambios y proveedor de soporte. Los contactos que se asocian como aprobador del cambio y revisor de cambios se utilizan como aprobadores contextuales para tickets de cambio que están relacionados con el elemento de configuración. El estado de un elemento de configuración indica si el elemento de configuración está en uso o no. El estado también especifica en qué etapa de su ciclo de vida está el elemento de configuración. Los elementos de configuración en todos los estados excepto Desprovisto están visibles para los analistas al relacionar un elemento de configuración con un ticket.

Relaciones del ticket

Las relaciones del ticket se refieren a los distintos tipos de registros que pueden estar relacionados con un ticket. Los tickets se pueden relacionar con otros tickets o elementos de configuración. También se pueden relacionar archivos adjuntos para obtener más información.

• Relación ticket-ticket: un ticket se puede relacionar con otro ticket de las tres maneras siguientes:
• Relación padre-hijo: cuando se crea un ticket nuevo desde un ticket existente, los dos tickets comparten una relación padre-hijo. Por ejemplo, si se crea un ticket de cambio a partir un ticket de problema. Se crea un ticket de tarea solo para unidades completas del trabajo hacia otro ticket existente. Un ticket de tarea se registra siempre como un ticket hijo.
• Relación de ticket global: cuando existen incidentes más pequeños que son el resultado de una incidencia mayor, el ticket que comunica la incidencia principal se puede marcar como Global. Otros incidentes se pueden relacionar con el incidente global. Por ejemplo, distintos usuarios registran varios tickets de incidente informando sobre pérdidas en la conectividad. Se registra un incidente que informa que el servidor de red tiene problemas de potencia, estas incidencias son todas debidas al incidente con el servidor de red. De esta forma, cuando se resuelve el servidor de red, se corrigen los incidentes relacionados. Por consiguiente, el ticket que se registra para el servidor de red se puede marcar como Global. Se pueden relacionar todos los otros incidentes con el ticket.
• Tickets relacionados: los tickets también pueden relacionarse entre ellos por otros motivos. Por ejemplo, dos tickets se registran para un elemento de configuración. El resolver un ticket da lugar o no a la resolución del otro ticket. Dos tickets pueden estar relacionados el uno con el otro. Los tickets relacionados permiten un acceso fácil y una mayor visibilidad de todas las incidencias que están conectadas a un elemento de configuración.
• Relación ticket-elemento de configuración: la base de datos de gestión de la configuración conserva los registros de todos los sistemas y servicios de TI. Los equipos de entrega de servicio y soporte de TI son compatibles con todos los servicios y sistemas de TI. Los tickets de servicios del equipo de soporte son normalmente por incidencias o para obtener ayuda para utilizar un elemento de configuración compatible en la CMDB. Uno o más elementos de configuración pueden relacionarse con un ticket cuando se registra, o en cualquier punto del ciclo de vida del ticket. Se puede hacer clic en un elemento de configuración y se pueden ver los detalles del registro. Se puede ver la relación entre un elemento de configuración y un ticket mediante el uso de la gráfica de relaciones de elementos de configuración.

Notificaciones y registro de actividades

Se recibe una notificación cuando se agrega un archivo adjunto a un ticket que está asignado al usuario. Cuando se agrega el archivo adjunto, también se almacena en el registro de actividades.  

Monitorización de conformidad del SLA

La gestión del nivel de servicio trata el proceso de negociación de acuerdos de nivel de servicio y garantiza que se cumplan. La gestión del nivel de servicio garantiza que todos los procesos, acuerdos y contratos de soporte son adecuados para los objetivos de nivel de servicio acordados. Los objetivos del servicio definen el tiempo que se ha adjudicado para una actividad especificada y se miden con la métrica del servicio. Un objetivo del servicio puede tener una o más reglas de umbral. Uno de los objetivos del servicio puede configurarse como umbral de incumplimiento para indicar que se ha infringido el acuerdo de nivel de servicio.

Factores como el horario comercial del grupo de soporte y la disponibilidad del servicio regulan la medida del acuerdo de nivel de servicio. El icono de progreso del objetivo del acuerdo de nivel de servicio muestra el progreso del estado del destino. El icono de progreso del objetivo del acuerdo de nivel de servicio también indica si un ticket se está acercando al incumplimiento o si ha infringido el objetivo del acuerdo de nivel de servicio.

El administrador configura las reglas de umbral y la monitorización del acuerdo de nivel de servicio de los tickets. El administrador también puede configurar acciones que se ejecutarán cuando se infringe una regla de umbral. Las acciones incluyen el envío de notificaciones a los diferentes interesados o el escalado del ticket al grupo de escalado siguiente.

Artículos de conocimiento y base de conocimiento

La gestión del conocimiento reúne, analiza y almacena conocimiento e información en una organización. Un artículo de conocimiento contiene información acerca de soluciones para problemas que ocurren con frecuencia, incidentes previamente registrados o instrucciones para configurar un servicio de TI. Los artículos de conocimiento también contienen noticias, detalles de la solución e información acerca de un sistema compatible o servicios. Los artículos de conocimiento se pueden poner a disposición de los usuarios asignando permisos a roles o grupos de soporte adecuados.

La base de conocimiento proporciona información sobre cómo tratar un incidente o problema que ha ocurrido previamente. La base de conocimiento puede utilizarse para acelerar el proceso de resolución de incidencias y mejorar la entrega de servicios.

Con los permisos necesarios, también se pueden crear artículos de conocimiento. Todos los artículos nuevos se crean en el estado Borrador. Una vez creados como borrador, todos los artículos de la base de conocimiento se pueden revisar, refinar y establecer como Aprobado. Una vez aprobado, un artículo se puede poner a disposición de diferentes grupos de soporte o roles. Se pueden sugerir también soluciones de tickets que se incluirán en la base de conocimiento. Los elementos de las soluciones se agregan a la base de conocimiento en el estado borrador.

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 que llevan a cabo. Una agrupación de contactos se utiliza para funciones como, por ejemplo, el enrutamiento de tickets basado en habilidades, la asignación de tickets y la aprobación de tickets. Los grupos de soporte se utilizan para acciones como notificaciones, permisos, aprobaciones, escalados del acuerdo de nivel de servicio y asignaciones.

Un rol es una agrupación de contactos y grupos de soporte que se basa en la cantidad de funciones que realizan. Por ejemplo, el rol de gestión de incidentes puede utilizarse para gestionar todas las funciones que están relacionadas con la gestión de incidentes. Los grupos de soporte que proporcionan soporte L1, L2 (o superior) y los supervisores que gestionan equipos de analistas pueden estar bajo este rol.

El administrador configura los permisos como, por ejemplo, el acceso a las plantillas de ticket, a las plantillas de comunicación, a las acciones del workflow y a los artículos de conocimiento. Se otorga permiso directamente o en virtud del grupo de soporte al que pertenece el usuario que ha iniciado la sesión. Un contacto puede relacionarse con varios grupos de soporte y roles. Un contacto hereda los permisos que se asignan a cada uno de los grupos de soporte relacionados o rol.

Organización y seguridad basada en la organización

ServiceAide Cloud Service Management admite una jerarquía de tres niveles organización-sitio-ubicación para la gestión de la información de la organización. Una organización puede tener varios sitios y cada sitio puede tener varias ubicaciones. Se pueden configurar varias organizaciones con sus propios sitios y ubicaciones en la misma instancia de la aplicación.

Los usuarios pueden relacionarse con una organización, un sitio web o un nivel de ubicación en la jerarquía. Mientras que los usuarios se pueden relacionar con varias organizaciones, una organización debe configurarse como Organización primaria para ese usuario. Varias funciones disponibles para un usuario que ha iniciado sesión como, por ejemplo, la capacidad de participar en la evaluación del servicio, se gestionan a nivel de la organización.

Se pueden consultar los tickets que registran los usuarios de diferentes organizaciones. Sin embargo, el administrador de la aplicación puede activar la seguridad basada en la organización para gestionar la capacidad de consultar y trabajar con tickets y elementos de configuración. Cuando se activa la seguridad basada en la organización, se pueden ver los tickets y los elementos de configuración que están relacionados con la organización a la que se pertenece. También se pueden ver los tickets que están relacionados con los grupos de soporte de los que el usuario es miembro.

Restricciones

• El número máximo de tickets que se pueden crear de forma simultánea es de 50. 

• Se pueden agregar hasta 25 archivos adjuntos a un ticket.

• Es posible crear un máximo de 1000 registros de trabajo para cada ticket.

• El número máximo de vistas basadas en roles que se pueden crear para cada tipo de ticket es 50.

• El número máximo de reglas de asignación automática que se pueden configurar para cada flujo de proceso es 500. 

• El número máximo de acciones del workflow que se pueden crear para cada tipo de ticket es 500.

• El número máximo de plantillas de campos personalizados que se pueden crear para cada tipo de ticket es 100.

• El número máximo de plantillas de ticket (elementos de catálogo) que se pueden crear para cada tipo de ticket es 1000.

• El número máximo de comunicaciones de correo electrónico saliente que se pueden enviar desde un ticket es 1000.