Patent Application
20060047565
The invention relates generally to metrics and, more particularly, to the decomposition of metrics.
There are a variety of metrics that can be used to measure productivity in the workplace. One of these measurements is known as a dashboard. Specifically, a dashboard is a tool for visualizing measurements (that is, making the measurements visible) and also provides an infrastructure for gathering the data needed to calculate those measurements. It can use bars or graphs or other forms of graphical data interpretations. Generally, a dashboard is designed to provide executives or other interested parties with a compressed, high level view of a business through providing the representation of various performance indicators distilled from large collections of data.
For instance, a dashboard could be used in telephone support. The dashboard could show an end user the average length of time a caller is on hold, the average time that a call takes to be processed by an operator, the number of calls that hang up before being processed by an operator. This information could be displayed graphically as charts or figures to the end user, and updated periodically.
However, there are problems associated with conventional dashboards. One problem is that the user is unaware of how a given metric has been obtained, that is, the nature of the data from which it is calculated. Furthermore, little or no guidance is given as to how the various indicators are derived. If the end user wishes to understand these key indicators, there is not a method or system that allows the end user to determine this.
Therefore, there is a need for a dashboard that allows an end user access to the calculation of various indices that addresses at least some of the problems associated with conventional dashboards.
The present invention provides decomposing metrics. A result is decomposed into a expression and at least one datum. The decomposed expression and at least one datum is rendered on a display means.
For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following Detailed Description taken in conjunction with the accompanying drawings, in which:
In the following discussion, numerous specific details are set forth to provide a thorough understanding of the present invention. However, those skilled in the art will appreciate that the present invention may be practiced without such specific details. In other instances, well-known elements have been illustrated in schematic or block diagram form in order not to obscure the present invention in unnecessary detail. Additionally, for the most part, details concerning network communications, electromagnetic signaling techniques, and the like, have been omitted inasmuch as such details are not considered necessary to obtain a complete understanding of the present invention, and are considered to be within the understanding of persons of ordinary skill in the relevant art.
In the remainder of this description, a processing unit (PU) may be a sole processor of computations in a device. In such a situation, the PU is typically referred to as an MPU (main processing unit). The processing unit may also be one of many processing units that share the computational load according to some methodology or algorithm developed for a given computational device. For the remainder of this description, all references to processors shall use the term MPU whether the MPU is the sole computational element in the device or whether the MPU is sharing the computational element with other MPUs, unless otherwise indicated.
It is further noted that, unless indicated otherwise, all functions described herein may be performed in either hardware or software, or some combination thereof. In a preferred embodiment, however, the functions are performed by a processor, such as a computer or an electronic data processor, in accordance with code, such as computer program code, software, and/or integrated circuits that are coded to perform such functions, unless indicated otherwise.
Turning to
Among other things, a metric can be defined as one or more calculations that provide a mathematical result, which in its final data form is intelligible to humans, that is then used to drive a Graphical User Interface (GUI) representation. In the system 100, such as within the network 120, as more final data becomes available, the metrics are periodically re-evaluated (that is, the mathematical expressions that comprise the metric are re-calculated), and the GUI is updated.
Generally, decomposing a metric enables a reviewer to be able to understand how various values and metrics are calculated and come into being. In other words, the end user is able to review both the data used in the calculations, and the calculations themselves, and have this information displayed on the displays 112, 132. This enables executives or other end users to have a further grasp of the depth analysis of their businesses. Implementation costs for dashboards can be reduced by building high level and low level analysis tools simultaneously to allow for decomposition into metrics. The metric decomposition can occur in the first computer 110, the second computer 130, or the network 120, or elsewhere as appropriate.
Turning now to
The rendering logic 220 illustrates the metric requested by the end user, and does not play a part in the actual performance of the system. In
In the system 200, mathematical expressions are stored within a rules engine in symbolic form (that is, $a+($b/$c)), where perhaps ($b/$c) is an important and meaningful sub-product. The rules engine 225 then takes data from the data source 250 and evaluates the symbolic mathematical expressions from the expressions memory 240, such as a substitution. Since the expression is stored within the expression memory 240, the expressions can be dissected to extract sub-expressions that could be very meaningful and helpful when looking at the high-level analysis on he display 210. To obtain this value, in one embodiment, a re-computation of the sub-expression commences. In another embodiment, a rules engine that has cached the intermediary result is selected for displaying the result on the display 210.
For instance, suppose that we have a metric that shows “average sales per customer.” That is all well and fine, but how does the end user know how this was calculated? As it turns out, “average sales per customer” was calculated in the following manner:
Average Sales per Customer=Average Sales/Number of Customers
But, where do Average Sales and Number of Customers information come from?
This can be then shown to be the following:
Average Sales=SUM sales/COUNT sales;
Number of Customers=COUNT customers;
The decomposer 230 shows the above expression to give the end user more of an idea of where the calculation of average sales per customer derives. The actual expression for this metric is therefore:
Average sales per customer=(SUM sales)*(COUNT sales)/(COUNT customers).
The decomposition of average sales per customer into the above specific logical expressions, which are retrievable by the end user, are of great assistance to the end user, as he can determine how the expressions which are used to generate the data are applied. Furthermore, if there is a case where an expression is using as inputs the output of other expressions, this can also be decomposed for the use of the end user.
For instance, if there was a metric showing “calculated overall customer satisfaction”, it could be worked as follows. Overall customer satisfaction could be naively calculated as combination of the number of complaints received divided by the average sales per customer, above. However, there could be cases wherein the complaints were only being generated by very small purchasers, or very large ones; alternatively, complaints could be generated by only those who are not buying. Furthermore, perhaps for business reasons, as market exposure goes up, complaints go up as well proportionately, but the sales are not finalized until 60 days after delivery, for example. The decomposition of the system 200 by the composer 230 could allow an executive to decompose metrics like “calculated overall customer satisfaction” to determine exactly how the metric was calculated, and how germane that information is to this particular situation.
It is understood that the present invention can take many forms and embodiments. Accordingly, several variations may be made in the foregoing without departing from the spirit or the scope of the invention. The capabilities outlined herein allow for the possibility of a variety of programming models. This disclosure should not be read as preferring any particular programming model, but is instead directed to the underlying mechanisms on which these programming models can be built.
Having thus described the present invention by reference to certain of its preferred embodiments, it is noted that the embodiments disclosed are illustrative rather than limiting in nature and that a wide range of variations, modifications, changes, and substitutions are contemplated in the foregoing disclosure and, in some instances, some features of the present invention may be employed without a corresponding use of the other features. Many such variations and modifications may be considered desirable by those skilled in the art based upon a review of the foregoing description of preferred embodiments. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the invention.
