Guía de implementación › Ejemplos de casos prácticos › Ejemplos de modelado de datos › Caso práctico 8: Rendimiento del servicio de asistencia

Caso práctico 8: Rendimiento del servicio de asistencia

Es un caso práctico típico sobre el rendimiento del servicio de asistencia.

Tenemos el origen de datos mostrado a continuación:

El origen de los datos mostrado anteriormente indica los detalles de los tickets del servicio de asistencia que se gestionan para cada cliente en las diversas ubicaciones de servicios de atención al cliente. Una sola ubicación se puede compartir también entre clientes.

Los tres requisitos siguientes son obligatorios para crear los informes al utilizar este origen de datos:

• % de tickets de prioridad 1 resueltos en cuatro horas para clientes CM3.
• % de tickets de prioridad 1 resueltos en cuatro horas para clientes CM3 en cada ubicación.
• % de tickets de prioridad 1 cerrados en un día para clientes CM3 en cada ubicación.

Los requisitos anteriores indican que los eventos se deben filtrar por:

• prioridad
• cliente
• ubicación

Es necesario especificar cuáles de estos criterios de filtrado se traducen como un tipo de evento y cuál será el recurso relevante.

¿Cómo selecciono un tipo de evento?

De los tres criterios de filtrado necesarios, la prioridad del ticket es la más apropiada para que se traduzca al tipo de evento por las siguientes razones:

• Describe el tipo de evento que se está tratando (tickets de prioridad 1).
• El número de las distintas prioridades que existen es relativamente pequeño (prioridad 1, 2, 3).
• El tipo de evento en sí mismo es relativamente constante (el servicio de asistencia raramente cambia las prioridades con las que trata los tickets).

¿Cómo se selecciona un recurso?

Los otros dos criterios de filtrado obligatorios son el cliente y la ubicación y estos son las entidades más pequeñas que requieren la creación de informes. Por lo tanto, la combinación del cliente y la ubicación es el recurso.

El cliente y la ubicación son entidades relativamente fijas y tienen un ciclo de vida definido, por lo que se pueden agregar clientes nuevos o sitios nuevos. Además, la relación entre un sitio y un cliente puede cambiar.

Por motivos de traducción, es posible utilizar más de un campo del origen de datos. Mientras que en el anterior caso práctico el campo de servidor se traducía a un recurso de CA Business Service Insight, en este caso el recurso se construye mediante la combinación de dos campos. Cada permutación, por lo tanto, produce un nuevo recurso.

La lista de recursos se muestra a continuación:

El recurso de salida es una combinación del cliente y los campos de sitio utilizando el símbolo '+' para combinarlos. Es importante tener en cuenta el nombre del recurso, ya que se extrajo del origen de datos y aparece posteriormente en los informes. Las capacidades de creación de informes tienen que cubrir unas expectativas.

Nota: Uno de los errores más comunes durante el modelado de un servicio de asistencia o cualquier ticket o sistema de incidencia es definir un único incidente como un recurso.

Los siguientes supuestos incorrectos conducen a menudo a errores:

1. El único incidente es aquel del que se informa. No establezca la entidad que se tiene que comunicar como la entidad para la cual se generan los cálculos, de forma que la única incidencia no es la base de los cálculos del sitio del cliente. En general, el acuerdo de nivel de servicio está basado en el rendimiento global, y no en el rendimiento del tratamiento del ticket individual.
2. La garantía es por nivel de ticket. Esto es un error porque las garantías son periódicas, lo que se calcula es una agregación con el tiempo.

Cómo establecer asignaciones para los recursos

Para el primer requisito del cálculo:

1. % de tickets de prioridad 1 resueltos en cuatro horas para clientes CM3.
   • Es necesario recibir los eventos de los tickets que se pueden atribuir a un cliente específico. El cliente forma parte de este recurso, que también indica el sitio del cliente. Por lo tanto, para capturar todos los eventos relacionados con recursos y que se pueden atribuir a ese cliente, hay dos opciones:
   • En los casos en los que el cliente en el origen de datos representa una parte contratante, los recursos pueden estar adjuntos a la parte contratante relevante. Esto permite realizar el registro por parte contratante. Siempre que es posible, esto es siempre preferible.
   • Cree un grupo de recursos para cada uno de los clientes del origen de datos y agrupe todos los recursos relevantes dentro de este. Mediante este método, el registro se realiza por grupo de recursos.

   Para los dos requisitos de cálculo siguientes:

2. % de tickets de prioridad 1 resueltos en cuatro horas para clientes CM3 en cada ubicación.
3. % de tickets de prioridad 1 cerrados en un día para clientes CM3 en cada ubicación.

Para estos requisitos, recopile los recursos en grupos de recursos. Esto es así porque las métricas tienen que estar en clúster ya que el cálculo es necesario para cada sitio individualmente.

Nota: Aunque las asignaciones de recursos para el modelo actual y los requisitos no sean necesarios, es importante crearlos teniendo en cuenta los requisitos futuros. Hacer esto evita las sobrecargas en el futuro desarrollo del sistema.

Selección del campo Marca de tiempo

Como se ha mencionado previamente, la marca de tiempo es muy importante para la forma en la que el motor de correlación trata los Eventos. Las métricas siempre calculan el nivel de servicio por período de tiempo y los eventos que se procesan en ese período de tiempo son aquellos cuya marca de tiempo está dentro de dicho período.

En el primer caso práctico, el origen de datos solamente tiene un campo de tiempo. Sin embargo en este caso hay tres posibles campos que se pueden establecer como la marca de tiempo. Vamos a examinar los dos primeros registros:

Para calcular el tiempo de resolución, se necesitan el campo Creado el y Resuelto el. Para los objetivos del evento, es posible adjuntarle solamente una marca de tiempo. Así la otra se puede utilizar como un valor dentro de los campos de valor.

Si el valor de Creado el se utiliza como la marca de tiempo, el ticket se incluye en los resultados de diciembre. Si el valor de Resuelto el se utiliza como la marca de tiempo, el ticket se incluye en los resultados de enero. Las dos opciones son válidas. La selección sólo tiene que cumplir las expectativas en cuanto al lugar en el que deberían aparecer los tickets en los informes.

Es un punto muy importante que hay que considerar durante la implementación, ya que determina cuándo se utilizan los eventos para los cálculos. Por ejemplo, si un ticket se crea en noviembre, pero no se cierra hasta diciembre, ¿cuándo debería influir en el resultado del acuerdo de nivel de servicio? ¿Va a los datos de noviembre o de diciembre?

En este caso, como el ticket se comunica al origen de datos solamente después de cerrarse, los datos se pueden capturar sólo después de que el ticket se cierre. Normalmente la fecha de cierre es posterior a las fechas de creación y resolución. En un caso en el que la fecha de creación se elige como la marca de tiempo, debería procesarse como parte de los resultados de diciembre. La fecha de cierre fue en enero, lo que significa que diciembre ya había pasado cuando este ticket se comunicó. Por consiguiente, los resultados de diciembre ya se habían publicado. El motor de correlación se da cuenta de que el evento ocurrió con posterioridad porque la marca de tiempo pertenece a diciembre y activa el recálculo. Por lo tanto, los resultados de diciembre cambian retroactivamente.

Estas consecuencias deben entenderse completamente para poder definir qué campo de tiempo se deberá elegir como una marca de tiempo. Normalmente, la fecha de cierre se elige para tener informes finales que no cambien retroactivamente.

Por otra parte, al utilizar la fecha de cierre como la marca de tiempo se retrasa la introducción del ticket en los cálculos. Un ticket que se ha resuelto se puede cerrar solamente en un tiempo sustancial más tarde.

Sea consciente sin embargo, que este uso de la fecha de cierre podría activar también un proceso en la organización que acelerase el tiempo de cierre de los tickets.

Por tanto, la sugerencia final es: