Following are several examples for cases some common and some more unique that describe concepts that should be taken in to account in the modeling process. These concepts may result with a more precise definition of the metrics and a stable framework.
Since the target field within the Metric definition is not mandatory, in cases where it is not defined, service-level reports are available for the Metric. However, no Service Level versus Target and Deviation reports are possible (since there is no target with which to compare the actual calculated service level). These types of Metrics are defined in cases where reports are required for information that is not part of actual contractual obligations.
Defining this type of Metric provides the user with all of the possible drill-down capabilities of reporting, as well as providing the Service Level Manager with the option of applying the measurements to a target at any stage in the future.
For Example:
The contractual guarantee is to provide 99% of network availability and report on the number of down times per each month.
Two Metrics are defined, one Metric is defined with a target of 99% for availability, and another Metric is defined for counting the number of down times for each month without a target. Both Metrics are reportable, but only the first has deviation calculations due to its contractual obligation.
Note: Another possible method for addressing this kind of situation is to use Business Logic outputs and free-form reporting on this data. However, this loses the drill-down capability of the report on the data as well as the option of using the simple report wizard. The advantage of using Business Logic outputs, on the other hand, is one of saving Engine power by having fewer Metrics.
For further information about this method refer to the Outputs-User Tables case study.
In the cases where a target is defined for a Metric, there are two possible ways of specifying the target. It can be specified as either a static or dynamic target. A static target is the most common scenario encountered, where the target can be an agreed-upon value valid for the duration of the contract.
For example:
Network availability should be no less than 98% every month.
The target in this case is 98%.
Alternatively, the target can depend on the previous months' performance, or just change its value throughout the year. There are many alternative situations which could be encountered here, but in general they are all implemented by way of a formula. CA Business Service Insight supports this feature by an additional function call from the standard Business Logic template. The target function can access other parameters from the context of the Business Logic and can support any possible scenario required.
For example, resolution time of tickets in the Helpdesk that depends on the Helpdesk load: The average resolution time for high priority tickets is 1 day if there are no more then 1000 tickets during the same month. If there are more then 1000 tickets issued in the helpdesk within the month, the average resolution time for high priority tickets is 2 days.
In this case, the Metric is defined as having a dynamic target that is evaluated within the Business Logic script according to the number of tickets issued that month.
Note: For details on the implementation method of dynamic target refer to the Implementing Dynamic Targets case study.
A Metric parameter is a value that can be addressed from within the Business Logic of the Metric and one which can be easily changed from the Metric definition without needing to change the actual code. It is used in place of the hard-coded value and can be easily changed.
It is important to identify metric parameters to easily identify the Business Logic modules and to create reusable content. In addition, Metric Parameters are accessible through the Contract Wizard which allows an end user to perform changes easily.
For example:
In the above obligation the target is a resolution rate of 24 hours and the severity level (Severity1) can be defined as a parameter.
In the above obligation, the time that is considered to be defined as down time can be defined as a parameter.
A Contract parameter is a value that can be addressed by all Metrics within a Contract. A Contract parameter can be used within the Metric using the same method as a Metric parameter but is instead defined as a dynamic parameter.
It is recommended to use a Contract Parameter when more then one metric requires using the same value. Another important incentive to use a Contract Parameter is for facilitating contract maintenance. Since parameters tend to change often and require updating within the system, it is easier to access a single location in the contract and change all parameters values concurrently than to access each metric in the contract and change the values of the parameters at the metric level.
Therefore, the most recommended modeling is to define the parameters in the contract level as Contract Parameters and to access their values through the Metric level dynamic parameters.
For an example, refer to the Helpdesk Performance case study.
|
Copyright © 2012 CA.
All rights reserved.
|
|