WebSphere Business Space powered by WebSphere, Version 6.2.0


Key performance indicators (KPIs)

Key performance indicators (KPIs) are quantifiable measurements of the improvement or deterioration in the performance of an activity critical to the success of a business. They enable you to measure essential activities of your business so that you can see how these activities influence business results. For example, in a call center, the timely answering of customer calls is a key business activity. A KPI could be Average time for response to a customer call for the last 30 days. This KPI could have a target of less than one minute.

KPIs are usually aggregations of values across many instances, where the aggregation function can be average, maximum, minimum, sum, count (number of occurrences), or standard deviation. KPIs can also be based on expressions; for example, a Profit KPI could be a Revenue KPI minus an Expenses KPI.

When selecting business activities to monitor with KPIs, choose those that reflect the goals of your business, are critical to its success, and permit corrective action through early detection of problems. You can use KPIs to measure aspects of your business in relation to defined targets and sets of ranges. In WebSphere® Business Monitor, KPIs are compared with the target and ranges to determine the level of success.

When to use modeled KPIs vs dashboard KPIs

You can define KPIs either in the Monitor Model editor or on the WebSphere Business Monitor dashboards. If you model the KPIs in the Monitor Model editor, there are some restrictions on the changes you can make in the dashboards.

You create KPIs in the model for any of the following reasons:
  • KPIs created in the model (modeled KPIs) represent the intent of the organization that authored the model. These KPIs can come from WebSphere Business Modeler and can, therefore, carry the intent of the business owner. The KPIs that are created in the dashboards, although they can be used for the same purpose, can also be defined as needed for personal or temporary what-if analysis.
  • Modeled KPIs are portable, making it simpler to deploy models with KPIs across environments.
  • Modeled KPIs reduce the amount of configuration that is required after deploying a monitor model.
  • The Monitor Model editor provides access to a KPI library of typically used KPIs, categorized according to the type of process to which they apply. Selecting a KPI from the library creates a KPI with that name in the monitor model. The KPI library is based on APQC's Process Classification Framework (PCF). APQC is a member-based nonprofit organization that provides benchmarking and best practices for approximately 500 organizations worldwide in all industries. PCF organizes operating and management processes into twelve enterprise-level categories and more than 1,500 processes and associated activities. PCF provides organizations with a shared language for communicating with each other.
KPIs that you model in the Monitor Model editor can be personalized in the dashboards but have the following restrictions:
  • The number of ranges and the IDs of those ranges cannot be changed because the trigger conditions of triggers in the model might refer to them. However, the ranges are still configurable at run time. The target and range values are treated as initial values so that they can be changed to reflect changes in business conditions.
  • A target cannot be set to null at run time, again because the trigger conditions of triggers in the model might refer to it.

Targets and ranges

A KPI can have a target, which is the exact value that the KPI should achieve. It can also have ranges, each of which is a span of possible values. Ranges can be specified either as a percentage of the target value or as an actual value. For each range, you specify the start value and the end value.

If your KPI were Average time for response to a customer call for the last 30 days and your target were less than one minute, you might decide not to set an exact target. Instead, you might set several ranges, as shown in the following table.
Start value End value Name
0 30 seconds Excellent
30 seconds 1 minute Good
1 minute 2 minutes Fair
2 minutes 10 minutes Poor
If your KPI were Average order amount and your target were $300, you might want to use percentages as ranges. You would set the target value as 300, but for the purposes of the ranges, the target is treated as 100%. You might set the ranges as shown in the following table.
Start value End value Name
0% 75% Unacceptable
75% 90% Good
90% 110% Excellent

For several ranges to work properly, the start element of each row must equal the end element of the previous row, as shown in both examples.

For each target and each set of ranges, you can specify a name, a description, and an ID. Use the ID to reference this target or set of ranges from another element, such as from a trigger. For example, a trigger that fires when the average order amount drops into the Unacceptable range might have the following condition:
avgOrderAmount < avgOrderAmount/unacceptable/endValue
where avgOrderAmount is the ID of the KPI and unacceptable is the ID of the range.

You can also specify a color for each range. For example, you might want the unacceptable range to be red, the good range to be yellow, and the excellent range to be green.

The values for target and ranges that you specify in the Monitor Model editor are the initial values. An administrator can modify the target and personalize the ranges for KPIs that will be used in a dashboard. A user of a dashboard can also personalize the ranges. Triggers that reference these ranges will use the new value the next time the trigger is evaluated.

Values

KPIs get their values at run time in one of two ways: either the value comes from a metric using an aggregation function, or the value comes from a calculation based on other KPIs or user-defined XPath functions. In the dashboards, these KPIs are called Aggregate KPIs and Expression KPIs.

Aggregate KPIs are based on a metric and an aggregation function, which can be average, maximum, minimum, sum, number of occurrences, or standard deviation. The following examples show some KPIs based on the aggregation of a metric:
Shipment duration KPI
For a delivery process, define an instance-level metric named shipmentDuration that calculates the time to deliver each order by subtracting the shipment date from the delivery date. Define a KPI that calculates the average value of these metrics. Use a sliding interval of 90 days, and define a target value of 5 days for the KPI.
Average order amount KPI
For an order-handling process, define an instance-level metric named orderTotal that tracks the amount of each order. Define a KPI that calculates the average value of these metrics. Use a repeating time period of daily with a target of $500 and, optionally, ranges for unacceptable, good, and excellent order amounts.
Manual order approval KPI
For an order-handling process in which order approval could be manual or automatic, define an instance-level metric named manualOrderApprovalTime. This metric calculates the time for each manual order approval by subtracting the time stamp of the event indicating that manual approval was required from the time stamp of the order approval (or rejection). Define a KPI that calculates the average value of these metrics. Use a target of 48 hours and, optionally, ranges for unacceptable, acceptable, and excellent manual order approval times.

Expression KPIs are defined by expressions that use other KPIs. For example, you could have a Total Profit KPI that subtracts the Total Cost KPI from the Total Revenue KPI. You can also define a KPI based on user-defined XML Path Language (XPath) functions. You can use XPath functions to retrieve KPI values from sources outside WebSphere Business Monitor.

Versions

When you define a KPI based on the aggregation of a metric, you decide whether you want to calculate the KPI using values collected from all versions of the model, including all previous and future versions, or using only the values from the most recent version of the model. In general, if the semantics of the KPI have not changed, include all versions. However, if a new version of the KPI has incompatible changes, choose only the current version.

History and prediction

You can choose to preserve the historical values of KPIs for viewing and analysis. In the KPI Manager widget, you will be able to create prediction models and use the collected historical data to predict future trends for the KPI. Using prediction models, you can take action before things go wrong rather than finding out afterwards.

Although you can enable or disable historical tracking in the KPI Manager widget, enabling tracking in the KPI model means that you can track the KPI history from the beginning.

Time filters

When you define a KPI based on the aggregation of a metric, you can specify a limited time period over which the KPI value is calculated. The time period is based on a metric from the same monitoring context as the metric on which the KPI is based. The metric must have a type of Date or DateTime. For example, if you are monitoring a process, you might have a Start Time metric based on the arrival of the event that starts the process.

The time period can be a repeating (last completed or current period) interval, a rolling (sliding) interval, or a fixed interval.
Repeating interval
Choose a repeating time period to calculate the KPI based on data from a repeating interval of a specific length, which can be a day, a month, a quarter, or a year. You can choose only one such time period to calculate the KPI; for example, the last month. You must also choose whether you want to evaluate data for the last full period or for the current period. If you set the repeating period to monthly and select the last full period, then the KPI will always reflect the value based on the last complete month. For example, if it is March, the last complete month was February. When April starts, the KPI value is no longer based on the data from February but is based on the data from March. At all times, the KPI is evaluated based on a full month of data. Alternatively, if you select the period in progress, the KPI is evaluated based on the current month. If it is March, the KPI is evaluated based on the March data so far. When April starts, the KPI value is no longer based on the data from March but on the (initially very little) April data.

If you want to see the results from more than one month at the same time, define two KPIs in the model: one for the current month and one for the previous month. Then use a third KPI to compare them and display the result.

Rolling (sliding) interval
Choose a sliding interval to evaluate the KPI data over a window of time that moves continuously, based on minutes, hours, days, months, or years. For example, you might always want to see the unit sales for the last 90 days. If you set the sliding interval to 90 days, you will see the value of the KPI from 90 days ago up to the current time (not from midnight to midnight). For example, if it is currently October 17th, 2007 12:30 PM and you select 3 months, the KPI will be based on all instances from July 17th, 2007 12:30 PM to October 17th, 2007 12:30 PM. Sliding interval KPIs simply take the current server system time to query the instances in the database.
Fixed interval
Choose a fixed interval if you want the KPI to be calculated for a single time period. You specify a start date and an end date, such as January 1, 2008 to January 31, 2008. If you specify a start date only, the KPI is calculated beginning at that date and continuing to the current date. If you specify an end date only, the KPI is calculated using all data up until the end date.
For repeating time periods and fixed time periods, you can also choose a time zone. For example, if you wanted to track the average order amount for all orders placed yesterday from a Pacific Standard Time (PST) perspective, you could specify the time zone as GMT-8. The value specified for the time zone helps to determine the values to be included in the KPI calculation. An order that was placed at 2:00 AM Eastern Standard Time (GMT-5) today translates to 11:00 PM PST (GMT-8), and therefore would be included in the calculation.

If you are measuring a period of time that crosses a daylight saving time boundary, you can optionally specify a location based on the time zone you choose. When the KPI is calculated, an hour will be subtracted or added as appropriate for that location.

Data filters

When you define a KPI based on the aggregation of a metric, you can use other metrics as data filters to restrict the set of information that is included in the KPI calculation. For example, you might have a KPI called Average Price in London. You want to take the Price metric and average it, but you only want to use monitoring contexts for which the city is London. You select the City metric, select IN for the comparison operator, and type London for the value.

Alternatively, you could have a KPI that measures price values for which the city is either London or Toronto, or a KPI that measures price values in any city that starts with the letter L, or any city that occurs in a list of cities that you specify. As another example, you might be interested in calculating an Average Order Amount KPI when the Customer metric contains the value GOLD or SILVER but not when it contains other values. You can enter a list of values for comparison.

Outbound events based on KPIs

To send outbound events based on the value of the KPI achieving its target or exceeding a range, create triggers and outbound events in the KPI context. For example, if you have a KPI that expects an average order amount of $500, you could create an outbound event that is triggered when the average falls below $400. The trigger is evaluated based on a specific time interval or the arrival of a specific inbound event, and it has a condition that causes it to fire only when the average falls below the amount you specify.

The start values and end values of KPI ranges are frequently considered thresholds, which can be monitored by a trigger that fires when they are crossed. You must, however, define those triggers. A KPI value exceeding a KPI range boundary will not automatically cause a trigger to fire or an outbound event to be emitted

You do not need to create outbound events to be able to send alerts. Users in the dashboard can create alerts based on KPIs. Alerts that are created in the dashboards can also be based on predictions.




Support | Terms of use | Contact IBM
Copyright IBM Corporation 2007, 2008. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)