Integral Logistics Management — Operations Management and Supply Chain Management Within and Across Companies

17.3.3 A Data Model for Parameterized Representation of a Product Family (*)

Intended learning outcomes: Produce an overview on parameter and parameter class. Differentiate between primary and secondary parameters. Explain plausibility or compatibility test. Identify various types of formulas.


The production rules introduced in Section 7.3.2 as an extension of conventional bill of material and operation positions form the basic idea behind the generative technique for product families with many variants. Additional object classes are needed for a complete model. With respect to the information system, see also [Pels92], p. 93 ff., [Veen92], [Schö01], Section 13.3, or [Schi01]. See also [SöLe96] for a comprehensive application in the insurance industry. For an application in the banking industry and in the event of uncertainty, see [Schw96].

The master data model introduced in Section 17.2 must be supplemented with at least the following object classes:

  • Parameter: This is used to define the distinctive characteristics of an item, for example, dimensions and options.
  • Parameter class: A product family is described by an “item” entity. The specific products are also characterized by parameters or features. These are combined to form parameter classes for structuring the set of all parameters. The item ID of the product family, together with a value for each parameter of the assigned parameter classes, then defines a product as a specific feature of the product family.

Parameters may be subdivided into:

  • Primary parameters, which directly characterize the product family.
  • Secondary parameters, which can be derived from the primary parameters using a formula whose range of values is thus totally dependent on the primary parameters. Secondary param­eters are always needed if facts expressed by primary parameters can be better expressed for certain people using a different term.

The range of values that a parameter can assume may also be partly dependent on other parameters of the same class. In this case, we speak of:

  • A plausibility or compatibility test. This can take the form “If …,” for example, “If width > 1000, then height < 500,” or “If type = 2, then width <= 1500 and height <= 1500.” The simple logical expressions in the IF and THEN clauses may, however, become very complex.

The components of product families may, in turn, belong to a product family, even one with different parameter classes. It must therefore be possible to transfer parameter values from one parameter class to another, so parameter classes are declared in the form of bills of material:

  • Bill of parameter class position: This defines how a parameter from a (lower level) class is derived from the parameters of another (higher level) class. As with a secondary parameter, the parameter is derived using a rule or formula. The rule or formula may also be directly linked to the bill-of-material position that links the component to the product. If this is the case, the rule or formula can only be used to transfer the parameter values of this component from those of the higher-level product family.

It has been demonstrated in practice that, for complex connections, the quantities used, setup loads and loads per piece, and setup times and times per piece are dependent on the parameters, rather than being constant. Each of these master data attributes should therefore be linked to an arithmetical formula that expresses this dependency.

The formula is a logistical object for defining expressions that are dependent on parameters.

These formulas are maintained by the users and must therefore be easy to use. There are formulas for:

  • IF or THEN clause, a production rule, and a compatibility test. If these contain only one parameter, then they can be represented by a table. Other­wise, they are logical expressions in disjunctive or conjunctive normal form or free form, which can be evaluated using a formula interpreter using the rules of Boolean algebra.
  • Range of values. This may be a table or a general free-form logical expression.
  • Free-form numerical or alphanumerical expression, which never­theless uses a standardized syntax. Such an expression may be part of a logical expression or a formula for calculating attributes. A formula interpreter analyzes the algebraic expression using the basic operators, brackets, functions, and constants, with variable parameters, in accordance with the rules of arithmetic.

An object class that saves the parameter values of a specific product from a product family for an order or query is needed as an extension of the object classes for representing orders described in Section 17.1.

  • The parameter value object is linked to an item receipt order position and defines the value of a parameter for a product family. The value is taken from a range of values. Sets of frequently recurring parameter values, for example, for a cost estimating of “inter­polation points” for a product family, may also be defined as part of the master data.

While of relatively low degree of complexity, product configuration using knowled­ge-based tech­ni­ques has become important within expert systems, particularly since the product with a wide range of variants has become a significant marketing strategy.



Course section 17.3: Subsections and their intended learning outcomes

Print Top Down Previous Next