Skip Headers
Oracle® Retail Category Management Implementation Guide
Release 14.1
E55388-01
  Go To Table Of Contents
Contents

Previous
Previous
 
Next
Next
 

6 Configuration Considerations

This chapter provides information on the configuration changes that can be made for Category Management. For some retailers, parts of the released version of the Category Management configuration might fit perfectly. However, it is anticipated that changes are needed to make the Category Management configuration match the organization of the retailer.

Hierarchies are limited to the determination of hierarchy aspects that pertain directly to dimensions, attributes, facts, and escalation. Due to RPAS limitations on intersection, distinct hierarchies must exist for the construction of all intersections to support all facts. No more than one dimension from any hierarchy can exist in a measure intersection.

For information on the configuration changes that can be made, see the following sections:

Calendar (CLND) Hierarchy

Figure 6-1 shows the CLND hierarchy in the RCM configuration.

Figure 6-1 Calendar Hierarchy


Name Label Hierarchy Type Child
YEAR Year Main SSN
SSN Half Main QRTR
QRTR Quarter Main MNTH
MNTH Month Main WEEK
WEEK Week Main DAY
DAY Day Main None

The Calendar hierarchy represents time in all RPAS solutions. It is a required hierarchy. RPAS requires a dimension named day (Day). This level is not displayed in the solution.

Category Management has many measures with a time component. Most "actuals" data (such as sales, cost, margins, and markdowns) is stored at the week level. Many calculations (such as market share and market growth) and index-type information (loyalty, penetration, and buyer conversion) are used at the quarter level. Basic RPAS functionality allows the user to view time-dependent data at any desired aggregate level.

With this in mind, a retailer implementation can structure the Calendar hierarchy in any way that best suits the retailer's functional needs. Dimensions other than week and quarter have been included in the Category Management configuration for the purpose of illustration. They can be modified or removed without requiring changes to any other elements of the Category Management configuration. Other dimensions and hierarchy branches may also be added without requiring changes to other elements of the Category Management configuration.

Product (PROD) Hierarchy

Figure 6-2 shows the PROD hierarchy in the Category Management configuration.

Figure 6-2 Product Hierarchy


Name Label Hierarchy Type Child
CMMP Company Main DVSN
DVSN Division Main PGRP
PGRP Group Main DEPT
DEPT Department Main CLSS
CLSS Category Main SCLS
SCLS Sub-category Main STYL
STYL Style Main STCO
STCO Style/Color Main SKU
SKU SKU Main None
VNDR Vendor Alternate SKU
BRD Brand Alternate SBRD
SBRD Sub-Brand Alternate SKU

The product hierarchy represents the retailer's merchandise (that is, merchandise that the retailer sells through its retail channels). Much of the work in Category Management focuses on the category and sub-category levels. Some workbooks and worksheets are focused on working with data at the SKU level. Style and Style-color levels are included in the configuration in between SKU and Sub-category.

A Category Management domain is typically partitioned at Department level or higher. Partitioning the domain above category allows multiple categories to be compared and analyzed side-by-side.

Several alternate rollups are provided for SKU. One relates SKU to Vendor and the other to Sub-brand and Brand. These alternate rollups provide additional insight and options for analysis.

The product hierarchy is also the base on which dynamic hierarchies are built. These dynamic hierarchies are created based on a consumer decision tree (CDT). They form an additional alternate hierarchy based on SKU. The dynamic hierarchies are based on product attributes (see Product Attributes (ATTR) Hierarchy) and can have a varying number of levels. Further, the rollup path can differ for different products.


Note:

Any changes to this hierarchy must be accompanied by changes to all the elements that employ the particular level that is being modified or removed. Adding levels or branches or changing labels should not require any changes to the Category Management configuration.

Further, any changes to the product hierarchy should be replicated to the right-hand side product hierarchy (PROR). This is important in keeping cross-product information available and up-to-date. For more information, see "Right-Hand Side Product (PROR) Hierarchy".


Right-Hand Side Product (PROR) Hierarchy

Figure 6-3 shows the Right-Hand Side Product (PROR) hierarchy in the Category Management configuration.

Figure 6-3 Right-Hand Side Product Hierarchy


Name Label Hierarchy Type Child
CMMR Company Main DVSR
DVSR Division Main PGRR
PGRR Group Main DEPR
DEPR Department Main CLSR
CLSR Category Main SCLR
SCLR Sub-category Main STYR
STYR Style Main STCR
STCR Style/Color Main SKUR
SKUR SKU Main None
VNDR Vendor Alternate SKUR
BRDR Brand Alternate SBRR
SBRR Sub-brand Alternate SKUR

The right-hand side product hierarchy (RHS Product or PROR) needs to be an exact replica of the main product hierarchy. The purpose of this hierarchy is to allow RCM to store and use various cross-product quantities related to Demand Transference (DT). Examples of these quantities include Item-Item Similarities, Demand Transferred, Substitutable Demand, and so on.

The DT calculations are always related back to SKUs in the main product hierarchy. So there is no partitioning done or dynamic hierarchies built on PROR.


Note:

Any changes to the main product (PROD) hierarchy must be replicated into the right-hand side product (PROR) hierarchy. This ensures that the demand transference data and calculations are complete and reliable.

Location (LOC) Hierarchy

Figure 6-4 shows the LOC hierarchy in the Category Management configuration.

Figure 6-4 Location Hierarchy


Name Label Hierarchy Type Child
CMPN Company Main CHN
CHN Chain Main CHNL
CHNL Channel Main AREA
AREA Area Main RGN
RGN Region Main DISTR
DISTR District Main STR
STR Store Main None
TDAR Trading Area Alternate STRC
TDRG Trading Area Group Alternate TDAR
STRC Store Cluster Alternate STR
STRG Store Group Alternate STR

The Location hierarchy represents the retailer's retail locations and their rollups. The Category Management configuration imposes few constraints on the structure of this hierarchy.

However, the alternate rollup of Store Cluster and Trading Area is integral to Category Management functionality. Store Clusters and Trading Areas allow the retailer to define groups of stores with common characteristics, such as assortments carried, sales patterns, customer segments served, and so on. This alternate rollup need not be tied to geography.

Focus Area Attributes (FAAH) Hierarchy

The focus area attributes hierarchy is used to list various facets of a category that a category manager might be interested in. Combined with strategies (another hierarchy), they are instrumental in the setup and calculation of Item Performance Indicators (IPIs).

This hierarchy is intended to be customized for the individual customer's needs.

It is a single dimension hierarchy. The only dimension is Focus Area (FAR).

Consumer Profile (CPRF) Hierarchy

The consumer profile hierarchy is used to represent all demographic information about a retailer's consumers. This hierarchy is intended to be customized for the individual customer's needs.

The type of information that is intended to be represented in this hierarchy includes:

  • Household income

  • Head of household age

  • Children's ages

  • Lifestage

  • Household size

Each demographic measure can have a number of gradations within it. For example, the Lifestage Consumer Profile Type might have the following profiles within it:

  • Starting Out

  • Young with Toddlers

  • Young Family

  • Singles/Couples without children

  • Middle-aged Family

  • Empty Nesters

  • Retired Couples

  • Older Singles

Name Label Hierarchy Type Child
CPRT Consumer Profile Type Main CPRD
CPRD Consumer Profile Main None

Retail Segment (RSGH) Hierarchy

The retail segment hierarchy is a single dimension hierarchy that contains broad segments of the retail market. This hierarchy is intended to be customized for the individual customer's needs.

It is a single dimension hierarchy. The only dimension is Retailer Type (RSGD).

Examples of what might be listed in this hierarchy include:

  • Grocery

  • Convenience/Gas

  • Drug

  • Super-centers

  • Warehouse Club

  • Dollar Stores

Retailer (RETH) Hierarchy

The retailer hierarchy is used to maintain a list of competitors. This is used for comparing certain metrics between the retailer and competitors. This hierarchy is intended to be customized for the individual customer's needs.

It is a single dimension hierarchy. The only dimension is Retailer (RETD).

Consumer Segment (CSH) Hierarchy

The consumer segment hierarchy is used for listing the consumer segments and the versions of each. A consumer segment is a classification of consumers with similar characteristics and buying patterns. Examples of consumer segments include "Soccer Mom" or "Golden Years". The consumer segment hierarchy is mainly used as the main characteristic of a consumer decision tree, which specifies the buying patterns for each consumer segment. The buying patterns may vary slightly from year to year or season to season, so multiple versions of consumer segments are supported.

Note the following about this hierarchy:

  • The consumer segment dimension position must be one of sX, where X equals 1 to 7.

  • The consumer segment version dimension position must be one of sXcdtY, where X equals 1 to 7 and Y equals 1 to 5.

  • The labels for these dimensions are user-choice or the GA labels can be used.

This hierarchy is intended to be customized for the individual customer's needs. The customer should advance plan how many Consumer Decision Trees (CDTs) they will need for each combination of category, trading area, and consumer segment. The Consumer Segment Hierarchy load file then must include a Consumer Segment Version position for each of these Consumer Segments. As a result, during domain build, the domain will include enough versions to hold the anticipated number of CDTs.

As a point of reference, the GA hierarchy load file contains 5 Consumer Segment Versions for each of the 7 Consumer Segments.

Name Label Hierarchy Type Child
CSD Consumer Segment Main CSVD
CSVD Version Main None

Linear Number (LNMH) Hierarchy

The linear number hierarchy is included for utility. It simply consists of a list of numbers. These numbers are used in various places in Category Management wherever a list of items are needed. It is used, for example, in an admin screen to define lists of tactics that will be combined to form a pick list that changes its values based on product, location, and topic.

This hierarchy should be modified with care. Adding new positions to the hierarchy can be done without affecting current functionality. For example, changing or deleting existing positions will cause rules to break. Care should be taken to modify affected rules and measures when modifying or deleting existing positions in this hierarchy.

It is a single dimension hierarchy. The only dimension is Linear Number (LNUM).

Tactic (TCTH) Hierarchy

The tactic hierarchy represents areas within Category Management where one or more choices of approach may be relevant. For example, the tactic hierarchy might contain an entry for "Pricing" or "Promotion". Individual tactics within each area (for example, "Pricing" might include "Match competition but do not lead" or "Do not initiate price decreases") are broken out by combining the tactic hierarchy with the linear number hierarchy.

This hierarchy is intended to be customized for the individual customer's needs.

It is a single dimension hierarchy. The only dimension is Tactic (TCTD).

Breakpoints (PCTH) Hierarchy

The breakpoint hierarchy represents thresholds used in the calculation of fragmentation, contribution, and ranking of SKUs within an assortment. Breakpoint positions are typically named to represent a certain numeric level (50%, 75%,...) or could be named to represent scenarios (such as "Base", "High", "What If").

This hierarchy is intended to be customized for the individual customer's needs.

It is a single dimension hierarchy. The only dimension is Breakpoint (PCTD).

Product Attributes (ATTR) Hierarchy

The product attributes hierarchy represents attributes associated with products. These attributes are used to group products within categories. This grouping is what consumer decision trees are built on and are used when showing dynamic rollups in Category Management.

This hierarchy is intended to capture all product attributes for all product types. The attributes are then assigned to individual products. This assignment is used when processing the dynamic rollups.

This hierarchy is intended to be customized for the individual customer's needs.

Name Label Hierarchy Type Child
ATN Attribute Name Main ATV
ATV Attribute Value Main None

Strategy (SGYH) Hierarchy

The strategy hierarchy represents broad actions designed to enhance a category. Sample strategies might include:

  • Traffic building

  • Transaction building

  • Profit contribution

  • Cash generating

  • Excitement creating

  • Image enhancing

  • Turf defending

This hierarchy is intended to be customized for the individual customer's needs.

It is a single dimension hierarchy. The only dimension is Strategy (sgyd).

Curve Points (CURV) Hierarchy

The curve points hierarchy facilitates calculations related to the Incremental Curve functionality within Demand Transference (DT). The incremental curve functionality calculates the aggregate amount of demand transferred based on the number of changed items in the assortment. So, while it is related to SKUs, it is expressed in terms of number of SKUs and is not representative of any one SKU.

It is a single dimension hierarchy. The only dimension is Curve Point (cnum). It should contain as many positions as the number of items that are expected to be substituted in what-if scenarios in planning an assortment.

Planogram (POGH) Hierarchy

The planogram hierarchy represents planogram details used in a space planning application. This hierarchy is intended to capture all planogram details used by the Macro Space Optimization module.

Name Label Hierarchy Type Child
PDEP POG Department Main PCAT
PCAT POG Category Main PSUB
PSUB POG Sub-Category Main None