Many Large BOM Models

This chapter describes an Oracle Configurator project involving many large BOM Models with much explicit and repetitive structure that is best modeled as a single top-level BOM Model containing a deep hierarchy of generic structure and abstractions.

This chapter covers the following topics:

Overview

This case study explores redesigning a project consisting of many large BOM Models (such as 90,000), each with a large number of options for selection (such as 150,000). The goal is to fulfill performance and usage expectations in a way best suited to the strengths and characteristics of Oracle Configurator.

This project illustrates the following best practices:

Project Description

A manufacturer and wholesaler of jewelry offers customers the opportunity to custom configure rings and bracelets. Configuring a ring consists of placing stones with characteristics such as shape, size, type, clarity, quality, into a specified location on the ring. Each ring consists of up to 60 locations. For example, a customer orders a 3-setting ring by configuring a 2mm round ruby at location 1 and 3, and a 3mm square emerald at location 2.

A Deficient Modeling Approach

An initial modeling approach might be to have a specific BOM for each ring model. Each ring model contains explicit submodels for each of 60 possible locations. Each Location submodel contains the specifications for the stone placed in that location. Stone specifications are shape, type, and so on. The 60 locations can be arranged in one of many possible settings. So for instance, if a ring is defined with three locations, the locations can be arranged in a line with two bevels flanking a peg. The locations on a 60-location ring could be arranged in many more possible settings. Multiplying the 60 rings containing from 1 to 60 Location submodels by the various possible settings results in 90,000 large, explicit BOM Models with up to 150,000 options in each BOM Model. Many Explicit Ring Models shows an example of such explicit, flat Model structure across many Models.

The graphic Many Explicit Ring Models shows RingModel 1000, RingModel 1001, and RingModel 1800, and shows that 800 RingModels contain repetitive structure.

Many Explicit Ring Models

the picture is described in the document text

Each Location has the same kind of configurable characteristics, such as particular stones of specific shapes and sizes. In the individual RingModels, the structure for configuring Locations is repeated over and over again, up to the maximum number of 60 locations. For example, if 100 rings are defined with 3 locations and another 100 rings are defined with 4 locations, then in 200 ring models the submodel structure for Location is repeated 700 times.

The ring configuration can contain the same configuration of a stone in several locations or a stone with different characteristics in different locations.

Perceived Advantages

By defining each possible model explicitly, the manufacturer can maintain and sell each model independently of all the other models. This includes sourcing items to separate organizations and preserving existing routings.

By not defining abstractions, the manufacturer does not have to create a large number of rules to capture the large number of valid combinations because each model identifies explicit options.

Overwhelming Disadvantages

A design consisting of 90,000 individual Models, each representing a unique combination, does not leverage the power of Oracle Configurator and causes the following:

The runtime performance issues at a minimum are prohibitive.

The Suggested Modeling Approach

The suggested modeling approach avoids the problems presented in A Deficient Modeling Approach and applies numerous best practices described in Best Practices. Rather than define separate explicit models repeatedly for each possible ring, a well-designed implementation defines the duplicated structure by references and abstractions, using optional instantiation to optimize performance.

Applying Best Practices to Your Model Structure

This case involves several separate models that represent unique rings. However, the ring models contain a large amount of similar structure, such as settings and locations for mountings on the rings.

To leverage the advantages of deep hierarchy and optional instantiation, you need to create abstractions of the structure that is similar across all ring models, as follows:

  1. Combine the separate models into a single top-level model for configuring rings. RingModel_1001 through RingModel_1800 in Many Explicit Ring Models become an abstract model called Ring Model in Top-level Ring Model with Abstractions. Instead of searching from a long list of rings with many pre-defined characteristics in RingModel_1001 through RingModel_1800, the end-user starts by selecting the characteristics of an undefined ring. The undefined ring is represented by Ring Model and the characteristics are the settings and the stones.

    This step applies the best practice:

  2. Creating a single top-level Ring Model containing the settings structure, initially results in one huge, flat BOM Option Class containing all possible settings, of which only one will be selected. Not only are all settings loaded when the top-level Ring Model is loaded, but the end user is faced with selecting a setting from this very large list of options.

    To help end users see only those settings options that are relevant to their configuration, organize settings into groups by some criterion such as popularity or the ring’s intended function. A Settings Model contains not all possible settings but BOM Option Classes of related or grouped settings.

    Each group of settings is a BOM Option Class containing only those options that belong in that group. Ideally, a specific Settings option should not appear in more than one group.

    Create a Settings Model that contains all the Setting Group BOM Option Classes.

    This step applies the best practices:

  3. To involve only that group of settings in the configuration that contains relevant settings, change the Settings Group BOM Option Classes into BOM Models and make them optionally instantiable, which means the value of Instance Minimum is 0, Maximum is 1. See Top-level Ring Model with Abstractions.

    This step applies the best practice:

  4. In the top-level Ring Model, you can significantly decrease the amount of repetitive structure by defining an ATO model for the various Stone Types, each containing BOM Option Classes for the configurable characteristics of the Stone such as size and quality.

    This step applies the best practice:

  5. To specify the location where the Stone will be placed, create a Location Option Feature for the Stone Model. The Location List of Options contains the maximum number of Locations allowed for any ring. Making Location an attribute of the Stone Model rather than an Item in the Ring Model is appropriate because the Stone is configurable and orderable, not the Location.

    This step applies the best practice described in:

  6. In the Stone Model, refine your design further by creating a Stone Type ­BOM Model containing each stone type (Diamond, Ruby, and so one) as a separate Model that is optionally instantiable. Each Model in the Stone Type ­BOM Model contains BOM Option Classes of the configurable characteristics of that stone type, such as shape and size.

    This applies the following best practices:

The graphic Top-level Ring Model with Abstractions shows the Ring Model that represents an abstraction of RingModel 1000 to 1800.

Top-level Ring Model with Abstractions

the picture is described in the document text

Applying Best Practices to Further Optimize the End-User Experience

After completing the steps in the previous section (Applying Best Practices to Your Model Structure), continue with the following steps:

  1. To allow end users to select only the Locations relevant to their ring configurations, write rules that disallow selecting Locations that are not allowed for a particular Setting. For example, when the end user has selected a 3-location setting, only 3 Locations should be selectable.

  2. To further enhance usability, define a display condition so only valid Locations are displayed in the UI.

    This applies the best practice:

  3. You can also write rules to ensure that each required Location for the selected Setting is selected and that, as the end user configures the Stones for a ring, only those Locations remain available for selection that have not yet been selected.

The Resulting End-User Flow

In the Order Management Sales Order Pad, the end user selects the top-level Ring Model and clicks the Configurator button to start configuring a ring. At start up, no Settings or Stone Models are instantiated. In the Oracle Configurator UI, the end user selects a Settings Group. For example, the end user picks a 3-setting ring. The end user must then configure between one and three Stones for the 3 Locations of the 3-setting ring. The first instance of the Stone Model allows the end user to configure the Stone Type and select from the three available Locations. If the end users picks all three Locations, the configuration is complete and the same Stone configuration will be set in each of the three locations. If not all three Locations are selected, the end user adds additional instances of the Stone Model, configures them and selects remaining available Locations until the ring is fully configured.

The diagram in End User Flow for Configuring a Ring Model shows a typical end-user flow.

The graphic End User Flow for Configuring a Ring Modelis an end-user flow chart for ordering the Ring Model. The end user picks a setting from the Settings submodel and rules select the corresponding number of Locations. The end user then creates an instance of a Stone and configures its characteristics. Finally, the end user completes the Stone configuration by selecting a location for that Stone. These tasks repeat for all locations required by the selected Setting.

End User Flow for Configuring a Ring Model

the picture is described in the document text

Advantages of This Modeling Approach

Perceived Disadvantages

Creating deeper hierarchy and abstractions may require greater designing effort and more rule definitions than an explicit design approach.

A single BOM Model can be sourced to only one organization.

Downstream ERP applications may require additional setup for option-dependent routings or using configuration attributes. Configuration attributes are explained in Oracle Configurator Methodologies.

Overwhelming Advantages

Comparing this approach to the deficient one presented in A Deficient Modeling Approach, a single top-level BOM Model with structure that is only instantiated as needed provides the following advantages: