Many BOM Items

This chapter describes an Oracle Configurator project involving many BOM Items that are not orderable and could be better implemented as Features or configuration attributes. Configuration attributes are explained in Oracle Configurator Methodologies.

This chapter covers the following topics:

• Overview
• Project Description
• A Deficient Modeling Approach
• The Suggested Modeling Approach

Overview

This case study explores redesigning a project that contains a profusion of items not all of which are part of the order.

This project illustrates the following best practices:

• Items Versus Alternatives to Items

• Grouped Versus Ungrouped Items

• Optional and Multiple Instantiation

• Optimizing User Interface Performance

Project Description

A manufacturer and retail supplier of perforated metal sheets offers customers both standard products available from local stock and custom-made products. When ordering metal sheets, customers must specify the type and grade of the material, its width, length, and thickness, and various characteristics about the perforations. From this information, the manufacturer must determine the machines and tools to use to produce the metal sheets.

A Deficient Modeling Approach

An initial modeling approach might be to define all possible characteristics of a metal sheet as items in the BOM Model. This would result in a top-level BOM structure for Metal Sheet, which contains submodels for specifying material and machines, and contains BOM Option Classes for specifying width, length, thickness, material grade, hole type, hole size, tools, and so on. Each BOM Option Class contains a large number of selectable items. Widths, lengths, thicknesses, material grades, hole types, hole sizes, and tools are all defined as items. For example, the Width BOM Option Class contains items that represent every possible selectable width for the metal sheet. Model With Too Many Items shows an excerpt of such a model.

The graphic Model With Too Many Items shows a Custom Metal Sheet Model containing submodels for Material and Machine, and BOM Option Classes for Width, Hole Size, and Hole Shape.

Model With Too Many Items

Perceived Advantage

• By defining each characteristic of the product as an item, the manufacturer does not have to create rules to capture a large number of valid combinations of characteristics

• Defining all of the information as part of the BOM Model ensures that all of the information is passed back to Order Management and to the downstream manufacturing applications.

• Defining each characteristic as an item provides a straightforward means by which to associate a price with each characteristic.

Overwhelming Disadvantages

A design that forces all of this information into the BOM Model inflates the size of the model structure, does not leverage the flexibility of Oracle Configurator, and causes the following problems:

• Poor performance when importing large numbers of items into Oracle Configurator Developer

• Poor performance at runtime caused by the large number of items (more than 10,000) that must be loaded into memory and displayed

• Poor usability of a UI that requires finding the desired item among a large number of items

• Insufficient scalability and maintainability as the business expands to more characteristics and dimensions

The Suggested Modeling Approach

Rather than defining thousands of BOM items to capture the characteristics of the configured item, a well-designed implementation reviews the requirement for this large number of items and based on the item’s use, redefines it either as a configuration attribute or Feature.

Applying Best Practices to Your Model Structure

The following suggested modeling approach applies best practices to achieve improved performance and usability:

1. Redesign the BOM Model for perforated metal sheets by analyzing the purpose of each submodel and BOM Option Class. By finding alternatives to items where possible, you can make the BOM structure significantly smaller and improve performance and maintainability.

   1. Identify which items appear on an order line and will be picked or assembled. For example, items in the Materials submodel must appear on the order line. These items must remain in your model as BOM Standard Items.

   2. Of the items that do not need to appear on the order line, determine whether you need end user input for the value of the item, or if the item has static value used in calculations or Compatibility rules. Define static values as Properties of the items they define.

      For example, the material grade has a static value (Premium, Medium, and so on) which can be defined as Properties of the Materials items.

   3. Define items whose values result from end user input as Features or as attributes on items. For example, hole size and width.

   4. Of the items that require end user input, determine whether they should be defined as Features or as configuration attributes. Those inputs that are required for downstream operations must be defined as configuration attributes. Write attribute values collected during the configuration session into the CZ_CONFIG_ATTRIBUTES table.

      For example, width, length, and thickness contribute to items that specify material. These values can be modeled as configuration attributes and associated with the Materials items that need to go to manufacturing.

      For details about implementing configuration attributes, seeOracle Configurator Methodologies. Note that configuration attributes are not accessible to downstream applications without customization.

   5. If the items are only needed during the configuration session, define them as Features.

      For example, the hole size and type affect the selection of tools needed for creating custom-made sheets. Tool selection occurs during the configuration session. Add a Numeric Feature to get the hole size and a Feature with a List of Options to get the hole shape from the end user.

   6. Define Configurator Extensions for selecting the appropriate tool based on end users selections for hole shape and size.

   This step applies the best practice:

   • Items Versus Alternatives to Items

2. The Material submodel contains a large number of items. Organize these items under some logical grouping by making each logical group a separate model. Add non-BOM Features to get user inputs that determine which Material group to load. Each group model contains only items belonging to that group. For instance, if the group were based on material type, then add a Feature to capture a material type selection such as aluminum or steel.

   This step applies the best practice:

   • Grouped Versus Ungrouped Items

The graphic Redesigned Model With Fewer Items shows a top-level root Custom Metal Sheet Model that contains references to a submodels for Material and Machine, as well as Features for Width, Thickness, Hole Shape, and Hole Size.

Redesigned Model With Fewer Items

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 enhance the runtime performance, load only those groups of items that are needed by making instantiation of each group model optional, which means the value of Instance Minimum is 0, Maximum is 1. For example, a particular submodel group of the Material model is instantiated based on certain end-user criteria.

   This step applies the best practice:

   • Optional and Multiple Instantiation

2. Hide the parts of the BOM that do not require user interaction. For example, hide the Machine submodel.

   This step applies the best practice:

   • Optimizing User Interface Performance: Visibility Settings

The Resulting End-User Flow

The end user starts the order in the Order Management Sales Order Pad, selects the appropriate item to be configured, and launches Oracle Configurator. The Oracle Configurator UI starts with a page or pages for entering high-level order characteristics, such as material type, hole size, and hole shape. Based on the end user’s selection of a material type, the Configurator Extension loads the appropriate Material model. The end user selects the material and then enters the dimensions for the material, such as height, width, and length. These dimensions are collected as configuration attributes. The end user then selects a tool selection button which invokes a Configurator Extension to determine the appropriate tool for processing the ordered specifications.

At the end of the configuration session, the Configurator Extension writes the dimension attributes to the CZ_CONFIG_ATTRIBUTES table and populates the order line with the ordered material and tool.

For more information about configuration attributes, see Oracle Configurator Methodologies.

Advantages of This Modeling Approach

Perceived Disadvantages

• Differentiating whether items are orderable or merely participants in completing a configuration may require greater designing effort and more rule definitions than simply defining all characteristics as individual items.

• Using configuration attributes requires customization to retrieve the dimension attributes information from CZ_CONFIG_ATTRIBUTES for use in downstream manufacturing applications. This customization must be reviewed for possible modification when you upgrade Oracle Applications.

• Associating prices with characteristics that are defined as configuration attributes requires customization and the use of Advanced Pricing rules.

Overwhelming Advantages

Compared to the deficient approach presented in A Deficient Modeling Approach, the suggested approach provides the following advantages:

• Importing fewer BOM items is significantly faster

• Instantiating only groups of items at runtime that are needed by the current configuration is significantly faster than instantiating all items

• Maintaining a smaller BOM Model with fewer items is easier

• A relatively smaller BOM Model can be scaled better as the business grows without irreparably degrading performance