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 Characteristic Object dependency Instance product group option rules or dependencies between selectable options and parts 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