| Oracle® Retail Category Management Implementation Guide Release 14.1 E55388-01 |
|
 Previous |
 Next |
| Oracle® Retail Category Management Implementation Guide Release 14.1 E55388-01 |
|
Previous |
Next |
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:
Figure 6-1 shows the CLND hierarchy in the RCM configuration.
| 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.
Figure 6-2 shows the PROD hierarchy in the Category Management configuration.
| 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". |
Figure 6-3 shows the Right-Hand Side Product (PROR) hierarchy in the Category Management configuration.
| 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. |
Figure 6-4 shows the LOC hierarchy in the Category Management configuration.
| 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.
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).
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 |
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
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).
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 |
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).
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).
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).
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 |
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).
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.
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 |
