Decomposing a Configurator Design

Hi all,

I dont work on Variant Configuration all the time, it just depends if it is part of an implementation, or sometimes providing support to a client.  Some of you who live this stuff everyday probably have tips and tricks when looking at how a design is built.

Anyway, a couple of weeks ago I had a call from a client who I had helped implement VC about 3-4 years previous.  In that time they had restructured, people left, new people arrive, and all along VC just ticks along.  But the core knowledge of the Configuration had gone or was very minimal.  So I was asked to conduct a training course on how the configurator works.

This is always an interesting prospect, taking someone with no VC knowledge (and sometimes little SAP knowledge) along a path to become at least reasonably knowledgeable of VC.  Normally when doing a new implementation I have conducted a two day crash course, often starting from the KMAT end, to Classes and characteristics, Constraints, Procedures, Variant Tables, Preconditions, then ending up at the BOM.  This worked ok, but this time it was quite different.

I had a group of guys who knew how the configurator worked in the sales order, and that by magic it generated the required BOMs, and a bunch of "things" happened in the middle.  They knew that some parts of the configurator needed changes as it was selecting wrong components at times, or they needed to add options etc.  Usual changes really.

So the training needed a rethink, as this time they had some basic knowledge.  In gathering their training requirements it was clear that they really needed to understand how to decompose a configurator design.  So that got me thinking about my training courses and I came to the conclusion I had to run the training backwards!  I gave them an overview of all the parts of VC, but when we got into the practical detail we started at the BOM end.  This client is on SAP 4.7 so doesnt have that nice transaction PMEVC thats I have seen in ECC6.

Here was my logic:

The BOM/s tell you why a component is selected.  You can see if it is selected as a class item, or by selection condition.  This then gives clues as to what were the key parameters for the selection being made.  You can see if there are any special procedures for quantities etc.

I constructed a spreadsheet for them, where we put all the components in a column, then have subsequent columns to start recording why something is selected, then moving to discover the additional rules around this.  A copy of the spreadsheet is attached

Next, I told them to look at the Configuration profile and examine the constraint Nets and Procedures.  At this client when we implemented we used Variant Tables to control allowed values and to set values.  So I knew that if the looked at these next they would then start to see how the tables control so much, and that often they could add new options this way.

We recorded this information in the spreadsheet and then started examining setting defaults and preconditions.  So now they had moved forward greatly in knowledge but this was only day one.

On day two, we took another approach.  They had a new product they wanted to build in the configurator.  We had some initial discussions on what we thought we needed and built a KMAT, and the Super BOM.  We pasted all the components into the spreadsheet and started to work through "why and how" is this component selected.  We decided whether a class item was better, or just use a selection condition.

We then decided what characteristics we needed to support it, whether any of these needed to be restrictable, and if a Variant Table made sense.

We then started building our model.  I get each person to build their own so they do all the coding, classes, characteristics etc.  Then you see the penny drop as they do this, and then they start looking at existing designs and start solving their own problems.

But I found it a really good exercise in trying to decompose the configurator.  In the sandbox there are many models in there, and I find it useful to have a method to unravel we dont always comment them well! 

I am in the process of putting together some lessons.  A bit like some you will find on my personal blog. But the first one will just look at what I know about characteristics.  There is a lot to these when you think about it.



Melbourne Australia