|
|
|
A continuación se incluyen varios ejemplos de casos, algunos comunes y otros más concretos, que describen conceptos que han de tenerse en cuenta en el proceso de modelado. Estos conceptos pueden resultar en una definición más precisa de las métricas y en un marco estable.
Puesto que el campo de destino dentro de la definición de la métrica no es obligatorio, si no se ha definido habrá informes de nivel de servicio disponibles para la métrica. Sin embargo, no es posible generar ningún informe de nivel de servicio frente a destino y desviación (puesto que no hay ningún destino con el cual comparar el nivel de servicio calculado real). Estos tipos de métricas se definen cuando se requieren informes para obtener información que no forma parte de las obligaciones contractuales.
Definir este tipo de métrica proporciona al usuario todas las capacidades de obtención de detalles necesarias en los informes, así como proporciona al gestor del nivel del servicio la opción de aplicar mediciones a un destino en el futuro, en cualquier etapa.
Por ejemplo:
La garantía contractual es proporcionar un 99 % de disponibilidad de la red e informar del número de tiempos de inactividad por cada mes.
Se definen dos métricas: una con un destino de 99 % de disponibilidad, y otra para contar el número de tiempos de inactividad para cada mes sin un destino. Se pueden emitir informes de las dos métricas, si bien sólo la primera tiene cálculos de desviación, debido a su obligación contractual.
Nota: Otro método posible para abordar este tipo de situación es utilizar salidas de lógica de negocios e informes de formato libre sobre estos datos. No obstante, esto impide la obtención de detalles de los datos en el informe, además de que no se puede utilizar el asistente de informes simples. La ventaja de utilizar salidas de lógica de negocios, por otra parte, es ahorrar potencia del motor gracias a un menor número de métricas.
Para obtener más información acerca de este método, consulte el caso práctico de Tablas de salidas de usuario.
Cuando se define un destino para una métrica, hay dos formas de especificar el destino. Se puede especificar como destino estático o dinámico. El destino estático es el escenario más común, donde el destino se puede acordar según un valor válido durante la duración del contrato.
Por ejemplo:
La disponibilidad de red no debe inferior a un 98 % todos los meses.
El destino en este caso es 98 %.
También, el destino puede depender del rendimiento en los meses anteriores, o simplemente cambiar su valor a lo largo del año. Se podrían dar muchas situaciones alternativas, pero en general se implementan todas por medio de una fórmula. CA Business Service Insight admite esta función gracias a la adición de una llamada de función adicional desde la plantilla de lógica de negocios estándar. La función de destino puede acceder a otros parámetros desde el contexto de la lógica de negocios y puede admitir cualquier escenario que haga falta.
Por ejemplo, el tiempo de resolución de los tickets en el servicio de Help Desk que depende de la carga del Help Desk: el tiempo de resolución promedio para tickets de prioridad alta es 1 día si no hay más de 1000 tickets durante el mismo mes. Si se emiten más de 1000 tickets en el Help Desk dentro del mes, el tiempo de resolución medio para los tickets de prioridad alta es 2 días.
En este caso, la métrica se define con un destino dinámico que se evalúa dentro del script de la lógica de negocios según el número de tickets emitidos ese mes.
Nota: Para obtener más detalles sobre el método de implementación de destinos dinámicos, consulte el caso práctico Implementación de destinos dinámicos.
Un parámetro de métrica es un valor que se puede abordar desde dentro de la lógica de negocios de la métrica y que se puede cambiar fácilmente desde la definición de la métrica, sin necesidad de cambiar el código en sí. Se utiliza en lugar del valor codificado y se puede cambiar fácilmente.
Es importante identificar los parámetros de la métrica para identificar con facilidad los módulos de lógica de negocios y crear contenido reutilizable. Además, a los parámetros de las métricas se puede acceder mediante el asistente del contrato, el cual permite que el usuario final realice cambios fácilmente.
Por ejemplo:
En la obligación anterior el destino es una tasa de resolución de 24 horas y el nivel de gravedad (gravedad 1) se puede definir como parámetro.
En la obligación anterior, el tiempo que se considera definido como tiempo de inactividad se puede definir como parámetro.
Un parámetro de contrato es un valor que pueden abordar todas las métricas dentro de un contrato. Dentro de la métrica se puede usar un parámetro de contrato que emplee el mismo método que un parámetro de métrica, si bien se define como parámetro dinámico.
Se recomienda utilizar un parámetro de contrato cuando haya más de una métrica que requiera utilizar el mismo valor. Otro incentivo importante para usar un parámetro de contrato es facilitar el mantenimiento del contrato. Dado que los parámetros tienden a cambiar a menudo y se tiene que actualizar dentro del sistema, es más fácil acceder a una sola ubicación en el contrato y cambiar todos los valores de los parámetros simultáneamente que acceder a cada métrica en el contrato y cambiar los valores de los parámetros a nivel de métrica.
Por lo tanto, el modelado más recomendado es definir los parámetros en el nivel de contrato como parámetros de contrato y acceder a sus valores a través de los parámetros dinámicos de nivel de métrica.
Para ver un ejemplo, consulte el caso práctico Rendimiento del Help Desk.
| Copyright © 2012 CA. Todos los derechos reservados. | Enviar correo electrónico a CA Technologies acerca de este tema |