Product configuration overview

In both business-to-business and business-to-consumer relationships, you often need to configure products to meet special requirements.

A manufacturer that supports configure-to-order scenarios can better address customer needs. By stocking semi-finished goods as generic components instead of finished products, the manufacturer can reduce the capital tied to inventory.

A successful move from a manufacture-to-stock setup to a configure-to-order setup requires careful analysis of the product structures, identification of product families, and componentization. To reduce the number of parts and minimize the number of goods in process, it's important that you understand the product interfaces and design for reusability.

Several product configuration modeling principles exist, such as rule-based, dimension-based, and constraint-based modeling. Studies show that the constraint-based methodology can reduce the number of code lines in models by about 50 percent compared to other modeling principles. Therefore, this methodology can reduce the total cost of ownership (TCO). By moving from a rule-based model that is based on X++ code to a constraint-based model, you no longer need a developer license to maintain product models.

Product configuration

The industrialization period led to great achievements in producing high-quality and feature-rich products at affordable prices. Economies of scale made it possible for most people in the industrialized world to buy cars, TVs, household appliances, and other goods that most of us consider a necessary part of our everyday life.

As many products become commodities, a need arises to differentiate them. The immediate response of manufacturers to this challenge is to create variants of each product, so that customers have more alternatives. This strategy leads to increased forecast challenges, and also to an increase in inventory cost and unsold products that become obsolete.

By adopting a configure-to-order philosophy, manufacturers can meet customer demand for unique products while reducing or eliminating obsolete inventory items. When shifting from a manufacture-to-stock philosophy to a configure-to-order philosophy, one immediate challenge is to balance the need for short lead times against low inventory levels.

The key to success is to carefully analyze the product portfolio and look for patterns in both product features and processes. The goal is to identify generic components that the same equipment can manufacture and use in all variants.

The product configuration feature set includes a user interface (UI) that provides a visual overview of the product configuration model structure, and also a declarative constraint syntax that doesn't require compilation. Therefore, companies that want to support a configuration practice can get started more easily. As the following sections explain, a product designer no longer requires the support of a developer to build a product configuration model, test it, and release it to the sales organization.

Building a product configuration model

Several approaches exist for building a product configuration model. One option is to follow a sequential flow by first creating all the reference data, such as product masters, distinct products, and operational resources, and then including them as components, bill of materials (BOM) lines, route operations, and other elements of the product configuration model. Alternatively, you can select a more iterative approach by first creating the model and then adding reference data as the need arises.

Components

A product configuration model consists of one or more components that connect through subcomponent relationships. Define components once, and then use them multiple times in one or more product configuration models. Components are the main building blocks of a product configuration model, and nearly all information about the model relates to them.

Attributes

Each component has one or more attributes that identify its properties. Users choose the attributes during the configuration process. Attributes control both inter-component and intra-component relationships through inclusion in constraints or calculations. Through conditions applied to BOM lines, attributes can determine which physical parts the configured product consists of. Additionally, an attribute can control the property of a BOM line through a mapping mechanism. Similar functionality exists for route operations regarding both inclusion and property settings.

Expression constraints

Use of a constraint-based product configuration model implies that some limitations exist when the user selects values for the various attributes. Implement such limitations as expression constraints by using the Optimization Modeling Language (OML). Alternatively, implement a constraint in the form of a table constraint.

Table constraints

Table constraints can be user-defined or system-defined.

A user-defined table constraint is built by the user. The user selects a combination of attribute types to represent the columns of the table and then enters values from the domains of the selected attribute types to form the rows in the table constraint.

A system-defined table constraint is defined by selecting which table to use as a reference and then selecting fields from this table to form the columns in the constraint. The rows of the table constraint are the rows of the Supply Chain Management table that are present at configuration time.

Include a table constraint in a product configuration model by referencing the table constraint definition and mapping the relevant attributes in the model to the columns in the table constraint.

Calculations

Calculations represent a mechanism for performing arithmetic operations in a configuration model. For example, a calculation can determine the length of a specific piece of raw material or the processing time for a polishing operation. Calculations are imperative and set the value for a target attribute after all the attribute values that are included in the calculation expression become available.

Subcomponents

Subcomponents represent the nodes in the product configuration model structure. For each subcomponent relationship, specify a reference to a product master that has the variant configuration technology set to constraint-based configuration.

User requirements

A user requirement has all the constituents of a subcomponent. The only difference is that a user requirement isn't bound to a product master. The practical effect of this difference is that any BOM lines or route operations defined in the context of a user requirement are collapsed into the parent component BOM structure or route. This behavior resembles the behavior of a phantom BOM.

BOM lines

Include BOM lines to identify the manufacturing BOM for each component. A BOM line must reference an item, and all item properties can be set to a fixed value or map them to an attribute.

Route operations

Include route operations to identify the manufacturing route. A route operation must reference a defined operation, and you can set all operation properties to a fixed value. You can map all properties except resource requirements to an attribute instead of a value.

Validating and testing a product configuration model

Validation of a product configuration model can occur on several levels in the model and can therefore cover various scopes. The lowest level is for a single expression constraint. In this case, the product designer typically performs validation to verify that the syntax of an expression is correct.

Similarly, a condition for a BOM line or a route operation can be validated in isolation.

Validation can also be done for a user-defined table constraint definition. In this case, the user verifies that the values entered for each field are inside the domain of the corresponding attribute types.

Finally, validation can be done for a complete product configuration model to verify that the complete syntax is correct, and that all naming and modeling conventions are respected.

Testing

Testing a model is similar to running an actual configuration session. The user can walk through the configuration pages and verify that the model structure supports the configuration process. The user can verify that the attribute values are correct, and that the attribute descriptions guide the user to select the correct values. Finally, after a test session is completed, the system tries to create the BOM and the route that corresponds to the selected attribute values, and presents an error message if anything goes wrong.

The configuration page

To navigate between components, select Next, or select a component in the product configuration model tree to set focus on it.

Finalizing a model for configuration

When a product configuration model is ready to use in configure-to-order scenarios, you need to create a version. However, several options can enhance the modeling experience.

User interface

Modify the configuration UI by introducing attribute groups in one or more subcomponents. This grouping highlights the relationships between specific attributes and helps the configuration user identify the area of the product that is currently in focus.

Templates

Create one or more configuration templates to speed up the configuration process. Alternatively, create templates to promote specific attribute combinations, such as when a sales campaign focuses on a specific set of product features.

Translations

If the product will be sold in different countries/regions, translations can be created for all text that appears in the configuration UI. This text includes not only name and description fields, but also attribute text values.

Versions

Create a version for the product configuration model. The version represents the relationship between the product master, which can be selected for configuration on an order or quotation line, and the product configuration model. A version must be approved and activated before it can be used in a configuration session.

Extending a product configuration model through the API

Partners and others with a developer license can extend the capabilities of a product configuration model by using a dedicated application programming interface (API). The main goal is to establish a mechanism that lets partners and customers who use the existing Product Builder migrate the code that is embedded in Product Builder models to the API. By using this mechanism, they can migrate their models from Product Builder to a product configuration. However, new partners and customers can also benefit from using the API to extend new product configuration models.

The API is implemented by using a set of PCAdaptor classes that expose the data structure of the product configuration models. An instance of the PCAdaptor class must be created for each model that can be extended. After a configuration session is completed, the system checks for an instance of this class and runs it if it's found.

The following API flow diagram outlines the process.

Configure products

Configure one or more products

You can configure products from the following places:

• Sales order line
• Sales quotation line
• Purchase order line
• Production order line
• Item requirement line (project)

The purpose of the configuration is to create a distinct variant of the product that meets the customer's requirement. A unique configuration ID is created for each new configuration. This ID enables tracking through inventory.

Multiple sites and intercompany considerations

If the configuration is done at a site, or even a company, that differs from the site or company where production occurs, the BOM and the route are created for and put them at the supplier site in the supplying company. The product variant is released in all companies that participate in the supply chain.