Starting a Variant Configuration Project

When you start a project that uses variant configuration as its goal, it is useful to allow 1 or 2 days
for the following:

to gain an overview of the current product mapping,

and from this, to draw conclusions about important product modeling basics in R/3
to define the tasks of the project team based on this information.

To gain the needed overview, the following questions have proved useful for the first working
session.

What are the products?

What is being
sold? Assessing
the product from
a sales point of
view
(Limit yourself to
the main process!
For example, with
the sale of
machinery, leave
processing of
spare parts alone
for the present).
What is relevant
to the price?
How many
products exist?
What does the
current
product/BOM
structure look
like?
Is there a
subdivision into
standard and
customer-specific
structures?

How much do the

individual
products differ?
First assessment: Type and quantity of configurable products on product level

How are the products described?

Do the customer
options only exist
on the highest
level of the sold
product?
Is the sales
employee alone in
a position to
describe the
product his
customer?
If not:
Who is involved in
a further
completion of the
sales order?
What form does
the further
completion of the
product
description take?
(manually by
engineers,
automatically by
existing
procedures?)
What sort of
options do the
products have?
Are restrictions
linked to the
options or
combinations of
them?
(e.g. a car can be
delivered with or
without a sunroof.
A sunroof does
not make
any sense with a
convertible)
Can the products
be grouped
together?

First assessment:
o
o

Structure the products (see picture above)

Structure the customer relevant options (materials, classes and characteristics)
Describe the options (characteristics description).

o
o
o

WHAT sort of existing data is relevant to the use of variant configuration in R/3
sources of info.?
HOW MUCH time and effort is required to gather the data relevant?
WHO must be included in this process?

Which requirements are known for the product?

Are there IT (or other) tools that support the processing of the customer specific product
configuration (for example, an editor for an order BOM)?
Are there other documents or computer programs describing dependencies between
product parts?
When should procedures, such as sales check lists assisting the sales employee with the
product description because he/she lacks the necessary technical knowledge be used?
(e.g. integrated in SD, on a laptop or on internet).

First assessment:
o
o
o
o
o

What type of object dependencies (variant tables, simple selection- and

preconditions or complex constraints) are needed?
Can SAP object dependencies map the customer logic?
Are variant functions needed (e.g. to call existing calculation functions)?
Effort involved in specifying and implementing the object dependencies
Who must be involved?

How is the product handled during order processing?

Can the product be processed immediately after the sales order has been created?
Should sub-assemblies from other areas/user departments be described in detail as part
of the model for the sales relevant product?
How frequent and extensive are customers' special requirements that cannot be
foreseen? (Indicator for order BOM)
Are there further business processes for the product (or parts of the product) besides
sales order processing? (Sales quantity planning for a specific product spectrum,
preplanning of parts of the products, spare part processing)
Which phase of the sales order are changes allowed in?

First assessment:
o
o
o

Which scenario will be used most? (planned or production order / single or multilevel interactive configuration, sales order set or order BOM)
Which other SAP processes have to satisfy the special features of variant
configuration?
Which business processes are there no standard solutions for? (for example,
you
configuration changes to the order are allowed up to product delivery
cannot automatically derive the consequences for all existing documents
planning order, production order, purchase orders etc.)

Other important topics

Ask at the start: Why do we want to use of variant configuration in this project?

Besides technical necessity (diversity of variants, customer-specific sales order

processing), other project goals should also be gained (for example,
considerable shortening of order processing times due to automatic generation of
the order BOM). These additional goals can serve to justify the time and effort
afforded in the project phase!

The effort that may be necessary to implement variant configuration should be estimated
and discussed in the project team. There are very rarely data sources that allow you to
convert the current data to the required SAP structures quickly and easily!
As far as possible, avoid "SAP variant-specific" terms such as classes, characteristics,
instances, pre- or selection conditions, constraints, and so on. Try also to avoid the
temptation to want to explain the different possibilities afforded by variant configuration!
The customer has often not yet done any of the courses and therefore does not
yet understand the complex connections.
Other possible terms:

Class

product group

Characteristic

option

Object dependency

rules or dependencies between selectable options and

parts

Instance

part of the configured product; item in the maximum

BOM that got chosen by the variant configurator

Demonstrate the above mentioned to the project team AS SOON AS POSSIBLE (best
within the first two days) on an SAP system and demonstrate a simple but complete
business process (sales order, MRP, production order with costs, delivery, invoices).
o Construct a simple example with the customers' data in an installed R/3 system
o If for any reason you cannot do this, use IDES! (The Harley Davidson is very
suitable for this and furthermore there are overheads for it!)
When you create a project team, you should make sure that representatives from all user
departments that have to deliver relevant modeling information are also involved in the
project work from the start.
Sales and development/construction form the focal point, but also subsequent
user departments involved in order processing (planning, purchasing, production
and assembly processing) deliver important information that can influence the
product model.
>> Go to Top of Document