The following article describes the requirements for sales configuration within Siemens A&D. The special challenge is "system configuration".
The first section of this article explains the basics of product modeling for system configurations.
In the second section we explain how we handle data maintenance given the requirement that the sales configuration result is the direct and synchronized input to manufacturing completion within R/3.
The third topic explains the consequences of the handling and mapping of the system configuration results to R/3 as a sales order.
Within Siemens A&D system configurations are very important. SAP's stated assumption is that 90% of application cases don't require system integration. This would only be true under this condition: all enterprises want to sell only simple products.
One example: Siemens sells the simple product, "circuit breaker" (and even this can be quite complex). Because breakers are usually simple, the ability to sell breakers in the internet is a requirement. This requirement can be fulfilled for the specific case where a customer wants to buy a single breaker.
Most customers, however, buy Siemens breakers because they are type tested components of Siemens Switchboards. The breakers are connected to controlling switches and need to be built into some kind of board.
As a result, the system solution "Switchboard" is the key for the sale of Siemens products. 90% of circuit breaker sales are to switchboard system manufacturers!
1. System Hierarchy
The slide shows a Product Structure (System Hierarchy). Some definitions:
A collection of products, e.g. Switchboard System 8PT contains these component products (or ps-nodes, see below): Section (rack), Module (kit) and Feeder (switching devices).
Systems have a structure. The nodes in such a structure represent product objects, so we call them ps(product structure)-nodes. Section, Module, Feeder. are examples of types of ps-nodes.
The product Structure is expressed by ps-nodes containing ps-nodes (i.e. linked by instances of the "contains" relation, see picture above).
In the sales configuration tool these ps-nodes are the sales objects to be configured by the user. The ps-nodes have cstics (characteristics), which the user configures by setting their values.
Every ps-node has a BOM of components, which is generated based on the settings of its cstic values.
The positions on the sales BOM of the ps-nodes are components.
The diagram below shows the ps-node, "Section". This ps-node has a "has parts" relationship to its Component BOM positions: e.g. Top plate, Door, Frame, Bottom plate.
The ps-node cstics are the sum of the cstics of the parts of the ps-node's BOM and their value domains.
Siemens uses an external Component Maintenance Tool to maintain the components and their variants as well as all dependency knowledge (see 2.).
1.4 Component Variants
The classification of Components results from assigned values to their cstics.
The combination of the cstic values of a component class defines the component variants. Each variant is the expression of one legal combination of cstic values. The component variant "is a" (see picture above) special expression of the component class (inheritance). This can be expressed in maximum BOMs (see picture above) or variant tables (see below).
Components and Variants can be expressed in compatible mode models using maximal BOMs with selection conditions; or in advanced mode models using variant tables, domain restrictions and has_part constraints.
The modeling effort is much higher for maximal BOMs. Variant tables are much more flexible for changes.
Siemens A&D uses advanced mode for sales configuration down to the component level. The component variants are the BOM heads of manufacturing BOMs (see 2. Process, below). As a result the manufacturing side only requires the maintenance of straightforward manufacturing BOMs, absolutely synchronized with the sales BOM.
The whole advanced mode configuration from the System to the Product (ps-node) level with the Component sales BOM takes place on the sales side (based on a lot of simple variant tables)!
To achieve an optimal business process we want maximal integration between sales and manufacturing. The most important requirement resulting from this goal is the synchronization of the sales BOM with the manufacturing materials.
Hence the sales model should only allow the configuration of component variants which are known on the manufacturing side (PDM). In the example below, the "Frame" KMAT on the sales side has a characteristic "component ID" with the material name of the "Frame" material on the manufacturing side (PDM).
Our Component Maintenance Tool contains all product related information about the product components which are the interface objects between CAD, Sales, and PDM, thereby ensuring the product release dependent synchronization between sales configuration and the selection of materials for manufacturing configuration.
The Component Maintenance Tool is an external tool for variant maintenance.
Scopes is a software tool developed by Siemens A&D (using DM, see 3.) on top of the IPC which manages this process and is used by the Sales engineers and the manufacturing engineers.
SAP R3 is used for sales modeling and for maintaining PDM data for both sales and manufacturing.
3. Handling of system configurations
Siemens has developed a shell on top of the IPC kernel to handle the complexity of system configurations (see 1.: definition of "system" and "ps-node"). This shell is called the "Dunk-in Manager". This is because of the functionality of this shell. The DM handles the system structure and "dunks" single ps-nodes into the IPC configuration when the ps-node characteristics are changed.
3.1 DM (Dunk-in Manager)
The DM is responsible for splitting the configuration along the contains relation (see 1.).
This supports system configurations by:
- handling product system structures outside of the configuration
- allowing slotting by driving procedural slotting functions outside the configuration
- improving the performance of the application
- driving the offer and order interface functions
3.2 The Dynamic Slotting Problem
The possibility of dynamic "slotting" is a consequence of system
configurations. Dynamic slotting is required, for example, because the
position of each
circuit breaker device in a Switchboard section/cubicle must be known
in order to carry out space demand and placement calculations. Later
on, manufacturing needs to know the positions, too. Therefore we need
to carry product structure and geometry down to the manufacturing
For simplicity of maintenance, we would like to store all the circuit breakers on a single BOM position. Advanced Mode allows us to do this at sales time, but when we come to R/3 for order processing and to prepare the manufacturing configuration, the paradigm breaks down and we need to multiply out the circuit breakers to, in the worst case, hundreds of BOM positions
The requirement for "Dynamic slotting" (see picture below) is handled by the so called "multi instantiation" of BOM positions in advanced mode.
The CWG Review article, "Optimization and the Slotting Problem" by Peter Illing (CWG Portal - Feature Article Archive) explains why the multi instantiation of BOM positions is absolutely required for system configuration.
The main problem for the SAP standard interfaces to R/3 is: they can't handle "dynamic slotting" / multi instantiation BOM's
All "dynamical slotting" problems are, however, simple to solve by external "mapping". This external mapping to Siemens R/3 order entry was solved with external functions as a part of the DM (Dunk-in manager).
We will address the support problem we have with SAP in the summary (section 4).
The example below shows that there is no 1:1 mapping from left to right for position 30 for dynamic slotting! R/3 does not allow two BOM instances with the same position (30) and class (Feeder 1). So the SAP standard mapping doesn't work.
But we have the structure at the left below (dynamic slotting based on multi instantiated BOM positions) and want two (non-identical!) instances of the same Class (Feeder 1) at Position (30). This is multi-instantiation!
We require a mapping program which transforms the structure on the
left (out of the sales configuration) to the structure on right (into
the R/3 order entry).
There are two main problems facing companies that sell system configurations: "advanced mode variant configuration (VC++)" and "order entry mapping".
We want the CWG to pursue an agreement from the SAP side to accept mapping for "dynamic slotting" problems as a strategic requirement for the future.
Today static slotting with the existing SAP standard CRM interface (see above 1:1 mapping) works only with severe restrictions:
- There is no mapping for advanced mode configuration results,
- There is no mapping for compatible mode configuration results if there is no 1:1 mapping (e.g. logistical/manufacturing mapping requirements, not all sales components are manufacturing relevant, ...)
We want SAP to precisely describe the current conditions and exclusions.
The VC++ / (CRM or ERP or R3) interface exists in some customer applications at the moment (with 1:1 or 1:n mapping).
Non SAP standard interfaces are already part of many applications. In this case SAP doesn't need to support the interface (this is the application programmer's responsibility).
Siemens A&D has provided an example of the problem description and the solution for the 1:n mapping in the article above. This may lead to a simple solution for standard mapping.
We will join the CWG in working with SAP on specifications for the 1:n mapping for certain standard cases as the content of the "Integration workgroup" of the CWG.
4.2 Advanced mode configuration
The second problem for system configuration is the requirement to use the advanced mode in sales configurations (VC++).
SAP 2005 does not support advanced mode. The following table
compares (Siemens A&D) sales requirements with the current
abilities of SAP 2005:
|Requirement||Siemens A&D||SAP 2005|
|Compatible mode configuration||+||+|
|Advanced mode configuration||+||-|
|Online and offline configuration||+||-|
|System configuration (system to product level)||+||-|
|No maximal BOM's required (unnecessary for sales)||+||-|
|Multi instantiation (major prerequisite for system configurations)||+||-|
|Dynamic slotting (consequence of system config.)||+||-|
|Static slotting (component can't have diff. positions)||+||+|
|1:n order entry mapping||+||-|
|1:1 order entry mapping||+||+|
|Sum||10 +||3 +|
The current SAP 2005 fails to fulfill 7 of 10 absolutely required functionalities of system sales configurations.
Most product manufacturers want to be suppliers for system solution sellers!
The system solution producers want to have system solution configurations.
The optimal system solution configuration takes functional requirements for the product(s) and provides a sales BOM synchronized to the manufacturing materials!
At least two applications presented at the CWG (May, 2005) had exactly these system configuration requirements (Putzmeister AG, Lenze AG).
Our assertion: There is no perspective for the future without integration of system configurations.
Consequence: The CWG must drive SAP to support the integration scenarios.Please send comments to Peter Illing, at firstname.lastname@example.org.