Oracle Demand Signal Repository User Guide Release 12.1 Part Number E12276-07

Contents

Previous

Next

Measures

Measures Overview

Use Demand Signal Repository’s base measure values to calculate common performance measures, such as sales growth, gross margin, and inventory cover (days of supply). Demand Signal Repository calculates these measures at the appropriate hierarchy levels.

As well as base measures, Demand Signal Repository supports external measures, which are measures that cannot be calculated based on the base data model or that are provided directly by the retailer in precalculated form. You can load external measures into Demand Signal Repository.

Note: Demand Signal Repository does not map or aggregate external measures.

DSR Base Measures

DSR Derived Measures

DSR External Measures

The following external measures can be loaded into DSR:

Loading Syndicated Consumption Measures

Syndicated consumption data can be purchased at various levels of the product hierarchy and customer organization hierarchy, as well as geographic region or sub-region and then loaded into Demand Signal Repository. In order to calculate ACV %, the consumer goods manufacturer must obtain store volumes of all stores in the desired geographical area. Obtaining store volume information from syndicated data sources is expensive and can be cost prohibitive. The more common practice is to purchase pre-calculated ACV measures from the syndicated data source for the desired Product, Retailer and/or Geography, and Time Period combinations.

Since Consumer Goods Manufacturers may receive ACV consumption data from multiple sources, DSR allows the same measure to come from different sources, so long as the data is for different dimensions (for example, geographies). The system will issue an error when a measure is received from a second source for the same dimension. For example, if Kroger measures were received for the Atlanta market area from IRI, an error would be issues if Kroger data for the Atlanta market area was received from AC Nielsen (or other source).

DSR Syndicated Consumption Data references the following logical entities:

All Commodity Volume (ACV) Measures

One of the types of syndicated consumption measures are All Commodity Volume (ACV) measures. These measures are commonly used by consumer goods manufacturers to analyze market share. ACV represents the total annual sales volume of retailers, which is aggregated from the individual store level up to larger geographical sets. When dividing total sales for a store into ACV million dollar blocks, it allows for weighting across different sized markets. For example, Vision Consumer Goods (a beverage manufacturer) has its Homestyle Root Beer distributed in one supermarket in a community with five supermarkets total. A straight percentage of stores displaying Homestyle Rootbeer would read 20% display; however, the one store that handles Homestyle Root Beer is responsible for 90% of all supermarket sales in the community. The numbers that would be reflected for Homestyle root beer would be 90% ACV display activity. In this example, ACV % is the percentage of exposure to consumer spending in the class of trade being analyzed for Homestyle Rootbeer during the specified time period.

Sample Syndicated Consumption Data

The layout of syndicated consumption data varies by Consumer Good manufacturer. The order of columns, measures to be included, and date format may be different; however, the measures will always have an associated product key, geography key and time code. Below is a sample of syndicated consumption data. The product key and geography description fields (bolded) are not actually part of the file; they have been included in the file layout to make it easier for the reader to understand the data. The number of measures received will vary based on what data the Consumer Goods manufacturer has purchased.

Product Key

The product key is a numeric code that represents one of the levels in a product hierarchy. For example, the data above illustrates data received at the SKU level (the first four rows), product subclass level (rows 5 – 8), and class (rows 9 & 10). To translate product key into DSR terms, you would need a table that looks like the following:

Note: Since product and geography keys are unique by data source, it’s necessary to identify the source in order to translate the product key.

Geography Key

The geography key is a numeric code that represents a combination market area, retail organization (at various levels of the hierarchy), Region or Sub-region and Channel. To translate geography key into DSR terms, you would need a table that looks like the following:

The data listed above illustrates valid combinations represented by geography key. For example, market area, region and sub-region are mutually exclusive. A measure can only be associated to one. Valid combinations include:

• Channel / Region

• Channel / Sub-region

• Channel / Market Area

• Channel / Market Area / Retail Organization

• Channel / Retail Organization

Setting Goals

Demand Signal Repository provides the ability to load goals and thresholds at various levels of the organization and item hierarchy for a given time period (i.e., year, quarter, week, etc.) The main purpose of goals and thresholds is to determine whether performance targets are being met; however, these goals and thresholds are not currently used in driving the color-coded performance indicators.

You can enter a goal for each measure at any level combination that is available in the scorecard dashboard. By default, a goal applies to all periods from the present going forward. Alternatively, you can specify a beginning and ending period for which the goal being entered should apply. In this way, goals can be set retroactively, and can be set for future periods without changing the goals for current periods.

The goal is either a constant scalar value, such as 9% for sales growth, or a ratio applied to a prior result (for example, units sold last year’s sales * 1.09 = goal for sales units this year for each week of the year).

You can also enter a single goal value that is to apply to many categories and/or regions. For example, if a user wants to set the days of supply goal for each of its regions to 14 days, they can select all of the combinations to which this goal is to apply, and enter the value once. The same value will be saved for each of the affected combinations. If new regions are subsequently added at a level within this type of goal specification, they automatically inherit these goals.

Runtime Evaluation of Goals

DSR uses color-coded performance indicators which are based on the loaded goals and thresholds. For each measure, a goal is either the lower or upper bound of performance. For example, a goal for sales growth is a lower bound measure, since exceeding the performance is considered good news. In other cases, such as the goal for days of supply (an upper bound measure) a higher number of days of supply would indicate an overstock (or negative) condition. If a goal is set for a measure and data is available for the period being measured, the display for that product/location/measure combination will be green if:

• The measure is a lower bound and the value meets or exceeds the goal

• The measure is an upper bound and the value is at or below the goal

The display is red if:

• The measure is a lower bound and the value is outside the tolerance for a major issue

• The measure is an upper bound and the value is outside the tolerance for a major issue

Otherwise the display is yellow.

If there is no data for the period being displayed for a measure, the result for the most recently available prior period should be displayed, with some visual indicator (hash marks or otherwise) that the value is not current. If there is no data from any prior period that was measured against a goal, the display for that product/location/measure combination is grayed.

Setting Thresholds

You can set Demand Signal Repository thresholds that determine whether goals are in the upper or lower bounds of performance.

For example, a goal for sales growth would typically be a lower bound, since exceeding the performance would be considered good news. Meanwhile, the goal for days of supply might be an upper bound, since a higher number of days of supply would indicate an overstock condition.

Note, however, that days of supply can also be too low, creating an understock condition. In this case, a separate goal could be set for the measure as a lower bound. It would then have a separate place in the scorecard for understock and overstock monitoring.

The second aspect of threshold setting is determining whether a goal shortfall is minor (yellow status) or major (red status). Users can either set a global tolerance for this (greater than 20 percent shortfall or overshooting of the goal indicates a red status), or they can specify a tolerance (in percentage or absolute terms) for individual measures, much as they set up the goals themselves.

Note: Scorecard thresholds are only applicable to retailer hierarchies.

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.