Implementierungshandbuch › Beispiele für Fallstudien › Vertragsbildungsbeispiele › Fallstudie 3: System-Reaktionszeit

Fallstudie 3: System-Reaktionszeit

Folgende Fallstudie stellt die Antwortzeit von Metriken dar. Ein Vertrag kann auf unterschiedliche Art und Weisen gebildet werden, jede mit seinen Vorteilen.

Das folgende Beispiel prüft verschiedene Bildungsmethoden:

Wie wird das aktuelle Service Level basierend auf die obige Matrix berechnet?

Basierend auf die Definition der Domänenkategorie, scheint es, dass das eigentliche Service Level als Maximalwert berechnet wird. Dies bedeutet, dass die Transaktion mit dem Maximalwert für alle während eines Monats ausgeführten Transaktionen aufgezeichnet und dieser Wert mit dem Ziel verglichen wird.

Hinweis: Die Berechnung des Service Levels basiert auf eine Aggregation von Rohdaten über einen bestimmten Zeitraum. Für jeden Zeitraum gibt die Metrik ein einzelnes Ergebnis aus. Das Ziel einer Metrik wird mit nicht mit einer einzelnen Transaktion, sondern mit einem monatlichen Ergebnis verglichen, das eine periodische Aggregation aller Transaktionen innerhalb dieses Zeitraums ist. Der Vertragsmanager muss sicherstellen, dass dieses Ergebnis den Vertrag auf der einen Seite und die Servicequalität auf der anderen widerspiegelt.

Beachten Sie, dass die gemessene Antwortzeit, wie ein Maximalwert, eine sehr strikte Verpflichtung ist und sehr schwierig in der Praxis zu erreichen sein wird. Bemessung an einem Höchstwert bedeutet, dass eine einzelne Transaktion von 751 ms aus einer Million, während des Ablaufs von einem Monat, durchgeführten Transaktionen lang genug ist, einen Vertragsbruch zu verursachen. Alle Balken in den Berichten werden deshalb rot sein und nicht den wirklichen Stand des Service wiedergeben, der angegeben wurde.

Die folgende Abbildung stellt einen typischen Bericht unter diesen Umständen dar.

Eine Transaktion, die das Ziel überschreitet, wird als ein Vertragsbruch betrachtet, aber als Basis dafür, zu verstehen, dass die eigentliche Servicequalität besorgniserregend ist, da es nur eine einzelne Transaktion widerspiegelt und nichts im Bezug auf den Rest der Transaktionen bekannt ist, so wie: War es ein einzelner Fehler oder ein Trend? Wenn es kein Einzelfall ist, wie viele Fehler waren dann vorhanden, oder wie ist das Verhältnis von fehlerhaften Transaktionen zur Gesamtzahl der innerhalb des Monats ausgeführten Transaktionen? Es kann eine Reihe von Monaten mit solchen Vorkommnissen geben und daher ein Vertragsbruch sein, aber wie ist der Trend? Verbessert er sich oder wird er schlechter? All das sind Fragen, die der Service Level-Manager fragen könnte und die der Bericht beantworten können sollte.

Hinweis: Bei der Definition der Metrik und ihren zugeordneten Berechnungsentwurf, ist es sehr wichtig, sich vorzustellen, wie die Ergebnisse in einem Bericht angezeigt werden. Dieser Bericht muss zwei entscheidende Elemente angeben:

• Hat es hat einen Vertragsbruch gegeben?
• Er muss Managern genug Datentransparenz zur Verfügung stellen und ihnen die Fähigkeit verschaffen, die Ursache des Fehlers zu untersuchen und auch Managern die notwendigen Tools bereitstellen, um dessen Servicekomponenten vollständig verstehen zu können.

Die Berechnung der durchschnittlichen Antwortzeit gibt eine bessere Vorstellung der monatlichen Servicequalität, und dennoch können gleichzeitig noch jene Monate mit extremen oder Außerhalb-von-Vertrag-Antwortzeiten wiedergeben.

Bei der Verwendung dieser Methode wird bei der Berechnung der Prozentsatz der Transaktionen, die erfolgreich unter dem Grenzwert von 750 ms während des angegebenen Zeitraums abgeschlossen wurden, von dieser Formel errechnet:

((Anzahl von Transaktionen unter 750 ms.)/(Gesamtanzahl der Transaktionen))*100

Das Ausdrücken einer Garantie als Erfolgsrate ermöglicht es, eine strikte Garantie beizubehalten (Ziel 100 %), wobei der tatsächliche Istwert darstellt, wie gut oder schlecht der Service war.

Mit dieser Methode ist das Ziel zwar nicht die Obergrenze von 750 ms, aber das beizubehaltende Verhältnis. In Fällen, wo die Garantie streng ausgelegt werden muss, sollte das Ziel dann 100 % sein, welches dann keinen Platz für auch nur einen einzelnen Fehler zulässt. Beachten Sie, dass eine zusätzliche Variable in diesem Fall eingeführt wurde, der Metrikparameter. Dieser Parameter sollte als ein Metrikparameter implementiert werden, um einfache Anpassungen bei Bedarf zu aktivieren.

Ein alternatives Modell zu dieser Methode kann die Erzwingung eines Eskalationstypenmodells sein:

Die folgenden Lösungen definieren drei Metriken anstelle einer einzelnen Metrik, wie in den bisherigen Lösungen.

In einem Fall, wo es notwendig ist, über die vertragliche Verpflichtung ebenso wie über die Anzahl an Transaktionen zu berichten, die den Grenzwert von 750 ms überschreiten, müssen Sie eine zusätzliche Metrik angeben, um die Anzahl von fehlgeschlagenen Transaktionen zu zählen.

Hinweis: Jede Metrik generiert ein einzelnes Ergebnis über einen bestimmten Zeitraum. Wenn sie festgelegt wird, um den Prozentsatz von Transaktionen zu berechnen, kann sie nicht auch die Anzahl der Transaktionen angeben.

Sie können zusätzliche Berichte nur aus einer Metrik erzeugen, indem die Ausgaben der Business-Logik verwendet werden. (Siehe Outputs - User Tables, welche die Ausgabeergebnisse der Business-Logik behandelt).