In many industries, in particular automotive, rather than choosing a particular variant of the product, customers "build" the product "à la carte" by choosing a set of options the final product should feature. An option denotes a part of the product (such as sunroof, air conditioning, CD player, leather upholstery, etc.) that should or should not be present in the product shipped to the customer. The following figure gives an example of options a customer might order on a product:

Customer-selected options

    Options are represented in OptiLine by way of implicit variants or BOM. For instance, the BOM may contain the information that 10% of the cars produced on the line will have a sunroof and 15% of the cars produced on the line will have air conditioning, such as in the following simple example:

A simple BOM representing two options

    BOM nodes are linked to operations that are carried out whenever a product featuring the corresponding option is being assembled, as in the following example (learn here how to link BOM nodes to operations):

Precedence graph with optional operations

    In this example, the gray operations ("Regular_1" through "Regular_7") are not linked to a BOM node and will be carried out on all products being assembled. Such operations are sometimes called "standard" or "base" operations. On the contrary, the green operations ("Sunroof_1" through "Sunroof_3") will only be carried out if the product being assembled has the option "Sunroof", which will happen 10% percent of the time according to the BOM, while the blue operations ("Airco_1" through "Airco_4") will only be carried out if the product being assembled has the option "Sunroof", which will happen 15% of the time.

    While the BOM offers an extremely concise way of representing thousands of different products, it only contains average frequencies of occurence of each option in the whole production. It lacks the information on how the different options are combined in the actual products being assembled on the line.
    The following precedence graphs represent the four possible products that could be assembled on the line given the above BOM. However, from the BOM alone it is not clear how often each of them will occur in an actual production:

The four possible products given the above example

    The above example tells you that 10% of the products will have a sunroof and 15% will have an air conditioning, but it does not tell you what percentage of the products will have both the sunroof and the air conditioning, yielding the precedence graph in the bottom right. That percentage could be between 0% (no car with sunroof also having air conditioning) and 10% (every car with sunroof also having air conditioning).

    Consequently, the BOM alone only allows for optimization of the line on average (that is, in the long run), but cannot account for transitory overflows of the cycle time caused by combinations of options that are very difficult to assemble on some workstations. Such overflows may lead to lines difficult to run.
    Indeed, suppose that some operations pertaining to mounting the sunroof and some pertaining to mounting the air conditioning are assigned to the same workstation. Since each of the operations concerns only a small percentage of the production, on average the workstation will probably finish all its operations within the cycle time. However, whenever a car is being assembled that features both of the two options, finishing all the operations may significantly exceed the cycle time. Depending on the layout of the line (e.g. possible buffer spaces), this may cause the line being stopped to allow the workstation to finish its work. Naturally, such stoppages are extremely expensive and should be avoided.

    In order to account for transitory peak times in workstations, OptiLine needs to know what combinations of the different options can be expected to appear in the production. This is done by specifying a list of product models, each having a given set of options and a percentage of occurence in the production. Models are defined in the Edit Product Mix dialog.
    When defined, the models are taken into account during optimization in a way similar to explicit variants. There is one crucial difference: the sum of percentages of all models can be smaller than 100%. This spares you the hassle of enumerating all possible models that could ever be assembled on the line, and concentrate instead on only the relevant ones. A useful set of models should contain models that

When product models are defined, the optimizing algorithm attempts to find the best tradeoff (according to the MP/Balance setting, see below) between

In the above example, pursuing the second objective may involve avoiding assignments of Sunroof operations to the same stations as Airco operations, if a model featuring both options is defined. If such a model is not defined (say it's never built at all, or only in negligible numbers), then the possibility of products with both options will be ignored and the algorithm will not attempt to dissociate the operations on workstations. Note that this may lead to a line better balanced on average.

    It is important to realize that these two objectives are often antagonistic: a perfectly balanced line may suffer high peak times for some models, reducing the efficiency of the line by repeated stoppages. Conversely, a line with very low peak times for all models may be highly disbalanced on average, reducing the efficiency of the line due to long idle times. The relative importance of each of the two criteria in the optimization is specified by the MP/Balance slider in the Optimize Dialog.