Restricting Characteristic Domains

Copyright © by Steve Schneider

Not believing it, the modeler finds that, yes, it really does work. Trying to explain it to a coworker quickly gets both modelers into thinking the discussion should be over a bottle of beer, or maybe even over many bottles of beer, especially when Marketing changes their mind... Oh, they never do that??

Foreword

In the November 2004 meeting of the CWG, there were many comments regarding a need for “best practices for product modeling”. If you attended, you may remember that I was one of the more vocal people wanting to have a forum to propose best practices among the modeling experts. I even went as far as proposing SAP give their stamp of approval to the best practices after review by the CWG at large. The main reason I wanted this forum is due to the history of the product model at my employer, Steelcase, Inc.

Over the past 7 years using SAP’s R/3 Variant Configurator, Steelcase has used multiple methods to construct product models, especially surrounding the use of characteristics. Personally, I don’t feel that Steelcase has a best practice in place for the use of characteristics. This is partly due to the lack of any published, industry standard, software provider approved, best practices that I could have held up to my peers and coworkers in I.T. and stated “look what other experts are saying and doing”.

So, having fully inserted my foot into my mouth at CWG, I thought it only right that I should try to describe a best practice for characteristics and their values, based on my company’s experience. This article is a direct result of those experiences, and yes, you can even assume that I am the confused, wandering, product modeler. It’s a situation many people here at Steelcase see every day. Hopefully, I’ve written this in a manner that is understandable, yet allows you to smile at (and maybe relate to) my thought processes…

Everyone may not be familiar with how office furniture is specified, but most people can relate to a bicycle. I think most people have experience riding a bicycle, although many may not have fallen off them as much as I have!! So, these examples will be done with a mythical bicycle manufacturer and a couple of products that they sell. Hopefully, I’ll be able to make the subject matter clear. Please take each example independently, on it’s own merits.

Background

Simply put, a characteristic is used to describe a material during specification, and the characteristic values make that description specific. For example, in our mythical bicycle company, the bicycles may be painted in different colors. The characteristic specified by the customer will be called COLOR and the values would be RED, GREEN, BLUE, and BLACK. Collectively, all of the values are referred to as the domain of possible characteristic values.

In the case of our mythical bicycle company, the racing bicycle is a product sold to one market while a mountain bicycle is sold to another. The racing bicycle is sold under product number RACER while the mountain bicycle is sold under product number MOUNTAIN.

So, what does our product modeler do when the Marketing department, in their infinite wisdom, says; “A racing bicycle may only be sold in Red and Green, and a mountain bicycle may only be sold in Green, Blue, and Black”??

Naturally, the product modeler restricts the domain of allowed characteristic values based on the application. It sounds so easy doesn’t it?? As the product modeler for our mythical company, it is up to me to allow only the values that Marketing has dictated, yet use the techniques that;

  • Allow greatest reuse of all variant configuration objects involved (to make I.T. happy)
  • Allow maintenance to be as easy as possible (because I'm lazy and don't like to work real hard)
  • Allow the product model to be easily understood by the next poor person Management can sucker into doing this thankless job. Oh, I mean the next Product Modeler.
  • Allow fast introduction of new products that may utilize the same characteristics (to make my management happy so I can do “other stuff”)

Description of Techniques

After going to Variant Configuration training, then reading the SAP Help files, our intrepid (but confused) product modeler decides there are at least 6 basic methods in SAP to accomplish the Marketing mandate. The modeler decides to try them all in the development system and see what works best.

The techniques tried will be:
1. Create two unique characteristics
2. Utilize preconditions to hide the values until appropriate
3. Specialize the characteristic during class inheritance
4. Overwrite the characteristic during assignment to a class
5. Utilize a function based value check against a ZTable
6. Use constraint based modeling

The methods for utilizing each technique will be described in turn.

Technique 1 . Create two Unique Characteristics

As you are probably aware, each characteristic must be assigned to a class before it can be used in the product model. At it's most basic concept, the product modeler may choose to create 2 unique characteristics:
  • COLOR_1 is a characteristic that only contains the values Red and Green
  • COLOR_1 is assigned to class RACER_1
  • Class RACER_1 is then assigned to material RACER
  • COLOR_2 is a characteristic that only contains the values Green, Blue, and Black
  • COLOR_2 is assigned to class MOUNTAIN_1
  • Class MOUNTAIN_1 is then assigned to material MOUNTAIN
Each material can now only be specified in the colors that Marketing has dictated. Not too difficult to accomplish, but the modeler doesn't like having 2 characteristics to maintain.

Technique 2 . Utilize Preconditions to Hide the Values until Appropriate

This technique uses only 1 characteristic for the Color. The product modeler creates:
  • COLOR_1, a characteristic that contains all possible colors allowed within the company. Red, Green,Blue, and Black are all valid values.
  • COLOR_1 is assigned to class BICYCLE_1
  • Class BICYCLE_1 is assigned to materials RACER and MOUNTAIN
  • Preconditions are written and assigned to each value that display that value under certain conditions

Under what condition will the configuration know when to display only the correct values? Can the precondition even be written using only the information we have at hand??

Since the precondition does not know what material number is being specified, the product modeler must introduce something into the model to allow the preconditions to know when each value should be displayed. One method (of many potential methods) is to introduce a hidden characteristic called PRODUCT_TYPE with values of RACER and MOUNTAIN.
In the configuration profile of material RACER, a procedure sets the value of characteristic PRODUCT_TYPE to RACER.
In the configuration profile of material MOUNTAIN, a different procedure sets the value of characteristic PRODUCT_TYPE to MOUNTAIN.

In this scenario, preconditions can now be written that look at the characteristic of PRODUCT_TYPE to determine which values are allowed under each material.

Example syntax of these preconditions would be:

$ROOT.PRODUCT_TYPE = ’RACER’
This precondition would be assigned to the value of Red

$ROOT.PRODUCT_TYPE = ’MOUNTAIN’
This precondition would be assigned to the values of Blue and Black

What about the value GREEN, doesn't it need a precondition?? In this case, no it does not, as this value is allowable on both materials. This method works, but it sure seems like a lot of work and it isn't easy to understand. What happens if Marketing decides to limit the color choices based on some other bright idea??

Our modeler takes a deep breath and presses on.

Technique 3 . Specialize the Characteristic during Class Inheritance

This technique again only utilizes one characteristic representing the Color. Our modeler creates;
  • COLOR_1 is a characteristic that contains all possible colors allowed within the company. Red, Green, Blue, and Black are all valid values.
  • Class COLOR is created with characteristic COLOR_1
  • Class RACER_1 is created and assigned as a subordinate class to class COLOR
  • During the class assignment process, the modeler specializes the inherited characteristic COLOR_1 to only allow the values of Red and Green
  • Class RACER_1 is then assigned to material RACER
  • Class MOUNTAIN_1 is created and assigned as a subordinate class to class COLOR
  • During the class assignment process, the modeler specializes the inherited characteristic COLOR_1 to only allow the values of Green, Blue, and Black
  • Class MOUNTAIN_1 is then assigned to material MOUNTAIN

During the class assignment process, the modeler would double click on the characteristic contained in the superior class. A pop up screen would appear (similar to what appears during configuration) which allows the modeler to pick only the values that will be allowed in the subordinate class. Upon save, only the values selected would appear during configuration.

This method accomplishes the goal. It's pretty tedious and seems to limit what can be done with the subordinate class.

The modeler can't help but wonder what would happen if an additional characteristic is needed in this class.

Time to move on.

Technique 4 . Overwrite the Characteristic during Assignment to a Class

This technique again only utilizes one characteristic representing the Color. Our modeler creates

  • COLOR_1 is a characteristic that contains all possible colors allowed within the company. Red, Green, Blue, and Black are all valid values.
  • Class RACER_1 is created and characteristic COLOR_1 is assigned to this class
  • Characteristic COLOR_1 has the values overwritten to only allow the values of Red and Green
  • Class RACER_1 is assigned to material RACER
  • Class MOUNTAIN_1 is created and characteristic COLOR_1 is assigned to this class
  • Characteristic COLOR_1 has the values overwritten to only allow the values of Green, Blue, and Black
  • Class MOUNTAIN_1 is assigned to material MOUNTAIN

During the assignment of the characteristic to the class, the modeler selects the characteristic and enters Overwrite mode (via icon or menu path). Once in overwrite mode, the modeler selects the values that are not applicable for the application and deletes them. Upon save, only the remaining values are allowed during configuration.

Well, this did achieve the goal and seems fairly easy. Oh wait, the modeler mistyped the description in the global characteristic. After changing the description, we find that the description is still wrong in both overwritten characteristics until we change it there as well…

What happens if a constraint is needed to limit some other choice based on color? Does each class need to be referenced?? Maybe it's time to reconsider this idea..

Technique 5-Utilize a Function Based Value Check Against a Ztable

This technique again utilizes only 1 characteristic representing the color.

Our thoroughly depressed modeler decides that help is required so a call is made to the I.T. department. During the conversation, a bold ABAP programmer says something like "I can solve all your problems for you using a function. It's really cool and you don't have to do anything"…Of course, any modeler that has heard that more than once will be skeptical, but, looking for the easy way out, our modeler decides to go explore this alternative. Based on the advice, our modeler creates;

  • COLOR_1 is a characteristic that contains no values
  • The modeler meets with I.T. and fully describes the business situation, including a spreadsheet listing all possible combinations of product and color alternatives.
  • I.T. creates a Ztable called Z_COLOR with fields for Product and Color, then loads the spreadsheet values into it
  • I.T. then creates a function module named Z_COLOR_CHOICES that reads the Dynamic Database (DDB) during configuration, gets the material number from the DDB instance, takes it into the table, selects only the matching rows and only allows those colors as choices in characteristic COLOR_1.
  • Our modeler assigns function module Z_COLOR_CHOICES to characteristic COLOR_1
  • Characteristic COLOR_1 is then assigned to class RACER_1
  • Class RACER_1 is assigned to material RACER
  • Characteristic COLOR_1 is then assigned to class MOUNTAIN_1
  • Class MOUNTAIN_1 is assigned to material MOUNTAIN

During the creation of the characteristic, the modeler clicks on the Values tab, then clicks on the "Other Value Check" button, then selects Funct. Module from the resulting list. The modeler then enters the function module name into the entry box. Upon save, only the values matching the rows in the table, keyed on the material name, are allowed during configuration.

Not believing it, the modeler finds that, yes, it really does work. Trying to explain it to a coworker quickly gets both modelers into thinking the discussion should be over many bottles of beer, especially when Marketing changes their mind..Oh, they never do that??

Lets see what the last technique offers.

Technique 6- Utilize Constraint Based Modeling

By now, our modeler is really tired and still doesn't like any of the alternatives (especially technique 5)…Somewhere, somehow, there must be a better way….

This technique again utilizes only 1 characteristic representing the color. Our modeler creates;

  • COLOR_1 is a restrictable characteristic that contains all possible colors allowed within the company. Red, Green, Blue, and Black are all valid values.
  • Class COLOR is created with characteristic COLOR_1
  • Class RACER_1 is created and assigned as a subordinate class to class COLOR
  • Class RACER_1 is then assigned to material RACER
  • Class MOUNTAIN_1 is created and assigned as a subordinate class to class COLOR
  • Class MOUNTAIN_1 is then assigned to material MOUNTAIN
  • Variant table T_COLORS_RACER is created with characteristic COLOR_1
  • Allowed values in this table are Red and Green
  • Variant table T_COLORS_MOUNTAIN is created with characteristic COLOR_1
  • Allowed values in this table are Green, Blue, and Black
  • Dependency net S_RACER is created with constraint S_RACER_COLOR.

Syntax of this constraint is;

OBJECTS:
?A IS_A (300)COLOR WHERE
SPEC = COLOR_1.

RESTRICTIONS:
TABLE T_RACER (COLOR_1 = SPEC).

INFERENCES:
SPEC.

  • Dependency net S_RACER is assigned to the configuration profile of material RACER
  • Dependency net S_MOUNTAIN is created with constraint S_MOUNTAIN_COLOR.

Syntax of this constraint is;

OBJECTS:
?A IS_A (300)COLOR WHERE
SPEC = COLOR_1.

RESTRICTIONS:
TABLE T_MOUNTAIN (COLOR_1 = SPEC).

INFERENCES:
SPEC.

  • Dependency net S_MOUNTAIN is assigned to the configuration profile of material MOUNTAIN

Once all objects have been saved, the system will only allow the values in each table to be present during configuration.

 

This works, doesn't seem all that difficult (after everything else) and seems to lend itself to easily adding other objects as needed. Maybe, just maybe, our modeler has found a workable solution..

Comparison of Techniques

Our product modeler has completed a journey through the realm of SAP, and now it's time to decide which technique to implement…At first glance, technique 1 (2 characteristics) seems pretty easy while technique 6 (constraint based modeling) seems pretty hard.. Remember the cliche "looks can be deceiving"?

The issues with techniques 1-5 are very similar. In some way, none of them

  • Hold all of the values for COLOR in one place, or
  • Reduce maintenance of objects (characteristics, classes, etc), or
  • Lend itself to controlling other situations in the model that may be based on the color selection, or
  • Reuse objects, or
  • Limit the number of objects that are required in future additions of color choices, or
  • Work well in other SAP applications (such as the IPC)

Specifically, techniques 1 and 4 both require multiple characteristics. In fact, technique 4 actually utilizes 3 characteristics, as SAP will create a new entry in table CABN (and all other associated tables) that represent each of the overwritten characteristics. Maintaining the global characteristic does not maintain the overwritten characteristics. This means you have 3 characteristics to maintain.

Technique 2 forces the creation of characteristics that have no real meaning to the model. They are there only to control the values and must now be maintained along with everything else. Preconditions also fire every time the enter key is pressed in configuration and may not work in all circumstances where the characteristic is used.

Technique 3, while keeping all the values in 1 characteristic, is very difficult to maintain. Try it. You will find that every time you introduce a new value, the process of checking and unchecking the allowed values is slow, tedious and not user friendly. On top of that, allocating (or unallocating) new objects to the subordinate class is not pleasant, especially if there are orders in the system…

Technique 5, while being very simple for the modeler, forces us into the realm of I.T. I don't know about you, but I try to avoid custom data dictionary objects and/or code whenever I can. It's not that I don't like my I.T. department, I just think they have other things to do that add lots more value to the company. This method also means that every time the model changes in some way, we need to get I.T. involved. On top of this, to my limited knowledge, this technique will not work in any IPC model.

Only technique 6 lends itself to solving most of the issues with model maintenance. By using class inheritance, you only have 1 characteristic for color and you only need to refer to the one class that contains that characteristic. The tables only allow the values entered in the characteristic and are very easily maintained. The real benefit comes when Marketing decides to get fancy. The use of inheritance, tables, and constraints all lend the model to being the most flexible. When Marketing comes along and says "Oh, now that our bicycles are being sold, we found out that we can only offer the triangular saddle on the Racing bicycle if the color is Green, and on the Mountain bicycle if the color is Green or Blue". On top of all this, it is the preferred modeling method in an IPC environment, although other techniques do work.

To find out why this is the case, take a look at past CWG review articles on use of variant tables, or wait a while. Someone is sure to write a follow up to this article explaining it all…

Best Practice Recommendation

Yes, I'm going to do it. I'll take my foot out of my mouth and stick my neck on the chopping block.

The best modeling practice to restrict characteristic value domains in a SAP environment is Constraint Based Modeling as described in technique 6.

 

Why is this a best practice? In every case I can think of, this method

  • Allows the greatest flexibility in the product model
  • Reduces total cost of ownership of the software
  • Fits in best with the future direction of the software

Now, if most product configuration experts (yes, you the reader) out there will agree with it, I might have something I can take to my peers at Steelcase and drive some change…You see, Steelcase does not currently use this technique in our SAP R/3 Variant Configuration models. We use a combination of methods 1, 4, and a variant of 5. If you'd like specific examples of how I feel these methods have constrained or added cost to my company, please don't hesitate to call or email me…

About the author

Steve Schneider is a Product Data Analyst at Steelcase, Inc., the world's largest manufacturer of office furniture. He has been involved with product configuration since 1993. From 1993 to 1997 he modeled product in the Steelcase developed configurator, and from 1997 to present has modeled in SAP's R/3 system using Variant Configuration. Prior to becoming a Product Data Analyst, he worked for many years in Production and Inventory Control as a user of product data. He can be reached at;

Steve Schneider, VC Editor

(616)-246-4103