Nachfolgend sind einige Beispiele für häufige und auch speziellere Fälle aufgeführt, die Konzepte beschreiben, die im Modellierungsprozess beachtet werden sollten. Diese Konzepte können eine präzisere Definition der Metriken und ein stabileres Framework ergeben.
Da das Zielfeld innerhalb der Metrik-Definition nicht obligatorisch ist, sind Service Level-Berichte in Fällen, in denen das Zielfeld nicht definiert ist, für die Metrik verfügbar. Es sind jedoch keine Berichte über den Service Level im Vergleich zum Ziel und zur Abweichung möglich (da es kein Ziel gibt, mit dem der tatsächlich berechnete Service Level verglichen werden könnte). Diese Metriktypen werden für die Fälle definiert, in denen Berichte für Informationen erforderlich sind, die nicht Teil der eigentlichen vertraglichen Verpflichtungen sind.
Durch die Definition dieses Metrik-Typs erhält der Benutzer alle möglichen Drilldown-Berichterstellungsoptionen. Zugleich erhält der Service Level-Manager die Möglichkeit, die Messungen in jeder künftigen Phase auf ein Ziel anzuwenden.
Zum Beispiel:
Die Vertragsgarantie lautet, 99 % der Netzwerkverfügbarkeit bereitzustellen und die Ausfallhäufigkeit pro Monat zu dokumentieren.
Es sind zwei Metriken definiert, eine Metrik wird mit dem Ziel 99 % Verfügbarkeit definiert, die andere Metrik wird für das Zählen der monatlichen Ausfallhäufigkeit ohne Ziel definiert. Die Berichterstellung ist für beide Metriken möglich, nur die erste verfügt jedoch aufgrund der vertraglichen Verpflichtung über Abweichungskalkulationen.
Hinweis: Eine andere mögliche Methode für das Bewältigen dieser Art von Situation besteht darin, Business-Logik-Ausgaben und Freitext-Berichterstellung für diese Daten zu verwenden. Allerdings verliert der Bericht dadurch die Möglichkeit zur Verfeinerung der Daten, wie auch die Möglichkeit, den einfachen Berichtsassistenten zu verwenden. Der Vorteil, Business-Logik-Ausgaben verwenden zu können, besteht jedoch darin, Engine-Leistung zu sparen, da weniger Metriken vorhanden sind.
Weitere Informationen zu dieser Methode finden Sie in der Fallstudie Ausgaben - Anwendertabellen.
In den Fällen, in denen ein Ziel für eine Metrik definiert ist, gibt es zwei Möglichkeiten zur Festlegung des Ziels: Es kann entweder als statisches oder als dynamisches Ziel festgelegt werden. Ein statisches Ziel ist das gängigste Szenario, wobei das Ziel ein Wert sein kann, auf den man sich geeinigt hat und der für die Dauer des Vertrages gültig ist.
Zum Beispiel:
Die Netzwerk-Verfügbarkeit sollte monatlich nicht weniger als 98 % betragen.
Das Ziel ist in diesem Fall 98 %.
Alternativ kann das Ziel von der Leistung der Vormonate abhängen, oder seinen Wert im Laufe des Jahres verändern. Es gibt viele mögliche Situationen, die im Allgemeinen jedoch alle über eine Formel implementiert sind. CA Business Service Insight unterstützt diese Funktion durch einen zusätzlichen Funktionsabruf von der Business-Logik-Standardvorlage. Die Zielfunktion kann im Rahmen der Business-Logik auf andere Parameter zugreifen und kann jedes erforderliche Szenario unterstützen.
Beispiel: Die Bearbeitungszeit von Anfragen am Helpdesk, die von der Helpdesk-Auslastung abhängt: Die durchschnittliche Bearbeitungszeit für Anfragen hoher Priorität ist 1 Tag, wenn es nicht mehr als 1000 Anfragetickets pro Monat gibt. Wenn innerhalb eines Monats mehr als 1000 Anfragetickets am Helpdesk ausgestellt werden, beträgt die durchschnittliche Lösungszeit für Anfragen hoher Priorität 2 Tage.
In diesem Fall ist die Metrik als dynamisches Ziel definiert, das innerhalb des Business-Logik-Skripts gemäß der Anzahl der in diesem Monat ausgestellten Anfragetickets ausgewertet wird.
Hinweis Weitere Einzelheiten zur Implementierungsmethode von dynamischen Zielen finden Sie in der Fallstudie Implementieren dynamischer Ziele.
Ein Metrikparameter ist ein Wert, der innerhalb der Business-Logik der Metrik angesprochen werden kann und der durch die Metrikdefinition auf einfache Weise geändert werden kann, ohne dass der eigentliche Code verändert werden muss. Er wird verwendet, um den hartcodierten Wert zu ersetzen, und er lässt sich leicht ändern.
Es ist wichtig, Metrikparameter zu identifizieren, um so die Business-Logik-Module auf einfache Weise identifizieren und wiederverwendbare Inhalte erstellen zu können. Darüber hinaus kann über den Vertragsassistenten auf Metrikparameter zugegriffen werden, wodurch der Endbenutzer leicht Änderungen vornehmen kann.
Zum Beispiel:
In der oben aufgeführten Verpflichtung besteht das Ziel in einem Klärungszeitraum von 24 Stunden, und der Schweregrad (Severity1) kann als Parameter festgelegt werden.
In der oben aufgeführten Verpflichtung kann die Zeit, die als Ausfallzeit gilt, als Parameter definiert werden.
Ein Vertragsparameter ist ein Wert, der von jeder Metrik innerhalb eines Vertrags angesprochen werden kann. Ein Vertragsparameter kann innerhalb einer Metrik verwendet werden, die dieselbe Methode wie ein Metrikparameter verwendet, wobei dieser stattdessen als dynamischer Parameter definiert ist.
Die Verwendung eines Vertragsparameters wird empfohlen, wenn mehr als eine Metrik denselben Wert benötigt. Ein anderer wichtiger Grund zur Verwendung eines Vertragsparameters besteht in der Vereinfachung der Vertragspflege. Da sich Parameter in der Regel häufig ändern und dadurch Aktualisierungen innerhalb des Systems erforderlich machen, ist es einfacher, auf einen einzigen Speicherort im Vertrag zuzugreifen und alle Parameterwerte gleichzeitig zu ändern, als auf jede Metrik im Vertrag separat zuzugreifen und die Werte der Parameter auf der Metrik-Ebene zu ändern.
Daher besteht die am meisten empfohlene Modellierung darin, die Parameter auf Vertragsebene als Vertragsparameter zu definieren und auf ihre Werte über die dynamischen Parameter auf der Metrik-Ebene zuzugreifen.
Ein Beispiel finden Sie in der Fallstudie Helpdesk-Leistung.
|
Copyright © 2013 CA.
Alle Rechte vorbehalten.
|
|