| Oracle® Retail Size Profile Optimization Implementation Guide Release 14.1 E55738-01 |
|
 Previous |
 Next |
| Oracle® Retail Size Profile Optimization Implementation Guide Release 14.1 E55738-01 |
|
Previous |
Next |
The following information needs to be considered before implementing SPO:
It is recommended that you have at least two years of historical sales and inventory data for creating size profiles. Less data can be used, but the more data that is available, the more statistical significance can be given to the size profiles.
The following factors can affect size requirements:
SKU– number of items. An item is a specific sized item, like a particular shirt in size medium.
Store– number of physical, web, and other distinct retail outlets.
Size– number of sizes. As sizes are specific to their size range, there might be many Small sizes, one for Small of Men's S/M/L, one for Small of Women's XS/S/M/L/XL, and so on.
Size range– number of size ranges, that is, collections of size, like S/M/L.
Product attribute– number of Attribute Codes (ATCD). ATCD captures the cross-product of all product attributes on which size will be analyzed. For example, if Season Code and Brand are two attributes, the ATCD has distinct positions for each distinct combination of Season Code (Summer/Fall/Winter/Spring) and Brand.
Escalation level– number of distinct aggregation levels at which size profiles are calculated and stored. The SPO configuration has 10 levels defined.
Generation ID– number of scenarios or slots that can be used for generating and storing size profiles. The positions are reused. The SPO configuration has three generation IDs defined.
SPO hosts sales data, inventory data, and calculated size profiles. During the batch process, SPO also needs temporary data storage for intermediate results. The total data storage space requirements for SPO are estimated to be several times larger than the storage space of the sales data.
Partitioning is done to avoid contention for resources. Building a workbook and committing data are two processes that can cause contention.
How data is partitioned has an impact on the business process. The SPO domain is defined as a global domain. For performance reasons, a single domain is not recommended. There should be an even distribution of users across a set of local domains. For example, men's merchandise could be in a domain, women's merchandise in a domain, and children's merchandise in a domain. When a user is committing data in the men's merchandise domain, this does not affect the users in the women's or children's domains because of the use of partitioning.
Consider the following questions when defining the partitioning of the domain:
How do I partition to meet my business needs?
How do I partition my users?
How do I create groups of users to further partition the solution?
Domain partitioning is supported either on Product hierarchy (PROD) or Location hierarchy (LOC) dimension. These hierarchies are standard RPAS hierarchies. For performance reasons, it is recommended that most of the escalation levels are kept below the partition dimension.
|
Note: The partitioning level in the SPO configuration is Group. It is recommended that this not be changed. |
In the GA configuration, group is a dimension label. The group dimension is a regular dimension in the product hierarchy, which the customer can rename or delete. One of the major purposes of partitioning in SPO is to facilitate the parallelization of the batch process. For the escalation levels that are below the partition intersection, profiles can be calculated from a local domain using local domain data only, thus allowing their profile calculations to be parallel.
For the escalation levels that are above the partition intersection, profiles have to be calculated using data from multiple local domains; thus, their profile calculations cannot be parallelized. Therefore, the wise selection of partition intersections can significantly reduce the batch time. Partition intersection selection should also consider business needs in such a way that contention issues are minimized. SPO can support partitioning on product or location levels.
Formatting can be done in the configuration or the workbook after the domain is built.
Each worksheet in the SPO configuration has a measure order as well as measure styles that have been preconfigured. The measures can be displayed in the pre-configured order through the user interface. That format can then be saved to the template.
An implementer can create generic styles for the measures and assign them to measure components or realized measures. For each measure, these styles can be overridden on each workbook template. Formatting can only be changed by using the RPAS Configuration Tools. For more information, see the Oracle Retail Predictive Application Server Configuration Tools User Guide.
Once the domain is built, the implementer can set up worksheet sizes and placements, exception value formatting, gridlines, and other formatting. The implementer instantiates a workbook of the template to set up specific formatting by using the Format menu. The updated format is then saved to the template so that it is available to all users for any newly created workbooks. For information on how to use the Format menu, see the Oracle Retail Size Profile Optimization User Guide for the RPAS Classic Client or the Oracle Retail Size Profile Optimization User Guide for the RPAS Fusion Client.
Plug-ins are application-specific Java code modules that run inside and automate the RPAS Configuration Tools to assist the implementer with specific application configuration. There are rules that an implementer must follow when configuring an application. A plug-in makes such adherence easier by automating parts of the configuration process and validity-checking entries that are made.
An SPO plug-in is available for automating the steps required for configuration. For information on the SPO plug-in, see Chapter 9.
A prepack optimization plug-in is also available to automate the steps required to configure the prepack optimization parameters. For information on this plug-in, see Chapter 10.
There are two types of patches that can affect the SPO domain:
Changes to the code in the RPAS libraries.
The configuration is not affected by this type of patch. For these types of changes, applying the patch is a straightforward process.
Changes to the configuration.
These types of changes can be more complex. If you have customizations in the configuration, you can use the rpasConfigMgr utility to determine the differences between your existing configuration and the new one. Then, you can use the utility to merge the two configurations. Any changes that cannot be applied are written to a change log. For more information, see the RPAS Configuration Tools User Guide.
|
Note: Starting with Release 13.3, RPAS uses integer indexing for hierarchy positions. As a result, the upgrade process of a given solution includes a conversion process. For more information on the migration process to RPAS 13.3, refer to the Oracle Retail Predictive Application Server Administration Guide.Complete the steps in the Oracle Retail Predictive Application Server Administration Guide for converting and upgrading your domain. |
|
Note: When a user changes the number of escalation levels in a SPO Plug-in, and builds/patches the domain, they must use the same RPASHome to build the workbook, run the batch, or perform any other tasks. If not, the administrator needs to copy the RPAShome/ applib/resource directory of the RPASHome after the build/patch. |
Batch scripts are lists of commands or jobs executed without manual intervention. A batch window is the time frame in which the batch process must run. It is the upper limit on how long the batch can take. Batch scripts are used for importing and exporting data and for generating size profiles. The retailer needs to decide the best time for running batch scripts within the available batch window.
How often to upload updated sales and inventory data and how often to re-create size profiles needs to be determined. The criteria to be considered are as follows:
You have to consider at what interval to load the latest sales and inventory data. It is recommended that this is done on a weekly basis.
Product availability and seasonal changes can be reasons for reoptimizing the size profiles. It can also be triggered by the addition of new products and availability of substantial new sales and inventory history.
For more information on batch scripts, see Chapter 8.
To define workbook template security, the system administrator grants individual users, or user groups, access to specific workbook templates. Granting access to workbook templates provides users the ability to create, modify, save, and commit workbooks for the assigned workbook templates. Users are typically assigned to groups based on their user application (or solution) role. Users in the same group can be given access to workbook templates that belong to that group alone. Users can be assigned to more than one group and granted workbook template access without belonging to the user group that typically uses a specific workbook template. Workbook access is either denied, read-only, or full access. Read-only access allows a user to create a workbook for the template, but the user is not be able to edit any values or commit the workbook. The read-only workbook can be refreshed.
When users save a workbook, they assign one of three access permissions to the workbook:
World– Allow any user to open and edit the workbook.
Group– Allow only those users in their same group to open and edit the workbooks.
User– Allow no other users to open and edit the workbook.
|
Note: A user must have access to the workbook template in order to access the workbook, even if the workbook has world access rights. |
For more information on security, see the Oracle Retail Predictive Application Server Administration Guide for the Classic Client or the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client.
For more information on configuring Alert Manager, see the Oracle Retail Predictive Application Server Administration Guide for the Classic Client or the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client.
