Page Comparison

...

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 CA en ServiceAide Cloud Service Management.

...

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.

...

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.
  
  

...

• 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. CA  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 CA en ServiceAide Cloud Service Management.

...

Organización y seguridad basada en la organización

CA Cloud 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.

...