Voici plusieurs exemples de cas courants ou plus spécifiques décrivant les concepts à prendre en compte dans le processus de modélisation. Ces concepts peuvent permettre d'obtenir une définition plus précise des métriques et une structure stable.
Puisque le domaine cible de la définition de métrique n'est pas obligatoire, lorsqu'elle n'est pas définie, des rapports de niveau de service sont disponibles pour la métrique. Toutefois, aucun rapport de niveau de service par rapport à la cible et à l'écart n'est possible (car il n'y a pas de cible permettant de comparer le niveau de service réel calculé). Ces types de métrique sont définis dans les cas où des rapports sont requis pour des informations qui ne font pas partie des obligations contractuelles réelles.
La définition de ce type de métrique permet à l'utilisateur de disposer de toutes les fonctions d'exploration possibles pour la génération de rapports, et offre au responsable de niveau de service la possibilité d'appliquer les mesures à une cible à tout moment à l'avenir.
Par exemple :
La garantie contractuelle est d'assurer 99 % de disponibilité du réseau et de générer des rapports sur le nombre d'interruptions par mois.
Deux métriques sont définies, l'une avec une cible de 99 % de disponibilité, et l'autre pour compter le nombre d'interruptions pour chaque mois sans cible. Les deux métriques peuvent être intégrées à un rapport, mais seule la première comporte des calculs de déviation à cause de son obligation contractuelle.
Remarque : Une autre méthode possible pour résoudre ce type de situation est d'utiliser des formats de sortie de logique applicative et des rapports libres sur ce type de données. Toutefois, cela ne permet plus la capacité d'exploration du rapport sur les données, ni la possibilité d'utiliser l'assistant de création de rapports simples. L'avantage de l'utilisation de sorties de logiques applicatives est d'autre part d'économiser l'utilisation du moteur, en ayant un nombre de métriques plus restreint.
Pour toutes autres informations sur cette méthode, consultez l'étude de cas Sorties-Tables utilisateur.
Dans les cas où une cible est définie pour une métrique, il existe deux façons possibles de spécifier la cible. Vous pouvez la spécifier comme cible statique ou dynamique. Les cibles statiques sont les plus utilisées : il peut s'agir d'une valeur convenue valide pendant toute la durée du contrat.
Par exemple :
La disponibilité de réseau ne doit pas être inférieure à 98 % tous les mois.
La cible dans ce cas est 98 %.
De même, la cible peut dépendre des performances des mois précédents ou juste changer de valeur au cours de l'année. Il existe beaucoup d'autres situations que vous êtes susceptible de rencontrer ici, mais en général toutes sont implémentées avec une formule. CA Business Service Insight prend en charge cette fonctionnalité par un appel à une fonction supplémentaire du modèle de logique applicative standard. La fonction cible peut accéder à d'autres paramètres dans le contexte de la logique applicative et peut prendre en charge tous les scénarios possibles requis.
Par exemple, le temps de résolution des tickets dans le centre d'assistance, qui dépend de la charge du centre d'assistance : le temps moyen de résolution des tickets haute priorité est de 1 jour s'il y a moins de 1 000 tickets au cours du même mois. S'il y a plus de 1 000 tickets envoyés au centre d'assistance dans le mois, le temps de résolution moyen des tickets haute priorité est de 2 jours.
Dans ce cas, la métrique est définie comme ayant une cible dynamique, évaluée dans le cadre du script de logique applicative en fonction du nombre de tickets émis pour ce mois.
Remarque : Pour plus de détails sur la méthode d'implémentation de cibles dynamiques, consultez l'étude de cas Implémentation de cibles dynamiques.
Un paramètre de métrique est une valeur pouvant être résolue depuis la logique applicative de la métrique et qui peut facilement être modifiée depuis la définition de la métrique, sans nécessité de modifier le code proprement dit. Il est utilisé à la place de valeurs codées en dur et peut facilement être modifié.
La spécification de paramètres de métrique est primordiale pour l'identification des modules de logique applicative et pour la création de contenu réutilisable. De plus, les paramètres de métriques sont accessibles à travers l'assistant de création de contrats qu'admet qu'un utilisateur final à effectuer change facilement.
Par exemple :
Dans l'obligation ci-dessus, la cible est un taux de résolution de 24 heures et vous pouvez définir le niveau de sévérité (Severity1) comme paramètre.
Dans l'obligation ci-dessus, vous pouvez définir comme paramètre la période devant être considérée comme une interruption.
Un paramètre de contrat est une valeur pouvant être résolue par toutes les métriques d'un contrat. Vous pouvez utiliser un paramètre de contrat dans la métrique à l'aide de la même méthode que pour un paramètre de métrique, mais en le définissant comme paramètre dynamique.
Il est recommandé d'utiliser un paramètre de contrat lorsque plusieurs métriques nécessitent l'utilisation de la même valeur. D'autre part, l'utilisation de paramètres de contrat permet de faciliter la gestion des contrats. Puisque les paramètres ont tendance à changer souvent et exigent d'être actualisés dans le système, il est plus facile d'accéder à un seul point du contrat et de modifier tous les paramètres en même temps que d'accéder à chaque métrique du contrat et de modifier les valeurs des paramètres au niveau de la métrique.
Par conséquent, la modélisation la plus recommandée consiste à définir les paramètres dans le niveau du contrat en tant que paramètres de contrat et d'accéder à leurs valeurs via les paramètres dynamiques au niveau de la métrique.
Pour obtenir un exemple, consultez l'étude de cas Performances d'assistance.
|
Copyright © 2013 CA.
Tous droits réservés.
|
|